From rem-conf-request@es.net Tue Mar 01 11:01:44 1994 Received: from philabs.philips.com by osi-west.es.net via ESnet SMTP service id <03561-0@osi-west.es.net>; Tue, 1 Mar 1994 08:01:11 +0000 Received: from mars.Philabs.Philips.Com by philabs.Philips.COM (smail2.5/12-15-87/4.1) id AA13543; Tue, 1 Mar 94 11:01:08 EST Received: by mars.Philabs.Philips.Com (4.1/SMI-4.1) id AA03907; Tue, 1 Mar 94 11:01:06 EST Date: Tue, 1 Mar 94 11:01:06 EST From: jec@philabs.Philips.COM (Jorge E. Caviedes) Message-Id: <9403011601.AA03907@mars.Philabs.Philips.Com> To: rem-conf@es.net Subject: nv on secure networks Cc: jec@mars Hi all, Thanks to those who replied to my first message asking for info on how to get started. There is an issue on which I would like to get some ideas. Talking to our system administrator about access to the MBONE, he says that probably we need to run similarly to the other internet applications we have (e.g. with the restrictions of a firewall). We run mosaic, ftp, telnet using "socksified" versions to protect the local system. This means that a demon on the firewall machine is the intermediary between our local machines and the internet, IPforward is turned off and thus none here talks directly to Internet. The question is under this conditions is it possible still to have access to the MBONE and run nv? thanks a bunch, Jorge Caviedes Philips Labs From rem-conf-request@es.net Tue Mar 01 13:14:57 1994 Received: from win70.nas.nasa.gov by osi-west.es.net via ESnet SMTP service id <05420-0@osi-west.es.net>; Tue, 1 Mar 1994 10:14:26 +0000 Received: by win70.nas.nasa.gov (5.67-NAS.6/NAS.3-sgi) id AA16157; Tue, 1 Mar 94 10:14:18 -0800 Date: Tue, 1 Mar 94 10:14:18 -0800 From: sma@nas.nasa.gov (Steve M. Acheson) Message-Id: <9403011814.AA16157@win70.nas.nasa.gov> To: jec@philabs.Philips.COM (Jorge E. Caviedes) Subject: Re: nv on secure networks Cc: rem-conf@es.net Reply-To: sma@nas.nasa.gov >Talking to our system administrator about access to the MBONE, he says that >probably we need to run similarly to the other internet applications we >have (e.g. with the restrictions of a firewall). This is reasonable, although not necessary as the tunnel from your site and the MBONE could run on the firewall machine if it is a dual homed gateway, which it sounds like. >We run mosaic, ftp, telnet using "socksified" versions to protect the >local system. This means that a demon on the firewall machine is the >intermediary between our local machines and the internet, IPforward is >turned off and thus none here talks directly to Internet. The question >is under this conditions is it possible still to have access to the MBONE >and run nv? Sure, you only need to configure the mrouted to be socksified, ie replace all of the connect and select [...] routines with the corresponding Rconnect and Rselect version. This should allow a host on the inside of your firewall to establish a tunnel with the MBONE and still have your security intact. The security probably isn't necessary as the tunnel is established with a single host external to your net, and it is an TCP connection port to port on the two hosts. This would be very difficult to exploit (never say impossible) and almost as pointless. But the answer to your question is as above, yes. Steve ====================================================== Steve Acheson (415) 604-6555 Sterling Software sma@nas.nasa.gov NASA Ames Moffett Field, Ca 94035-1000 From rem-conf-request@es.net Tue Mar 01 20:53:22 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <11486-0@osi-west.es.net>; Tue, 1 Mar 1994 17:52:57 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23045; Tue, 1 Mar 94 17:52:54 PST Received: from icestation.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14866; Tue, 1 Mar 94 17:51:54 PST Received: by icestation.Eng.Sun.COM (5.0/SMI-SVR4) id AA22153; Tue, 1 Mar 1994 17:51:47 +0800 Date: Tue, 1 Mar 1994 17:51:47 +0800 From: Michael.Bundschuh@Eng.Sun.COM (Mike Bundschuh) Message-Id: <9403020151.AA22153@icestation.Eng.Sun.COM> To: rem-conf@es.net Subject: vat for bsdi? (SoundBlaster support) X-Sun-Charset: US-ASCII Content-Length: 502 Here's a quick question. In the CHANGES file, the following comment is made regarding soundblaster cards: "- Change audio device model to support totally braindead, half-duplex PC audio cards (like SoundBlaster)." Is there a version of vat that can run on bsdi and half-duplex cards like the soundblaster? Thanks, ____________________________________________________ Michael Bundschuh michael.bundschuh@sun.com Audio Software Engineer, SunSolutions From rem-conf-request@es.net Wed Mar 02 09:19:44 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <15457-0@osi-west.es.net>; Wed, 2 Mar 1994 06:19:17 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA18193; Wed, 2 Mar 94 06:19:56 -0800 Message-Id: <9403021419.AA18193@rx7.ee.lbl.gov> To: Michael.Bundschuh@eng.sun.com (Mike Bundschuh) Cc: rem-conf@es.net Subject: Re: vat for bsdi? (SoundBlaster support) In-Reply-To: Your message of Tue, 01 Mar 94 17:51:47 U. Date: Wed, 02 Mar 94 06:19:55 PST From: Van Jacobson Yes, ftp.ee.lbl.gov:conferencing/vat/i386-vat.tar.Z runs on bsdi/netbsd/freebsd/etc. and will work with a SoundBlaster (which is a horrible piece of junk that should be avoided) or a PAS-16 (which is less bad than a SoundBlaster). I'm not sure if BSDI is shipping Steve McCanne's SoundBlaster driver yet. If not, it's available on ftp.ee.lbl.gov: bsd386-sb-0.2a.tar.Z. - Van From rem-conf-request@es.net Thu Mar 03 10:01:05 1994 Received: from nautilus.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <29587-0@osi-west.es.net>; Thu, 3 Mar 1994 07:00:22 +0000 Received: by nautilus.gsfc.nasa.gov (931110.SGI/931108.SGI.AUTO.ANONFTP) for rem-conf@es.net id AA09017; Thu, 3 Mar 94 10:02:22 -0500 From: Paul Smith Message-Id: <9403031002.ZM9015@nautilus.gsfc.nasa.gov> Date: Thu, 3 Mar 1994 10:02:11 -0500 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: rem-conf@es.net Subject: Problem: multicast tunnel to Belize Cc: jason@fagaloa.twc.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Greetings to all! Has anyone multicast through a satellite link? I'm in need of some sage advice. We are attempting a multicast tunnel from Greenbelt, Maryland USA to the rainforest in Belize as part of the 1994 Jason Project. For those of you not familiar with the project, try the following page reference in Mosaic or other WWW client: http://seawifs.gsfc.nasa.gov/JASON/JASON.html The major problem we are having is connectivity. While we have been able to establish normal TCP/IP links (ping, telnet, ftp) from Belize to Maryland, I am unable to do the reverse (only ping works). The link is through a satellite, and pings from MD to Belize reports an average trip time of 750 ms. As you might guess, the multicast tunnel won't work either. I've tried contacting the service provider that is handling the satellite, but haven't gotten a response. The timeframe for getting the tunnel going has come and gone, so they need it ASAP. The current configuration follows: Maryland mrouter: SGI 440 running IRIX 4.0.5c with IP encapsulation patches applied to mrouted. This node is already supporting a tunnel to Miami, and has another tunnel coming in. IP: 128.183.121.16 mrouted.conf entry: tunnel 128.183.121.16 151.142.33.20 metric 30 threshold 128 Belize mrouter: SGI Indigo2 running IRIX 5.1 (has the IP encapsulation built in) IP: 151.142.33.20 mrouted.conf entry tunnel 151.142.33.20 128.183.121.16 metric 1 threshold 128 I've run the mrouted at the Maryland end - it definitely is trying to reach the Belize end. I've tried playing with the metric at my end to see if that helps (which is why it is at 30). I've run traceroutes - the Belize end is about 17 hops. I think I may be hitting a wall somewhere in the satellite provider's setup that is blocking higher level TCP/IP utilities from getting through, but I can't be certain. If anyone has an idea, workaround, or sympathy, it is most welcome! Thank you. -- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ |Paul F. Smith - General Sciences Corporation | |Systems Manager - SeaWiFS Project voice: (301) 286-2852 | |NASA/Goddard Space Flight Center fax: (301) 286-1775 | |Code 970.2 | |Greenbelt, Maryland 20771 e-mail: Paul.F.Smith.1@gsfc.nasa.gov | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ From rem-conf-request@es.net Thu Mar 03 11:32:25 1994 Received: from pussy.inria.fr by osi-west.es.net via ESnet SMTP service id <00662-0@osi-west.es.net>; Thu, 3 Mar 1994 08:30:49 +0000 Received: by pussy.inria.fr (5.65c8/IDA-1.2.8) id AA17246; Thu, 3 Mar 1994 17:32:41 +0100 Message-Id: <199403031632.AA17246@pussy.inria.fr> To: end2end-interest@ISI.EDU, f-troup@AURORA.CIS.UPENN.EDU, icad-request@santafe.edu, icad@santafe.edu, ietf@ISI.EDU, ir-l@uccvma.bitnet, rem-conf-request@es.net, rem-conf@es.net, sigmedia@bellcore.com, sound@acm.org, tccc@cs.umass.edu Date: Thu, 03 Mar 1994 17:32:41 +0100 From: Christophe Diot Subject: High Performance Networking (HPN) '94 program --------- 5 th International IFIP Conference On HIGH PERFORMANCE NETWORKING ADVANCED PROGRAM June 27 - July 1, 1994 Museum of Art, Grenoble (France) organized by the IMAG Institute (Grenoble) and the MASI Laboratory (Paris) ================================================================= General Chairman Guy Pujolle (PRiSM, Versailles, F) Program Chairman Serge Fdida (MASI, Paris, F) Program Committee Daniel Abensour (IBM Res. Div. Cary, USA) Andres Albanese (ICSI, USA) Patrick Baker (HP Labs Bristol, UK) Augusto Casaca (IST-INESC, P) Greg Chesson (SGI, USA) Andre Danthine (Univ. de Liege, B) Michel Diaz (LAAS, F) Christophe Diot (INRIA Sophia Antipolis, F) Zygmunt Haas (AT&T Bell Labs, USA) Marjory Johnson (RIACS, USA) Hanafy Meleis (DEC, USA) Gerard Michel (IMAG, Grenoble, F) Craig Partridge (BBN, USA) Radu Popescu-Zeletin (GMD FOKUS, D) Otto Spaniol (Tech. Univ. Aachen, D) Samir Tohmé (ENST, F) Harmen Van As (IBM Zurich, CH) Giorgio Ventre (Univ. di Napoli, I) Martina Zitterbart (Univ. Karlsruhe, D) Organization Co-Chairmen Jean-Pierre Verjus (IMAG, Grenoble F) Christophe Diot (INRIA Sophia Antipolis, F) Foreword This workshop belongs to the serie started in 1987 in Aachen, followed by Liege in 1988, Berlin in 1991 and Liege in 1992. HPN '94 is the fifth event of this serie sponsored by IFIP WG 6.4. It aims at beeing an international forum where researcher coming from industry and universities present and discuss evolution in the framework of high-speed networking and computing in private and public environments. The conference targeted new mechanisms, protocols, services and architectures derived from the need of emerging distributed multimedia appli cations, as well as from the requirements of the new communication environment. Eighty papers were received from 23 countries. The program committee, helped by more than hundred reviewers, selected 28 papers. Two well known invited speakers will complete the conference program. The first two days of the workshop are dedicated to one day tutorial sessions. The topics covered in these tutorials have been selected to provide very informative presentations from experts in the field covered by HPN '94. The conference is organized by the IMAG (Grenoble) Institute and the MASI Laboratory (Paris). It will be held in Grenoble, which is located at hundred kilometers south of Lyon and hundred and fifty kilometers from Geneva. Grenoble is the heart of the French Alps. Following the 1968 Olympic games, Grenoble developed a high technology R&D park around one of the most famous French Universities. The technical sessions will be organized in the new museum of art of Grenoble. This museum, that opened its doors in january 1994, exhibits the most famous paintings and sculptures collection in France, out of Paris. Grenoble, with its sport, culture, and academic environment is definetely the ideal place to host an international event on advanced networking. ================================================================== Tutorial A Host Interface Design for High Speed Networks by Bruce Davie (Bellcore-USA) Monday 27 June 1994 ; 09:00 to 17:00 With the advent of gigabit per second networks, it has become apparent that the interface between host computers and the network is a potential bottleneck in the effort to achieve high application-to-application performance. This tutorial will focus on the issues that must be considered when designing a host interface in order to deliver as much as possible of the network bandwidth to workstation hosts. Aspects of the problem covered include: - the partitioning of functionality between the host and the interface, and between hardware and software; - the impact of workstation architecture, including the memory and bus architectures, on the problem of building a high-performance interface; - the close relationship between host software, such as protocols and operating systems, and interface design. The tutorial will make extensive use of examples from real implementations, including the speaker's own work with interfaces to ATM networks, as well as several other interfaces (the CMU CAB, Kanakia's NAB, Jacobsen's WITLESS, and others). Bruce S. Davie is the Director of the Internetworking Research Group at Bell Communications Research (Bellcore) in Morristown, New Jersey. He has worked on performance analysis of packet-switched networks and is currently engaged in research on host-network interface architectures and protocols for gigabit networks. Since 1990 he has been a project manager for the Aurora gigabit testbed. He has authored numerous papers on host interface issues, designed and implemented the `Osiris' 622 Mbit/sec ATM host interface, and was a guest editor of the IEEE Journal of Selected Areas of Communications issue on host interfacing. =============================================================== Tutorial B Multimedia in Operating and Communication Systems by Ralf Steinmetz and Ralf Guido Herrtwich (IBM Heidelberg-D) Monday 27 June 1994 ; 09:00 to 17:00 Multimedia means audio and video in computing and communications; a multimedia system is characterized by the integrated computer-controlled generation, manipulation, presentation, storage, and communication of independent discrete (such as text and images) and continuous media (such as audio and video). This tutorial presents the key issues of multimedia systems concerning the user demands and the derived implementations with respect to operating and communication systems. Aspect of the problem covered include : - Introduction to multimedia: user requirements and constraints; real-time; survey of existing environments. - Resource management: phases, local. - Operating systems: scheduling, file systems. - Communication systems: exploitation of networks for multimedia data transfer. - Synchronization: media correlation examples, user requirements, non trivial synchronization, integration. This tutorial provides computer and communication experts with an overall view of what is multimedia today and where the main challenges in contrast to conventional computing arise. After a year at the ICSI-UCB, Dr. Ralf Guido Herrtwich, joined the IBM European Networking Center in Heidelberg in 1990. As manager of the Distributed Multimedia Solutions Department, his main area of work still are networked multimedia systems. He is in charge of the development of a distributed multimedia environment for IBM's RS/6000 and PS/2 platforms. Dr. Ralf Steinmetz is working at the IBM European Networking Center (ENC) in Heidelberg since 1988. There he has been involved in various multimedia communication activities. He was the leader of the OS/2 multimedia transport system development and subsequently was in charge of several application projects and the respective application support issues. Now he leads the Multimedia Information Systems group at the ENC. =============================================================================== Tutorial C LOTOS-Based Protocol Engineering by Guy Leduc (University of Liège-B) Tuesday 28 June 1994 ; 09:00 to 17:00 LOTOS is an ISO formal description technique (IS 8807) for the design of distributed systems. LOTOS is based on a sound mathematical model that has allowed the development of suitable methods and software tools to support specification, simulation, verification, refinement, implementation and conformance testing of communication systems. This course will survey the state-of-the-art in LOTOS-based design from a practical viewpoint. The presen tation of some underlying mathematical theories will be reduced to the minimal concepts necessary to understand. The emphasis is put on the principles, methods and existing tools. Aspects of the problem covered include: - Presentation of a generic design process based on formal description techniques (FDTs). - Clear definitions of several architectural concepts. - Tutorial on LOTOS: presentation of basic features. - Specification of systems using LOTOS: specification styles, methods, existing tool support, real size case-studies - Simulation of LOTOS specifications: general principles, goal-driven simula tion, existing tools. - Verification of LOTOS specifications: general principles, automatic genera tion of a model, verification of behavioural equivalences, diagnostics generation. - Implementation of LOTOS specifications: general principles, codenb generation, existing tools - Conformance test suite generation : general principles, test suite generation, existing tools. Examples of industrial applications will be mentioned and some real case studies (e.g. from the ESPRIT/OSI95 project) will be used as illustration. Guy Leduc is working for the Belgian National Fund for Scientific Research (F. N.R.S.) at the University of Liège. Since 1990 he is a Research Associate. His activities and research interests include formal description techniques (FDTs) and data communication networks. Since 1985 his research has focused on LOTOS: besides basic research, he applied this FDT in several ESPRIT European project. =============================================================================== Tutorial D High Speed Networks and Multimedia Communications by Fouad Tobagi (Starlight Inc., Stanford University -USA) Tuesday 28 June 1994 ; 09:00 to 17:00 The main driving force behind innovative networking in the 1990's is clearly "multimedia". From the communications point of view, we note that the traffic underlying the various types of information have characteristics that differ substantially from each other, and from those of traditional data applications for which existing network infrastructures and protocols have been designed. These new traffic types place new requirements on the networks, pertaining to data rates, traffic patterns, loss and latency requirements, modes of communi cations, synchronization, etc. In this tutorial, following a brief description of multimedia applications, we identify the new communications requirements that these applications introduce. We then discuss the network infrastructures and network functions that are needed in order to meet these requirements. In particular, we examine the role of existing networking solutions (Ethernet, token ring, and FDDI in the LAN environment; pac-ket-switched and circuit-switched services in the WAN environment); we describe new emerging networking technologies (Ethernet switching hubs, 100 Mbps Ethernet, ATM, etc.) and discuss the role they are likely to play; we examine the limitations of existing protocols, and describe emerging network, transport, and session layer protocols designed by various groups (the IETF, the ATM Forum, the IMA and others). Finally, we address the subject of multimedia video servers, and discuss design issues pertaining to storage and streaming capabilities. Fouad A. Tobagi is Professor of Electrical Engineering (and by courtesy Computer Science) at Stanford University, Stanford, CA. He is also a Co-Founder and ChiefTechnical Officer of Starlight Networks, a venture concerned with multimedia networking. Dr. Tobagi is a fellow of the IEEE. His research interests include multimedia communications, broadband integrated services digital networks, ATM and fast packet switching. =============================================================================== Conference Preliminary Program Wednesday June 29, 1994 8:00-18:00 Registration 9:00 Opening Session Chairpersons: Guy Pujolle, PRiSM, France, Jean-Pierre Verjus, IMAG, France, Serge Fdida, MASI, France, Christophe Diot, INRIA Sophia Antipolis, France 9:45 Keynote Address Radu Popescu-Zeletin, GMD-FOKUS, Germany 10:45 Break 11:15 SessionA : High-Performance LANs and MANs Chairperson: Fouad Tobagi, Stanford University, USA A1- HMR: An ATM-Based Medium Access Protocol for Gigabit Ring Networks. B. Chun Jeon, ETRI, South Korea, K. Dae Young, Chungnam National University, South Korea. A2- R-Net: A Round Robin Medium Acces Protocol for MANs. A. Bissonauth, A. E. Kamal, University of Alberta, Canada. A3- Behaviour of the Metaring Gigabit/s Network under Multipriority Traffic. M. Gagnaire, ENST, France. 12:45 Lunch 14:30 Session B : MAC Performance in High-Speed Networks Chairperson: Harmen Van As, IBM Zurich Research, Switzerland B1- Performance Comparison of Media Access Protocols in the Gps range. A. Grebe, C. Bach, Univ. of Hagen, Germany.. B2- RAIN (Redundant Array of Inexpensive Networks): Expending Existing Networks to Support Multi-Traffic Performance. E. C. Foudriat, K. Maly, R. Mukkamala, C.M. Overstreet, L. Mathews, S.Balay, Old Dominion Univ., USA. 15:30 Break 16:00 Session C : Routing Issues in High-Performance Networks Chaiperson: Giorgio Ventre, Universita di Napoli, Italy C1- An Evaluation of Routing and Admission Control Algorithms for Real-Time Traffic in Packet-Switched Networks. D. S. Reeves, S. Rampal, North Carolina State University, USA. C2- Adressing and Routing in Heterogeneous Data Networks. J. W. Atwood, Concordia University, Canada, J.M Jézéquel, IRISA, France, A. Das, N'H. Nour, Université de Montreal, Canada. C3- A Comparison of Gigabit Router Architectures. O.G. Koufopavlou, A.N. Tantawi, IBM Yorktown Heights, USA, M. Zitterbart, Karlsruhe University, Germany. C4- Automatic Network Clustering for Fast Path Selection. C. Galand, P. Scotton, Centre d'Etudes et Recherches, IBM La Gaude, France. 18:00 End of the Session 19:00 Get-together party Thursday June 30, 1994 8:30-17:30 Welcome Desk, Registration 8:30 Session D : Enhanced Transport and Synchronization Chairperson: Marjory Johnson, RIACS, USA D1- Performance Analysis of Window-based Flow Control using TCP-IP: The Effect of High Bandwidth-Delay Products on Random Loss. T.V. Lakshman, U. Madhow, Bell Communication Research, USA. D2- Dynamic Quality and Congestion Control for Integrated Video and Data Communications. Y. Ishibashi, S. Tasaka, Nagoya Institute of Technology, Japan. D3- Multipeer Transport Services for Multimedia Applications. L. Henckel, GMD FOKUS, Germany D4- Implementing Intra-Stream Synchronization by means of Conditional Dependency Expressions. L. F. Rust da Costa Carmo, J.P. Courtiat, LAAS-CNRS, France. 10:30 Break 11:00 Invited Speaker Chaiperson: Martina Zitterbart, University of Karlsruhe, Germany. Experiments with Lock-free Data Structures and Parallel Communications Software. Greg Chesson, Silicon Graphics Inc., USA. 12:00 Lunch 14:00 Session E : Quality of Service and Architecture Chairperson: Guy Leduc, University of Liège, Belgium. E1- Flow Management. A. T. Campbell, G. Coulson, D. Hutchinson, Lancaster University, UK. E2- Quality of Service Negotiation for Orchestrated, Distributed Multimedia Presentation. S. V. Raghavan, P. Prabhakaran, India Institute of Technology, India, S. K. Tripathi, University of Maryland, USA. E3- A Simplified QoS Model for Multimedia Protocols over ATM. S. Damaskos, A. Gavras, GMD-FOKUS, D. E4- Broadband Network Services: Architecture for High Speed Multimedia Networking. G.A. Marin, T. Tedijanto, R.O. Onvural, IBM RTP, USA. 15:30 Break 16:00 Session F : Resource Management Chairperson: Craig Partridge, BBN, USA F1- An Optimal Resource Allocation Policy for ATM networks Supporting Time critical Applications. K. Chen, R. Coelho, S. Thomé, ENST, France. F2- Fast Connection Establishment in the DTM Gigabit Network. P. Lindgren, C. Bohm, Tele System Laboratory, S. 17:30 End of the Session 18:00 Conference Banquet Friday July 1, 1994 8:30-16:00 Welcome Desk 9:00 Session G: Traffic Analysis and Performance Chairperson: Otto Spaniol, Aachen University, Germany G1- A Source Model for Connectionnless Traffic in B-ISDN. M. Ajmone Marsan, R. Lo Cigno, M. Munafo, Politecnico di Torino, I, A. Tonietti, CSELT, Italy. G2- Analysis of Traffic Measurement in the VISTAnet Gigabit Networking Testbed. D. S. Holtsinger, H. Perros, A. A. Nilsson, North Carolina State University, USA. G3- Analysis of a Statistical Multiplexer with Generalized Periodic Sources. I. Cidon, R. Guerin, I. Kessler, IBM Yorktown Heights, USA. A. Khamisy, Technion, Israel. 10:00 Break 10:30 Session H : Internetworking Chaiperson: Augusto Casaca, IST/INESC, Portugal H1- Performance of Interconnecting FDDI Networks through ATM when Managing Video Traffic. D. Andrés, J. Vila, J. Domingo, J. Sole-Pareta, Universita Politecnica de Catalunya, Spain. H2- A Rate Control Mechanism for LAN/MAN Interworking Systems. L. Orozco Barbosa, N. Hirzalla, University of Ottawa, Canada. 11:30 Lunch 13:30 Session I : Multimedia Communication Systems Chairperson: Julio Escobar, BBN, USA I1- A Distributed Environment to Support Cooperative Software Development. A. F. Marcos, Fraunhofer Institue for Computer Graphics, Germany. I2- TITTLE: Multimedia Mail Services. M. Baveco, PTT Research, the Netherland, P. Hoepner, GMD-FOKUS, Germany. M. Szymanski, Telefonica, Spain. 14:30 Break 15:00 Session J : Performance Tools Chairperson: Michel Diaz, LAAS-CNRS, F J1- FDDI Performance Evaluation Based on LOTOS Description Technique. A. Martinez, C. Miguel, E. Pérez, A. Fernandez ETSI Telecomunicacion, UPM, Spain. J2- Description of a Simulation Environment to Evaluate High Performance ATM Fast Packet Switches. J. Garcia-Haro, R. Marin-Sillué, J. L. Melus-Moreno, Polytechnic University of Catalonia, Spain. 16:00 Closing Session 16:15 End of the Conference Technical program inquiries can be addressed to : Professor Serge FDIDA Laboratoire MASI - CNRS 4 Place Jussieu - 75252 PARIS cedex 05 - FRANCE Ph : +33 1 44 27 30 58 - Fx : +33 1 44 27 62 86 - e.mail : fdida@masi.ibp.fr =============================================================================== Tutorials and Conference Information Dates Tutorials : Monday 27 June 1994 from 9:00 to 17:00 Tuesday 28 June 1994 from 9:00 to 17:00 Two 30 minutes breaks at 10:30 and 15:30 Conference : Wednesday 29 June to Friday 1st of July 1994 Opening session : Wednesday 29 June 1994 at 9.00 Get-together party : Wednesday 29 June 1994 at 19:00 Conference dinner : Thursday 30 June 1994 evening Closing session : Friday 1st of July 1994 at 16.00 Excursion : Saturday 2nd of July 1994 in les 2 Alpes Venue The Tutorials will be held in the IMAG Institute (5mn from the train station) : 46 Avenue Felix Viallet ; 38031 GRENOBLE cedex 01 Phone : +33 76 57 47 02 The HPN conference will be held in the New Grenoble Museum of Art : Place de la Valette ; 38000 GRENOBLE Phone : +33 76 63 44 44 Both locations are on the tramway line. Language The official language of the Conference is English Registration fees Registration & payment received : by 27 May 94 after 27 May 94 Tutorial A, B,C or D 1800 FRF 1800 FRF Conference fees 2500 FRF 2900 FRF Reduced Conference Fees* 2200 FRF 2600 FRF Package "2 days tutorials + conference" 5000 FRF The reduced conference fee* is granted to Program Committee members, authors of submitted papers, reviewers, and participants attending one tutorial. A tutorial fee includes : the tutorial notes, the access to a one day tutorial session, a lunch and refreshments during the two breaks. The conference fee includes : the access to all sessions, the final program, one copy of the participant's edition of the proceedings, the lunches for the three days, morning and afternoon refreshments during the breaks, tramway pass for 3 days, free access to the Museum of Art, access to the get-together party on Wednesday evening and to the excursion on Saturday. Name badge An admission name badge will be delivered to each fully registered participant. This badge gives access to the appropriate room and it must be worn visible throughout the whole Conference period. Literature A participant's edition of the proceedings will be made available at the Welcome Desk of the Conference. The final Proceedings will be published in the IFIP series format by Elsevier Science Publishers B.V. (North Holland). Registration form The enclosed registration form must be returned as soon as possible with payment to Destination Congrès - BP 56 - 38242 MEYLAN Cedex - FRANCE. Registration is only effective when payment is received. Payment Payment of fees will be accepted in French Francs only. The fees can be paid : - by sending a certified cheque in French francs drawn in a French bank to the order of "Destination Congrès". - by credit card (Eurocard - MC - Visa - Amex) - by bank transfer to BNP account number : 30004 01456 00021510057 88 (be sure to clearly state your name and adress). Bank transfer and cheques should be made net of all bank charges and commissions. Confirmation Destination Congrès, upon receipt of the registration form and of the payment, will send to the participant a confirmation and an invoice for his/her accounting department. On his arrival the participant is requested to present himself at the Welcome Desk to get his/her conference documents (badge, proceedings, lunch ticket, party ticket, excursion ticket). Cancellation For written cancellations received by Destination Congrès - prior to 30 May 1994 : total refund - after 30 May and before 17 June : total refund less 200 FRF for administrative costs - after 17 June and before 20 June : 50 % refund - after 20 June : no refund Accomodation The accomodation form must be returned as soon as possible with the payment of a deposit equal to the first night to Destination Congrès BP 56 - 38242 Meylan cedex-France. Fax : +33 76 90 33 26. Approximative price per night per person, breakfast, taxes included. Category hotel 4* 700 FRF Category hotel 3* 300 to 400 FRF Category hotel 2* 250 to 350 FRF Most hotels are within a walking distance of the New Grenoble Museum. Anycase, they all are on the tramway line. A number of rooms have been blocked for participants. Reservation will be handled on a first-come first-served basis. Early reservation is advisable. Travel arrangements For international flights : Destination Congrès has made special arrangements with airline companies for special packages. For national flights : Destination Congrès will centralize all the requests and will issue the flight tickets at special congress prices. Participants who are interested should ask for the Travel Arrangement Form, and return it by fax or mail to Destination Congrès as soon as possible. Get-together party Participants and companions are invited to attend a get-together party on Wednesday 29 June from 18:30 to 21:00. They will be given the opportunity to taste french cheese and french wines. The party will take place at "La Bastille". Transport from the congress site and from most of the hotels can be made on foot and by cable car. Details will be made available upon arrival at the Conference centre. Conference Banquet Early reservation is required together with your Conference registration. The price of 350 FF has to be paid with the Conference fee. The transportation will be arranged by the organization. Excursion Participants and companions are invited to a "Grand Air" journey in Les 2 Alpes on Saturday 2nd July . Les 2 Alpes is a ski resort located in the Oisans Mountains, between 1600 and 3660 meters. The privileged situation of the resort guarantee snow cover all year round. A Ski-Pass will be offered to each participant of the journey : -Walkers can easily raise the top of the Glacier to enjoy an exceptional view of the Alps, visit typical surrounding villages, or spend time at the outdoor swimming pool. - Skiors will have access to the largest summer ski area in Europ. The transportation (and ski equipment rental) will be arranged by the organization. Details will be made available upon arrival at the conference centre. We advice appropriate clothing (and shoes !). Participants who envisage to take part in this "Grand Air" journey are invited to indicate it at the registration desk. HPN '94 Conference Administrative Office Catherine HICTER-PLOTTIER and Martine RETTER DESTINATION CONGRES BP 56 - 38242 MEYLAN cedex - FRANCE Phone : +33 76 90 18 12 - Fax : +33 76 90 33 26 Organization inquiries Christophe Diot INRIA Sophia Antipolis hpn94@imag.fr - fax : +33 93 65 77 65 Shuttle - Airport pick-up service We inform you that a regular shuttle service is available from Satolas and St Geoirs Airports. Please buy your tickets on arrival (per way and per person): From Satolas (Lyon) : 120 FF ; from St Geoirs (Grenoble) : 60 FF. To get to Grenoble from the various airports, the Airport company can offer you a personnalized "Limo-like" Service : - a car can pick you up at the airport and take you to your hotel or directly to the congress location. - for your departure, the Airport company can also arrange to pick you up either at your hotel or at the congress location. Prices per person (round trip ticket) : Grenoble (St Geoirs) : 180 FF ; Lyon (Satolas) : 320 FF ; Genevea (Cointrin) : 510 FF If you are interested please contact Airport by phone : +33.76.70.30.40 or fax :+33.76.48.48.31, and mention HPN94 rate. Note that while in Grenoble, you will not need any transport facilities. A tramway pass will be provided to each participant. Companion program A companion program is organized on Wednesday, Thursday and Friday. Companions who are interested in this programme are invited to fill in the registration form. Wednesday June 29 : Grenoble (240 FRF incl. lunch) Discover Grenoble in one day, including a bus tour, a visit of the city center by foot, and a visit to the "Musée Dauphinois", which presents culture and tradition of the French Alps from prehistoric times to the present days. Thursday June 30 : Vercors (270 FRF incl. lunch) A one day tour in the Vercors mountains where you will visit the 1968 olympic ski jump (view point), Villard de Lans, a typical alpin village and the Choranche caves, through spectacular narrow widing roads hemmed in magnificient cliffs. Friday July 1 : Chartreuse (270 FRF incl. lunch) A bus tour within the mystic Chartreuse mountains that will bring you the the "Monastère de la Grande Chartreuse" (Carthusian monks), to St Pierre de Chartreuse, and to the cellars of the Great Chartreuse liquor (including a tasting). =============================================================================== HPN '94 is proud to thanks its partners : SUN CONNECT RANK XEROX HPN'94 organization committee also wants to thank its academic and non profit partners : The city of GRENOBLE Grenoble Isère Développement INRIA Institut National Polytechnique de Grenoble Université Joseph Fourier and, for their precious collaboration : Les 2 Alpes DESTINATION Congrès Service de Reprographie de l'IMAG =============================================================================== REGISTRATION AND ACCOMODATION FORM First name : .................................................................. Family Name : ................................................................. Address :..................................................................... .............................................................................. City : ................................... Zip code : ........................ State : .......................... Country : .................................. Fax : ............................ E.mail : ................................... --------------------------------------------------------------------------- Please reserve : Single room Double room : one bed two beds (please circle selected items) De Lux hotel category **** 700 FRF First class category *** 300 to 400 FRF Economy category ** 250 to 350 FRF All rooms rate include one night and breakfast ARRIVAL DATE : ............................................................... DEPARTURE DATE : ............................................................. Sharing person : ............................................................. To guarantee your room, a one night deposit is required. --------------------------------------------------------------------------- HPN '94 Conference fees: by 27 May 94 after 27 May 94 Tutorial A or C 1800 FRF 1800 FRF Tutorial B or D 1800 FRF 1800 FRF Conference fees 2500 FRF 2900 FRF Reduced Conference Fees 2200 FRF 2600 FRF Package "2 days tutorials + conference" 5000 FRF Conference Banquet ........... x 350 FRF Extra Lunch Ticket ........... x 75 FRF Companion Program : Grenoble 240 FRF / Vercors 270 FRF / Chartreuse 270 FRF Room Deposit **** hotel : 700 FRF / *** hotel : 400 FRF / ** hotel : 350 FRF (Please CIRCLE selected items) TOTAL AMOUNT : ...............................FRF --------------------------------------------------------------------------- Payment of the fees and deposit by (please circle selected mode of payment) CREDIT CARD: Eurocard VISA MC AMEX name : ........................................................................ number : ........................................... exp. date : .............. signature : ................................................................... BANK TRANSFER to the Banque Nationale de Paris ; account number 30004 01456 00021510057 88. CHEQUE in French Franc drawn on a French bank payable to "DESTINATION Congrès" Please Note : Cancellation received after June 20 will not be refunded Payment by cheque and bank transfer must be net of any charge. Please complete this form and return it with your payment to DESTINATION CONGRES; BP56; 38242 Meylan cedex, FRANCE Phone +33.76.90.18.12 - fax: +33.76.90.33.26 --------- INRIA e-mail: christophe.diot@sophia.inria.fr 2004 route des Lucioles BP 93, 06902 Sophia Antipolis Phone: (33) 93 65 77 56 FRANCE Fax: (33) 93 65 77 65 From rem-conf-request@es.net Thu Mar 03 11:33:04 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <00680-0@osi-west.es.net>; Thu, 3 Mar 1994 08:31:30 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Mar 1994 16:31:00 +0000 To: rem-conf@es.net CC: mice-seminars-announce@cs.ucl.ac.uk Subject: MICE International Seminar: March 8, 1994. Date: Thu, 03 Mar 94 16:30:57 +0000 From: Gordon Joly ** Please limit traffic between 13:30 and 15:30 GMT on Tuesday March 8th. At 14:00 GMT, Dr. Klaus Dieter Guenther (GMD in Darmstadt) with speak on "Distributed Cooperative Office Applications". An announcement will be made in "sd" on Tuesday. Abstract. ----------- "DISCO" stands for "DIS-tributed C-ooperative O-ffice applications". The purpose of DISCO is to facilitate programming, administration, and execution of distributed applications. Its primary application domain are forms-oriented office procedures. I.e., the emphasis of DISCO is on cooperation between persons by exchanging forms or texts in a more or less programme-controlled fashion. Some highlights of DISCO are: 1. its support for arbitrary distributed applications based on a special concept of inter-process communication: DISCO does not just shift forms/documents around between persons, 2. its strict "single-language approach": all aspects of a distributed application are programmed in C++ (enhanced by a pre-compiler), 3. system-supported restart after crashes or deliberate interruptions of work by persons, 4. extensive support for administration of applications, persons, organizational units and their rights, 5. support of distributed transactions, digital signatures, and of a forms-oriented user interface (based on the X Window System). ----------- In general, information on the MICE seminars kept up to date in the URL http://www.cs.ucl.ac.uk/mice/seminars/ which should also contain abstracts of future talks. Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT & mice-nsc@cs.ucl.ac.uk & http://www.cs.ucl.ac.uk/mice/gjoly.html & From rem-conf-request@es.net Thu Mar 03 16:10:31 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <05558-0@osi-west.es.net>; Thu, 3 Mar 1994 13:10:02 +0000 Received: by radio.com (5.65/IDA-940223.01) id AA26395; Thu, 3 Mar 94 16:10:02 -0500 Date: Thu, 3 Mar 94 16:10:02 -0500 From: Carl Malamud Message-Id: <9403032110.AA26395@radio.com> To: rem-conf@es.net Subject: Flakey announcements Org: Internet Multicasting Service We've announced a few things in SD that haven't happened. We've had some real problems with connectivity, which has delayed our daily news, Computer Chronicles, and one of our luncheons. We'll try to do Computer Chronicles tomorrow afternoon. Carl From rem-conf-request@es.net Sat Mar 05 23:43:43 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <01074-0@osi-west.es.net>; Sat, 5 Mar 1994 20:43:12 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Sat, 5 Mar 1994 20:43:08 -0800 Posted-Date: Sat 5 Mar 94 20:42:05 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 5 Mar 94 20:42:06 PST Date: Sat 5 Mar 94 20:42:05 PST From: Stephen Casner Subject: Re: nv on secure networks To: sma@nas.nasa.gov, jec@philabs.philips.com Cc: rem-conf@es.net Message-Id: <762928925.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9403011814.AA16157@win70.nas.nasa.gov> Mail-System-Version: On Tue, 1 Mar 94, sma@nas.nasa.gov (Steve M. Acheson) replied to jec@philabs.Philips.COM (Jorge E. Caviedes) on this subject, but I think some of that information was incorrect. > >Talking to our system administrator about access to the MBONE, he says that > >probably we need to run similarly to the other internet applications we > >have (e.g. with the restrictions of a firewall). > > This is reasonable, although not necessary as the tunnel from your site and > the MBONE could run on the firewall machine if it is a dual homed gateway, > which it sounds like. There are several sites that allow multicast traffic through their firewall even though unicast traffic is blocked. That can be done either by running mrouted on the firewall machine, as suggested, or by setting the filter parameters of the firewall to let the control and data packets of a tunnel flow through. > >We run mosaic, ftp, telnet using "socksified" versions to protect the > >local system. This means that a demon on the firewall machine is the > >intermediary between our local machines and the internet, IPforward is > >turned off and thus none here talks directly to Internet. The question > >is under this conditions is it possible still to have access to the MBONE > >and run nv? > > Sure, you only need to configure the mrouted to be socksified, ie replace all > of the connect and select [...] routines with the corresponding Rconnect and > Rselect version. This should allow a host on the inside of your firewall to > establish a tunnel with the MBONE and still have your security intact. Well, I've now learned another topic on which I am ignorant, since I have not heard of "socksified" before. However, I'm pretty sure the suggested replacements are not going to solve the problem. The mrouted daemon process only handles the exchange of multicast routing packets; the multicast data does not flow through mrouted. Data forwarding is handled by the additions to the kernel, and I would guess that part of the code would also need some form of protection. > The security probably isn't necessary as the tunnel is established with a > single host external to your net, and it is an TCP connection port to port on > the two hosts. This would be very difficult to exploit (never say impossible) > and almost as pointless. But the answer to your question is as above, yes. The multicast tunnel is not a TCP connection. The routing packets are IGMP (protocol 2) and the data packets are IP-in-IP (protocol 4). Port numbers do not apply to the tunnel itself, and the port numbers of the encapsulated audio and video traffic inside the tunnel are typically dynamic, not fixed. There is risk involved in letting multicast traffic through the firewall, for example in a trojan horse application. You have to decide if the risk is acceptable. -- Steve Casner ------- From rem-conf-request@es.net Mon Mar 07 12:14:44 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <16628-0@osi-west.es.net>; Mon, 7 Mar 1994 09:14:02 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA21606; Mon, 7 Mar 94 12:13:55 EST Date: Mon, 7 Mar 1994 11:48:21 -0500 (EST) From: Allen Robel Subject: VAT to Phone System Gateway? To: rem-conf@es.net Cc: Allen Robel Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Has anyone thought about the issues involved in implementing a VAT to phone system gateway? I'm thinking that it might be possible to use, say, a Sparc with an ISDN interface as the gateway platform, but haven't really thought a lot about how VAT would need to be modified (if its even possible) to support something like this. Better yet, is anyone working on building this? :-) Various ruminations in no particular order. Is there an ISDN PRI interface for the Sparc so that multiple calls (incoming and outgoing could be supported? If so, is it relatively easy to access the individual DS0s (B-channels) to packetize them? Would a Sparc 10 be up to this for 24 DS0s? I guess that you'd map local telephone numbers to IP addresses so that the gateway could route incoming calls to the proper recipient. Could map multiple IP addresses to each phone number for rollover capability i.e. When an outside caller calls a given local number, the gateway tries initiating a VAT connection with each IP number in a prioritized list in turn. Ideally, a computer generated voice would inform the remote caller to wait and that its trying multiple locations. Could probably map multicast addresses to phone numbers for regular conference calls with outside agencies. i.e. When an outside caller calls a given local number, the gateway sends the packetized audio on a given multicast address. Sorry if this has been brought up before... allen From rem-conf-request@es.net Mon Mar 07 12:30:27 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <16927-0@osi-west.es.net>; Mon, 7 Mar 1994 09:29:48 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.6.Beta9/2.2) with SMTP id MAA08805; Mon, 7 Mar 1994 12:29:42 -0500 Message-Id: <199403071729.MAA08805@terminator.rs.itd.umich.edu> To: Allen Robel Cc: rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of Mon, 07 Mar 1994 11:48:21 -0500. Date: Mon, 07 Mar 1994 12:29:41 -0500 From: Dory Ethan Leifer I gave it some thought at one time when I was doing tests of the ISDN Sparc interface. I don't know of any official PRI interface for the Sparc yet - possibly someone at Sun could comment on this. PRI is really expensive and probably out of the range of most users. I do understand that multiple BRIs can be plugged into an S-bus and that may do the job. A voice response front end would be a nice touch - I do have code which does DTMF detection on the ISDN interface so that users could enter an IP address, a PIN, etc. It would be good to listen for DTMF so the user could enter "#" to disconnect from the conference and return to some type of menu. Another lower-tech possibility is using analog modems that pass digital speech. Anyone know how this works? Does it just send u-law PCM at 56K? Dory Leifer University of Michigan > Hi, > > Has anyone thought about the issues involved in implementing a VAT to > phone system gateway? I'm thinking that it might be possible to use, say, > a Sparc with an ISDN interface as the gateway platform, but haven't really > thought a lot about how VAT would need to be modified (if its even > possible) to support something like this. Better yet, is anyone working > on building this? :-) > > Various ruminations in no particular order. > > Is there an ISDN PRI interface for the Sparc so that multiple calls > (incoming and outgoing could be supported? > > If so, is it relatively easy to access the individual DS0s (B-channels) to > packetize them? Would a Sparc 10 be up to this for 24 DS0s? > > I guess that you'd map local telephone numbers to IP addresses so that > the gateway could route incoming calls to the proper recipient. > > Could map multiple IP addresses to each phone number for rollover > capability i.e. When an outside caller calls a given local number, the > gateway tries initiating a VAT connection with each IP number in a > prioritized list in turn. Ideally, a computer generated voice would inform > the remote caller to wait and that its trying multiple locations. > > Could probably map multicast addresses to phone numbers for regular > conference calls with outside agencies. i.e. When an outside caller calls > a given local number, the gateway sends the packetized audio on a given > multicast address. > > Sorry if this has been brought up before... > > allen > From rem-conf-request@es.net Mon Mar 07 12:33:42 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <16948-0@osi-west.es.net>; Mon, 7 Mar 1994 09:32:55 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Mar 1994 17:32:15 +0000 To: Allen Robel cc: rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of "Mon, 07 Mar 94 11:48:21 EST." Date: Mon, 07 Mar 94 17:32:07 +0000 From: Jon Crowcroft >Has anyone thought about the issues involved in implementing a VAT to >phone system gateway? I'm thinking that it might be possible to use, say, >a Sparc with an ISDN interface as the gateway platform, but haven't really >thought a lot about how VAT would need to be modified (if its even >possible) to support something like this. Better yet, is anyone working >on building this? :-) we are working o nthis with a group of 5 Masters students over the summer - we are doing it exactly as you say, with a sun & isdn... >Is there an ISDN PRI interface for the Sparc so that multiple calls >(incoming and outgoing could be supported? we have our own primary rate isdn cgateway on a sun - i havn't heard of anyone elses that fit on unix systems... >If so, is it relatively easy to access the individual DS0s (B-channels) to >packetize them? Would a Sparc 10 be up to this for 24 DS0s? i think you need help with that many - we have outboard processing for managing the B-channel mappings... >I guess that you'd map local telephone numbers to IP addresses so that >the gateway could route incoming calls to the proper recipient. yes - we thought something similar..or else have a recorded message for inbound calls with a list of vat cofnerence session names, and use tone-dials to select fro mthe list... >Could map multiple IP addresses to each phone number for rollover >capability i.e. When an outside caller calls a given local number, the >gateway tries initiating a VAT connection with each IP number in a >prioritized list in turn. Ideally, a computer generated voice would inform >the remote caller to wait and that its trying multiple locations. rotaries - interesting... >Could probably map multicast addresses to phone numbers for regular >conference calls with outside agencies. i.e. When an outside caller calls >a given local number, the gateway sends the packetized audio on a given >multicast address. good to bring this up btw, we are going to do video too (we have isdn videophones and nv, and IV, so why not...?) cheers jon From rem-conf-request@es.net Mon Mar 07 12:42:42 1994 Received: from win70.nas.nasa.gov by osi-west.es.net via ESnet SMTP service id <17100-0@osi-west.es.net>; Mon, 7 Mar 1994 09:41:46 +0000 Received: by win70.nas.nasa.gov (5.67-NAS.6/NAS.3-sgi) id AA25738; Mon, 7 Mar 94 09:41:38 -0800 Date: Mon, 7 Mar 94 09:41:38 -0800 From: sma@nas.nasa.gov (Steve M. Acheson) Message-Id: <9403071741.AA25738@win70.nas.nasa.gov> To: Stephen Casner Subject: Re: nv on secure networks Cc: rem-conf@es.net Reply-To: sma@nas.nasa.gov >Well, I've now learned another topic on which I am ignorant, since I >have not heard of "socksified" before. However, I'm pretty sure the >suggested replacements are not going to solve the problem. The >mrouted daemon process only handles the exchange of multicast routing >packets; the multicast data does not flow through mrouted. Data >forwarding is handled by the additions to the kernel, and I would >guess that part of the code would also need some form of protection. "Socksified" is refering to the socket based tcp proxy forwarding software available for Unix (and some other systems). >The multicast tunnel is not a TCP connection. The routing packets are >IGMP (protocol 2) and the data packets are IP-in-IP (protocol 4). >Port numbers do not apply to the tunnel itself, and the port numbers >of the encapsulated audio and video traffic inside the tunnel are >typically dynamic, not fixed. I apologize for the assumption (Errk). It was a stupid assumption based on glibly reading the docs, and getting the software working that the tunnels were TCP based. I rescend my previous showing of ignorance and hope that nobody keeps it for blackmail when I'm running for some Political office etc. *grin* >There is risk involved in letting multicast traffic through the >firewall, for example in a trojan horse application. You have to >decide if the risk is acceptable. Agreed. (I'll only put one foot in the mouth today, thanks :-) Steve ====================================================== Steve Acheson (415) 604-6555 Sterling Software sma@nas.nasa.gov NASA Ames Moffett Field, Ca 94035-1000 From rem-conf-request@es.net Mon Mar 07 13:34:25 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <17979-0@osi-west.es.net>; Mon, 7 Mar 1994 10:33:29 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA21974; Mon, 7 Mar 94 13:33:05 EST Date: Mon, 7 Mar 1994 13:30:03 -0500 (EST) From: Allen Robel Subject: Re: VAT to Phone System Gateway? To: Jon Crowcroft Cc: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Very cool Jon. This opens doors for FREE (well, as free as the Internet) around the world calling vat->phone, or even phone->vat->phone. Yikes! Hope they get those OC-12 links in the backbone installed soon ;-) allen On Mon, 7 Mar 1994, Jon Crowcroft wrote: > > > >Has anyone thought about the issues involved in implementing a VAT to > >phone system gateway? I'm thinking that it might be possible to use, say, > >a Sparc with an ISDN interface as the gateway platform, but haven't really > >thought a lot about how VAT would need to be modified (if its even > >possible) to support something like this. Better yet, is anyone working > >on building this? :-) > > we are working o nthis with a group of 5 Masters students over the > summer - we are doing it exactly as you say, with a sun & isdn... > > >Is there an ISDN PRI interface for the Sparc so that multiple calls > >(incoming and outgoing could be supported? > > we have our own primary rate isdn cgateway on a sun - i havn't heard > of anyone elses that fit on unix systems... > > >If so, is it relatively easy to access the individual DS0s (B-channels) to > >packetize them? Would a Sparc 10 be up to this for 24 DS0s? > > i think you need help with that many - we have outboard processing for > managing the B-channel mappings... > > >I guess that you'd map local telephone numbers to IP addresses so that > >the gateway could route incoming calls to the proper recipient. > > yes - we thought something similar..or else have a recorded message > for inbound calls with a list of vat cofnerence session names, and use > tone-dials to select fro mthe list... > > >Could map multiple IP addresses to each phone number for rollover > >capability i.e. When an outside caller calls a given local number, the > >gateway tries initiating a VAT connection with each IP number in a > >prioritized list in turn. Ideally, a computer generated voice would inform > >the remote caller to wait and that its trying multiple locations. > > rotaries - interesting... > > >Could probably map multicast addresses to phone numbers for regular > >conference calls with outside agencies. i.e. When an outside caller calls > >a given local number, the gateway sends the packetized audio on a given > >multicast address. > > good to bring this up > > btw, we are going to do video too (we have isdn videophones and nv, > and IV, so why not...?) > > cheers > > jon > > From rem-conf-request@es.net Mon Mar 07 14:24:04 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <18823-0@osi-west.es.net>; Mon, 7 Mar 1994 11:22:40 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA22073; Mon, 7 Mar 94 14:22:32 EST Date: Mon, 7 Mar 1994 14:10:01 -0500 (EST) From: Allen Robel Subject: Re: VAT to Phone System Gateway? To: rem-conf@es.net Cc: Allen Robel Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I got some messages asking for clarification to my last posting about "free" worldwide phone service. What I mean't was that, given the facilities diagrammed below, any phone user could dial up any other phone user (or VAT user) thru the Internet. TelephoneUser--LocalVatGW--Internet--LocalVatGW--TelephoneUser That is, if a mechanism were developed for local calls to the LocalVATGW to be routed appropriately. So, if I wanted to call someone from Down Under from Bloomington, IN (USA), the LocalVatGW would need to know the IP address of the appropriate RemoteVatGW. This implies some sort of routing between the VatGW's (possibly by associating country code + area code + prefix to IP network??). Or, then again, we could always just stick with our phones :-). allen From rem-conf-request@es.net Mon Mar 07 15:21:37 1994 Received: from interlock.ans.net by osi-west.es.net via ESnet SMTP service id <18933-0@osi-west.es.net>; Mon, 7 Mar 1994 11:25:51 +0000 Received: by interlock.ans.net id AA29308 (InterLock SMTP Gateway 1.1 for rem-conf@es.net); Mon, 7 Mar 1994 14:25:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Mar 1994 14:25:42 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Mar 1994 14:25:42 -0500 From: Curtis Villamizar Message-Id: <199403071924.AA81752@foo.ans.net> To: Dory Ethan Leifer Cc: Allen Robel , rem-conf@es.net, curtis@ans.net Subject: Re: VAT to Phone System Gateway? In-Reply-To: (Your message of Mon, 07 Mar 94 12:29:41 EST.) <199403071729.MAA08805@terminator.rs.itd.umich.edu> Date: Mon, 07 Mar 94 14:24:27 -0500 > Another lower-tech possibility is using analog modems that pass > digital speech. Anyone know how this works? Does it just send > u-law PCM at 56K? > > Dory Leifer > University of Michigan Many PBXs, including some very low cost ones, have an out of band RS-232 control port with prorietary command set that supports this. Not that we want this purely acedemic discussion to encourage this sort of practice. ;-) Curtis From rem-conf-request@es.net Mon Mar 07 15:21:39 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <18674-0@osi-west.es.net>; Mon, 7 Mar 1994 11:14:46 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14595(2)>; Mon, 7 Mar 1994 11:14:06 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16145>; Mon, 7 Mar 1994 11:14:13 -0800 To: Allen Robel cc: rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of "Mon, 07 Mar 94 08:48:21 PST." X-Mailer: exmh version 1.3beta 2/17/94 Date: Mon, 7 Mar 1994 11:14:10 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Mar7.111413pst.16145@ecco.parc.xerox.com> In message you writ e: > Has anyone thought about the issues involved in implementing a VAT to > phone system gateway? I'm thinking that it might be possible to use, say, > a Sparc with an ISDN interface as the gateway platform, but haven't really > thought a lot about how VAT would need to be modified (if its even > possible) to support something like this. Better yet, is anyone working > on building this? :-) > At one point, I asked Van Jacobson for a change in vat to allow me to specify the audio device filename to use, for exactly this purpose. When I forked off a vat, I had a pipe open on a particular fd for me to feed it data, and I just used the Solaris "/dev/fd/nnn" trick and this new switch to make vat get its data from there. The interface I provided was a recorded voice message played when the caller first attached which allowed them to select among various conferences, and a touch tone decoder. I arranged it such that the touch tone processing stayed in the loop even after vat was running. I added an artificial delay of a couple of hundred msec before passing data to vat, so I could actually filter out all the touch tone sounds in the vat data stream. The result was you still had a full control channel available while vat was running. All of this was only a couple hundred lines, if I remember right. I didn't really push on what I might want to use the control channel for, though. Now that Vat uses Tk, it might be fairly easy to arrange for interesting UI features to be controllable by Tk 'send' messages. If you had a voice synthesizer available, you could even query vat for various statistics and have the system read them to you on command. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Mar 07 15:22:59 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <19227-0@osi-west.es.net>; Mon, 7 Mar 1994 11:37:57 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA01237; Mon, 7 Mar 94 11:37:07 PST Date: Mon, 7 Mar 94 11:37:07 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9403071937.AA01237@viipuri.nersc.gov> To: rem-conf@es.net Subject: FWD: SGI InPerson Desktop Conferencing Software Cc: dvtf@es.net From IRIS On-Line VOL 2 ISSUE 3 March 4, 1994: SILICON GRAPHICS PRODUCT INFORMATION ==================================== 4. InPerson Desktop Conferencing Software Nothing can replace the dynamic exchange of ideas offered by a face to face encounter. And nothing is faster and more convenient than a computer network for sharing information. Imagine the power of combining the two. Imagine how productive you'd be if ytou could intereact and share information wiht your co-workers live on your workstation monitor. InPerson desktop conferencing software makes all of this possible. InPerson turns your workstation into a powerful communications center, allowing you to call people and interact with live video and audio while you work together - in real time - on a selected file, a captured image or text document. When you need to share your ideas with the rest of your group, simply use InPerson to call all the members of the group, bring your work on screen then colalborate interactively on the project. With InPerson, you hear the group comments and see their reactions -- a productive and creative way to work. InPerson is entirely software based. Just load the software and that's it - there is no expensive option board to install. InPerson runs on the entire family of SIlicon Graphics workstations. Anyone with a Silicon Graphics system and InPerson can receive video images and fully participate in a conference through the use of the whiteboard. WOrkstations equipped with an audio system can send and receive audio as well -- no need to use the telephone. A workstation with a video camera can send video as well as receive it. Video allows you to bring real-world data, such as physical design prototypes or paper documents into the conversation. The Indigo family of workstations, with it's integrated digital media hardware, provides the ideal platform for increasing your productivity through desktop conferencing and collaboration. InPerson, through a shared whiteboard, interactive video and interactive audio, makes imagination reality, today. It's like nothing you've ever done on a workstation before. For more information on InPerson, send e-mail to inperson@sgi.com or, in North America, call 1-800-800-7441 ask for department N - end - ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Mon Mar 07 15:35:14 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <20229-0@osi-west.es.net>; Mon, 7 Mar 1994 12:33:28 +0000 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26346; Mon, 7 Mar 94 12:33:17 PST Received: from sunpix.East.Sun.COM (mailman.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA14550; Mon, 7 Mar 94 14:40:04 EST Received: from beale.East.Sun.COM by sunpix.East.Sun.COM (4.1/SMI-4.1) id AA08614; Mon, 7 Mar 94 14:40:02 EST Received: by beale.East.Sun.COM (5.0/SMI-SVR4) id AA11824; Mon, 7 Mar 1994 14:39:38 +0500 Date: Mon, 7 Mar 1994 14:39:38 +0500 From: Herman.Towles@East.Sun.COM (Herman Towles - Sun NC Development Center) Message-Id: <9403071939.AA11824@beale.East.Sun.COM> To: allen@stone.ucs.indiana.edu, leifer@terminator.rs.itd.umich.edu Subject: Re: VAT to Phone System Gateway? Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Content-Length: 317 While Sun has only BRI-ISDN products, you might check with BinTec in Germany as I'm told they announced BRI & PRI cards for Sun in early 93. Postal address: BinTec Computersysteme GmbH Willstaetterstr. 30 8500 Nuernberg 60 GERMANY Tel: 0911-99675-0 Fax: 0911-6880725 email: reinhard@bintec.de From rem-conf-request@es.net Mon Mar 07 16:41:16 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <21046-0@osi-west.es.net>; Mon, 7 Mar 1994 13:38:32 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.6.Beta11/2.2) with SMTP id QAA14393; Mon, 7 Mar 1994 16:38:23 -0500 Message-Id: <199403072138.QAA14393@terminator.rs.itd.umich.edu> To: Curtis Villamizar Cc: Allen Robel , rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of Mon, 07 Mar 1994 14:24:27 -0500. <199403071924.AA81752@foo.ans.net> Date: Mon, 07 Mar 1994 16:38:23 -0500 From: Dory Ethan Leifer Curtis - More clarification - There are modems that work with PC/Mac voice mail packages that are available from lots of mail order places. Both the signaling (AT extensions?) and digital voice stream are encoded over the RS232 port. Question is if anyone knows how the voice is encoded and are there any ad hoc standards for these types of modems? Dory > > > Another lower-tech possibility is using analog modems that pass > > digital speech. Anyone know how this works? Does it just send > > u-law PCM at 56K? > > > > Dory Leifer > > University of Michigan > > Many PBXs, including some very low cost ones, have an out of band > RS-232 control port with prorietary command set that supports this. > Not that we want this purely acedemic discussion to encourage this > sort of practice. ;-) > > Curtis From rem-conf-request@es.net Mon Mar 07 16:50:02 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <21195-0@osi-west.es.net>; Mon, 7 Mar 1994 13:46:59 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.6.Beta11/2.2) with SMTP id QAA14505; Mon, 7 Mar 1994 16:46:14 -0500 Message-Id: <199403072146.QAA14505@terminator.rs.itd.umich.edu> To: Allen Robel Cc: Jon Crowcroft , rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of Mon, 07 Mar 1994 13:30:03 -0500. Date: Mon, 07 Mar 1994 16:46:14 -0500 From: Dory Ethan Leifer > Very cool Jon. This opens doors for FREE (well, as free as the Internet) > around the world calling vat->phone, or even phone->vat->phone. Yikes! > Hope they get those OC-12 links in the backbone installed soon ;-) > Better check with the regulators, at least in the U.S. first. At one time it was illegal to pass a local call through a private network and then dump it back out as a local call without paying the local telephone company interexchange access fees. Of course if you connect the Internet to the local company using the right type of access trunks (feature group D?) then you could actually "PIC" the Internet to be your long distance carrier :) Dory From rem-conf-request@es.net Mon Mar 07 17:02:56 1994 Received: from churchy.nisc.sri.com by osi-west.es.net via ESnet SMTP service id <21444-0@osi-west.es.net>; Mon, 7 Mar 1994 14:01:58 +0000 Received: by churchy.nisc.sri.com (4.1/SRI-NISC1.2) id AA09519; Mon, 7 Mar 94 14:00:29 PST Message-Id: <9403072200.AA09519@churchy.nisc.sri.com> To: zia@jon.bellcore.com Cc: rem-conf@es.net Subject: Re: vat on Sparc10 problems Date: Mon, 07 Mar 94 14:00:27 GMT From: Ruth Lang > I have had a very similar problem with vat on Sparcstation10 and Sparcstation2. > Although IP multicasting is properly installed, sometimes input meters show > a high level of activity even though the mic is turned off. The resulting > speech is unintelligible. > > Can someone please shed some light on possible solutions? Thanks. Zia, As Steve Casner suggested (see below) we upgraded from vat v2.17 to v3.2 and have not observed any problems on our SPARCstation 10. As we did not use AGC during the observed problems, it did not seem to be part of the equation for us. I would be interested in hearing from you if you observe additional problems and will do likewise. Good luck, Ruth Lang ----------------------------------------- Return-Path: casner@ISI.EDU Received: from venera.isi.edu by NISC.SRI.COM (5.65/SRI-NISC1.2) id AA20148; Thu, 24 Feb 94 19:31:58 -0800 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 24 Feb 1994 19:31:59 -0800 Posted-Date: Thu 24 Feb 94 19:31:07 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 24 Feb 94 19:31:08 PST Date: Thu 24 Feb 94 19:31:07 PST From: Stephen Casner Subject: Re: vat on Sparc10 problems To: rlang@nisc.sri.com Message-Id: <762147067.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9402082145.AA00290@paris.nisc.sri.com> Mail-System-Version: Ruth, Your message from 08 Feb 94 to rem-conf did not come to me until today. I don't know if it was delivered to other people on time. Have you had any luck with fixing your SPARC10 audio? If the vat you were running was older than 2.20, I suggest that you get the new one, 3.2. It includes code to filter out a DC offset in SPARC10 audio, and also to reduce the level in software when mike input is selected because the minimum hardware level was not low enough with the extra-sensitive SunMicrophone. Also, you should not try to run with AGC turned on because it really does not behave well. -- Steve ------- From rem-conf-request@es.net Mon Mar 07 17:59:55 1994 Received: from interlock.ans.net by osi-west.es.net via ESnet SMTP service id <22485-0@osi-west.es.net>; Mon, 7 Mar 1994 14:58:38 +0000 Received: by interlock.ans.net id AA17151 (InterLock SMTP Gateway 1.1 for rem-conf@es.net); Mon, 7 Mar 1994 17:58:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Mar 1994 17:58:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Mar 1994 17:58:31 -0500 From: Curtis Villamizar Message-Id: <199403072257.AA63608@foo.ans.net> To: Dory Ethan Leifer Cc: Curtis Villamizar , Allen Robel , rem-conf@es.net, curtis@ans.net Subject: Re: VAT to Phone System Gateway? In-Reply-To: (Your message of Mon, 07 Mar 94 16:38:23 EST.) <199403072138.QAA14393@terminator.rs.itd.umich.edu> Date: Mon, 07 Mar 94 17:57:17 -0500 > Curtis - More clarification - There are modems that work with PC/Mac > voice mail packages that are available from lots of mail order I'm not familiar with these PC/MAC products so I don't know anything about their programming details. If you are just trying to do unicast audio where one or both ends are constrained by a voice grade line (ie: when working at home), why not just do PPP over a V.fast modem and use VAT with gsm as is (and get IP access through the same line). Just set up PPP to dial when packets follow the route through the PPP link. BSDI or NetBSD runs on a PC, BSDI has PPP with the dial capability (NetBSD too?) and BSDI and NetBSD support VAT. If both ends run PPP and the permanently Internet connected side can dial out, then you can call either way. I'm really not sure what you are trying to accomplish. Are you really trying to do IXC bypass? If so, is this appropriate for rem-conf? Curtis From rem-conf-request@es.net Mon Mar 07 18:07:44 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <22583-0@osi-west.es.net>; Mon, 7 Mar 1994 15:06:31 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.6.Beta11/2.2) with SMTP id SAA15842; Mon, 7 Mar 1994 18:06:24 -0500 Message-Id: <199403072306.SAA15842@terminator.rs.itd.umich.edu> To: Curtis Villamizar Cc: Allen Robel , rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of Mon, 07 Mar 1994 17:57:17 -0500. <199403072257.AA63608@foo.ans.net> Date: Mon, 07 Mar 1994 18:06:23 -0500 From: Dory Ethan Leifer > I'm not familiar with these PC/MAC products so I don't know anything > about their programming details. > > If you are just trying to do unicast audio where one or both ends are > constrained by a voice grade line (ie: when working at home), why not > just do PPP over a V.fast modem and use VAT with gsm as is (and get IP > access through the same line). Just set up PPP to dial when packets > follow the route through the PPP link. BSDI or NetBSD runs on a PC, > BSDI has PPP with the dial capability (NetBSD too?) and BSDI and > NetBSD support VAT. If both ends run PPP and the permanently Internet > connected side can dial out, then you can call either way. The idea was access to the PSTN.. not with PPP but with voice. user (human) on POTS ------ PSTN ------- ---- Internet ... > I'm really not sure what you are trying to accomplish. Are you really > trying to do IXC bypass? Nope. I was just responding in jest to the message about the free calls. Dory From rem-conf-request@es.net Mon Mar 07 20:35:34 1994 Received: from mothra.nts.uci.edu by osi-west.es.net via ESnet SMTP service id <24894-0@osi-west.es.net>; Mon, 7 Mar 1994 17:34:42 +0000 Received: by mothra.nts.uci.edu id AA00183 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 7 Mar 1994 17:34:35 -0800 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA00138 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 7 Mar 1994 17:34:16 -0800 Message-Id: <199403080134.AA00138@mothra.nts.uci.edu> X-Sender: dhwalker@mothra.nts.uci.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Mar 1994 17:34:25 -0800 To: Dory Ethan Leifer , Curtis Villamizar From: David Walker Subject: Re: VAT to Phone System Gateway? Cc: Allen Robel , rem-conf@es.net We are very interested in this kind of thing at UCI. It strikes me, though, that a single-port vat-PBX gateway could be made simply by connecting a workstation's microphone and speaker jacks to the telephone line's earphone and microphone of a phone by way of some electrical magic that I'm not qualified to comment on. It suspect that this would be easier than figuring out how to do voice over RS-232. Am I all wet? One would probably still need a modem to do dialing, answer calls, etc., switching between "voice" and "data" modes as appropriate. Clearly what Jon's working on is a much preferable way to put this together, but probably can't be done on a shoestring budget. David Walker Assistant Director, ECS Office of Academic Computing Addresses: Electronic Communication Services University of California, Irvine Irvine, CA 92717-5475 DHWalker@uci.edu (714) 856-7037 (voice) (714) 725-2270 (FAX) At 4:38 PM 3/7/94 -0500, Dory Ethan Leifer wrote: >Curtis - More clarification - There are modems that work with PC/Mac >voice mail packages that are available from lots of mail order >places. Both the signaling (AT extensions?) and digital voice >stream are encoded over the RS232 port. Question is if anyone >knows how the voice is encoded and are there any ad hoc standards >for these types of modems? > >Dory > >> >> > Another lower-tech possibility is using analog modems that pass >> > digital speech. Anyone know how this works? Does it just send >> > u-law PCM at 56K? >> > >> > Dory Leifer >> > University of Michigan >> >> Many PBXs, including some very low cost ones, have an out of band >> RS-232 control port with prorietary command set that supports this. >> Not that we want this purely acedemic discussion to encourage this >> sort of practice. ;-) >> >> Curtis From rem-conf-request@es.net Mon Mar 07 20:43:10 1994 Received: from mothra.nts.uci.edu by osi-west.es.net via ESnet SMTP service id <24964-0@osi-west.es.net>; Mon, 7 Mar 1994 17:42:46 +0000 Received: by mothra.nts.uci.edu id AA00467 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 7 Mar 1994 17:42:44 -0800 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA00450 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 7 Mar 1994 17:42:24 -0800 Message-Id: <199403080142.AA00450@mothra.nts.uci.edu> X-Sender: dhwalker@mothra.nts.uci.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Mar 1994 17:42:31 -0800 To: Dory Ethan Leifer , Allen Robel From: David Walker Subject: Re: VAT to Phone System Gateway? Cc: Jon Crowcroft , rem-conf@es.net What I'm interested in is a PBX replacement. I suspect there are not regulatory problems with that. David Walker At 4:46 PM 3/7/94 -0500, Dory Ethan Leifer wrote: >> Very cool Jon. This opens doors for FREE (well, as free as the Internet) >> around the world calling vat->phone, or even phone->vat->phone. Yikes! >> Hope they get those OC-12 links in the backbone installed soon ;-) >> > >Better check with the regulators, at least in the U.S. first. At one >time it was illegal to pass a local call through a private network >and then dump it back out as a local call without paying the local >telephone company interexchange access fees. Of course if you connect >the Internet to the local company using the right type of access trunks >(feature group D?) then you could actually "PIC" the Internet to be >your long distance carrier :) > >Dory From rem-conf-request@es.net Tue Mar 08 00:13:25 1994 Received: from gallery.ncb.gov.sg by osi-west.es.net via ESnet SMTP service id <26675-0@osi-west.es.net>; Mon, 7 Mar 1994 21:12:57 +0000 Received: by ncb.gov.sg (4.1/SMI-4.1) id AA15486; Tue, 8 Mar 94 13:14:46 SST Date: Tue, 8 Mar 1994 13:08:04 +0800 (SST) From: Tan Pow Hwee Subject: Re: vat for bsdi? (SoundBlaster support) To: Mike Bundschuh Cc: rem-conf@es.net In-Reply-To: <9403020151.AA22153@icestation.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Mar 1994, Mike Bundschuh wrote: > > Here's a quick question. In the CHANGES file, the following > comment is made regarding soundblaster cards: > > "- Change audio device model to support totally braindead, half-duplex > PC audio cards (like SoundBlaster)." > Someone told me an undocumented feature about PC Sound cards. Some sound cards (other than SB) actually has two sound board in it, one to maintain MS Sound System compatibility and the other for Sound Blaster compatibility. Therefore, in Windows, if you install both drivers, you can achieve full-duplex operation, ie. record and playback at the same time. A tried example was the Sound Galaxy sound card. Others like Pro Audio Spectrum, I believe, also support full-duplex operation. -- Tan, Pow-hwee National Computer Board, Singapore > Is there a version of vat that can run on bsdi and half-duplex cards > like the soundblaster? > > Thanks, > > ____________________________________________________ > > Michael Bundschuh > michael.bundschuh@sun.com > Audio Software Engineer, SunSolutions > > From rem-conf-request@es.net Tue Mar 08 01:44:45 1994 Received: from thresher.cs.washington.edu by osi-west.es.net via ESnet SMTP service id <27160-0@osi-west.es.net>; Mon, 7 Mar 1994 22:44:16 +0000 Return-Path: Received: from localhost (localhost [127.0.0.1]) by thresher.cs.washington.edu (8.6.4/7.1ws+) with SMTP id WAA14698; Mon, 7 Mar 1994 22:43:40 -0800 To: Tan Pow Hwee cc: Mike Bundschuh , rem-conf@es.net, savage@cs.washington.edu Subject: Re: vat for bsdi? (SoundBlaster support) In-reply-to: Your message of "Tue, 08 Mar 1994 13:08:04 +0800." Date: Mon, 07 Mar 1994 22:43:40 PST Message-ID: <14696.763109020@thresher.cs.washington.edu> From: Stefan Savage > Someone told me an undocumented feature about PC Sound cards. > Some sound cards (other than SB) actually has two sound board in it, one to > maintain MS Sound System compatibility and the other for Sound Blaster > compatibility. Therefore, in Windows, if you install both drivers, > you can achieve full-duplex operation, ie. record and playback at the > same time. A tried example was the Sound Galaxy sound card. Others like > Pro Audio Spectrum, I believe, also support full-duplex operation. My brief experience with trying to make this work was not positive. These cards are meant to provide compatibility with different hardware standards, not full duplex capability. The PAS for instance has two DAC's, but they cross in the mixer chip leading to _alot_ of feedback. There are some PC cards which do this right (one from Antex I think) but they're not mass market. - Stefan savage@cs.washington.edu From rem-conf-request@es.net Tue Mar 08 03:15:28 1994 Received: from csch.home.netcs.com by osi-west.es.net via ESnet SMTP service id <28089-0@osi-west.es.net>; Tue, 8 Mar 1994 00:14:51 +0000 Received: by csch.home.netcs.com (5.67a8+/1.2-eef) id AA10682; Tue, 8 Mar 1994 09:02:15 +0100 Return-Path: Message-Id: <199403080802.AA10682@csch.home.netcs.com> From: csch@csch.netcs.com (Clemens Schrimpe) To: allen@stone.ucs.indiana.edu, rem-conf@es.net Subject: VAT to Phone System Gateway? X-Mailer: ScoMail 1.0 Date: Tue, 8 Mar 1994 9:02:14 +0100 (MET) <> Has anyone thought about the issues involved in implementing a VAT to <> phone system gateway? I'm thinking that it might be possible to use, say, <> a Sparc with an ISDN interface as the gateway platform, but haven't really <> thought a lot about how VAT would need to be modified (if its even <> possible) to support something like this. Better yet, is anyone working <> on building this? :-) Since we (my company) have been in the ISDN business already for some years I brought up the idea a long time ago. But at that time Van Jacobsen was probably junked with mail regarding deeper information for VAT and he never responded - even to multiple queries. I than gave up. <> Is there an ISDN PRI interface for the Sparc so that multiple calls <> (incoming and outgoing could be supported? Hmmm... we have ISDN SW/HW for Sun Sparc, but currently only BRI, since our PRI board doesn't fit into a single SBus slot. But we offer full PRI access (for 30 B-channels/Europe or 23/U.S.) for PC/ISA/EISA and MC (thus for the RS6000) bus systems. I have two systems with a 30-channel PRI each installed here, ready and yearning for MBONE :-) I currently use them for IP-over-ISDN issues [o.k. - that's the main reason, why they are installed :-] but I also use them to make the Internet Talk Radio available to poor users without the bandwidth needed to get the files home. Will say: I already run a software, which allows you to "dial in" to ITR. Using ISDN, we have full access to the signaling of the network, which eases these tasks VERY MUCH! <> If so, is it relatively easy to access the individual DS0s (B-channels) to <> packetize them? Would a Sparc 10 be up to this for 24 DS0s? Probably not, if you use compression (GSM/LPC) - sending out bare A-law/U-law would probably work (keeping the Sparc busy though :-) <> I guess that you'd map local telephone numbers to IP addresses so that <> the gateway could route incoming calls to the proper recipient. As I said: I can use the signaling of the PSTN. After dialing my trunk access code you can dial up to 14 additional digits (this probably wouldn't work from foreign countries), which would be enough the represent an IP address. <> Sorry if this has been brought up before... No problem. Perhaps this time somebody shows some interest :-) Greetings from Berlin - Clemens Schrimpe, netCS Berlin -- INTERNET: csch@netcs.com WWW: http://www.netcs.com/PEOPLE/csch.html PHONE: +49-30-856 999-0 FAX: +49-30-855 52 18 From rem-conf-request@es.net Tue Mar 08 05:15:34 1994 Received: from charon.cwi.nl by osi-west.es.net via ESnet SMTP service id <28687-0@osi-west.es.net>; Tue, 8 Mar 1994 02:15:10 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id ; Tue, 8 Mar 1994 11:15:05 +0100 Received: by schelvis.cwi.nl with SMTP id AA09659 (5.65b/3.13/CWI-Amsterdam); Tue, 8 Mar 1994 11:15:04 +0100 Message-Id: <9403081015.AA09659=jack@schelvis.cwi.nl> To: rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-Reply-To: Message by Dory Ethan Leifer , Mon, 07 Mar 1994 16:38:23 -0500 , <199403072138.QAA14393@terminator.rs.itd.umich.edu> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Neil Young cover night (Paradiso, 5-3) X-Mini-Review: Great songs, and some good bands too! (Bonecrushing was great) Date: Tue, 08 Mar 1994 11:15:04 +0100 From: Jack Jansen Recently, Dory Ethan Leifer said: > > Curtis - More clarification - There are modems that work with PC/Mac > voice mail packages that are available from lots of mail order > places. Yes, but the ones I have come across (Zyxels) are half-duplex. They use a proprietary 3-bit ADPCM codec (but the specs are available), at at most 38K4. The sound quality is so-so, but the fact that they're half-duplex really killed the project. I resorted to getting my soldering iron out and putting together an interface between the (analog) phone line and my SGI audio port. Unfortunately, I didn't get the echo-compensation working, so the person on the other end of the phone hears a pretty bad echo. (this is a really difficult thing to get right, it involves a feedback circuit that should be tuned really well, obviously better than I was able to do). I've been told that in the US you can buy a module called a 'DA box', that should contain all the magic you need (optocouplers, echo-compensation), so you can just hook it to the phone line on one end and to your audio port on the other. (well, you need two digital signals for ring and offhook, but for that you can use the modemcontrol lines of an unused serial port:-). Unfortunately, I wasn't able to get them here in Holland, because with such a device it should be peanuts to build a vat-to-phone box. -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Tue Mar 08 05:34:07 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <28809-0@osi-west.es.net>; Tue, 8 Mar 1994 02:33:37 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Mar 1994 08:49:14 +0000 To: Dory Ethan Leifer cc: Allen Robel , rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of "Mon, 07 Mar 94 16:46:14 EST." <199403072146.QAA14505@terminator.rs.itd.umich.edu> Date: Tue, 08 Mar 94 08:49:09 +0000 From: Jon Crowcroft >Better check with the regulators, at least in the U.S. first. At one >time it was illegal to pass a local call through a private network >and then dump it back out as a local call without paying the local >telephone company interexchange access fees. Of course if you connect >the Internet to the local company using the right type of access trunks >(feature group D?) then you could actually "PIC" the Internet to be >your long distance carrier :) its not clear this can be enforced - the internet is not a 'private' network.... also, if i choose, i can record the voice, then send it .3 seconds later - thats voice mail, not a phone relay:-) jon From rem-conf-request@es.net Tue Mar 08 05:34:34 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <28809-1@osi-west.es.net>; Tue, 8 Mar 1994 02:33:44 +0000 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Mar 1994 09:08:32 +0000 To: Allen Robel cc: rem-conf@es.net, P.Kirstein@cs.ucl.ac.uk Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of "Mon, 07 Mar 94 14:10:01 EST." Date: Tue, 08 Mar 94 09:08:29 +0000 From: P.Kirstein@cs.ucl.ac.uk The use of the internet this way for normal telephone calls would be disasterours in some countries. First it is probably illegal in most; second, the international links are quickly saturated, and those providing us with internet bandwidth would be most unsympthetic to ANY attempt to increase it. It should be made clear that the UCL activity is designed to allow others to come into a multiplexed vAT session; there is no plan to allow any other use of UCL ISDN facilities for voice. Peter Kirstein In message you writ e: >I got some messages asking for clarification to my last posting about >"free" worldwide phone service. What I mean't was that, given the >facilities diagrammed below, any phone user could dial up any other phone >user (or VAT user) thru the Internet. > >TelephoneUser--LocalVatGW--Internet--LocalVatGW--TelephoneUser > >That is, if a mechanism were developed for local calls to the LocalVATGW >to be routed appropriately. So, if I wanted to call someone from Down >Under from Bloomington, IN (USA), the LocalVatGW would need to know the IP >address of the appropriate RemoteVatGW. This implies some sort of routing >between the VatGW's (possibly by associating country code + area code + >prefix to IP network??). Or, then again, we could always just stick with >our phones :-). > >allen > From rem-conf-request@es.net Tue Mar 08 08:21:37 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <00320-0@osi-west.es.net>; Tue, 8 Mar 1994 05:21:10 +0000 Received: from localhost (carl@localhost) by trystero.radio.com (8.6.5/940306.02ccg) id IAA22198; Tue, 8 Mar 1994 08:21:06 -0500 Date: Tue, 8 Mar 1994 08:21:06 -0500 From: Carl Malamud Message-Id: <199403081321.IAA22198@trystero.radio.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: VAT to Phone System Gateway? Cc: rem-conf@es.net Org: Internet Multicasting Service At one >time it was illegal to pass a local call through a private network >and then dump it back out as a local call without paying the local >telephone company interexchange access fees. its not clear this can be enforced - the internet is not a 'private' network.... Jon - Nonissue (as you said). We are already paying our access fees for both our local phone and for our dedicated lines into the Internet. Bridging the two together is perfectly legit. To actually make the link from workstation to POTS, we're using a device known as a "telephone interface" which is what radio stations use for talk shows. It adjusts the impedence characteristics of the two networks and lets you link a phone line into a mixing board (which in turn connects to the workstation). Lots of potential applications of this. We prefer to think of it as "integration" instead of "bypass." Hoping to have an interesting little test application up fairly soon. Carl From rem-conf-request@es.net Tue Mar 08 09:49:26 1994 Received: from interlock.ans.net by osi-west.es.net via ESnet SMTP service id <00972-0@osi-west.es.net>; Tue, 8 Mar 1994 06:49:01 +0000 Received: by interlock.ans.net id AA14925 (InterLock SMTP Gateway 1.1 for rem-conf@es.net); Tue, 8 Mar 1994 09:48:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 8 Mar 1994 09:48:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 8 Mar 1994 09:48:48 -0500 From: Curtis Villamizar Message-Id: <199403081447.AA94540@foo.ans.net> To: Carl Malamud Cc: J.Crowcroft@cs.ucl.ac.uk, rem-conf@es.net, curtis@ans.net Subject: Re: VAT to Phone System Gateway? In-Reply-To: (Your message of Tue, 08 Mar 94 08:21:06 EST.) <199403081321.IAA22198@trystero.radio.com> Date: Tue, 08 Mar 94 09:47:34 -0500 Strong Conjecture: There is nothing illegal about taking a leased line and using it as a private trunk between two PBX. There is also nothing illegal about using compression and an IP encoding to squeeze more effective capacity through that trunk. Strong Conjecture: If you offer that as a service for a fee, whether you use IP or not, you have a legal problem on your hands in most places. Conjecture: If you are leasing the trunk, (no IP service provider) and the PBXs are yours, it might be a good cost containment measure to compress voice, and IP unicast it between PBXs, decompress and delay compensate on the other end, _if_ suitable hardware exists and is not prohibitably expensive. (Even though saving a T1 can save a fair amount of money, I don't believe there is a cost effective solution yet due to the hardware cost of something capable of digitizing and compressing that much audio. But I do beleive it is quite feasible to boild something - any entrepeneurs out there?). Conjecture: If you traverse an IP service provider, your IP service provider might notice and get mad at you. They also might not notice and they also might not get mad at you if they did notice. IMO: ANS has plenty of T1 customers that saturate their T1 completely for hours at a time and probably wouldn't notice or care if they soaked the link and some of it was voice. If it were a soaked T3: a) ANS would notice, b) ANS would care. If enough non-NSF funded sites did this on T1 to make a difference, ANS would begin to notice and would care (we can't degrade NSF service and would have to add bandwidth to the core). *** Disclaimer ***: I'm neither a lawyer or a spokesperson for ANS. Random thought: If two major universities (both NSF funded) did this, Ma Bell's offspring might notice and things could get very interesting. Curtis PS - I hope this thread doesn't have a life of it's own. ;-) From rem-conf-request@es.net Tue Mar 08 16:21:08 1994 Received: from itd.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <06472-0@osi-west.es.net>; Tue, 8 Mar 1994 13:20:42 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27575; Tue, 8 Mar 94 16:20:39 EST From: mcdonald@itd.nrl.navy.mil (Daniel McDonald) Message-Id: <9403082120.AA27575@itd.nrl.navy.mil> Subject: WANTED: Papers on multicast congestion control To: rem-conf@es.net Date: Tue, 8 Mar 1994 16:20:37 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 210 Has there been any research into or implementation of congestion control in a multicast environment? I would appreciate any pointers to literature. Thanks, Dan McDonald ( {danmcd,mcdonald}@itd.nrl.navy.mil ) From rem-conf-request@es.net Tue Mar 08 22:35:56 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <09121-0@osi-west.es.net>; Tue, 8 Mar 1994 16:32:21 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 9 Mar 1994 10:31:46 +1000 To: P.Kirstein@cs.ucl.ac.uk cc: Allen Robel , rem-conf@es.net Subject: Re: VAT to Phone System Gateway? In-reply-to: Your message of "Tue, 08 Mar 1994 09:08:29 GMT." <9403081213.AA24156@wraith.internode.com.au> X-Mailer: exmh version 1.3beta 2/17/94 Date: Wed, 09 Mar 1994 10:31:43 +1000 Message-ID: <10133.763173103@brolga.cc.uq.oz.au> From: George Michaelson The use of the internet this way for normal telephone calls would be disasterours in some countries. First it is probably illegal in most; second, the international links are quickly saturated, and those providing us with internet bandwidth would be most unsympthetic to ANY attempt to increase it. It should be made clear that the UCL activity is designed to allow others to come into a multiplexed vAT session; there is no plan to allow any other use of UCL ISDN facilities for voice. I think there are two issues here. one is technical, the other regulatory. I would be most interested in knowing that for the usual range of platforms methods exist to improve interop between traditional telephony and the Internet preferrably using PD/Freely available solutions. That doesn't change the fact that DOING it in anger is questionable for a range of reasons. Also worth noting: the cost issues in telephony are complex and very different for each country and provider. Even with advantages like untimed local calls, My institution spends on average $100k Australian per month on combined local,STD,IDD and facimile bills, and if the local Internet can provide a route to cost savings on this (TPC-INT for instance in facimile) or even just cost-sharings, its worth knowing about. Internet-wide and down the long-haul fibres, very arguably no. onshore, to other academic institutions who could be talked to PABX-PABX via a tied line, I can see VERY positive reasons why yes. -George From rem-conf-request@es.net Wed Mar 09 01:39:32 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <12007-0@osi-west.es.net>; Tue, 8 Mar 1994 22:39:04 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 9 Mar 1994 16:38:32 +1000 To: Stefan Savage Subject: Re: vat for bsdi? (SoundBlaster support) cc: rem-conf@es.net In-reply-to: Your message of "Tue, 08 Mar 1994 22:13:37 PST." <25830.763193617@thresher.cs.washington.edu> Date: Wed, 09 Mar 1994 16:38:29 +1000 From: David Vu Message-ID: <"brolga.cc.uq:240350:940309063835"@cc.uq.oz.au> Well, to put it simply, the GUS is a very high-tech sound board at a low price. OK, let me give you some specs: 1 MEG onboard RAM for samples and patches, 32 independent stereo panable, hardware digital voices that's right not just two as on the PAS/SBpro or 1 on the SB stereo 8 bit or 16 bit 44.1kHz digital outputs with oversampling stereo/mono 8 bit recording standard, optional 48kHz 16-bit recording daughterboard (DAT compatible, ADPCM and other type hardware compression) real CD, very low noise, frequency response, >85dB dynamic range free high/low level SDK dedicated GUS anon ftp with multiple mirrors with lots of pd software. I have one, with the line out connected to my hifi. Very high quality digital sound output. There are also jumpers on the board to disconnect the mixing of the output and input, allowing you to record and playback (DUPLEX) at the same time without feedback and crosstalk. A hacker's soundboard IMHO. I believe there is a GUS driver for Linux and some other PC-UNIX's. RRP price in the US is about $120 with 256 k RAM. Street prices are lower of course. -David- Stefan Savage wrote: > I don't know much about the GUS. From rem-conf-request@es.net Wed Mar 09 08:34:18 1994 Received: from esusda.gov by osi-west.es.net via ESnet SMTP service id <16669-0@osi-west.es.net>; Wed, 9 Mar 1994 05:33:54 +0000 Received: by esusda.gov (AIX 3.2/UCB 5.64/26-eef) id AA16972; Wed, 9 Mar 1994 08:34:39 -0500 From: Everett Dowd Message-Id: <9403091334.AA16972@esusda.gov> Subject: Re: vat for bsdi? (SoundBlaster support) To: ccdvu@cc.uq.oz.au (David Vu) Date: Wed, 9 Mar 1994 08:34:39 -0500 (EST) Cc: savage@cs.washington.edu, rem-conf@es.net In-Reply-To: <"brolga.cc.uq:240350:940309063835"@cc.uq.oz.au> from "David Vu" at Mar 9, 94 04:38:29 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1221 Ok, where do we pick one up? David Vu writes: > > Well, to put it simply, the GUS is a very high-tech sound board at a low > price. > OK, let me give you some specs: > > 1 MEG onboard RAM for samples and patches, > 32 independent stereo panable, hardware digital voices > that's right not just two as on the PAS/SBpro or 1 on the SB > stereo 8 bit or 16 bit 44.1kHz digital outputs with oversampling > stereo/mono 8 bit recording standard, optional 48kHz 16-bit recording > daughterboard (DAT compatible, ADPCM and other type hardware > compression) > real CD, very low noise, frequency response, >85dB dynamic range > free high/low level SDK > dedicated GUS anon ftp with multiple mirrors with lots of pd software. > > I have one, with the line out connected to my hifi. Very high quality digital > sound output. There are also jumpers on the board to disconnect the mixing > of the output and input, allowing you to record and playback (DUPLEX) at the > same time without feedback and crosstalk. A hacker's soundboard IMHO. > > I believe there is a GUS driver for Linux and some other PC-UNIX's. > > RRP price in the US is about $120 with 256 k RAM. Street prices are lower > of course. From rem-conf-request@es.net Wed Mar 09 11:23:31 1994 Received: from watson.ibm.com by osi-west.es.net via ESnet SMTP service id <18297-0@osi-west.es.net>; Wed, 9 Mar 1994 08:06:55 +0000 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2615; Wed, 09 Mar 94 11:06:36 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 5705; Wed, 9 Mar 1994 11:08:18 EST Received: from zooey.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 09 Mar 94 11:08:15 EST Received: by zooey.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA26064; Wed, 9 Mar 1994 11:06:27 -0500 Date: Wed, 9 Mar 1994 11:06:27 -0500 From: jerryr@watson.ibm.com (Jerry Ratner) Message-Id: <9403091606.AA26064@zooey.watson.ibm.com> To: rem-conf@es.net Subject: test, please ignore just a test. From rem-conf-request@es.net Wed Mar 09 13:58:52 1994 Received: from bnl.gov by osi-west.es.net via ESnet SMTP service id <21074-0@osi-west.es.net>; Wed, 9 Mar 1994 10:58:20 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA09164; Wed, 9 Mar 94 13:58:18 -0500 Received: by sirius.ccd.bnl.gov (930416.SGI/930416.SGI) for @bnl.gov:rem-conf@es.net id AA00819; Wed, 9 Mar 94 13:58:16 -0500 From: Graham Campbell Message-Id: <9403091358.ZM817@sirius.ccd.bnl.gov> Date: Wed, 9 Mar 1994 13:58:15 -0500 Reply-To: gc@bnl.gov X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: rem-conf@es.net Subject: Colormap problems on Indy Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I am having lots of colormap problems on a new Indy. If I use the xstdcmap game, nv does not seem to use it, but tries to install a new map for which there is no room. So it displays in black and white. If I then start transmitting video and hit the button to send black and white, it aborts. If I start up xpsview (to avoid the wb hang), enough of the color map space gets eaten up to cause nv to use b/w. So I have to do this, then log out and back in. Can anyone offer any advice/help on how to deal with this? -- Graham gc@bnl.gov From rem-conf-request@es.net Wed Mar 09 17:50:32 1994 Received: from siggraph.org by osi-west.es.net via ESnet SMTP service id <24708-0@osi-west.es.net>; Wed, 9 Mar 1994 14:50:08 +0000 Received: from localhost (zaritsky@localhost) by siggraph.org (8.6.4/8.6.4) id QAA09927; Wed, 9 Mar 1994 16:49:17 -0600 Date: Wed, 9 Mar 1994 16:48:16 -0600 (CST) From: Raul Zaritzky Subject: Please add me To: rem-conf@es.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I would like to be included on your list. rem-conf@es.net Please, when you can, add me. Raul Zaritsky zaritsky@siggraph.org From rem-conf-request@es.net Wed Mar 09 20:10:47 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <01581-0@osi-west.es.net>; Wed, 9 Mar 1994 17:10:14 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14446(4)>; Wed, 9 Mar 1994 17:09:38 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Wed, 9 Mar 1994 17:09:46 -0800 To: gc@bnl.gov cc: rem-conf@es.net Subject: Re: Colormap problems on Indy In-reply-to: Your message of "Wed, 09 Mar 94 10:58:15 PST." <9403091358.ZM817@sirius.ccd.bnl.gov> X-Mailer: exmh version 1.3beta 2/17/94 Date: Wed, 9 Mar 1994 17:09:42 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Mar9.170946pst.16150@ecco.parc.xerox.com> In message <9403091358.ZM817@sirius.ccd.bnl.gov> you write: > I am having lots of colormap problems on a new Indy. If I use the xstdcmap > game, nv does not seem to use it, but tries to install a new map for which > there is no room. So it displays in black and white. If I then start > transmitting video and hit the button to send black and white, it aborts. > There was a bug in nv for doing greyscale sending which is probably still in the 3.2 that you have for the Indy right now. That's what is causing the crash. As for xstdcmap not working, nv _will_ use those colors, but it also wants some additional ones, and if it can't get them it drops to B&W. I'm working on a new dither which should look better and will hopefully be able to get by with fewer colors to avoid this problem. The way I suggest doing things is to start nv up fairly early so it stakes out its claim, and let other applications run after it. For many things, this works great, as they tend to eat lots of colors but will be happy with however few happen to be free.. (xv is like this) -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Mar 09 21:05:10 1994 Received: from exxilon.xx.rmit.EDU.AU by osi-west.es.net via ESnet SMTP service id <02049-0@osi-west.es.net>; Wed, 9 Mar 1994 18:04:47 +0000 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.6.Beta11/8.6.4/ram4) id MAA06272; Thu, 10 Mar 1994 12:59:12 +1100 From: "Richard A. Muirden" Message-Id: <199403100159.MAA06272@exxilon.xx.rmit.EDU.AU> Subject: Re: Colormap problems on Indy To: frederic@parc.xerox.com (Ron Frederick) Date: Thu, 10 Mar 1994 11:59:12 +1000 (EST) Cc: gc@bnl.gov, rem-conf@es.net In-Reply-To: <94Mar9.170946pst.16150@ecco.parc.xerox.com> from "Ron Frederick" at Mar 9, 94 05:09:42 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1194 > There was a bug in nv for doing greyscale sending which is probably still in > the 3.2 that you have for the Indy right now. That's what is causing the crash. yes, and it's a real pain too! :-) I had problems with that when I was running 5.1.1.1, but my problems were solved by the nice folks at SGI who compiled up a new Xserver for me, with the added benefit of having to NOT have to load xpsview before running wb (it fixed that bug), but it wouldn't let me run xpsview at all *laugh* However, the colormap problems seem to be mainly solved in th 5.1.1.3 patch, but NOT 5.1.1.2. Right now everything runs nicely for me. Now if only someone at SGI would listen for my requests for 5.2beta so I could run the new ivs port... > -- > Ron Frederick > frederick@parc.xerox.com -richard -- Richard A Muirden, Systems Administrator, Computer Centre, RMIT, Australia P. O. Box 2476V, Melbourne 3000, Vic, Australia | Tel: 660 3814 | Fax: 663 5652 Email: richard@rmit.EDU.AU | Fanatic of: Shostakovich, "Star Trek" etc :) Music Selection for This Week: Arnold: English/Irish/Scottish/Cornish Dances. ------------------------------------------------------------------------------- From rem-conf-request@es.net Thu Mar 10 01:45:51 1994 Received: from dworkin.wustl.edu by osi-west.es.net via ESnet SMTP service id <03694-0@osi-west.es.net>; Wed, 9 Mar 1994 22:45:28 +0000 Received: from localhost (zubin@localhost) by dworkin.wustl.edu (8.6.5/yuckCCRC) id AAA22707 for rem-conf@es.net; Thu, 10 Mar 1994 00:46:34 -0600 From: Zubin Dittia Message-Id: <199403100646.AAA22707@dworkin.wustl.edu> Subject: EXTENDED DEADLINE: March 25th --- ACM MULTIMEDIA 94 To: rem-conf@es.net Date: Thu, 10 Mar 1994 00:46:33 -0600 (CST) Organization: Washington University in St. Louis Phone: (314)-935-4163 (off), (314)-962-4176 (res) X-Z: I will not be pushed, filed, stamped, indexed, briefed, debriefed, X-Z: or numbered. My life is my own. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9889 NOTICE FOR EXTENSION OF DEADLINE -- ACM MULTIMEDIA 94 ----------------------------------------------------- Many potential participants have requested an extension on the submission deadline for ACM Multimedia 94. The conference committee has therefore decided to extend the submission deadline for papers, panels, courses, workshops, exhibits, videos and demonstrations. The new deadline is: **** MARCH 25 th, 1994 ****. _______________________________________________________________________ ACM MULTIMEDIA 94 ----------------- October 15-20, 1994, San Francisco, California THE SECOND ACM INTERNATIONAL CONFERENCE ON MULTIMEDIA Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS in cooperation with SIGAPP, SIGCAPH, SIGCPR, SIGMOD, SIGOPS, and the IEEE Communications Society. CALL FOR PARTICIPATION ACM Multimedia 94 will provide an international forum for papers, panels, courses, workshops, and exhibits focusing on the synergies between processing and communicating information represented in multiple media (multimedia). Research ideas, emerging technologies, engineering methodologies, prototype demonstrations, and experiences should be submitted for review. Technical areas for Multimedia 94 include, but are not limited to: applications and tools; video information systems; interactive television; collaboration environments; database and information systems; distributed systems; operating system extensions; hardware and architectures; networking and communication; media integration and synchronization; image, video and audio compression techniques; programming paradigms and environments; storage and I/O architectures; and user interfaces. PAPERS: ------- Technical papers, preferably accompanied by electronic and videotape software, on completed or in-progress research, innovative applica- tions, or experience with multimedia systems are solicited. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the talks. Outstanding papers on different areas of multimedia will be given awards. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, the Communications of the ACM (CACM), the ACT Transactions on Information Systems, or the IEEE/ACM Transactions on Networking. Submit six copies of each paper (no more than 15 double-spaced pages including figures, tables, and references) and four copies of any accompanying videotape to: Prof. Domenico Ferrari, Program Chair Computer Science Division EECS Department University of California Berkeley, CA 94720 USA. Voice: +1 510 642 3806 Fax: +1 510 642 5775 Email: multimedia94@tenet.berkeley.edu PANELS: ------- We are soliciting proposals for panels that examine an innovative, controversial, or otherwise provocative issue of interest to the field. Panel proposals should include the issue to be addressed, the members of the panel with a brief statement of their positions on the issue, and a description of the panel format. The best panels, in our experience, have been structured as a debate with an opportunity for audience participation, but we are open to other stimulating ideas. Panels consisting of a collection of short paper presentations are not encouraged. The Panel chair is willing to work with prospective session chairs in advance of submission to discuss panel concepts or the form of a proposal. Panel proposals should be at most 3 pages, and should include a brief description of each panelist's relevant expertise. Submit six copies of each panel proposal to: Allan Kuchinsky, Panels Co-Chair Hewlett-Packard Co. 1501 Page Mill Rd. M/S 1U-17 Palo Alto, CA 94304 USA. Voice: +1 415 857 7423 Fax: +1 415 857 8526 Email: kuchinsk@hpl.hp.com COURSES: -------- Proposals (at most 5 pages, including biographical sketches of instructors) for both 1/2- and 1-day tutorial courses are solicited. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit six copies of each course proposal to: Ephraim Glinert, Courses Chair Department of Computer Science and Engineering FR-35 University of Washington Seattle, WA 98195 USA. Voice: +1 206 543 4305 Fax: +1 206 543 2969 Email: glinert@cs.washington.edu WORKSHOPS: ---------- During the first two days of Multimedia 94, we would like to hold workshops on specific areas of multimedia research and technology. Evening sessions during the main conference (last three days) will be held to report on the results of the workshops. For more information, contact: D. Shepherd, Workshops Chair Computer Center University of Lancaster Lancaster, UK LA1 4YW. Voice: 44-52-459-3827 Fax: 44-52-484-4011 Email: doug@comp.lancs.ac.uk EXHIBITS: --------- ACM Multimedia 94 offers a unique opportunity for vendors and researchers to exhibit and demonstrate multimedia products and research prototypes. For more information, contact: Multimedia 94 Exhibit Sales c/o Danieli & O'Keefe Associates, Inc. 490 Boston Post Road Sudbury, MA 01776 USA. Voice: +1 508 443 3330 Ext. 1227 Fax: +1 508 443 4715 Email: DOK.Boston@applelink.apple.com DEMONSTRATIONS: --------------- As part of ACM Multimedia 94, we plan to hold a referreed technical and artistic demonstration program. We solicit working systems that demonstrate the essence of multimedia: the integration of technologies and media (e.g., computers, television, facsimile, communications/networking, databases, user interfaces, hypermedia, operating systems, virtual reality, data compression, interface hardware, publishing, etc.). Submissions (at most 4 pages) should consist of a description of the exhibit, demo requirements, biography, and a single VHS video. Electronic submission of the description is encouraged. Send submissions to: Tom Little, Demonstrations Chair Department of Electrical and Computer Engineering Boston University 44 Cummington Street Boston, MA 02215 USA. Voice: +1 617 353 9877 Fax: +1 617 353 6440 Email: tdcl@spiderman.bu.edu VIDEO: ------ We are solicting videos of innovative multimedia technology. Videotape submissions should be between 5 to 8 minutes, and should be accompanied by a 2 page overview. We expect to show the Multimedia 94 Video Program in a special room in the Conference Center during the conference, and the videotape will be available for purchase. For more information, contact: Marc Brown or Dave Redell, Video Co-Chairs DEC Systems Research Center 130 Lytton Ave. Palo Alto, CA 94301 USA. Voice: +1 415 853 2152 or 2131 Fax: +1 415 853 2104 Email: {mhb,redell}@src.dec.com ELECTRONIC PUBLISHING: ---------------------- The proceedings of Multimedia 94 will be available both on CD-ROM and via electronic network. Accepted papers will be expected to be finally provided in several formats including postscript, and authors are strongly encouraged to provide about 2 minutes of video and also software and other relevant information that complements the content of the paper. For more information, contact: Roy Rada, Electronic Publishing Chair Department of Computer Science University of Liverpool Liverpool, UK L69 3BX. Voice: 44-51-794-3669 Fax: 44-51-794-3715 Email: rada@compsci.liverpool.ac.uk ---------------------------------------------------------------------------- STUDENT PARTICIPATION: ---------------------- Papers with a student as the primary author can enter the student paper award competition. A cover letter must identify the paper as a candidate for the competition. Graduate and undergraduate students are invited to participate in Multimedia 94. Student volunteers receive complimentary registration, complimentary meals and the opportunity to interact with conference attendees in return for helping with day-to-day operations of the conference. Housing costs for student volunteers may be reduced by sharing hotel rooms. IMPORTANT DATES: ---------------- All submissions due: March 25, 1994. Notification of acceptance: June 10, 1994. Submissions in final form due: July 20, 1994. ---------------------------------------------------------------------------- CONFERENCE COMMITTEE: --------------------- Co-Chairs: J. O. Limb, Hewlett-Packard. M. Blattner, Lawrence Livermore National Laboratory and University of California, Davis. Steering Committee Chair: E. Fox, Virginia Polytechnic Institute and SU. Treasurer: R. Allen, Bellcore. Proceedings: J.J. Garcia-Luna, University of California, Santa Cruz. Workshops: D. Shepherd, Lancaster University, UK. Demonstrations: T. Little, Boston University. Video: M. Brown, Digital Equipment Corporation. D. Redell, Digital Equipment Corporation. Elec. Publishing: R. Rada, University of Liverpool, UK. Panels: A. Kuchinsky, Hewlett-Packard. S. Bulick, US WEST Advanced Technologies. Courses: E. Glinert, Renssaeler Polytechnic Institute. Local Arrangements: J.D. Smith, Lawrence Livermore National Laboratory. Publicity: G. Parulkar, Washington University in St. Louis. PROGRAM COMMITTEE: ------------------ Chair: Prof. Domenico Ferrari Computer Science Division EECS Department University of California Berkeley, CA 94720 USA. +1 510 642 3806 multimedia94@tenet.berkeley.edu Co-Chairs: S. Ahuja, AT & T Bell Laboratories. F. Kitson, Hewlett-Packard. T. Kunii, University of Aizu, Japan. R. Phillips, Los Alamos National Laboratory. R. Rada, University of Liverpool, UK. R. Sacks-Davis, University of Melbourne, Australia. From rem-conf-request@es.net Thu Mar 10 06:23:26 1994 Received: from citi.umich.edu by osi-west.es.net via ESnet SMTP service id <05256-0@osi-west.es.net>; Thu, 10 Mar 1994 03:23:04 +0000 Received: from citi.umich.edu by citi.umich.edu with SMTP; Thu, 10 Mar 94 06:22:37 -0500 From: wrh@citi.umich.edu To: rem-conf@es.net Date: Thu, 10 Mar 94 06:22:30 EST Subject: Please remove me from this list X-Mailer: exmh version 1.3beta 2/17/94 Sorry to bother the entire list but I'm trying to get off this mailing list and rem-conf-request@es.net does not show me listed. If anyone runs an exploder, please check for wrh@citi.umich.edu and remove me from the rem-conf list. Thanks very much. ---------------------------- | Bill Hampton | | Phone: (313) 747-4405 | | Email: wrh@citi.umich.edu | ---------------------------- From rem-conf-request@es.net Thu Mar 10 10:25:58 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <07041-0@osi-west.es.net>; Thu, 10 Mar 1994 07:25:28 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA03982; Thu, 10 Mar 94 07:25:27 PST Date: Thu, 10 Mar 94 07:25:27 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9403101525.AA03982@viipuri.nersc.gov> To: craig@aland.bbn.com Subject: re: How Long to a Multimedia Internet Cc: rem-conf@es.net [ Marketing style (ie oversimplified, non-techie) promo to com-priv deleted)] > But the result is that all >sorts of things like video on demand, voice and video calls from your desktop, >etc., will be available over the Internet. > > Of course, this isn't going to come immediately. The working groups >will kick off their first meetings the end of this month (at IETF in Seattle). >And their timetables call for starting to deliver proposed standards in late >1995. But deployment in the Internet can be quite brisk, so you might >conceivably see people other than researchers using the stuff sometime in 1996 > >Craig >(Chair of one of the soon-to-be-announced IETF WGs in this area) This is interesting... Would you care to elucidate on these "soon-to-be-announced IETF WGs" to the rem-conf list, who in a small way represent the first wave of folks interested in these issues? ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Thu Mar 10 11:07:32 1994 Received: from uu2.psi.com by osi-west.es.net via ESnet SMTP service id <07356-0@osi-west.es.net>; Thu, 10 Mar 1994 08:06:56 +0000 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA21154 for ari@es.net; Thu, 10 Mar 94 11:06:40 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA11661; Thu, 10 Mar 1994 08:05:29 -0800 Message-Id: <199403101605.IAA11661@aland.bbn.com> To: ari@es.net (Ari Ollikainen) Cc: craig@aland.bbn.com, rem-conf@es.net Subject: Re: How Long to a Multimedia Internet In-Reply-To: Your message of Thu, 10 Mar 94 07:25:27 -0800. <9403101525.AA03982@viipuri.nersc.gov> From: Craig Partridge Date: Thu, 10 Mar 94 08:05:25 -0800 Sender: craig@aland.bbn.com Ari: Well, I already did announce this to big-I. Sorry I didn't hit REM CONF. There are two working groups. One is announced (Bob Braden's on RSVP). The other is the Integrated Services working group (INT SERV), which I'm chairing, along with John Wroclawski, Scott Shenker and Dave Clark. INT SERV is focussed on determining what extensions to the Internet architecture are required to support multimedia and defining those extensions. First meetings on Monday at IETF. (As a BOF if for some reason the WG application isn't approved in time). Craig From rem-conf-request@es.net Thu Mar 10 13:17:23 1994 Received: from zephyr.isi.edu by osi-west.es.net via ESnet SMTP service id <09135-0@osi-west.es.net>; Thu, 10 Mar 1994 10:16:28 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 10 Mar 1994 10:16:25 -0800 Date: Thu, 10 Mar 1994 10:16:25 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199403101816.AA24490@zephyr.isi.edu> To: ari@es.net, craig@aland.bbn.com Subject: Re: How Long to a Multimedia Internet Cc: rem-conf@es.net *> *> There are two working groups. One is announced (Bob Braden's on RSVP). Bob Braden and Lixia Zhang are co-chairs of the RSVP working group. Bob Braden From rem-conf-request@es.net Thu Mar 10 13:48:18 1994 Received: from uu2.psi.com by osi-west.es.net via ESnet SMTP service id <09705-0@osi-west.es.net>; Thu, 10 Mar 1994 10:47:40 +0000 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA10047 for ari@es.net; Thu, 10 Mar 94 13:46:52 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA12030; Thu, 10 Mar 1994 10:45:39 -0800 Message-Id: <199403101845.KAA12030@aland.bbn.com> To: ari@es.net (Ari Ollikainen) Cc: craig@aland.bbn.com, rem-conf@es.net Subject: Re: How Long to a Multimedia Internet In-Reply-To: Your message of Thu, 10 Mar 94 07:25:27 -0800. <9403101525.AA03982@viipuri.nersc.gov> From: Craig Partridge Date: Thu, 10 Mar 94 10:45:36 -0800 Sender: craig@aland.bbn.com Ari et al., It was pointed out to me that my description of what INT SERV was up to is perhaps too broad. We're focussed on what has to happen in the *internetwork layer* to make guaranteed services happen. Craig From rem-conf-request@es.net Thu Mar 10 17:54:28 1994 Received: from mgate.uni-hannover.de by osi-west.es.net via ESnet SMTP service id <11434-0@osi-west.es.net>; Thu, 10 Mar 1994 14:54:09 +0000 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP) id <11823-0@mgate.uni-hannover.de>; Thu, 10 Mar 1994 23:51:25 +0100 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA03703; Thu, 10 Mar 94 23:50:57 +0100 Date: Thu, 10 Mar 94 23:50:57 +0100 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9403102250.AA03703@helios.tnt.uni-hannover.de> To: mbone@isi.edu, rem-conf@es.net, www-talk@info.cern.ch Subject: Who is exhibiting on CeBIT 94 fair? I am looking for exhibitors on CeBIT 94 fair in Hannover who are demonstrating advanced internet technology like MBone and World-Wide Web. During the time of CeBIT fair I will work for the Deutsche Messe AG as a scientific adviser. One of my jobs is to look around for interesting new products and write articles with a stronger technical background. These articles are handed out to the jounalists and shall give them some hints on where it is worth to look. I would like to make a special report on Internet services. If you are presenting such a service or know who does, please send me a short notice on where to meet you on CeBIT fair. Arnold From rem-conf-request@es.net Thu Mar 10 20:10:41 1994 Received: from stars.reston.paramax.com by osi-west.es.net via ESnet SMTP service id <13659-0@osi-west.es.net>; Thu, 10 Mar 1994 17:10:22 +0000 Received: from repos (repos.stars.reston.paramax.com) by aviary.Stars.Reston.Paramax.COM (4.1/mls/3.2) id AA21847; Thu, 10 Mar 94 20:11:15 EST Message-Id: <9403110111.AA21847@aviary.Stars.Reston.Paramax.COM> Received: by repos (4.1/mls/3.5) id AA00950; Thu, 10 Mar 94 20:06:38 EST Date: Thu, 10 Mar 94 20:06:38 EST From: perry@Stars.Reston.Paramax.COM To: rem-conf@es.net, wrh@citi.umich.edu Subject: Re: Please remove me from this list Cc: perry@stars.reston.paramax.com I too am tring to get off the list. I send a not to rem-conf-request and received back a not that I was taken off, but I still keep getting messages. dennis ----------------------------------- >From rem-conf-request@es.net Thu Mar 10 08:51:34 1994 Received: from osi-west.es.net by aviary.Stars.Reston.Paramax.COM (4.1/mls/3.2) id AA17172; Thu, 10 Mar 94 08:51:24 EST Message-Id: <9403101351.AA17172@aviary.Stars.Reston.Paramax.COM> Received: from citi.umich.edu by osi-west.es.net via ESnet SMTP service id <05256-0@osi-west.es.net>; Thu, 10 Mar 1994 03:23:04 +0000 Received: from citi.umich.edu by citi.umich.edu with SMTP; Thu, 10 Mar 94 06:22:37 -0500 From: wrh@citi.umich.edu To: rem-conf@es.net Date: Thu, 10 Mar 94 06:22:30 EST Subject: Please remove me from this list X-Mailer: exmh version 1.3beta 2/17/94 Status: RO Sorry to bother the entire list but I'm trying to get off this mailing list and rem-conf-request@es.net does not show me listed. If anyone runs an exploder, please check for wrh@citi.umich.edu and remove me from the rem-conf list. Thanks very much. ---------------------------- | Bill Hampton | | Phone: (313) 747-4405 | | Email: wrh@citi.umich.edu | ---------------------------- From rem-conf-request@es.net Thu Mar 10 23:02:07 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <14988-0@osi-west.es.net>; Thu, 10 Mar 1994 20:01:42 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA04639; Thu, 10 Mar 94 20:01:40 PST Date: Thu, 10 Mar 94 20:01:40 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9403110401.AA04639@viipuri.nersc.gov> To: perry@stars.reston.paramax.com Subject: Re: Please remove me from this list Cc: rem-conf@es.net > From rem-conf-request@es.net Thu Mar 10 18:20:01 1994 > Date: Thu, 10 Mar 94 20:06:38 EST > From: perry@Stars.Reston.Paramax.COM > To: rem-conf@es.net, wrh@citi.umich.edu > Subject: Re: Please remove me from this list > Cc: perry@stars.reston.paramax.com > Content-Length: 1265 > > I too am tring to get off the list. I send a not to rem-conf-request and > received back a not that I was taken off, but I still keep getting > messages. > You are off the list ... NOW! (You might remember that your request, included below, was sent last Sunday. Life, in the form of my kids interfered with list maintenance...so I deferred your request until I had some time to perform an update.) >From perry@Stars.Reston.Paramax.COM Sun Mar 6 11:44:30 1994 >Date: Sun, 6 Mar 94 14:40:40 EST >From: perry@Stars.Reston.Paramax.COM >To: rem-conf-request@es.net >Subject: unsubscribe >Cc: perry@stars.reston.paramax.com >Content-Length: 23 > > >please unsubscribe me > ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Fri Mar 11 00:09:01 1994 Received: from usc.edu by osi-west.es.net via ESnet SMTP service id <15560-0@osi-west.es.net>; Thu, 10 Mar 1994 21:08:34 +0000 Received: from catarina.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA21147; Thu, 10 Mar 94 21:08:33 PST Received: from catarina.usc.edu by catarina.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA04441; Thu, 10 Mar 94 21:11:21 PST Message-Id: <9403110511.AA04441@catarina.usc.edu> To: rem-conf@es.net Subject: NV on HP X-Mailer: exmh version 1.3beta 2/17/94 Date: Thu, 10 Mar 1994 21:11:18 -0800 From: "Danny J. Mitzel" quick question... is there a version of NV available anywhere that runs on the HP? thanks, danny (mitzel@catarina.usc.edu) From rem-conf-request@es.net Fri Mar 11 03:03:19 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <16974-0@osi-west.es.net>; Fri, 11 Mar 1994 00:02:57 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14507(1)>; Fri, 11 Mar 1994 00:02:32 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Fri, 11 Mar 1994 00:02:46 -0800 To: "Danny J. Mitzel" cc: rem-conf@es.net Subject: Re: NV on HP In-reply-to: Your message of "Thu, 10 Mar 94 21:11:18 PST." <9403110511.AA04441@catarina.usc.edu> Date: Fri, 11 Mar 1994 00:02:38 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Mar11.000246pst.16150@ecco.parc.xerox.com> In message <9403110511.AA04441@catarina.usc.edu> you write: > quick question... is there a version of NV available anywhere that > runs on the HP? > Geir Pedersen provided me with a frame grab routine for the HP, and I hope to integrate that into the nv 3.3 sources sometime soon. I have already put in the few other minor things that were needed to make nv compile properly receive-only, but I don't have any HP machines to test it on so it is possible some of the other recent changes have introduced some minor incompatibility. If anyone out there wants to try compiling the existing sources on the HP, let me know. If you have a VideoLive card, I should be able to soon provide you with a set of grabber sources as well. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Mar 11 04:29:29 1994 Received: from diable.upc.es by osi-west.es.net via ESnet SMTP service id <17372-0@osi-west.es.net>; Fri, 11 Mar 1994 01:29:11 +0000 Received: by diable.upc.es (4.1/SMI-4.1) id AA26970; Fri, 11 Mar 94 10:28:19 +0100 Date: 11 Mar 94 10:28 +0100 From: "Manuel A. Marin" To: rem-conf@es.net Message-Id: <179*M.Marin@si.upc.es> Subject: bit help I've IVS v3.2 for Sparc and Indy, my problem is when I select the 'encode video' botton in the ivs of the Indy, it say that doesn't open then indycam. initialy, the video driver is OK and also the ivs instalation. Any suggestion to solve this problem? Thanks in advanced. Manuel A. Marin From rem-conf-request@es.net Fri Mar 11 08:05:18 1994 Received: from fenris.dhhalden.no by osi-west.es.net via ESnet SMTP service id <18759-0@osi-west.es.net>; Fri, 11 Mar 1994 05:04:59 +0000 Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) id <13461-0@fenris.dhhalden.no>; Fri, 11 Mar 1994 14:04:47 +0100 Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.11); Fri, 11 Mar 94 14:04:33 GMT+1 Received: from MERCURY by SOFUS (Mercury 1.11); Fri, 11 Mar 94 14:04:09 GMT+1 From: Jardar Sunde Olsen Organization: Ostfold College To: rem-conf@es.net Date: Fri, 11 Mar 1994 14:04:00 +0100 Subject: Re: NV on HP Reply-to: jardarso@dhhalden.no Priority: normal X-mailer: PMail v3.0 (R1a) Message-ID: <346BE410EF@sofus.dhhalden.no> > quick question... is there a version of NV available anywhere that > runs on the HP? Yes, there is. I am running nv on my HP. I can both send and recieve jus fine. You can find a nv binary for HP (and several other workstations) on: ftp://aun.uninett.no/pub/misc/ipmulti/nv/ > thanks, Your welcome. :-) JardarSO jardarso@dhhalden.no From rem-conf-request@es.net Fri Mar 11 08:07:06 1994 Received: from mitsou.inria.fr by osi-west.es.net via ESnet SMTP service id <18769-0@osi-west.es.net>; Fri, 11 Mar 1994 05:06:36 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA28020; Fri, 11 Mar 1994 14:08:01 +0100 Message-Id: <199403111308.AA28020@mitsou.inria.fr> To: Craig Partridge Cc: ari@es.net (Ari Ollikainen), rem-conf@es.net Subject: Re: How Long to a Multimedia Internet In-Reply-To: Your message of "Thu, 10 Mar 1994 10:45:36 PST." <199403101845.KAA12030@aland.bbn.com> Date: Fri, 11 Mar 1994 14:08:00 +0100 From: Christian Huitema Craig, As I mentioned in Houston during the INT-SERV BOF, I don't think one should equate "Multimedia Internet" and "guaranteed services". Today's Internet is ill fitted to today's realtime multimedia applications, but there are certainly two possible approaches, i.e. adapt the net to the aplications and adapt the applications to the net. INT-SERV is clearly geared towards the first approach, but I think we can go quite far with the first one. Assuming there is some short term stability in the Internet (i.e. that there is a significant correlation with state of instant "t" and state at "t+dt"), one can certainly do a number of adaptations within the application, e.g. derive play-out buffers sizes from transit delays statistics or perform "congestion control" by adapting compression ratios to observed throughput. The assumption on the network is minimal - in fact, the same hypothesis are already assumed in the TCP "slow-start" and "congestion avoidance" algorithms. One of the challenge of INT-SERV should be to find a way to make it easier to adapt applications to the net IMHO. There are certainly ways to do it, e.g. unweighted fair queueing in the absence of reservations. Christian Huitema From rem-conf-request@es.net Fri Mar 11 08:47:48 1994 Received: from uu2.psi.com by osi-west.es.net via ESnet SMTP service id <19089-0@osi-west.es.net>; Fri, 11 Mar 1994 05:47:25 +0000 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05698 for rem-conf@es.net; Fri, 11 Mar 94 08:47:08 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id FAA12589; Fri, 11 Mar 1994 05:45:55 -0800 Message-Id: <199403111345.FAA12589@aland.bbn.com> To: Christian Huitema Cc: Craig Partridge , ari@es.net (Ari Ollikainen), rem-conf@es.net Subject: Re: How Long to a Multimedia Internet In-Reply-To: Your message of Fri, 11 Mar 94 14:08:00 +0100. <199403111308.AA28020@mitsou.inria.fr> From: Craig Partridge Date: Fri, 11 Mar 94 05:45:53 -0800 Sender: craig@aland.bbn.com As I mentioned in Houston during the INT-SERV BOF, I don't think one should equate "Multimedia Internet" and "guaranteed services". Today's Internet is ill fitted to today's realtime multimedia applications, but there are certainly two possible approaches, i.e. adapt the net to the aplications and adapt the applications to the net. INT-SERV is clearly geared towards the first approach, but I think we can go quite far with the first one. Hi Christian: Well, I'm only one of the chairs of INT SERV, but my expectation here is that INT SERV's goal is to modify our internetworking protocols (e.g., IP) by the minimum amount necessary to make high quality multimedia applications possible at reasonable cost. So we are not just adapting the network to applications, but also worrying about how much applications must be expected to adapt to the network. Craig From rem-conf-request@es.net Fri Mar 11 12:47:57 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <22478-0@osi-west.es.net>; Fri, 11 Mar 1994 09:47:41 +0000 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14439(6)>; Fri, 11 Mar 1994 09:47:19 PST Received: by redwing.parc.xerox.com id <57155>; Fri, 11 Mar 1994 09:47:25 -0800 Date: Fri, 11 Mar 1994 09:47:16 PST Sender: Lixia Zhang From: Lixia Zhang To: Christian.Huitema@sophia.inria.fr Subject: Re: How Long to a Multimedia Internet In-Reply-To: Your message of Fri, 11 Mar 1994 05:08:00 -0800 Cc: rem-conf@es.net Message-ID: > Assuming there is some short term stability in the Internet (i.e. that there > is a significant correlation with state of instant "t" and state at "t+dt"), > one can certainly do a number of adaptations within the application, e.g. > derive play-out buffers sizes from transit delays statistics or perform > "congestion control" by adapting compression ratios to observed throughput. > The assumption on the network is minimal - in fact, the same hypothesis are > already assumed in the TCP "slow-start" and "congestion avoidance" algorithms. Christian, fully agreement on that there are two approaches to multimedia internet. And IMHO I see them as complementary to each other. Multimedia applications often differ from traditional TCP data stream in their tolerable lower bound--a TCP data connection may be able to adapt its transmission rate from 0 on to max (whatever that is), while even adaptive multimedia typically have a lower bound that is well above 0 ... and this calls for network help to assure acceptable performance. > One of the challenge of INT-SERV should be to find a way to make it easier > to adapt applications to the net IMHO. There are certainly ways to do it, e.g. > unweighted fair queueing in the absence of reservations. FYI I played some toy simulation with this model and the story is a bit more complex than one's first perception :-) We can chat more at Seattle IETF. Lixia From rem-conf-request@es.net Fri Mar 11 14:39:02 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <27788-0@osi-west.es.net>; Fri, 11 Mar 1994 11:38:36 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA02025; Fri, 11 Mar 94 11:42:59 -0800 Received: from beo.heidelbg.ibm.com by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA22799; Fri, 11 Mar 94 09:31:51 -0800 Received: by beo.heidelbg.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA36398; Fri, 11 Mar 1994 16:23:18 +0100 From: ibmpa!beo.heidelbg.ibm.com!goebel@ibminet.awdpa.ibm.com (Thomas Goebel) Message-Id: <9403111523.AA36398@beo.heidelbg.ibm.com> Subject: IEEE JSAC special issue Synchronization Issues in MM Communications To: PP-Warning: Parse error in original version of preceding line Original-To: distribution.@beo.heidelbg.ibm.com@ibmpa.awdpa.ibm.com; (see end of body) Date: Fri, 11 Mar 1994 16:23:18 +0100 (MEZ) Content-Length: 3592 |||||||||||||| |||||||||||||||||||||||| |||||||||||||||||||||||||||||| | | | | ( | -------/ -------/ |) ( | (o) (o) | ) ( | ^ |) | / \ | /-------------------------\ \ o o / / hello, this is to remeber \ \ \ / / / the IEEE JSAC \ \ \\=============/<<<<<<<<< call for papers on | \ \=============/ / \ Synchronization Issues in / \ / \ Multimedia Communications / \ / \-------------------------/ +-----------\-/-----------+ | X | +-----------/-\-----------+ (PS. adapted from Michael Heinz, thanks.) CALL FOR PAPERS IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS SYNCHRONIZATION ISSUES IN MULTIMEDIA COMMUNICATIONS Multimedia systems can be defined as systems capable of creating, storing, retrieving and transporting data ("documents") composed of a variety of information formats ("media"), such as text, voice, graphics, image, audio and video. One of the most important problems that we face in multimedia communications is the synchronization of different components ("media") of a multimedia document, stored in distributed servers of a multimedia database, during transmission over a high-speed network (e.g., ATM) and for presentation on the display workstation. Similar problems arise during Computer Supported Collaborative Work (CSCW), when many users of multimedia workstations interact in a teleconferencing mode. Basically, the synchronization constraints come from the architecture of the multimedia document (MMD). As we use tools such as multimedia editors and authoring systems to create the MMD, we specify temporal constraints for the display of every medium and these constraints result into synchronization problems for the playback of the document. This issue will be devoted to the topic of Synchronization Issues in Multimedia Communications , as related to the topics listed below, or related subjects: -Multimedia Standards -Multimedia Applications -Authoring Systems -Visual Programming -Communication issues -Performance Evaluation -Multimedia Documents -Multimedia Database issues -Multimedia Toolkits -Multimedia Objects -Presentation -Multimedia Protocols -User Interfaces -Operating System -File Systems -Distribution -Distributed Algorithms -Quality of Service Prospective authors should send five(5) copies of their manuscript to one of the Guest Editors listed below. Submission Deadline: August 1, 1994 Notification of Acceptance: January 1, 1995 Final Manuscript Due: April 1, 1995 Publication: 4th Quarter 1995 Guest Editors Professor Nicolas D. Georganas Dept. of Electrical Engineering University of Ottawa P.O.Box 450, St. "A" Ottawa, Ontario, Canada, K1N 6N5 Tel: +1 613 564-3457 Fax: +1 613 564-9910 Internet: georgana@trix.genie.uottawa.ca Dr Ralf Steinmetz IBM European Networking Centre Vangerowstrasse 18 D-69115 Heidelberg, Germany Tel: +49 6221 594280 Fax: +49 6221 593400 Earn: steinmet@dhdibmip.bitnet Internet: kiwi.heidelbg.ibm.com!rst@ibmpa.awdpa.ibm.com Toru Nakagawa NTT Human Interface Laboratories 1-2356 Take Yokosuka Kanagawa, Japan Tel: +81 468 59 3820 Fax: +81 468 59 2332 %%% overflow headers %%% To: rajiv%ms.uky.edu@ibmpa.awdpa.ibm.com, rakow%darmstadt.gmd.de@ibmpa.awdpa.ibm.com, rama%gti.ssr.upm.es@ibmpa.awdpa.ibm.com, rao%tech.ascom.ch@ibmpa.awdpa.ibm.com, raynetintl%connectinc.com@ibmpa.awdpa.ibm.com, rba%bellcore.com@ibmpa.awdpa.ibm.com, rcbox%roke.co.uk@ibmpa.awdpa.ibm.com, rdi%ler.thomson.fr@ibmpa.awdpa.ibm.com, rebensburg%prz.tu-berlin.d400.de@ibmpa.awdpa.ibm.com, redell%src.dec.com@ibmpa.awdpa.ibm.com, reible%deteberkom.detecon.d400.de@ibmpa.awdpa.ibm.com, reibman%research.att.com@ibmpa.awdpa.ibm.com, reichel%freia.inf.tu-dresden.de@ibmpa.awdpa.ibm.com, reijo.juvonen%research.nokia.fi@ibmpa.awdpa.ibm.com, reimer%swssai.uu.ch@ibmpa.awdpa.ibm.com, rem-conf%es.net@ibmpa.awdpa.ibm.com, reuter%informatik.uni-stuttgart.de@ibmpa.awdpa.ibm.com, rgleaton@vnet.ibm.com, rhodgson%cix.compulink.co.uk@ibmpa.awdpa.ibm.com, rhp%ipsys.co.uk@ibmpa.awdpa.ibm.com, rich%cc.gatech.edu@ibmpa.awdpa.ibm.com, richard.marsden%rd.eng.bbc.co.uk@ibmpa.awdpa.ibm.com, rick%cs.arizona.edu@ibmpa.awdpa.ibm.com, riedl%hannibal.cs.umn.edu@ibmpa.awdpa.ibm.com, riglet%lep.lep-philips.fr@ibmpa.awdpa.ibm.com, rl%case.co.uk@ibmpa.awdpa.ibm.com, rmarcus%atc.boeing.com@ibmpa.awdpa.ibm.com, rmc%gandalf.inesc.pt@ibmpa.awdpa.ibm.com, rmerino%cc.unizar.es@ibmpa.awdpa.ibm.com, rmr%inesc.pt@ibmpa.awdpa.ibm.com, rnk%sei.cmu.edu@ibmpa.awdpa.ibm.com, robert.primrose%mari.co.uk@ibmpa.awdpa.ibm.com, roberto.minerva%cselt.stet.it@ibmpa.awdpa.ibm.com, roki%dfv.rwth-aachen.de@ibmpa.awdpa.ibm.com, roko%ensae.ericsson.se@ibmpa.awdpa.ibm.com, rolf_schuetze%m2tek.fido.de@ibmpa.awdpa.ibm.com, rolin%rennes.enst-bretagne.fr@ibmpa.awdpa.ibm.com, roman%cs.wustl.edu@ibmpa.awdpa.ibm.com, ronchett%phoenix.fatme.it@ibmpa.awdpa.ibm.com, ronr%dgp.utoronto.ca@ibmpa.awdpa.ibm.com, rothermel%informatik.uni-stuttgart.de@ibmpa.awdpa.ibm.com, rrhein%rcs.sel.de@ibmpa.awdpa.ibm.com, rsd%soton.ac.uk@ibmpa.awdpa.ibm.com, rtsai%e0sun3.ccl.itri.org.tw@ibmpa.awdpa.ibm.com, rudinger%uni-bonn.de@ibmpa.awdpa.ibm.com, rudolf.kuechler%sp1.y-net.dbp.de@ibmpa.awdpa.ibm.com, rudolph%ztivax.zfe.siemens.de@ibmpa.awdpa.ibm.com, s.dustdar%lse.ac.uk@ibmpa.awdpa.ibm.com, s.j.bruyn%bnr.co.uk@ibmpa.awdpa.ibm.com %%% end overflow headers %%% From rem-conf-request@es.net Fri Mar 11 14:51:57 1994 Received: from watson.ibm.com by osi-west.es.net via ESnet SMTP service id <27949-0@osi-west.es.net>; Fri, 11 Mar 1994 11:51:27 +0000 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8277; Fri, 11 Mar 94 14:51:25 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 2811; Fri, 11 Mar 1994 14:51:24 EST Received: from zooey.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 11 Mar 94 14:50:52 EST Received: by zooey.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA21128; Fri, 11 Mar 1994 14:50:49 -0500 Date: Fri, 11 Mar 1994 14:50:49 -0500 From: jerryr@watson.ibm.com (Jerry Ratner) Message-Id: <9403111950.AA21128@zooey.watson.ibm.com> To: rem-conf@es.net Subject: test; please ignore Sorry; please ignore. From rem-conf-request@es.net Fri Mar 11 15:42:02 1994 Received: from gatech.edu by osi-west.es.net via ESnet SMTP service id <29244-0@osi-west.es.net>; Fri, 11 Mar 1994 12:41:31 +0000 Received: from eedsp.gatech.edu (gauss.eedsp.gatech.edu) by gatech.edu with SMTP id AA29327 (5.65c/Gatech-10.0-IDA for ); Fri, 11 Mar 1994 15:40:26 -0500 Message-Id: <199403112040.AA29327@gatech.edu> From: Mat Hans Date: Fri, 11 Mar 1994 15:41:18 EST X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: casner@isi.edu, hgs@research.att.com, rem-conf@es.net Subject: RTP protocol Source-Info: From (or Sender) name not authenticated. I read the Internet Draft titled: "RTP: A Transport Protocol for Real-Time Applications", which expires on 12/31/93. Is there a recent document, and where can I get this document on Internet? I am currently developping an application sending audio and video over the network and therefore I am really interested in learning more about RTP. Thank you for your help. -- \|/ @ @ Mat Hans --------------------------o00-(_)-00o--------------------- begin 644 gt0567a@prism.gatech.edu.booby.trap.yes.it.is.gzipped.twice.gz.gz M'XL(`,>?#RP"`Y/OYF"8.9]?AXGY[<%&!B`XK##_)[/; Fri, 11 Mar 1994 13:31:14 +0000 Received: from john-bigboote.ics.uci.edu by paris.ics.uci.edu id aa02453; 11 Mar 94 13:31 PST To: rem-conf@es.net Subject: 4ISS Mbone broadcast April 8th Reply-To: Sam Horrocks Date: Fri, 11 Mar 1994 13:31:04 -0800 Message-ID: <14910.763421464@john-bigboote.ics.uci.edu> From: Sam Horrocks On Friday April 8th, we would like to broadcast the Fourth Annual Irvine Software Symposium from the University of California, Irvine. The Symposium would take place on Friday, April 8th, from 8AM to 5PM PDT (1500 to 000 GMT). We'd also like to do some testing of the channel on April 7th for a few hours in the evening. The broadcast would consist of both audio and video. The Fourth Annual Irvine Software Symposium is a symposium on current issues in software engineering, including software testing, engineering evironments and metrics. It's sponsored by the Irvine Research Unit in Software (IRUS). Does sending a message to this list reserve that time? Is there anything else I need to do before creating an Mbone session? If there is any discussion, please cc me in your replies, since I haven't yet been added to the rem-conf mailing list. Thanks, Sam Horrocks ICS Support Group, UC Irvine Email: sam@ics.uci.edu From rem-conf-request@es.net Fri Mar 11 16:45:16 1994 Received: from madhaus.utcs.utoronto.ca by osi-west.es.net via ESnet SMTP service id <00373-0@osi-west.es.net>; Fri, 11 Mar 1994 13:44:40 +0000 Received: from rathaus.utcs.utoronto.ca by madhaus.utcs.utoronto.ca (5.0/) id AA21192; Fri, 11 Mar 94 16:44:27 EST Date: Fri, 11 Mar 94 16:44:27 EST From: oattes@madhaus.utcs.utoronto.ca (Lee Oattes) Message-Id: <9403112144.AA21192@madhaus.utcs.utoronto.ca> To: rem-conf@es.net Subject: /kernel/drv/ip for mrouted 3.1? X-Sun-Charset: US-ASCII content-length: 696 I have just taken a kick at mrouted3.1beta on my Solaris 2.3 box. I can make all of the code compile with a few #ifdef SVR4 changes. However, I have run into a road block in that the "vifctl" structure has been changed (understandably) -- thus when making the setsockopt system call for DVMRP_ADD_VIF (in kern.c) the kernel (presumably the ip driver) goes "blech". Question: Does anyone out there (SUN?) have an ip driver that supports the new vifctl structures? lee ---- Lee Oattes, Network Development, University of Toronto Computing Services. 4 Bancroft Ave. Rm. 102, University of Toronto, Toronto, CANADA. M5S 1A1 E-MAIL:oattes@utcs.utoronto.ca PHONE:416 978 5448 FAX:416 978 6620 From rem-conf-request@es.net Fri Mar 11 17:56:41 1994 Received: from watson.ibm.com by osi-east.es.net via ESnet SMTP service id <03618-0@osi-east.es.net>; Fri, 11 Mar 1994 14:56:02 +0000 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2065; Fri, 11 Mar 94 17:49:13 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 0981; Fri, 11 Mar 1994 17:50:54 EST Received: from zooey.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 11 Mar 94 17:50:53 EST Received: by zooey.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA19391; Fri, 11 Mar 1994 17:49:07 -0500 Date: Fri, 11 Mar 1994 17:49:07 -0500 From: jerryr@watson.ibm.com (Jerry Ratner) Message-Id: <9403112249.AA19391@zooey.watson.ibm.com> To: rem-conf@es.net Subject: test; please ignore Sorry; just a test. From rem-conf-request@es.net Sat Mar 12 00:32:03 1994 Received: from grimaldi.rutgers.edu by osi-west.es.net via ESnet SMTP service id <04595-0@osi-west.es.net>; Fri, 11 Mar 1994 21:31:37 +0000 Received: from localhost (jim@localhost) by grimaldi.rutgers.edu (8.6.4+bestmx/8.6.4) id AAA14052; Sat, 12 Mar 1994 00:31:18 -0500 Date: Sat, 12 Mar 94 0:31:13 EST From: Jim Martin To: oattes@madhaus.utcs.utoronto.ca (Lee Oattes) Cc: rem-conf@es.net Subject: Re: /kernel/drv/ip for mrouted 3.1? In-Reply-To: Your message of Fri, 11 Mar 94 16:44:27 EST Message-ID: > > However, I have run into a road block in that the "vifctl" structure has been > changed (understandably) -- thus when making the setsockopt system call for > DVMRP_ADD_VIF (in kern.c) the kernel (presumably the ip driver) goes > "blech". Yep, as you suspected, there are kernel changes required for the additional functionality of mrouted 3.x. > Question: Does anyone out there (SUN?) have an ip driver that supports the > new vifctl structures? Actually, I think the change is needed in the kernel itself, "/kernel/unix". I'm planing on doing the kernel mods to the 2.3 kernel (or 2.3.2 or 2.4 or whatever they call 2.3++), but I've been asked by Steve Deering to hold off until the next mrouted 3.x release. He told me to expect it sometime in the next two weeks or so (but these things are always flexible.), and I hope to take a whack at it soon thereafter. The folks at Sun have expressed an interest in taking the changes back, so hopefully we can get it into a real Solaris release rather than having to keep hacking it in. Stay tuned.... Jim Jim Martin Internet: jim@noc.rutgers.edu Network Services UUCP: {backbone}!rutgers!jim Rutgers University Phone: (908) 932-3719 From rem-conf-request@es.net Sat Mar 12 12:53:41 1994 Received: from ctrvx1.Vanderbilt.Edu by osi-west.es.net via ESnet SMTP service id <12394-0@osi-west.es.net>; Sat, 12 Mar 1994 09:53:06 +0000 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V4.2-15 #3899) id <01H9VTJDM9QO8XJ9VQ@ctrvax.Vanderbilt.Edu>; Sat, 12 Mar 1994 11:49:49 CST Date: Sat, 12 Mar 1994 11:49:49 -0600 (CST) From: BEZALEL GAVISH Subject: 2nd Int. Coonf.. on Telecommunication Systems Conference Anouncement To: LISTOFLISTS:; Message-id: <01H9VTJDNLYQ8XJ9VQ@ctrvax.Vanderbilt.Edu> X-VMS-To: IN%LISTOFLISTS X-VMS-Cc: GAVISHB MIME-version: 1.0 Content-transfer-encoding: 7BIT CONFEREENCE ANOUNCEMENT 2nd INTERNATIONAL CONFERENCE on TELECOMMUNICATION SYSTEMS MODELLING AND ANALYSIS March 24-27, 1994, Nashville, TN SPONSORS: AT&T, Bell South, Motorola SatCom, Owen Graduate School of Management Program Committee: Jerome Chifflet -- CNET Guy Pujolle -- MASI \hfill &\cr Imrich Chlamtac -- UMass Amherst William W. Sharkey -- Bellcore \hfill &\cr Bezalel Gavish -- Vanderbilt U.(Chairman) David Simchi-Levi -- Columbia U. \hfill &\cr Andre Girard -- INRS-Telecom Edward A. Sykes -- U. Virginia \hfill &\cr Roch Guerin -- IBM Yutaka Takahashi -- Kyoto U. \hfill &\cr Richard Harris -- RMIT Dong-wan Tcha -- KAIST \hfill &\cr Konosuke Kawashima -- NTT Ward Whitt -- AT\&T \hfill &\cr Raif Onvural -- IBM James Yan -- BNR \hfill &\cr The Second International Conference on Telecommunication Systems, will be held on March 24-27, 1994 at the Owen Graduate School of Management, Vanderbilt University, Nashville, Tennessee. This accouncement contains the following sections 1. CONFERENCE HIGHLIGHTS 2. NASHVILLE INFORMATION 3. HOTEL RESERVATIONS 4. REGISTRATION 5. PROGRAM and SCHEDULE **************************************************************************** 1. CONFERENCE HIGHLIGHTS: KEYNOTE SPEAKER: Jun-ichi Mizusawa ``New Services Impacts on PSTN Architecture,'' NTT Telecommunication Networks Labs., Japan. LEAD SPEAKERS: Luigi Fratta - "Deflection Routing Networks Architecture," Politecnico di Milano, Italy. Gerard Hebuterne - "Traffic Control in ATM Networks: Existing and Tendencies," CNET, France. J. K. MacKie-Mason - "Pricing the Internet," University of California Energy Institute, Berkeley, Michel Minoux - "Multicommodity Network Flow Models and Decomposition Techniques for Telecommunication Network Applications," Universite Pierre et Marie Curie, France. Patrick L. Reilly - "Wireless LEOS Communications Networks: An Operations Researcher's, Applied Mathematicians, Engineer's Field of Dreams," Motorola SatCom, Ward Whitt - "Numerical Solution of M_t/G_t/1 Queues," AT\T Bell Laboratories, Copy of the Conference program and schedule is given later in this message. ********************************************************************** 2. NASHVILLE INFORMATION Nashville, Tennessee Famous as the Music City, U.S.A., Nashville is the home of Music Row, Opryland, the Grand Ole Opry, the Nashville Network, and many small clubs featuring country and popular music. A network of public parks spread over 6,650 acres is known as one of the nation's finest. Historic attractions include Bell Meade Plantation, the Belmont Mansion, and the Hermitage, home of Andrew Jackson. Climate Nashville in March is typical spring like weather, with daytime highs in the 60's and nighttime lows in the 40's. Rain is common during March and participants arre advised to bring raincoats/umbrellas. Conference Site Conference materials and registration will be held at the Owen Graduate School of Management, Vanderbilt University. Access to the Internet will be available through a local connection. The hotels are within walking distance of Vanderbilt University, Centennial Park, and many local eateries and Music Row. Technical sessions will be held at the Owen Graduate School of Management Vanderbilt University. Vanderbilt University is situated on 333 acres in the heart of Nashville, and boasts a park-like campus for a student body of nearly 9,000 undergraduate and graduate students. Transportation Gray Line Tours offer shuttles to the Hotel every 1/2 hour. The cost is $9.00 one way. Tickets and boarding are next to the baggage claim area at the Nashville Airport. If you drive or rent a car, covered parking is available in the Plaza for $5.00 (self-parked) or $7.00 (valet parked) per night. or across the Owen Graduate School of Management. Directions Exit the Airport onto I-40 West. Follow I-40 west 7 miles, then exit at the Broadway ramp. Turn left on Broadway from the access ramp, and drive 3 blocks to the split between Broadway and West End Avenue. Follow Broadway Avenue (bear left) past the split, the Owen Graduate School of Management is roughly half a mile down on the right, where Brodway becomes 21st Avenue. Directions for the hotels are: Follow West End Avenue (bear right) past the split. The Days Inn is 5 blocks from the split on the right, the Hampton Inn is on West End Avenue 3 blocks from the Days Inn, on the left side of West End Avenue. The Loews Vanderbilt Plaza is another 3 blocks down on the right, just past the 21st Avenue intersection. ***************************************************************************** 3. HOTEL INFORMATION %============================================================================ HOTEL INFORMATION Hotel Reservations The following is a list of Vanderbilt area hotels for your convenience. All hotels are within 5 to 10 minutes walking distance from the Owen School. The prices listed, while not guaranteed, will give you a general framework within which to work. With most of the hotels you will need to mention that you are a participant of the Telecommunication Systems Conference with the Owen School at Vanderbilt, with the exception of the Hampton Inn, in which you must give them the code name "TSC," to receive the best price. Our advice is to please make your reservations as soon as possible. ------------------------------------------------------------------- Loews Vanderbilt Plaza - (5 minutes walk) One of Nashville's Finest Luxury Hotels 2100 West End Avenue Nashville, TN 37203 615-320-1700 Approx $100 No Special Amenities Included ------------------------------------------------------------------- Hampton Inn - Vanderbilt - (5 minutes walk) Nice and Very Convenient (highley recommended by past users). Mention reservation code TSC when making the reservation. 1919 West End Avenue Nashville, TN 37203 615-329-1144 or 1-800-426-7866 $50.00 - $60.00 Special Amenities Include: - Free continental breakfast (breakfast cereals, muffins, fruit, yogurt, juices, donuts, etc.) - Free local phone calls - Free movies on Showtime - An exercise room --------------------------------------------------------------------------- Holiday Inn - Vanderbilt (10 minutes walk) 2613 West End Avenue Nashville, TN 37203 1-800-465-4329 $60 - $70 Special Amenities Include: - Exercise Facility - Complimentary Coffee ------------------------------------------------------------------------ Days Inn 1800 West End Avenue 1-800-325-2525 least expensive ***************************************************************************** 4. PROGRAM and SCHEDULE %============================================================================ 2nd INTERNATIONAL CONFERENCE on TELECOMMUNICATION SYSTEMS MODELLING AND ANALYSIS March 24-27, 1994, Nashville, TN Program and Schedule %============================================================================ Thursday - March 24, 1994 { 4:00 - 7:00} {Registration} -- on second floor of the Owen Graduate School of Management (OGSM). %=========================================================================== {SESSION 1:} Queueing Models in Telecommunications Session Chair: Michael Pinedo, Columbia University, NY. { 4:30 - 5:20} ``Numerical Solution of M_t/G_t/1 Queues,'' Gagan L. Choudhury, David M. Lucantoni, and {Ward Whitt}, AT\T Bell Laboratories, { 5:20 - 5:40} ``On the Stability of Multiclass Queueing Networks,'' Alexander L. Stolyar, Motorola, Inc., { 5:40 - 6:00} ``Simple Performability Bounds for Communication Networks,'' Nico M. van Dijk, University of Amsterdam, { 6:00 - 6:20} ``Modelling MAC Protocols in a Slotted Channel with Minislots,'' Graham Campbell, Miroslav Maramica, Illinois Institute of Technology; Michael J. McPheters, IIT/AT\T Laboratories, { 6:20 - 6:40} ``An Erlang Loss Formula-Based Approximation for Closed Queueing Network,'' Arie Harel, Su Hyeon Namn, Rutgers University, { 7:30 - 9:30} {Reception at the Gavish's residence}. Shuttle service will be available from OGSM to Gavish home, and back to the hotels. End Thursday End Thursday End Thursday End Thursday End Thursday End Thursday %============================================================================ Friday - March 25, 1994 {SESSION 2:} Keynote Session Session Chair: Konosuke Kawashima, NTT Telecommunication Networks Laboratory, { 8:30 - 8:40} Welcome { 8:45 - 9:40} Keynote address - ``New Services Impacts on PSTN Architecture,'' {Jun-ichi Mizusawa}, NTT Telecommunication Networks Labs., Japan. { 9:40 - 10:00}} {Coffee Break} %============================================================================ {SESSION 3:} Routing Analysis Session Chair: Andre Girard, INRS Telecommunications, Canada. {10:00 - 10:45} ``Deflection Routing Networks Architecture,'' {Luigi Fratta}, Politecnico di Milano, Italy. {10:50 - 11:00} ``On Circuit Switching with Alternate Routing and Link Failures,'' Nico M. van Dijk, University of Amsterdam, {11:00 - 11:20} ``Bifurcated Routing with Transition Costs,'' Anne De Jongh, Universite Libre de Bruxelles, {11:20 - 11:40} ``Non Convex Models for the Optimal Design of Packet Switched Network,'' Philippe Mahey, Laboratoire ARTEMIS-IMAG; Jerome Chifflet, CNET - Sophia Antipolis, {11:40 - 12:00} ``Multihour Dimensioning and Switching Costs,'' Andre Girard, INRS Telecommunications, {12:00 - 1:30} {Lunch Break} {12:00 - 1:30} {Telecommunication Systems Journal - Editorial Board Lunch} %=========================================================================== {SESSION 4:} ATM Networks Session Chair: Paul Nemirovsky, Network Planning, Sprint International. { 1:30 - 2:20} ``Traffic Control in ATM Networks: Existing and Tendencies,'' {Gerard Hebuterne}, and Annie Gravey, CNET, France. { 2:20 - 2:40} ``Statistical Multiplexing of Data ATM Connections,'' Jacqueline Boyer, CNET, France. { 2:40 - 3:00} ``Virtual Trees - A New Technique for Bandwidth Allocation in ATM Networks,'' Antonio Mock, and Adarshpal S. Sethi, University of Delaware. { 3:00 - 3:20} ``Performance Evaluation of a Simple Congestion Control at Burst Level for ATM Networks,'' J-M. Fourneau, MASI; V. Veque, and F. Quessette, Universite Paris-Sud; Leila Kloul, MASI, { 3:20 - 3:40} ``Dimensioning Traffic Control Devices in an ATM Network,'' Catherine Rosenberg, Ecole Polytechnique de Montreal; Gerard Hebuterne, CNET, {3:40 - 4:10} {Coffee Break} %=========================================================================== {SESSION 5:} Telecom Services (Parallel) Session Chair: Richard J. Harris, Royal Melbourne Institute of Technology { 4:10 - 4:30} ``A Flow Model for Computer Network Traffic Using Real-time Measurements,'' Madhu K. Acharya, IBM; Bharati Bhalla, Richard Newman-Wolfe, Haniph A. Latchman, Randy Chow, U. of Florida, { 4:30 - 4:50} ``Requirements Specification of Telecommunication Services Assisted by Case-Based Reasoning,'' Peter Funk, ELLEMTEL Telecom. Systems Labs; Dave Robertson, University of Edinburgh, { 4:50 - 5:10} ``TRACS: A Development Tool for Programming in a Networked Environment,'' Alberto Bartoli, P. Corsini, G. Dini, and Cosimo Antonio Prete, Universita' di Pisa, { 5:10 - 5:30} ``Applying the Object-Oriented Paradigm to Telecommunications Pricing,'' Phyllis A. Schneck, and Charles E. Vela, The MITRE Corporation, %=========================================================================== {SESSION 6:} Network Configuration Tools (Parallel) Session Chair: { 4:10 - 4:30} ``FOMENTOR: A Post Processor for MENTOR,'' Richard VanSlyke, O. Faruk Taplamaci, Polytechnic University, Brooklyn, { 4:30 - 4:50} ``A Methodology for Designing Large Hierarchical Networks,'' Kamel Barkaoui, Consevatoire National des Arts et Metiers; P. Mikoulinsky, TRT, { 4:50 - 5:10} ``Conception of a CATV Based MAN,'' Catherine Rosenberg, Daniel Gelinas, and Elias Haddad, Ecole Polytechnique de Montreal, { 5:10 - 5:30} ``Approximation Algorithms for Configuring Hierarchical Non- blocking Communication Networks,'' A. Fingerhut, Washington U., { 5:30 - 6:30} Distributed Group Decision Support System (CM$^3$) -- Demonstration in the PC Lab on the third floor of OGSM. { 7:00 - 8:30} Dinner at Jimmy Kelly's Restaurant, See instructions in the conference packet. End Friday End Friday End Friday End Friday End Friday End Friday End Friday %============================================================================ Saturday - March 26, 1994 %============================================================================ {SESSION 7:} Reliable Network Design - 1 Session Chair: Scott Rogers, University of Toronto { 8:30 - 9:20} ``Multicommodity Network Flow Models and Decomposition Techniques for Telecommunication Network Applications,'' {Michel Minoux}, Universite Pierre et Marie Curie, France. { 9:20 - 9:40} ``Design of Survivable Multicommodity Flow Networks,'' Geir Dahl, Norwegian Telecom Research; Mechthild Stoer, Konrad-Zuse-Zentrum fur Informationstechnik, Berlin, { 9:40 - 10:00} ``Performance Models for Reliable Network Design,'' Brunilde Sanso, V. N. Dang, Ecole polytechnique de Montreal; Andre Girard, INRS Telecommunications, {10:00 - 10:20} ``A Unified Performance-Reliability Model for B-ISDN,'' Richard J. Harris, and A. Tiku, Royal Melbourne Inst. of Tech., {10:20 - 10:40} {Coffee Break} %============================================================================ {SESSION 8:} Reliable Network Design - 2 (Parallel) Session Chair: Miguel A. Perez, Pontificia Universidad Catolica de Chile. {10:40 - 11:00} ``Reliable Network Design,'' Joseph Hui, Rutgers University; Yan-Jun Li, NYNEX Science and Technology, {11:00 - 11:20} ``Investigation of Network Performance in the Presence of Unreliable Components,'' Mary E. Helander, Northeastern U.; Robert Signorile, Boston College, {11:20 - 11:40} ``Node Reachability Estimation by Eavesdropping,'' Richard Kooijman, Technical University of Delft, {11:40 - 12:00} ``Modeling and Simulation of a Router-Based Wide-Area Network,'' Hong Jiang, Teyao Chen, Gabriel Sidler, and C. C. Lee, Northwestern University, %=========================================================================== {SESSION 9:} Distributed Data Bases (Parallel) Session Chair: {10:40 - 11:00} ``Atomic Delayed Replication in Databases for Intelligent Networks,'' K. Klabunde, Philips Research Laboratories Aachen; Ralf Nellessen, Rainer Gallersdoerfer, RWTH Aachen, {11:00 - 11:20} ``A Real-Time Database System for Telecommunication Applications,'' Brad Adelberg, Ben Kao, Stanford University; Hector Garcia-Molina, SUNY at Stony Brook, {11:20 - 11:40} ``PWRDB: Performance Analysis Workload Characterization Relational DataBase Tool,'' Denis McRae, Motorola, Inc., {11:40 - 12:00} ``Modelling and Analysis of a National Facsimile Delivery Service,'' M. Stone, University of Manitoba; Richard J. Harris, Royal Melbourne Institute of Technology, {12:00 - 1:30} Lunch served on the second floor of OGSM %=========================================================================== {SESSION 10:} Wireless and Cellular Communication - 1 Session Chair: Bezalel Gavish, Vanderbilt University { 1:30 - 2:20} ``Wireless LEOS Communications Networks: An Operations Researcher's Field of Dreams,'' {Patrick L. Reilly}, Motorola SatCom, { 2:20 - 2:40} ``Performance Model for Future Cellular Systems,'' Terje Jensen, The Norwegian Institute of Technology/Norwegian Telecom, { 2:40 - 3:00} ``Analysis of the Location Area Update Instability in Cellular Mobile Radio System,'' I. Arieh Cimet, Motorola, Inc., { 3:00 - 3:20} ``High Level Protocol Handling in Wireless WANs,'' Peter Peinl, Christoph Kroll, and Iris Neumeier-Mackert, IBM, Heidelberg, { 3:20 - 3:40} {Coffee Break} %=========================================================================== {SESSION 11:} Wireless and Cellular Communication - 2 (Parallel) Session Chair: { 3:40 - 4:00} ``Analysis of Performance Model for Cellular Networks with Multilayers and Multiclasses,'' Terje Jensen, The Norwegian Institute of Technology/Norwegian Telecom, { 4:00 - 4:20} ``Heavy Traffic Limit for a Mobile Phone System Loss Model,'' Alexander L. Stolyar, Motorola, Inc.; Burton Simon, University of Colorado at Denver; Philip J. Fleming, Motorola, Inc. { 4:20 - 4:40} ``Performance of Data Link Protocols over Cellular Networks,'' John DeDourek, Bernd Kurz, and Abdulaziz Hamad Al-Zoman, University of New Brunswick, { 4:40 - 5:00} ``T1 Data Communications on an Intelligent Ka Band Satellite: Initial Results from the ACTS Project,'' Hans Kruse, Ohio U. { 5:00 - 5:20} ``Evaluation of Call Set-UP Procedures in UMTS,'' Damian Lawniczak, Ericsson Eurolab Deutschland; Johan Dahlstrom, Ericsson Radio Systems, %=========================================================================== {SESSION 12:} Protocols (Parallel) Session Chair: Henrique Pacca Luna, Federal Univerrsity de Minas Geras. { 3:40 - 4:00} ``A High Performance Dual Token Passing Network for Time Critical Applications,'' Sajed Husein, Stefan Szumko, and Mike E. Woodward, Loughborough University of Technology, { 4:00 - 4:20} ``A Discrete-time, Fixed Point Approximation Model for the Orwell Protocol,'' K. R. S. Rodrigo, and Mike E. Woodward, Loughborough University of Technology, { 4:20 - 4:40} ``Explicit Congestion Notification in Broadband Network,'' Steven Low, AT\T Bell Labs; Nina T. Plotkin, James Yee, University of California, Berkeley; Michael K. Wong, AT\T Bell Laboratories, { 4:40 - 5:00} ``A Combination of Mechanisms for Effective Congestion Management in Switched High-Speed Networks,'' Andrea F. Lobo, Florida Atlantic U.; Adarshpal S. Sethi, University of Delaware; { 5:00 - 5:20} ``GTPN Model of the Network Monitor Beholder,'' Richard Kooijman, and D. M. Wisse, Technical University of Delft, { 5:30 - 6:30} Distributed Group Decision Support System (CM$^3$) -- Demonstration in the PC Lab on the third floor of OGSM { 6:30 - 8:45} Reception and Dinner at the University Club { 9:30 - 11:30} {Grand Ole Opry}, A shuttle will be available from the Univerity Club to the Grand Ole Opry, and back to the hotels after the performance. End Saturday End Saturday End Saturday End Saturday End Saturday End Saturday %============================================================================ Sunday - March 27, 1994 %=========================================================================== {SESSION 13:} Economics of Telecommunications - 1 Session Chair: W. W. Sharkey, Bellcore, { 8:30 - 9:10} ``Pricing the Internet,'' Hal Varian, University of Michigan; {Jeffrey K. MacKie-Mason}, University of California Energy Institute, Berkeley, { 9:10 - 9:30} ``A Rate Allocation Algorithm for Computer Networks with Non-myopic and Manipulative Privately Informed Users,'' Bhaskar Chakravorti, Bellcore, { 9:30 - 9:50} ``A Unifying Efficient Characterization of Some Cost Allocation Solutions Associated with Capacitated Network Design Problems,'' Darko Skorin-Kapov, and Hector Fernando Beltran, SUNY at Stony Brook, { 9:50 - 10:10} {Coffee Break} %=========================================================================== {SESSION 14:} Economics of Telecommunications - 2 (Parallel) Session Chair: W. W. Sharkey, Bellcore, {10:10 - 10:30} ``Deciding on Priority Rankings and Prices Under Externalities for Packet Switched Networks,'' Ashok Srinivasan, and Kemal Altinkemer, Purdue University, {10:30 - 10:50} ``A Cable Television Financial Model with Analysis of the 1993 Rate Regulations,'' Kent Webb, San Jose State and U.C. Berkeley Extension, {10:50 - 11:10} ``Service Shadow Price and Link Shadow Price,'' Joseph Hui, Rutgers University; Yan-Jun Li, NYNEX Science and Technology, {11:10 - 11:30} ``On Minimum Cost Isolated Failure Immune Networks,'' Hector Fernando Beltran, and Darko Skorin-Kapov, SUNY at Stony Brook, %=========================================================================== {SESSION 15:} Network Interconnection (Parallel) Session Chair: June SS. Park, University of Iowa. {10:10 - 10:30} ``Optimal Design of Reliable Local Internets Using Source Routing Bridges,'' V. Sridhar, The University of Iowa; Bezalel Gavish, Vanderbilt University; June S. Park, The University of Iowa, {10:30 - 10:50} ``Optimal Design of Reliable Local Internets Using Transparent Bridges,'' June S. Park, Fred Kaefer, and V. Sridhar, The University of Iowa, {10:50 - 11:10} ``A Simulated Annealing Algorithm for LANs Interconnection Networks Design,'' Nicolas Boissin, Alain Sutter, and Olivier Strilka, CNET, France Telecom, {11:10 - 11:30} ``Optimizing GSM Network Component Location,'' Kieran Brennan, Dublin City University, %=========================================================================== {SESSION 16:} Network Design Algorithms (Parallel) Session Chair: Larry J. LeBlanc, Vanderbilt University. {10:10 - 10:30} ``Routing in Backbone Networks with Response-Time-Dependent Offered Traffic,'' Larry J. LeBlanc, Vanderbilt University; Sridhar Narasimhan, Georgia Institute of Technology; Bin Ran, University of California at Berkeley, {10:30 - 10:50} ``Multicommodity Flows Formulations and Minimal Spanning Trees with Hop Constraints,'' Luis Gouveia, Faculdade de Ciencias da Universidade de Lisboa, {10:50 - 11:10} ``A Multiperiod Capacity Planning Model for a Local Access Network,'' Rakesh Kawatra, Mankato State University, {11:10 - 11:30} ``Reformulation and Column Generation for Several Telecommunication Network Design Problems,'' Dong Shaw, Purdue University, {11:30 - 12:00} {Closing Session} ***************************************************************************** 5. REGISTRATION FORM %============================================================================ %============================================================================ CUT HERE CUT HERE CUT HERE CUT HERE CUT HERE CUT HERE CUT HERE %============================================================================ %============================================================================ 2nd INTERNATIONAL CONFERENCE on TELECOMMUNICATION SYSTEMS MODELLING AND ANALYSIS March 24-27, 1994, Nashville, TN REGISTRATION FORM Name:__________________________________________ Title:_______________________ Affiliation:_________________________________________________________________ Address:_____________________________________________________________________ _____________________________________________________________________ Country:_____________________________ Zip Code:______________________________ Phone:_______________________________ FAX:___________________________________ Email:_______________________________________________________________________ Registration Rates and Deadlines: Last Applicable Academic Industry Date Rate Rate -------------- -------- -------- Registration: March 21, 1994 $ 450 $ 650 * On Site Registration: $ 595 $ 895 * Advance notification by Email, phone or FAX is advised, as the number of on site registrants is limited. Mail your registration form and check to: Mrs Dru Mace Owen Graduate School of Management Vanderbilt University Nashville, TN 37203 USA Tel: (615) 322-3694 FAX: (615) 343-7717 Email: MACED@CTRVAX.VANDERBILT.EDU The check should be addressed to: 2nd Int. Telecom. Systems Conference Refund Policy: No refunds after February 15, 1994. %============================================================================ %============================================================================ BYE  ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Tel: (615) 322-3659 FAX: (615) 343-7177 ------------------------------------------------------------------------------- From rem-conf-request@es.net Sat Mar 12 14:19:16 1994 Received: from dynamo.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <12671-0@osi-west.es.net>; Sat, 12 Mar 1994 11:18:53 +0000 Received: from localhost by dynamo.ecn.purdue.edu (5.65/1.32jrs) id AA16269; Sat, 12 Mar 94 14:18:50 -0500 Message-Id: <9403121918.AA16269@dynamo.ecn.purdue.edu> To: rem-conf@es.net Subject: Help with mrouted messages Date: Sat, 12 Mar 1994 14:18:49 EST From: "David A. Curry" I have mrouted's configured on my network as follows. There's one primary mrouted that talks to the rest of the world (a guy in another department), several secondary ones (one in each department on our net) that talk to my primary one, and then several tertiary ones on various subnets in each department, in a tree hierarchy: MBONE | the guy in the other department | mine-01 __________/ | \__________ / | \ mine-02 mine-03 mine-04 / | \ / | \ / | \ mine05 | mine07 | ....... ....... mine06 Over the last week or so, all my mrouted's have been spitting out the following sorts of error messages. Sometimes they just do it a few times and then shut up; this weekend they started just continuously spewing the messages: Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (198.93.168.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (198.93.168.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (192.135.245.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (192.135.245.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (192.31.7.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (192.31.7.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (131.108.236.0) and mask (ffffff00) Mar 12 13:57:22 solaris.ecn.purdue.edu mrouted[183]: warning - 128.210.67.25 reports a conflicting origin (131.108.236.0) and mask (ffffff00) The above are from "mine-01" in the picture, with 128.210.67.25 being "the guy in the other department". The subordinate mrouted's say that the mrouted above them in the hierarchy is reporting the problem. I think I sort of understand what the message is complaining about, but I don't understand what's actually causing the problem. Do these messages mean: - I screwed up and shouldn't do mrouted's this way? - One or more of my mrouted's is confused and needs to be restarted? - The mrouted upstream from me is confused and needs to be restarted? - Someone out in mbone-land screwed up big-time? - Something else? Any help in figuring out what's wrong (and getting it fixed) would be appreciated. For now I just turned off my primary mrouted, which is obviously not a very good long-term solution. Thanks, Dave Curry Purdue University Engineering Computer Network From rem-conf-request@es.net Sat Mar 12 18:06:36 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <13766-0@osi-west.es.net>; Sat, 12 Mar 1994 15:06:19 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Sat, 12 Mar 1994 15:06:17 -0800 Posted-Date: Sat 12 Mar 94 15:05:23 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 12 Mar 94 15:05:24 PST Date: Sat 12 Mar 94 15:05:23 PST From: Stephen Casner Subject: Re: Help with mrouted messages To: davy@ecn.purdue.edu, rem-conf@es.net Message-Id: <763513523.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9403121918.AA16269@dynamo.ecn.purdue.edu> Mail-System-Version: Dave, The "conflicting origin and mask" warnings you are seeing are caused by an engineering field test of the experimental "PIM Dense-Mode" multicast routing protocol in cisco routers at a few sites. Some problems have been observed in the coupling of DVMRP (in mrouted) with PIM. I have sent a message to the participants in the test asking that the coupling be severed temporarily at those sites that are causing the conflicting routes to be introduced. These warning messages do not imply anything is wrong with your installation. -- Steve ------- From rem-conf-request@es.net Sun Mar 13 14:46:05 1994 Received: from leland.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <11802-0@osi-west.es.net>; Sun, 13 Mar 1994 11:45:46 +0000 Received: from popserver.Stanford.EDU (popserver.Stanford.EDU [36.21.0.17]) by leland.Stanford.EDU (8.6.5/8.6.5) with ESMTP id LAA23503; Sun, 13 Mar 1994 11:45:43 -0800 From: aubrey harris Received: from DialupEudora (tip-forsythe.Stanford.EDU [36.170.0.21]) by popserver.Stanford.EDU (8.6.5/8.6.5) with SMTP id LAA06571; Sun, 13 Mar 1994 11:45:34 -0800 Date: Sun, 13 Mar 1994 11:45:34 -0800 Message-Id: <199403131945.LAA06571@popserver.Stanford.EDU> To: rem-conf@es.net Subject: Deparately Trying to Escape Cc: na.aha@forsythe.Stanford.EDU Sorry to bother the entire list but I'm trying to get off this mailing list and rem-conf-request@es.net does not show my account as listed. If anyone runs an exploder, would you mind please checking for AHARRIS@LELAND.STANFORD.EDU and remove me from the rem-conf list. Many thanks Aubrey Harris aharris@leland.stanford.edu 415-725-7331 From rem-conf-request@es.net Mon Mar 14 07:16:01 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <17332-0@osi-west.es.net>; Mon, 14 Mar 1994 04:15:43 +0000 Received: from focushope.edu ([192.195.252.75]) by merit.edu (8.6.5/8.6.5) with SMTP id HAA24238; Mon, 14 Mar 1994 07:15:39 -0500 Received: from mailer.focushope.edu by focushope.edu (4.1/SMI-4.1) id AA03465; Mon, 14 Mar 94 07:13:08 EST Received: from video1.CAT.engr by mailer.focushope.edu (4.1/SMI-4.1) id AA02465; Mon, 14 Mar 94 07:17:14 EST Received: by video1.CAT.engr (5.0/SMI-SVR4) id AA00344; Mon, 3 Jan 1994 19:46:09 +0800 Date: Mon, 3 Jan 1994 19:46:09 +0800 From: kumarv@video1.focushope.edu (Vinay Kumar - EIT @ mailhost) Message-Id: <9401040346.AA00344@video1.CAT.engr> To: rem-conf@es.net Subject: Focus:HOPE Mbone Sessions Cc: bjs@video1.focushope.edu, harari@eit.com, kumarv@video1.focushope.edu X-Sun-Charset: US-ASCII Content-Length: 868 To: Mbone/ Rem-Conf Listeners: I apologize for this late notification for reservation of an Audio/Video Channel on Mbone. I would like to reserve two channels: Focus:HOPE Audio: 224.22.16.94, ttl 127; and Focus:HOPE Video: 224.2.145.84, ttl 127 There is no specific agenda for this demo here, however, feel free to tune-in to the two channels, and say hello to G-7 Job Summit Visitors here at Focus:HOPE, in Detroit, Michigan, USA. However, being good citizen's of Mbone, make sure you don't send too many sources of high-data rate video simultaneously. From our end, we will not be able to send in video since i am on a Soalris2.3 m/c with XIL libraries, and i am given to believe that there are no nv-with-send binaries available yet. Regards --- Vinay Kumar Enterprise Integration Technologies for Focus:HOPE kumarv@focushope.edu | vinay@eit.com From rem-conf-request@es.net Tue Mar 15 08:02:21 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <00922-0@osi-west.es.net>; Tue, 15 Mar 1994 05:01:55 +0000 Via: uk.ac.hertfordshire.helios; Tue, 15 Mar 1994 12:22:25 +0000 Received: from altair.herts.ac.uk by helios.herts.ac.uk with SMTP (PP) id <03186-0@helios.herts.ac.uk>; Tue, 15 Mar 1994 10:23:09 +0000 From: J.Angel@hertfordshire.ac.uk Date: Tue, 15 Mar 94 10:25:56 GMT Message-Id: <26638.9403151025@altair.herts.ac.uk> To: rem-conf@es.net Subject: mrouted3.1 Sender: J.Angel@hertfordshire.ac.uk Can anyone help please. I would like to connect to MBONE and am looking for a binary copy of mrouted3.1 to run on SGI Indigo 4.05F. I can get hold of the sources, but unfortunately have no c complier yet. Any offer will be greatly appreciated. Judy Angel University of Hertfordshire J.Angel@herts.ac.uk From rem-conf-request@es.net Tue Mar 15 11:26:31 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <02226-0@osi-west.es.net>; Tue, 15 Mar 1994 08:26:16 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14478(6)>; Tue, 15 Mar 1994 08:25:43 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 15 Mar 1994 08:25:50 -0800 To: ietf@cnri.reston.va.us, rem-conf@es.net Cc: stjohns@arpa.mil, deering@parc.xerox.com Subject: HPCC Symposium sessions to be multicast Date: Tue, 15 Mar 1994 08:25:41 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Mar15.082550pst.12171@skylark.parc.xerox.com> We are planning to multicast the audio and video (and maybe some wb) from two more sessions of ARPA's High Performance Computing and Communications Symposium, tomorrow (Wednesday). The session agendas are as follows: 10:30 - 12:00 EST (1530 - 1700 GMT) NEW INTERNET SERVICES (chair: Mike St. Johns) Dave Clark, MIT - New Services for the Internet of Tomorrow Steve Deering, Xerox PARC - Internet Multicasting M. Satyanarayanan, CMU - Mobile Computing in the Internet Mike Schwartz, UColorado - Internet Publishing and Discovery 13:30 - 15:00 EST (1830 - 2000 GMT) LESSONS FROM THE EVOLUTION OF THE INTERNET (chair: Mike St. Johns) Vint Cerf, ISOC Dan Lynch, Interop Dain Gary, CERT Stephen Squires, ARPA Look for the session advertisements in sd, under the name "ARPA HPCC Symposium". Steve From rem-conf-request@es.net Wed Mar 16 01:58:21 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <12946-0@osi-west.es.net>; Tue, 15 Mar 1994 22:58:00 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 15 Mar 1994 22:57:53 -0800 Posted-Date: Tue 15 Mar 94 22:56:55 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 15 Mar 94 22:56:56 PST Date: Tue 15 Mar 94 22:56:55 PST From: Stephen Casner Subject: 2nd Call for Papers: Packet Video To: rem-conf@es.net Message-Id: <763801015.0.CASNER@XFR.ISI.EDU> Mail-System-Version: I would particularly like to encourage those of you working on video over the Internet to notice that area of interest in the following CFP, and to invite your participation. -- Steve Casner ************************************************************************ SECOND CALL FOR PAPERS Sixth International Workshop on PACKET VIDEO September 26-27, 1994 Portland, Oregon, USA The Sixth International Workshop on Packet Video (PV) will be held from September 26 to 27 in Portland, Oregon. It will follow the Picture Coding Symposium (PCS) to be held in Sacramento, California from September 21-23. The objective of the Workshop is to provide a forum for discussion of new and recent results or ideas on video services for packet switched networks, including the applicability of evolving MPEG2/H.26X video coding standards for such services. In order to preserve its characteristic as a workshop, active participation of the attendees in the meeting is encouraged. Authors are invited to submit an abstract of 500 words with a Work Description Cover Sheet on recent advances in the field of packet video. Final contributions in the form of a four page extended summary and a 20 minute oral presentation or a poster presentation (based on the Steering Committee decision) will be required for accepted abstracts. Areas of interest include, but are not limited to: -- Video coding for ATM and other packet networks -- Video over Internet -- Multiplexing and switching of variable bit rate video -- Compensation of packet loss and jitter -- Privacy and security aspects of packet video -- Variable rate video transport with or without priority -- Network architecture for real-time video transport -- Performance modeling and evaluation -- Protocols for packet video -- Inter-media synchronization in ATM and Internet networks -- New visual services over ATM networks (LAN, MAN, B-ISDN) -- Human factors in packet video -- Rate control for VBR encoders -- Memory architecture for multimedia terminals In submitting a paper, please take into account the following summary of deadlines: April 15, 1994 Abstract and Work Description Cover Sheet submission (5 copies) May 31, 1994 Notification of acceptance mailed July 15, 1994 Camera ready copy (extended summary) submission To send the abstract or receive further information, please contact General Chairperson: A. Tabatabai; Tektronix, Inc.; P.O. Box 500, Mail Stop 50-370; Beaverton, OR 97077; USA; Telephone: (503) 627-1121; Fax: (503) 627-5502; Email: ajt@sail.labs.tek.com Technical Chairperson: A. Reibman; AT&T Bell Laboratories; Room 4E-520; 101 Crawford's Corner Rd.; Holmdel, NJ 07733-3030; USA; Telephone: (908) 949-3470; FAX: (908) 949-3697; Email: reibman@research.att.com Steering Committee Members: M. Biggar -Telecom Australia -AUS S. Casner -USC/Info. Sciences Inst. -USA L. Chiariglione -CSELT -I J. Y. Cochennec -CNET -F H. Gharavi -Loughborough Univ. -UK J. Guichard -CNET -F T. V. Lakshman -Bellcore -USA G. Morrison -BT Laboratories -UK D. Pearson -Essex University -UK D. Raychaudhuri -NEC -USA R. Shafer -Heinrich-Hertz Institute -D H. Tominaga -Waseda University -J M. Vetterli -U.C. Berkeley -USA M. Wada -KDD -J L. Zhang -Xerox -USA This workshop is sponsored by the European Association for Signal Processing. Sixth International Workshop on PACKET VIDEO WORK DESCRIPTION COVER SHEET Please answer all questions clearly and concisely. Reviewers may reject contributions for lack of adequate information. Attach this form to a 500 word abstract of your contribution. Submit 5 copies as indicated on the Call for Papers. ________________________________________________________________________ Paper title: ________________________________________________________________________ Name and address of author with whom correspondence on this paper should be conducted: ________________________________________________________________________ Is this paper theoretical, experimental, descriptive or "other"? (please specify) ________________________________________________________________________ Into which Areas of Interest does your paper fit? (If more than one, please specify order of your preference) ________________________________________________________________________ What is the problem and why is it important? ________________________________________________________________________ What is the original contribution and/or novelty of this work? ________________________________________________________________________ Does it check and/or extend previously reported work? What work? (Give references) ________________________________________________________________________ What kind of presentation do you prefer? (Please check) Oral presentation (20 minutes) O Poster presentation (90 minutes) O ________________________________________________________________________ If your contribution is accepted, what type of visual equipment is needed for your presentation? (please check) Overhead projector O 35 mm Slide Projector O Video cassette recorders with monitor/projector: Betacam-SP 50 Hz O 60 Hz O D1 50 Hz O 60 Hz O VHS: 50 Hz (PAL) O 60 Hz (NTSC) O Registration Form Sixth International Workshop on PACKET VIDEO September 26-27, 1994 Portland, Oregon, USA Please make check or money order payable to "Tektronix -- (for Packet Video '94)" and send with the completed registration form to: T. Naveen, Packet Video '94, Tektronix, Inc., P.O. Box 500, Mail Stop 50-370, Beaverton, OR 97077, USA. Name: ____________________________________________________ Title Family Name First Name Affiliation: _____________________________________________ Address: _________________________________________________ _________________________________________________ Country: _________________________________________________ Phone:_____________ Fax:_____________ E-Mail:______________ Please indicate your registration: ______ $300 Advance registration (received by July 15, 1994) ______ $350 Late/On-site registration (received July 16, 1994 or later) Authors must register and pay the advance registration fee by July 15, 1994 as a commitment to attend and present the paper. Registration includes a copy of the proceedings, 2 lunches, and a dinner. If you have any questions, contact either General Chair: A. Tabatabai; Tektronix, Inc.; Phone: (503) 627-1121; Fax: (503) 627-5502; Email: ajt@sail.labs.tek.com Technical Chair: A. Reibman; AT&T Bell Laboratories; Phone: (908) 949-3470; FAX: (908) 949-3697; Email: reibman@research.att.com Hotel Information Form Sixth International Workshop on PACKET VIDEO September 26-27, 1994 RED LION HOTEL Portland-Downtown 310 S. W. Lincoln Portland, Oregon 97201 Tel: +1-503-221-0450 Fax: +1-503-226-6260 Reservations: To make reservation simply call reservation office at +1-503-221-0450 and ask for Tektronix rate of $85 single or double occupancy. This rate is non- commissionable and does not include local room tax, currently at 9%. Transportation: Hotel is located approximately 10 miles southwest of Portland International Airport. They provide complimentary airport shuttle service every 30 minutes between 5:00 AM and 11:30 PM with pick up and delivery just outside the baggage claim area. Should you desire other transportation methods, the hotel is located half a block from Budget Car Rental (221-4521). They would be happy to assist you with making arrangements. In addition, front desk personnel would be happy to serve you in arranging for local taxi service should you need or desire it. Please note that the Hotel is located within Metro's Fareless Square District which provides complimentary bus transportation throughout the downtown corridor. Area Attractions: Within Walking Distance: Civic Auditorium, Tom McCall Waterfront Park (restaurants, shops, jogging routes along the Willamette River). Within five-minute driving access: downtown shopping; Washington Park Zoo; Oregon Museum of Science and Industry; World Forestry Center; Theaters. Directions to the Red Lion/Portland-Downtown from the Portland International Airport: >From the Portland International Airport, take I-205 heading South. Take the I-84 exit heading west into downtown Portland. Take the I-5 south exit. Following the signs to City Center on I-405, take the 4th Avenue exit off of I-405 (first exit). At the light take a right onto Lincoln. Hotel is located on the right side. ------- From rem-conf-request@es.net Wed Mar 16 11:16:48 1994 Received: from andy.bgsu.edu by osi-west.es.net via ESnet SMTP service id <16929-1@osi-west.es.net>; Wed, 16 Mar 1994 08:16:28 +0000 Received: from dad.bgsu.edu by andy.bgsu.edu (5.65/4.0) id AA24638 ; Wed, 16 Mar 94 11:16:05 -0500 Received: from chip.bgsu.edu by dad.bgsu.edu (4.1/SMI-4.0) id AA03363; Wed, 16 Mar 94 11:16:00 EST Date: Wed, 16 Mar 94 11:16:00 EST From: hasley@dad.bgsu.edu (John Hasley) Message-Id: <9403161616.AA03363@dad.bgsu.edu> To: rem-conf@es.net Subject: Nv with SGI Indy I've been asked to set things up for transmitting multicast conferences from BGSU. So far, we've only been receiving data. Since we have an SGI Indy with a camera, I'd like to use that and save the cost of connecting a camera to one of our Sun workstations. (The session immediately at issue will only involve a few people who would otherwise have to travel to Columbus for some meeting; nothing major as far as anyone has told me.) When I run nv on the Indy, it doesn't have any of the options that are needed to transmit video. The documentation mentions needing an Indigo Video card. I talked to SGI and was told that the Indigo Video card doesn't work with the Indy, but that there is an *Indy* Video card. Before I spend a couple thousand dollars of taxpayer money, can anyone tell me if nv will work with the Indy Video card? -- And as long as I have bothered everyone already, has anyone written up tips on setting things up for multicasting conferences? I can't recall seeing anything recently, and a lot of the README files with the software are getting old. (I could try to put something together; but I don't know enough to write it myself. If this is already being done, please let me know. If not, I'm willing to help compile it.) Thanks in advance. John Hasley Internet: hasley@dad.bgsu.edu University Computer Services Bowling Green State University Bowling Green, OH 43403-0125 MaBell: (419) 372-9989 From rem-conf-request@es.net Wed Mar 16 11:27:28 1994 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <17080-0@osi-west.es.net>; Wed, 16 Mar 1994 08:27:03 +0000 Received: from herman.cmf.nrl.navy.mil (herman-atm.cmf.nrl.navy.mil [134.207.10.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA10309 for ; Wed, 16 Mar 1994 11:26:59 -0500 From: William C Fenner Received: by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA00545; Wed, 16 Mar 94 11:26:57 EST Date: Wed, 16 Mar 94 11:26:57 EST Message-Id: <9403161626.AA00545@herman.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: Comments on use of wb for lectures I just finished watching Steve's presentation at the HPCC Symposium. The one comment I had was that the recieving whiteboards don't switch to a page until you draw on it, so I saw Steve's marks on the pages before the page got rendered. The wbimport tool allows page changes to be propogated, so if the lecturer uses wbimport to change pages, everyone else will see that page change at the same time. I think that I actually missed seeing some of the slides because no marks were made on them. Paging through after the lecture, there were indeed slides that I didn't see during. Bill From rem-conf-request@es.net Wed Mar 16 12:30:39 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <17980-0@osi-west.es.net>; Wed, 16 Mar 1994 09:29:17 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14520(7)>; Wed, 16 Mar 1994 09:28:24 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16148>; Wed, 16 Mar 1994 09:28:34 -0800 To: hasley@dad.bgsu.edu (John Hasley) cc: rem-conf@es.net Subject: Re: Nv with SGI Indy In-reply-to: Your message of "Wed, 16 Mar 94 08:16:00 PST." <9403161616.AA03363@dad.bgsu.edu> Date: Wed, 16 Mar 1994 09:28:28 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Mar16.092834pst.16148@ecco.parc.xerox.com> In message <9403161616.AA03363@dad.bgsu.edu> you write: > When I run nv on the Indy, it doesn't have any of the options > that are needed to transmit video. The documentation mentions needing > an Indigo Video card. I talked to SGI and was told that the Indigo Video > card doesn't work with the Indy, but that there is an *Indy* Video card. > The Indy has built-in video input hardware (VINO), so there's no need to buy the IndyVideo board for this. It does give you some additional functionality like video out, but you don't need that here. The problem you are having is that nv 3.2 was released before the Indy came out, and it only supports the older Indigo StarterVideo board. There is a "beta" version of nv 3.2 on sgi.com in sgi/ipmcast/nv-indy.Z which should work on Irix 5.1.1.x on the Indy. It's somewhat slow, as that version of the OS has very early video drivers that weren't tuned much. The release of nv I'm working on right now runs quite nicely on Irix 5.2 beta 2, but I haven't gotten the official Irix 5.2 release yet, so I haven't tested it there. If you are running 5.2, drop me some private mail and I'll get you a version to try. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Mar 16 13:46:50 1994 Received: from csservera.scs.usna.navy.mil by osi-west.es.net via ESnet SMTP service id <19591-0@osi-west.es.net>; Wed, 16 Mar 1994 10:46:14 +0000 Received: from douglas.scs.usna.navy.mil by SCS.USNA.NAVY.MIL (4.1/SMI-4.1) id AA08558; Wed, 16 Mar 94 13:43:56 EST Date: Wed, 16 Mar 94 13:43:56 EST From: eun@SCS.USNA.NAVY.MIL (E.K. Park x3037) Message-Id: <9403161843.AA08558@SCS.USNA.NAVY.MIL> To: atm@sun.COM, members@farnet.ORG, nren-discuss@psi.COM, rem-conf@es.NET, wireless@tandem.COM Subject: ICCCN94 ***************************************************************************** * Paper submission deadline has been extended until April 10, 1994 !!! * ***************************************************************************** CALL FOR PAPERS Third International Conference on Computer Communications and Networks (IC3N) September 11 -- 14, 1994, San Francisco, California, USA Sponsored by USC Communication Sciences Institute In cooperation with IEEE Communication Society* The third IC3N will cover all aspects of computer communications and networks. Of particular interest are recent advances in high-speed distributed multimedia applications, and the design and performance evaluation of system and network architectures that support these applications. Authors are invited to submit papers and tutorial proposals. Topics of interest include, but are not limited to: ATM Network Design Protocols for High Speed Networks ATM Traffic Control Distributed Multimedia applications ATM LAN's Multimedia Man/Machine Interface ATM Testbeds Video-on-Demand Systems Quality of Service Issues Video Coding Wireless Networks Network Management Multicast Protocols Performance Modeling/Analysis Optical Networks LAN/WAN Internetworking INSTRUCTIONS TO AUTHORS: All submissions must be accompanied by a cover letter containing a list of all authors, their affiliations, phone/fax numbers, and email addresses. Papers should be at most 20 double-spaced pages and must include an abstract of 100-150 words with up to ten keywords. Tutorial proposals should contain a one-page description and a detailed outline. All submissions will be refereed and judged with respect to quality and relevance. Submit six copies of each paper to the Program Chair (J. W. Wong), and tutorial proposal to the Program Vice Chair (E. K. Park). Proceedings will be available at the conference. CONFERENCE CHAIR: Professor T. Suda, Department of Information and Computer Science, University of California at Irvine, Irvine, CA 92717; Phone (714) 856-5474; Fax (714) 856-4056; Email suda@ics.uci.edu PROGRAM CHAIR: Professor J. W. Wong, Department of Computer Science, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1; Phone (519) 888-4431; Fax (519) 885-1208; Email jwwong@math.uwaterloo.ca PROGRAM VICE CHAIR: Professor E. K. Park, Computer Science Department, United States Naval Academy, Annapolis, MD 21042; Phone (410) 267-3037; Fax (410) 267-2686; Email eun@usna.navy.mil LOCAL ARRANGEMENT CHAIR: Dr. I. Khan, SRI International, Phone (415) 859-6335; Fax (415) 859-4812; Email khan@erg.sri.com REGISTRATOIN CHAIR: Prof. K. Makki, Univ. of Nevada at Las Vegas, Las Vegas, Nevada 89154; Phone (702) 895-4024; Email kia@koko.cs.unlv.edu PUBLICATOIN CHAIR: Professor W. Liu, Computer Science Department, Univ. of Maryland - Baltimore, Baltimore, MD 21228; Phone (410) 455-3968; Fax (410) 455-3969; Email lw@cs.umbc.edu PUBLICITY CHAIR: Professor N. Pissinou, Center for Advanced Computer Studies, Univ. of Southwestern Louisiana, 2 Rex Street, P.O. Box 44330, Lafayette, LA 70504; Phone (318) 231-6604; Fax (318) 231-5791; Email Pissinou@cacs.usl.edu IMPORTANT DATES: Deadline for paper and/or tutorial submissions: APRIL 10, 1994 Notification of acceptance: May 10, 1994 Camera ready papers due: June 10, 1994 IC3N STEERING COMMITTEE: Prof. V. O. K. Li, Chair (213-740-4665, vli@irving.usc.edu), Prof. B. G. Lee (Korea), Prof. J.-F. Chang (Taiwan), Dr. Y. C. Lee (USA), Prof. H. Okada (Japan), Prof. R. Pickholtz (USA), Prof. G.-S. Poo (Singapore), and Prof. I. Rubin (USA) *Pending approval From rem-conf-request@es.net Wed Mar 16 14:32:43 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <20550-0@osi-west.es.net>; Wed, 16 Mar 1994 11:32:27 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Mar 1994 19:32:01 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Steve Deering cc: rem-conf@es.net, stjohns@arpa.mil Subject: Re: HPCC Symposium sessions to be multicast In-reply-to: Your message of "Tue, 15 Mar 94 08:25:41 PST." <94Mar15.082550pst.12171@skylark.parc.xerox.com> Date: Wed, 16 Mar 94 19:31:57 +0000 Sender: M.Handley@cs.ucl.ac.uk I'm curious - what video card are you using at HPCC? - I'm seeing 12fps on a SunOS machine. Mark From rem-conf-request@es.net Wed Mar 16 20:24:05 1994 Received: from darpa.mil by osi-west.es.net via ESnet SMTP service id <25027-0@osi-west.es.net>; Wed, 16 Mar 1994 17:23:49 +0000 Received: from [192.48.218.6] (next6.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5) id ; Wed, 16 Mar 1994 20:22:43 -0500 Message-Id: <199403170122.AA20491@vax.darpa.mil> X-Sender: stjohns@next.darpa.mil Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Mar 1994 20:24:26 -0500 To: Mark Handley , Steve Deering From: stjohns@ARPA.MIL (Michael StJohns) Subject: Re: HPCC Symposium sessions to be multicast Cc: rem-conf@es.net, stjohns@ARPA.MIL At 19:31 3/16/94 +0000, Mark Handley wrote: >I'm curious - what video card are you using at HPCC? - I'm seeing 12fps on a >SunOS machine. > >Mark Ron Fredericks card (xerox PARC) - nice huh? Mike From rem-conf-request@es.net Wed Mar 16 22:09:10 1994 Received: from elxr-fddi.jpl.nasa.gov by osi-west.es.net via ESnet SMTP service id <25445-0@osi-west.es.net>; Wed, 16 Mar 1994 19:08:40 +0000 Received: from localhost (localhost [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.7/8.6.6) with SMTP id TAA16707 for ; Wed, 16 Mar 1994 19:08:30 -0800 Message-Id: <199403170308.TAA16707@elxr.jpl.nasa.gov> To: rem-conf@es.net Subject: CUSeeMe Date: Wed, 16 Mar 1994 19:08:29 -0800 From: Dave Hayes Who knows about this program and what protocols it uses for transmitting video? ------ Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh Exaggeration is a standard peculiarity of man. To deprecate is often a form of exaggeration which people do not notice because it appears to be its opposite. From rem-conf-request@es.net Thu Mar 17 03:50:51 1994 Received: from elroy.jpl.nasa.gov by osi-west.es.net via ESnet SMTP service id <26738-0@osi-west.es.net>; Thu, 17 Mar 1994 00:50:27 +0000 Received: from isolar.UUCP by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA15126; Thu, 17 Mar 94 00:50:24 PST Received: from isolar by isolar.Tujunga.CA.US (4.1/SATAN-6.6.6) id AA07159; Wed, 16 Mar 94 23:16:15 PST Message-Id: <9403170716.AA07159@isolar.Tujunga.CA.US> To: mbone@venera.isi.edu Cc: rem-conf@es.net Subject: Installing SunOS 4.1.3 Multicast support on host with FDDI/DX board? Date: Wed, 16 Mar 1994 23:15:57 -0800 From: - Greg Earle I have installed the June 29th Multicast software on my desktop Sun and on a Sun-4/330 gateway, which is intended to become the "mrouted" tunnel host. Unfortunately, the 4/330 has a Sun FDDI/DX VMEbus FDDI card installed, with a kernel-resident if_fddi.o driver. There is no replacement for this driver in the distribution (not that I'm surprised, mind you). I was directed to Anders Klemets' rem-conf posting from last September wherein he'd apparently whacked together a file to partially enable Multicast support for the SBus FDDI card (FDDI/S). Alas, that is not the board we have, nor are there source patches anywhere to be seen, etc. I would like to run an MBONE tunnel feed over the FDDI interface, as we have an all-FDDI path between my intended gateway and the remote tunnel host. Has anyone else found themselves in the same predicament and solved this? Or do we have to bite the bullet and build a kernel with the FDDI card disabled and do the tunnel over the Ethernet between our Cisco subnet router and the intended gateway (ugh)? I guess I'd be interested to know if Anders' file "fddi_fix_for_multicast.o" would also work on this FDDI/DX board, and if not, what advice would anyone have if I could get access to the if_fddi.c source and whack on it? Or any other solutions to this dilemma ... Please cc: me on any replies as I'm not on either mbone or rem-conf (yet) ... (Speaking of which, I can access the IETF mailing lists as "info" groups, but there's no "info.mbone" nor "info.rem-conf". Given the networking bent of most of the other info.* gatewayed mailing lists, any chance of getting the UIUC folks to add these two lists?) Thanks in advance, -- - Greg Earle Phone: (818) 353-8695 FAX: (818) 353-1877 [Call # again if Internet: earle@isolar.Tujunga.CA.US you get data tone] UUCP: isolar!earle@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle From rem-conf-request@es.net Thu Mar 17 05:09:15 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <27123-0@osi-west.es.net>; Thu, 17 Mar 1994 02:08:56 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA26612 (5.65c-6/7.3v-FAU); Thu, 17 Mar 1994 11:07:38 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA26619 (5.65c-6/7.3m-FAU); Thu, 17 Mar 1994 11:07:36 +0100 From: Toerless Eckert Message-Id: <199403171007.AA26619@faui43.informatik.uni-erlangen.de> Subject: Re: Installing SunOS 4.1.3 Multicast support on host with FDDI/DX board? To: - Greg Earle Date: Thu, 17 Mar 94 11:07:21 MET Cc: mbone@ISI.EDU, rem-conf@es.net In-Reply-To: <9403170716.AA07159@isolar.Tujunga.CA.US>; from "- Greg Earle" at Mar 16, 94 11:15 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > I have installed the June 29th Multicast software on my desktop Sun and on a > Sun-4/330 gateway, which is intended to become the "mrouted" tunnel host. ... I wouldn't bet that running mrouted on that machine will be very useful, because even with Anders neat fixes it still is not a good mrouter with FDDI card. As far as fixing the FDDI interface goes, you should simply replace the arpresolve and arpinput strings in if_fddi_subr.o with ARPresolve and ARPinput respectively. I actually have got two of these DX boards too, but i yet havn't installed multicasting on the machines, because there is another very ugly problem and this comes with the if_ie.o modules for karch sun4 machines. The ie ethernet driver suffers from a severe bug which makes NFS quite unusable over them, unless you install Patch 100570-05. Now the problem ist that there is of course no released diff or source for this patch, so it's currently not possible to build a multicasting if_ie.o with this patch included, and without it the machines won't do NFS very well. Best regards Toerless Yeah, Yeah, i know the answers to all questions, but it's 42 and not Solaris (what does BSD stands for by the way ? - "Ban Solaris, Dude" ;-) From rem-conf-request@es.net Thu Mar 17 09:46:32 1994 Received: from MITCHELL.CIT.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <28018-0@osi-west.es.net>; Thu, 17 Mar 1994 06:46:15 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by mitchell.cit.cornell.edu (8.6.4/8.6.4) with SMTP id JAA09742 for ; Thu, 17 Mar 1994 09:46:11 -0500 Message-Id: <199403171446.JAA09742@mitchell.cit.cornell.edu> X-Sender: rhx@132.236.199.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Mar 1994 09:50:21 -0500 To: rem-conf@es.net From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: CUSeeMe At 10:08 PM 3/16/94 -0500, Dave Hayes wrote: >Who knows about this program and what protocols it uses for >transmitting video? >------ >Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA >dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh > >Exaggeration is a standard peculiarity of man. To deprecate is often a form >of exaggeration which people do not notice because it appears to be its >opposite. ftp to gated.cornell.edu /pub/video get the text file with README in its name with the latest date. It describes now current 0.60b1 beta version. New versions coming with audio, etc. Join list described in README to learn news. -Dick From rem-conf-request@es.net Thu Mar 17 12:17:50 1994 Received: from nps.navy.mil by osi-west.es.net via ESnet SMTP service id <28934-0@osi-west.es.net>; Thu, 17 Mar 1994 09:17:17 +0000 Received: from in50216.cc.nps.navy.mil by nps.navy.mil (4.1/SMI-4.1) id AA04425; Thu, 17 Mar 94 09:16:37 PST Date: Thu, 17 Mar 94 09:16:37 PST From: mtweathe@nps.navy.mil (Mark T. Weatherford) Message-Id: <9403171716.AA04425@nps.navy.mil> To: rem-conf@es.net Subject: MBONE Please remove me from the mbone mail list. ********************************************************************* * LT Mark T. Weatherford, USN U.S. Naval Postgraduate School * * Information Technology Management 375B Bergin Drive * * SMC Box 1553, Monterey, CA 93943 Monterey, CA 93940 * * e-mail mtweathe@sagan.nps.navy.mil (408) 655-5136 * ********************************************************************* From rem-conf-request@es.net Thu Mar 17 18:43:24 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <02188-0@osi-west.es.net>; Thu, 17 Mar 1994 15:43:06 +0000 Received: from localhost (carl@localhost) by trystero.radio.com (8.6.5/940315.04ccg) id SAA04501 for rem-conf@es.net; Thu, 17 Mar 1994 18:43:25 -0500 Date: Thu, 17 Mar 1994 18:43:25 -0500 From: Carl Malamud Message-Id: <199403172343.SAA04501@trystero.radio.com> To: rem-conf@es.net Subject: Computer Chronicles Org: Internet Multicasting Service Any feedback on quality on the Computer Chronicles multicast today? We had some connectivity troubles for a while, but things are in a somewhat stable state. We still haven't fixed the overloaded mbone router or the Cisco synch problem, but would be interested in any feedback on things we can do in the meantime. Are these programs a worthwhile use of the bandwidth? Do people want to see the world news broadcast repeated more than once? Is the quality good enough to make listening bearable or are the packet loss rates so bad that it is really painful? Carl Malamud From rem-conf-request@es.net Fri Mar 18 05:49:31 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <04638-0@osi-west.es.net>; Fri, 18 Mar 1994 02:49:10 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Mar 1994 10:48:03 +0000 To: rem-conf@es.net Subject: MICE International Seminar: Tuesday March 22, 1994. Date: Fri, 18 Mar 94 10:47:55 +0000 From: Gordon Joly ******** Please limit traffic between 13:30 and 15:30 GMT on Tuesday March 22nd. ******** An announcement will be made in "sd" on Tuesday. The seminar will start at 14:00 GMT, when Christian Huitema (INRIA) will speak on A criticisim of the OSI model and an alternative architecture Abstract: The OSI model was elaborated 15 years ago, from experience gained in networks such as ARPANET or CYCLADES. At that time, networks were slow and complex, the emphasis was on reliability rather than performance. There was an absolute need to isolate the application from the very different networking environments provided by X.25, SNA or ARPANET. This lead to the formalization of the "layering" concept, and to the well known seven layers model for "Open Systems Interconnections". The situation has changed a lot, and the OSI model is now the object of severe criticisms. The particular choice of layer decomposition appears very debatable now. It was done in 1980, before such minor concepts as local networks or RPC were even invented! Classic criticisms of the model concentrates on the top-heaviness of OSI application protocols such as CMIP or X.400, but one can in fact go further and explain that the time of layered models has passed. In the talk, we will review the concepts of ALF and ILP which were first proposed by David Tennenhouse and David Clark from MIT/LCS. Integrated layer processing is a protocol implementation techniques that enable very efficient protocol implementation on modern "RISC" processors through fine grained pipelining of functions belonging to different "layers". Application level framing is a protocol design concept which allows the application to take full advantage of its internal parallelism when running over a high speed network. The European/Australian project Hipparch, which is just starting, aims at combining these techniques which can provide and order of magnitude gain in performance over traditional layered executions. The complexity of the resulting code, however, requires the development of automatic implementation techniques - very much like a parallelizing RPC stub compiler for multimedia applications. Such compilers require the development of formal specification techniques, i.e. of an adequate description language that can be use to describe the requirements of application. Network independance and ease of development, which were the goals of the layered model, will still be acheived. But the complexity will be removed from the "run time" systems and their layered stacks, and exported in the compiler - much in the same way that the complexity of CISC instructions was exported in RISC compilers. *********** Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT XXX YYY WWW & http://www.cs.ucl.ac.uk/mice/gjoly.html & WWW YYY XXX From rem-conf-request@es.net Fri Mar 18 11:42:48 1994 Received: from fnal.fnal.gov by osi-west.es.net via ESnet SMTP service id <06099-0@osi-west.es.net>; Fri, 18 Mar 1994 08:42:17 +0000 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HA44YPWS680047FB@FNAL.FNAL.GOV>; Fri, 18 Mar 1994 10:42:08 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA12150; Fri, 18 Mar 94 10:41:43 CST Date: Fri, 18 Mar 1994 10:41:43 -0600 From: Matt Crawford Subject: VAT question - audio device arbitration To: rem-conf@es.net Message-id: <9403181641.AA12150@munin.fnal.gov> Content-transfer-encoding: 7BIT How does one vat take the audio device away from another? If it's something easy like a tk send call, I'd like to get the tk-based mail-tool "exmh" to play the same game. It wants to generate occasional sound effects. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Fri Mar 18 12:46:54 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <06513-0@osi-west.es.net>; Fri, 18 Mar 1994 09:46:38 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Mar 1994 17:45:44 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Matt Crawford cc: rem-conf@es.net Subject: Re: VAT question - audio device arbitration In-reply-to: Your message of "Fri, 18 Mar 94 10:41:43 CST." <9403181641.AA12150@munin.fnal.gov> Date: Fri, 18 Mar 94 17:45:41 +0000 Sender: M.Handley@cs.ucl.ac.uk >How does one vat take the audio device away from another? If it's >something easy like a tk send call, I'd like to get the tk-based >mail-tool "exmh" to play the same game. It wants to generate >occasional sound effects. It uses multicast messages with a ttl of zero. (Not like a tk send call) Mark From rem-conf-request@es.net Fri Mar 18 13:03:46 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <06614-0@osi-west.es.net>; Fri, 18 Mar 1994 10:03:02 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Mar 1994 18:02:04 +0000 To: hhs@teleoscom.com (Chip Sharp 6424) cc: rem-conf@es.net Subject: Re: MICE International Seminar: Tuesday March 22, 1994. In-reply-to: Your message of "Fri, 18 Mar 94 09:57:02 EST." <9403181457.AA27133@teleoscom.com> Date: Fri, 18 Mar 94 18:01:59 +0000 From: Gordon Joly At present we maintain an FTP archive in ftp://cs.ucl.ac.uk/mice/seminars/ DTM deering.ps jacobson maguire abs gknight kato reichert davoli grandhi lavender sarkies deering guenther lavender.tar struif which is "as you find it". However, we are starting to provide this information on the WWW in better format. You could try the following. http://www.cs.ucl.ac.uk/mice/seminars/archive.html which is a little unstructured (comments welcome). For the current schedule please see http://www.cs.ucl.ac.uk/mice/seminars/ Gordon. >>>>> On Fri, 18 Mar 94 09:57:02 EST, hhs@com.teleoscom (Chip Sharp 6424) said: >> -- using template mhl.format -- >> From: hhs@com.teleoscom (Chip Sharp 6424) >> Subject: MICE International Seminar: Tuesday March 22, 1994. >> I am not able to access the seminars announced for MICE, but I was >> wondering if there was a way to get the seminar notes over the >> internet (email server or ftp). Could you please let me know if this >> is possible? >> Thanks. >> ======================================================================= >> Hascall H. Sharp Teleos Communications, Inc. >> System Engineering 2 Meridian Road >> Eatontown, NJ 07724 USA >> voice: +1 908 544 6424 >> fax: +1 908 544 9890 >> email: hhs@teleoscom.com >> ======================================================================== Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT XXX YYY WWW & http://www.cs.ucl.ac.uk/mice/gjoly.html & WWW YYY XXX From rem-conf-request@es.net Sat Mar 19 14:13:36 1994 Received: from origami.cso.uiuc.edu by osi-west.es.net via ESnet SMTP service id <11488-0@osi-west.es.net>; Sat, 19 Mar 1994 11:13:17 +0000 Received: from [128.174.33.159] (tobago.cso.uiuc.edu) by origami.cso.uiuc.edu with SMTP id AA29000 (5.67b/IDA-1.4.4 for ); Sat, 19 Mar 1994 13:13:12 -0600 Message-Id: <199403191913.AA29000@origami.cso.uiuc.edu> X-Sender: kline@origami.cso.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Mar 1994 13:13:15 -0600 To: rem-conf@es.net From: cvk@uiuc.edu (Charley Kline) Subject: Maven (vat for the Macintosh) finally available, sort of. Due to popular demand, this is the first officially released version of Maven, an Internet audioconferencing tool for the Macintosh computer. This is alpha-quality code, and this is version 2.0a11. It's available in Macbinary format by anonymous FTP from k12.cnidr.org in pub/Mac/Maven-2.0a11.sea.bin. This version incorporates several enhancements over the "toy" that made it out to the Global Schoolhouse a few weeks ago. If you have a development version of Maven (use the Finder's "Get Info..." command to retrieve the version number--development versions include a letter "d", as in 2.0d1), please do everyone a favor and throw it away. It was very incomplete and could easily crash. It also had some network behaviour that was rather unfriendly. To keep up on future versions and discussions of Maven, please join the Maven discussion list, maven@cnidr.org. To join, send electronic mail to listserv@cnidr.org containing the single line "sub maven Your Name" substituting your full name for Your Name. Maven requires a Macintosh with sound input hardware and will refuse to run if it can't find any. I haven't tested it on a lot of different Macintosh models, but I have noticed that many cannot input and output audio at the same time. Maven does the best it can with this shortcoming, but doesn't yet check for it at startup. If you find that no sound comes out of your speaker when not in Push-To-Talk mode, you'll have to run in Push-To-Talk mode at all times. Since the squelch-detect software requires that the sound input channel be open at all times, and if your Macintosh can't input and output at the same time, no sound output channels can be opened and no audio can be produced. I've had bug reports about it not working on AV macintoshes. It worked for me the one time I tried it on an 840AV, but I don't have regular access to AV's so that will take me some time to track down. The user interface and session control are really horrible; I'll have a slightly better version out in a few days, hopefully before IETF. I have a student working on cleaning it up some more. This version uses the vat protocol; at some point I want to plug in my RTP code and see how well I did. Are there any RTP-capable audioconferencing programs for me to try to interoperate with? -- Charley Kline, UIUC Network Architect cvk@uiuc.edu "Behind it all is surely an idea so simple, so beautiful, that when we grasp it--in a decade, a century, or a millennium--we will all say to each other, how could it have been otherwise? How could we have been so stupid for so long?" --John A. Wheeler From rem-conf-request@es.net Mon Mar 21 08:52:44 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <16023-0@osi-west.es.net>; Mon, 21 Mar 1994 05:52:22 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 21 Mar 1994 05:52:18 -0800 Posted-Date: Mon 21 Mar 94 05:51:23 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 21 Mar 94 05:51:24 PST Date: Mon 21 Mar 94 05:51:23 PST From: Stephen Casner Subject: AVT WG Agenda and Proposed RTP Changes To: rem-conf@es.net Message-Id: <764257883.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the Audio/Video Transport WG: You may be wondering about the status of AVT in general and of the Real-time Transport Protocol (RTP) in particular. Just before the November IETF meeting in Houston, the RTP spec was submitted to the Area Director with a request for "IESG Last Call". At the AVT meeting, comments were solicited on the spec but none were offered. However, behind the scenes, some objections were raised with the Area Directorate regarding the classification of RTP as a proposed standard and some aspects of the specification. I have received some feedback on the Area Directorate's review of RTP through discussions with Allison Mankin and John Wroclawski, but I have not received a written response yet. I was hoping to get that first, but I'll try to cover the issues with this message anyway. Subsequently, I've had two discussions with Van Jacobson and Ron Frederick in which we've taken the vat and nv programs as examples against which to test the issues listed below. As a further verification, Van and Ron plan to implement test versions of vat and nv incorporating RTP with the changes proposed below (there are hopes for this to be done before IETF). Please read about the proposed changes below, and if you can send comments before IETF, it would be much appreciated. This will be the main topic for Seattle. The current released RTP draft is draft-ietf-avt-rtp-04.txt and .ps even though its listed expiration date is past. There is a newer version on gaia.cs.umass.edu, in pub/hgschulz/rtp, files rtp.txt and profile.txt with updates for the timestamp change proposed below. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, March 29, 1330-1530 - Status of RTP and the working group - Presentation on changes proposed in response to Area Directorate review: 1. Control and data on separate ports 2. Remove Channel ID, put multiplexing into encapsulations 3. Replace data options with a bit field 4. Media-specific timestamps 5. Application-specific sync marker bit 6. Global source identifiers 7. Control packet format / Reception reports - Report on test implementations of proposed changes - Discussion of proposed changes -- what issues and problems may have been overlooked? Wednesday, March 30, 1330-1530 - Continuation of discussion of proposed changes as needed - Presentation on RTP and Synchronization Protocol - Presentation of new encoding specifications over RTP (may include: JPEG; MPEG1/MPEG2; Cell-B; new version of H.261) - Assess schedule for RTP completion and other work needed Proposed Changes to RTP My take on the AVT process is that we have designed a protocol that is well specified and certainly functional if not optimal. However, part of the criticism was that RTP follows a "classical" protocol style rather than the principles of Application Level Framing (ALF) and Integrated Layer Processing (ILP) proposed by David Clark and David Tennenhouse in their SIGCOMM '90 paper. I have some trouble with this claim because I believe RTP already adheres to at least the major points of these principles. For example, each packet is typically one application data unit and includes the identification required to enable processing of application data units out of order. So, the fit is really a matter of degree. The following guidelines are relevant: - Minimize the number of multiplexing points - Minimize the number of inband control operations As applied to RTP, the following changes are proposed (though not all of these are exactly motivated by ALF): - Carry the control and data traffic on separate ports - Remove the application-level multiplexing of the Channel ID and move it to an encapsulation for the cases where it's needed - Minimize the use of options - Make the definition of some fields application-specific (in particular, the timestamp clock rate and sync marker) - Use global rather than local IDs, to be able to detect loops - Specify more precisely how reception reports should be provided Each of these items is described in more detail below. 1. Control and data on separate ports This change removes RTCP functions from RTP data packets and puts them into a separate packet stream on another port to streamline data processing and to allow monitoring programs to receive the control information with having to sort through the data. The relationship of port numbers does not have to be even/odd pair, only some arithmetic algorithm (such as +1) so that the mapping can be calculated in either direction. This is so that a set of ports can be identified as being in use when either control or data traffic is observed. Advantages: - Allows monitors to collect feedback from receivers without having to sort through the data packets. - Moves multiplexing of control and data from option decoding to the exising multiplexing point of port number to streamline data processing. - Enables elimination of options in data packets. Disadvantages: - Consumes more port number space. - It may be harder to convince some firewall administrators to allow multiple ports through the firewall than one (although this becomes moot if port numbers are randomly allocated). 2. Remove Channel ID, put multiplexing into encapsulations as needed There was quite a bit of debate about the Channel ID, with Christian Huitema being notable among those who opposed it. ILP says the number of multiplexing points should be minimized, which argues for removal of the Channel ID. The argument for the Channel ID was not strong, but two cases were identified where the Channel ID was needed: - When multiple RTP units are carried in one UDP packet (to reduce packet overhead); this is indicated by a profile that specifies an additional encapsulation that currently includes only a frame length. The frame length is 32 bits for purposes of alignment, but really only 16 are needed. The other 16 bits could carry a demultiplexing field to take the place of the Channel ID. - For some applications, the multiplexing of the Channel ID might be sufficient without UDP, so RTP could be carried directly over IP. Without the Channel ID, such applications would have to use UDP, or a new encapsulation (perhaps 32 bits) could be defined. Advantages: - Eliminates a multiplexing point. - Frees bits for indication of optional fields. Disadvantages: - No multiplexing provided for RTP-over-IP case. 3. Replace data options with a bit field With the RTCP operations separated into another packet stream on a different port, there are only a few optional fields to be selected in data packets. That allows the optional fields to be indicated by bits in the fixed header. If the bits are also grouped together, it is possible to interpret them as a "packet format", which is a single demultiplexing point for processing as a set of fixed formats if appropriate. (If the options were not orthogonal, a more compact encoding of the packet format would be possible.) Or, rather than replicating code, the option bits may be processed individually, which is more likely for the existing applications. The order of the bits and the corresponding fields is fixed, but the receiver may process them in any order. This reduces the validation required. The RTP options would be replaced as follows: CSRC (content source) -- A bit field of 5 or 6 bits in the fixed header to count the number of content source identifiers to follow, for packets produced by a bridge (mixer). Zero indicates that the packet did not come from a bridge. This count takes the place of the length field in the current CSRC option. SSRC (synchronization source) -- One bit to indicate that a sync source identifier follows. The CSRC count and SSRC bit could be combined into a "source ID" count if the first source ID in the list is defined to identify the sync source. That is, a packet produced by a bridge would always have to identify the bridge explicitly as the sync source, so the count would be at least 2, for the sync source ID and one content source ID. This extra overhead of the explicit sync source ID may be justified if global identifiers are used (see below) and the implicit source ID is reserved for traffic generated by the bridge host itself. BOS (beginning of sync unit) -- This option carries the sequence number of the first packet of a synchronization unit. It has not been used yet, and it would be eliminated as a generic RTP option. A profile could define this field to be included after the RTP header. APP (application-specific) -- Application specific functions could be defined in profiles as extensions to the RTP header, but there is no provision for one implementation of an application to define its own optional information in a way that other implementations can simply ignore. SDST (sync destination, or reverst-path option) -- The same mechanism that is used for the SSRC on a forward packet can be used for SDST on a reverse path packet because the directions are distinguished by the arrival port (the current SSRC and SDST options could have been one). However, if global identifiers are used, it may not be possible to implement reverse path packets (some would say that's a good thing). This is because translators would not need to keep a table that would allow mapping source identifiers back into transport addresses. ENC (encryption) -- Two methods: A. When encryption is used, the whole RTP unit is encrypted (all of the RTP header and data). The receiver depends upon header validity checks (version, format, sequence number, and timestamp having reasonable values) to discard packets that should have been decrypted (or decrypted with a different key). There is no provision for an explicit initialization vector; instead zero would be used with random initial values for the sequence number and timestamp to deter a known plaintext attack, or a shared secret could be used. Since it would not be possible for a translator to insert or modify the SSRC field, the SSRC would always have to be inserted before encryption, and the local identifier scheme would not work. The key and encryption algorithm would be specified by out of band information; key switching can be done by trying the possible keys one at a time to decrypt the header and make the validity checks. B. The fixed portion of the RTP header (64 bits) and the SSRC field (if present) would not be encrypted in order to allow translators to insert or modify the SSRC field (so this would reduce header size in the normal case, and would work with local identifiers). One bit in the header would indicate that the packet was encrypted. As with the current RTP ENC option, the initialization vector could either be the first 64 bits of the RTP header, or an explicit value generated randomly for each packet, but the choice would be specified only by the out-of-band information. In the case of the explict IV, the 64-bit field would be inserted after the SSRC (if present), and encryption would begin after the IV field. MIC (authentication) -- Two methods: A. An authenticated packet would be indicated by a bit in the header which would indicate the presence of an authentication field later in the header. To work with locally unique identifiers, which must be updated when a packet goes through a translator, the SSRC field would have to be excluded from the authentication; this means it could be faked by a translator. With the global identifier scheme, the SSRC could be authenticated to have been set by one of the sources (but could still be false). For either scheme, the SSRC field must always be included in case the packet has to go through a translator, or alternatively the SSRC flag bit could be excluded from the authentication. The authentication method (covered by ENC, keyed, symmetrically encrypted, or asymmetrically encrypted), algorithm and key (if any) would be known from out-of-band information. As with the method (A) for encryption, key changes could be accomplished by trying with old an new keys in succession. Alternatively, a key descriptor could be included at the start of the authentication field. To allow some receivers to ignore the authentication without knowing the out-of-band information, a length field would be needed at the start of the authentication field. B. Since authentication may in the future be provided at a layer below RTP, it would be advantageous if no bits were wasted once authentication within RTP became unused. This could be accomplished by using a separate encapsulation header prepended to the RTP header and distinguished from the RTP header by a different version number or some combination of bits in the first word that was sufficiently unique from a valid RTP header. One possibility would be version 0, which would otherwise indicate vat protocol, but with unused flag bits set. The first word of the authentication encapsulation should include a length field so receivers that didn't care about authentication could skip it. The other fields in the first 32 bits of the RTP header are the version number, format, sync marker, and sequence number. It is proposed that the version number be bumped to 2 if these proposed changes are adopted. In that case, the version field could be reduced from two bits to one if we were willing to sacrifice the possibility of defining a version 3. The format field would remain unchanged. The sync marker definition might change (see below), but would remain one bit. The sequence number should stay at 16 bits for arithmetic convenience, but could be trimmed if necessary. So, the resulting header bit count would be: min max 5 6 for CSRC count 0 1 for SSRC present 0 1 for encryption 0 1 for authentication 1 2 for version 6 6 for format 1 1 for sync marker 8 16 for sequence number --- --- 21 34 (so 2 must be trimmed) Advantages: - Options may be processed collectively as a packet format, although that seems unlikely for the options defined here. - Option bit field takes less space than the option code + length format (though longer global ID's would consume some of the space). - More streamlined data processing, though the difference may not be noticeable compared to the data manipulation in existing apps. - Allows processing of SSRC first, which was identified as a problem with current scheme unless SSRC option was required to be first. Disadvantages: - There may not be any spare bits for new options, but it may be argued that there just aren't that many variations that must be accommodated in the common part of supporting communication across a packet net (vs. application or media specific details which go later in the packet) - Encryption and authentication key changes can't be indicated explicitly. 4. Media-specific timestamps A more careful analysis of the technique given in the RTP spec for conversion between RTP timestamps and sample clocks has identified two problems: - It is possible to construct unusual pathological cases that result in an off-by-1 error due to floating point arithmetic, so we can't claim it's always accurate even though it would probably work fine for all the real examples. - The example code in the spec is insufficient because it does not point out that the received 32-bit RTP timestamp must always be extended with the high 16 bits of the NTP timestamp in order to accurately reconstruct a 32-bit sample counter. This requires that the sender and receiver both know roughly what time it is, and we believe it is not reasonable to establish that as a requirement for all uses of the RTP protocol, even though it might be a reasonable requirement within a given profile. Also, the fact that the RTP timestamp uses the middle bits of an NTP timestamp has led some implementations to "ask the system" for an NTP timestamp as each packet is being prepared. This technique will produce timestamps with too much jitter to be valid for audio samples. Furthermore, the sampling instant, rather than the time of packet preparation, is what's really needed for synchronization. Therefore, it is proposed that the rate at which the clock ticks, instead of always being 65536Hz, would become a parameter of the format. For some formats, such as the variable frame rate video we are now using, it may make sense to retain the 65536Hz rate, while for most audio formats, the clock rate would be set to be the same as the sampling rate, as is done for the timestamp in vat. For predefined format codes, the clock rate would be defined in the profile spec. For dynamically defined format codes, it is proposed that the clock rate be specified as a reduced rational number, with a 32-bit numerator and a 32-bit denominator. Assuming that all sampling rates are rational, this would be exact and would avoid the complications of incompatible floating point formats. A second aspect of the current RTP timestamp is that senders with synchronized time sources (e.g., using NTP) are supposed to periodically adjust the timestamp calculation to correct for drift between the sampling oscillator and the nominal sampling rate. This is to aid in intermedia synchronization, in particular for sources from multiple sites. In the new timestamp scheme, it would still be possible to have the sample counter be relative to the same t0 as NTP and periodically adjust it at the sender to correct for drift if the sender knows the time of day. By conveying the relationship of media timing to real time in the timestamp itself, no separate explicit communication of the relationship would be needed. However, independent of what clock rate is chosen for the timestamp, receivers would need some indication whether or not the senders knew the time of day (and how accurately) to determine whether they could use the timestamp to synchronize. If a periodic indication would be required anyway, then one could just as well communicate the relationship to real time periodically so the receiver can make the necessary adjustments (since it must be adaptive anyway). This would remove the requirement for the sender to make adjustments, which is an advantage for continuous transmission. Adjustments to the sample clock may cause audible glitches. If the sender must adjust for drift between the sampling clock and real time, and the receiver must adjust for drift between real time and the playout clock, the number of adjustments (and glitches) may be more than twice as many as if the receiver just made adjustments for drift between the sampling clock and the playout clock. (In the extreme case, if the sampling clock and playout clock happened to be exactly the same but both skewed with respect to real time, then synchronizing with real time would require adjustments at both sender and receiver, whereas not synchronizing to real time would require no adjustments). Therefore, it is also proposed to remove the requirement for senders to make timestamp adjustments. For example, the timestamps would just follow the input device's sample counter. For senders that do know the time of day, control packets would carry both an RTP timestamp (sample clock) and the corresponding full 64-bit NTP timestamp to establish the relationship. Specific applications such as the talking clocks might choose to still initialize the sample counter timestamp relative to t0 and adjust periodically keep the timestamps synchronized to real time since the data is artificially generated anyway. Advantages - Avoids time conversion calculations at the sender and receiver, and the potential errors at the receiver. - Doesn't require sender to know what time it is. - Reduced number of drift corrections for continuous transmission. Disadvantages - Relationship to real time must be communicated periodically. - Monitoring and recording tools would need to know about the predefined formats and their clock rates, whereas before they could be format-independent. - A receiver must wait for the periodic control packet before synchronization can be done. In particular, a recorder would need to back calculate the real time corresponding to the first packet of a recording to know how to play back the first packets in sync with another medium, for example. 5. Application-specific sync marker bit In the RTP specification, the sync bit was chosen to mark the last packet of a synchronization unit because that allows the receiver to also determine the first packet of the next talkspurt by its sequence number. If the sync bit marked the first packet of a synchronization unit, it would not be possible in real time to establish the end of the previous synchronization unit. However, some applications of RTP may only care about the start of a synchronization unit. For them to successfully determine the first packet of a synchronization unit requires that both the last packet of the previous unit and the first packet of the next one be received intact. This is a disadvantage, so those applications would prefer to mark the first packet. If you think about it, it's not necessary for the main RTP specification to define the meaning of the sync marker because there is no generic processing of that bit to be done for all applications. In fact, within a given application, it might make sense for the definition of the marker bit to be specific to a particular encoding. Therefore, it might be claimed that the sync marker does not belong in the common RTP header at all, but there are a couple of reasons for it to remain: - Most applications will want to mark something, and to allocate a bit elsewhere may require allocating 32. Since we don't want to make the header any longer than necessary, we should try to provide that space in the common header. - The marker bit may be useful for media-independent monitoring because loss may often occur in some relationship to the marker. It may be possible to draw some useful information from that relationship without knowing the specific definition of the marker. 6. Global source identifiers RTP currently uses locally unique source 16-bit identifiers to keep track of distinct sources when packets flow through translators (when the original transport address is replaced by that of the translator) and bridges (when packets from multiple sources are mixed). These identifiers have the advantage of small size, but there are some disadvantages as well: - Translators and bridges must maintain a table of incoming streams (identified by transport addresss and possibly an incoming SSRC identifier) to be mapped to outgoing identifiers. - If a translator or bridge went down, the mapping would probably be lost, which means downstream receivers would be temporarily confused about sources. - Local identifiers can't be used to detect a delivery loop. For example, if there is a translator from multicast to unicast followed by a translator from unicast to multicast, and somehow the two multicast trees get hooked together, a loop may form. Earlier in the RTP design process, truly globally unique identifiers were considered. These were constructed with [type,length,value] structures to use unique network addresses of various forms. This idea was rejected because these identifiers are too large. Van Jacobson proposes a point in between with the scheme used by vat and wb. This scheme uses 32-bit identifiers unique within a particular medium in a particular session. In other words, one site (source) may use the same identifier for each of several media in a session. In the current Internet, the 32-bit identifiers may be derived simply by using the IPv4 address of the host if there is only one source per host (as is common for workstations), or otherwise chosen at random from the "class F" IP address space (26 bits). There are some obvious difficulties in this scheme: - Two sources may choose the same random number. Fortunately, if the number of sources in a session that need to choose random numbers is small compared to the square root (8192) of the size of the space (2**26), the probability is "negligibly small" according to the analysis of the Birthday Problem. - If hosts on a private internet reuse IP addresses that are assigned to hosts in the Internet, and if the two internets are connected by some kind of translator (e.g., a firewall), then the applications running in the private internet would have to be configured to use random identifiers when communicating across the translator. This could be messy. There are two mechanisms that might be used for conflict resolution: - During the relatively long startup period when a participant first joins a conference, the IDs of the other participants are likely to be heard before the new participant transmits, so there is a chance for the new participant to choose another random number if a conflict is heard. - If a new site begins using an ID in conflict with an existing one, then any site in the session can send a message challenging the new participant (since the owner of the ID might not be in the session at that moment). Randomized delays would be used to prevent an implosion of responses. This challenge mechanism would need to be specified in the protocol. If the probability of unresolved conflict is smaller than the probability of lightning striking your workstation, it probably doesn't matter. This scheme would impose a limit on session size, but the practical limit for the "lightweight session" mechanism is somewhere between 1K and 10K anyway. Beyond that, the scaling of control packet rate backoff stops working (it becomes slower than about 2 minutes, and this gets unstable if participants come and go at similar time scales). For larger sessions, such as cable TV distribution, some means of aggregation would have to be specified, and that mechanism could provide a partitioning of the identifier space as well. For some applications, such as wb, the identifiers should be stable across invocations to avoid loss of ownership of previously generated information. If a random ID must be chosen then it must be remembered in persistent storage (e.g., a file). Rules such as this for the use of identifiers might be part of an application-specific profile. Multiple sources participating in the same session on one host would need some means to coordinate which one gets to use the IP address and which ones must select random identifiers. Although vat does not do this yet, I think Van has a plan. Advantages - Loop detection. - Less work in translators and bridges. - May be required for some encryption or authentication schemes under the new option mechanism. Disadvantages - 32 bits instead of 16. - Must be convinced by probability. 7. Control packet format / Reception reports With control and data being carried on separate ports, the functions of the RTCP options would be moved into the control packets. The primary functions are: - Providing information about the sender, e.g., name - Providing reception reports for all sources received - Relating the sender's media timestamp to real time, and also marking the time of the reception reports In previous AVT meetings, it has been suggested that RTCP might be removed from the RTP spec entirely. However, Van Jacobson states the position that in order for RTP to be used on a large scale, we must provide mechanisms for network service providers as well as users to evaluate the distribution quality, and the mechanism is to monitor the reception reports generated from the multicast data itself as the test traffic. This mechanism needs to be considered a fundamental part of RTP having to do with using the network for distribution; it's use should not be considered optional. Since the reception report mechanism is independent of particular media, it goes in the base RTP spec rather than a profile. The spec should be written such that any application using RTP will work in multicast mode, with unicast as a special case. The format of control packets has not been as well defined as the other items in this proposed collection of changes. The header format for the control packets need not be exactly the same as for the data packets, but it may be useful to keep them similar. The following information is proposed: Sender info: media timestamp NTP timestamp sender's packet count sender's byte count sender's name Reception info: number of reception reports array of report structures: source identifier count of packets received count of bytes received variance of interarrival time last timestamp received from this source in a session packet delay time since that session packet was received The reception report structure includes multiple reports per packet (all sources heard from since the last report). If the conference is large such that the control packet rate is slowed down, and if there are so many sources generating traffic that the reports will not all fit into a packet, then a different set of sites would be picked each time in round robin order, for as many as will fit. The last two items in the reception report can be used in an NTP-like algorithm to figure the round-trip propagation delay and then divide by two. Then one can make an ordering of the sources based on propagation delay as an approximation of distance, and can cluster the sites based on error rate and on distance. The reception report should contain absolute information rather than deltas so it does not matter if a report is missed. The NTP timestamp in the sender information is useful for media synchronization, but it is also needed as the timestamp at which the counts in the reception report were generated. This double duty requires that the media timestamp have sufficient resolution that one can be generated to correspond to the NTP timestamp at the time a reception report is generated; alternatively, the reception report must be generated at an instant that corresponds to a media timestamp tick. Given two reception reports with timing information allows the counts to be translated into rates. The RTP QOS option includes minimum and maximum delay measures. These are not included above because an outlyer can make the value useless as a description of the distribution. The general guideline for the construction of the control packet is to put more common information first so that application-independent monitors can process all the common information without having to know anything about the format of the application- or media-dependent information. So, the packet would be assembled as: sender info: common application dependent media dependent reception report: common, for all sources received application dependent, for all sources received media dependent, for all sources received There is one field that tells the number of reception reports, and then the reception info is contained in several parallel arrays, all with the same number of entries (some of which may be structs) and all indexed by the same number. The application dependent part would be defined by a profile and the main spec wouldn't say what the format was. In addition to the sender description and reception report information, the existing RTCP defines the following options. These options may need to be incorporated into the control packet structure in some way: FMT (format description) -- Allows format codes to be defined dynamically. This may also be accomplished with a higher-layer session protocol, but some applications may not include such a protocol. BYE (goodbye) -- Indicates that a source is terminating its participation in a session. Since no source description or reception report information is required, this could be a separate (trivial) control packet format. APP (application-specific controls) -- Application-specific sections of the sender information and reception reports in the control packet provide a means to carry application-specific information defined by a profile. However, in cases where multiple implementations of a single application interoperate but may have their own control information to communicate, and additional option mechanism may be appropriate. [end] ------- From rem-conf-request@es.net Mon Mar 21 12:34:00 1994 Received: from riches.rutgers.edu by osi-west.es.net via ESnet SMTP service id <16881-0@osi-west.es.net>; Mon, 21 Mar 1994 09:33:34 +0000 Received: by riches.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17302; Mon, 21 Mar 94 12:33:30 EST Date: Mon, 21 Mar 94 12:33:30 EST From: klemets@paul.rutgers.edu (Anders Klemets) Message-Id: <9403211733.AA17302@riches.rutgers.edu> To: rem-conf@es.net Subject: Sunergy and HPCC recordings available I made a recording of the Sunergy #9 broadcast last week. It is available for interactive replay on my WWW-based media on demand server. Access it through the URL http://www.it.kth.se/Events/MBONE/Sunergy.html or from main entry point, http://www.it.kth.se/~klemets/vatplay.html Thanks to Sun for letting me redistribute their program. I also have some recordings of talks given at the ARPA HPCC symposium. I have Satyas and Mike Schwartz' talks online. They can be accessed through the URL http://www.it.kth.se/Events/MBONE/HPPC.html or from the main entry point as stated previously. Anders From rem-conf-request@es.net Mon Mar 21 17:07:02 1994 Received: from jarthur.cs.hmc.edu by osi-west.es.net via ESnet SMTP service id <18120-0@osi-west.es.net>; Mon, 21 Mar 1994 14:06:27 +0000 Subject: Take me off please To: rem-conf@es.net Date: Mon, 21 Mar 94 14:06:24 PST From: Elecia X-Mailer: ELM [version 2.3 PL11] Please take me off this mailing list. Thanks, Elecia From rem-conf-request@es.net Tue Mar 22 04:29:05 1994 Received: from hplms26.hpl.hp.com by osi-west.es.net via ESnet SMTP service id <20523-0@osi-west.es.net>; Tue, 22 Mar 1994 01:28:43 +0000 Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (16.6/15.5+ECS 3.3+HPL1.1S) id AA29331; Tue, 22 Mar 94 01:16:57 -0800 Received: from opera.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA08664; Tue, 22 Mar 1994 01:15:45 -0800 Received: by opera.hpl.hp.com (1.37.109.8/HPL42.42) id AA25934; Tue, 22 Mar 1994 01:12:39 -0800 Date: Tue, 22 Mar 1994 01:12:39 -0800 From: Community Networking Workshop Message-Id: <9403220912.AA25934@opera.hpl.hp.com> To: cn-mail@opera.hpl.hp.com Subject: Community Networking Workshop: April 15 deadline ============================================================================= Call for Participation ============================================================================= FIRST INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME July 13-14, 1994 Westin Hotel, San Francisco Bay, California, USA Sponsored by the IEEE Communications Society In collaboration with ACM SIGCOMM, the Internet Society, and Smart Valley Community networking concerns the network infrastructures that will bring integrated multimedia services to home users. Community networking differs in many ways from enterprise networking in its services, technologies, and economics. In contrast to enterprise networking applications, community networking services will not necessarily be work oriented and will range from entertainment to shopping to information services. At present, community networking technology is driven by the requirements of video-on-demand, most notably high bandwidth (compared to narrowband), bandwidth asymmetry, and the delay-jitter constraints imposed by today's limited-storage TV set-top devices. As various other services develop, community networking will evolve to include integrated multimedia communication and user-to-user applications. Community networking must also provide access to resources located outside the community, in an increasingly global repository of information of every conceivable type. Since very little has been published to date on the topic of community networking, this workshop will give researchers and professionals the chance to share their views and advance the state of the art in this field. RELEVANT AREAS: Contributions are encouraged in the four areas listed below with relevant topics: 1. APPLICATIONS AND REQUIREMENTS: types of applications; coding; set-top operating systems; QoS networking requirements (symmetric/asymmetric bandwidth, delay, and losses); security and privacy; service models; user interface and navigation facilities. 2. LOCAL DISTRIBUTION TECHNOLOGY: topology; fiber/cable/UTP/wireless; modulation, bandwidth allocation; MAC (reverse channel); role of ATM; dependencies on equipment/network in the home (e.g., TV set-top). 3. ADDRESSING, SIGNALING, AND UPPER-LAYER PROTOCOLS: local vs. global addressing; the service provider view vs. the common carrier view: the video-dialtone gateway; role of B-ISDN protocols; network- and transport-layer protocols; network management; APIs. 4. INTERNETWORKING AND ARCHITECTURE: the gateway: accessing other networks (data, telephone); server placement and network optimization; the regional distribution centers; testbeds; network traffic models; network cost structure and its implications on service pricing; medium- and long-term network evolution; the impact of regulatory constraints. INSTRUCTIONS FOR SUBMITTING ABSTRACTS: Please send via electronic mail a short abstract (up to 700 words in ASCII or PostScript) describing a position statement in one of the areas above to cn-workshop@opera.hpl.hp.com Note that submissions longer than the limit above will not be reviewed. Only if electronic submission is impossible, a hardcopy version may be sent to: Riccardo Gusella Hewlett-Packard Laboratories 1501 Page Mill Rd., MS 1U-17 Palo Alto, CA 94304, USA Participation in the workshop will be by invitation only based on the Program Committee's review of position statements. Some of the authors will be asked to submit extended abstracts and to present their positions during the workshop. Workshop size limitation may preclude attendance of all authors of multi-author abstracts. DATES: Deadline for submitting abstracts . . . . . . . . April 15, 1994 Acceptance notification . . . . . . . . . . . . . May 12, 1994 Extended abstract due (limited to 2000 words) . . June 16, 1994 PROGRAM COMMITTEE: Program Co-Chairs: Martin De Prycker Alcatel Bell Telephone, Antwerp, Belgium Riccardo Gusella Hewlett-Packard Laboratories, Palo Alto, California Committee Members: Joel Winthrop AT&T Bell Labs Alexander D. Gelman Bellcore Gordon Kerr BT Labs Jurgen Brommelhoff Digital Equipment Corporation Matthew D. Miller General Instruments Jeff H. Derby IBM Corporation David Skellern Macquarie University, Sydney Andrew Lippman MIT, Media Lab Joydeep Bose National Computer Board, Singapore Tetsuya Miki NTT Transmission Systems Laboratories Andrew Laursen Oracle Corporation G. Keith Cambron Pacific Bell Albert J. Stienstra Philips Research H. Allen Ecker Scientific-Atlanta, Inc. Mario P. Vecchi Time Warner Cable, Inc. From rem-conf-request@es.net Tue Mar 22 09:53:26 1994 Received: from cathedral.cerc.wvu.edu by osi-west.es.net via ESnet SMTP service id <21783-0@osi-west.es.net>; Tue, 22 Mar 1994 06:53:08 +0000 Received: from raleigh (raleigh.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA02613; Tue, 22 Mar 94 09:53:05 EST From: zhang@cerc.wvu.edu (Xiao-Dong \(Nick\) Zhang) Received: by raleigh (5.65//ident-1.0) id AA04481; Tue, 22 Mar 1994 09:53:04 -0500 Date: Tue, 22 Mar 1994 09:53:04 -0500 Message-Id: <9403221453.AA04481@raleigh> To: rem-conf@es.net Subject: unsubscribe please unsubscribe me. Nick Zhang From rem-conf-request@es.net Tue Mar 22 14:07:42 1994 Received: from amway.ch.apollo.hp.com by osi-west.es.net via ESnet SMTP service id <23743-0@osi-west.es.net>; Tue, 22 Mar 1994 11:07:22 +0000 Original-Received: from daphne.ch.apollo.hp.com by amway.ch.apollo.hp.com id Tue, 22 Mar 94 14:06:22 EST PP-warning: Illegal Received field on preceding line Received: by daphne.ch.apollo.hp.com id AA26786; Tue, 22 Mar 1994 14:03:20 -0500 From: postmaster@apollo.hp.com (Postmaster - IT/NOS ) Date: Tue, 22 Mar 94 13:50:05 EST Subject: re:unsubscribe Sender: postmaster@apollo.hp.com To: rem-conf@es.net --------------- FORWARDED MESSAGE FOLLOWS --------------- Received: from it_750.ch.apollo.hp.com by daphne.ch.apollo.hp.com id AA24762; Tue, 22 Mar 1994 12:31:48 -0500 Received: from nis_mstr.ch.apollo.hp.com by it_750.ch.apollo.hp.com for postmaster@apollo.hp.com id AA24876; Tue, 22 Mar 1994 12:31:40 -0500 Received: from it_750.ch.apollo.hp.com by nis_mstr.ch.apollo.hp.com for Postmaster@apollo.hp.com id AB28079; Tue, 22 Mar 94 12:31:31 -0500 Date: Tuesday, March 22, 1994 9:53:04 am (EST) From: MAILER-DAEMON@ch.hp.com (Mail Delivery Subsystem) Subject: Unable to return to sender (Returned Mail: Unable to deliver mail) To: postmaster@apollo.hp.com ----- Transcript of session follows ----- 554 ... Unbalanced '(' 554 ... Unbalanced '(' 554 ... Unbalanced '(' ----- Unsent message follows ----- Received: from it_750.ch.apollo.hp.com by nis_mstr.ch.apollo.hp.com for brezak id AA28077; Tue, 22 Mar 94 12:31:31 -0500 Received: from amway.ch.apollo.hp.com by it_750.ch.apollo.hp.com for brezak@POP id AA24873; Tue, 22 Mar 1994 12:31:31 -0500 Received: from osi-west.es.net by amway.ch.apollo.hp.com id Tue, 22 Mar 94 12:30:46 EST Received: from cathedral.cerc.wvu.edu by osi-west.es.net via ESnet SMTP service id <21783-0@osi-west.es.net>; Tue, 22 Mar 1994 06:53:08 +0000 Received: from raleigh (raleigh.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA02613; Tue, 22 Mar 94 09:53:05 EST From: zhang@cerc.wvu.edu \(\) \(\) (\) (Xiao-Dong \(Nick\) Zhang) Received: by raleigh (5.65//ident-1.0) id AA04481; Tue, 22 Mar 1994 09:53:04 -0500 Date: Tue, 22 Mar 1994 09:53:04 -0500 Message-Id: <9403221453.AA04481@raleigh> To: rem-conf@es.net Subject: unsubscribe please unsubscribe me. Nick Zhang From rem-conf-request@es.net Tue Mar 22 16:55:23 1994 Received: from watson.ibm.com by osi-west.es.net via ESnet SMTP service id <24653-0@osi-west.es.net>; Tue, 22 Mar 1994 13:55:06 +0000 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3551; Tue, 22 Mar 94 16:55:01 EST Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 5063; Tue, 22 Mar 1994 16:56:39 EST Received: from vindhya.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 22 Mar 94 16:56:36 EST Received: by vindhya.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA25378; Tue, 22 Mar 1994 16:54:53 -0500 From: kandlur@watson.ibm.com (Dilip Kandlur) Message-Id: <9403222154.AA25378@vindhya.watson.ibm.com> X-Sender-Data: Phone: 914-784 7722 or 8-863 7722 To: rem-conf@es.net Subject: CFP - DIGITAL VIDEO COMPRESSION: ALGORITHMS AND TECHNOLOGIES Reply-To: kandlur@watson.ibm.com Date: Tue, 22 Mar 94 16:54:53 -0500 CALL FOR PAPERS DIGITAL VIDEO COMPRESSION: ALGORITHMS AND TECHNOLOGIES Part of IS&T/SPIE Symposium on Electronic Imaging: Science & Technology San Jose Convention Center, San Jose, California, February 5-11, 1995 The rapid continual advances in computer and network technologies coupled with the availability of high-volume data storage devices have effected the advent of multimedia applications on a multiplicity of computer platforms and consumer devices. Digital video data poses many challenges due to its inherent high bandwidth processing and storage requirements. The increased performance levels that are being achieved by these systems have made real-time digital video decompression and playback, and in some cases capture and encoding, feasible. This conference brings together practitioners and researchers working in all facets of digital video. The conference will serve as a forum for exchange on video codec research, development, and implementations. Presenters will be encouraged to demonstrate their digital video solutions. Also encouraged are presentations on the scientific concepts behind making these technologies work, as well as understanding the compromises required when faced with real world resource constraints. Papers are solicited in all areas of digital video and audio codec methods, including, but not limited to: - software-only video codecs - hierarchical encoding schemes (wavelets, sub-band coding, pyramids) - object, model and region based image coding - vector quantization, fractals based image coding - MPEG I and II implementation and application issues - video codec standards (software and hardware implementations of MPEG, HDTV, Px64,MPEG-4) - very low bit rate video coding - DCT and transform implementations - motion estimation techniques - video indexing (automatic logging, scene change detection) - rate control issues and implementations - quantification of perceptual quality - audio compression methods - special hardware implementations (VLSI, DSP, parallel architectures) Papers describing case studies of digital video codec algorithms, technologies, and system integration issues are also welcomed. Conference Chairs: Robert J. Safranek, AT&T Bell Labs Arturo A. Rodriguez, Kaleida Labs Edward J. Delp, Purdue University Program Committee: V. Michael Bove Jr., MIT Media Lab Alexander I. Drukarev, Hewlett-Packard Laboratories Ephraim Feig, IBM Watson Research Center Chad Fogg, University of Washington James D. Johnston, AT&T Bell Laboratories Riccardo Leonardi, University of Brescia (Italy) John O. Limb, Hewlett-Packard Laboratories King Ngan, University of Western Australia James O. Normile, Apple Computer Michael T. Orchard, Universitry of Illinois Davis Pan, Digital Equipment Corporation S. Panchanathan, University of Ottawa K. R. Rao, University of Texas at Arlington S. I. Sudharsanan, Digital Equipment Corporation Eric Viscito, IBM Watson Research Center INSTRUCTIONS FOR AUTHORS Each paper will be reviewed by members of the program committee. The deadline for paper submissions is 11 July 1994. Please submit four copies by mail, or one copy by email or fax, of a five to ten page, double-spaced summary and other requested information to: IS&T/SPIE EI95 Digital Video Compression: Algorithms and Technologies P.O. Box 10 Bellingham, WA 98227-0010 USA Shipping address: 1000 20th St., Bellingham, WA 98225 Telephone: (206) 676-3290 Telefax: (206) 647-1445 Internet abstracts@mom.spie.org Please include the following information: 1. Title of Paper 2. Authors' full names, affiliations, address, phone, fax and email 3. Include a sentence indicating that the paper is intended for Digital Video Compression: Algorithms and Technologies. 4. Summary text (five to 10 double-spaced pages) 5. Authors' Biographies The Conference Chairs and Program Committee will ask authors of the best papers to make journal form submissions to Multimedia Systems or tutorial style submissions to the IEEE Multimedia Magazine. A special issue of the Multimedia Systems journal will be devoted to the theme of the conference. Multimedia Systems is an international journal jointly published by ACM and Springer-Verlag. IEEE Multimedia is a technical magazine co-sponsored by the IEEE Computer Society and the IEEE Communications Society. From rem-conf-request@es.net Tue Mar 22 17:03:33 1994 Received: from watson.ibm.com by osi-west.es.net via ESnet SMTP service id <24683-0@osi-west.es.net>; Tue, 22 Mar 1994 14:03:14 +0000 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3673; Tue, 22 Mar 94 17:03:15 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 2167; Tue, 22 Mar 1994 17:03:14 EST Received: from vindhya.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 22 Mar 94 17:03:12 EST Received: by vindhya.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA17486; Tue, 22 Mar 1994 17:03:08 -0500 From: kandlur@watson.ibm.com (Dilip Kandlur) Message-Id: <9403222203.AA17486@vindhya.watson.ibm.com> X-Sender-Data: Phone: 914-784 7722 or 8-863 7722 To: rem-conf@es.net Subject: CFP - High-Speed Networking and Multimedia Computing 1995 Reply-To: kandlur@watson.ibm.com Date: Tue, 22 Mar 94 17:03:07 -0500 CALL FOR PAPERS High-Speed Networking and Multimedia Computing 1995 Part of IS&T/SPIE Symposium on Electronic Imaging: Science & Technology San Jose Convention Center, San Jose, California, February 5-11, 1995 Advances in computer and networking technologies have fueled the rapid growth of research and development in high-speed networking and multimedia computing. As emerging multimedia technologies set higher performance levels at competitive costs, they are starting to enable and proliferate multimedia solutions in a spectrum of commercial products and laboratory projects. This conference brings together researchers, developers, and practitioners working in all facets of multimedia computing and networking. The conference will serve as a forum for the dissemination of state-of-the-art research, development, and implementations of multimedia systems, technologies, and applications. Presenters will be encouraged to make multimedia presentations and demonstrate their solutions. Papers are solicited in all areas of multimedia, including, but not limited to: 1. Multimedia Computing and Presentation (e.g., hardware and software architectures, real-time operating system services, data representation, time-keeping mechanisms, data streaming and delivery mechanisms, event processing, synchronization and real-time compositing, display mechanisms, media and user interaction) 2. Multimedia User Interfaces (e.g., video widgets, synthetic animation, interactive navigation schemes) 3. Multimedia Networking (e.g., network protocols, quality-of-service control, bandwidth management strategies, transmission of media streams, synchronization mechanisms, connections, data exchange and formats) 4. Multimedia Authoring Systems (media capture and creation, scripting languages, authoring metaphors, editing techniques, data transitions) 5. Multimedia Applications (e.g., video conferencing, e-mail, education and training, digital libraries, medical applications, entertainment and games) 6. Multimedia Services to the Home (e.g., set-top technologies and operating systems; video-on-demand services; video servers; community networking architecture) 7. Collaborative Multimedia Computing (e.g., concurrency control of shared multimedia objects; cyberspace communication, presentation, and interaction; electronic communities; entertainment and games) 8. Multimedia Standards, documents, and data interchange. Conference Chairs: Jacek Maitan, University of North Carolina/Charlotte Mong-Song Chen, IBM T. J. Watson Research Arturo A. Rodriguez, Kaleida Labs Program Committee: H. W. Peter Beadle, U. of Wollongong (Australia) S. K. Chang, University of Pittsburgh Jerome R. Cox, Jr., Washington University J. J. Garcia-Luna, University of California, Santa Cruz Nicolas Georganas, Univ. of Ottawa (Canada) Simon J. Gibbs, Univ. of Geneva (Switzerland) Riccardo Gusella, Hewlett Packard Labs Wendy Hall, U. of Southampton (UK) Dilip D. Kandlur, IBM T. J. Watson Research John O. Limb, Hewlett Packard Labs Thomas D. C. Little, Boston University Ken Morse, Kaleida Labs A. Desai Narasimhalu, National University of Singapore Bonnie Nardi, Apple Computers. P. Venkat Rangan, Univ. of California, San Diego Lawrence A. Rowe, Univ. of California Berkeley Ralf Steinmetz, IBM European Network Center (Germany) Scott M. Stevens, Carnegie Mellon Univ. INSTRUCTIONS FOR AUTHORS Each paper will be reviewed by members of the program committee. The deadline for paper submissions is 11 July 1994. Please submit four copies by mail, or one copy by e-mail or fax, of a five to ten page, double-spaced summary and other requested information to: IS&T/SPIE EI95 High-Speed Networking and Multimedia Computing 1995 P.O. Box 10 Bellingham, WA 98227-0010 USA Shipping address: 1000 20th St., Bellingham, WA 98225 Telephone: (206) 676-3290 Telefax: (206) 647-1445 Internet abstracts@mom.spie.org Please include the following information: 1. Title of Paper 2. Authors' full names, affiliations, address, phone, fax and e-mail 3. Include a sentence indicating that the paper is intended for High-Speed Networking and Multimedia Computing II 4. Summary text (five to ten double-spaced pages) 5. Authors' Biographies The Conference Chairs and Program Committee will ask authors of the best papers to make journal form submissions to Multimedia Systems or tutorial style submissions to the IEEE Multimedia Magazine. Multimedia Systems is an international journal jointly published by ACM and Springer-Verlag. IEEE Multimedia is a technical magazine co-sponsored by the IEEE Computer Society and the IEEE Communications Society. From rem-conf-request@es.net Wed Mar 23 20:18:17 1994 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <01451-0@osi-west.es.net>; Wed, 23 Mar 1994 17:17:58 +0000 Received: from bitski.pa.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA11927; Wed, 23 Mar 94 17:12:29 -0800 Received: by bitski.pa.dec.com; id AA07807; Wed, 23 Mar 94 17:12:23 -0800 Message-Id: <9403240112.AA07807@bitski.pa.dec.com> To: rem-conf@es.net Cc: redell@Pa.dec.com Subject: References Date: Wed, 23 Mar 94 17:12:23 -0800 From: redell@src.dec.com X-Mts: smtp I want to cite the MBone conferencing tools in a paper. (sd, vat, nv, etc.) I'd appreciate suggestions as to the "canonical" papers to reference. Dave Redell From rem-conf-request@es.net Wed Mar 23 21:17:41 1994 Received: from elxr-fddi.jpl.nasa.gov by osi-west.es.net via ESnet SMTP service id <01572-0@osi-west.es.net>; Wed, 23 Mar 1994 18:17:20 +0000 Received: from localhost (localhost [127.0.0.1]) by elxr.jpl.nasa.gov (8.6.8/8.6.6) with SMTP id SAA01209 for ; Wed, 23 Mar 1994 18:17:16 -0800 Message-Id: <199403240217.SAA01209@elxr.jpl.nasa.gov> To: rem-conf@es.net Subject: Vat and X resources Date: Wed, 23 Mar 1994 18:17:13 -0800 From: Dave Hayes Anyone know why the other vat resources would work but the font resources wouldn't? I've been trying to set the title font for vat and "Vat.titleFont" doesn't work at all. Any help would be appreciated. ------ Dave Hayes - Institutional Network & Communications - JPL/NASA - Pasadena CA dave@elxr.jpl.nasa.gov dave@jato.jpl.nasa.gov ...usc!elroy!dxh He who has self-conceit in his head - Do not imagine that he will ever hear the truth. From rem-conf-request@es.net Thu Mar 24 11:20:53 1994 Received: from herman.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <04060-0@osi-west.es.net>; Thu, 24 Mar 1994 08:20:36 +0000 Received: from localhost.cmf.nrl.navy.mil (localhost.cmf.nrl.navy.mil [127.0.0.1]) by herman.cmf.nrl.navy.mil (8.6.7/8.6.6) with SMTP id LAA12885; Thu, 24 Mar 1994 11:20:23 -0500 Message-Id: <199403241620.LAA12885@herman.cmf.nrl.navy.mil> X-Authentication-Warning: herman.cmf.nrl.navy.mil: Host localhost.cmf.nrl.navy.mil didn't use HELO protocol To: Dave Hayes cc: rem-conf@es.net Subject: Re: Vat and X resources In-reply-to: Your message of "Wed, 23 Mar 94 18:17:13 PST." <199403240217.SAA01209@elxr.jpl.nasa.gov> X-Face: -*.ZYbFWa}{2c8NmF| > Anyone know why the other vat resources would work but the font resources > wouldn't? I've been trying to set the title font for vat and "Vat.titleFont" > doesn't work at all. Any help would be appreciated. The resource "Vat.titleFont" doesn't appear to be used in the tk code. The title font (assuming you meant the thing that says "LBL Visual Audio Tool") is controlled by the Vat.ctrlFont resource, which also controls the button font. The title bar font when vat doesn't have control of the audio port is Vat.noAudioFont . You can probably change this in your .vat.tcl if you feel so inclined. Bill From rem-conf-request@es.net Thu Mar 24 23:06:32 1994 Received: from origami.cso.uiuc.edu by osi-west.es.net via ESnet SMTP service id <07025-0@osi-west.es.net>; Thu, 24 Mar 1994 20:06:11 +0000 Received: from [128.174.33.159] (tobago.cso.uiuc.edu) by origami.cso.uiuc.edu with SMTP id AA01741 (5.67b/IDA-1.4.4 for ); Thu, 24 Mar 1994 22:06:04 -0600 Message-Id: <199403250406.AA01741@origami.cso.uiuc.edu> X-Sender: kline@origami.cso.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 1994 22:06:06 -0600 To: maven@cnidr.org, rem-conf@es.net From: cvk@uiuc.edu (Charley Kline) Subject: Maven 2.0a15 available I'll be mailing a copy of Maven 2.0a15 to CNIDR for installation on their anonymous FTP server; presumably the path will be k12.cnidr.org:pub/Mac/Maven-2.0a15.sea.bin when they get it stuck out there. Changes since version 2.0a11 include various bug fixes and the following new features: Control of audio encoding, quantization, and the push-to-talk vs. squelch-controlled mode are now on an "Audio" menu that comes active after the main menu appears. These used to be in the configuration dialog. A new command, "Mute Speaker" also appears on the Audio menu. When checked, no network audio will be played out to the Sound Manager. =46urther improvements in the playout algorithm. It computes playout delay dynamically based on delay variance. It seems to work pretty well, but I'll be interested in anyone's experiences with unusual long speech delays or long gaps in the audio. An even coarser audio quantization (160 milliseconds) is now available. This is nice for sending things like lectures because the packet rate is quite low. Be careful, though; with this it's easy to send packets larger than some pieces of the Internet can handle without fragmentation. (Some) session control. The main window now includes a list containing the names of the participants in the audioconference. The names of the participants are determined from ID messages coming from the other participants. New participants can be added to this list by choosing "New=8A= " from the "Sessions" menu. In this case the list entry temporarily contains what you connected to, preceded by question marks, until an ID message is received from the connection partner. Participants can also be added by an unsolicited ID message being received when "Ignore unsolicited streams" was left unchecked in the config dialog. Maven automatically begins sending audio packets to each new participant no matter how they were added to the list. Participants get removed from the list (and audio stops getting sent to them) when they quit their audioconferencing tool, be it Maven or vat. There is still no way to close a single session in the list short of quitting Maven (unless the other participant quits). You can click on the list participants with the mouse, and they'll highlight, but this doesn't do anything interesting. This session control is still somewhat cheesy as it does not deal with vat mixers very well (doesn't handle the IDLIST message), you still can't tell who's speaking, and there's no way to manipulate the list. The code that implements it is also full of race conditions. I have a student working on this, and I have high hopes that I will soon have some session control at least as useful as what vat does. A new creator signature and a cooler icon. If you can do better, send me your improvement in the form of 'icl8' and 'ics8' resources. Balloon help for the menus and the windows (ooh, ahh). Actually some of the menu help provides a short tutorial on the tradeoffs of the various audio encodings and packet sizes, so you might want to check it out by turning balloon help on in the help menu. Bug reports and comments as always to me. /cvk From rem-conf-request@es.net Fri Mar 25 10:00:06 1994 Received: from access2.digex.net by osi-west.es.net via ESnet SMTP service id <09254-0@osi-west.es.net>; Fri, 25 Mar 1994 06:59:49 +0000 Received: from dean.com. (dean.com) by access2.digex.net with SMTP id AA06453 (5.67a8/IDA-1.5 for ); Fri, 25 Mar 1994 09:59:45 -0500 Message-Id: Date: Fri, 25 Mar 94 09:57:05 EST From: Doug Subject: Multimedia applications on the Internet To: rem-conf@es.net X-Mailer: VersaTerm Link v1.1.1 I was wondering if anyone can help me with the following: I am interested in finding out about multimedia applications that are currently running over the Internet, and the basic functionality of each. Just a few examples would suffice. Do all multimedia applications run over the MBONE? Excuse me for my ignorance, but a quick reply would be greatly appreciated. Doug Pls reply to DougEp233@aol.com if possible. Thanks. From rem-conf-request@es.net Sat Mar 26 02:56:14 1994 Received: from wraith.internode.com.au by osi-west.es.net via ESnet SMTP service id <12725-0@osi-west.es.net>; Fri, 25 Mar 1994 23:55:45 +0000 Received: from simon.Zen by wraith.internode.com.au with DMSP (5.64+1.3.1+0.50/UA-5.23) id AA28896; Sat, 26 Mar 1994 17:24:29 +0930 Date: Sat, 26 Mar 1994 17:24:29 +0930 Message-Id: <9403260754.AA28896@wraith.internode.com.au> To: ccdvu@cc.uq.oz.au Subject: Re: vat for bsdi? (SoundBlaster support) From: simon@internode.com.au (Simon Hackett) Reply-To: simon@internode.com.au Cc: rem-conf@es.net Sender: simon@internode.com.au Repository: internode.com.au Originating-Client: Zen > 1 MEG onboard RAM for samples and patches, > 32 independent stereo panable, hardware digital voices > that's right not just two as on the PAS/SBpro or 1 on the SB > stereo 8 bit or 16 bit 44.1kHz digital outputs with oversampling > stereo/mono 8 bit recording standard, optional 48kHz 16-bit recording > daughterboard (DAT compatible, ADPCM and other type hardware > compression) > real CD, very low noise, frequency response, >85dB dynamic range > free high/low level SDK > dedicated GUS anon ftp with multiple mirrors with lots of pd software. > > I have one, with the line out connected to my hifi. Very high quality digital > sound output. There are also jumpers on the board to disconnect the mixing > of the output and input, allowing you to record and playback (DUPLEX) at the > same time without feedback and crosstalk. A hacker's soundboard IMHO. > > I believe there is a GUS driver for Linux and some other PC-UNIX's. > > RRP price in the US is about $120 with 256 k RAM. Street prices are lower > of course. > Sounds wonderful, I ought to go get one... Meanwhile, for those interested, I'm aware of one other card for PC's that is full duplex voice grade. I've been using them since 1990 for cross-the-internet audio demos using software that has nothing to do with vat (something I threw together myself before I was aware of vat and friends). I'll tell y'all about it, just in case the information helps someone. It's an Artisoft card, which has gone out under a couple of names. Artisoft use it with their own software to do various audio I/O things, but it also has a little programmers' kit (a DOS TSR, only, alas) which allows one to write code for it. It has this sort of spec set: - mono, but very much full duplex audio I/O, with a line in , line out, and telephone handset jack on the back. It comes with its own handset, actually! - a slightly strange sampling rate, 7990.1 samples/second. It can sample as 8 bit mu-law or it can run in an artisoft-provided 2:1 compression mode (quite a nice simple one, which I can explain if anyone cares, and which works fine) - it's very small, and very cheap (street price was circa $50 a year ago). As I said, I've been using 'em for ages. But the GUS card, as described above, does sound like a lot more fun :-) Hey, where is the GUS anonymous FTP site? Cheers, Simon Hackett {------------------------------------------------} { Simon Hackett, Internode Systems Pty Ltd } { E-mail: simon@internode.com.au } { Phone: +61 8 373 1020 Fax: +61 8 373 4911 } { Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA } {------------------------------------------------} From rem-conf-request@es.net Sat Mar 26 22:07:51 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <17105-0@osi-east.es.net>; Sat, 26 Mar 1994 19:07:27 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA17567; Sat, 26 Mar 94 19:07:19 PST Date: Sat, 26 Mar 94 19:07:19 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9403270307.AA17567@viipuri.nersc.gov> To: rem-conf@es.net Subject: H.261 software DECODING frame rate Cc: videophone@vivo.com In an article laced with inaccuracies and misinformation in DataCommunications, March 1994, " PC-Based Videoconferencing Arrives", Elliot Gold also writes: "...Eventually, as PC processors become more powerful, videoconferencing will be handled entirely by software and the PC platform's central processor, eliminating the need for codec chips. One software company, Performance Computing Inc. (Portland, Ore.), now sells packages called Video Decompression Source (VDS) Kits for MPEG, JPEG, and H.261. The H.261 kit decodes color QCIF video at 5.2 fps on a 486 PC with a 66-MHz clock and at 9.0 fps on a Pentium-based PC. Color CIF has been decoded at 1.5 fps on a 66-MHz 486 and 2.5 fps on a Pentium. Other companies are working on software packages that use the PC's main processor to handle not only the decoding but also the endcoding of H.261 video, as well as processing the entire suite of H.320 standards for voice, video, shared screen applications, video framing, communications, and multipoint bridging. ..." Yep... gonna be a BraveNewWorld without codec chips...how many MIPS is needed to support SIMULTANEOUS encoding and decoding of H.221 framed H.261 color CIF at a standards compliant frame rate? ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Sun Mar 27 18:42:23 1994 Received: from news.std.com by osi-west.es.net via ESnet SMTP service id <17601-0@osi-west.es.net>; Sun, 27 Mar 1994 15:42:03 +0000 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA15172; Sun, 27 Mar 1994 18:41:58 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA27023; Sun, 27 Mar 1994 18:41:52 -0500 Date: Sun, 27 Mar 1994 18:41:52 -0500 From: oj@world.std.com (Oliver Jones) Message-Id: <199403272341.AA27023@world.std.com> To: ari@es.net Cc: rem-conf@es.net, videophone@vivo.com In-Reply-To: Ari Ollikainen's message of Sat, 26 Mar 94 19:07:19 PST <9403270307.AA17567@viipuri.nersc.gov> Subject: H.261 software DECODING frame rate Ari Ollikainen wrote ... In an article laced with inaccuracies and misinformation in DataCommunications, March 1994, " PC-Based Videoconferencing Arrives", ... Say, Ari, can you be more specific about the inaccuracies you found? Elliot Gold also writes: "...Eventually, as PC processors become more powerful, videoconferencing will be handled entirely by software and the PC platform's central processor, eliminating the need for codec chips. One software company, Performance Computing Inc. (Portland, Ore.), now sells packages called Video Decompression Source (VDS) Kits for MPEG, JPEG, and H.261. The H.261 kit decodes color QCIF video at 5.2 fps on a 486 PC with a 66-MHz clock and at 9.0 fps on a Pentium-based PC. Color CIF has been decoded at 1.5 fps on a 66-MHz 486 and 2.5 fps on a Pentium. Of course, the trouble with decoding H.261 in H.320 is that the coded bits just keep coming, and there's no capabilities exchange code to restrict the incoming frame rate to anything lower than 7.5 fps. So, I'm not convinced of the utility of a frame-rate capability stated in these m.n fps terms. Plus, the speed of the frame buffer for display is a material factor in useful performance. I wish Elliot had stated whether the PCs in question were equipped with ATI mach32s or Diamond Vipers or whatever. Oliver Jones From rem-conf-request@es.net Sun Mar 27 23:10:01 1994 Received: from harry.lloyd.com by osi-west.es.net via ESnet SMTP service id <18328-0@osi-west.es.net>; Sun, 27 Mar 1994 20:09:33 +0000 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0pl8de-000ERqC; Sun, 27 Mar 94 20:09 PST Message-Id: Date: Sun, 27 Mar 94 20:09 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ari@es.net (Ari Ollikainen), rem-conf@es.net From: brian@lloyd.com (Brian Lloyd) Subject: Re: H.261 software DECODING frame rate Cc: videophone@vivo.com At 19:07 3/26/94 -0800, Ari Ollikainen wrote: >Yep... gonna be a BraveNewWorld without codec chips...how many MIPS is needed >to support SIMULTANEOUS encoding and decoding of H.221 framed H.261 color CIF >at a standards compliant frame rate? Yeah, well, ya couple the output of the camera to one bit on the parallel port of yer PC, see? And the processor just oversamples the port reeeel fast ... ;^) Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From rem-conf-request@es.net Mon Mar 28 04:08:10 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <19378-0@osi-west.es.net>; Mon, 28 Mar 1994 01:07:43 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <04627-0@ceres.fokus.gmd.de>; Mon, 28 Mar 1994 10:57:13 +0200 To: rem-conf@es.net Subject: RTPv2 Cc: casner@isi.edu Date: Mon, 28 Mar 1994 10:57:13 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Comments about RTPv2, suggested changes: General: Many (but not all) of the changes had been discussed at one point or another; the "issues" document actually covers most of these in some depth. As the listing of advantages and disadvantages for each item shows, these are clearly engineering tradeoffs, with no "right" or "wrong" solutions. The choices often hinge on "aesthetics" as much as hard engineering, or on projected uses for RTP. I hope the issues Steve raised can be discussed with a wide participation and consent by the working group so that we can rapidly reach consensus. Executive summary: 1) (ports) we have gone back and forth on this, so let's go forth once again... 2) channel id: no tears for its demise here 3) data options to bit field: all pain, no gain 4) media-specific timestamps: already in draft spec, although the old solution didn't have all the problems attributed to it... 5) sync-marker bit: provide both 6) global source identifier: SSRC change doesn't buy anything 7) control packets: no comment in this message Now to the individual points: 1) Control and data on separate ports: Clearly, either approach will work. Two ports are a bit more work and state (need to open two sockets), but the approach does have a "cleaner" feel to it, particularly if the RTCP functionality will be taken over by a directory service (for distribution applications) or a conference control service. For ST-II and similar protocols, we need twice the number of connections (depending on the encapsulation protocol). Some care needs to be taken in making sure that RTCP packets carry the necessary CSRC/SSRC information. To avoid yet one more configuration option where things can go wrong, I would strongly suggest the current +1 port number scheme, probably within the profile. Also, in case this isn't obvious, mixed lower-layer protocols (multicast UDP for RTCP and ST-II for data) should be avoided. 2) Channel ID I have no problem with dropping it, given my difficulties in explaining it. Savings in complexity and code are minor, from my experience, but it does eliminate one more relatively obscure item to specify. The RTP-over-IP and RTP-over-AAL5 case can be handled by encapsulation. 3) Replace data options with a bit field Again, this is an engineering decision, where appeals to ILP or ALF or whatever are not very convincing, IMHO. The current option processing has basically no processing overhead; I would be really surprised if the bit-checking and skipping, with all the special cases and embedded knowledge of "option" lengths would be either easier to program or faster. (The code, however trivial, would be re-used from RTCP in any event.) If RTCP and RTP are separated, most packets will contain no options (the current option bit would reveal that very quickly). If SSRC should be visible early (this could indeed be desirable), mandating its placement immediately after the fixed header is clearly feasible in the current scheme. I would support that requirement. It would make the critical path before playout insertion longer by exactly one and (check option bit and check whether first option is SSRC instead of just check bit). I have a hard time believing that that matters. Bit masks rob us of any flexibility to add options later, be that for security or other purposes. Also, options could not be added without bumping the version number since "old" applications have no way of knowing what to do with that new header bit (assuming there are any left). While I see the point of avoiding options for production use, they certainly are extremely handy for experimental purposes. Encapsulation doesn't really work here since we don't have a next-protocol option to play with in either UDP or RTP. Yes, we can designate certain format options to say "watch for options ahead" if we have to, but that is nothing but a very ugly hack. Before giving up the flexibility, I would like to see convincing profiling evidence that the current scheme (with the SSRC restriction) is broken. With the number of bits (SSRC, CSRC, encryption, authentication), we have 16 possible packet formats, hardly conducive to treating them as individual "fixed" packets, particularly since the CSRC list is inherently variable-length. Even without security bits, we still have four different packet formats to deal with. 4) Media-specific timestamps Already in the draft on gaia and implemented in Nevot-current. The "audible glitches" argument seems a strawman to me since any adjustment would be done during silence periods. (For media without silence, like music, any adjustment, in band or out of band, is going to cause glitches and would have to be avoided; slow sampling frequency adjustments are probably better in that case.) The "some people read NTP timestamps from a clock for every packet" argument just argues for clearer specs and some common sense... 6) Global source identifiers In short: CSRCs are either not translated or only by systems that have to keep per-source state in any event (mixers). Thus, longer identifiers (random or otherwise) don't buy anything. SSRC: If I understand the proposal correctly, the new proposal would work as follows: Translators (think of a firewall as an example) would see two cases: 1) Packets received without SSRC get their IP address inserted as SSRC. 2) Packets with SSRC keep it. Note that this works ONLY if the translator uses the IP address. A random number will not work unless the translator keeps state and maps incoming network address to (random) SSRC value. In that case, the whole argument for random SSRC values, i.e., no state in translators, goes away. Using IP addresses in such a way has a number of consequences. First, typing RTP to IP unnecessarily seems like a bad idea on the face of it. (Witness the FTP problems with IPng.) Also, RTP can and should run over non-IP networks (CLNP and direct ATM connection come to mind). The WG had considered other network addresses as identifier (with a complicated type-value mechanism) and gotten away from that. There is one solution for the post-IP world: Carry a random 32-bit SSRC in EVERY packet, kind of like an end point identifier. (Using an actual EID, if ever defined, is not likely to work since any proposals entertained are much larger than 32 bits since they are not meant to be carried in every packet, if I understand Noel Chiappa right.) I'm not saying that random 32-bit quantities are inherently a bad idea, but we should be honest enough to then admit to having increased the header by 50% (from 8 to 12 bytes) in all cases. Tying the interpretation of an element of an application-level protocol like RTP to whether IPv4 addresses are still unique system IDs or not seems like a dangerous proposition. (Remember that one of the goals of IPng is to leave applications as untouched as possible.) The main argument against a mapping table in a translator seems to be the confusion that arises after a translator reboots. First, we should note that the same problem arises each time an end application reboots and gets a different source port. Given the timescales of rebooting vs. typical playout buffers, it is unlikely that there will be audible confusion. At worst, there will be a wrong talker indication until the source descriptors "catch up". We should be able to try what happens with todays RTP applications quite easily. Other comments: Loop detection with random IDs has a rather nasty drawback: Since both loops and collisions are unlikely, we can't be sure which of the two we are seeing. Loops would best be detected by multiple identical sender identification strings. None of the suggested collision-recovery mechanisms seem particularly general or foolproof. Since they are used only extremely infrequently, the likelihood that different implementations will work together correctly during the collision is fairly low. Thus, either we can convince ourselves that random IDs work without recovery, or we shouldn't use them. Thus, I'd suggest truly random 32-bit numbers instead of IP addresses. Relying on IP addresses in any shape or form brings up fond memories of IP addresses lurking in the depths of ftp. Just make sure that not every application uses the standard Unix random number generator with the same seed... ------------ Since we have 6 bits to play with after the demise of the channel ID, I would suggest using one bit as a "start of synchronization unit" flag. Avoids a profiling decision and provides additional information to the receiver (silence substitution comes to mind). We also avoid the fruitless which-is-better arguments for each media. We have existence proofs for both audio and video that generating either is easy. This, IMHO, appears to be a better use of the bits than "fixing" the current variable-header mechanism. This message is approaching the length of Steve's, so I'll comment on the RTCP issues separately. --- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin From rem-conf-request@es.net Mon Mar 28 04:57:49 1994 Received: from sage.ucs.uwa.edu.au by osi-west.es.net via ESnet SMTP service id <19672-0@osi-west.es.net>; Mon, 28 Mar 1994 01:57:30 +0000 Received: (toivo@localhost) by sage.ucs.uwa.edu.au (8.6.7/8.6.4) id RAA15525 for rem-conf@es.net; Mon, 28 Mar 1994 17:59:16 +0800 Date: Mon, 28 Mar 1994 17:59:16 +0800 From: Toivo Pedaste Message-Id: <199403280959.RAA15525@sage.ucs.uwa.edu.au> To: rem-conf@es.net Subject: var-dynamic won't run under Solaris 2.3 Content-Length: 231 I'm trying to run vat (dynamically linked) under solaris 2.3 and it segmentation faults before is brings up a window. Anyone know why it would do this, its supposed to work. I tried tracing it but it produced nothing informative. From rem-conf-request@es.net Mon Mar 28 05:44:32 1994 Received: from tel.vtt.fi by osi-west.es.net via ESnet SMTP service id <19830-0@osi-west.es.net>; Mon, 28 Mar 1994 02:44:09 +0000 Received: by tel.vtt.fi id AA11662 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 28 Mar 1994 13:43:54 +0300 Date: Mon, 28 Mar 1994 13:43:54 +0300 From: Jarmo Molsa Message-Id: <199403281043.AA11662@tel.vtt.fi> To: rem-conf@es.net Subject: RTP in PC-environment / comments to RTP changes When reading the RTP-specification, we got the impression, that application data (e.x. audio data) is handled at very low-level. The text seems to be rather "sampling-oriented", i.e. the application program is supposed do some hardware-level things, like collecting continuously individual samples of audio. Have we got the correct impression? In PC-environment we are using a specific audio/video codec, which hides all low-level, sample-oriented things. The A/V codec provides application programming interface (a set of functions for accessing the codec). It seems, that Unix workstations are the primary testing environment for RTP. Has anybody done any RTP testing in PC-environment? We hope, that PC-environment will be properly considered, when specifying RTP-protocol. Some comments to proposed RTP changes: -------------------------------------- 1. Control and data on separate ports: At the moment we are experimenting in DOS-environment and using the PC/TCP-software. This combination limits the number of descriptors to 20 (including file descriptors and sockets). If several ports (and thus sockets) should be used, the maximum descriptor count may cause problems, especially if the application needs to operate on several files at the same time. For this reason, the usage of separate ports should be diminished. 2. Remove Channel ID, put multiplexing into encapsulations Does the channel ID really add so much overhead, that it should be removed? We would like to transmit several RTP-streams (e.g. audio and video) over a single transport connection (to be able to get equal transport service). This could partly help in inter-media synchronization. Sincerely Jarmo Molsa From rem-conf-request@es.net Mon Mar 28 06:25:56 1994 Received: from noc.BelWue.DE by osi-west.es.net via ESnet SMTP service id <19995-0@osi-west.es.net>; Mon, 28 Mar 1994 03:25:19 +0000 Received: from kssun7.rus.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA25230 (5.65c8/IDA-1.4.4 for ); Mon, 28 Mar 1994 13:23:03 +0200 Received: by kssun7.rus.uni-stuttgart.de (4.1/BelWue-1.3SUN) id AA02371; Mon, 28 Mar 94 13:20:32 +0200 Date: Mon, 28 Mar 94 13:20:32 +0200 From: Schulz@rus.uni-stuttgart.de (Claus-Dieter Schulz) Message-Id: <9403281120.AA02371@kssun7.rus.uni-stuttgart.de> To: rem-conf@es.net, toivo@ucs.uwa.edu.au Subject: Re: var-dynamic won't run under Solaris 2.3 > > I'm trying to run vat (dynamically linked) under solaris 2.3 and > it segmentation faults before is brings up a window. Anyone know > why it would do this, its supposed to work. > I've the same problem here, when using a SparcStation10, but vat runs fine on my SX10 under Solaris2.3 Claus-Dieter From rem-conf-request@es.net Mon Mar 28 07:28:48 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <20331-0@osi-west.es.net>; Mon, 28 Mar 1994 04:28:17 +0000 Received: from topo.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Mar 1994 13:27:46 +0100 To: Toivo Pedaste cc: rem-conf@es.net Subject: Re: var-dynamic won't run under Solaris 2.3 In-reply-to: Your message of "Mon, 28 Mar 94 17:59:16 +0700." <199403280959.RAA15525@sage.ucs.uwa.edu.au> Date: Mon, 28 Mar 94 13:27:44 +0100 From: Atanu Ghosh >> I'm trying to run vat (dynamically linked) under solaris 2.3 and >> it segmentation faults before is brings up a window. Anyone know >> why it would do this, its supposed to work. >> >> I tried tracing it but it produced nothing informative. We have had no problems running vat under solaris 2.3. I tried the following just in case there was something that we set up localally in our environments and it worked fine. $ env - DISPLAY=:0 ./vat.dyn The env - throws away all of your environment variables. Atanu. From rem-conf-request@es.net Mon Mar 28 07:31:12 1994 Received: from iraun1.ira.uka.de by osi-west.es.net via ESnet SMTP service id <20369-0@osi-west.es.net>; Mon, 28 Mar 1994 04:30:49 +0000 Received: from groucho.telematik.informatik.uni-karlsruhe.de by iraun1.ira.uka.de with SMTP (PP); Mon, 28 Mar 1994 14:28:20 +0200 Received: by groucho.telematik.informatik.uni-karlsruhe.de (5.65/DEC-Ultrix/4.3) id AA26479; Mon, 28 Mar 1994 14:28:11 +0200 Received: by wagstaff.telematik.informatik.uni-karlsruhe.de (5.65/DEC-Ultrix/4.3) id AA03911; Mon, 28 Mar 1994 14:28:06 +0200 Message-Id: <9403281228.AA03911@wagstaff.telematik.informatik.uni-karlsruhe.de> To: moongw@helios.ece.arizona.edu Cc: rem-conf@es.net Subject: IP multicasts on DEC 5000 Ultrix 4.3 Date: Mon, 28 Mar 94 14:28:05 +0200 From: martin@tk.telematik.informatik.uni-karlsruhe.de X-Mts: smtp Hello, I had to solve the problem you described on my own. We were requested to use the latest Mbone routing algorithms (which include pruning) in order to be connected to the Mbone. This is what I did: 1. Take the binary kit for Ultrix 4.2a from gregorio.stanford.edu (ipmulticast-ultrix4.2a-binary.tar) and put the contents to the appropriate places. 2. Get the latest multicast distribution for SUNs. (It was 3.1Beta in my case.) Take the mrouted sources from this kit and move the following kernel sources to the appropriate places in your /sys resp. /usr/sys directories (overriding those that came from ipmulticast-ultrix4.2a-binary.tar): sys.sunos413/netinet/igmp.c sys.sunos413/netinet/igmp.h sys.sunos413/netinet/igmp_var.h sys.sunos413/netinet/ip_mroute.c sys.sunos413/netinet/ip_mroute.h 3. Apply the follwowing patch to igmp.c that came from the SUN kit: *** igmp.c.orig Sun Jun 23 09:24:52 1991 --- igmp.c Thu Feb 24 13:10:00 1994 *************** *** 281,288 **** --- 281,293 ---- imo->imo_multicast_loop = 0; #endif MROUTING + #ifdef ultrix ip_output(m, (struct mbuf *)0, (struct route *)0, + IP_MULTICASTOPTS, (struct socket *)0, mopts); + #else + ip_output(m, (struct mbuf *)0, (struct route *)0, IP_MULTICASTOPTS, mopts); + #endif m_free(mopts); ++igmpstat.igps_snd_reports; 4. Add the following lines to /sys/conf/files: net/netinet/igmp.c optional inet net/netinet/ip_mroute.c optional inet Of course, don't forget to include options MULTICAST options MROUTING in your /sys/conf/mips/MACHINE file. (I think, a change to /sys/conf/mips/newvers.sh is recommended too to have a boot message that reminds you that you have a special kernel, but it's not essential.) 5. Build a new kernel (and make sure you keep the old one). 6. Reboot and pray. 7. If you get here and your machine runs, compile the mrouted from the SUN kit. It should work with no hassle. Configure your /etc/mrouted.conf, run your mrouted and join the Mbone! I hope it helps and that I didn't forget anything important. Good luck, --Martin Richartz Martin Richartz -- Institut fuer Telematik - Universitaet Karlsruhe, Germany E-Mail: martin@tk.telematik.informatik.uni-karlsruhe.de From rem-conf-request@es.net Mon Mar 28 07:32:10 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <20383-0@osi-west.es.net>; Mon, 28 Mar 1994 04:31:23 +0000 Received: from topo.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Mar 1994 13:31:05 +0100 To: Schulz@rus.uni-stuttgart.de (Claus-Dieter Schulz) cc: rem-conf@es.net, toivo@ucs.uwa.edu.au Subject: Re: var-dynamic won't run under Solaris 2.3 In-reply-to: Your message of "Mon, 28 Mar 94 13:20:32 +0100." <9403281120.AA02371@kssun7.rus.uni-stuttgart.de> Date: Mon, 28 Mar 94 13:31:04 +0100 From: Atanu Ghosh >> > >> > I'm trying to run vat (dynamically linked) under solaris 2.3 and >> > it segmentation faults before is brings up a window. Anyone know >> > why it would do this, its supposed to work. >> > >> I've the same problem here, when using a SparcStation10, >> but vat runs fine on my SX10 under Solaris2.3 >> >> Claus-Dieter Ah, we are using Classics and LXs. Atanu. From rem-conf-request@es.net Mon Mar 28 17:15:37 1994 Received: from ADRASTEA.LCS.MIT.EDU by osi-west.es.net via ESnet SMTP service id <23808-0@osi-west.es.net>; Mon, 28 Mar 1994 14:15:17 +0000 Received: by adrastea.lcs.mit.edu; id AA01602; Mon, 28 Mar 1994 17:15:27 -0500 Date: Mon, 28 Mar 1994 17:15:27 -0500 From: Garrett Wollman Message-Id: <9403282215.AA01602@adrastea.lcs.mit.edu> To: rem-conf@es.net Subject: IETF audio quality While trying to listen to my Fearless Leaders talking at the INT-SERV meeting on channel 2 today, I noticed a horrendous amount of humming noise in the signal, which (when I jumped over to check) was not present on channel 1. Can anybody investigate this (and hopefully fix it during the break)? -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. formerly known as | It is a bond more powerful than absence. We like people wollman@emba.uvm.edu | who like Shashish. - Claude McKenzie + Florent Vollant From rem-conf-request@es.net Mon Mar 28 18:48:34 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <24126-0@osi-west.es.net>; Mon, 28 Mar 1994 15:48:13 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14457(8)>; Mon, 28 Mar 1994 15:47:45 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Mon, 28 Mar 1994 15:47:59 -0800 To: rem-conf@es.net cc: mbone@isi.edu Subject: Video thumbnails Date: Mon, 28 Mar 1994 15:47:44 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Mar28.154759pst.16143@ecco.parc.xerox.com> Hello... Those of you running nv 3.2 may be noticing some weird behavior with regard to the nv 'thumbnail' images in the main nv window. They'll show up too large, clipping in a funny way. This is normal, and shouldn't cause any real problems. The reason is that we're sending 640x480 video (as you'll notice when you click to open the window) and nv 3.2 wasn't designed to properly cope with that. It has been fixed for the next release. Hopefully, the larger images will make the slides easier to read this time around. I'd be interested in feedback about that, though. The price you pay is in frame rate and the speed at which it can correct for any packet loss which might have occurred. Is it worth it? -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Mar 28 20:44:23 1994 Received: from sage.ucs.uwa.edu.au by osi-west.es.net via ESnet SMTP service id <24671-0@osi-west.es.net>; Mon, 28 Mar 1994 17:43:54 +0000 Received: (toivo@localhost) by sage.ucs.uwa.edu.au (8.6.7/8.6.4) id JAA23636; Tue, 29 Mar 1994 09:45:56 +0800 Date: Tue, 29 Mar 1994 09:45:56 +0800 From: Toivo Pedaste Message-Id: <199403290145.JAA23636@sage.ucs.uwa.edu.au> To: Denny.Gentry@Eng.Sun.COM, rem-conf@es.net Subject: Re: var-dynamic won't run under Solaris 2.3 X-Sun-Charset: US-ASCII I'm using an IPC and Openwin 3.3. I tied zeroing the environment apart from the DISPLAY variable but that didn't help. The annoying thing is that I'm sure that it was working when they were repairing the Hubble. I have no idea what might have changed. When I first tried it it didn't work, then somehow I got it work for a while a few months ago and it doesn't work again now. I don't know of any changes I made that could affect this, but then I cann't think of any changes that might cause it to crash. The Sunos versions of other tools ie sd and ivs work without problem. From rem-conf-request@es.net Tue Mar 29 04:30:03 1994 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Tue, 29 Mar 1994 01:29:39 +0000 Date: Tue, 29 Mar 1994 01:29:39 +0000 X400-Originator: rem-conf-request@es.net X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=ESnet/ADMD= /C=US/;osi-west.e.175:29.02.94.09.29.39] Priority: Non-Urgent DL-Expansion-History: rem-conf@es.net ; Tue, 29 Mar 1994 01:29:39 +0000; From: Michel Colin Message-ID: <1230001*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: Toivo Pedaste (Non Receipt Notification Requested) Cc: "Denny.Gentry" (Non Receipt Notification Requested), rem-conf (Non Receipt Notification Requested) Subject: Re: var-dynamic won't run under Solaris 2.3 I use vat on a sparc LX running Solaris 2.3 and if I use vat.dyn, core dump occurs. To solve the problem, I load a special shared library .vat-compat-lib.so before running vat.dyn and everything works fine ! michel =============================================================================== Michel Colin Tel. +32-2-650 57 03 Fax: +32-2-641 38 16 Universite Libre de Bruxelles Faculte des Sciences Service Telematique et Communication CP 230, Boulevard du triomphe B-1050 Bruxelles BELGIUM RFC822: colin@helios.iihe.rtt.be X.400 : C=be;ADMD=rtt;PRMD=iihe;O=helios;S=colin; X.500 : @c=be@o=Universite Libre de Bruxelles@ou=Faculte des Sciences@ou=Service Telematique et Communication@cn=Michel Colin ------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 29 08:31:07 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <27078-0@osi-west.es.net>; Tue, 29 Mar 1994 05:30:47 +0000 Date: Tue, 29 Mar 94 8:30:26 EST From: Chip Elliott To: rem-conf@es.net Subject: IETF - Bad Audio! I was trying very hard to follow Craig Partridge's WG but it was almost incomprehensible due to bad audio. Lots of hum and almost inaudible voice levels. Plus little bursts of packet drops but they were hardly the worst of it. Any chance that folks on site could make sure the mikes are set up right? thanks, - Chip Elliott From rem-conf-request@es.net Tue Mar 29 08:51:48 1994 Received: from lhc.nlm.nih.gov by osi-west.es.net via ESnet SMTP service id <27169-0@osi-west.es.net>; Tue, 29 Mar 1994 05:51:29 +0000 Received: from billings.nlm.nih.gov by nlm.nih.gov (4.1/SMI-4.0) id AA12809; Tue, 29 Mar 94 08:51:22 EST Received: by billings.nlm.nih.gov (4.1/SMI-4.1) id AA00488; Tue, 29 Mar 94 08:51:27 EST Date: Tue, 29 Mar 94 08:51:27 EST From: rodgers@nlm.nih.gov (R. P. Channing ["Rick"] Rodgers) Message-Id: <9403291351.AA00488@billings.nlm.nih.gov> To: rem-conf@es.net, frederic@parc.xerox.com Subject: Re: Video thumbnails Cc: mbone@ISI.EDU > Hello... > > Those of you running nv 3.2 may be noticing some weird behavior with regard > to the nv 'thumbnail' images in the main nv window. They'll show up too large, > clipping in a funny way. I assume you refer to the IETF? I think it would be helpful if messages such as this *always* *explicitly* referred to the program they are concerned with. > Hopefully, the larger images will make the slides easier to read this time > around. I'd be interested in feedback about that, though. The price you pay > is in frame rate and the speed at which it can correct for any packet loss > which might have occurred. Is it worth it? I noted the anomalous behavior, but found the video was terrific (the overheads were indeed readable). As for the audio.... 8^( Keep it up, Ron! > Ron Frederick > frederick@parc.xerox.com > From rem-conf-request@es.net Tue Mar 29 23:42:25 1994 Received: from sage.ucs.uwa.edu.au by osi-west.es.net via ESnet SMTP service id <00187-0@osi-west.es.net>; Tue, 29 Mar 1994 20:42:03 +0000 Received: (toivo@localhost) by sage.ucs.uwa.edu.au (8.6.7/8.6.4) id MAA28730; Wed, 30 Mar 1994 12:38:57 +0800 Date: Wed, 30 Mar 1994 12:38:57 +0800 From: Toivo Pedaste Message-Id: <199403300438.MAA28730@sage.ucs.uwa.edu.au> To: toivo@ucs.uwa.edu.au, colin@helios.iihe.rtt.be Subject: Re: var-dynamic won't run under Solaris 2.3 Cc: Denny.Gentry@Eng.Sun.COM, rem-conf@es.net X-Sun-Charset: US-ASCII From colin@helios.iihe.rtt.be Tue Mar 29 17:38 WST 1994 > I use vat on a sparc LX running Solaris 2.3 and if I use vat.dyn, > core dump occurs. > > To solve the problem, I load a special shared library .vat-compat-lib.so > before running vat.dyn and everything works fine ! > > If you have a WWW client try the following url > http://www.iihe.ac.be/ > and go to Multimedia / mice-nsc / sources & binaries directory > and retrieve vat > The file include vat.dyn .vat-compat-lib.so and a script to preload the file > and execute vat.dyn ! > You can also retrieve it by ftp > sun4.iihe.ac.be /pub/mice-nsc/vat.dyn.tar.gz Thanks, that fixes my problem From rem-conf-request@es.net Wed Mar 30 12:11:47 1994 Received: from uucp7.netcom.com by osi-west.es.net via ESnet SMTP service id <02569-0@osi-west.es.net>; Wed, 30 Mar 1994 09:11:30 +0000 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id IAA26981; Wed, 30 Mar 1994 08:01:53 -0800 Received: from diablo.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA03600; Wed, 30 Mar 94 09:51:11 EST Received: by diablo.insoft.com (4.1/SMI-4.1) id AA01465; Wed, 30 Mar 94 10:03:57 EST Date: Wed, 30 Mar 94 10:03:57 EST From: cemarley@diablo.insoft.com (Conall E. Marley) Message-Id: <9403301503.AA01465@diablo.insoft.com> Reply-To: "Conall E. Marley" To: rem-conf@es.net Subject: 4.1.3_U1 kernel mods Has anyone successfully reconfigured a 4.1.3_U1 kernel? I can get it to config, but it builds a kernel that isn't bootable. I'm using the Multicast Source found on: parcftp.xerox.com:pub/net-research/ipmulti-sunos41x.tar.Z Is there more recent Multicast Source out there that works with 4.1.3_U1? Thanks for the help. ========================================================================= Conall Marley Phone: (717) 730-9501 Product Manager FAX : (717) 730-9504 InSoft, Inc. email: cemarley@insoft.com From rem-conf-request@es.net Wed Mar 30 12:51:14 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <02680-0@osi-west.es.net>; Wed, 30 Mar 1994 09:50:49 +0000 Received: from hun.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 30 Mar 1994 09:50:45 -0800 Date: Wed, 30 Mar 1994 09:48:39 -0800 From: feldy@ISI.EDU Posted-Date: Wed, 30 Mar 1994 09:48:39 -0800 Message-Id: <199403301748.AA02561@hun.isi.edu> Received: by hun.isi.edu (5.65c/4.0.3-4) id ; Wed, 30 Mar 1994 09:48:39 -0800 To: rem-conf@es.net Subject: I'm seeing 50% loss on NV IETF channel 1 (Plenary) I'm getting approx. 40-50 kbps, and always 40%-50% loss. The picture and slides are still fine, just wondered whether this was normal. I'm watching at ISI in Los Angeles. Bob From rem-conf-request@es.net Wed Mar 30 12:57:05 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <02704-0@osi-west.es.net>; Wed, 30 Mar 1994 09:56:41 +0000 Received: from hun.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 30 Mar 1994 09:56:34 -0800 Date: Wed, 30 Mar 1994 09:54:24 -0800 From: feldy@ISI.EDU Posted-Date: Wed, 30 Mar 1994 09:54:24 -0800 Message-Id: <199403301754.AA02568@hun.isi.edu> Received: by hun.isi.edu (5.65c/4.0.3-4) id ; Wed, 30 Mar 1994 09:54:24 -0800 To: rem-conf@es.net Subject: It just returned to 0% loss at ISI From rem-conf-request@es.net Thu Mar 31 04:35:24 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <05745-0@osi-west.es.net>; Thu, 31 Mar 1994 01:35:01 +0000 Via: uk.ac.edinburgh.castle; Thu, 31 Mar 1994 10:34:03 +0100 Received: from ucs.ed.ac.uk by castle.ed.ac.uk id aa13051; 31 Mar 94 10:33 BST Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Thu, 31 Mar 94 10:33:49 BST Date: Thu, 31 Mar 94 10:33:48 BST Message-Id: <1549.9403310933@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: 4.1.3_U1 kernel mods To: "Conall E. Marley" , rem-conf@es.net In-Reply-To: Conall E. Marley's message of Wed, 30 Mar 94 10:03:57 EST Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 650 6552 > Has anyone successfully reconfigured a 4.1.3_U1 kernel? I can get it to > config, but it builds a kernel that isn't bootable. > > I'm using the Multicast Source found on: > > parcftp.xerox.com:pub/net-research/ipmulti-sunos41x.tar.Z > > Is there more recent Multicast Source out there that works with 4.1.3_U1? > > Thanks for the help. I had no problem building and booting from a 4.1.3_U1 kernel. I am using version 3.1 of the multicast code which you should merge with the contents of the tar file you have. The 3.1 code is in a file called ipmulti-3.1beta.tar.Z from xerox. On a related topic does anyone know why I should get so many of these messages coming from mrouted: Mar 31 10:17:40 scorpio mrouted[146]: warning - prune message received incorrectly Graeme From rem-conf-request@es.net Thu Mar 31 16:04:28 1994 Received: from mindvox.phantom.com by osi-west.es.net via ESnet SMTP service id <08068-0@osi-west.es.net>; Thu, 31 Mar 1994 13:04:12 +0000 Received: by mindvox.phantom.com (4.1/SMI-4.1) id AA29864; Thu, 31 Mar 94 16:02:26 EST Date: Thu, 31 Mar 1994 16:02:24 -0500 (EST) From: Howard Katzman Subject: General Information To: rem-conf@es.net In-Reply-To: <1549.9403310933@scorpio.ucs.ed.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have been on this list for a short while. The little I can make out of what is going on sounds interesting, but is there a faq to explain more fully the terms. Is this "internet telephone" only usable by mainframes or are dialups powerful enough? I suppose the faq would answer these questions. Thank you, Howard katzman@phantom.com From rem-conf-request@es.net Thu Mar 31 22:59:45 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <09223-0@osi-west.es.net>; Thu, 31 Mar 1994 19:59:18 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA28827; Thu, 31 Mar 94 22:59:14 EST Date: Thu, 31 Mar 1994 22:48:35 -0500 (EST) From: Allen Robel Subject: Newbridge T1 Sbus card. (was: VAT to Phone System Gateway?) To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Hi all, I received a product description from Newbridge describing a T1 card with integral CSU they are close to releasing. I thought that this would be of interest to those involved in the 'VAT to Phone System' thread. There is=20 contact info contained below as well. regards, allen ---------------------- >% cut here %< ------------------------ Introduction This product bulletin is announcing that Newbridge Microsystems has develop= ed,=20 in conjunction with SunConnect, the first T1 network interface card (with a= n=20 integral CSU) for Sun SPARCstations. Simply put, this card allows a custom= er=20 to take a RJ-45 jack (provided by your carrier when you order T1 service) a= nd=20 plug it directly into your SPARCstation. You will find the following produ= ct=20 information useful if your customers are: =A5 using SPARCstations in a wide area network, =A5 using full or fractional T1 services, =A5 using SunLink's X.25, PPP, or Frame Relay with Solaris 1.X or 2.X, =A5 internetworking distributed LANs via the public switched phone network= =20 (PSTN), =A5 developing applications for regional or long-distance carriers, or =A5 developing voice processing applications on open systems. For more information about this product, please contact Jeff VanZwol (jvanzwol@ newbridge.com) or Ed Hacker (ehacker@newbridge.com) at Newbridge Microsystems. Phone 1-800-267-7231 or 1-613-592-0714. =20 Fax 1-613-592-1320. NM212=AA Product Description Newbridge Microsystems=D5 SBus T1 Wide Area Network (WAN) interface card pr= ovide=20 SBus platforms with T1 (1.544 Mbps) connectivity directly onto Sun=20 SPARCstations =A8or SPARCservers=A9. The NM212 is an intelligent T1 networ= k=20 interface card which has an integral CSU and can terminate up to 24 data=20 circuits over one primary rate link. The NM212 card delivers channelized T= 1=20 to the SPARCstation. Simply put, this card offers the functionality of a= =20 three 8-channel High Speed Interface (HSI) cards, a 24 channel CSU/DSU, and= =20 associated cabling, All this is condensed onto a single-width SBus card wit= h a=20 RJ-48C connector. The NM212 can connect Sun SPARCstations=AA with T1 networks. The NM212 is = an=20 ideal primary rate network interface card for digital access to public=20 networks and for point-to-point applications. The NM212 can be used as=20 intelligent CSU, offering ESF and D4 conversion for equipment with T1=20 interfaces. The NM212 supports up to 24 concurrent DS-0 rate connections over a T1 link= . =20 Additionally, the NM212 supports both sub-rate and super-rate data channels= . =20 Super-rate channels may consist of contiguous and non-contiguous DS-0 time= =20 slots. Sub-rate data channels are supported in multiples of 8 Kbps data ra= tes. By using the Graphical User Interface (GUI) or Command Line Interpreter (CL= I),=20 all T1/E1 link and circuit parameters can be software configured directly b= y=20 the customer. An array of performance statistics and alarms allows for a= =20 detailed evaluation of system status at any time. Network administrators w= ill=20 be able to remotely configure the NM212 via any X-Windows compatible system= by=20 redirecting the GUI=D5s or CLI output to the administrator=D5s workstation.= =20 Additionally, the NM212 can be configured to direct alarms to the system=20 console of the host.=20 The NM212 card operates with SunNet Manager. The SunNet Manager agent,=20 residing on the Sun host, will allow access to the NM212's status parameter= s=20 and alarm conditions. As an element in a network operated by SunNet Manager= ,=20 the customer will benefit from the remote access capabilities, easier netwo= rk=20 fault analysis, better network management and control. NM212=AA Technical Description Solaris Operating System Requirements =A5 Requires Solaris 1.X or 2.X operating system. =A5 Implemented as a Solaris 1.X ifnet driver or Solaris 2.X streams-based= =20 device driver. =A5 Integrated with SunLink's X.25, PPP, and Frame Relay software. T1 Line Features =A5 Network Connector: One RJ-48C connector=20 =A5 Channels supported: Eight (8) or twenty-four (24)=20 =A5 Framing: D4 and Extended Superframe (ESF) =A5 Line Code: B8ZS, JB7, or clear channeling =A5 Alarms: Yellow Alarms, Red Alarm, Robbed Bit Signaling,= =20 Alarm Indication Signal=20 =A5 Line Interfaces: CSU (Channel Service Unit) or DSX-1 Line Interfac= e=20 Module =09=09 Loopback Features =A5 Per channel loopback =A5 Local line loopback =A5 Local and remote framer loopback =A5 Local FDL/TS0 loopback NM212=AA Application Note - LAN Internetworking NM212 can reside in each Sun SPARCstation connecting two inter-networked Lo= cal=20 Area Network (LANs A & B). With the NM212 card resident in each SPARCstati= on=20 connected to the T1, traffic (data packets) from a node in LAN A can be=20 delivered to a node in LAN B. The "gateway" SPARCstation (for LAN A)=20 determines which packets must be routed to a node on the other LAN, then=20 reroutes this inter-LAN traffic across the T1 span to the other "gateway"= =20 SPARCstation (for LAN B). The SPARCstation (receiving the traffic) routes= =20 incoming packets onto the LAN and to the destination node on it's local=20 network. By having a NM212 card resident in each SPARCstation, the=20 SPARCstation provides the functionality of a bridge, router, and CSU/DSU us= ed=20 for LAN-to-LAN connection. The LAN protocols (e.g. TCP/IP) are encapsulate= d=20 in a WAN protocol (X.25, PPP, Frame Relay) to ensure integrity of the data= =20 when it crosses the T1 span. =20 NM212=AA Application Note - Client/Server Applications The NM212 can reside in each Sun SPARCstation. A compute-intensive, multi- media server application (e.g. a video training application) can reside on= =20 SPARCstation resident on LAN A. The client portion of the application can= =20 reside on each node on LAN B. With the NM212 card resident in each of the= =20 SPARCstations, client/server applications (which require large bandwidth) c= an=20 be used by all nodes on the corporate network. This is independent of the L= AN=20 with the client application and the SPARCstation with the server applicatio= n. NM212=AA Application Note - Video Conferencing The NM212 supports Sun SPARC-based video conferencing across the Public=20 Switched Telephone Network (PSTN) using T1 communications facilities. Vide= o=20 conferencing applications require a large amount of bandwidth and, at a=20 minimum, require the bandwidth supplied with a T1 trunk. Conventional vide= o=20 conferencing systems can provide a cost-effective conferencing capability= =20 across a digital data network. These systems provide a conference session= =20 across a wide area or local area networks, allowing multiple people in the= =20 same building to conference using their internal LAN or allowing multiple= =20 people on different continents to conference using the corporate WAN. Vide= o=20 conferencing systems can use either common LAN protocols (e.g. TCP/IP) or= =20 proprietary protocols to carry the video signals from point to point in a L= AN.=20 When video conferencing across a WAN, both the LAN protocols or the=20 proprietary protocols are encapsulated in a WAN protocol (X.25, PPP, Frame= =20 Relay) to ensure integrity of the data when it crosses the T1 span.