From rem-conf Wed Oct 01 10:17:43 1997 From rem-conf-request@es.net Wed Oct 01 10:17:42 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGS07-00044m-00; Wed, 1 Oct 1997 09:51:51 -0700 Date: Wed, 1 Oct 1997 09:51:50 -0700 Message-Id: <199710011651.AA28721@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: rem-conf@es.net Subject: Vern Paxson seminar today at 12 noon PST Reply-To: estrin@usc.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here it is wed morning and once again I forgot to send out a message yesterday saying that Dr. Vern Paxson will be speaking at the USC CS Dept wednesday-noon seminar. We hope to have video and slides in wb this time... From rem-conf Wed Oct 01 13:31:30 1997 From rem-conf-request@es.net Wed Oct 01 13:31:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGVIm-0007AJ-00; Wed, 1 Oct 1997 13:23:20 -0700 Sender: liao@ctr.columbia.edu Message-ID: <3432B0E6.40EC@ctr.columbia.edu> Date: Wed, 01 Oct 1997 16:21:58 -0400 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net CC: dimitris@watson.ibm.com, mnl@ctr.columbia.edu, ctr-pis@ctr.columbia.edu, ee-phd@ctr.columbia.edu, ee-ms@ctr.columbia.edu, image@ctr.columbia.edu Subject: Mbone Broadcast: OPENSIG FALL'97 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: OPENSIG FALL'97 Workshop Date: Monday, Oct. 6, 1997 8:45 AM - 6:45 PM EST Tuesday, Oct. 7, 1997 9:00 AM - 7:00 PM EST Multicast Address: audio: DVI, RTP, 224.2.191.165/30612 , ttl=127 video: H.261, RTP, 224.2.158.93/49180 , ttl=127 Contact: Dimitrios E. Pendarakis Andrew T. Campbell URL: http://comet.ctr.columbia.edu/opensig/activities/fall97.html Place: 4th Floor Schapiro Research Building Center for Telecommunications Research Columbia University 530 West 120th Street, New York City, USA Abstract: This is a two-day workshop on Open Signalling for ATM, Internet and Mobile Networks. Please refer to the web page for the detailed program schedule and presentation slides. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf Wed Oct 01 13:32:38 1997 From rem-conf-request@es.net Wed Oct 01 13:32:37 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGVPm-0007Ik-00; Wed, 1 Oct 1997 13:30:34 -0700 Sender: liao@ctr.columbia.edu Message-ID: <3432B2BC.5830@ctr.columbia.edu> Date: Wed, 01 Oct 1997 16:29:48 -0400 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu, ee-phd@ctr.columbia.edu, ee-ms@ctr.columbia.edu, ctr-pis@ctr.columbia.edu, image@ctr.columbia.edu Subject: Mbone Broadcast: OPENSIG FALL'97 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: OPENSIG FALL'97 Workshop Date: Monday, Oct. 6, 1997 8:45 AM - 6:45 PM EST Tuesday, Oct. 7, 1997 9:00 AM - 7:00 PM EST Multicast Address: audio: DVI, RTP, 224.2.191.165/30612 , ttl=127 video: H.261, RTP, 224.2.158.93/49180 , ttl=127 Contact: Dimitrios E. Pendarakis Andrew T. Campbell URL: http://comet.ctr.columbia.edu/opensig/activities/fall97.html Place: 4th Floor Schapiro Research Building Center for Telecommunications Research Columbia University 530 West 120th Street, New York City, USA Abstract: This is a two-day workshop on Open Signalling for ATM, Internet and Mobile Networks. Please refer to the web page for the detailed program schedule and presentation slides. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf Wed Oct 01 17:05:53 1997 From rem-conf-request@es.net Wed Oct 01 17:05:53 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGYhq-0003Sy-00; Wed, 1 Oct 1997 17:01:26 -0700 From: Marcia Perry Date: Wed, 1 Oct 1997 17:01:24 -0700 Message-Id: <199710020001.RAA09523@portnoy.lbl.gov> To: rem-conf@es.net Subject: New Version of confcntlr Cc: deba@george.lbl.gov Content-Length: 797 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everyone, We in the Imaging and Distributed Computing Group of Lawrence Berkeley National Lab, as part of the Spectro-Microscopy Collaboratory project (LabWeb), have completed a new version of our mbone tool, confcntlr. The upgraded version (V0.4) adds a great deal more functionality to the conference controller, including more control over vat. It can now also be launched from sdr. If you're interested in trying out this tool, the beta version (V0.4) is available from our web site: http://www-itg.lbl.gov/mbone/confcntlr If you have the older version, we encourage you to upgrade. Thanks, Deb Agarwal (DAAgarwal@lbl.gov) Marcia Perry (mperry@george.lbl.gov) MS50B-2239 phone :(510)486-7078 Lawrence Berkeley National Lab Berkeley, CA 94720 From rem-conf Thu Oct 02 01:25:41 1997 From rem-conf-request@es.net Thu Oct 02 01:25:40 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGgRY-0004Ka-00; Thu, 2 Oct 1997 01:17:08 -0700 Message-ID: <34335709.217B1BA5@KEGO.COM> Date: Thu, 02 Oct 1997 01:10:49 -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: H.263 inside RTP as per H.323(H.225)? Content-Type: multipart/mixed; boundary="------------26E7358F655223296DEC121D" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------26E7358F655223296DEC121D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit H.225 describes the format which to use H.261 over RTP. But currently vendors are shipping H.323 with H.263 over RTP, which isn't detailed in my copy of H.225 (May96) Could someone tell me where to find the documentation that vendors are using to implement interoperable H.323 with H.263 over RTP? Thanks, Cameron Elliott -- Cameron Elliott Kego - Software & Datacommuncations Unix, Embedded Software, TCP/IP, H.323 888-FOR-KEGO Cam@Kego.com --------------26E7358F655223296DEC121D 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 --------------26E7358F655223296DEC121D-- From rem-conf Thu Oct 02 02:09:12 1997 From rem-conf-request@es.net Thu Oct 02 02:09:10 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGhD9-0005Zv-00; Thu, 2 Oct 1997 02:06:19 -0700 Date: Thu, 02 Oct 1997 11:05:37 +0200 From: Della Betta Filippo Subject: RE: H.263 inside RTP as per H.323(H.225)? To: rem-conf@es.net, 'Cameron Elliott' Message-id: Old-X-Envelope-to: rem-conf@es.net MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable X-Priority: 3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RFC 2190 may help you. You can also find it here: ftp://ds.internic.net/rfc/rfc2190.txt > ---------- > From: Cameron Elliott[SMTP:cam@elliott.net] > Sent: gioved=EC, ottobre 02, 1997 9:10 > To: rem-conf@es.net > Subject: H.263 inside RTP as per H.323(H.225)? >=20 > <> > H.225 describes the format which to use > H.261 over RTP. > But currently vendors are shipping H.323 > with H.263 over RTP, which isn't > detailed in my copy of H.225 (May96) >=20 > Could someone tell me where to find the > documentation that vendors are using > to implement interoperable H.323 with > H.263 over RTP? >=20 > Thanks, > Cameron Elliott >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Cameron Elliott >=20 > Kego - Software & Datacommuncations > Unix, Embedded Software, TCP/IP, H.323 >=20 > 888-FOR-KEGO > Cam@Kego.com >=20 From rem-conf Thu Oct 02 02:16:49 1997 From rem-conf-request@es.net Thu Oct 02 02:16:48 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGhMj-0005y2-00; Thu, 2 Oct 1997 02:16:13 -0700 Date: Thu, 02 Oct 1997 11:15:46 +0200 From: Della Betta Filippo Subject: RE: H.263 inside RTP as per H.323(H.225)? To: 'REM-CONF' Message-id: Old-X-Envelope-to: rem-conf@es.net MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain Content-transfer-encoding: 7BIT X-Priority: 3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Could someone tell me where to find the > documentation that vendors are using > to implement interoperable H.323 with > H.263 over RTP? > > RFC 2190 may help you. You can also find it here: > > ftp://ds.internic.net/rfc/rfc2190.txt > > > > > > > From rem-conf Thu Oct 02 08:13:58 1997 From rem-conf-request@es.net Thu Oct 02 08:13:58 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGmpw-0005kC-00; Thu, 2 Oct 1997 08:06:44 -0700 Message-ID: <01BCCF23.229CD600.aheddaya@infolibria.com> From: "A. 'Solom' Heddaya" Reply-To: "aheddaya@infolibria.com" To: "'hipparch@sophia.inria.fr'" , "'enternet@bbn.com'" , "'xtp-relay@cs.concordia.ca'" , "'rem-conf@es.net'" , "'sigmedia@bellcore.com'" , "'mobile-ip@tadpole.com'" To: "'cellular@comnets.rwth-aachen.de'" , "'ieeetcpc@ccvm.sunysb.edu'" , "'cnom@maestro.bellcore.com'" , "'commsoft@cc.bellcore.com'" , "'multicomm@cc.bellcore.com'" , "'epr@infotest.com'" Cc: "'mouftah@eleceng.ee.queensu.ca'" , "'wieselthier@itd.nrl.navy.mil'" Subject: CFP -- ISCC'98, Athens -- deadline 11/1 Date: Thu, 2 Oct 1997 11:05:46 -0400 Organization: InfoLibria, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 Call for Papers The Third IEEE Symposium on Computers and Communications (ISCC'98) Athens, Greece June 30--July 2, 1998 Sponsored IEEE Communic. Society and IEEE Computer Society(*) The fast growing convergence between communications and computer technologies is having an increasingly profound impact on information and networking systems. This third annual event will provide a technical forum for experts >from industry and academia to exchange ideas and present results of ongoing research in the areas listed below. You are invited to submit a full paper, or a proposal for a panel, invited session, or tutorial, related to the following topics: - High Speed Networks, ATM/SONET/SDH - Multimedia Networking, Services and Applications - Intelligent Networks and Network Planning - Optical Systems and Networks - Network Interoperability and Internetworking - Internet Services - Electronic Commerce - Mobile Communications and Nomadic Computing - Wireless Networks - Access Networks - Satellite Communications - Simulation, Modeling, and Performance Evaluation - Network Management and Operations - Control and Optimization Methods for Communication Systems and Networks - Network Reliability and Quality of Service - Signal Processing in Communications and Networking - Distributed Systems - Software Engineering - Fault Tolerant Systems - Security, Privacy and Information Access - Computer Systems and Applications - Intelligent Highway Please send four copies of your original paper (not to exceed 20 double-spaced pages) to reach either Technical Program Co-Chair at the addresses below by November 1, 1997. Keywords should be included. The paper should clearly indicate the complete postal and electronic mailing addresses, as well as the phone and fax numbers of the corresponding author. Prof. Hussein Mouftah Tech Program Co-Chair, ISCC'98 Department of Electrical Engineering Queen's University Kingston, Ontario Canada K7L 3N6 Tel: +1 (613) 545-2934 Fax: +1 (613) 545-6615 mouftah@eleceng.ee.queensu.ca Dr. Jeffrey E. Wieselthier Tech Program Co-Chair, ISCC'98 Code 5521 Naval Research Laboratory 4555 Overlook Ave. SW Washington, DC 20375 USA Tel: +1 (202) 767-3043 Fax: +1 (202) 767-1191 wieselthier@itd.nrl.navy.mil ------------------------------------------------------------------------ Important Dates: - November 1, 1997: Paper submission deadline - February 15, 1998: Notifications of acceptance mailed to authors - March 15, 1998: Final camera-ready manuscripts due. ------------------------------------------------------------------------ General Chair: - P. A. Probst, Swiss Telecom, Switzerland Vice-chair: - H. Mouftah, Queens Univ, Canada. Steering Committee: - H. Abdel-Wahab, Old Dominion Univ, USA - T. N. Saadawi, City Univ of N.Y., USA - M. H. Sherif, AT&T Labs, France - G. Stassinopoulos, Nat Tech Univ of Athens, Greece - A. Tantawy, IBM T.J. Watson Research Ctr., USA Technical Program Commitee: - H. Mouftah, Queens Univ, Canada, (Co-Chair) - J. E. Wieselthier, Naval Res Lab, USA, (Co-Chair) - H. Afifi, ENST-Bertagne, France - J. Ash, AT&T Labs, USA - D. Baker, Naval Research Lab, USA - J. Baras, Univ of Maryland, USA - E. Chong, Purdue University, USA - I. Cidon, Technion, Israel - P. Constantinou, Nat Tech Univ of Athens, Greece - M. Daneshmand, AT&T Labs, USA - M. Elhadidi, Cairo Univ, Egypt - S. Elkhamy, Alexandria Univ, Egypt - A. Elrefaie, HP Labs, USA - M. Elsayed, AT&T Labs, USA - A. Ephremides, Univ of Maryland, USA - J. Garcia-Luna, Univ of CA, Santa Cruz, USA - E. Geraniotis, University of Maryland, USA - J. Gluck, US Patent & Trademark Office, USA - B. Hajek, University of Illinois, USA - J. Hayes, Concordia University, Canada - C. Kroell, European Space Agency, Germany - M. Malek, Lucent Technologies, USA - K. Maly, Old Dominion Univ, USA - I. Moskowitz, Naval Research Lab, USA - M. Nassar, AT&T Labs, USA - C. Perkins, Sun Microsystems, USA - A. Pitsillides, Univ of Cyprus, Cyprus - M. Pursley, Clemson University, USA - A. Saleh, AT&T Research, USA - C. Savolaine, AT&T Labs, USA - M. Sidi, Technion, Israel - E. Sykas, Nat Tech Univ of Athens, Greece - A. Tantawi, IBM T.J. Watson Research Ctr., USA - L. Tassiulas, University of Maryland, USA - M. Theologou, Nat Tech Univ of Athens, Greece - S. Thome, ENST-Paris, France - N. Zervos, Lucent Technologies, USA Registration & Finance Co-Chairs: - S. Elmaghraby, Univ of Louisville, USA - R. Ammar, Univ of Connecticut, USA - M. H. Fallah, Lucent Technologies, USA Local Committee - G. Stassinopoulos, NTU of Athens, Greece (Chair) - P. Constantinou, NTU of Athens, Greece - V. Daskalou, AUEB, Greece Tutorials Committee - H. Akhtar, AT&T Labs, USA (Chair) - W. Makky, FAA, USA - E. Sykas, Nat Tech Univ of Athens, Greece Publicity Committee - A. Heddaya, Boston University, USA (Chair) - S. El Hennaoui, ENST, France - N. Pavlidou, AUTH, Greece - K. Shenawy, AAST, Egypt ------------------------------------------------------------------------ * Technical Committee on Simulation ------------------------------------------------------------------------ Conference history - First ISCC, June 27-29 1995,Alexandria, Egypt - Second ISCC, July 1-3 1997,Alexandria, Egypt - Third ISCC, June 30-July 2 1998, Crete, Greece ------------------------------------------------------------------------ Web site: http://www.cs.bu.edu/ftp/amass/ISCC/ ------------------------------------------------------------------------ Maintained by Abdelsalam Heddaya. From rem-conf Thu Oct 02 16:03:54 1997 From rem-conf-request@es.net Thu Oct 02 16:03:54 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xGtzX-0000DY-00; Thu, 2 Oct 1997 15:45:07 -0700 Message-Id: <199710022243.PAA09648@tweety.main.gnac.com> To: baylisa@baylisa.org, sage-members@usenix.org, rem-conf@es.net Cc: bigmac@baylisa.org Subject: BayLISA: Upcoming meetings Date: Thu, 02 Oct 1997 15:43:49 -0700 From: Bryan McDonald X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. Please feel free to redistribute this meeting announcement. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco Building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. [Note: We will be back in the usual place in Building J for the upcoming meetings, our appologies for the confusion caused by the changed room at the September meeting.] Schedule ======== October 16: Software Configuration Management -- Lessons Learned, Steve Harris Thursday, October 16, 1997, 7:30 PM: Software Configuration Management (SCM) has evolved from early methodologies and tools (e.g.: SCCS) to high-end SCM systems which support a variety of development process models. Two and a half years ago, my organization purchased ClearCase, a high-end SCM tool. Before making the purchase, we evaluated most of the major SCM tools then available for our platform (SPARC, SunOS). Since then, we have had our share of learning pains as we deployed the tool, trained our users, and developed our SCM process; all the while continuing to ship software to our customers. This talk will describe: (1) our experiences evaluating SCM tools, and (2) some of the lessons we learned over the past couple years working with ClearCase. It will focus on the high-level changes to our software development culture rather than on the low-level specifics of the tool we chose. November 20: Larry Wall [Schedule subject to change] For further information on BayLISA, check out our web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/BayLISA/location For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or the info alias listed above. =============================================================================== Bryan McDonald bigmac@baylisa.org President president@baylisa.org BayLISA http://www.baylisa.org =============================================================================== - ------- End of Forwarded Message ------- End of Forwarded Message From rem-conf Fri Oct 03 06:25:38 1997 From rem-conf-request@es.net Fri Oct 03 06:25:37 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xH7bZ-0004ZT-00; Fri, 3 Oct 1997 06:17:17 -0700 From: Chas Williams Date: Fri, 3 Oct 1997 09:15:49 -0400 (EDT) Message-Id: <199710031315.JAA19958@borg.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Broadcasting of the White House Conference on Climate Change: The Challenge of Global Warming X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The White House Conference on Climate Change is being broadcast via satellite >from Georgetown University's Gaston Auditorium. The conference is scheduled to run from 10:00am to 4:30pm. There will be a lunch break from 1:00pm to 2:15pm during which the morning sessions will be re-broadcast. Session TTL 127 Video - H.261 (64kbps) Audio - PCM2 A brief version of the agenda: 10:00-10:05 Vice President Gore: Welcome attendees 10:05-10:20 President Clinton: Opening Remarks 10:20-11:20 Panel I: The Science of Global Warming and Climate Change 11:30-11:45 Vice President Gore: Remarks 11:45-12:45 Panel II: The Role of Technology in Reducing Greenhouse Gas Emissions 1:00-2:00 Lunch: Breakout Discussions with the Cabinet 2:15-2:30 Fist Lady Hillary Rodham Clinton: Remarks 2:30-3:30 Panel III: The Kyoto Conference and US National Interests 3:30-4:30 Panel IV: Climate Change Policy and the US Economy From rem-conf Fri Oct 03 06:39:11 1997 From rem-conf-request@es.net Fri Oct 03 06:39:10 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xH7tJ-00051H-00; Fri, 3 Oct 1997 06:35:37 -0700 Date: Fri, 3 Oct 1997 14:35:17 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Chas Williams cc: rem-conf@es.net Subject: Re: Broadcasting of the White House Conference on Climate Change: The Challenge of Global Warming In-Reply-To: <199710031315.JAA19958@borg.cmf.nrl.navy.mil> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 3 Oct 1997, Chas Williams wrote: > The White House Conference on Climate Change is being broadcast via satellite > from Georgetown University's Gaston Auditorium. The conference is scheduled > to run from 10:00am to 4:30pm. There will be a lunch break from 1:00pm to > 2:15pm during which the morning sessions will be re-broadcast. Could I remind people of the importance of stating timezones in these announcements. There have been several lately which have given no indication of timezone. Is this Eastern Daylight Time? ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ============================================================================= From rem-conf Sat Oct 04 04:46:35 1997 From rem-conf-request@es.net Sat Oct 04 04:46:34 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xHSUQ-00056y-00; Sat, 4 Oct 1997 04:35:18 -0700 Date: Sat, 4 Oct 1997 13:36:39 +0200 (MET DST) From: Electronic Commerce Message-Id: <199710041136.NAA28770@vsys1.informatik.uni-hamburg.de> Subject: ec98: Electronic Commerce Working Conference in Hamburg June 3-5 '98 Content-Type: text Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list International IFIP Working Conference on ELECTRONIC COMMERCE 98 in Hamburg, Germany +----------------------------------------------------------------+ | Now extended to 3 days ! | +----------------------------------------------------------------+ This is to announce the International IFIP Working Conference on Distributed Systems for Electronic Commerce to be held in Hamburg,Germany, June 3-5th, 1998. As we found your name and email address in some way related to distributed systems or electronic commerce we assume you may be interested in this event. We apologize if this assumption is not true or if you receive this announcement several times through different channels - even though this list was carefully assembled and checked. For more detailed information in this event please follow this link: http://vsys-www.informatik.uni-hamburg.de/ec98/ For the program committee, W. Lamersdorf and M. Merz +------------------------------------------------------------------+ | CALL FOR PAPERS | | International IFIP Working Conference on | | DISTRIBUTED SYSTEMS FOR ELECTRONIC COMMERCE | | Hamburg, Germany, June 3-5, 1998 | +------------------------------------------------------------------+ Electronic Commerce is currently one of the fastest growing and most practically relevant application areas of distributed systems technologies. It is based on the economic aspects of commercial trading patterns combined with distributed computing systems technology. It is a market environment that is characterized by low transaction costs, a large number of market participants, and facile online access to services and goods offered. It also implies a set of rules and policies for the successful organization of business transactions. Accordingly, open computer networks supporting commercial transactions show respective characteristics such as - a systems infrastructure that provides easy access to any kind of services (for both service providers as well as consumers), - a reasonable level of standardization for software components and communication protocols, - appropriate supporting functions such as locating services, accounting, security, and notarization, etc. Technically, these mechanisms support, e.g., distributed open and secure multimedia environments, service trading and brokerage functions, mobile and distributed software concepts, component-based development tools, etc. Consequently, Electronic Commerce is an area where distributed systems technologies have to meet the requirements of advanced applications that span locational as well as organizational boundaries. Therefore, potential Electronic Commerce service providers and users as well as researchers and implementers of emerging Electronic Commerce systems or components are invited to contribute with their individual experiences and research results in order to exchange their respective views with colleagues from both research and industry at the conference. CONFERENCE TOPICS ----------------- Topics of special interest include, but are not restricted to: - Economic Market Models and Foundations - Architectures for Electronic Marketplaces - Business Transaction Support - EDI vs. Internet - Workflow Management for Electronic Markets - System Support for Distributed Applications - Platforms: WWW, CORBA, Java, and beyond - Intelligent Agents and Multi-Agent Systems - Mobile Computing and Mobile Agent Systems - Trading and Information Brokerage - Service Specification, Quality of Service - Security & Payment Functions - Multimedia Shopping Malls and Kiosk Systems - Distributed Digital Library Applications IMPORTANT DATES AND DEADLINES ----------------------------- Paper Submissions until : December 8, 1997 Acceptance notification : February 1, 1998 Camera-ready paper due : March 15, 1998 Early bird registration until : April 17, 1998 CONFERENCE CHAIRS ----------------- W. Lamersdorf, M. Merz, Hamburg University, Germany PROGRAM COMMITTEE ----------------- N. Adam, Rutgers University, USA B. Bhargava, Purdue University, USA G. Blair, University of Lancaster, UK F. Caneschi, Finsiel, Italy W. Cellary, University of Economics at Poznan, Poland K. Crowston, Syracuse University, NY, USA J. Cunningham, Imperial College London, UK K. Geihs, University of Frankfurt, Germany L. Huguet, University of the Baleares, Spain G. Karjoth, IBM Rueschlikon, Switzerland C. Linnhoff-Popien, RWTH Aachen, Germany H. de Meer, Hamburg University, Germany Z. Milosevic, DSTC, Australia M. Muehlhäuser, University of Linz, Austria J. Posegga, Deutsche Telekom AG, Germany A. Puder, ICSI/Berkeley, USA K. Rothermel, University of Stuttgart, Germany A. Schill, Techn. University of Dresden, Germany B. Schmid, University St. Gallen, Switzerland G. Schuermann, GMD FOKUS, Berlin, Germany J. Slonim, University of Toronto, Canada R. Soley, OMG, USA O. Spaniol, RWTH Aachen, Germany R. Steinmetz, Technical University Darmstadt, Germany D. O'Sullivan, IONA, Ireland A. Vogel, Visigenic, USA Y. Yesha, NASA, USA +----------------------------------------------------------------+ | Further Information may be obtained from the EC98 Web Site: | | http://vsys-www.informatik.uni-hamburg.de/ec98 | | Contact and further information: merz@informatik.uni-hamburg.de| +----------------------------------------------------------------+ From rem-conf Sun Oct 05 02:49:39 1997 From rem-conf-request@es.net Sun Oct 05 02:49:39 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xHn5a-00040J-00; Sun, 5 Oct 1997 02:35:02 -0700 Date: Sun, 5 Oct 97 17:15:34 CST Message-Id: <9710050915.AA17039@Venus.sui.ustc.edu.cn> From: Tao Chen To: "aheddaya@infolibria.com" , ghafoor@ecn.purdue.edu, djensen@pri.org, aheddaya@infolibria.com, hipparch@sophia.inria.fr, enternet@bbn.com, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, multicomm@cc.bellcore.com, epr@infotest.com, mouftah@eleceng.ee.queensu.ca, wieselthier@itd.nrl.navy.mil Subject: Re: CFP -- ISCC'98, Athens -- deadline 11/1 In-Reply-To: <01BCCF23.229CD600.aheddaya@infolibria.com> References: <01BCCF23.229CD600.aheddaya@infolibria.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.22 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe tchen@venus.sui.ustc.edu.cn From rem-conf Tue Oct 07 19:14:57 1997 From rem-conf-request@es.net Tue Oct 07 19:14:56 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xIlAh-0003i8-00; Tue, 7 Oct 1997 18:44:19 -0700 Sender: hgs@cs.columbia.edu Message-ID: <343AE56E.4DA9A2F4@cs.columbia.edu> Date: Tue, 07 Oct 1997 21:44:14 -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: rem-conf@es.net Subject: PCMCIA frame grabbers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Any pointers to PCMCIA video frame grabber cards are appreciated. I've seen the www.nogatech.com one; any experiences? Non-Windows drivers? Thanks. -- 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 From rem-conf Tue Oct 07 21:54:07 1997 From rem-conf-request@es.net Tue Oct 07 21:54:06 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xInjU-0004xC-00; Tue, 7 Oct 1997 21:28:24 -0700 From: IEEE Multimedia Systems Conference Date: Tue, 7 Oct 1997 23:28:17 -0500 Message-Id: <199710080428.XAA10608@homburg.cs.utexas.edu> To: rem-conf@es.net Subject: Call for Papers: IEEE Multimedia Systems '98 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ======================================================================== CALL FOR PAPERS ========================================================================= IEEE Multimedia Systems'98 June 28-July 1, 1998 Renaissance Austin Hotel Austin, Texas, USA Sponsored by IEEE Computer Society* * Approval pending ======================================================================== The Call for Papers and the Prospectus (e.g., for exhibits, demos, workshops and panels) in Acrobat PDF format can be obtained from: http://www.utexas.edu/coe/sqi/confs/ieee/multi.html ======================================================================== IEEE Multimedia Systems is an annual conference organized with the objective of bringing together researchers, developers, and practitioners from academia and industry working in all facets of multimedia, content authoring, processor technology, and systems design. The conference serves as a forum for the dissemination of state-of-the-art research, development, and implementations of multimedia systems, technologies, and applications. A key objective of IEEE Multimedia Systems'98 is to create a program that achieves a balance between theory and practice, academia and industry, systems/tools-oriented research and content creation. The topics of interest include, but are not limited to: * Network and operating system support for multimedia * Quality-of-service control and scheduling algorithms * Multimedia file systems and databases * Audio and video compression * Sound and MIDI music, surround and around video * Set-top technologies and operating systems * Multimedia processor architecture * Computer-aided training and education, tele-medicine * Animation and morphing, fractals and rendering * Virtual reality * Mobile network architecture * Intelligent network applications * Internet and intranet applications * Web servers and services * Multimedia conferencing, internet phones, and mail * Electronic commerce * User interfaces * Authoring systems * Entertainment and games IEEE Multimedia Systems'98 will include a single-track technical program, a full day of tutorials, and several new exciting features such as focussed technical workshops, exhibits/demonstrations, and special multimedia showcase events in the evenings. You are cordially invited to participate in IEEE Multimedia Systems'98 in one or more of the following ways. TECHNICAL PAPERS Technical papers are scheduled to be presented on June 29-July 1, 1998, and will be published in the Conference Proceedings. Descriptions of original and significant research, the results of empirical studies, and innovative applications in the area of multimedia systems are solicited. Please submit 5 copies of each paper. Submissions must use a minimum of 10-point typeface, and should not exceed 15 single-spaced pages (preferably double sided), including figures, tables, and references. Where applicable, submission of prototype demonstrations or videotape presentations are encouraged to supplement the papers. For each paper, please also submit a cover page containing the title of the paper, author names and their affiliations, the topic area(s), and an abstract. The cover page should be submitted in plain text format by e-mail to: ieeemm@sqi.utexas.edu. PANELS Panel presentations are scheduled for June 29-July 1, 1998. Topics that examine innovative, controversial, or otherwise provocative issues are being sought. Proposals for panels should be limited to 2 pages and include a 2-paragraph publishable biography of the panel organizer and the number of panelists. Please send an e-mail to ieeemm@sqi.utexas.edu for more information. TUTORIALS Tutorials are scheduled for June 28, 1998. Topics for both novice and seasoned professionals are solicited. Tutorial proposals (at most 5 pages) should include a description of the subject matter, and a 2-paragraph publishable biography of the instructors. Please send an e-mail to ieeemm@sqi.utexas.edu for more information. DEMONSTRATIONS Demonstrations are scheduled for June 29-July 1, 1998. Working systems in technical and artistic categories are solicited. Submissions (at most 2 pages) should include a description of the demonstration requirements, a 2-paragraph publishable biography of the demonstration leader, the number of people involved, and demonstration samples on CD-ROM, the World Wide Web, or a VHS NTSC video, as appropriate. Please send an e-mail to ieeemm@sqi.utexas.edu for more information. WORKSHOPS Workshops are scheduled for June 29-July 1, 1998, focusing on techniques, tools and breakthroughs that will carry members of the multimedia research and development community and field practitioners into the 21st century. Each workshop plans to relate to a common area of technology and present the innovation(s) therein. Competing technical approaches will be organized for each session to promote interaction with the audience. Workshop proposals should include a clear statement of objectives, the target audience, and a 2-paragraph publishable biography for the workshop leader. Please send an e-mail to ieeemm@sqi.utexas.edu for more information. EXHIBITS The IEEE Multimedia Systems'98 will offer multimedia product vendors and publishers an opportunity to interface with more than 400 conference participants worldwide. Displays and demonstrations of product lines may include (but are not limited to) technologies and research prototypes as well as commercial products. Please send an e-mail to ieeemm@sqi.utexas.edu for more information. SUBMISSION GUIDELINES All submissions must be sent to the following address. Postal Mail: IEEE Multimedia Systems'98 Software Quality Institute The University of Texas at Austin PRC/MER MC R9800 Austin, TX 78712-1080 Express Mail (e.g., FedEx): IEEE Multimedia Systems'98 Software Quality Institute The University of Texas at Austin 10100 Burnet Road, Bldg. 160, Rm. 2l206T Austin, TX 78758 Phone : (512) 471-4875 Fax: (512) 471-4824 E-mail: ieeemm@sqi.utexas.edu IMPORTANT DATES All submissions due: October 31, 1997 Notification of acceptance: February 6, 1998 Final manuscripts due: March 20, 1998 From rem-conf Wed Oct 08 06:09:36 1997 From rem-conf-request@es.net Wed Oct 08 06:09:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xIvio-0007kZ-00; Wed, 8 Oct 1997 06:00:14 -0700 Message-Id: <199710081256.IAA12884@gte.com> From: "Chris Martin" To: "Henning Schulzrinne" , Subject: Re: PCMCIA frame grabbers Date: Wed, 8 Oct 1997 08:53:37 -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 > Any pointers to PCMCIA video frame grabber cards are appreciated. The following site lists some of the available cards. http://www.ct-oy.com/artsi/pcmcia.html From rem-conf Wed Oct 08 06:22:36 1997 From rem-conf-request@es.net Wed Oct 08 06:22:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xIw1C-0000Ie-00; Wed, 8 Oct 1997 06:19:14 -0700 From: Toerless Eckert Message-Id: <199710081318.PAA03303@faui45r.informatik.uni-erlangen.de> Subject: Re: PCMCIA frame grabbers In-Reply-To: <343AE56E.4DA9A2F4@cs.columbia.edu> from Henning Schulzrinne at "Oct 7, 97 09:44:14 pm" To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 8 Oct 1997 15:18:57 +0200 (MET DST) Cc: rem-conf@es.net Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL35 (25)] 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 > Any pointers to PCMCIA video frame grabber cards are appreciated. I've > seen the www.nogatech.com one; any experiences? Non-Windows drivers? Just the usual recommendation: Matrox Meteor if you want to go for an old but reliable and expensive card. Drivers for freebsd and linux available. If you want something new, fast and inexpensive, go for Bt848 based framegrabber, there are a lot out there, i.e.: Hauppauge WiN/TV amongst others. Which OS do you need ? From rem-conf Wed Oct 08 06:22:43 1997 From rem-conf-request@es.net Wed Oct 08 06:22:43 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xIw1s-0000Jr-00; Wed, 8 Oct 1997 06:19:56 -0700 From: Toerless Eckert Message-Id: <199710081319.PAA03311@faui45r.informatik.uni-erlangen.de> Subject: Re: PCMCIA frame grabbers In-Reply-To: <343AE56E.4DA9A2F4@cs.columbia.edu> from Henning Schulzrinne at "Oct 7, 97 09:44:14 pm" To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 8 Oct 1997 15:19:50 +0200 (MET DST) Cc: rem-conf@es.net Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL35 (25)] 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 Forget my previous mail, i couldn't read (thought i read PCI) Sorry Toerless From rem-conf Wed Oct 08 10:36:04 1997 From rem-conf-request@es.net Wed Oct 08 10:36:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xIzuI-0001Y8-00; Wed, 8 Oct 1997 10:28:22 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 8 Oct 1997 10:27:56 -0700 (PDT) Message-Id: <199710081727.KAA07347@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Applications of Video Server Technology in a Commercial Television Station X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Applications of Video Server Technology in a Commercial Television Station Date: Oct 15, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w8.html Description: Abstract: KGO-TV is the prototype facility at ABC for the implementation of video server technology. As a result, KGO has been the most agressive television station in the country at converting from video tape to computer technology for the storage, editing, and playout of video and audio material. This implementation relies heavily on the use of data tape silos for near-line library storage. This paper will outline KGO's progress as well as the anticipated future requirements for DTV Broadcast, current and future asset management requirements, and the possible uses of voice identification and scene recognition in automating the creation of improved meta-data. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Oct 08 10:56:04 1997 From rem-conf-request@es.net Wed Oct 08 10:56:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJ0IW-0004Zd-00; Wed, 8 Oct 1997 10:53:24 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 8 Oct 1997 10:52:23 -0700 (PDT) Message-Id: <199710081752.KAA07384@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: "Object-based Navigation for Content-based Image and Video Retrieval" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: "Object-based Navigation for Content-based Image and Video Retrieval" Date: Oct 22, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w9.html Description: Multimedia data such as an image and video are composed of several meaningful components. For example, an image consists of a car, a woman and a mountain and each of them is described with visual characteristics. We call this meaningful component "object" mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Oct 09 07:23:18 1997 From rem-conf-request@es.net Thu Oct 09 07:23:16 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJJCW-0000Mj-00; Thu, 9 Oct 1997 07:04:28 -0700 Sender: mueller@es.net Message-ID: <343CE45A.5306@fh-zwickau.de> Date: Thu, 09 Oct 1997 16:04:10 +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: XI. Deutsch-Niederländisch-Flämische Hochschulkonferenz Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: XI. Deutsch-Niederländisch-Flämische Hochschulkonferenz Date: October 13, 1997 Time: 10:00 MET; 9 hours Contact org: wolfgang.grundmann@fh-zwickau.de Contact tech: rainer.mueller@fh-zwickau.de URL: http://www.fh-zwickau.de/veranst/dnf-hk/hk-nf-hp.htm Description: The Conference takes place from October 12 -14, 1997 in Zwickau (Germany) and will be transmitted on MBone at October 13, 1997. -- 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 Oct 09 15:02:25 1997 From rem-conf-request@es.net Thu Oct 09 15:02:25 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJQWo-0003mh-00; Thu, 9 Oct 1997 14:53:54 -0700 Message-ID: From: "Anders Klemets (VXtreme)" To: "'rem-conf@es.net'" Subject: RTP payload format for ASF streams Date: Thu, 9 Oct 1997 14:53:48 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a document that specifies an RTP payload format for ASF (Advanced Streaming Format) streams. I intend to submit the document as an Internet Draft in a few days, but first I would like to see if I can get any comments from the members of this group. Some of you might recall the ASF presentation that was given at the AVT meeting in Los Angeles, one and a half years ago. That version of ASF tried to be both a file format and a networking protocol. Forget about that. ASF has been revised since then. It is now only a file format. The latest ASF spec can be found at http:://www.microsoft.com/asf Here is the abstract of the Internet Draft: This document specifies the payload format for encapsulating Advanced Streaming Format (ASF) streams in the Real-time Transport Protocol (RTP). This specification is primarily intended for ASF media types or codecs that are not already handled by other RTP payload specifications. Each ASF stream is sent with a separate RTP synchronization source ID and the streams are synchronized using standard RTP techniques. A special encapsulation scheme for ASF streams is described, where each RTP packet contains an ASF payload header and an ASF payload. This specification is primarily intended for streaming ASF streams that do not require reliable transfer. You can get the draft using this URL: ftp://ftp.vxtreme.com/pub/incoming/draft-klemets-asf-rtp-00.txt Anders From rem-conf Fri Oct 10 04:21:37 1997 From rem-conf-request@es.net Fri Oct 10 04:21:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJd0l-000714-00; Fri, 10 Oct 1997 04:13:39 -0700 Date: Fri, 10 Oct 1997 13:11:35 +0200 (METDST) From: Rogelio Montanana X-Sender: montanan@iluso.ci.uv.es To: iris-mbone@listserv.rediris.es, mbone-es@listserv.rediris.es, rem-conf@es.net cc: Fernando Dura Subject: Solicitud de creacion de sesion MBone Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list La siguiente sesion ha sido ya reservada rellenando el correspondiente formulario, pero al observar que no aparece alli campo para algunos de los datos solicitados enviamos tambien este mensaje. Organizacion: Universidad de Valencia Titulo de la sesion: Reunion interna del proyecto Neptuno Breve extradcto del contenido: Reunion privada de coordinacion de los participantes en el proyecto Neptuno, financiado por la Comision Europea, dedicado a ensenyanza a distancia mediante recursos telematicos. Fecha de comienzo: 23-OCT-97 Fecha de terminacion: 24-OCT-97 Hora de comienzo: 9:30 GMT (ambos dias) Duracion: una hora cada sesion Alcance: europeo (TTL 64) Maximo ancho de banda utilizado: 256 Kbps Tipo de la sesion: audio (DVI2) y video (H.261) Direccion de correo electronico del responsable tecnico de la retransimision: Fernando.Dura@uv.es ------------------------------------------------------------------------ Rogelio Montanana, System Analyst Valencia University Computer Center Tel: +34-6-3864310 Dr. Moliner, 50 Fax: +34-6-3864200 46100 Burjassot (Valencia) e-mail: rogelio.montanana@uv.es Spain From rem-conf Fri Oct 10 09:00:37 1997 From rem-conf-request@es.net Fri Oct 10 09:00:37 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJhHs-0000fJ-00; Fri, 10 Oct 1997 08:47:36 -0700 Message-Id: <199710101546.IAA06761@mailhost.nttlabs.com> To: "Anders Klemets (VXtreme)" Cc: "'rem-conf@es.net'" Subject: Re: RTP payload format for ASF streams Reply-to: sumisu@nttlabs.com (Jeffrey D. Smith) In-reply-to: Your message of "Thu, 09 Oct 1997 14:53:48 PDT" References: Date: Fri, 10 Oct 1997 08:14:46 -0700 From: Jeff Smith X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list After a quick look... this is the reverse of what I was hoping for. Fine, now we can carry ASF in RTP as we do any other codec type, but I was hoping for ASF to be useable as a storage/file format for RTP streams. Oh well, one can only hope. js From rem-conf Fri Oct 10 11:50:29 1997 From rem-conf-request@es.net Fri Oct 10 11:50:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJk4v-000261-00; Fri, 10 Oct 1997 11:46:25 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 10 Oct 1997 11:46:03 -0700 (PDT) Message-Id: <199710101846.LAA08788@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: A Multicast User Directory Service for Synchronous Rendezvous X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: A Multicast User Directory Service for Synchronous Rendezvous Date: Oct 29, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w10.htm Description: There is a recurring need for a dynamic Internet phonebook for collaborative applications. This talk focuses on the design of a multicast user directory service to meet that need. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 10 11:50:31 1997 From rem-conf-request@es.net Fri Oct 10 11:50:31 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJk4w-00026C-00; Fri, 10 Oct 1997 11:46:26 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 10 Oct 1997 11:46:11 -0700 (PDT) Message-Id: <199710101846.LAA08806@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: A Multicast User Directory Service for Synchronous Rendezvous X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: A Multicast User Directory Service for Synchronous Rendezvous Date: Oct 29, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w10.htm Description: There is a recurring need for a dynamic Internet phonebook for collaborative applications. This talk focuses on the design of a multicast user directory service to meet that need. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 10 11:52:02 1997 From rem-conf-request@es.net Fri Oct 10 11:52:02 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJk9o-0002ID-00; Fri, 10 Oct 1997 11:51:28 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 10 Oct 1997 11:51:14 -0700 (PDT) Message-Id: <199710101851.LAA08846@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Application-Controllable Quality of Service Management Platform X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Application-Controllable Quality of Service Management Platform Date: Nov 05, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w11.htm Description: With the temporal audio-visual and sensory information in various distributed multimedia applications, the provision of end-to-end quality of service (QoS) guarantees is a major acceptance factor for these applications. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 10 12:03:30 1997 From rem-conf-request@es.net Fri Oct 10 12:03:30 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJkIT-0003VY-00; Fri, 10 Oct 1997 12:00:25 -0700 Message-Id: <3.0.3.32.19971010120006.00dde198@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 10 Oct 1997 12:00:06 -0700 To: ASF List , rem-conf@es.net From: Rob Lanphier Subject: Re: RTP payload format for ASF streams 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:56 PM 10/9/97 -0700, Anders Klemets (VXtreme) wrote: >This is to announce a document that specifies an RTP payload format for >ASF (Advanced Streaming Format) streams. I intend to submit the >document as an Internet Draft in a few days, but first I would like to >see if I can get any comments from the members of this group. I'm confused. ASF is a codec-independent file-format. Payload types are typically assigned to codecs. Why is there a need for a payload format for ASF in RTP? 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 From rem-conf Fri Oct 10 12:06:06 1997 From rem-conf-request@es.net Fri Oct 10 12:06:06 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJkNN-0003dt-00; Fri, 10 Oct 1997 12:05:29 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 10 Oct 1997 12:05:08 -0700 (PDT) Message-Id: <199710101905.MAA08876@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Application-Controllable Quality of Service Management Platform X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Application-Controllable Quality of Service Management Platform Date: Nov 05, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w11.html Description: With the temporal audio-visual and sensory information in various distributed multimedia applications, the provision of end-to-end quality of service (QoS) guarantees is a major acceptance factor for these applications. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 10 12:06:43 1997 From rem-conf-request@es.net Fri Oct 10 12:06:43 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJkOL-0003mQ-00; Fri, 10 Oct 1997 12:06:29 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 10 Oct 1997 12:05:58 -0700 (PDT) Message-Id: <199710101905.MAA08903@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: A Multicast User Directory Service for Synchronous Rendezvous X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: A Multicast User Directory Service for Synchronous Rendezvous Date: Oct 29, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w10.html Description: There is a recurring need for a dynamic Internet phonebook for collaborative applications. This talk focuses on the design of a multicast user directory service to meet that need. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 10 12:36:48 1997 From rem-conf-request@es.net Fri Oct 10 12:36:47 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJkpU-0005Bm-00; Fri, 10 Oct 1997 12:34:32 -0700 Message-ID: From: "Anders Klemets (VXtreme)" To: 'Rob Lanphier' , ASF List , rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Fri, 10 Oct 1997 12:31:41 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Friday, October 10, 1997 12:00 PM, Rob Lanphier [SMTP:robla@real.com] wrote: > I'm confused. ASF is a codec-independent file-format. Payload types are > typically assigned to codecs. Why is there a need for a payload format for > ASF in RTP? The idea is that would you use the payload format when there is no other suitable RTP payload format defined defined for your codec. (This is also mentioned in the Abstract, BTW.) This payload format can also be used as a generic payload format. Suppose you have a video server that has access to thousands of ASF files. The files may contain media from a large number of different codecs. You would have to change your server, to add an implementation of an RTP payload type handler, for each new codec that appears in an ASF file. That is clearly not acceptable in many situations. This payload specification solves that problem by defining a generiec ASF payload type, that can be used as the payload type for any codec that appears in the ASF file. Anders From rem-conf Fri Oct 10 12:54:06 1997 From rem-conf-request@es.net Fri Oct 10 12:54:06 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJl5w-0005hs-00; Fri, 10 Oct 1997 12:51:32 -0700 Message-Id: <3.0.3.32.19971010125115.0167f6fc@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 10 Oct 1997 12:51:15 -0700 To: "Anders Klemets (VXtreme)" , ASF List , rem-conf@es.net From: Rob Lanphier Subject: RE: RTP payload format for ASF streams 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:31 PM 10/10/97 -0700, Anders Klemets (VXtreme) wrote: >The idea is that would you use the payload format when there is no other >suitable RTP payload format defined defined for your codec. (This is >also mentioned in the Abstract, BTW.) > >This payload format can also be used as a generic payload format. >Suppose you have a video server that has access to thousands of ASF >files. The files may contain media from a large number of different >codecs. You would have to change your server, to add an implementation >of an RTP payload type handler, for each new codec that appears in an >ASF file. Sure, but wouldn't this problem be better solved by generalized extensions to the RTP header rather than something specific to a particular file format. What happens when you have a media server that has access to thousands of ASF, Quicktime, AVI, and WAV files. Why should generalized extensions for one file format be any differnt than generalized extensions for another format? 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 From rem-conf Fri Oct 10 14:26:14 1997 From rem-conf-request@es.net Fri Oct 10 14:26:14 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xJmWV-0006qW-00; Fri, 10 Oct 1997 14:23:03 -0700 Message-ID: From: "Anders Klemets (VXtreme)" To: 'Rob Lanphier' , ASF List , rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Fri, 10 Oct 1997 14:22:47 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Friday, October 10, 1997 12:51 PM, Rob Lanphier [SMTP:robla@real.com] wrote: > What happens when you have a media server that has access to > thousands of ASF, Quicktime, AVI, and WAV files. You can handle that is in several ways. Here are two possibilities: 1) You implement the RTP payload type specifications for each of the four different file formats. Four different payload types is not too bad. It would be much worse if there were no payload type specifications for ASF or QuickTime. 2) Use the ASF payload type specification to transmit the QuickTime, AVI and WAV data. The ASF payload type is not really limited to ASF files. Obviously, if your data is stored in the ASF format, it is going to be easy to send it using the ASF payload type specification. If your data is stored in some other format, you will have to do some more work, but it should not be extremely difficult. > wouldn't this problem be better solved by generalized extensions > to the RTP header rather than something specific to a particular file > format. Maybe. But in my opinion such a thing would have to be an effort that is initialized by the AVT group, rather than any single company. I think that a "generalized extension to the RTP header" would be harder for the RTP developer community to swallow than a single payload type definition. Here is why: You can only add one extension to the RTP header, and the general concenus seems to be that it should be reserved for extensions that are applicable to all payload types, such as encryption. The alternative is to define a separate RTP profile. With an RTP profile you can redefine the meaning of fields in the RTP header, and probably also extend the header with additional fields. This would be a much more incompatible change for most existing RTP implementations, than just adding a new payload type. But by all means, if somebody else wants to pursue such an approach, they are obviously free to do so. Anders From rem-conf Tue Oct 14 14:41:03 1997 From rem-conf-request@es.net Tue Oct 14 14:41:02 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xLEPO-0004qo-00; Tue, 14 Oct 1997 14:21:42 -0700 Date: Tue, 14 Oct 1997 17:21:12 -0400 From: Debanjan Saha Message-Id: <9710142121.AA24654@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: CFP: JHSN special issue on Multimedia Networking Cc: tripathi@engr.ucr.edu 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. You can also submit papers electronically by sending postscript files via e-mail. 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 -------------------------------------------------------------------------------- Editorial Board of JHSN Editor-in-Chief Professor Deepinder Sidhu Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County Telephone: 410-455-3028 Fax: 410-455-3969 Email: sidhu@cs.umbc.edu Editorial Board Members Anthony Acampora(University of California, San Diego) Subrata Banerjee (Stevens Institute of Technology) Anthony Chung (Depaul University) Fow-Sen Choa (University of Maryland Baltimore County) Rene L. Cruz (University of California, San Diego) J.J. Garcia-Luna-Aceves(University of California, Santa Cruz) Inder Gopal (Prodigy) Roch Guerin (IBM T.J. Watson Research Center) Cesar Johnston (NEC) Michael C. Hluchyj (Summa Four, Inc.) Raj Jain (Ohio State University) Srinivasan Keshav (Cornell University) Leonard Kleinrock (University of California, Los Angeles) Arvind Krishna (IBM T. J. Watson Research Center) Srikantha Kumar (Northwestern University) L. Landweber (University of Wisconsin) Brad Makrucki (IBM) Debasis Mitra (AT&T Bell Laboratories) Howard Motteler (UMBC) Biswanath Mukherjee (University of California, Davis) Kinji Ono (National Center for Science Information Systems, Japan) Abhey Parekh (Sun Microsystems) Steve Pink (SICS,Sweden) Neil Ransom Bell (South Communications) Norio Shiratori (Tohoku University, Japan) Dinkar Sitaram (IBM T.J. Watson Research Center) Jonathan M. Smith (University of Pennsylvania) O. Spaniol (Technical University Aachen, Germany) Martha Steenstrup (BBN Systems and Technologies) James Sterbenz (GTE Laboratories) Fouad Tobagi (Stanford University) Satish K. Tripathi (University of California, Riverside) Richard Watson (Lawrence Livermore National Laboratory) Ellen W. Zegura (Georgia Tech) PUBLISHER: IOS Press, Netherlands From rem-conf Wed Oct 15 03:42:09 1997 From rem-conf-request@es.net Wed Oct 15 03:42:08 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xLQnZ-0000oJ-00; Wed, 15 Oct 1997 03:35:29 -0700 Sender: mech@helios Message-ID: <34449C44.237C228A@tnt.uni-hannover.de> Date: Wed, 15 Oct 1997 12:34:44 +0200 From: Roland Mech Organization: Universitaet Hannover, Theoretische Nachrichtentechnik X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3 sun4m) To: rem-conf@es.net Subject: vic and SIEMENS I-VIEW videoconferencing card MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, does anybody know a patch for the vic mbone-tool or a vic binary so that vic can be used with the "SIEMENS I-VIEW" videoconferencing card? Thank you very much in advance, Roland Mech ________________________________________________________________________ Dipl.-Inform. Roland Mech Universität Hannover Institut für Theoretische Nachrichtentechnik und Informationsverarbeitung Appelstraße 9A 30167 Hannover, Germany phone: +49-511-762-5308, fax: +49-511-762-5333 mailto:mech@tnt.uni-hannover.de http://www.tnt.uni-hannover.de/~mech.html ________________________________________________________________________ From rem-conf Wed Oct 15 07:50:30 1997 From rem-conf-request@es.net Wed Oct 15 07:50:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xLUcd-0002E2-00; Wed, 15 Oct 1997 07:40:27 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 15 Oct 1997 07:39:32 -0700 (PDT) Message-Id: <199710151439.HAA11407@hille.msri.org> To: rem-conf@es.net From: Reply-to: jyluke@ew.mimos.my Subject: Malaysia's 1998 Budget Speech X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Malaysia's 1998 Budget Speech Date: Oct 17, 1997 Time: 17:00 GMT+8 2 hours Contact: jyluke@ew.mimos.my URL: http://www.treasury.gov.my/ Description: Malaysia was recently hit by currency issues and was said to face a tough challenge in its future. Listen to Malaysia's Finance Minister on how Malaysia will face this challenge in his 1998 Budget Speech. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Oct 17 04:38:24 1997 From rem-conf-request@es.net Fri Oct 17 04:38:23 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xMAMW-0001A0-00; Fri, 17 Oct 1997 04:14:36 -0700 Message-ID: <344748F5.726D@ew.mimos.my> Date: Fri, 17 Oct 1997 19:16:05 +0800 From: JY Luke Reply-To: jyluke@ew.mimos.my Organization: MIMOS Berhad X-Mailer: Mozilla 3.03 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: MBone Session confirmation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I was having problem with my MBone feed for more than a week and was only able to get it back two days ago. I am able to recieve sessions but not sure if the session I created was able to view by others. Can anybody tell me if you can recieve any of these sessions: Malaysia's 1998 Budget Speech Test from Malaysia Your feedback is much appreciated. Thanks in advance. JY Luke From rem-conf Sun Oct 19 12:57:34 1997 From rem-conf-request@es.net Sun Oct 19 12:57:34 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xN1Bt-00057U-00; Sun, 19 Oct 1997 12:39:09 -0700 Date: Mon, 20 Oct 1997 03:33:15 +0800 From: gskuo@IMRNET.MGT.NCU.EDU.TW (G.S. Kuo) Message-Id: <199710191933.DAA02371@IMRNET.MGT.NCU.EDU.TW> To: cost237-transport@comp.lancs.ac.uk, rem-conf@es.net, reres@laas.fr, sigmedia@bellcore.com, xtp-relay@cs.concordia.ca Subject: Advanced Technical Program of IEEE BSS'97 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE BSS '97 2nd IEEE International Workshop on Broadband Switching Systems The Ritz Taipei Hotel, Taipei, R.O.C., 2-4 December 1997 Workshop Theme: "Switching Systems for the Broadband Internet and for QoS on Demand" Technical Sponsored by IEEE Communications Society. Sponsored by National Science Council of ROC. Co-sponsored by The Ministry of Education of ROC Chunghwa Telecom Co., Ltd., ROC ITRI, ROC (pending) Ericsson Taiwan Ltd. National Central University, ROC. OBJECTIVE ========= The goal of this workshop is to provide an effective forum for discussing new directions, new challenges, new opportunities, and new advances on Broadband Switching Systems, and to foster communications among researchers and engineers from both academia and industry with a common interest in improving Broadband Switching Systems. WORKSHOP ORGANIZERS =================== Honorary General Co-Chairs: C. H. Liu, National Central University, Taiwan, ROC. Maurizio Decina, Politecnico di Milano/CEFRIEL, Italy General Chair: Jin-Fu Chang, National Science Council, ROC. Vice General Co-Chairs: Wen-Tsuen Chen, National Tsing Hua University, Taiwan, ROC. Jean-Lien C. Wu, National Taiwan Institute of Technology, ROC. Keynote Speaker: Steve Weinstein, NEC America, USA Technical Program Committee Co-Chairs: G.S. Kuo, National Central University, Taiwan, ROC. Kai Eng, Bell Labs., USA Technical Program Committee: Chung-Ju Chang, National Chiao Tung University, Taiwan, ROC. Jurgen Haag, Deutsche Telekom, Germany Bijan Jabbari, George Mason University, USA Andrzej Jajszczyk, Institute of Communication and Information Technologies Ltd., Poland Dennis Kong, Bellcore, USA Lung-Sing Liang, Telecommunication Laboratories, Chunghwa Telecom Co., Ltd., Taiwan, ROC. Steve Liu, GTE Labs., USA Richard Vickers, NORTEL, Canada Naoaki Yamanaka, NTT, Japan Chu Hwan Yim, ETRI, Korea ADVANCED TECHNICAL PROGRAM ========================== ========================== Day One - Tuesday, December 2, 1997. ==================================== 9:00 - 12:00 Tutorial 1: Nonblocking Multirate Switching Networks Frank K. Hwang, Bell Labs. ABSTRACT To combine audio, data and video networks all into one, an ATM network must be able to connect requests requiring a broad range of bandwidths, or rates. The classical theory on nonblocking networks needs a complete overhaul for this new multirate environment. I will present the up-to-date story on the recent development of this new theory, taken from a chapter from my upcoming book "Mathematical Theory of Nonblocking Switching Networks." 9:00 - 12:00 Tutorial 2: Management Platforms: Operability, Portability, Interoperability Joseph Ghetie, Bellcore ABSTRACT The tutorial provides a basis for analysis of technical capabilities of distributed management platforms in offering operability services as required by the users/operators, portability of management applications running on top of these management platforms, and interoperability between similar/dissimilar management platforms. The objective of this analysis is to determine the extent to which management platforms provide flexible, scalable, integrated, enterprise-wide management, including management of broadband networks. The purpose of this tutorial is to provide useful and timely analysis information to technical and managerial staff (planners, designers, developers, procurers, and users) seeking selection of management platforms and selection of management applications associated with management platforms. 14:00 - 17:00 Tutorial 3: Agent Platforms Analysis and Evaluation Joseph Ghetie, Bellcore ABSTRACT This tutorial presentation is focused on agent platforms design, functions, interfaces, development, and implementations in order to manage enterprise- wide networks, including broadband networks. Six major conceptual and implementation agent paradigms are analyzed: SNMP/RMON Agent, OSI CMIP/TMN Agent, DMTF DMI Agent, RPC-based Agents, CORBA distributed object environment, and WEB-based management. Agent development environments and toolkits used in agent applications development are also presented. Evaluation criteria for agent platforms are presented along with the analysis of several available agent development tools. The purpose of this tutorial is to provide useful and timely analysis information to technical and managerial staff (planners, designers, developers, procurers, and users) seeking selection of management and agent platforms and selection of agent applications development tools. 18:30 - 20:00 Welcome Reception Day Two - Wednesday, December 3, 1997. ====================================== 8:00 - 9:00 Registration 9:00 - 9:10 Workshop Opening 9:10 - 9:20 Guest Speech 9:20 - 9:50 Keynote Speech - "A Future of Diversity: Multimedia Communications and Applications in the Broadband Internet" Dr. Stephen B. Weinstein, NEC C&C Laboratories, USA. President of IEEE Communications Society. ABSTRACT The 1980s' dream of universal B-ISDN service for residential subscribers, delivered through optical fibers at rates of 155Mbps and above, has given way to a more diverse and less expensive universe of wideband and broadband access systems. These systems, oriented more toward Internet access than traditional network services, come in a variety of physical architectures and communication protocols. The task of edge switches and multiplexers will be to support this diversity, including utilizing overlay networks within the same communication session. A particular objective is to invoke high quality of service connections from within best- effort Internet applications. Beginning from consideration of the B-ISDN model, I introduce the more diverse broadband vision that has been inspired by the innovations of the Internet. I describe how overlay switching and distributed object system middleware supports future multimedia applications, illustrated with applications that I believe will become popular with a large public in the not-too-distant future. 9:50 - 10:30 Invited Presentation - "Research Perspectives in High-Speed Networks: Gigabit ATM, Wireless ATM and Gigabit Ethernet" Dr. Kai Eng, Bell Labs., USA 10:30 - 10:45 Tea & Coffee 10:45 - 12:15 Technical Session 1: ATM and IP (4 papers) [1] ATM Switching and IP Routing Integration: The Next Stage in Internet Evolution Paul Patrick White University College London, UK. [2] Improving the Fairness of TCP over ATM WAN with the Age Priority Packet Discarding Scheme Hong-Bin Chiou* and Zsehong Tsai** * Chunghwa Telecommunication Co., Ltd., Taiwan, ROC. ** National Taiwan University, Taiwan, ROC. [3] Interworking between IFMP Switching and B-ISDN Access Protocols L. Cipriani*, D. Di Giorgio**, M. Pugliese**, and S. Salsano*** * Ericsson Telecomunicazioni S.p.A., Italy. ** CoRiTel, Italy. *** Universita "La Sapienza" di Roma, Italy. [4] Early Packet Discard with Diverse Management Policies for EOM Cells Maurizio Casoni University of Bologna, Italy. 12:30 - 13:45 Luncheon Invited Speech - "R&D Status on Broadband ATM Switching Systems in Taiwan" Dr. Jin Tuu Wang, Telecommunication Laboratories, Chunghwa Telecom Co., Ltd., ROC. 14:00 - 15:30 Technical Session 2: ATM Switch Architecture (4 papers) [1] Tandem-crosspoint ATM Switch Architecture and Its Cost- effective Expansion Eiji Oki, Naoaki Yamanaka, and Seisho Yasukawa NTT, Japan. [2] A Bus-based Modular Approach to Designing A Large Scale ATM Switch Young-Keun Lee and Young-Keun Park Yonsei University, Korea. [3] Flexible ATM Switching Architecture for Multimedia Communications Zenichi Yashiro, Toshiro Tanaka, and Yukihiro Doi NTT, Japan. [4] ATM Switching System Architecture for ATM Trunking Using AAL1 Sung-Jae Lee, Tae-Joon Park, and Jung-Sik Kim ETRI, Korea. 15:30 - 15:45 Tea & Coffee 15:45 - 17:15 Technical Session 3: Switch Performance (4 papers) [1] Technical Issues and Standardization on ATM Network Performance and Quality of Services Terufumi Shinomiya*, Hideyo Murakami*, and Kouichi Asatani** * NTT, Japan. ** Kogakuin University, Japan. [2] Performance Modelling of Multistage ATM Switches with Backpressure Control Schemes Simon Fong and Samar Singh La Trobe University, Australia. [3] Performance Simulation of A Multicast Input-Indexed Switch Felixberto S. Cruz and Peter A. Ivey University of Sheffield, UK. [4] A Hybrid ATM VBR/ABR Service for Scalable MPEG2 Video Networking: A Simulation -based Analysis Ahmed Mehaoua Computer Science Research Institute of Montreal, Canada. 18:30 - 20:30 Banquet Banquet Speech - "The Internet Revolution: Reshaping Business for the 21st Century" Prof. Maurizio Decina, Politecnico di Milano/CEFRIEL, Italy Past President of IEEE Communications Society ABSTRACT The age of digital convergence cannot be ignored by technology, service, and content provision companies, given the phenomenal growth of the Internet and its enormous potential in delivering services. While the interactive television and video on demand early pilot trials have not succeeded on the market, the unpredicted explosive development of the Internet and the World Wide Web have clearly demonstrated that Internet is the medium where the commercial and end users interests' converge. The fundamental limitation in the existing Internet model is the lack of network bandwidth for delivering synchronous media such as video and audio with the needed Quality of Service performance, which is fundamental for applications in the consumer and the business markets. The next generation of Internet will offer a new network architecture suitable for the provision of broadband multimedia services and applications, thus expanding the end users' WWW experience from the technological, content, and service provision point of view. The purpose of the speech is to offer an entertaining overview of the latest development in building an Integrated Services Internet Architecture, as well as of the current efforts of the Telecommunications community to develop broadband networks based on ATM (Asynchronous Transfer Mode) standards. Day Three - Thursday, December 4, 1997. ======================================= 9:00 - 10:30 Technical Session 4A: Photonic Switching-Related Topic (2 papers) [1] 640Gb/s Ultra-High-Speed Optical Interconnection System Using Wide-Channel-Spacing Wavelength Division Multiplexing Seisho Yasukawa and Naoaki Yamanaka NTT, Japan. [2] Architecture of 2-to-1 COD Multiplexers for Asynchronous Packet Arrivals Jung-Tsung Tsai ITRI, Taiwan, ROC. Technical Session 4B: Wireless ATM (2 papers) [1] Mobile ATM: Architecture, Protocols and Implementation Arup Acharya, Jun Li, and D. Raychaudhuri NEC C&C Research Laboratories, USA. [2] Wireless ATM LAN with and without Infrastructure Y. Du, C. Herrmann, and P. May Philips Research Laboratories, Germany. 10:30 - 10:45 Tea & Coffee 10:45 - 12:15 Technical Session 5: Flow Control and Scheduling (4 papers) [1] A Prediction Algorithm for Feedback Control Models with Long Delays B. Jang, B.G. Kim and G. Pecelli University of Mass. Lowell, USA. [2] Flow Control in A High-Speed Bus-Based ATM Switching Hub Song Chong*, Ramesh Nagarajan**, and Y.T. Wang** * Sogang University, Korea. ** Bell Laboratories, Lucent Technologies, USA. [3] An Efficient Scheduling Algorithm to Input-queueing ATM Switch Bin Li, Mounir Hamdi, and Xi-Ren Cao The Hong Kong University of Science and Technology, Hong Kong, China. [4] A RAM-Based Generic Packet Switch with Scheduling Capability Massoud R. Hashemi and Alberto Leon-Garcia University of Toronto, Canada. 12:30 - 13:45 Luncheon Invited Speech - "Switching Bits in the Years Ahead" Prof. Hussein Mouftah, Queen's University, Canada Editor-in-Chief of IEEE Communications Magazine 14:00 - 15:30 Technical Session 6: Switching Service and Operation- Related Topic (4 papers) [1] Efficient Multicast Copy Network M. Alimuddin, H. M. Alnuweiri, and R. W. Donaldson University of British Columbia, Canada. [2] Priority Control Mechanism by Cell Service Ratio in ATM Switch Won Gi Park and Yoon Yu Lee ETRI, Korea. [3] Minimal Overhead Fault Masking Scheme for Broadband Multi- Channel Switching Peter Y. Yan and Paul S. Min Washington University, USA. [4] Implementation of ATM OAM Functions for the Integrated Service Access Network Sang-Ho Lee ETRI, Korea. 15:30 - 15:45 Tea & Coffee 15:45 - 17:15 Panel Discussion - "The Future of Broadband Switching Systems" 17:15 - 17:25 Workshop Closing WORKSHOP LOCATION ================= The workshop location is The Ritz Taipei Hotel, a member of The Leading Hotels of the World. As you might know, The Ritz is the best business hotel in Taipei. We have negotiated with them and obtained an excellent package for our BSS'97 participants. Its address is 41, Min Chuan East Road, Section 2, Taipei, Taiwan, R.O.C. For more information about our BSS'97 hotel reservation, please contact Ms. Stephanie Wang, tel: +886 2 5985588, fax: +886 2 5863557, and e-mail: ritz@theritz-taipei.com http://www.theritz-taipei.com From rem-conf Sun Oct 19 14:09:38 1997 From rem-conf-request@es.net Sun Oct 19 14:09:37 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xN2YP-0005vl-00; Sun, 19 Oct 1997 14:06:29 -0700 Date: Sun, 19 Oct 1997 17:06:25 -0400 (EDT) From: Jeff Pulver To: rem-conf@es.net Subject: Call for Speakers (and Subjects) for Spring '98 Voice on the Net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi There, If you are interested in speaking at Spring '98 Voice on the Net (http://pulver.com/von98) - which takes place March 30 - April 2, 1998 at the Fairmont Hotel in San Jose please submit your speaking proposal to me by November 14, 1997. At the conference we will be covering a broad array of issues and technologies effecting the VON/VoIP industry. Some of the topics which are under consideration include: specific VoIP standards and protocols; quality of service issues; IN/SS7 issues; SIP vs. H.323; H.323 2.0; H.323 Gatekeeper; NextGen Codecs; NextGen Gateways; The future of Multicast; directory services; Voice over Cable; feedback >from Carriers/Enterprises who have implemented VoIP gateways (both voice and fax); ubiquitious VoIP Gateways; Billing/accounting/settlement for VoIP technologies; Etherphones; enterprise use of VoIP / Video technologies; NextGen Telcos; IP Video; IP based PBX and ACDs; VoIP Solutions for ISPs; Last Mile Technologies; Voice enabled Web applications; TAPI 3.0; The UnPBX; Internet Call Centers; VPIM; Multipoint Audio Conferencing; Domestic and International Regulatory issues. Please keep in mind that these sessions are meant to be educational and blatant product pitches will not be tolerated. However, at the Spring conference I am introducing a specific "Infomercial" track and speaking slots in this track will be sold to those companies interested in giving product pitches. And just as important - rather than submitting a speaking proposal - if there is a specific topic you would like to see covered, or a specific person speak at the conference please feel free to suggest it. In your proposal please include the title of the session, a one paragraph abstract together with the proposed names of other panelists / discusssants. Best Regards, --------------------------------------------------------------------------- Jeff Pulver Tel. 516.487.1424 Publisher Fax. 516.487.7269 The Pulver Report http://pulver.com Workshop: How an ISP can become a Telco http://pulver.com/isp98 Conference: Spring '98 Voice on the Net http://pulver.com/von98 From rem-conf Mon Oct 20 12:55:27 1997 From rem-conf-request@es.net Mon Oct 20 12:55:27 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNNfa-0004ZI-00; Mon, 20 Oct 1997 12:39:18 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 20 Oct 1997 12:39:12 -0700 (PDT) Message-Id: <199710201939.MAA13233@hille.msri.org> To: rem-conf@es.net From: Reply-to: laurent@ncsa.uiuc.edu Subject: October 27-31, 1997 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: October 27-31, 1997 Date: Oct 28, 1997 Time: 09:00 GMT-6 8 hours Contact: laurent@ncsa.uiuc.edu URL: http://www.excelgov.org/wm97/mbone/MBonewelcome.html Description: FedWeb'97 IS HERE! October 27-31, 1997 The World Wide Web Federal Consortium is sponsoring its annual Web workshop designed specifically for federal employees. This year's focus theme is "collaboration", working together to build a web-based government that works. In response to suggestions made by last year's workshop participants, FedWeb has been expanded, and the '97 workshop will run for five days. It will be held during the last week of October and has been extended by adding two extra days - including one whole day just for tutorials! During the Workshop, we will be multicasting from the Natcher Center, there will only be one session including Audio, Video and White Board. We will be transmitting from 9:00 am to 5:00 pm on Oct. Agenda available at http://www.excelgov.org/wm97/mbone/mboneschedule.html Laurent FEUILLET (laurent@ncsa.uiuc.edu) National Center for Supercomputing and Applications (NCSA) University of Illinois, Urbana-Ch! ! ampaign (217)-244-6628 International WWW Conferences mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Oct 20 13:30:46 1997 From rem-conf-request@es.net Mon Oct 20 13:30:45 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNOPa-0005L7-00; Mon, 20 Oct 1997 13:26:50 -0700 Date: Mon, 20 Oct 1997 13:24:56 -0700 (PDT) From: Karl Auerbach Reply-To: karl@precept.com To: "Anders Klemets (VXtreme)" cc: "'Rob Lanphier'" , ASF List , rem-conf@es.net Subject: RE: RTP payload format for ASF streams In-Reply-To: Message-ID: X-X-Sender: karl@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, 10 Oct 1997, Anders Klemets (VXtreme) wrote: > On Friday, October 10, 1997 12:00 PM, Rob Lanphier [SMTP:robla@real.com] > wrote: > > I'm confused. ASF is a codec-independent file-format. Payload types > are > > typically assigned to codecs. Why is there a need for a payload > format for > > ASF in RTP? > The idea is that would you use the payload format when there is no other > suitable RTP payload format defined defined for your codec. (This is > also mentioned in the Abstract, BTW.) > > This payload format can also be used as a generic payload format. > Suppose you have a video server that has access to thousands of ASF > files. The files may contain media from a large number of different > codecs. You would have to change your server, to add an implementation > of an RTP payload type handler, for each new codec that appears in an > ASF file. That is clearly not acceptable in many situations. This > payload specification solves that problem by defining a generiec ASF > payload type, that can be used as the payload type for any codec that > appears in the ASF file. This seems to me to be a very bad idea. If ASF were simply an RTP payload type one would have to do the double step of first decoding the ASF RTP payload and then decoding the ASF structure in order to determine the true encoding. This is not only wasteful, but can be bad for the network -- the reason is this: When sending media streams it is very good if the sender can find useful points in the encodings such that a lost packet causes minimal damaged to the content when rendered. This is often rather difficult to do with known codecs/encodings. But when blindly wrapped in ASF, this ability is lost. As an aside, your proposal will probably not please those folks who are concerned about the cost of additional bytes in data streams over dial-up and low bitrate pathways. Those ASF wrapper bytes, besides being redundant to the RTP information, will substantially reduce the effective media bandwidth that one can squeeze over a slow link. On a non technical point, I had heard many times that ASF was merely a file format for local storage. This seems like the nose of an ASF camel poking under the networking tent. --karl-- From rem-conf Mon Oct 20 19:48:45 1997 From rem-conf-request@es.net Mon Oct 20 19:48:44 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNUG0-0000GR-00; Mon, 20 Oct 1997 19:41:20 -0700 Message-ID: From: "Anders Klemets (VXtreme)" To: "'rem-conf@es.net'" Subject: RE: RTP payload format for ASF streams Date: Mon, 20 Oct 1997 19:40:58 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Monday, October 20, 1997 1:25 PM, Karl Auerbach [SMTP:karl@PRECEPT.COM] wrote: > > This payload format can also be used as a generic payload format. > > Suppose you have a video server that has access to thousands of ASF > > files. The files may contain media from a large number of different > > codecs. You would have to change your server, to add an implementation > > of an RTP payload type handler, for each new codec that appears in an > > ASF file. That is clearly not acceptable in many situations. This > > payload specification solves that problem by defining a generiec ASF > > payload type, that can be used as the payload type for any codec that > > appears in the ASF file. > > This seems to me to be a very bad idea. Bad idea or not, without a solution like this, it would be even worse. You would not be able to stream a new media type without first implementing the corresponding RTP payload type handler for your server. And if no RTP payload type is specified for your media type, you would be stuck. You simply would not be able to stream your data. The good folks at Apple also realized that this was a problem, so they published an RTP payload type definition for QuickTime. The ASF payload type definition is very similar to the QuickTime one in concept. > If ASF were simply an RTP payload type one would have to do the double > step of first decoding the ASF RTP payload and then decoding the ASF > structure in order to determine the true encoding. If one reads the document, one may notice that the minimal ASF Payload Header is very "light weight" in nature. If the ASF file contains Data Units of a size suitable for network transmission, then it should be possible to use the minimal ASF Payload Header. Otherwise, one may want to fragment the Data Units across multiple RTP packets, or group them together. But one would probably want to do that regardless of which payload format is being used. The ASF Payload Header introduces some additional overhead when one is doing fragmentation or grouping, but again, this is not anything that is unique to this payload format. > This is not only wasteful, but can be bad for the network -- the reason is > this: When sending media streams it is very good if the sender can > find useful points in the encodings such that a lost packet causes minimal > damaged to the content when rendered. This is often rather difficult to > do with known codecs/encodings. But when blindly wrapped in ASF, this > ability is lost. It is true that if you have an RTP payload format that is tailored for a particular codec, you have the possibility of doing special things that work only for that particular codec. I don't think anyone is disputing that. So if you have a codec-specific RTP payload implementation, you might want to keep using it. ASF does not specify a particular layout for ASF streams. However, there are certain simple things that one can do, in order to minimize the impact of packet loss. For instance, if one is creating an ASF stream containing video, one may want to store only an integer number of video frames in each ASF Data Unit. And although ASF allows Data Units to be huge, it should come as no surprise that a 4 GB Data Unit might be a less than ideal size for some network transmission schemes. > As an aside, your proposal will probably not please those folks who are > concerned about the cost of additional bytes in data streams over dial-up > and low bitrate pathways. Those ASF wrapper bytes, besides being > redundant to the RTP information, will substantially reduce the effective > media bandwidth that one can squeeze over a slow link. I am one of those concerned folks that you talk about. The overhead imposed by RTP, UDP and IP is a total of 40 bytes. The ASF RTP payload type adds another 4 bytes in the typical case. Not a big deal, in my opinion. As you know, there are proposals for how to compress the RTP/UDP/IP headers. Such compression schemes could be extended to also include well-known RTP payload type headers. > On a non technical point, I had heard many times that ASF was merely a > file format for local storage. This seems like the nose of an ASF camel > poking under the networking tent. > > --karl-- ASF is still just a file format. The ASF specification does not dictate how one should transmit data from an ASF file across a network. This payload format is just one of many possible ways to do the transmission using RTP. Anders From rem-conf Tue Oct 21 00:23:16 1997 From rem-conf-request@es.net Tue Oct 21 00:23:15 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNYaY-0001pc-00; Tue, 21 Oct 1997 00:18:50 -0700 Message-Id: <3.0.3.32.19971021001837.011cd1c4@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Oct 1997 00:18:37 -0700 To: "Anders Klemets (VXtreme)" , "'rem-conf@es.net'" , ASF@LISTSERV.MSN.COM From: Rob Lanphier Subject: RE: RTP payload format for ASF streams 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 07:40 PM 10/20/97 -0700, Anders Klemets (VXtreme) wrote: >Bad idea or not, without a solution like [a payload type for RTP], it would be even worse. >You would not be able to stream a new media type without first >implementing the corresponding RTP payload type handler for your server. >And if no RTP payload type is specified for your media type, you would >be stuck. You simply would not be able to stream your data. Adding more goo to put on the wire does not make things simpler. I fail to see how having both an RTP type mechanism and an ASF subtype mechanism makes things simpler than a single RTP type mechanism. What is wrong with placing the RTP type as a well-known property in the ASF file? No extra server code necessary, just look for the RTP type. >The good folks at Apple also realized that this was a problem, so they >published an RTP payload type definition for QuickTime. The ASF payload >type definition is very similar to the QuickTime one in concept. ...except of course that Apple was trying to reconcile the fact that Quicktime is more than just a file format, and includes a set of datatypes. They were defining the payload types for the datatypes by defining an umbrella datatype under which their subtypes were defined. I personally don't agree with that approach either, and discussed that with them recently. I'll let them speak to their approach. Regardless, ASF does not have any datatypes, and defines a datatype-neutral way of storing media, so this shouldn't be a problem. 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 From rem-conf Tue Oct 21 00:45:20 1997 From rem-conf-request@es.net Tue Oct 21 00:45:19 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNYyu-0002Mq-00; Tue, 21 Oct 1997 00:44:00 -0700 Message-ID: <344C5BB4.2B04D2E7@KEGO.COM> Date: Tue, 21 Oct 1997 00:37:24 -0700 From: Cameron Elliott Organization: KEGO - Software & Datacommunications X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 Newsgroups: comp.dcom.videoconf To: rem-conf@es.net Subject: IMTC or Telecon in California 11/97 ?? Content-Type: multipart/mixed; boundary="------------22E87F92989D96BC803F8DFD" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------22E87F92989D96BC803F8DFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Help! I'm a software developer who is working on H.323 software. I am developing a multiplatform H.323 client. (I wrote my own ASN.1 PER and Q.931, H.245, and H.225 stacks) (I can currently make simple calls to NetMeeting and Intel Internet phone) Anyway, I need to find out whats going on in the industry, and maybe find a consulting client. Could someone who is familiar with both conferences please characterise each. Where is the best place to meet potential buyers of H.323 technology? Thanks for your help. -Cameron Elliott ------------------ Kego - Software & Datacommuncations Unix, Embedded Software, TCP/IP, H.323 888-FOR-KEGO Cam@Kego.com --------------22E87F92989D96BC803F8DFD 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 --------------22E87F92989D96BC803F8DFD-- From rem-conf Tue Oct 21 01:54:26 1997 From rem-conf-request@es.net Tue Oct 21 01:54:25 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNZyk-00039K-00; Tue, 21 Oct 1997 01:47:54 -0700 Message-ID: <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.microsoft.com> From: Arlie Davis To: 'Rob Lanphier' Cc: "'rem-conf@es.net'" Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 01:47:11 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: Rob Lanphier [SMTP:robla@real.com] > Sent: Tuesday, October 21, 1997 12:19 AM > To: Anders Klemets (VXtreme); 'rem-conf@es.net'; > ASF@LISTSERV.MSN.COM > Subject: RE: RTP payload format for ASF streams > > Adding more goo to put on the wire does not make things simpler. I > fail to > see how having both an RTP type mechanism and an ASF subtype mechanism > makes things simpler than a single RTP type mechanism. > I agree that adding more layers to the protocol stack is Bad. However, ASF-on-RTP is required because the RTP payload type system is woefully inadequate. It describes a few static types, with precious little extensibility. ASF allows much more in the way of an extensible payload description. The support for dynamic payload types in RTP is extremely weak, mostly because it relies on using out-of-band communication to describe the true payload format. I speak only for myself, not my company. -- arlie From rem-conf Tue Oct 21 06:41:20 1997 From rem-conf-request@es.net Tue Oct 21 06:41:19 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNeP1-0004uc-00; Tue, 21 Oct 1997 06:31:19 -0700 Sender: hgs@cs.columbia.edu Message-ID: <344CAE96.65D7@cs.columbia.edu> Date: Tue, 21 Oct 1997 09:31:02 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Arlie Davis , Eric Fleischman CC: "'Rob Lanphier'" , rem-conf@es.net Subject: Re: RTP payload format for ASF streams References: <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Arlie Davis wrote: > > > -----Original Message----- > > From: Rob Lanphier [SMTP:robla@real.com] > > Sent: Tuesday, October 21, 1997 12:19 AM > > To: Anders Klemets (VXtreme); 'rem-conf@es.net'; > > ASF@LISTSERV.MSN.COM > > Subject: RE: RTP payload format for ASF streams > > > > Adding more goo to put on the wire does not make things simpler. I > > fail to > > see how having both an RTP type mechanism and an ASF subtype mechanism > > makes things simpler than a single RTP type mechanism. > > > I agree that adding more layers to the protocol stack is Bad. However, > ASF-on-RTP is required because the RTP payload type system is woefully > inadequate. It describes a few static types, with precious little > extensibility. ASF allows much more in the way of an extensible payload > description. The support for dynamic payload types in RTP is extremely > weak, mostly because it relies on using out-of-band communication to > describe the true payload format. Carrying GUIDs in each RTP packet isn't exactly a viable alternative. Thus, we had to choose an out-of-band mechanism. This, if you want, is not really different from ASF having a header at the beginning of the file that maps a full "payload description" to a smaller "payload type", except that ASFv2 blends the notions of stream (single source, timeline) and payload type. If you have a proposal for avoiding out-of-band carriage of media encoding-to-PT description, please elaborate. There had been discussions about periodic distribution of such information in RTCP, but this tends to duplicate information that you need on a separate multicast announcement group or statically (on a web page) in any event. Given that we need (in the absence of such a proposal) an out-of-band mechanism, you only need enough payload types to cover the likely number of different media types within a single session. > -- arlie -- 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 From rem-conf Tue Oct 21 08:48:49 1997 From rem-conf-request@es.net Tue Oct 21 08:48:48 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNgQl-0006E6-00; Tue, 21 Oct 1997 08:41:15 -0700 Date: Tue, 21 Oct 1997 08:40:11 -0700 (PDT) From: Karl Auerbach X-Sender: karl@big-bear Reply-To: karl@precept.com To: rem-conf@es.net Subject: RE: RTP payload format for ASF streams In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With regard for the purported "need" to define a special ASF payload for RTP: It isn't necessary. At Precept we have defined an "unstructured" dynamic RTP payload type. We use it to ship media streams that we don't understand. We could even ship ASF files over it, today, without any predefined ASF RTP payload type. So, to my mind, adding a special ASF payload type is an exercise in the redundant. And, adding inefficiency to redundancy, the added burden of 4 bytes of ASF header largely vitiates the gain from proposed header compression methods on low speed links. It is best, by far, to leave ASF as a purely local file format. It's idiosyncrasies should not be propogated onto the network. --karl-- From rem-conf Tue Oct 21 09:24:52 1997 From rem-conf-request@es.net Tue Oct 21 09:24:51 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNh4E-0006us-00; Tue, 21 Oct 1997 09:22:02 -0700 Message-Id: <199710211621.JAA01560@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Arlie Davis cc: "'Rob Lanphier'" , "'rem-conf@es.net'" Subject: Re: RTP payload format for ASF streams In-reply-to: Your message of "Tue, 21 Oct 1997 01:47:11 PDT." <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 09:21:47 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > > > -----Original Message----- > > From: Rob Lanphier [SMTP:robla@real.com] > > Sent: Tuesday, October 21, 1997 12:19 AM > > To: Anders Klemets (VXtreme); 'rem-conf@es.net'; > > ASF@LISTSERV.MSN.COM > > Subject: RE: RTP payload format for ASF streams > > > > Adding more goo to put on the wire does not make things simpler. I > > fail to > > see how having both an RTP type mechanism and an ASF subtype mechanism > > makes things simpler than a single RTP type mechanism. > > > I agree that adding more layers to the protocol stack is Bad. However, > ASF-on-RTP is required because the RTP payload type system is woefully > inadequate. It describes a few static types, with precious little > extensibility. ASF allows much more in the way of an extensible payload > description. The support for dynamic payload types in RTP is extremely > weak, mostly because it relies on using out-of-band communication to > describe the true payload format. > > I speak only for myself, not my company. > Well, that has been one of the weakness in rtp for a long time and nothing was done about it. The alternative is to keep adding layers such as the RTP-ASF mechanism. "I can't envison more than 1/2 dozen codecs or so " 8) Cheers, Amancio From rem-conf Tue Oct 21 09:39:51 1997 From rem-conf-request@es.net Tue Oct 21 09:39:50 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNhJA-0007Ir-00; Tue, 21 Oct 1997 09:37:28 -0700 Message-Id: <199710211637.JAA01701@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: karl@precept.com cc: rem-conf@es.net Subject: Re: RTP payload format for ASF streams In-reply-to: Your message of "Tue, 21 Oct 1997 08:40:11 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 09:37:07 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can you elaborate on ""unstructured dynamic payload type" ? Tnks, Amancio From rem-conf Tue Oct 21 10:31:16 1997 From rem-conf-request@es.net Tue Oct 21 10:31:15 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNi6J-0000Ln-00; Tue, 21 Oct 1997 10:28:15 -0700 Message-ID: From: Eric Fleischman To: 'Henning Schulzrinne' , Arlie Davis Cc: 'Rob Lanphier' , rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 09:59:04 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I find myself in the peculiar situation of agreeing with both proponents who apparently disagree with each other. On the one hand, I believe that Henning is clearly correct in pointing out that encoding information is best done out-of-band. In fact, every networked multimedia product with which I am familiar follows this approach. Thus, I strongly suspect that this isn't what Arlie Davis was arguing. Rather, the view from my knothole (a view which perhaps Arlie would agree with?) is that RTP resulted from extensive experimentation of carrying A/V content over the Internet. After years of experience, the innovative (and remarkable) findings of these experiments were described in RFCs 1889 and 1890. While the (MBONE) community uses RTP to convey media types other than audio and video, the community is nevertheless oriented to these two media. One might accurately say that the RTP protocol is oriented to the demands of these two media types. A previous thread within AVT described some problems with payload types. Specifically, it was generally agreed that a trend towards increasingly using dynamic RTP payload types will need to occur simply because the codecs used for static payload type values tend to become obsolete over time. Another reason is that alternative media types will increasingly be conveyed via RTP and there are simply not enough reserved payload type values to statically account for all of these alternatives. These alternative media types introduce problems which RTP did not address. For example, the frame sizes of audio and video are such that one should normally expect to convey their frames within a single RTP packet. This is not the case for some other media types. Image data and many text data types (e.g., HTML), for example, will frequently not fit into an Internet-sized (576 byte long) -- or even an Ethernet-sized -- packet. Thus, these classes of media types will need to have a method to indicate fragmentation of their objects and RTP does not directly support fragmentation. I believe that experienced RTP proponents would argue that such fragmentation is properly done in the extension field of the RTP header. Simultaneously, Microsoft has been experimenting with introducing a distinction between send time (the time in which a server sends a packet) and presentation time (the time in which a client renders the multimedia data). This distinction permits the development of multimedia tools which can "data rate level" multimedia presentations by purposefully sending data, which would otherwise exceed a certain bandwidth threshold, earlier than expected during periods which otherwise would have had diminished data rates. This approach has been demonstrated to be quite successful for supporting bandwidth constrained environments such as modem connections. If one wishes to be able to retain the ability to record this type of data at the client, one needs to be able to send both send times and presentation times to the client for it to record. Please note that this concept is not media dependent. One could, of course, require that it also be carried within RTP's extension field, pretending that it is somehow payload related. It isn't, of course. Thus, I expect some experienced RTP proponents to doubt the need for data levelling. Which brings about a second observation: RTP is oriented to Real Time uses -- as one would expect by the protocol's name. However, data rate levelling is primarily an "on demand issue" (i.e., an issue for multimedia presentations which have been edited "off line" rather than done real-time; Please note the word "primarily" for Microsoft's implementations occur both for on-demand and real-time uses, and real time also must be concerned somewhat with this issue) and hence the traditional community is not likely to resonate with it (or else say that it should be handled elsewhere, perhaps with RSVP). Thus, I believe that problems are arising as RTP is increasingly used for domains which weren't envisioned when the protocol was created. This is why I agree with Arlie's claims that RTP (as it is currently defined) is inadequately extensible to support these innovative new uses. I also agree with him that it is the limitations of the Payload Type which are causing the problems. Therefore, I interpret Anders Klemet's internet-draft document as providing a mechanism to make RTP's payload type system extensible. Please follow my logic to see how I arrived at this conclusion: * RTP is oriented to static RTP payload types -- an orientation that will increasingly become obsolete over time. * RTP extensions were created "to allow individual implementations to experiment with new payload-format-independent functions" (see first paragraph of RTP 1889 section 5.3.1) -- though the standard also discourages their use. Instead it encourages "additional information required for a particular payload format should not use this header extension, but should be carried in the payload section of this packet" (2nd paragraph of section 5.3.1). Ander's internet-draft proposes a mechanism consistent with this directive. * The RTP community needs to use dynamic RTP payload types to support new media types, and, increasingly, all payload types. * Dynamic payload types are entirely defined by out-of-band techniques (i.e., they lack all semantics built into Static Payload Types). Since this is so, RTP's whole payload orientation breaks down since what a dynamic payload type means is unknown to RTP and thus payload-specific semantics becomes undesirable and tenuous, especially for implementations of large number of different dynamic payloads (i.e., it is much easier for implementations to handle a large number of different dynamic payloads by treating them in a consistent, payload-independent fashion). * Communities arise which desire to support new concepts via RTP which transcend media types. * Anders Klemet's internet-draft proposes an efficient way to satisfy these diverse needs and thus extend RTP to be used within environments for which it was not originally designed. > -----Original Message----- > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > Sent: Tuesday, October 21, 1997 6:31 AM > To: Arlie Davis; Eric Fleischman > Cc: 'Rob Lanphier'; rem-conf@es.net > Subject: Re: RTP payload format for ASF streams > > Arlie Davis wrote: > > > > > -----Original Message----- > > > From: Rob Lanphier [SMTP:robla@real.com] > > > Sent: Tuesday, October 21, 1997 12:19 AM > > > To: Anders Klemets (VXtreme); 'rem-conf@es.net'; > > > ASF@LISTSERV.MSN.COM > > > Subject: RE: RTP payload format for ASF streams > > > > > > Adding more goo to put on the wire does not make things simpler. > I > > > fail to > > > see how having both an RTP type mechanism and an ASF subtype > mechanism > > > makes things simpler than a single RTP type mechanism. > > > > > I agree that adding more layers to the protocol stack is Bad. > However, > > ASF-on-RTP is required because the RTP payload type system is > woefully > > inadequate. It describes a few static types, with precious little > > extensibility. ASF allows much more in the way of an extensible > payload > > description. The support for dynamic payload types in RTP is > extremely > > weak, mostly because it relies on using out-of-band communication to > > describe the true payload format. > > Carrying GUIDs in each RTP packet isn't exactly a viable alternative. > Thus, we had to choose an out-of-band mechanism. This, if you want, is > not really different from ASF having a header at the beginning of the > file that maps a full "payload description" to a smaller "payload > type", > except that ASFv2 blends the notions of stream (single source, > timeline) > and payload type. > > If you have a proposal for avoiding out-of-band carriage of media > encoding-to-PT description, please elaborate. There had been > discussions > about periodic distribution of such information in RTCP, but this > tends > to duplicate information that you need on a separate multicast > announcement group or statically (on a web page) in any event. > > Given that we need (in the absence of such a proposal) an out-of-band > mechanism, you only need enough payload types to cover the likely > number > of different media types within a single session. > > > -- arlie > > -- > 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 From rem-conf Tue Oct 21 10:56:30 1997 From rem-conf-request@es.net Tue Oct 21 10:56:30 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNiVQ-0000rO-00; Tue, 21 Oct 1997 10:54:12 -0700 Sender: hgs@cs.columbia.edu Message-ID: <344CEC3F.2125@cs.columbia.edu> Date: Tue, 21 Oct 1997 13:54:07 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Eric Fleischman CC: Arlie Davis , "'Rob Lanphier'" , rem-conf@es.net Subject: Re: RTP payload format for ASF streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Eric Fleischman wrote: > > A previous thread within AVT described some problems with payload types. > Specifically, it was generally agreed that a trend towards increasingly > using dynamic RTP payload types will need to occur simply because the > codecs used for static payload type values tend to become obsolete over > time. Another reason is that alternative media types will increasingly > be conveyed via RTP and there are simply not enough reserved payload > type values to statically account for all of these alternatives. Correct, but that never was the intent, as I have pointed out before. One could argue that we should only have had dynamic payload types, but this was a bootstrapping compromise to get tools out the door faster. It has been suggested that even the static assignments can be overridden by out-of-band means, so the distinction becomes meaningless. > > These alternative media types introduce problems which RTP did not > address. For example, the frame sizes of audio and video are such that > one should normally expect to convey their frames within a single RTP > packet. Not quite. MPEG, JPEG and H.26x already have this problem - and solve it in the way which is appropriate for that particular media types. These problems need to be solved for the other types that you mention. We intentionally did not include a generic fragmentation mechanism since it was believed that each "real time" type > This is not the case for some other media types. Image data and > many text data types (e.g., HTML), for example, will frequently not fit > into an Internet-sized (576 byte long) -- or even an Ethernet-sized -- > packet. Thus, these classes of media types will need to have a method to > indicate fragmentation of their objects and RTP does not directly > support fragmentation. I believe that experienced RTP proponents would > argue that such fragmentation is properly done in the extension field of > the RTP header. I have argued that, but only if the payload format does not address this directly. If you look at H.261, you'll find that you need more than just length information to make this work well. > > Simultaneously, Microsoft has been experimenting with introducing a > distinction between send time (the time in which a server sends a > packet) and presentation time (the time in which a client renders the > multimedia data). This distinction permits the development of multimedia > tools which can "data rate level" multimedia presentations by > purposefully sending data, which would otherwise exceed a certain > bandwidth threshold, earlier than expected during periods which > otherwise would have had diminished data rates. This approach has been > demonstrated to be quite successful for supporting bandwidth constrained > environments such as modem connections. If one wishes to be able to > retain the ability to record this type of data at the client, one needs > to be able to send both send times and presentation times to the client > for it to record. The recording of data for local playback does not require send time information, unless the client stream the same data back to the network. > > Please note that this concept is not media dependent. One could, of > course, require that it also be carried within RTP's extension field, > pretending that it is somehow payload related. It isn't, of course. > Thus, I expect some experienced RTP proponents to doubt the need for > data levelling. Which brings about a second observation: RTP is oriented > to Real Time uses -- as one would expect by the protocol's name. > However, data rate levelling is primarily an "on demand issue" (i.e., an > issue for multimedia presentations which have been edited "off line" > rather than done real-time; Please note the word "primarily" for > Microsoft's implementations occur both for on-demand and real-time uses, > and real time also must be concerned somewhat with this issue) and hence > the traditional community is not likely to resonate with it (or else say > that it should be handled elsewhere, perhaps with RSVP). Thus, I believe > that problems are arising as RTP is increasingly used for domains which > weren't envisioned when the protocol was created. Send times are a network sender (and file format issue). Once the data is "on the wire", it serves no useful purpose. > > This is why I agree with Arlie's claims that RTP (as it is currently > defined) is inadequately extensible to support these innovative new > uses. I also agree with him that it is the limitations of the Payload > Type which are causing the problems. Therefore, I interpret Anders > Klemet's internet-draft document as providing a mechanism to make RTP's > payload type system extensible. These are wholly separate issues. Please don't mix payload types with send times and fragmentation. > > Please follow my logic to see how I arrived at this conclusion: > * RTP is oriented to static RTP payload types -- an orientation > that will increasingly become obsolete over time. Wrong. > * RTP extensions were created "to allow individual implementations > to experiment with new payload-format-independent functions" (see first > paragraph of RTP 1889 section 5.3.1) -- though the standard also > discourages their use. Instead it encourages "additional information > required for a particular payload format should not use this header > extension, but should be carried in the payload section of this packet" > (2nd paragraph of section 5.3.1). Ander's internet-draft proposes a > mechanism consistent with this directive. But it is not "a specific payload type". It's a file type. Specific payload types have very distinct needs. An HTML file might, for example, want to break things at top-level element level, an H.261 file may need to convey GOB information for each fragment, etc. > * The RTP community needs to use dynamic RTP payload types to > support new media types, and, increasingly, all payload types. That's fully intentional. Static payload types are just a bootstrapping mechanism which should become less needed as supporting tools (such as RTSP) become more widely used. > * Dynamic payload types are entirely defined by out-of-band > techniques (i.e., they lack all semantics built into Static Payload > Types). Static payload types are no different from dynamic payload types. The only difference is that you pick up the mapping to a globally unique name (such as a GUID) from RFC 1890 instead of an SDP or other mechanism. Since this is so, RTP's whole payload orientation breaks down > since what a dynamic payload type means is unknown to RTP and thus > payload-specific semantics becomes undesirable and tenuous, especially > for implementations of large number of different dynamic payloads (i.e., > it is much easier for implementations to handle a large number of > different dynamic payloads by treating them in a consistent, > payload-independent fashion). These two things have nothing to do with each other. You are arguing that the same mechanisms (such as fragmentation) apply to (almost) all payload types. Experience with a large number of common non-audio payload types has shown that not to be the case. Again, I refer you to the different solutions needed for MPEG, JPEG, H.261 and H.263. This has nothing whatsoever to do with the fact that these payload types are static or not (or the desire to create extra work...). > * Communities arise which desire to support new concepts via RTP > which transcend media types. > * Anders Klemet's internet-draft proposes an efficient way to > satisfy these diverse needs and thus extend RTP to be used within > environments for which it was not originally designed. > > > -----Original Message----- > > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > > Sent: Tuesday, October 21, 1997 6:31 AM > > To: Arlie Davis; Eric Fleischman > > Cc: 'Rob Lanphier'; rem-conf@es.net > > Subject: Re: RTP payload format for ASF streams > > > > Arlie Davis wrote: > > > > > > > -----Original Message----- > > > > From: Rob Lanphier [SMTP:robla@real.com] > > > > Sent: Tuesday, October 21, 1997 12:19 AM > > > > To: Anders Klemets (VXtreme); 'rem-conf@es.net'; > > > > ASF@LISTSERV.MSN.COM > > > > Subject: RE: RTP payload format for ASF streams > > > > > > > > Adding more goo to put on the wire does not make things simpler. > > I > > > > fail to > > > > see how having both an RTP type mechanism and an ASF subtype > > mechanism > > > > makes things simpler than a single RTP type mechanism. > > > > > > > I agree that adding more layers to the protocol stack is Bad. > > However, > > > ASF-on-RTP is required because the RTP payload type system is > > woefully > > > inadequate. It describes a few static types, with precious little > > > extensibility. ASF allows much more in the way of an extensible > > payload > > > description. The support for dynamic payload types in RTP is > > extremely > > > weak, mostly because it relies on using out-of-band communication to > > > describe the true payload format. > > > > Carrying GUIDs in each RTP packet isn't exactly a viable alternative. > > Thus, we had to choose an out-of-band mechanism. This, if you want, is > > not really different from ASF having a header at the beginning of the > > file that maps a full "payload description" to a smaller "payload > > type", > > except that ASFv2 blends the notions of stream (single source, > > timeline) > > and payload type. > > > > If you have a proposal for avoiding out-of-band carriage of media > > encoding-to-PT description, please elaborate. There had been > > discussions > > about periodic distribution of such information in RTCP, but this > > tends > > to duplicate information that you need on a separate multicast > > announcement group or statically (on a web page) in any event. > > > > Given that we need (in the absence of such a proposal) an out-of-band > > mechanism, you only need enough payload types to cover the likely > > number > > of different media types within a single session. > > > > > -- arlie > > > > -- > > 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 -- 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 From rem-conf Tue Oct 21 11:23:42 1997 From rem-conf-request@es.net Tue Oct 21 11:23:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNiwY-0001PP-00; Tue, 21 Oct 1997 11:22:14 -0700 Message-Id: <3.0.3.32.19971021112202.00f85a64@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Oct 1997 11:22:02 -0700 To: Arlie Davis From: Rob Lanphier Subject: RE: RTP payload format for ASF streams Cc: "'rem-conf@es.net'" In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 01:47 AM 10/21/97 -0700, Arlie Davis wrote: >I agree that adding more layers to the protocol stack is Bad. However, >ASF-on-RTP is required because the RTP payload type system is woefully >inadequate. It describes a few static types, with precious little >extensibility. ASF allows much more in the way of an extensible payload >description. The support for dynamic payload types in RTP is extremely >weak, mostly because it relies on using out-of-band communication to >describe the true payload format. The out-of-band mechanism that we are using is RTSP, which is a protocol. ASF is a file format. We shouldn't use file formats to do the job of protocols. 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 From rem-conf Tue Oct 21 11:23:43 1997 From rem-conf-request@es.net Tue Oct 21 11:23:43 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNiwt-0001Pg-00; Tue, 21 Oct 1997 11:22:35 -0700 Date: Tue, 21 Oct 1997 11:20:14 -0700 (PDT) From: Karl Auerbach Reply-To: karl@precept.com To: Eric Fleischman cc: "'Henning Schulzrinne'" , Arlie Davis , "'Rob Lanphier'" , rem-conf@es.net Subject: RE: RTP payload format for ASF streams In-Reply-To: Message-ID: X-X-Sender: karl@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 > These alternative media types introduce problems which RTP did not > address. For example, the frame sizes of audio and video are such that > one should normally expect to convey their frames within a single RTP > packet. That's not an accurate statement. The RTP M-bit is used to delimit groups of RTP packets that form a higher level Application Data Unit (ADU). Here at Precept we happily move audio/video encodings in which the higher level chunks span multiple RTP packets. > many text data types (e.g., HTML), for example, will frequently not fit > into an Internet-sized (576 byte long) I haven't seen a path MTU of 576 in a long time. The Path MTU Discovery protocol is a nice tool when used in conjunction with RTP. > Simultaneously, Microsoft has been experimenting with introducing a > distinction between send time (the time in which a server sends a > packet) and presentation time (the time in which a client renders the > multimedia data). In RTP one can send data in advance. The timestamps on the various RTP streams are coordinated against a universal, worldwide reference clock of better than nanosecond resolution so that multiple streams may be played out in synchrony. In no way does this mean that the sender must hold back data that is ready to be sent. However, curtesy to the receiver dictates that such advance transmissions be kept within reason in order to prevent overunning the receiver's buffering resources. --karl-- From rem-conf Tue Oct 21 11:27:53 1997 From rem-conf-request@es.net Tue Oct 21 11:27:53 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNj1d-0001yt-00; Tue, 21 Oct 1997 11:27:29 -0700 Date: Tue, 21 Oct 1997 11:25:54 -0700 (PDT) From: Karl Auerbach Reply-To: karl@precept.com To: Amancio Hasty cc: rem-conf@es.net Subject: Re: RTP payload format for ASF streams In-Reply-To: <199710211637.JAA01701@rah.star-gate.com> Message-ID: X-X-Sender: karl@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 > Can you elaborate on ""unstructured dynamic payload type" ? Essentially we treat the stream as binary data of unknown structure, chopping it into RTP packets as appropriate for the path MTU. We assert the RTP M bit either at the start of end of significant chunks, i.e. Application Data Units (ADUs). (M bit handling depends on whether the stream is nominally audio or video or a combination.) We don't have any tag that says "this opaque content is purported to be of type xxx"; the application is expected to make heads or tails out of what it gets, so there is some a priori knowledge (in the application, not in the RTP code) about the structure of the data bits. Since the format grew somewhat organically I don't believe we have a formal payload definition document. --karl-- From rem-conf Tue Oct 21 11:33:29 1997 From rem-conf-request@es.net Tue Oct 21 11:33:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNj5M-0002Wp-00; Tue, 21 Oct 1997 11:31:20 -0700 From: Dermot Tynan Message-Id: <9710211833.AA00919@karpov.wfa.digital.ie> Subject: Re: RTP payload format for ASF streams To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Tue, 21 Oct 1997 19:33:19 +0000 (BST) Cc: ericfl@MICROSOFT.com, arlied@MICROSOFT.com, robla@real.com, rem-conf@es.net In-Reply-To: <344CEC3F.2125@cs.columbia.edu> from "Henning Schulzrinne" at Oct 21, 97 01:54:07 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1659 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne wrote: > > > For example, the frame sizes of audio and video are such that > > one should normally expect to convey their frames within a single RTP > > packet. > > Not quite. MPEG, JPEG and H.26x already have this problem - and solve it > in the way which is appropriate for that particular media types. These > problems need to be solved for the other types that you mention. Add BT.656 to that list as well. Not only is the decision on where to fragment quite specific to the media type, but also what the receiver should do in terms of fragment loss is payload-specific. If you try to hide this in an intermediate layer such as ASF, I don't think it will work. > > I believe that experienced RTP proponents would > > argue that such fragmentation is properly done in the extension field of > > the RTP header. > > I have argued that, but only if the payload format does not address this > directly. While I wouldn't consider myself an "experienced RTP proponent", if the IP layer isn't going to handle fragmentation transparently (such as IPv6), I can't imagine that you can get the RTP layer to do it transparently. Certainly not in light of things such as the IPv6 ICMP-"Packet Too Big" message. Fragmentation is a nuisance. At any layer. It seems to me that the best thing to do in the IPv6 case is pick the minimum MTU (which, thankfully, is relatively large) and run with that. Handle the packet size at the top level so that you don't have to second-guess the layers below you. - Der -- Dermot Tynan +353 91 754608 dtynan@wfa.digital.ie DTN: 822-4608 AltaVista Internet Software, Galway, Ireland From rem-conf Tue Oct 21 11:42:32 1997 From rem-conf-request@es.net Tue Oct 21 11:42:32 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNjEi-0003Vy-00; Tue, 21 Oct 1997 11:41:00 -0700 X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C046@RED-09-MSG.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 11:39:16 -0700 To: rem-conf@es.net From: Steve Deering Subject: RE: RTP payload format for ASF streams X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I appreciate the desire for more flexibility in RTP to enable the technology to evolve, but don't forget that flexibility is often the enemy of interoperability, and interoperability is the whole point of Standards. Certainly, gratuitous proliferation of payload types/encodings makes it less and less likely that two different implementations will be able talk to each other. If the small Payload Type field makes it relatively "expensive" to add new encodings, that's probably a Good Thing, >from the IETF, if not the corporate, point of view. Steve From rem-conf Tue Oct 21 12:20:01 1997 From rem-conf-request@es.net Tue Oct 21 12:20:01 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNjly-0004Un-00; Tue, 21 Oct 1997 12:15:22 -0700 Message-ID: <7D06B4AA8B39D011A64900805F682CDA02D7C048@RED-09-MSG.dns.microsoft.com> From: Arlie Davis To: 'Rob Lanphier' Cc: "'rem-conf@es.net'" Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 12:15:21 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't think RTSP is that great. It depends on the concept of a session, and it depends on bidirectional communication, which is not always possible, desireable, or scalable. The fact that RTP *could* be self-describing but is not is a true weakness. RTP was originally quite appealing precisely because you could determine everything about the stream from the stream itself. I think this is a desireable, and easily attainable, design goal. Requiring RTSP, SDP, HTTP, or whatever external means of communicating information about the stream is just an adaptive hack. -- arlie > -----Original Message----- > From: Rob Lanphier [SMTP:robla@real.com] > Sent: Tuesday, October 21, 1997 11:22 AM > To: Arlie Davis > Cc: 'rem-conf@es.net' > Subject: RE: RTP payload format for ASF streams > > At 01:47 AM 10/21/97 -0700, Arlie Davis wrote: > >I agree that adding more layers to the protocol stack is Bad. > However, > >ASF-on-RTP is required because the RTP payload type system is > woefully > >inadequate. It describes a few static types, with precious little > >extensibility. ASF allows much more in the way of an extensible > payload > >description. The support for dynamic payload types in RTP is > extremely > >weak, mostly because it relies on using out-of-band communication to > >describe the true payload format. > > The out-of-band mechanism that we are using is RTSP, which is a > protocol. > ASF is a file format. We shouldn't use file formats to do the job of > protocols. > > 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 From rem-conf Tue Oct 21 12:39:50 1997 From rem-conf-request@es.net Tue Oct 21 12:39:50 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNk6N-000519-00; Tue, 21 Oct 1997 12:36:27 -0700 Date: Tue, 21 Oct 1997 12:35:28 -0700 () From: Stephen Casner To: Arlie Davis cc: "'rem-conf@es.net'" Subject: RE: RTP payload format for ASF streams In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C048@RED-09-MSG.dns.microsoft.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 Arlie, > The fact that RTP *could* be self-describing but is not is a true > weakness. RTP was originally quite appealing precisely because you > could determine everything about the stream from the stream itself. I > think this is a desireable, and easily attainable, design goal. > Requiring RTSP, SDP, HTTP, or whatever external means of communicating > information about the stream is just an adaptive hack. Sorry, I just can't agree with that. You've got to find out about the address of the stream from somewhere, and you can just as well find out about the dynamic RTP payload type mappings from the same place, whatever it is. The only weakness in the dynamic payload type mechanism is/was the lack of implementation in several popular programs used on the MBone, therefore people have not learned about it and have not used it. We've used dynamic payload types in Precept's products from the beginning, and they work fine. -- Steve From rem-conf Tue Oct 21 12:52:20 1997 From rem-conf-request@es.net Tue Oct 21 12:52:20 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNkFR-0005Pg-00; Tue, 21 Oct 1997 12:45:49 -0700 Message-Id: <3.0.3.32.19971021124539.00fee474@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Oct 1997 12:45:39 -0700 To: Arlie Davis From: Rob Lanphier Subject: RE: RTP payload format for ASF streams Cc: "'rem-conf@es.net'" In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C048@RED-09-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are you telling me that mulitcasting file header information with every packet doesn't constitute a hack? The model used in RTSP is the one used in RealAudio and RealVideo which is proven technology and is in widespread use today, and RTSP itself has been successfully deployed in our RealMedia Developer SDK. SDP is in widespread use on the MBONE. Please tell me which systems in widespread use RTP and yet avoid the use of either RTSP or SDP. Rob At 12:15 PM 10/21/97 -0700, Arlie Davis wrote: >I don't think RTSP is that great. It depends on the concept of a >session, and it depends on bidirectional communication, which is not >always possible, desireable, or scalable. > >The fact that RTP *could* be self-describing but is not is a true >weakness. RTP was originally quite appealing precisely because you >could determine everything about the stream from the stream itself. I >think this is a desireable, and easily attainable, design goal. >Requiring RTSP, SDP, HTTP, or whatever external means of communicating >information about the stream is just an adaptive hack. > >-- arlie > >> -----Original Message----- >> From: Rob Lanphier [SMTP:robla@real.com] >> Sent: Tuesday, October 21, 1997 11:22 AM >> To: Arlie Davis >> Cc: 'rem-conf@es.net' >> Subject: RE: RTP payload format for ASF streams >> >> At 01:47 AM 10/21/97 -0700, Arlie Davis wrote: >> >I agree that adding more layers to the protocol stack is Bad. >> However, >> >ASF-on-RTP is required because the RTP payload type system is >> woefully >> >inadequate. It describes a few static types, with precious little >> >extensibility. ASF allows much more in the way of an extensible >> payload >> >description. The support for dynamic payload types in RTP is >> extremely >> >weak, mostly because it relies on using out-of-band communication to >> >describe the true payload format. >> >> The out-of-band mechanism that we are using is RTSP, which is a >> protocol. >> ASF is a file format. We shouldn't use file formats to do the job of >> protocols. >> >> 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 > > --- 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 From rem-conf Tue Oct 21 12:52:22 1997 From rem-conf-request@es.net Tue Oct 21 12:52:22 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNkIG-0005Uk-00; Tue, 21 Oct 1997 12:48:44 -0700 Message-ID: <7D06B4AA8B39D011A64900805F682CDA02D7C049@RED-09-MSG.dns.microsoft.com> From: Arlie Davis To: 'Henning Schulzrinne' , Eric Fleischman Cc: 'Rob Lanphier' , rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 12:18:59 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Almost a year ago, I proposed reserving two related static RTP payload types. One would be used for transmitting the data, one for transmitting the full description of the data; it's "type". The description could include the number of channels, the encoding, the bit rate, a GUID, whatever. The description could be transmitted often enough that a new sender would not have to wait long at all, while not frequently enough to consume a noticeable amount of bandwidth. I still think this scheme is a good one, and is especially well suited to ASF. The stream description is in-band, but does not have to be on every single packet. -- arlie > -----Original Message----- > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > Sent: Tuesday, October 21, 1997 6:31 AM > To: Arlie Davis; Eric Fleischman > Cc: 'Rob Lanphier'; rem-conf@es.net > Subject: Re: RTP payload format for ASF streams > > Carrying GUIDs in each RTP packet isn't exactly a viable alternative. > Thus, we had to choose an out-of-band mechanism. This, if you want, is > not really different from ASF having a header at the beginning of the > file that maps a full "payload description" to a smaller "payload > type", > except that ASFv2 blends the notions of stream (single source, > timeline) > and payload type. > > If you have a proposal for avoiding out-of-band carriage of media > encoding-to-PT description, please elaborate. There had been > discussions > about periodic distribution of such information in RTCP, but this > tends > to duplicate information that you need on a separate multicast > announcement group or statically (on a web page) in any event. > > Given that we need (in the absence of such a proposal) an out-of-band > mechanism, you only need enough payload types to cover the likely > number > of different media types within a single session. > > From rem-conf Tue Oct 21 12:55:42 1997 From rem-conf-request@es.net Tue Oct 21 12:55:42 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNkNZ-0005nv-00; Tue, 21 Oct 1997 12:54:13 -0700 Message-ID: <7D06B4AA8B39D011A64900805F682CDA02D7C04A@RED-09-MSG.dns.microsoft.com> From: Arlie Davis To: 'Rob Lanphier' Cc: "'rem-conf@es.net'" Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 12:54:11 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yes, I am. Did you read more than the first sentence of the post? I said that the stream description could be transmitted periodically, *not* with every packet. The period between descriptions could be small enough to have a negligible impact on bandwidth, and often enough to make joining a multicast group (and learning the stream description) relatively quick. Also, transmitting the stream description in-band and communicating it out-of-band are not mutually exclusive. Keeping the description of a stream as close as (reasonably) possible to the stream itself just makes sense. I never asserted that there *was* a system in use right now that avoids using RTSP, SDP, or payload mappings scribbled on bathroom walls, unless you count the early days of using VAT and NV, when people just passed around multicast groups and ports in e-mail. -- arlie > -----Original Message----- > From: Rob Lanphier [SMTP:robla@real.com] > Sent: Tuesday, October 21, 1997 12:46 PM > To: Arlie Davis > Cc: 'rem-conf@es.net' > Subject: RE: RTP payload format for ASF streams > > Are you telling me that mulitcasting file header information with > every > packet doesn't constitute a hack? > > The model used in RTSP is the one used in RealAudio and RealVideo > which is > proven technology and is in widespread use today, and RTSP itself has > been > successfully deployed in our RealMedia Developer SDK. SDP is in > widespread > use on the MBONE. Please tell me which systems in widespread use RTP > and > yet avoid the use of either RTSP or SDP. > > Rob > From rem-conf Tue Oct 21 13:10:41 1997 From rem-conf-request@es.net Tue Oct 21 13:10:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNkbe-0006op-00; Tue, 21 Oct 1997 13:08:46 -0700 Message-Id: <3.0.3.32.19971021130836.00ff29f0@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Oct 1997 13:08:36 -0700 To: Arlie Davis From: Rob Lanphier Subject: RE: RTP payload format for ASF streams Cc: "'rem-conf@es.net'" In-Reply-To: <7D06B4AA8B39D011A64900805F682CDA02D7C04A@RED-09-MSG.dns.mi crosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 12:54 PM 10/21/97 -0700, Arlie Davis wrote: >Yes, I am. Did you read more than the first sentence of the post? Yes I did. You did not mention the concept below in that post (though you did in another post, which I was going to reply to, but I'll just say it here). > I >said that the stream description could be transmitted periodically, >*not* with every packet. The period between descriptions could be small >enough to have a negligible impact on bandwidth, and often enough to >make joining a multicast group (and learning the stream description) >relatively quick. This doesn't differ substantively from SDP/SAP. The fact that the description is broadcasted to a well-known rendezvous address rather than in-band is a strength, not a weakness. Broadcasting it in-band is not useful, unless you plan on scanning all 4 million multicasting addresses for content and then listening long enough to find out what it is just to avoid having a rendezvous point. 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 From rem-conf Tue Oct 21 13:27:50 1997 From rem-conf-request@es.net Tue Oct 21 13:27:50 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNksk-00000P-00; Tue, 21 Oct 1997 13:26:26 -0700 Message-ID: From: Eric Fleischman To: 'Henning Schulzrinne' Cc: Arlie Davis , 'Rob Lanphier' , rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 13:23:49 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > >> Please follow my logic to see how I arrived at this conclusion: >> * RTP is oriented to static RTP payload types -- an orientation >> that will increasingly become obsolete over time. > >Wrong. > >> * RTP extensions were created "to allow individual implementations >> to experiment with new payload-format-independent functions" (see first >> paragraph of RTP 1889 section 5.3.1) -- though the standard also >> discourages their use. Instead it encourages "additional information >> required for a particular payload format should not use this header >> extension, but should be carried in the payload section of this packet" >> (2nd paragraph of section 5.3.1). Ander's internet-draft proposes a >> mechanism consistent with this directive. > >But it is not "a specific payload type". It's a file type. Specific >payload types have very distinct needs. An HTML file might, for example, >want to break things at top-level element level, an H.261 file may need >to convey GOB information for each fragment, etc. You are certainly correct in viewing it as being a file type since that (unfortunately) is how it has been presented. However, this isn't how I view it. I view it as a mechanism for consistently conveying specific RTP packet information in a payload-independent fashion. [Note: we have both previously agreed that the relevent media stream information has already been conveyed by out-of-band means. Thus, this simply addresses packet information such as fragmentation. Please note that fragmentation occurs in a payload specific fashion in either case, but the approach I'm arguing for doesn't require either the client or the server to be aware of why the fragmentation occured at which specific point. It is thus much easier to stream.] The alternative to this approach which you seem to be advocating is to define an endless series of "payload types" for each distinct payload type instance. I view this requirement to be a total "show stopper" because new payload types are continually being defined and implemented -- and look at how much time is needed to register each of the payload types which have been registered!! The net effect of the current system is that implementations are forced to either not use unregistered types or else to use them in non-interoperable ways. Even if implementations could register these many types, which implementation can keep track of the various differences between them if they are all treated in such an "ad hoc" fashion? The combinatorics demonstrate (to my feeble brain, at least) the unworkability of such an approach, especially if one assumes (as I do) multimedia sessions with potentially large number of different media streams. (Note: I wouldn't have such difficulty if I were merely concerned with the media types currently used by conferencing applications such as H.323 conferences.) >> * The RTP community needs to use dynamic RTP payload types to >> support new media types, and, increasingly, all payload types. > >That's fully intentional. Static payload types are just a bootstrapping >mechanism which should become less needed as supporting tools (such as >RTSP) become more widely used. That's good news. >> * Dynamic payload types are entirely defined by out-of-band >> techniques (i.e., they lack all semantics built into Static Payload >> Types). > >Static payload types are no different from dynamic payload types. The >only difference is that you pick up the mapping to a globally unique >name (such as a GUID) from RFC 1890 instead of an SDP or other >mechanism. Excellent point. Thank you. >> Since this is so, RTP's whole payload orientation breaks down >> since what a dynamic payload type means is unknown to RTP and thus >> payload-specific semantics becomes undesirable and tenuous, especially >> for implementations of large number of different dynamic payloads (i.e., >> it is much easier for implementations to handle a large number of >> different dynamic payloads by treating them in a consistent, >> payload-independent fashion). > >These two things have nothing to do with each other. You are arguing >that the same mechanisms (such as fragmentation) apply to (almost) all >payload types. Experience with a large number of common non-audio >payload types has shown that not to be the case. Again, I refer you to >the different solutions needed for MPEG, JPEG, H.261 and H.263. This has >nothing whatsoever to do with the fact that these payload types are >static or not (or the desire to create extra work...). On the contrary, I do not seek to argue this at all. Rather, I am trying to argue that generic extensibility capabilities are needed within RTP so that these concepts can be addressed in a systematic and generic (non-ad hoc) fashion. (My point being that just because the fragmentation approaches for MPEG, JPEG, H.261, etc differ, does not mean that clients and servers need to be aware of these differences as RTP currently requires. All that clients and servers need is a generic approach to implement the payload-specific fragmentations which the editing tool or live encoder device performs.) This will permit RTP to be readily adaptable to support the scores of media types whose semantics will be defined via out-of-band techniques without needing to define a specific payload format for each one. Other readers of this list may perhaps view my previous sentence to be fantastic, but I expect you to understand my point since you have already read the ASF spec which explains one mechanism by which such variability can be coherently expressed in a general format. All that is lacking is a generic approach to address specific packet information -- the topic of this thread. By the way, I view this controversy/problem to be solely limited to trying to express generic and varied media types within RTP. The inverse (i.e., recording existing MBONE content within ASF) is rather transparent and demands no changes to either RTP or ASF. I am in the process of trying to write an internet-draft document on how to do this mapping for recording MBONE sessions to ASF. Such a recording does not need any of the structures postulated for RTP by Anders Klemet's internet-draft -- nor does the playback of such recorded information >from ASF files. From rem-conf Tue Oct 21 13:29:30 1997 From rem-conf-request@es.net Tue Oct 21 13:29:30 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNkv6-0000Al-00; Tue, 21 Oct 1997 13:28:52 -0700 Date: Tue, 21 Oct 1997 13:27:52 -0700 () From: Stephen Casner To: rem-conf@es.net, ASF@LISTSERV.MSN.COM Subject: RE: RTP payload format for ASF streams In-Reply-To: <3.0.3.32.19971021001837.011cd1c4@mail.real.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 I believe the discussion of the proposed RTP payload format for ASF should happen on the AVT mailing list, that is rem-conf. It would be OK for the discussion to be copied to the ASF list as well except that the ASF list follows a policy of removing all destination addresses except for the ASF list itself. I dislike this policy on any list, but in this case it is causing the discussion to become fractured since a response sent to a message received on the ASF list is not seen by those only on the rem-conf list. May I request that anyone participating in this discussion who answers a message received on the ASF list take the effort to add (back) the rem-conf@es.net address as well. Or, just answer the copy that comes through the rem-conf list instead. Thanks. -- Steve From rem-conf Tue Oct 21 14:29:48 1997 From rem-conf-request@es.net Tue Oct 21 14:29:48 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNlka-0001LC-00; Tue, 21 Oct 1997 14:22:04 -0700 Sender: hgs@cs.columbia.edu Message-ID: <344D1CF9.6DB6@cs.columbia.edu> Date: Tue, 21 Oct 1997 17:22:01 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Arlie Davis CC: rem-conf@es.net Subject: Re: RTP payload format for ASF streams References: <7D06B4AA8B39D011A64900805F682CDA02D7C048@RED-09-MSG.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Arlie Davis wrote: > > I don't think RTSP is that great. It depends on the concept of a > session, and it depends on bidirectional communication, which is not > always possible, desireable, or scalable. You don't need RTSP. If large-scale, unidirectional multicast is your goal, SAP/SDP is the appropriate mechanism. The client tool gets the same information, however, it may have to wait Any other magic mechanisms that you have in mind? > > The fact that RTP *could* be self-describing but is not is a true > weakness. Since you need a discovery protocol in any event to allow you to decide if you profitably join a multicast group, replicating that information in RT(C)P does no good. One could include SDP-like information in RTCP packets, but that serves no useful purpose if one needs discovery or session establishment in any event. > RTP was originally quite appealing precisely because you > could determine everything about the stream from the stream itself. I > think this is a desireable, and easily attainable, design goal. Pray tell, how? > Requiring RTSP, SDP, HTTP, or whatever external means of communicating > information about the stream is just an adaptive hack. > > -- arlie > > > -----Original Message----- > > From: Rob Lanphier [SMTP:robla@real.com] > > Sent: Tuesday, October 21, 1997 11:22 AM > > To: Arlie Davis > > Cc: 'rem-conf@es.net' > > Subject: RE: RTP payload format for ASF streams > > > > At 01:47 AM 10/21/97 -0700, Arlie Davis wrote: > > >I agree that adding more layers to the protocol stack is Bad. > > However, > > >ASF-on-RTP is required because the RTP payload type system is > > woefully > > >inadequate. It describes a few static types, with precious little > > >extensibility. ASF allows much more in the way of an extensible > > payload > > >description. The support for dynamic payload types in RTP is > > extremely > > >weak, mostly because it relies on using out-of-band communication to > > >describe the true payload format. > > > > The out-of-band mechanism that we are using is RTSP, which is a > > protocol. > > ASF is a file format. We shouldn't use file formats to do the job of > > protocols. > > > > 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 -- 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 From rem-conf Tue Oct 21 16:08:29 1997 From rem-conf-request@es.net Tue Oct 21 16:08:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNnM2-0002WI-00; Tue, 21 Oct 1997 16:04:50 -0700 Sender: hgs@cs.columbia.edu Message-ID: <344D350F.7A40@cs.columbia.edu> Date: Tue, 21 Oct 1997 19:04:47 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Eric Fleischman CC: Arlie Davis , rem-conf@es.net Subject: Re: RTP payload format for ASF streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This dicussion is basically about whether generic fragmentation makes sense or not (and when), not so much about payload types. The designers of RTP believed that, in general, fragmenting application data units (ADUs) "blindly" is about as bad as IP fragmentation, as loss of a single fragment will make the whole ADU unintelligible to the receiver. Experience seems to show that the notion that only length and position information is needed to allow the client to make use of partial ADUs is not correct. The existing video formats don't just do this differently because authors didn't read each other's specs but because there is ADU-based "global" information that needs to be conveyed in each RTP packet to allow partial decoding. Unfortunately, this means that server and client need to be aware as to where to find this information and what it is, as it is not present in the equivalent disk format. It may well turn out that for some class of codecs only byte-level fragmentation information is necessary. (A concrete example might help the discussion). "Real-Time" HTML may work, although I'd suspect that even there, each packet may need to contain things like a pointer to the style file for that (partial) page, so that, again, the server has to understand the media format rather than just "chop at MTU". While creating payload types for each media type sounds burdensome, the effort is minimal compared to the effort of developing a codec and its implementation. In the spirit of application-layer framing, the codec may well get the RTP packets and assemble those. This does mean that you can't just use a codec implementation that simply expects unlimited size (disk) blocks to be delivered whole to work well in a network environment. Traditional layering in the spirit of IP/UDP (IP doesn't care what's in the fragments, it just slaps them together and delivers them to the next higher layer when complete) doesn't work well for any codec that I've met. Thus, part of understanding a media type to decode it is to understand how to packetize and re-assemble it. Rather than trying to encourage a technically inferior solution of "chop and ship", we should encourage codec vendors to define packetizations and API vendors to define API interfaces that I can hand RTP-appropriate information to. There is an argument to be made for a last-ditch payload format, although in many cases, using IP fragmentation is more packet-size efficient and no worse in terms of partial decodability in that case. If there are stream data units that exceed 65 k (or 8 k, say), then we may need application-layer "blind" fragmentation. Henning From rem-conf Tue Oct 21 17:02:03 1997 From rem-conf-request@es.net Tue Oct 21 17:02:02 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNoDU-0003Lq-00; Tue, 21 Oct 1997 17:00:04 -0700 Date: Tue, 21 Oct 1997 16:58:27 -0700 (PDT) From: Karl Auerbach X-Sender: karl@big-bear Reply-To: karl@precept.com To: Henning Schulzrinne cc: Eric Fleischman , Arlie Davis , rem-conf@es.net Subject: Re: RTP payload format for ASF streams In-Reply-To: <344D350F.7A40@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > ... Rather than > trying to encourage a technically inferior solution of "chop and ship", > we should encourage codec vendors to define packetizations and API > vendors to define API interfaces that I can hand RTP-appropriate > information to. Agreed. One additional bit of information that would be useful is if codecs provided a map of good "scribe lines" where the RTP packetizer could break the raw data into network packets with the lowest risk of rendering damage should a packet be lost in transit. --karl-- From rem-conf Tue Oct 21 17:26:07 1997 From rem-conf-request@es.net Tue Oct 21 17:26:06 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNoal-0003uR-00; Tue, 21 Oct 1997 17:24:07 -0700 Message-ID: From: Eric Fleischman To: 'Henning Schulzrinne' Cc: rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 17:23:15 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thank you, Henning, for returning us to the principle subject at hand. Please put your mind at ease: nobody is arguing for "chop and ship" fragmentation. You are preaching to the choir when it comes to the need to do fragmentation in an intelligent, media specific fashion. I think that we all agree that fragmentation must be performed by a device which understands the relevent encoding type. Such devices would be the editing system (for on-demand content creation) or the real time encoding system (for live content creation). I believe that there is common agreement on this point. Please correct me if I am mistaken. Having said this, I believe that the current RTP system of defining payload types for each encoding approach is untenable and that an alternative, scaleable system needs to be defined. There are simply too may payload types which need to be recorded and the registration process is unacceptably onerous. New and novel payload types are continually being devised and need to be readily introduceable within the RTP mileau as dynamic payload types. Non-encoding and non-decoding devices and sub-systems should not be burdoned with the knowledge of payload type esoteria. The combinatorics of this current approach convinces me that we have addressed this problem in a "brute force" fashion which doesn't scale. I invite the AVT community to join me in seeking to devise a solution which does scale. I view Anders Klemet's internet-draft document as an excellent first step in this direction. It proposes a mechanism for consistently conveying additional RTP packet information in a payload-independent fashion. (Yes, I share your concern, Henning, that it is file format specific -- but it is a beginning of a promising direction!!) It relies on relevent media stream information to have already been conveyed by out-of-band means to identify to the decoding device how to treat that data. It permits (non-encoding) servers to convey fragmentation information which is presented in a consistent, general format (should it exist) so that servers (and the non-decoding part of the client system) needn't understand anything about that fragmentation, only how to serve it. There are three key points to what I am saying: 1) that the concepts which define payload specific features be presented to the RTP system as a whole via a common interface approach across the board so that one-and-only-one system can support all of this diversity. In this way implementations will be simplified by only needing to know one system to address these common considerations. 2) that this common approach only appear when it is needed. 3) that the approach be scaleable and extensible to support new and novel innovations and inventions in a consistent fashion. I believe that draft-klemets-asf-rtp-00.txt is a noble first step towards addressing these issues. I invite the AVT community to join us in examining possible solutions to make RTP payload types scaleable, extensible, simple, and generic without introducing non-intelligent encoding or decoding of media types. > -----Original Message----- > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > Sent: Tuesday, October 21, 1997 4:05 PM > To: Eric Fleischman > Cc: Arlie Davis; rem-conf@es.net > Subject: Re: RTP payload format for ASF streams > > This dicussion is basically about whether generic fragmentation makes > sense or not (and when), not so much about payload types. > > The designers of RTP believed that, in general, fragmenting > application > data units (ADUs) "blindly" is about as bad as IP fragmentation, as > loss > of a single fragment will make the whole ADU unintelligible to the > receiver. > > Experience seems to show that the notion that only length and position > information is needed to allow the client to make use of partial ADUs > is > not correct. The existing video formats don't just do this differently > because authors didn't read each other's specs but because there is > ADU-based "global" information that needs to be conveyed in each RTP > packet to allow partial decoding. Unfortunately, this means that > server > and client need to be aware as to where to find this information and > what it is, as it is not present in the equivalent disk format. > > It may well turn out that for some class of codecs only byte-level > fragmentation information is necessary. (A concrete example might help > the discussion). "Real-Time" HTML may work, although I'd suspect that > even there, each packet may need to contain things like a pointer to > the > style file for that (partial) page, so that, again, the server has to > understand the media format rather than just "chop at MTU". > > While creating payload types for each media type sounds burdensome, > the > effort is minimal compared to the effort of developing a codec and its > implementation. In the spirit of application-layer framing, the codec > may well get the RTP packets and assemble those. This does mean that > you > can't just use a codec implementation that simply expects unlimited > size > (disk) blocks to be delivered whole to work well in a network > environment. Traditional layering in the spirit of IP/UDP (IP doesn't > care what's in the fragments, it just slaps them together and delivers > them to the next higher layer when complete) doesn't work well for any > codec that I've met. Thus, part of understanding a media type to > decode > it is to understand how to packetize and re-assemble it. Rather than > trying to encourage a technically inferior solution of "chop and > ship", > we should encourage codec vendors to define packetizations and API > vendors to define API interfaces that I can hand RTP-appropriate > information to. > > There is an argument to be made for a last-ditch payload format, > although in many cases, using IP fragmentation is more packet-size > efficient and no worse in terms of partial decodability in that case. > If > there are stream data units that exceed 65 k (or 8 k, say), then we > may > need application-layer "blind" fragmentation. > > Henning From rem-conf Tue Oct 21 17:26:15 1997 From rem-conf-request@es.net Tue Oct 21 17:26:14 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNobo-0003ul-00; Tue, 21 Oct 1997 17:25:12 -0700 Message-Id: <3.0.3.32.19971021172506.01093104@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Oct 1997 17:25:06 -0700 To: Eric Fleischman From: Rob Lanphier Subject: RE: RTP payload format for ASF streams Cc: rem-conf@es.net 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 01:23 PM 10/21/97 -0700, Eric Fleischman wrote: >You are certainly correct in viewing it as being a file type since that ^^ >(unfortunately) is how it has been presented. However, this isn't how I >view it. I view it as a mechanism for consistently conveying specific >RTP packet information in a payload-independent fashion. [Note: we have >both previously agreed that the relevent media stream information has >already been conveyed by out-of-band means. Thus, this simply addresses >packet information such as fragmentation. Please note that fragmentation >occurs in a payload specific fashion in either case, but the approach >I'm arguing for doesn't require either the client or the server to be >aware of why the fragmentation occured at which specific point. It is >thus much easier to stream.] Does "it" refer to ASF or to Anders' draft. (I looked to enough context to make this clear, and wasn't able to find it.) Do you really mean that it was unfortunate that Anders' draft had "ASF" in the title, or that it was unfortunate that ASF has mistakenly been presented as a file format? The distinction makes a lot of difference here, and clearing this up may clear up the discussion here. ASF is very clearly a file format, and I would agree that it was unfortunate that Anders' draft had "ASF" in the title, because that generated a lot of unnecessary heat. However, if you are saying that ASF is more than a file format, we really need clarification on what ASF is. 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 From rem-conf Tue Oct 21 19:12:43 1997 From rem-conf-request@es.net Tue Oct 21 19:12:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNqDW-0005Ma-00; Tue, 21 Oct 1997 19:08:14 -0700 Message-ID: <19971021190812.49814@nlanr.net> Date: Tue, 21 Oct 1997 19:08:12 -0700 From: k claffy To: rem-conf@es.net Subject: Forum Reminder, Wednesday, Oct 22, 7pm: weblications, vrml 97 overview Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64e X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Date: October 22, 1997 Time: 7:00PM (PST) Place: SDSC Auditorium Mark Punak, Silver Stream, "Building 'Weblications' using Silver Stream's Web Application Platform" Mark will discuss teh development of web applications, or 'weblications', using the Web Applicaiton Platform of SilverStream Software. The presentation will be mostly technical in nature and should appeal to web developers. John Moreland, San Diego Supercomputer Center, "Overview of VRML 97" This presentation introduces participants to the latest version of VRML and describes the features, capabilities, and some applications of the language. The presentation includes numerous VRML examples and information on where to find more about VRML features and use. See our web page for details, parking info, directions, and information on how to see the mbone broadcast of this meeting. www.sdsc.edu/scwpf From rem-conf Tue Oct 21 19:56:05 1997 From rem-conf-request@es.net Tue Oct 21 19:56:04 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNqvp-0005zu-00; Tue, 21 Oct 1997 19:54:01 -0700 Message-Id: <199710220253.TAA03856@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Steve Deering cc: rem-conf@es.net Subject: Re: RTP payload format for ASF streams In-reply-to: Your message of "Tue, 21 Oct 1997 11:39:16 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Oct 1997 19:53:27 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I appreciate the desire for more flexibility in RTP to enable the > able talk to each other. If the small Payload Type field makes it > relatively "expensive" to add new encodings, that's probably a Good Thing, > from the IETF, if not the corporate, point of view. > > Steve > > > I don't agree with your assesment for instance the web browserses to a certain extent have been able to evolve besides the existing rtp mechanism just simply invites new, exciting , creative ways. The alternatives so far are: 1. Proposals similar to Anders 2. Go all the way like Precept and define an opague data structure karl@precept.com said: > Essentially we treat the stream as binary data of unknown structure, > chopping it into RTP packets as appropriate for the path MTU. We > assert the RTP M bit either at the start of end of significant chunks, > i.e. Application Data Units (ADUs). (M bit handling depends on > whether the stream is nominally audio or video or a combination.) > We don't have any tag that says "this opaque content is purported to > be of type xxx"; the application is expected to make heads or tails > out of what it gets, so there is some a priori knowledge (in the > application, not in the RTP code) about the structure of the data > bits. > Since the format grew somewhat organically I don't believe we have a > formal payload definition document. > --ka 3. Forget about RTP and create your own RTP protocol. I am sure that there are other popular methods for encoding multiple date types in fact to numerous and here I think lies the danger. Cheers, Amancio > I appreciate the desire for more flexibility in RTP to enable the > technology to evolve, but don't forget that flexibility is often the > enemy of interoperability, and interoperability is the whole point of > Standards. Certainly, gratuitous proliferation of payload types/encodings > makes it less and less likely that two different implementations will be > able talk to each other. If the small Payload Type field makes it > relatively "expensive" to add new encodings, that's probably a Good Thing, > from the IETF, if not the corporate, point of view. > > Steve > > > From rem-conf Tue Oct 21 20:20:10 1997 From rem-conf-request@es.net Tue Oct 21 20:20:09 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNrIX-0006U9-00; Tue, 21 Oct 1997 20:17:29 -0700 Date: Tue, 21 Oct 1997 20:15:47 -0700 (PDT) From: Karl Auerbach X-Sender: karl@big-bear Reply-To: karl@precept.com To: Amancio Hasty cc: Steve Deering , rem-conf@es.net Subject: Re: RTP payload format for ASF streams In-Reply-To: <199710220253.TAA03856@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With regard to Precept's "unstructured" mechanism -- it is an escape when no other facilities are available. It is *very* important to use encoding-specific packetization when sufficient information is available. That said, I should point out that "encoding-specific packetization" is a late-binding phenomenon. One can not safely anticipate the appropriate data break-points/scribe-lines without knowing the network MTU. Thus, the notion of pre-breaking encodings and putting the pre-broken data into a file is unrealistic. --karl-- From rem-conf Tue Oct 21 21:51:23 1997 From rem-conf-request@es.net Tue Oct 21 21:51:22 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xNsgU-0007XT-00; Tue, 21 Oct 1997 21:46:18 -0700 Message-ID: From: "Anders Klemets (VXtreme)" To: 'Rob Lanphier' Cc: rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Tue, 21 Oct 1997 21:35:47 -0700 X-Mailer: Internet Mail Service (5.5.1939.0) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tuesday, October 21, 1997 5:25 PM, Rob Lanphier [SMTP:robla@real.com] wrote: > The distinction makes a lot of difference here, and clearing this up may > clear up the discussion here. ASF is very clearly a file format, and I > would agree that it was unfortunate that Anders' draft had "ASF" in the > title Yes, it is probably confusing that the spec has "ASF" in the title. It does not mean that the payload format can only be used with ASF files. I stated early on that it should be possible to use the payload format to transmit data that is stored in other kinds of files. (But perhaps that comment got lost in the noise!) However, the payload format is optimized, or "tuned" for efficient transmission of ASF files. It means that if you have an ASF file, you don't need to go through complicated transformations to transmit the "records" (Data Units) in the file. For example, most fields use the same number of bits on the wire as they use in the file. I am told that the ASF payload type has too much "goo" in it, and that it would be better to have a "generic" or "generalized" RTP payload type. Such a payload type would be designed to be good enough to carry any unknown media type, independently of the file format used to store it. I think that there might be some merit to such an idea. But the problem is that an ASF "record" has several fields that are used in a way that is codec-specific. For instance, there is a "clean point flag", an "Object ID", and even an "object size" field that may be used in a codec-specific fashion. Since it is not known how codecs are going to use these fields, the fields have to be included in the RTP packet. That seems to be one of the main issues that has fueled all this discussion. Now, suppose we want to define a "generic", file format independent, RTP payload type. How would we design it so that it can be used with ASF files? One approach that has been suggested, is a "minimalist" method, where the generic payload type only supports fragmentation and grouping. But we still need to send the remaining ASF fields that are not included in the minimalist header. A solution would be to define an "ASF extension profile" that specifies how to the ASF fields are sent using the generic payload type. Other file formats, may have to use extension profiles of their own. As you can see, we would end up with an extra layer between RTP and the ASF payload type, and it does not buy us much. Another approach for a "generic" RTP payload type is exactly the opposite of what was just described. One would create a very "rich" payload type that would efficiently encode all the flags and fields one may think of. Fields that are not needed would be optional or set to some default value. It would still be possible to extend such a payload type, but the expectation would be that it would rarely be necessary. The ASF payload type could be used as such a rich generic payload type. I may want follow some suggestions and swap the two timestamps, and maybe make the send timestamp optional, but other than that, I think the spec can be used as-is. But there is no guarantee that any generic payload type will always be the right thing for everybody. Suppose some new ASF-like file format comes along, which has some additional fields that need to be included in most RTP packets. These additional fields would have to be transmitted using the extension mechanism of the generic payload type. Depending on how that mechanism works, one either has to rely on out-of-band information for how to interpret the extensions, or one must include addional Type and Length fields, which causes a per-packet overhead. Anders From rem-conf Wed Oct 22 08:31:09 1997 From rem-conf-request@es.net Wed Oct 22 08:31:08 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xO28a-00036M-00; Wed, 22 Oct 1997 07:51:56 -0700 From: Stefan Winterstein-Theobald Message-Id: <199710221452.QAA17807@kik-10.dfki.uni-sb.de> Subject: Re: vic and SIEMENS I-VIEW videoconferencing card To: mech@tnt.uni-hannover.de (Roland Mech) Date: Wed, 22 Oct 1997 16:52:40 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: <34449C44.237C228A@tnt.uni-hannover.de> from "Roland Mech" at Oct 15, 97 12:34:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > does anybody know a patch for the vic mbone-tool or a vic binary so that > vic can be used with the "SIEMENS I-VIEW" videoconferencing card? As far as I know, the I-View card does not come with a Video for Windows interface, so the standard vic does not work. Also, I know of no special vic version for I-View, sorry. > Roland Mech Gruss, -Stefan ............................................................................ Stefan Winterstein-Theobald Siemens Telekooperationszentrum winter@stz.dfki.de ............................................................................ From rem-conf Wed Oct 22 09:17:30 1997 From rem-conf-request@es.net Wed Oct 22 09:17:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xO3Mq-0003zE-00; Wed, 22 Oct 1997 09:10:44 -0700 Message-ID: From: Eric Fleischman To: 'Rob Lanphier' Cc: rem-conf@es.net Subject: RE: RTP payload format for ASF streams Date: Wed, 22 Oct 1997 09:10:22 -0700 X-Mailer: Internet Mail Service (5.5.1939.0) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: Rob Lanphier [SMTP:robla@real.com] >At 01:23 PM 10/21/97 -0700, Eric Fleischman wrote: >>You are certainly correct in viewing it as being a file type since that > ^^ >>(unfortunately) is how it has been presented. However, this isn't how I >Does "it" refer to ASF or to Anders' draft. (I looked to enough context to >make this clear, and wasn't able to find it.) Do you really mean that it >was unfortunate that Anders' draft had "ASF" in the title, or that it was >unfortunate that ASF has mistakenly been presented as a file format? My reply was an attempt to scratch the itch of how best to solve a multi-faceted problem. Here are the issues as seen from my knothole: 1) There needs to be a direct, timely, and efficient way of conveying payload information within RTP for new and novel payload types as dynamic payload types. The approach should be interoperatable between vendor implementations. 2) This system should establish clear interfaces so that any payload types needing extensions to RTP will implement the same extensions in the same fashion. These extensions should ideally be only as long as needed in any instance so as to conserve space. 3) There needs to be a clean way to indicate encoding information for dynamic payload types within the session announcement process. This process should be extensible and permit the inclusion of file header information to convey enhanced semantics to benefit those systems able to understand such information. In addition, we need to have a mapping of how to convey how non-RTP-oriented multimedia sessions which have been recorded in ASF should be mapped to use RTP transports. This was the central goal of Anders' internet-draft. Unfortunately, my personal frustration is that there is no general solution for issues 1 through 3 at this time so that we had to also combine issues 1 and 2 as an intricate part of our target (i.e., mapping non-RTP multimedia sessions to RTP transports) otherwise we wouldn't be specifying a complete solution. Thus, the message which I was seeking to convey to Henning was that because of this unfortunate coupling, he has every right to view our proposal as being an RTP file type proposal. However, in my mind the most critical elements of Anders' internet-draft affecting the AVT community as a whole is that it presents an excellent "first step" to resolving issues 1 and 2 above. These issues, by the way, include many more technical considerations than merely fragmentation -- as is reflected by draft-klemets-asf-rtp-00.txt. BTW: Section 1.2 of the ASF spec is entitled "What is ASF?" and answers the question of what ASF is. Therefore, that text can authoritatively answer that question for anyone who is confused. A short answer is that "ASF is an extensible multimedia file format defining a set of standard media type classes". In any case, the meaning I had intended in my reply to Henning was not directly related to ASF at all. From rem-conf Wed Oct 22 10:28:15 1997 From rem-conf-request@es.net Wed Oct 22 10:28:14 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xO4UZ-0004uH-00; Wed, 22 Oct 1997 10:22:47 -0700 Date: Thu, 23 Oct 1997 01:14:09 +0800 From: gskuo@IMRNET.MGT.NCU.EDU.TW (G.S. Kuo) Message-Id: <199710221714.BAA07091@IMRNET.MGT.NCU.EDU.TW> To: cost237-transport@comp.lancs.ac.uk, dbworld@cs.wisc.edu, f-troup@codex.cis.upenn.edu, rem-conf@es.net, reres@laas.fr, tccc@cs.umass.edu, xtp-relay@cs.concordia.ca Subject: IEEE BSS'97 Advanced Technical Program and Registration X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- IEEE BSS '97 2nd IEEE International Workshop on Broadband Switching Systems The Ritz Taipei Hotel, Taipei, R.O.C., 2-4 December 1997 Workshop Theme: "Switching Systems for the Broadband Internet and for QoS on Demand" Technical Sponsored by IEEE Communications Society. Sponsored by National Science Council of ROC. Co-sponsored by The Ministry of Education of ROC Chunghwa Telecom Co., Ltd., Taiwan, ROC ITRI, ROC (pending) Ericsson Taiwan Ltd. National Central University, ROC. OBJECTIVE ========= The goal of this workshop is to provide an effective forum for discussing new directions, new challenges, new opportunities, and new advances on Broadband Switching Systems, and to foster communications among researchers and engineers from both academia and industry with a common interest in improving Broadband Switching Systems. WORKSHOP ORGANIZERS =================== Honorary General Co-Chairs: C. H. Liu, National Central University, Taiwan, ROC. Maurizio Decina, Politecnico di Milano/CEFRIEL, Italy General Chair: Jin-Fu Chang, National Science Council, ROC. Vice General Co-Chairs: Wen-Tsuen Chen, National Tsing Hua University, Taiwan, ROC. Jean-Lien C. Wu, National Taiwan Institute of Technology, ROC. Keynote Speaker: Steve Weinstein, NEC America, USA Technical Program Committee Co-Chairs: G.S. Kuo, National Central University, Taiwan, ROC. Kai Eng, Bell Labs., USA Technical Program Committee: Chung-Ju Chang, National Chiao Tung University, Taiwan, ROC. Jurgen Haag, Deutsche Telekom, Germany Bijan Jabbari, George Mason University, USA Andrzej Jajszczyk, Institute of Communication and Information Technologies Ltd., Poland Dennis Kong, Bellcore, USA Lung-Sing Liang, Telecommunication Laboratories, Chunghwa Telecom Co., Ltd., Taiwan, ROC. Steve Liu, GTE Labs., USA Richard Vickers, NORTEL, Canada Naoaki Yamanaka, NTT, Japan Chu Hwan Yim, ETRI, Korea ADVANCED TECHNICAL PROGRAM ========================== ========================== Day One - Tuesday, December 2, 1997. ==================================== 9:00 - 12:00 Tutorial 1: Nonblocking Multirate Switching Networks Frank K. Hwang, National Chiaotung University ABSTRACT To combine audio, data and video networks all into one, an ATM network must be able to connect requests requiring a broad range of bandwidths, or rates. The classical theory on nonblocking networks needs a complete overhaul for this new multirate environment. I will present the up-to-date story on the recent development of this new theory, taken from a chapter from my upcoming book "Mathematical Theory of Nonblocking Switching Networks." 9:00 - 12:00 Tutorial 2: Management Platforms: Operability, Portability, Interoperability Joseph Ghetie, Bellcore, USA. ABSTRACT The tutorial provides a basis for analysis of technical capabilities of distributed management platforms in offering operability services as required by the users/operators, portability of management applications running on top of these management platforms, and interoperability between similar/dissimilar management platforms. The objective of this analysis is to determine the extent to which management platforms provide flexible, scalable, integrated, enterprise-wide management, including management of broadband networks. The purpose of this tutorial is to provide useful and timely analysis information to technical and managerial staff (planners, designers, developers, procurers, and users) seeking selection of management platforms and selection of management applications associated with management platforms. 14:00 - 17:00 Tutorial 3: Agent Platforms Analysis and Evaluation Joseph Ghetie, Bellcore, USA. ABSTRACT This tutorial presentation is focused on agent platforms design, functions, interfaces, development, and implementations in order to manage enterprise- wide networks, including broadband networks. Six major conceptual and implementation agent paradigms are analyzed: SNMP/RMON Agent, OSI CMIP/TMN Agent, DMTF DMI Agent, RPC-based Agents, CORBA distributed object environment, and WEB-based management. Agent development environments and toolkits used in agent applications development are also presented. Evaluation criteria for agent platforms are presented along with the analysis of several available agent development tools. The purpose of this tutorial is to provide useful and timely analysis information to technical and managerial staff (planners, designers, developers, procurers, and users) seeking selection of management and agent platforms and selection of agent applications development tools. 18:30 - 20:00 Welcome Reception Day Two - Wednesday, December 3, 1997. ====================================== 8:00 - 9:00 Registration 9:00 - 9:10 Workshop Opening 9:10 - 9:20 Guest Speech 9:20 - 9:50 Keynote Speech - "A Future of Diversity: Multimedia Communications and Applications in the Broadband Internet" Dr. Stephen B. Weinstein, NEC C&C Laboratories, USA. President of IEEE Communications Society. ABSTRACT The 1980s' dream of universal B-ISDN service for residential subscribers, delivered through optical fibers at rates of 155Mbps and above, has given way to a more diverse and less expensive universe of wideband and broadband access systems. These systems, oriented more toward Internet access than traditional network services, come in a variety of physical architectures and communication protocols. The task of edge switches and multiplexers will be to support this diversity, including utilizing overlay networks within the same communication session. A particular objective is to invoke high quality of service connections from within best- effort Internet applications. Beginning from consideration of the B-ISDN model, I introduce the more diverse broadband vision that has been inspired by the innovations of the Internet. I describe how overlay switching and distributed object system middleware supports future multimedia applications, illustrated with applications that I believe will become popular with a large public in the not-too-distant future. 9:50 - 10:30 Invited Presentation - "Research Perspectives in High-Speed Networks: Gigabit ATM, Wireless ATM and Gigabit Ethernet" Dr. Kai Eng, Bell Labs., USA 10:30 - 10:45 Tea & Coffee 10:45 - 12:15 Technical Session 1: ATM and IP (4 papers) [1] ATM Switching and IP Routing Integration: The Next Stage in Internet Evolution Paul Patrick White University College London, UK. [2] Improving the Fairness of TCP over ATM WAN with the Age Priority Packet Discarding Scheme Hong-Bin Chiou* and Zsehong Tsai** * Chunghwa Telecommunication Co., Ltd., Taiwan, ROC. ** National Taiwan University, Taiwan, ROC. [3] Interworking between IFMP Switching and B-ISDN Access Protocols L. Cipriani*, D. Di Giorgio**, M. Pugliese**, and S. Salsano*** * Ericsson Telecomunicazioni S.p.A., Italy. ** CoRiTel, Italy. *** Universita "La Sapienza" di Roma, Italy. [4] Early Packet Discard with Diverse Management Policies for EOM Cells Maurizio Casoni University of Bologna, Italy. 12:30 - 13:45 Luncheon Invited Speech - "R&D Status on Broadband ATM Switching Systems in Taiwan" Dr. Jin Tuu Wang, Telecommunication Laboratories, Chunghwa Telecom Co., Ltd., ROC. 14:00 - 15:30 Technical Session 2: ATM Switch Architecture (4 papers) [1] Tandem-crosspoint ATM Switch Architecture and Its Cost- effective Expansion Eiji Oki, Naoaki Yamanaka, and Seisho Yasukawa NTT, Japan. [2] A Bus-based Modular Approach to Designing A Large Scale ATM Switch Young-Keun Lee and Young-Keun Park Yonsei University, Korea. [3] Flexible ATM Switching Architecture for Multimedia Communications Zenichi Yashiro, Toshiro Tanaka, and Yukihiro Doi NTT, Japan. [4] ATM Switching System Architecture for ATM Trunking Using AAL1 Sung-Jae Lee, Tae-Joon Park, and Jung-Sik Kim ETRI, Korea. 15:30 - 15:45 Tea & Coffee 15:45 - 17:15 Technical Session 3: Switch Performance (4 papers) [1] Technical Issues on ATM Network Performance and Quality of Services and Related Standards Terufumi Shinomiya*, Hideyo Murakami*, and Koichi Asatani** * NTT, Japan. ** Kogakuin University, Japan. [2] Performance Modelling of Multistage ATM Switches with Backpressure Control Schemes Simon Fong and Samar Singh La Trobe University, Australia. [3] Performance Simulation of A Multicast Input-Indexed Switch Felixberto S. Cruz and Peter A. Ivey University of Sheffield, UK. [4] A Hybrid ATM VBR/ABR Service for Scalable MPEG2 Video Networking: A Simulation -based Analysis Ahmed Mehaoua Computer Science Research Institute of Montreal, Canada. 18:30 - 20:30 Banquet Banquet Speech - "The Internet Revolution: Reshaping Business for the 21st Century" Prof. Maurizio Decina, Politecnico di Milano/CEFRIEL, Italy Past President of IEEE Communications Society ABSTRACT The age of digital convergence cannot be ignored by technology, service, and content provision companies, given the phenomenal growth of the Internet and its enormous potential in delivering services. While the interactive television and video on demand early pilot trials have not succeeded on the market, the unpredicted explosive development of the Internet and the World Wide Web have clearly demonstrated that Internet is the medium where the commercial and end users interests' converge. The fundamental limitation in the existing Internet model is the lack of network bandwidth for delivering synchronous media such as video and audio with the needed Quality of Service performance, which is fundamental for applications in the consumer and the business markets. The next generation of Internet will offer a new network architecture suitable for the provision of broadband multimedia services and applications, thus expanding the end users' WWW experience from the technological, content, and service provision point of view. The purpose of the speech is to offer an entertaining overview of the latest development in building an Integrated Services Internet Architecture, as well as of the current efforts of the Telecommunications community to develop broadband networks based on ATM (Asynchronous Transfer Mode) standards. Day Three - Thursday, December 4, 1997. ======================================= 9:00 - 10:30 Technical Session 4A: Photonic Switching-Related Topic (2 papers) [1] 640Gb/s Ultra-High-Speed Optical Interconnection System Using Wide-Channel-Spacing Wavelength Division Multiplexing Seisho Yasukawa and Naoaki Yamanaka NTT, Japan. [2] Architecture of 2-to-1 COD Multiplexers for Asynchronous Packet Arrivals Jung-Tsung Tsai ITRI, Taiwan, ROC. Technical Session 4B: Wireless ATM (2 papers) [1] Mobile ATM: Architecture, Protocols and Implementation Arup Acharya, Jun Li, and D. Raychaudhuri NEC C&C Research Laboratories, USA. [2] Wireless ATM LAN with and without Infrastructure Y. Du, C. Herrmann, and P. May Philips Research Laboratories, Germany. 10:30 - 10:45 Tea & Coffee 10:45 - 12:15 Technical Session 5: Flow Control and Scheduling (4 papers) [1] A Prediction Algorithm for Feedback Control Models with Long Delays B. Jang, B.G. Kim and G. Pecelli University of Mass. Lowell, USA. [2] Flow Control in A High-Speed Bus-Based ATM Switching Hub Song Chong*, Ramesh Nagarajan**, and Y.T. Wang** * Sogang University, Korea. ** Bell Laboratories, Lucent Technologies, USA. [3] An Efficient Scheduling Algorithm to Input-queueing ATM Switch Bin Li, Mounir Hamdi, and Xi-Ren Cao The Hong Kong University of Science and Technology, Hong Kong, China. [4] A RAM-Based Generic Packet Switch with Scheduling Capability Massoud R. Hashemi and Alberto Leon-Garcia University of Toronto, Canada. 12:30 - 13:45 Luncheon Invited Speech - "Switching Bits in the Years Ahead" Prof. Hussein Mouftah, Queen's University, Canada Editor-in-Chief of IEEE Communications Magazine 14:00 - 15:30 Technical Session 6: Switching Service and Operation- Related Topic (4 papers) [1] Efficient Multicast Copy Network M. Alimuddin, H. M. Alnuweiri, and R. W. Donaldson University of British Columbia, Canada. [2] Priority Control Mechanism by Cell Service Ratio in ATM Switch Won Gi Park and Yoon Yu Lee ETRI, Korea. [3] Minimal Overhead Fault Masking Scheme for Broadband Multi- Channel Switching Peter Y. Yan and Paul S. Min Washington University, USA. [4] Implementation of ATM OAM Functions for the Integrated Service Access Network Sang-Ho Lee ETRI, Korea. 15:30 - 15:45 Tea & Coffee 15:45 - 17:15 Panel Discussion - "The Future of Broadband Switching Systems" 17:15 - 17:25 Workshop Closing WORKSHOP LOCATION ================= The workshop location is The Ritz Taipei Hotel, a member of The Leading Hotels of the World. As you might know, The Ritz is the best business hotel in Taipei. We have negotiated with them and obtained an excellent package for our BSS'97 participants. Its address is 41, Minchuan East Road, Section 2, Taipei, Taiwan, R.O.C. For more information about our BSS'97 hotel reservation, please contact Ms. Stephanie Wang, tel: +886 2 5985588, fax: +886 2 5863557, and e-mail: ritz@theritz-taipei.com http://www.theritz-taipei.com WORKSHOP REGISTRATION ===================== Please complete this registration form, and return with your payment to the address given below (Please copy this form for additional attendees). IEEE BSS'97 Registration Form ----------------------------- Last Name (Family/Surname): ______________________________________________ _____________________________________ [ ] Prof. [ ] Dr. [ ] Mr. [ ] Ms. First Name (Given Name): _________________________________________________ Name for Badge (if different from above): ________________________________ Company/Organization: ____________________________________________________ Address: _________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Telephone: _____________________________ Fax: ____________________________ E-mail address: __________________________________________________________ _________________________________________ Vegetarian Meals: [ ] Yes [ ] No For IEEE Member Registration rates, Member No.:___________________________ Workshop Registration Fee (On or before 16 November*): Fee Paid IEEE Member US$160 or NT$4,500 _____________ Non-IEEE Member US$190 or NT$5,400 _____________ IEEE Student Member US$60 or NT$1,500 _____________ Non-IEEE Student Member US$75 or NT$1,950 _____________ Workshop Registration Fee (After 16 November*): IEEE Member US$180 or NT$5,100 _____________ Non-IEEE Member US$210 or NT$6,000 _____________ IEEE Student Member US$70 or NT$1,800 _____________ Non-IEEE Student Member US$85 or NT$2,250 _____________ Tutorial Fee (On or before 16 November*): Tutorial 1 US$50 or NT$1,200 _____________ Tutorial 2 US$50 or NT$1,200 _____________ Tutorial 3 US$50 or NT$1,200 _____________ Tutorial Fee (After 16 November*): Tutorial 1 US$60 or NT$1,500 _____________ Tutorial 2 US$60 or NT$1,500 _____________ Tutorial 3 US$60 or NT$1,500 _____________ Extra Items Workshop Banquet US$60 or NT$1,500 _____________ Proceedings US$30 or NT$600 _____________ TOTAL: _____________ * It is postmarked. On Oct. 20, 1997, US$1 = NT$30.451 The workshop registration fee covers a copy of Proceedings, welcome reception, refreshments during the workshop, luncheon and the dinner banquet. Student rate attendees must have proper ID. The workshop registration fee for student member covers a copy of Proceedings, refreshments during the workshop, and luncheon. All payments can be in U.S. dollars or N.T. dollars. All checks or money orders must be payable to "Geng-Sheng Kuo" in order to make fast processing. Please send your registration form with payment to Prof. G.S. Kuo National Central University Chung-Li, Taiwan 32054 R.O.C. Tel: +886 3 4263086 Fax: +886 3 4262309 In addition, please e-mail one copy of your registration form to e-mail: gskuo@imrnet.mgt.ncu.edu.tw for record and quick response. HOTEL RESERVATION ================= The workshop hotel is The Ritz Taipei Hotel. All reservations should be made directly through the Rite Taipei Hotel by mailing, faxing, or e-mailing this Form. If you prefer to call, mention IEEE BSS'97 to get the workshop rate. Please make your reservations early. IEEE BSS'97 Hotel Reservation Form ---------------------------------- Last Name (Surname): _____________________________________________________ _____________________________________ [ ] Prof. [ ] Dr. [ ] Mr. [ ] Ms. First Name: ______________________________________________________________ Company/Organization: ____________________________________________________ Address: _________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Telephone: _____________________________ Fax: ____________________________ E-mail address: __________________________________________________________ Arrival Date: ______________________ Departure Date: _____________________ Special needs (please describe): _________________________________________ _________________________________________ Vegetarian Meals: [ ] Yes [ ] No ROOM RATE: NT$3,500 + 10% Service Charge per day. (On Oct. 20, 1997, US$1 = NT$30.451) MAIL, FAX, E-MAIL, OR PHONE RESERVATION TO: Address: The Ritz Taipei Hotel 41 Minchuan East Road, Section 2 Taipei, Taiwan, R.O.C. Tel: +886 2 597-1234 Fax: +886 2 596-9223 E-mail: ritz@theritz-taipei.com http://www.theritz-taipei.com HK toll free: 800 962606 Fax: 800 962607 USA toll free: 800 5176747 Fax: 800 5176662 Singapore toll free: 800 8861006 Fax: 800 8861007 FOR MORE INFORMATION ABOUT THE WORKSHOP ======================================= For more information about the Workshop, please contact Prof. G.S. Kuo Tel: +886 3 4263086 Fax: +886 3 4262309 e-mail: gskuo@imrnet.mgt.ncu.edu.tw -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Wed Oct 22 12:22:36 1997 From rem-conf-request@es.net Wed Oct 22 12:22:35 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xO68Z-0005yu-00; Wed, 22 Oct 1997 12:08:11 -0700 Date: Wed, 22 Oct 1997 12:07:09 -0700 () From: Stephen Casner To: Eric Fleischman cc: rem-conf@es.net Subject: RE: RTP payload format for ASF streams 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 On Tue, 21 Oct 1997, Eric Fleischman wrote: > The alternative to this approach which you seem to be advocating is to > define an endless series of "payload types" for each distinct payload > type instance. I view this requirement to be a total "show stopper" > because new payload types are continually being defined and implemented > -- and look at how much time is needed to register each of the payload > types which have been registered!! We need to keep two things distinct: - design and specification of a payload _format_, which involves determining what information, if any, beyond what is already present in the encoded data needs to be carried in the RTP data packets - assignment and registration of a static RTP payload _type_ number This second step need never happen because a dynamic payload type mapping can be used instead. In fact, I posed the question at the Munich AVT meeting whether all new payload formats should just use dynamic payload types rather than having static types assigned. We _should_ expect to be defining new RTP payload formats for years to come as encoding work continues. We need to broaden the pool of authors, especially that we hope encoding designers will consider this as part of the encoding design process. It seems the MPEG4 group believes this, which is encouraging. While there have been some payload formats that took way too long to get through the IETF process to become Proposed Standard RFCs, that was not really the problem. A particular example was H.261, but it was in use long before getting to RFC. In other cases, such as H.263, the delay had to do with resolving technical issues in the design of the payload format itself. There the snag we ran into was in making a static payload type assignment before the design process was finished. If the payload format were used with a dynamic type instead, and the binding of the dynamic type was specific to the particular revision of the draft, this snag would have been avoided. (There would still be interoperation issues between early applications and later ones unless the later ones implement backward compatibility, but there is no way around that problem other than waiting.) > The net effect of the current system > is that implementations are forced to either not use unregistered types > or else to use them in non-interoperable ways. Even if implementations > could register these many types, which implementation can keep track of > the various differences between them if they are all treated in such an > "ad hoc" fashion? So, we need a well-defined mapping between and dynamic payload type. I believe this should be done, for example, in the SDP file using the rtpmap and fmtp attributes. The exact design of this mapping needs to be worked out. It might involve the GUID mechanism used in ASF. But it is critical that this mapping information be the same for an Indeo (say) stream coming from an ASF file or a QuickTime file or an AVI file or ... Otherwise, we have the same non-interoperability problem that leads some of us to push back on the idea of an ASF payload format. > The combinatorics demonstrate (to my feeble brain, at > least) the unworkability of such an approach, especially if one assumes > (as I do) multimedia sessions with potentially large number of different > media streams. (Note: I wouldn't have such difficulty if I were merely > concerned with the media types currently used by conferencing > applications such as H.323 conferences.) Like Steve Deering said, one hopes that many of the potential variations are simply not used and that market selection will lead to a reasonable working set. > >> Since this is so, RTP's whole payload orientation breaks down > >> since what a dynamic payload type means is unknown to RTP and thus > >> payload-specific semantics becomes undesirable and tenuous, especially > >> for implementations of large number of different dynamic payloads (i.e., > >> it is much easier for implementations to handle a large number of > >> different dynamic payloads by treating them in a consistent, > >> payload-independent fashion). No, an RTP implementation definitely needs to be informed what the dynamic payload type means. Since the work require to process different payload formats will vary, and new ones will arise, it is a good idea to design the RTP implementation so that the payload format handling is a loadable module just like the codec itself is likely to be a loadable module. Installation of the loadable module needs to make use of the same indentification information that is used in the dynamic payload mapping (rtpmap and fmtp) so that the right loadable module can be found in a payload format independent way. There are such implementations in existence. > I am trying > to argue that generic extensibility capabilities are needed within RTP > so that these concepts can be addressed in a systematic and generic > (non-ad hoc) fashion. (My point being that just because the > fragmentation approaches for MPEG, JPEG, H.261, etc differ, does not > mean that clients and servers need to be aware of these differences as > RTP currently requires. Well, they must be aware to the extent that they can load the right code to handle the differences. > All that clients and servers need is a generic > approach to implement the payload-specific fragmentations which the > editing tool or live encoder device performs.) This is a matter of API, not protocol. Identification of the payload-specific fragmentations is a matter of protocol. > This will permit RTP to > be readily adaptable to support the scores of media types whose > semantics will be defined via out-of-band techniques without needing to > define a specific payload format for each one. This is only true to the extent that the scores of media types don't need any additional information to be efficiently and effectively packetized. The MPEG, JPEG, H.261 examples listed earlier are all different because each of those media types does need different specific information to be added. The only way to avoid that problem is to say that we will treat all of these media types in an opaque manner and accept the reduction in packetization effectiveness that results. I don't accept that. As new encodings are designed to be more packet-aware, then in fact it may not be necessary to add any information at the packetization step. Great! Then we don't need to define any additional header information, and the RTP payload format spec (which may be an appendix in the encoding spec) can simply consist of a couple of statements something like this: - This encoding is identified as with the following parameters , , - To packetize this protocol, put an integral number of chunks into one packet. > Other readers of this > list may perhaps view my previous sentence to be fantastic, but I expect > you to understand my point since you have already read the ASF spec > which explains one mechanism by which such variability can be coherently > expressed in a general format. No, I don't think this solves the problem. The H.261 payload format header information is not anywhere in the ASF file, and must be constructed based on how many H.261 macroblocks are put into each packet. > All that is lacking is a generic approach > to address specific packet information -- the topic of this thread. The only generic part is a fragmentation mechanism, but even that is not strictly necessary: as some others have said, the sequence number and M bit in RTP allow reassembling application data units (ADUs). Putting in a byte offset may simplify buffer management, but is not absolutely required. The fragmentation information can avoid a copy in buffer reassembly, but in many cases a copy is required anyway so the savings is not that important. As Henning said, knowing what piece of an ADU is missing is not useful because an ADU is by definition the minimal chunk that the encoding can process. We should avoid as much as possible the creation of an "easy way out" using generic formats that leads to opaque and inefficient packetization of media streams. Say the generic format exists and is implemented in some popular servers, and then a new encoding is defined. The designers of the new MPEG9 encoding go to the trouble of defining an RTP payload type optimized for that encoding, but the encoding can also be sent using the generic format. Will the servers ever learn the optimized payload format? Will receivers? Unlikely. Ergo, no new payload formats will be created. So, my position is that it is better to solve the problem of plugging in new packetization functions (we're all doing object-oriented programming now, right?) into the servers and clients. There are encodings for which no optimization may be possible, so there are just chunks of data that need to be sent. I think the chunks should be codec-specific ADUs (A=application not ASF) rather than file-format blocks, for example video frames. All such encodings might share the same payload header and in a sense this would be a "generic" payload format, but I think this generic format consists of no header at all or just a byte offset for fragmentation. A strong goal for me is to eliminate as much overhead in the data packets as possible, i.e., remove as much constant information from the headers as possible, which is done through indirection. If there is a generic payload header, a dynamic payload type can indicate that this payload header is present and further indicate what kind of encoding is carried inside. It is not necessary to put another PT field into that generic payload header. If you want to send several such encodings, you define several dynamic payload types, each of which indicates the presence of the generic payload header but with different contents. I believe some of the additional information in the proposed ASF format is not needed and should not be sent. If objects are ADUs, then there is no point in capturing part of one. As discussed above, some fragmentation info may assist reassembly, which suggests a fragmentation header (like that of the JPEG format), but even that is not absolutely required. As an example in this space, and please excuse the Windows-specific references to follow, we at Precept needed to send some Video for Windows format encodings, such as Indeo, for which no payload format exists and for which we don't have access to the information to design an optimized payload format. All we get is a frame of video data that we need to treat as opaque. So, we defined a private "WBIH" (Windows Bitmap Info Header) payload format in which each video frame is preceded by the WBIH header which is how the frames are exchanged in the VfW API. The header plus frame is one RTP ADU. Our WBIH payload format does not have any additional payload header; we simply use the standard RTP video payload format conventions (M bit and timestamp) in combination with chained buffers to reassemble ADUs according to the RTP sequence number. If any packet of a frame is lost, the whole frame must be tossed, but we can't do any better than that with the information that is available. For high data rate Indeo frames which are multiple Kbytes, the overhead of the 40-byte WBIH header is acceptable, but for lower data rates it is a waste. Since the information in the WBIH header is constant from frame to frame, it really should not be included in the data stream at all. We should have designed this payload format to communicate the necessary information out of band in the session description instead. More recently, we have a need to carry WAV format audio codecs. I believe the same philosophy should apply here. The constant information in the WAVEFORMAT header should be sent in the session description, bound to a dynamic payload type. Audio blocks are small enough that fragmentation should not be required, so no additional payload format header should be needed. If we do define a generic format, I suggest it may be better to define separate generic formats for audio, video, and perhaps other types of data. The M bit interpretation may be different, and there may be other optimizations. Several other problems I see with the ASF payload format proposal: - It includes the send time. As others have said, this does not need to be included in the packet except for the purpose of recreating the ASF file on the other end. I suggest two alternatives: use FTP to communicate the entire and intact ASF file; or, if you want to be able to create an ASF file when recording a real-time transmission, use the time of packet reception as the send time in the recording. If CBR is the goal, you can use a low-pass filter to smooth out network variations. It should be a goal to record an equally good ASF file at the receiver no matter whether the original transmission started from an ASF file or any other file or live capture. Also, the use of send time for the RTP timestamps seems badly broken to me. RTP interstream synchronization assumes the RTP timestamps are presentation times. [Actually, I question whether send time in the ASF file is really a useful notion. If constant BW is the goal, you can simply time the transmission of packets to meet that goal. If the goal is something else, how will one know at file creation time what timing will be appropriate at network transmission time?] - If ASF really is a file format and not an encoding format or wire protocol, then none of the additional ASF object information should be needed by the receiver to properly receive and play the media stream. Again, that media stream may be coming from live capture rather than an ASF file. So the Clean Point Flag should not be needed, and the statement "the ASF stream that is transmitted over RTP is useless to any receiver that does not have access to the Header Object" shouldn't be true. Now, since I advocate the use of dynamic payload types and out-of-band communication of the binding of that payload type, then yes, the stream is useless without the communication of the binding of the payload type. - It may be fine to multiplex multiple streams on one RTP session using multiple SSRC values, in particular for the case where audio from multiple conference participants has been recorded into an ASF file. But as has been discussed at length previously, audio and video RTP streams should not be multiplexed together this way. [The draft doesn't say either way.] - Variable-size headers should be avoided whenever possible in order to allow fast hardware implementations of high-speed streams. -- Steve --------------------------------------------------- > > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > > > >> Please follow my logic to see how I arrived at this conclusion: > >> * RTP is oriented to static RTP payload types -- an orientation > >> that will increasingly become obsolete over time. > > > >Wrong. > > > >> * RTP extensions were created "to allow individual > implementations > >> to experiment with new payload-format-independent functions" (see > first > >> paragraph of RTP 1889 section 5.3.1) -- though the standard also > >> discourages their use. Instead it encourages "additional information > >> required for a particular payload format should not use this header > >> extension, but should be carried in the payload section of this > packet" > >> (2nd paragraph of section 5.3.1). Ander's internet-draft proposes a > >> mechanism consistent with this directive. > > > >But it is not "a specific payload type". It's a file type. Specific > >payload types have very distinct needs. An HTML file might, for > example, > >want to break things at top-level element level, an H.261 file may need > >to convey GOB information for each fragment, etc. > > You are certainly correct in viewing it as being a file type since that > (unfortunately) is how it has been presented. However, this isn't how I > view it. I view it as a mechanism for consistently conveying specific > RTP packet information in a payload-independent fashion. [Note: we have > both previously agreed that the relevent media stream information has > already been conveyed by out-of-band means. Thus, this simply addresses > packet information such as fragmentation. Please note that fragmentation > occurs in a payload specific fashion in either case, but the approach > I'm arguing for doesn't require either the client or the server to be > aware of why the fragmentation occured at which specific point. It is > thus much easier to stream.] > what this means is that the payload format needs to be > > > >These two things have nothing to do with each other. You are arguing > >that the same mechanisms (such as fragmentation) apply to (almost) all > >payload types. Experience with a large number of common non-audio > >payload types has shown that not to be the case. Again, I refer you to > >the different solutions needed for MPEG, JPEG, H.261 and H.263. This > has > >nothing whatsoever to do with the fact that these payload types are > >static or not (or the desire to create extra work...). > -- Steve From rem-conf Wed Oct 22 13:04:03 1997 From rem-conf-request@es.net Wed Oct 22 13:04:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xO6yd-0006mN-00; Wed, 22 Oct 1997 13:01:59 -0700 Date: Wed, 22 Oct 1997 13:01:57 -0700 (PDT) From: "T. Todd Elvins" To: rem-conf@es.net Subject: Forum Reminder, Wednesday, Oct 22, 7pm (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This will be broadcast on the MBONE this evening. Todd ---------- Forwarded message ---------- Date: Tue, 21 Oct 1997 11:52:07 -0700 (PDT) From: "T. Todd Elvins" Subject: Forum Reminder, Wednesday, Oct 22, 7pm Date: October 22, 1997 Time: 7:00PM Place: SDSC Auditorium Mark Punak, Silver Stream, "Building 'Weblications' using Silver Stream's Web Application Platform" Mark will discuss teh development of web applications, or 'weblications', using the Web Applicaiton Platform of SilverStream Software. The presentation will be mostly technical in nature and should appeal to web developers. John Moreland, San Diego Supercomputer Center, "Overview of VRML 97" This presentation introduces participants to the latest version of VRML and describes the features, capabilities, and some applications of the language. The presentation includes numerous VRML examples and information on where to find more about VRML features and use. See our web page for details, parking info, directions, and information on how to see the mbone broadcast of this meeting. www.sdsc.edu/scwpf From rem-conf Thu Oct 23 11:55:23 1997 From rem-conf-request@es.net Thu Oct 23 11:55:23 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xOSBC-0000wI-00; Thu, 23 Oct 1997 11:40:22 -0700 Date: Thu, 23 Oct 1997 11:38:09 -0700 (PDT) From: Don Hoffman Reply-To: Don Hoffman Subject: Re: RTP payload format for ASF streams To: rem-conf@es.net In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: "Karl Auerbach" > > That said, I should point out that "encoding-specific packetization" is a > late-binding phenomenon. One can not safely anticipate the appropriate > data break-points/scribe-lines without knowing the network MTU. Thus, the > notion of pre-breaking encodings and putting the pre-broken data into a > file is unrealistic. > > --karl-- > In addition, different network infractructures have different loss charateristics. When running in a 10**(-6) loss environment (I think a properly designed satellite downlink with server at head-end would be of this sort), I can use a very simple packetization without much in the way of redundant encoding. When running across the Internet or a wireless IP network, loss rates are much higher and I might packetize in a more redundant manner. Don From rem-conf Thu Oct 23 11:55:24 1997 From rem-conf-request@es.net Thu Oct 23 11:55:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xOSKi-00011M-00; Thu, 23 Oct 1997 11:50:12 -0700 From: "Edward W. Knightly" Message-Id: <971023135008.ZM11989@qos.ece.rice.edu> Date: Thu, 23 Oct 1997 13:50:08 -0500 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: IWQoS 1998 CFP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Below is the CFP for IWQoS '98. The workshop's URL is http://www-ece.rice.edu/conf/iwqos98/ Best regards, -Ed Knightly http://www-ece.rice.edu/~knightly ________________________________________________ CALL FOR PAPERS Sixth IEEE International Workshop on Quality of Service (IWQoS '98) -Napa, California USA - May 18-20, 1998 Sponsored by IEEE* Communications Society Technical Committees on Computer Communications, Internet, Multimedia Communications, and Software In co-operation with ACM SIGCOMM and IFIP* ICODP/ICDP Joint Conference Patron: Hewlett Packard *to be approved ________________________________________________ WORKSHOP SCOPE -------------- This is the sixth in a series of workshops aimed at providing an international forum for the exchange of information on quality of service (QoS) research in distributed systems. The objective of the Sixth International Workshop on Quality of Service is to bring together researchers, developers, and practitioners working in all facets of QoS research addressing multimedia applications and services, programmability, operating systems, networking, multimedia devices and middleware. Contributions are solicited in all areas of QoS research in distributed systems and networking, including, but not limited to: - QoS Guarantees in an Integrated Services Internet - QoS Resource Allocation, Translation, (Re)negotiation, and Maintenance - QoS Programmability, Languages and Formal Method Techniques - Storage Systems/Database Support for QoS - QoS Performance Modeling, Analysis and Evaluation - Operating System Support for QoS - Adaptive Applications and Services - Middleware Solutions for End-to-End QoS - Media Scaling and QoS Filtering Techniques - QoS-based APIs for Applications, Transport and Management - QoS Support for Information Appliances - Video Coding/Compression Techniques and QoS - QoS-based Network Management and Control - End-to-End QoS Mechanisms and Architectures - QoS Support for Mobility and Wireless Networks - Experimental Studies on QoS - QoS Measurement and Prediction - Studies of End User's Perceptions of QoS IMPORTANT DATES --------------- * Submission of contribution: February 23, 1998 * Notification of acceptance: April 6, 1998 * Camera-ready paper due: April 13, 1998 Program Co-Chairs: ------------------ Ed Knightly, Rice University Rich Friedrich, Hewlett Packard Laboratories Program Committee: ------------------ Gordon Blair, University of Lancaster, UK Andrew Campbell, Columbia University, USA Simon Crosby, Cambridge University, UK Jon Crowcroft, UCL, UK Hermann de Meer, University of Hamburg, Germany Jan de Meer, GMD Fokus, Germany Alexandros Eleftheriadis, Columbia University, USA Domenico Ferrari, Universita' Cattolica Piacenza, Italy Leonard Franken, KPN Research, The Netherlands Michael Fry, University of Technology, Australia Jean-Peirre Hubaux, EPFL, Switzerland Brigitte Kerherve, University of Quebec at Montreal, Canada Glenford Mapp, Olivetti Research Ltd, UK Mahmoud Nagshineh, IBM Thomas J. Watson Research Center, USA Klara Nahrstedt, University of Illinois at Urbana Champaign, USA Max Ott, C&C Research, NEC USA Guru Parulkar, Washington University, USA Steve Pink, Lulea University of Technology, Sweden Jerry Rolia, Carleton University, Canada Douglas Schmidt, Washington University, USA Chris Sluman, OpenIT Ltd, UK Cormac Sreenan, AT&T Research, USA Hideyuki Tokuda, Keio University, Japan Bharghavan Vanduvur, University of Illinois at Urbana Champaign, USA James VanLoo, Sun Microsystems, USA Andreas Vogel, DSTC, Australia Lixia Zhang, University of California, Los Angeles, USA Hui Zhang, Carnegie Mellon University, USA From rem-conf Thu Oct 23 18:06:43 1997 From rem-conf-request@es.net Thu Oct 23 18:06:43 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xOY7y-0004ln-00; Thu, 23 Oct 1997 18:01:26 -0700 Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender slwang@jdl.mcel.mot.com ) Message-Id: <344FF33A.99BAB76E@jdl.mcel.mot.com> Date: Fri, 24 Oct 1997 09:00:42 +0800 From: "Wang, Shuanglin" Reply-To: slwang@jdl.mcel.mot.com Organization: MOT-NCIC JDL X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 To: rem-conf@es.net Subject: (no subject) 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 From rem-conf Thu Oct 23 20:37:19 1997 From rem-conf-request@es.net Thu Oct 23 20:37:19 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xOaU1-00060d-00; Thu, 23 Oct 1997 20:32:21 -0700 Date: Thu, 23 Oct 1997 21:31:17 -0600 (MDT) From: Evi Nemeth Message-Id: <199710240331.VAA03946@rupertsberg.cs.colorado.edu> To: rem-conf@es.net Subject: usenix lisa conference Cc: evi@rupertsberg.cs.colorado.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list the usenix lisa conference, october 29-31, will be broadcast on the mbone. the broadcast will cover a mix of technical papers and invited talks and will run from 9am-5:30pm pacific daylight time (utc+8). -evi From rem-conf Sun Oct 26 10:09:39 1997 From rem-conf-request@es.net Sun Oct 26 10:09:38 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPWpe-0001kT-00; Sun, 26 Oct 1997 09:50:34 -0800 From: "Ephraim P. Glinert" Date: Sun, 26 Oct 1997 12:50:20 -0500 (EST) Message-Id: <199710261750.MAA00322@avs.cs.rpi.edu> To: end2end-interest@isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: ACM MM97 and ASSETS98 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues: Please take a moment to read this short message, in which I'd like to draw your attention to two upcoming important conferences you won't want to miss. o ACM MULTIMEDIA'97 will take place November 9-13 in Seattle. The 40 technical papers in the truly outstanding program cover all aspects of multimedia technology and systems, so no matter what your specialty you'll surely find much of interest here! Two great keynote talks by Brad Myers of CMU and Ben Shneiderman of the University of Maryland, and a reception at the Seattle Space Needle, will be highlights of the conference. And yes, YOU -CAN- AFFORD TO COME, even at this late date, because we've arranged incredibly cheap coast-to-coast zone fares with USAir which -DO NOT- require a Saturday night stay or way-in-advance purchase. For full details, check out the superb conference web site: http://www.acm.org/sigmm/MM97 If you have any questions, please feel free to contact me personally as General Co-Chair. o ASSETS'98, the 3rd ACM/SIGCAPH Conference on Assistive Technologies, will take place April 15-17, 1998 at the Marina del Rey Hotel in Los Angeles (back-to-back with CHI'98). This is the premier international forum where researchers and developers from academia and industry meet to exchange ideas and report on new developments relating to computer-based systems to help people. The conference scope spans disabilities and special needs of ALL types; there are no parallel sessions, in order to encourage total group participation throughout the meeting (even meals are taken together). THERE IS STILL TIME TO SUBMIT a paper or to volunteer to participate in other ways - the deadline is November 14, 1997. For complete details, please see the conference web site: http://www.acm.org/sigcaph/assets Or contact one of the lead organizers: General Chair: Arthur I. Karshmer (e-mail: arthur@cs.nmsu.edu) Program Chair: Meera M. Blattner (e-mail: blattner@llnl.gov) I hope to see you at one or both of these great events. Thank you! -Ephraim From rem-conf Sun Oct 26 11:27:10 1997 From rem-conf-request@es.net Sun Oct 26 11:27:09 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPYAC-0002YJ-00; Sun, 26 Oct 1997 11:15:52 -0800 Sender: hgs@cs.columbia.edu Message-ID: <345396DF.F02D5C7B@cs.columbia.edu> Date: Sun, 26 Oct 1997 14:15:43 -0500 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: rem-conf@es.net Subject: Conversion RTP DVI to/from WAV DVI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Anybody happen to have (source) code for the conversion from DVI as defined in the RTP profile and that defined in the WAV DVI files? (The headers and sample order within a byte are slightly different.) Thanks. From rem-conf Sun Oct 26 13:36:06 1997 From rem-conf-request@es.net Sun Oct 26 13:36:05 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPaEG-0003gy-00; Sun, 26 Oct 1997 13:28:12 -0800 Message-Id: From: eep6as@ee.surrey.ac.uk (Abdul Sadka) Subject: VICVAT problem To: rem-conf@es.net Date: Sun, 26 Oct 1997 21:27:52 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 636 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I installed vicvat on windows95 but each time I try to run vic.exe or vat.exe I am faced with a message : tcl runtime error ! Anyone has run through that before ? What do you think this might be due to ? Any pointer is appreciated. -- _________________________________________ Dr Abdul H. Sadka (Lecturer) | Multimedia Communications Research Group | Centre for Communication Systems Research| Uni. of Surrey, GU2 5XH, Surrey, England | Tel: +44 (01483) 259490 | Fax: +44 (01483) 259504 | WWW: www.ee.surrey.ac.uk/CCSR/Multimedia | _________________________________________| From rem-conf Sun Oct 26 22:52:24 1997 From rem-conf-request@es.net Sun Oct 26 22:52:23 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPiwP-0000S2-00; Sun, 26 Oct 1997 22:46:21 -0800 Date: Mon, 27 Oct 1997 07:44:35 +0100 (MET) From: Christoph Fleck X-Sender: fleck@rncmm1 Reply-To: Referenzzentrum fuer multimediale Teledienste To: Abdul Sadka cc: rem-conf@es.net Subject: Re: VICVAT problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Abdul, On Sun, 26 Oct 1997, Abdul Sadka wrote: > Dear all, > > I installed vicvat on windows95 but each time I try to run vic.exe > or vat.exe I am faced with a message : tcl runtime error ! Anyone > has run through that before ? What do you think this might be due > to ? If You cancel the Username Dialog Window (or you have not one at start time) the tolls dont know your name and break. Then you have to set the enviroment: On Thu, 25 Sep 1997, Justin wrote: > TIPS: > > Also, sometimes you have to add this: > SET USER=username > because some installed Windows don't have the user entered. > > On Wed, 24 Sep 1997, Mick Russell wrote: > > > Set the Path and home directories to the location of the mbone tools in > > autoexec.bat i.e. > > > > SET PATH=C:\MBONE;C:\WINDOWS;C:\WINDOWS\COMMAND > > SET HOME=C:\MBONE > > >From: Frank P. Troy[SMTP:ftroy@ISI.EDU] > > >Can anyone please tell me what I need to modify in windows 95 so sdr > > >can find vic and vat? I keep getting the "no sutable XX tool > > >installed" error. rgds Christoph Fleck ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck, Rainer Kranz | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Mon Oct 27 10:20:04 1997 From rem-conf-request@es.net Mon Oct 27 10:20:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPtO0-0004b6-00; Mon, 27 Oct 1997 09:55:32 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 27 Oct 1997 09:55:00 -0800 (PST) Message-Id: <199710271755.JAA15526@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Annotating the Web X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Annotating the Web Date: Nov 19, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w13.html Description: Thomas A. Phelps Computer Science Division - EECS U.C. Berkeley Paper is still preferred to digital document systems for tasks involving annotating, folding, juxtaposing or otherwise treating the document as a tactile object. Based on the Multivalent Documents model, Multivalent annotations brings to the Web a distributed annotation system with extensive capability to manipulate documents. The individual can use it to customize one's information space, the professor can use it to mark up student papers without the need to print them out, and a distributed community can use it to maintain a set of commentaries on a seminal paper. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Oct 27 11:29:56 1997 From rem-conf-request@es.net Mon Oct 27 11:29:56 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPuj6-0005WU-00; Mon, 27 Oct 1997 11:21:24 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Mon, 27 Oct 1997 11:20:59 -0800 (PST) Message-Id: <199710271920.LAA15560@hille.msri.org> To: rem-conf@es.net From: Reply-to: hgs@cs.columbia.edu Subject: Globecom/Global Internet'97 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Globecom/Global Internet'97 Date: Nov 05, 1997 Time: 09:00 CST6CDT 9 hours Contact: hgs@cs.columbia.edu URL: http://www.cs.columbia.edu/~hgs/InternetTC/GlobalInternet97/ Description: The Globecom'97 keynote address by Kevin Kahn, Intel Architecture Labs and the Global Internet'97 paper sessions and keynote by Steve Pink. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Mon Oct 27 12:01:06 1997 From rem-conf-request@es.net Mon Oct 27 12:01:05 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPvIQ-0006Az-00; Mon, 27 Oct 1997 11:57:54 -0800 Date: Mon, 27 Oct 1997 13:54:33 -0600 From: laurent@havefun.ncsa.uiuc.edu Message-Id: <199710271954.NAA25326@havefun.ncsa.uiuc.edu.> To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FedWeb'97 IS HERE! October 27-31, 1997 The World Wide Web Federal Consortium is sponsoring its annual Federal Webmaster's Workshop designed specifically for federal employees. The theme of this year's conference is "Collaboration: Working together to build a web-based government that works!" In response to suggestions made by last year's workshop participants, FedWeb has been expanded, and the '97 workshop will run for five days, running from Monday October 27 through Friday October 31. The workshop is being held at the Natcher Center at the National Institutes of Health in Bethesda, Maryland. During the Workshop, a team from the National Center for Supercomputing Applications at the University of Illinois will be multicasting from the Natcher Center. The multicast will consist of one session containing audio, video, and a whiteboard. The multicasts will be transmitted from 9:00 AM to 5:00 PM on Tuesday through and Thursday, October 28 through October 30. The agenda is available at http://www.excelgov.org/wm97/mbone/mboneschedule.html From rem-conf Mon Oct 27 13:21:15 1997 From rem-conf-request@es.net Mon Oct 27 13:21:15 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xPwVN-00075p-00; Mon, 27 Oct 1997 13:15:21 -0800 Message-ID: <19971027131510.12181@nlanr.net> Date: Mon, 27 Oct 1997 13:15:10 -0800 From: k claffy To: rem-conf@es.net, nanog@merit.edu Subject: LATE NOTICE: NANOG MBONE BROADCAST SET UP AND NOW BEING BROADCAST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64e X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list sorry folks, we know nanog announced last week it would be able to make it, but thanks to the noble dedication of Jeff Rizzo from Digital Internet Exchange and Rodney Joffe at Genuity (NANOG host this time) (and of course to the vivid complaints >from those nanog devotees that couldn't be here in person) we've got Mbone broadcasting of nanog as of 5 minutes ago -- audio and video, and i'll set up a whiteboard for feedback now -- (early reports indicate that audio is 'uh, about as good as usual') fwiw k From rem-conf Tue Oct 28 01:52:47 1997 From rem-conf-request@es.net Tue Oct 28 01:52:46 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8H5-0003eg-00; Tue, 28 Oct 1997 01:49:23 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 01:49:10 -0800 (PST) Message-Id: <199710280949.BAA15944@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 1) Date: Nov 26, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Bas mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 01:52:58 1997 From rem-conf-request@es.net Tue Oct 28 01:52:57 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8G8-0003e2-00; Tue, 28 Oct 1997 01:48:24 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 01:48:01 -0800 (PST) Message-Id: <199710280948.BAA15914@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 1) Date: Nov 25, 1997 Time: 10:00 Greenwich 8 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Basque Studies Society XIV Congress intends to reflection on the information society concept ans its impact on four different areas. This session will introduce the congress topic through some philosophical reflections on the information society concept, and will show the active policies carried out by institutions and especially relevat companies in our country. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 01:53:58 1997 From rem-conf-request@es.net Tue Oct 28 01:53:57 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8Kz-0003kD-00; Tue, 28 Oct 1997 01:53:25 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 01:52:57 -0800 (PST) Message-Id: <199710280952.BAA15974@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 1) Date: Nov 26, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Basque Studies Society XIV Congress intends to reflection on the information society concept ans its impact on four different areas. This session will be held in Bilbao and will introduce the impact of the information society on the mass media. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 02:03:02 1997 From rem-conf-request@es.net Tue Oct 28 02:03:02 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8Sm-0004Tl-00; Tue, 28 Oct 1997 02:01:28 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 02:00:32 -0800 (PST) Message-Id: <199710281000.CAA16004@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 1) Date: Nov 27, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Bas mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 02:03:05 1997 From rem-conf-request@es.net Tue Oct 28 02:03:05 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8Sl-0004TY-00; Tue, 28 Oct 1997 02:01:27 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 02:00:57 -0800 (PST) Message-Id: <199710281000.CAA16034@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 1) Date: Nov 27, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Basque Studies Society XIV Congress intends to reflection on the information society concept ans its impact on four different areas. This session will be held in Bilbao and will introduce the impact of the information society on the services for the citizens and the companies. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 02:05:00 1997 From rem-conf-request@es.net Tue Oct 28 02:05:00 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8Vn-0004wx-00; Tue, 28 Oct 1997 02:04:35 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 02:03:49 -0800 (PST) Message-Id: <199710281003.CAA16064@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 2) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 2) Date: Nov 26, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Basque Studies Society XIV Congress intends to reflection on the information society concept ans its impact on four different areas. This session will be held in Pamplona and will introduce the impact of the information society on the work at the companies, the administration and the liberal professions. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Tue Oct 28 02:06:05 1997 From rem-conf-request@es.net Tue Oct 28 02:06:05 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQ8Wp-00057z-00; Tue, 28 Oct 1997 02:05:39 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 28 Oct 1997 02:05:06 -0800 (PST) Message-Id: <199710281005.CAA16094@hille.msri.org> To: rem-conf@es.net From: Reply-to: sixvideo@si.ehu.es Subject: Basque Studies Society XIV Congress (Room 2) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Basque Studies Society XIV Congress (Room 2) Date: Nov 27, 1997 Time: 09:30 Greenwich 10 hours Contact: sixvideo@si.ehu.es URL: http://suse00.su.ehu.es Description: The Basque Studies Society XIV Congress intends to reflection on the information society concept ans its impact on four different areas. This session will be held in Vitoria and will introduce the impact of the information society on the education (pre-university, university and post graduate). mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Oct 29 08:20:23 1997 From rem-conf-request@es.net Wed Oct 29 08:20:23 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQaUB-0007UY-00; Wed, 29 Oct 1997 07:56:47 -0800 From: Toerless Eckert Message-Id: <199710291556.QAA25779@faui45r.informatik.uni-erlangen.de> Subject: vat_play_audio mit RTP ? To: rem-conf@es.net Date: Wed, 29 Oct 1997 16:56:38 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL35 (25)] 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 Hi Is there a program that fullfills the task of what "vat_play_audio" did, but for RTP compliant audio ? Thanks Toerless From rem-conf Wed Oct 29 12:08:22 1997 From rem-conf-request@es.net Wed Oct 29 12:08:21 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQeGR-0001cE-00; Wed, 29 Oct 1997 11:58:51 -0800 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 29 Oct 1997 11:58:44 -0800 (PST) Message-Id: <199710291958.LAA16915@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Indexing the Content of Multimedia Documents X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Indexing the Content of Multimedia Documents Date: Dec 03, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w15.html Description: Stephen W. Smoliar and Lynn D. Wilcox, FX Palo Alto Laboratory As the concept of what constitutes a "content-based" search grows more mature, it becomes valuable for us to establish a clear sense of just what is meant by "content." mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Oct 30 02:16:16 1997 From rem-conf-request@es.net Thu Oct 30 02:16:13 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xQrV7-0005GT-00; Thu, 30 Oct 1997 02:06:53 -0800 Message-ID: <34585CF2.77212ECF@hosim.kwangjuac.kr> Date: Thu, 30 Oct 1997 19:09:54 +0900 From: kim gwang hyun Reply-To: ghkim@hosim.kwangju.ac.kr X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) 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 subcsribe rem-conf@es.net