From rem-conf Sat May 01 16:47:19 1999 From rem-conf-request@es.net Sat May 01 16:47:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10djH3-0003Up-00; Sat, 1 May 1999 16:34:21 -0700 Received: from dip.eecs.umich.edu [141.213.4.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10djH1-0003Tq-00; Sat, 1 May 1999 16:34:20 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.9.2/8.9.2) id TAA27982; Sat, 1 May 1999 19:33:57 -0400 (EDT) From: Dave Thaler Message-Id: <199905012333.TAA27982@dip.eecs.umich.edu> Subject: Re: Working group last call on the RTP MIB To: bill.strahm@intel.com (Strahm Bill) Date: Sat, 1 May 1999 19:33:57 -0400 (EDT) Cc: fenner@research.att.com, bill.strahm@intel.com, mbaugher@intel.com, isuconick@videoserver.com, rem-conf@es.net, casner@cisco.com, c.perkins@cs.ucl.ac.uk In-Reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB201362DCA@orsmsx41.jf.intel.com> from "Strahm, Bill" at Apr 29, 99 03:18:06 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Based on the comments in this thread, I probably need to go read this MIB. However, I have two immediate comments on the comments. > rtpSessionIfIndex refers to the "Internet Standard MIB". Should this > reference have an RFC reference attached to it, since there are lots of > MIBs that are Internet Standards? > [Bill Strahm responds] You are correct. See if you like this better > "The ifIndex value is set to the corresponding value > from MIB-II (See RFC 1213, "Management Information > Base for Network Management of TCP/IP-based internets: > MIB-II). This is the interface that the RTP stream is RFC 1213 should not be referenced for ifIndex. The Interfaces MIB (RFC 2233) updates the ifTable in RFC 1213 and should be referenced instead. > The MIB specifies a DisplayString for the sender's and receiver's CNAME > and Tool. However, the RTP spec says that SDES items are encoded using > UTF-8. Although it suggests that CNAME should be in ASCII it doesn't > seem to require it, and there is no such restriction for the Tool. > Therefore, what should agents do when they get RTP CNAMEs or TOOLs that > are not representable as DisplayStrings? > [Bill Strahm responds] You are correct. Changed from DisplayString to OCTET > STRING For UTF-8 strings, you should either import the Utf8String TC from RFC 2287, or the SnmpAdminString TC from RFC 2271. See RFC 2561 for an example that imports these to use UTF-8 strings. -Dave From rem-conf Sat May 01 21:03:21 1999 From rem-conf-request@es.net Sat May 01 21:03:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10dnOs-0006Bu-00; Sat, 1 May 1999 20:58:42 -0700 Received: from dial-52.panamacity.fl.digitalexp.net (B.S.U.I. Ltd.) [204.49.43.65] by mail1.es.net with smtp (Exim 1.81 #2) id 10dnOq-0006Be-00; Sat, 1 May 1999 20:58:41 -0700 From: "zamora_imports@hotmail.com" To: Message-Id: <419.436281.95373727zamora_imports@hotmail.com> Subject: DO NOT PAY RETAIL OVER 50% OFF ALL TIME Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sat, 1 May 1999 20:58:41 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Spending $200 a year on gifts, furniture, or decorative home accessories, then you need this package. BSUI is an inport distribution company with 23 years of experience in bringing the best quality to its customers. What we are presenting to you is the capability to purchase product at wholesale prices. what does the term wholesale mean to you? Actual wholesale is what the product cost the store. The average markup a store places on its products is between 100% and 200%. For example EX-1 our price = $25 store markup = $25-$50 store price = $50-$75 savings = $25-$50 EX-2 our price = $50 store markup = $50-$100 store price = $100-$150 savings = $50-$100 BSUI product line consit of more than 1000 different pieces to choose from, coupled with an ever-changing seasonal gift line, for all major holidays. In addition many of our products you may never find in stores. BSUI's product line consists of: Furniture Decorative home accessories Lamps Mirrors Rugs Gifts These are only a portion of the products avelable to you. The prices of our products range from $15 to $500, remeber you add 100% to 200% to get the same products in a store. The company does have a $30 membership fee that will be more than compensated for in the savings you will receive. After receiving our product line info, if you are not totally satisfied E-mail us with your account number and your membership fee will be immediatly refunded. To order: We accept Visa, MasterCard, American Express, and Discover You may E-mail your order, or fax it to (850)230-1969 or if you prefer simply mail it in to us; BSUI,inc 11483 Front beach rd. tower 1 suite 912 Panama City Beach, FL 32407 please give us; name address phone THANK YOU FOR YOUR TIME. From rem-conf Sun May 02 18:35:07 1999 From rem-conf-request@es.net Sun May 02 18:35:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10e7Uh-0005x1-00; Sun, 2 May 1999 18:26:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10e7Ug-0005wr-00; Sun, 2 May 1999 18:26:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sun May 2 21:25:08 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.218]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA08662; Sun, 2 May 1999 21:25:06 -0400 (EDT) Message-ID: <372CFAFB.8006413E@dnrc.bell-labs.com> Date: Sun, 02 May 1999 21:25:15 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Anders Klemets (Exchange)" CC: rem-conf@es.net Subject: Re: Usage of SDP with FEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Anders Klemets (Exchange) wrote: > > > m=audio 44 RTP/AVP 0 34 > > a=rtpmap:34 parityfec > > c=IN IP4 123.3.4.5 > > c=IN IP4 123.4.4.4 > > a=fec:2 1 > > > > This indicates there are two unicast addresses. The FEC is protecting > > the audio on the second port (123.4.4.4), and the FEC itself comes on > > 123.3.4.5. > > The problem with the above example is that it may break clients that do not > know about the "a=fec" attribute. Such clients will not know which unicast > address carries the audio. The "fec" attribute establishes a mapping > between the payload type and the unicast address, so without it, clients are > left guessing. Clients that don't know about the fec attribute will listen on 123.3.4.5, and see payload type 34, which they don't understand (since its mapped to a type, parityfec, they don't undersand). Thus, they will ignore these packets. A smart implementation might stop listening on this address after a while. Perhaps, as an alternative, we could make the FEC address information part of the fmtp parameter: m=audio 44 RTP/AVP 0 34 a=rtpmap:34 parityfec c=IN IP4 123.4.4.4 a=fmtp:34 123.3.4.5 45 1 The fmtp parameter has the semantics: a=fmtp:
/[] This way, if the recipient doesn't understand parity, it won't ever even see the FEC address and port (123.3.4.5, port 45). This would also allow us to have a separate group and port for the FEC. When used with hierarchical video coders, the FEC would be protecting whichever layer is in the field. I think this is better than my original proposal. Comments? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon May 03 06:05:52 1999 From rem-conf-request@es.net Mon May 03 06:05:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eIHQ-0002WR-00; Mon, 3 May 1999 05:57:04 -0700 Received: from oak.fernuni-hagen.de [132.176.114.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eIHO-0002Ve-00; Mon, 3 May 1999 05:57:03 -0700 Received: from mail.ftk.de (actually guard.ftk.de) by oak.fernuni-hagen.de via local-channel with ESMTP; Mon, 3 May 1999 14:56:11 +0200 Received: from FTK1/SpoolDir by mail.ftk.de (Mercury 1.21); 3 May 99 14:55:01 +0100 Received: from SpoolDir by FTK1 (Mercury 1.21); 3 May 99 14:54:40 +0100 Received: from Landoja.ftk.de by mail.ftk.de (Mercury 1.21); 3 May 99 14:54:38 +0100 From: Thomas Paleschke To: Donations Date: Mon, 3 May 1999 15:00:16 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: They need Your help! CC: rem-conf@es.net Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Message-ID: <64C7FB5CA5@mail.ftk.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Who are you?????? It seems like a confidence trick..... From: Donations To: rem-conf@es.net Subject: They need Your help! Date sent: Fri, 30 Apr 1999 05:20:05 -0700 > Dear Sir/Madam ! > > The Crisis in Kosovo is dramatically turning for the worse. > Kosovar's Albanian's were subjected to ethnic cleansing and > systematic expulsion from their territory and now more than 600 000 of the > peaceful inhabitants are forced to search for shelters in the amicable > countries. Many of them, first of all children and women, are starving and > go through diseases, but humanitarian program of the countries of NATO > can't help all requiring. > > If you sympathizing these deeply unhappy people, who are not guilty in the > circumstances and if you have a possibility, please provide whatever > support you are able. > > We appeal for aid to all who are not indifferent to the fate of > unfortunate children. > > Please, help this people. > They need your friendly hand, as never before! > > PLease, visit our site: http://Help-kosovo.com > > > Any amount of financial aid (the account is written below) would help > destitute people to survive. > > 71617 HELP > Federal Bank of Middle East > Cyprus off shore > Banking Unit P.O.BOX 3498, > 3303, Limassol, Cyprus > > God Bless you. > > > _______________________________________________ Dipl.-Ing. Thomas Paleschke FTK - Forschungsinstitut fuer Telekommunikation Martin-Schmeisser-Weg 4 D-44207 Dortmund Tel.: 0231/ 975056-58 Fax: 0231/ 975056-10 Email: Thomas.Paleschke@FernUni-Hagen.de HTTP://www.media.nrw.de _______________________________________________ FernUniversitaet Hagen Department for Communication Systems Feithstr. 142 D-58084 Hagen Tel.: +49 2331/ 987 4796 Fax: +49 2331/ 987 397 Email: Thomas.Paleschke@FernUni-Hagen.de http://ks.fernuni-hagen.de _______________________________________________ From rem-conf Mon May 03 12:20:30 1999 From rem-conf-request@es.net Mon May 03 12:20:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eOB4-0006hp-00; Mon, 3 May 1999 12:14:54 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eOB1-0006hO-00; Mon, 3 May 1999 12:14:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01504; Mon, 3 May 1999 15:13:48 -0400 (EDT) Message-Id: <199905031913.PAA01504@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtpsample-03.txt Date: Mon, 03 May 1999 15:13:44 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sampling of the Group Membership in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-03.txt Pages : 10 Date : 30-Apr-99 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. NOTE: This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the binning algorithm which is a part of the specification. This declaration is being made pursuant to the provisions of IETF IPR Policy , Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtpsample-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990503121110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990503121110.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon May 03 13:06:10 1999 From rem-conf-request@es.net Mon May 03 13:06:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eOwy-0007je-00; Mon, 3 May 1999 13:04:24 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eOwr-0007iZ-00; Mon, 3 May 1999 13:04:17 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id QAA01255; Mon, 3 May 1999 16:37:22 -0300 (EST) Date: Mon, 3 May 1999 16:37:22 -0300 (EST) From: "LANOMS'99" Message-Id: <199905031937.QAA01255@lrg.ufsc.br> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, commsoft@cc.bellcore.com, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, enternet@BBN.COM, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, kia@usl.edu, multicomm@cc.bellcore.com, osimcast@BBN.COM, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@IEEE.ORG, xtp-relay@cs.concordia.ca, ekpark@cstp.umkc.edu, westphal@lrg.ufsc.br Subject: Re: IEEE LANOMS99 - Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: 3EfRjqdaToAGZ3gmNUgyQw== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. "NETWORK MANAGEMENT FOR THE NEW WORLD" Call for Papers The First Latin American Network Operations and Management Symposium - LANOMS, to be held in Rio de Janeiro on the turn of the millennium is the result of the great success of the events in the area of network management known as NOMS and APNOMS. NOMS (Network Operations and Management Symposium) was originally created ten years ago in New Orleans, USA, and nowadays constitutes a worldwide event for the researches in the area of network management. Recently, the Asia/Pacific community promoted the APNOMS (Asia-Pacific Network Operations and Management Symposium), which is an event more oriented to the research and development community in that continent. Within this context, we will promote the first LANOMS (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the GLOBECOM. In the last few years, we have been witnessing an increasing demand on topics associated with Network Management in national and international events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay. As a consequence, we observed in Latin America a solid necessity of a specific event where there might be room to debate the main issues=20 involving the area of Network Management. For obvious reasons, the organization of LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies, academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific event on network management in Latin America in order to divulge the researches currently developed; * to identify the problems and solutions specific to the area of network management; * to make viable the solutions proposed by the international community to Latin America and vice-versa; and * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed 12 pages. Electronic submission of papers is strongly encouraged. Full instructions for the electronic submissions is available on the LANOMS web page. Important Dates: Paper due: May 06, 1999=20 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management =20 + TMN Technology + Web-Based Management Committee Members --------- ------- General and TCP Chair: Carlos Becker Westphall, Brazil TPC Co-Chairs: Luiz Fernando Kormann, Brazil Mirela Sechi Moretti Annoni Notare, Brazil Publication Chair: Bernardo Goncalves Riso, Brazil Publicity Chair: Juan Carlos Miguez, Uruguay Finance Chair: Fernando Augusto da Silva Cruz, Brazil Joao Bosco Mangueira Sobral, Brazil =20 Local Arrangements Chair: Michael Stanton, Brazil IEEE CNOM Chair: Veli Sahin, USA International Liasions: Africa: J. Roos, South Africa Asia: J. Hong, Korea Europe: E. Bagnasco, Italy N. America: S. Aidarous, USA Oceania: P. Ray, Australia Advisory Board: B. Meandzijas, USA D. Zuckerman, USA M. Ejiri, Japan M. Yoshida, Japan R. Saracco, Italy S. Goyal, USA V. Sahin, USA =20 W. Zimmer, Germany Technical Program Committee Adarsh Sethi (USA) Alan Mckinlay (UK) Alejandro Miralles (Chile) Behcet Sarikaya (Japan) Carlos de Lara (Mexico) Carlos E. Caicedo (Colombia) Edward Pinnes (USA) Edmundo R. Madeira (Brazil) Elias Procopio Duarte Junior (Brazil) Gabriel Jakobson (USA) German Goldszmidt (USA) Guy Pujolle (France) Heinz-Gerd Hegering (Germany) Joberto S. Barbosa Martins (Brazil) Jong-Tae Park (Korea) Jose Marcos Nogueira (Brazil) Jose Neuman de Souza (Brazil) Keith-Stuart von Mecklenburg (UK) Leonor W. Chaux (Colombia) =20 Manu Malek (USA) Manoel C. Penna (Brazil) Michael Bauer (Canada) Michele Sibilla (France) Nelson Fonseca (Brazil) Osvaldo Bianchi (Argentina) Paulo Gomide Cohn (Brazil) Raul Monge (Chile) Robert Weihmayer (USA) Roberto Vercelli (Italy) Seraphin Calo (USA) Varoozh Harikian (Belgium) This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC =20 Network and Management Laboratory - LRG P.O.Box 476 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon May 03 13:10:10 1999 From rem-conf-request@es.net Mon May 03 13:10:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eP2C-00009I-00; Mon, 3 May 1999 13:09:48 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eP23-00007g-00; Mon, 3 May 1999 13:09:44 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id QAA01353; Mon, 3 May 1999 16:45:00 -0300 (EST) Date: Mon, 3 May 1999 16:45:00 -0300 (EST) From: "LANOMS'99" Message-Id: <199905031945.QAA01353@lrg.ufsc.br> To: Omar.Elloumi@enst-bretagne.fr, wwlu@ieee.org Subject: IEEE LANOMS99 - LAST CFP Cc: bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@BBN.COM, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@BBN.COM, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: 3EfRjqdaToAGZ3gmNUgyQw== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. "NETWORK MANAGEMENT FOR THE NEW WORLD" Call for Papers The First Latin American Network Operations and Management Symposium - LANOMS, to be held in Rio de Janeiro on the turn of the millennium is the result of the great success of the events in the area of network management known as NOMS and APNOMS. NOMS (Network Operations and Management Symposium) was originally created ten years ago in New Orleans, USA, and nowadays constitutes a worldwide event for the researches in the area of network management. Recently, the Asia/Pacific community promoted the APNOMS (Asia-Pacific Network Operations and Management Symposium), which is an event more oriented to the research and development community in that continent. Within this context, we will promote the first LANOMS (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the GLOBECOM. In the last few years, we have been witnessing an increasing demand on topics associated with Network Management in national and international events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay. As a consequence, we observed in Latin America a solid necessity of a specific event where there might be room to debate the main issues=20 involving the area of Network Management. For obvious reasons, the organization of LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies, academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific event on network management in Latin America in order to divulge the researches currently developed; * to identify the problems and solutions specific to the area of network management; * to make viable the solutions proposed by the international community to Latin America and vice-versa; and * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed 12 pages. Electronic submission of papers is strongly encouraged. Full instructions for the electronic submissions is available on the LANOMS web page. Important Dates: Paper due: May 06, 1999=20 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management =20 + TMN Technology + Web-Based Management Committee Members --------- ------- General and TCP Chair: Carlos Becker Westphall, Brazil TPC Co-Chairs: Luiz Fernando Kormann, Brazil Mirela Sechi Moretti Annoni Notare, Brazil Publication Chair: Bernardo Goncalves Riso, Brazil Publicity Chair: Juan Carlos Miguez, Uruguay Finance Chair: Fernando Augusto da Silva Cruz, Brazil Joao Bosco Mangueira Sobral, Brazil =20 Local Arrangements Chair: Michael Stanton, Brazil IEEE CNOM Chair: Veli Sahin, USA International Liasions: Africa: J. Roos, South Africa Asia: J. Hong, Korea Europe: E. Bagnasco, Italy N. America: S. Aidarous, USA Oceania: P. Ray, Australia Advisory Board: B. Meandzijas, USA D. Zuckerman, USA M. Ejiri, Japan M. Yoshida, Japan R. Saracco, Italy S. Goyal, USA V. Sahin, USA =20 W. Zimmer, Germany Technical Program Committee Adarsh Sethi (USA) Alan Mckinlay (UK) Alejandro Miralles (Chile) Behcet Sarikaya (Japan) Carlos de Lara (Mexico) Carlos E. Caicedo (Colombia) Edward Pinnes (USA) Edmundo R. Madeira (Brazil) Elias Procopio Duarte Junior (Brazil) Gabriel Jakobson (USA) German Goldszmidt (USA) Guy Pujolle (France) Heinz-Gerd Hegering (Germany) Joberto S. Barbosa Martins (Brazil) Jong-Tae Park (Korea) Jose Marcos Nogueira (Brazil) Jose Neuman de Souza (Brazil) Keith-Stuart von Mecklenburg (UK) Leonor W. Chaux (Colombia) =20 Manu Malek (USA) Manoel C. Penna (Brazil) Michael Bauer (Canada) Michele Sibilla (France) Nelson Fonseca (Brazil) Osvaldo Bianchi (Argentina) Paulo Gomide Cohn (Brazil) Raul Monge (Chile) Robert Weihmayer (USA) Roberto Vercelli (Italy) Seraphin Calo (USA) Varoozh Harikian (Belgium) This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC =20 Network and Management Laboratory - LRG P.O.Box 476 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon May 03 13:18:19 1999 From rem-conf-request@es.net Mon May 03 13:18:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eP9O-0000oW-00; Mon, 3 May 1999 13:17:14 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eP9G-0000lm-00; Mon, 3 May 1999 13:17:10 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id QAA00958; Mon, 3 May 1999 16:13:55 -0300 (EST) Date: Mon, 3 May 1999 16:13:55 -0300 (EST) From: "LANOMS'99" Message-Id: <199905031913.QAA00958@lrg.ufsc.br> To: lyko@kt.agh.edu.pl, activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@d Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list tc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, christ@rus.uni-stuttgart.de Subject: IEEE LANOMS99 - LAST CFP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: 3EfRjqdaToAGZ3gmNUgyQw== *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. "NETWORK MANAGEMENT FOR THE NEW WORLD" Call for Papers The First Latin American Network Operations and Management Symposium - LANOMS, to be held in Rio de Janeiro on the turn of the millennium is the result of the great success of the events in the area of network management known as NOMS and APNOMS. NOMS (Network Operations and Management Symposium) was originally created ten years ago in New Orleans, USA, and nowadays constitutes a worldwide event for the researches in the area of network management. Recently, the Asia/Pacific community promoted the APNOMS (Asia-Pacific Network Operations and Management Symposium), which is an event more oriented to the research and development community in that continent. Within this context, we will promote the first LANOMS (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the GLOBECOM. In the last few years, we have been witnessing an increasing demand on topics associated with Network Management in national and international events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay. As a consequence, we observed in Latin America a solid necessity of a specific event where there might be room to debate the main issues=20 involving the area of Network Management. For obvious reasons, the organization of LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies, academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific event on network management in Latin America in order to divulge the researches currently developed; * to identify the problems and solutions specific to the area of network management; * to make viable the solutions proposed by the international community to Latin America and vice-versa; and * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed 12 pages. Electronic submission of papers is strongly encouraged. Full instructions for the electronic submissions is available on the LANOMS web page. Important Dates: Paper due: May 06, 1999=20 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management =20 + TMN Technology + Web-Based Management Committee Members --------- ------- General and TCP Chair: Carlos Becker Westphall, Brazil TPC Co-Chairs: Luiz Fernando Kormann, Brazil Mirela Sechi Moretti Annoni Notare, Brazil Publication Chair: Bernardo Goncalves Riso, Brazil Publicity Chair: Juan Carlos Miguez, Uruguay Finance Chair: Fernando Augusto da Silva Cruz, Brazil Joao Bosco Mangueira Sobral, Brazil =20 Local Arrangements Chair: Michael Stanton, Brazil IEEE CNOM Chair: Veli Sahin, USA International Liasions: Africa: J. Roos, South Africa Asia: J. Hong, Korea Europe: E. Bagnasco, Italy N. America: S. Aidarous, USA Oceania: P. Ray, Australia Advisory Board: B. Meandzijas, USA D. Zuckerman, USA M. Ejiri, Japan M. Yoshida, Japan R. Saracco, Italy S. Goyal, USA V. Sahin, USA =20 W. Zimmer, Germany Technical Program Committee Adarsh Sethi (USA) Alan Mckinlay (UK) Alejandro Miralles (Chile) Behcet Sarikaya (Japan) Carlos de Lara (Mexico) Carlos E. Caicedo (Colombia) Edward Pinnes (USA) Edmundo R. Madeira (Brazil) Elias Procopio Duarte Junior (Brazil) Gabriel Jakobson (USA) German Goldszmidt (USA) Guy Pujolle (France) Heinz-Gerd Hegering (Germany) Joberto S. Barbosa Martins (Brazil) Jong-Tae Park (Korea) Jose Marcos Nogueira (Brazil) Jose Neuman de Souza (Brazil) Keith-Stuart von Mecklenburg (UK) Leonor W. Chaux (Colombia) =20 Manu Malek (USA) Manoel C. Penna (Brazil) Michael Bauer (Canada) Michele Sibilla (France) Nelson Fonseca (Brazil) Osvaldo Bianchi (Argentina) Paulo Gomide Cohn (Brazil) Raul Monge (Chile) Robert Weihmayer (USA) Roberto Vercelli (Italy) Seraphin Calo (USA) Varoozh Harikian (Belgium) This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC =20 Network and Management Laboratory - LRG P.O.Box 476 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon May 03 15:19:32 1999 From rem-conf-request@es.net Mon May 03 15:19:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eR0i-0003Ig-00; Mon, 3 May 1999 15:16:24 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eR0h-0003IW-00; Mon, 3 May 1999 15:16:23 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id PAA42848 for ; Mon, 3 May 1999 15:12:14 -0700 Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Mon, 03 May 1999 15:12:13 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id PAA15230; Mon, 3 May 1999 15:12:11 -0700 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <93496446F5EDD211A8C100805FEAD74901911F@nsrip00207.mcit.com> Date: Mon, 3 May 1999 15:09:10 -0700 To: rem-conf@es.net From: Dave Singer Subject: SAP for MAC fyi Cc: confctrl@isi.edu Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've heard recently of "Silly SAP Client" for the Mac, and it now has a web page. Anyone needing to gather SDP announcements on Macintosh can download this program. The web site for MacOS Binary is at: http://macinfo.its.queensu.ca/MBONE/SillySAPClient.html David Singer Apple Computer/QuickTime From rem-conf Mon May 03 15:30:13 1999 From rem-conf-request@es.net Mon May 03 15:30:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eRCg-0003oZ-00; Mon, 3 May 1999 15:28:46 -0700 Received: from law2-f25.hotmail.com (hotmail.com) [216.32.181.25] by mail1.es.net with smtp (Exim 1.81 #2) id 10eRCf-0003mS-00; Mon, 3 May 1999 15:28:45 -0700 Received: (qmail 5646 invoked by uid 0); 3 May 1999 22:27:44 -0000 Message-ID: <19990503222744.5645.qmail@hotmail.com> Received: from 208.211.99.1 by www.hotmail.com with HTTP; Mon, 03 May 1999 15:27:44 PDT X-Originating-IP: [208.211.99.1] From: "Neal Schneider" To: schulzrinne@cs.columbia.edu, rem-conf@es.net Cc: xiaotaow@cs.columbia.edu, almeroth@cs.ucsb.edu Subject: Re: rtptools 1.12 Date: Mon, 03 May 1999 15:27:44 PDT Mime-Version: 1.0 Content-type: text/plain; format=flowed; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Xiaotao Wu, one of my students, has packaged a new version of the >rtptools that now compiles more readily on Windows 95/NT. You can find >the tools at http://www.cs.columbia.edu/~hgs/rtptools. Comments and >suggestions are appreciated. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > The FTP site for sources and binaries can not be accessed by an anonymous user. ftp://ftp.cs.columbia.edu/pub/schulzrinne/rtptools Could you possibly set up a public account, or make them downloadable directly from your site? Regards, Neal _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From rem-conf Mon May 03 16:04:36 1999 From rem-conf-request@es.net Mon May 03 16:04:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eRja-0005CG-00; Mon, 3 May 1999 16:02:46 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eRjT-0005Bo-00; Mon, 3 May 1999 16:02:41 -0700 Received: (from westphal@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id RAA02080; Mon, 3 May 1999 17:40:40 -0300 (EST) Date: Mon, 3 May 1999 17:40:40 -0300 (EST) From: "Prof. Carlos B. Westphall" Message-Id: <199905032040.RAA02080@lrg.ufsc.br> To: ac@enci.ucalgary.ca, achille@elet.polimi.it, activenets_all@ittc.ukansas.edu, andj@pact.srf.ac.uk, apc@eee.nthu.edu.tw, apclarke@usa.net, are.magnus.bruaset@si.sintef.na, arpanet-bboard@mc.lcs.mit.edu, atkinson@ucsd.edu, B.Marchent@fujitsu.co.uk, beadle@elec.uow.edu.au, Bharat.Patel@telematics.com, bmerriman@fusion.ucsd.edu, bmunro@agile.com, bob@boulderlabs.com, bparks@wuecona.wustl.edu, buford@cs.uml.edu, c.langreiter@tirol.com, cabernet-events@ncl.ac.uk, canning@cs.uml.edu, Carl.McCrosky@USask.CA, cell-relay@cell.onecall.net, chkoo@daisy.kwangwoon.ac.kr, cif@injector.ca.sandia.gov, claes@math.chalmers.se, claudio@dial.eunet.ch, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.a, cplus.guide@miningco.com, cssamuel@cphkvx.cphk.hk, D.D.Kouvatsos@comp.brad.ac.uk, D.J.Parish@lboro.ac.uk, dama@dist.unige.it, dancey@isomedia.com, davidc@davidc.com, dbword@cs.wisc.edu, dik_kalluri@uml.edu, dittmer@capital.net, dkamil@zd.com, ego@iis.nsk.su, elsa@econ.berkeley.edu, emmpdl@aaem.amc.anl.gov, end2end-interest@isi.edu, enternet@bbn.com, erahmmm@era-t.ericsson.se, erol@ee.duke.edu, feedback@techweb.com, FI51@vmxa.fz.telekom.de, flr@seiv10.rpi.ses.alcatel.es, fokus-users@fokus.gmd.de, fotios@vergina.eng.auth.gr, fransp@eos.cs.kun.nl, fred@langa.com, f-troup@codex.cis.upenn.edu, Gerry.Miles@telematics.com, gk@sics.se, gkonst@ektor.telecom.ece.ntua.gr, gli@metal.chpc.ict.ac.cn, gmayor@pollux.usc.edu, gmyk@ektor.telecom.ece.ntua.gr, grieblm@inforamp.net, g-troup@ccrc.wustl.edu, gus@bourg.net, habreu@bellsouth.net, hanoch@rutcor.rutgers.edu, hessa@acf4.nyu.edu, hipparch@sophia.inria.fr, hleitold@iaik.tu-graz.ac.at, hslee@nms.kyunghee.ac.kr, httpd@ncsa.uiuc.edu, I.M.MacPhee@durham.ac.uk, ieee.announce@bellcore.com, ieeetcpc@ccvm.sunysb.edu, ioannis@sce.carleton.ca, isi.mitrani@ncl.ac.uk, itc@attrh1.attrh.att.com, itrac@itrac.bourg.net, J.E.Mellor@durham.ac.uk, j.w.parker@bnr.co.uk, jay_weitzen@uml.edu, jekon@sunrise.pg.gda.pl, jem@sunsite.unc.edu, jes@lrg.ufsc.br Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list er@newton.mli.kvl.dk, jgobat@ucsd.edu, Jiang.Shengming@prism.uvsq.fr, jiann@newton.ccs.tuns.ca, jmsmith@ecs.umass.edu, johan@tts.lth.se, John.Kroeze@cs.kun.nl, John.Meyer@italtel.it, johnecarter@mindspring.com, jomah@cs.bris.ac.uk, jou@mcnc.org, jpearce@dcs.rhbnc.ac.uk, jraynard@freebsd.org, jwmark@bbcr.waterloo.edu, kapoor_v@motsat.sat.mot.com, kavid@telecom.ntua.gr, Kavitha_Chandra@uml.edu, kb7uzn@ida.net, kim@cs.uml.edu, kim@trillium.com, kl@lci.rug.ac.be, kofman@inf.enst.fr, kohlen@etna.int-evry.fr, korez@inf.enst.fr, kosberg@delab.sintef.no, koubias@ee.upatras.gr, koukias@wcl.ee.upatras.gr, kuehn@nvdv.e-technik.uni-stuttgart.dbp.de, kurose@cs.umass.edu, Kyamakya.Kyandoghere@FernUni-Hagen.de, lampe@math.tu-dresden.de, langford@cte.acu.edu, laws@stats.ox.ac.uk, leboudec@di.epfl.ch, Leila.Kloul@prism.uvsq.fr, levendov@hit.bme.hu, Lewis@stp.dias.ie, lmurphy@eng.auburn.edu, lobejko_@cc.wil.waw.pl, locigno@polito.it, lpa@log.on.ca, M.Merabti@livjm.ac.uk, macfadrn@boat.bt.com, m! achy@ix.netcom.com, maja.matijasevic@etf.hr, mal@qnx.com, marketing@trillium.co, marvin@mail.microserve.net, mary_bradburne@kvo.com, marzo@songoku.udg.es, mascolo@poliba.it, medoe@essex.ac.uk, mellia@polito.it, mfc-mlorenz@visionx.com, Michael_Fiddy@uml.edu, michael_moeller@zd.com, miklos@ttt-atm.ttt.bme.hu, mitrou@ektor.telecom.ece.ntua.gr, mlee@e0sun3.ccl.itri.org.tw, m-logo@wcl.ee.upatras.gr, mobile-ip@tadpole.com, moessenboeck@ssw.uni-linz.ac.at, mourad@scs.leeds.ac.uk, mst@amc-hln.com, multicomm@cc.bellcore.com, munafo@polito.it, muppala@cs.ust.hk, murphyj@eeng.dcu.ie, mustildp@boat.bt.com, N.Linge@eee.salford.ac.uk, naudts@uia.ua.ac.be, Nihal.Pekergin@prism.uvsq.fr, nilsson@eceyv.ncsu.edu, noconnell@stats.tcd.ie, olivier@smartcodesoft.com, osimcast@bbn.com, owner-tccc@majordomo.ieee.org, P.Jones@ee.surrey.ac.uk, Paglino@ilt9h23.settimo.italtel.it, pancha@ee.upenn.edu, pascua@tid.es, paul@mathserv.math.nccu.edu.tw, pechiar@iie.edu.uy, Pekergin@lipn.univ-paris13.fr, perfor! mance@haven.epm.ornl.gov, Philip.Mars@durham.ac.uk, philippe.schweizer@pcm.bosch.de, pironneau@ann.jussieu.fr, pjbk@cee.hw.ac.uk, pka@itm.hk-r.se, Pravin.K.Johri@att.com, prof@gauss.wis.kuleuven.ac.be, prudhomm@ann.jussieu.fr, Q.Li@leeds.ac.uk, qli@cs.ucl.ac.uk, raif_onvural@alliedtelesyn.com, raschid@informatik.rwth-aachen.de, ravet@seua.am, rem-conf@es.net, reres@laas.fr, risingsun@msn.com, rnelson@watson.ibm.com, roitzsch@zib-berlin.de, Ross_Holmstrom@uml.edu, rvissers@voyager.net, S.Murphy@teltec.dcu.ie, sanjay@buckaroo.ho.att.com, shd@earthling.net, sigcomm-members@acm.org, sigmedia@bellcore.com, sigmetrics-bb@haven.epm.ornl.gov, simsuz@turing.utoronto.ca, SKKong@aol.com, skulski@nsrl.rochester.edu, sslaven@watson.ibm.com, stefan.wils@zorro.ruca.ua.ac.be, steve@nickel.laurentian.ca, stu@cs.uml.edu, support@tmt.com, sveo@itm.hk-r.se, T.Ors@ee.surrey.ac.uk, tap@ws7u.com, tccc@ieee.org, tcgn@ieee.org, tjp@dmu.ac.uk, ug@ica3.uni-stuttgart.de, ulfk@tts.lu.se, vfn@cs.utwente.nl! , w3@unipress.com, wamckee@msn.com, wash@lambic.cfg.cornell.edu, wbmaster@psti.com, webmaster@ch.engr.ucdavis.edu, webmaster@planet-source-code.com, webmaster@spinweb.net, webmaster@streamsoft.com, webmasters@spinweb.net, werner@mosaic.co.za, woltman@magicnet.net, wviehmann@compuserve.com, www@astro.cf.ac.uk, xhafer@orion.eee.kcl.ac.uk, xiaowen@buckaroo.ho.att.com, xtp-relay@cs.concordia.ca, yakov@buckaroo.ho.att.com, ylevy@att.com, yodamon@aol.com, z.mihretu@statistics.bbk.ac.uk, Zhen.Liu@sophia.inria.fr, fhuebner@att.com Subject: IEEE LANOMS99 - LAST CFP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: 2E4hJPKAoZV3Q4HeU/yKAw== *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. "NETWORK MANAGEMENT FOR THE NEW WORLD" Call for Papers The First Latin American Network Operations and Management Symposium - LANOMS, to be held in Rio de Janeiro on the turn of the millennium is the result of the great success of the events in the area of network management known as NOMS and APNOMS. NOMS (Network Operations and Management Symposium) was originally created ten years ago in New Orleans, USA, and nowadays constitutes a worldwide event for the researches in the area of network management. Recently, the Asia/Pacific community promoted the APNOMS (Asia-Pacific Network Operations and Management Symposium), which is an event more oriented to the research and development community in that continent. Within this context, we will promote the first LANOMS (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the GLOBECOM. In the last few years, we have been witnessing an increasing demand on topics associated with Network Management in national and international events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay. As a consequence, we observed in Latin America a solid necessity of a specific event where there might be room to debate the main issues=20 involving the area of Network Management. For obvious reasons, the organization of LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies, academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific event on network management in Latin America in order to divulge the researches currently developed; * to identify the problems and solutions specific to the area of network management; * to make viable the solutions proposed by the international community to Latin America and vice-versa; and * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed 12 pages. Electronic submission of papers is strongly encouraged. Full instructions for the electronic submissions is available on the LANOMS web page. Important Dates: Paper due: May 06, 1999=20 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management =20 + TMN Technology + Web-Based Management Committee Members --------- ------- General and TCP Chair: Carlos Becker Westphall, Brazil TPC Co-Chairs: Luiz Fernando Kormann, Brazil Mirela Sechi Moretti Annoni Notare, Brazil Publication Chair: Bernardo Goncalves Riso, Brazil Publicity Chair: Juan Carlos Miguez, Uruguay Finance Chair: Fernando Augusto da Silva Cruz, Brazil Joao Bosco Mangueira Sobral, Brazil =20 Local Arrangements Chair: Michael Stanton, Brazil IEEE CNOM Chair: Veli Sahin, USA International Liasions: Africa: J. Roos, South Africa Asia: J. Hong, Korea Europe: E. Bagnasco, Italy N. America: S. Aidarous, USA Oceania: P. Ray, Australia Advisory Board: B. Meandzijas, USA D. Zuckerman, USA M. Ejiri, Japan M. Yoshida, Japan R. Saracco, Italy S. Goyal, USA V. Sahin, USA =20 W. Zimmer, Germany Technical Program Committee Adarsh Sethi (USA) Alan Mckinlay (UK) Alejandro Miralles (Chile) Behcet Sarikaya (Japan) Carlos de Lara (Mexico) Carlos E. Caicedo (Colombia) Edward Pinnes (USA) Edmundo R. Madeira (Brazil) Elias Procopio Duarte Junior (Brazil) Gabriel Jakobson (USA) German Goldszmidt (USA) Guy Pujolle (France) Heinz-Gerd Hegering (Germany) Joberto S. Barbosa Martins (Brazil) Jong-Tae Park (Korea) Jose Marcos Nogueira (Brazil) Jose Neuman de Souza (Brazil) Keith-Stuart von Mecklenburg (UK) Leonor W. Chaux (Colombia) =20 Manu Malek (USA) Manoel C. Penna (Brazil) Michael Bauer (Canada) Michele Sibilla (France) Nelson Fonseca (Brazil) Osvaldo Bianchi (Argentina) Paulo Gomide Cohn (Brazil) Raul Monge (Chile) Robert Weihmayer (USA) Roberto Vercelli (Italy) Seraphin Calo (USA) Varoozh Harikian (Belgium) This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC =20 Network and Management Laboratory - LRG P.O.Box 476 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon May 03 22:56:05 1999 From rem-conf-request@es.net Mon May 03 22:56:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eY3M-0001JG-00; Mon, 3 May 1999 22:47:36 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10eY3K-0001I9-00; Mon, 3 May 1999 22:47:35 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.3/8.9.3) with ESMTP id OAA17786 for ; Tue, 4 May 1999 14:47:32 +0900 (JST) Message-Id: <199905040547.OAA17786@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: rtptools 1.12 In-reply-to: Your message of "Mon, 03 May 1999 15:27:44 ." <19990503222744.5645.qmail@hotmail.com> Date: Tue, 04 May 1999 14:47:31 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > The FTP site for sources and binaries can not be accessed by an anonymous > user. > ftp://ftp.cs.columbia.edu/pub/schulzrinne/rtptools > > Could you possibly set up a public account, or make them downloadable > directly from your site? I can access the site from japan, downloaded the sources. I suppose there was a problem between your site and columbia. if you cannot connect ftp.cs.columbia.edu, try . -- yozo. From rem-conf Mon May 03 23:18:01 1999 From rem-conf-request@es.net Mon May 03 23:18:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eYW6-0002Q4-00; Mon, 3 May 1999 23:17:18 -0700 Received: from dns2.nec.com (dns3.nec.com) [131.241.15.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eYW5-0002Op-00; Mon, 3 May 1999 23:17:17 -0700 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by dns3.nec.com (ready at/) with ESMTP id XAA16019; Mon, 3 May 1999 23:16:15 -0700 (PDT) Received: from necccrl-pn.ccrl.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id XAA11879; Mon, 3 May 1999 23:14:18 -0700 (PDT) Received: (from smtp@localhost) by necccrl-pn.ccrl.sj.nec.com (8.8.5/8.7.3) id WAA06269; Mon, 3 May 1999 22:56:33 -0700 (PDT) Received: from ccrl.sj.nec.com (monet.ccrl.sj.nec.com [131.241.79.5]) by necccrl-pn.ccrl.sj.nec.com id rfWAA06262; Mon May 3 22:56:22 1999 X-Spoof-Warning: ccrl.sj.nec.com [131.241.79.5] does not match with monet.ccrl.sj.nec.com [131.241.79.5] Received: from localhost by ccrl.sj.nec.com (SMI-8.6/SMI-SVR4) id XAA16551; Mon, 3 May 1999 23:15:33 -0700 Date: Mon, 3 May 1999 23:15:33 -0700 (PDT) From: Jeffrey Lo To: Yozo Toda cc: rem-conf@es.net Subject: Re: rtptools 1.12 In-Reply-To: <199905040547.OAA17786@aohakobe.ipc.chiba-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hey Hendrick, isn't it some kind of buffer dinner where everyone can get to chat?!! Correct me if I am wrong. I got one more offer from Network Computers! But you guys seems not to favor the company. They say they are going public soon, sometimes next year. I am not sure whether that's true, is there anyway to find out? I heard from a friend that when a company is going public, they will keep quite. If they are not going public, then they boast about it. Is that true? If this is the case, then I better not join NC... They say their share is only 1 buck now! If they should ever go public, I would make big bucks. But again, why $1? I remember when MMC was going public, it was $6++... Advice? ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 On Tue, 4 May 1999, Yozo Toda wrote: > > > The FTP site for sources and binaries can not be accessed by an anonymous > > user. > > ftp://ftp.cs.columbia.edu/pub/schulzrinne/rtptools > > > > Could you possibly set up a public account, or make them downloadable > > directly from your site? > > I can access the site from japan, downloaded the sources. > I suppose there was a problem between your site and columbia. > > if you cannot connect ftp.cs.columbia.edu, try > . > > -- yozo. > > > From rem-conf Tue May 04 06:21:00 1999 From rem-conf-request@es.net Tue May 04 06:20:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eezq-000708-00; Tue, 4 May 1999 06:12:26 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10eezn-0006zw-00; Tue, 4 May 1999 06:12:23 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 4 May 1999 14:11:53 +0100 To: Jonathan Rosenberg cc: "Anders Klemets (Exchange)" , rem-conf@es.net Subject: Re: Usage of SDP with FEC In-reply-to: Your message of "Sun, 02 May 1999 21:25:15 EDT." <372CFAFB.8006413E@dnrc.bell-labs.com> Date: Tue, 04 May 1999 14:11:53 +0100 Message-ID: <2879.925823513@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: >Anders Klemets (Exchange) wrote: >> >> > m=audio 44 RTP/AVP 0 34 >> > a=rtpmap:34 parityfec >> > c=IN IP4 123.3.4.5 >> > c=IN IP4 123.4.4.4 >> > a=fec:2 1 >> > >> > This indicates there are two unicast addresses. The FEC is protecting >> > the audio on the second port (123.4.4.4), and the FEC itself comes on >> > 123.3.4.5. >> >> The problem with the above example is that it may break clients that do not >> know about the "a=fec" attribute. Such clients will not know which unicast >> address carries the audio. The "fec" attribute establishes a mapping >> between the payload type and the unicast address, so without it, clients are >> left guessing. > >Clients that don't know about the fec attribute will listen on >123.3.4.5, and see payload type 34, which they don't understand (since >its mapped to a type, parityfec, they don't undersand). Thus, they will >ignore these packets. A smart implementation might stop listening on >this address after a while. > >Perhaps, as an alternative, we could make the FEC address information >part of the fmtp parameter: > >m=audio 44 RTP/AVP 0 34 >a=rtpmap:34 parityfec >c=IN IP4 123.4.4.4 >a=fmtp:34 123.3.4.5 45 1 > >The fmtp parameter has the semantics: > >a=fmtp:
/[] > >This way, if the recipient doesn't understand parity, it won't ever even >see the FEC address and port (123.3.4.5, port 45). This would also allow >us to have a separate group and port for the FEC. When used with >hierarchical video coders, the FEC would be protecting whichever layer >is in the field. You'd have to include the full semantics of the "c=" field in the "a=fmtp" attribute, so one could do... m=audio 5000 RTP/AVP 0 34 c=IN IP6 ff15::8 a=rtpmap:34 parityfec a=fmtp:34 IN IP6 ff15::10 5002 1 ...which makes things a little uglier. >I think this is better than my original proposal. Comments? So, to use it with redundancy you'd do: m=audio 5000 RTP/AVP 0 121 122 c=IN IP4 224.1.2.3 a=rtpmap:121 red/8000/1 a=fmtp:121 0 122 a=rtpmap:122 parityfec/8000/1 and omit the "a=fmtp" attribute for the parity FEC, since it's sent as part of the redundant data? Colin From rem-conf Tue May 04 07:24:39 1999 From rem-conf-request@es.net Tue May 04 07:24:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eg3I-0000xx-00; Tue, 4 May 1999 07:20:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10eg3G-0000xd-00; Tue, 4 May 1999 07:20:02 -0700 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue May 4 10:19:30 EDT 1999 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA23801; Tue, 4 May 1999 10:19:30 -0400 (EDT) Message-ID: <372EFEFA.6C7F7C7B@dnrc.bell-labs.com> Date: Tue, 04 May 1999 10:06:50 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: "Anders Klemets (Exchange)" , rem-conf@es.net Subject: Re: Usage of SDP with FEC References: <2879.925823513@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > >The fmtp parameter has the semantics: > > > >a=fmtp:
/[] > > > >This way, if the recipient doesn't understand parity, it won't ever even > >see the FEC address and port (123.3.4.5, port 45). This would also allow > >us to have a separate group and port for the FEC. When used with > >hierarchical video coders, the FEC would be protecting whichever layer > >is in the field. > > You'd have to include the full semantics of the "c=" field in the "a=fmtp" > attribute, so one could do... > > m=audio 5000 RTP/AVP 0 34 > c=IN IP6 ff15::8 > a=rtpmap:34 parityfec > a=fmtp:34 IN IP6 ff15::10 5002 1 > > ...which makes things a little uglier. A little uglier, but probably the most consistent with current SDP usage and semantics. > > >I think this is better than my original proposal. Comments? > > So, to use it with redundancy you'd do: > > m=audio 5000 RTP/AVP 0 121 122 > c=IN IP4 224.1.2.3 > a=rtpmap:121 red/8000/1 > a=fmtp:121 0 122 > a=rtpmap:122 parityfec/8000/1 > > and omit the "a=fmtp" attribute for the parity FEC, since it's sent as part > of the redundant data? Yes. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue May 04 13:41:18 1999 From rem-conf-request@es.net Tue May 04 13:41:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10else-0006EB-00; Tue, 4 May 1999 13:33:28 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 10elsd-0006Dw-00; Tue, 4 May 1999 13:33:27 -0700 Received: from BMRC.Berkeley.EDU (opus.CS.Berkeley.EDU [128.32.131.116]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id NAA24306; Tue, 4 May 1999 13:33:26 -0700 (PDT) Message-ID: <372F5996.8A5B3AD@BMRC.Berkeley.EDU> Date: Tue, 04 May 1999 13:33:26 -0700 From: "Lawrence A. Rowe" Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net CC: Markus Buchhorn Subject: Re: Is there a standard for sending images? References: <3.0.32.19990428095019.00a01e60@acsys.anu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Markus Buchhorn wrote: > > At 20:02 26/04/99 +0200, Peter Parnes wrote: > >Sure, you get a JPEG image. That is why I wrote "real HTML" in the > >paragraph before that. But even if you do create a JPEG image it is > >still only 20-50KB which should be compared to the 100-200 Kbps that > >is normally used for sending out video slides. > > In seminars like the Berkeley Multimedia, which are very > professionally done IMHO, they use two video streams, one for the > speaker and one for the slides. ... The images we produce are taken from a YEM scan converter directly off a PC or from an Elmo camera stand. We have several ideas for improving the quality of the images and program: 1. Adapt the bandwidth used in the presentation stream when there is a change. For the public mbone broadcast, we are constrained to 200 Kbs (i.e., 64 Kbs audio, 100 Kbs video, and 36 Kbs presentation video). But, when there is a slide change, we want to dynamically adjust the presentation video to use more bandwidth. The same is try when someone plays a video tape in the vcr or plays a video on the PC screen. My thought was to detect changes at the capture source and use Elan Amir's SCUBA protocol to adjust the bandwidth dynamically. 2. Improve the digitizing on the images. If you watch carefully, you'll notice that after the slide is displayed, blocks change when there is no change on the screen. It has something to do with the threshholding in the H.261 algorithm and the digitizing. Might just be a bug or it might require a small modification to the coding algorithm. 3. H.261 does a nice job of updating the image, but when you change the slide with the bandwidth limitation it sometimes takes a long, long time for the full image to be filled in. What I'd like to do is modify the stream to include some marker that a new image has appeared. The encoder should send a moderate quality version of every block then use h.261 replenishment to improve the quality. At the decoder you want to hold the display of the entire image until you have all the blocks. 4. Implement H.263+ -- incorporate some of the coding improvements available here into the stream. Should improve the quality. Anyway, all these things are possible, I just don't have the people/time right now to do them. We'll probably do 1 and 2 first. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry From rem-conf Tue May 04 23:12:19 1999 From rem-conf-request@es.net Tue May 04 23:12:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eunM-000336-00; Tue, 4 May 1999 23:04:36 -0700 Received: from www.readysoft.es [194.179.34.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10eunI-00032u-00; Tue, 4 May 1999 23:04:33 -0700 Received: from guzman (rs163-136.readysoft.es [194.224.163.136]) by www.readysoft.es (8.8.5/8.8.5) with SMTP id NAA16057; Tue, 4 May 1999 13:40:52 +0200 Message-ID: <0ed901be9623$d83dc0a0$fc66a8c0@guzman> Reply-To: "guzman" To: From: "guzman" Subject: E M O 9 9 P A R I S Date: Tue, 4 May 1999 13:43:50 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: multipart/related; boundary="----=_NextPart_000_0ECE_01BE9634.9BB5C7C0"; type="multipart/alternative" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0ECF_01BE9634.9BBEEF80" ------=_NextPart_001_0ECF_01BE9634.9BBEEF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Asociaci=F3n Espa=F1ola de Fabricantes de M=E1quinas-herramienta=20 =20 -------------------------------------------------------------------- = =20 =20 =20 Dear Sirs, =20 AFM, the Spanish Association of Machine Tool Manufacturers, = would like to invite you to visit our companies at the next EMO Fair in = Paris-Nord (Villepinte). As you know, all the world innovations in the = Machine Tool sector will be shown there from 5th to 12th May. As a = technological reference point in this sector, Spain has over 7.200 m2 = and 93 companies taking part, and will be the 5th most important country = there. =20 If you would like to known more about Spanish machine tool = companies exhibiting at the EMO (stand number, contact addresses or = machines made) either press here or simply type in the following = Internet address: www.afm.es/emo/index.html. =20 We would also like to suggest a visit to the AFM=92s WEB = page www.afm.es, where you will find all the information you may require = about the Spanish machine tool sector and its makers. =20 Thanking you for your attention, we look forward to your = visit at the EMO.=20 -------------------------------------------------------------------- = =20 =20 =20 Messieurs, =20 L'AFM, l'Association Espagnole de Fabricants de = Machines-outils est heureuse de vous inviter =E0 visiter ses entreprises = associ=E9es lors du prochain salon EMO =E0 Paris-Nord (Villepinte). = Comme vous le savez, du 5 au 12 mai prochain, la capitale fran=E7aise = sera le lieu de pr=E9sentation de toutes les nouveaut=E9s dans le monde = de la machine-outil. L'Espagne, comme point de r=E9f=E9rence = technologique dans ce secteur, et avec une surface d'exposition de plus = 7.200 m2 et 93 entreprises participantes, y sera le 5=E8me pays en = importance. =20 Si vous d=E9sirez en savoir plus au sujet des fabricants = espagnols de machines-outils pr=E9sents =E0 l'EMO (n=BA de stand, = adresses de contact ou production) cliquez ici ou simplement tapez = l'adresse Internet suivante: www.afm.es/emo/03index.html. =20 D'autre part, nous vous invitons =E0 visiter la page WEB de = l'AFM, www.afm.es, o=F9 vous y trouverez toute l'information sur le = secteur de la machine-outil espagnole et ses fabricants. =20 Nous vous remercions et attendons votre visite =E0 l'EMO. =20 -------------------------------------------------------------------- = =20 =20 =20 AFM Asociaci=F3n Espa=F1ola de Fabricantes de M=E1quinas-herramienta Parque Tecnol=F3gico de San Sebasti=E1n Paseo Mikeletegi, 59 20009 San Sebasti=E1n - ESPA=D1A Tel.: +34 943 309009 - Fax: +34 943 309191 E-mail: afm@afm.es=20 http://www.afm.es=20 =20 ------=_NextPart_001_0ECF_01BE9634.9BBEEF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

 
 


 
3DAFM 3D""
Asociación Española
de = Fabricantes
de=20 Máquinas-herramienta

3DEnglish 3D""

Dear = Sirs,

AFM, = the Spanish=20 Association of Machine Tool Manufacturers, would like to = invite you=20 to visit our companies at the next EMO Fair = in=20 Paris-Nord (Villepinte). As you know, all the = world=20 innovations in the Machine Tool sector will be shown there = from=20 5th to 12th = May. As a=20 technological reference point in this sector, Spain has over = 7.200=20 m2 and 93 companies taking part, and will be the=20 5th most important country there.

If you = would=20 like to known more about Spanish machine tool companies = exhibiting=20 at the EMO (stand number, contact addresses or machines = made) either=20 press here or simply type in the = following=20 Internet address: = www.afm.es/emo/index.html.

We would=20 also like to suggest a visit to the AFM’s WEB page www.afm.es,=20 where you will find all the information you may require = about the=20 Spanish machine tool sector and its makers.

Thanking = you for=20 your attention, we look forward to your visit at the EMO.=20


3DFrançais

Messieurs,

L'AFM, = l'Association=20 Espagnole de Fabricants de Machines-outils est heureuse de = vous=20 inviter à visiter ses entreprises associées = lors du=20 prochain salon EMO = à=20 Paris-Nord (Villepinte). Comme vous le savez, du = 5 au=20 12 mai prochain, la capitale française = sera le=20 lieu de présentation de toutes les nouveautés = dans le=20 monde de la machine-outil. L'Espagne, comme point de=20 référence technologique dans ce secteur, et = avec une=20 surface d'exposition de plus 7.200 m2 et 93 = entreprises=20 participantes, y sera le 5ème pays en=20 importance.

Si vous désirez en savoir plus au = sujet=20 des fabricants espagnols de machines-outils présents = à=20 l'EMO (nº de stand, adresses de contact ou production) = cliquez=20 ici ou simplement tapez = l'adresse=20 Internet suivante: www.afm.es/emo/03index.html.

D'autre=20 part, nous vous invitons à visiter la page WEB de = l'AFM, www.afm.es,=20 où vous y trouverez toute l'information sur le = secteur de la=20 machine-outil espagnole et ses fabricants.

Nous vous=20 remercions et attendons votre visite à=20 l'EMO.



AFM
Asociación Española
de = Fabricantes
de=20 Máquinas-herramienta
Parque Tecnológico = de San=20 Sebastián
Paseo Mikeletegi, 59
20009 San=20 Sebastián - ESPAÑA
Tel.: +34 943 309009 - = Fax: +34=20 943 309191
E-mail: afm@afm.es
http://www.afm.es=20

------=_NextPart_001_0ECF_01BE9634.9BBEEF80-- ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <0e8c01be9623$5f3e6920$fc66a8c0@guzman> R0lGODlhwABWAPEAAEd8kL0sHv///wAAACwAAAAAwABWAAEC+5SPqcvtD6OctNqLs94chQ6G4kiC wVemEaC2rnOi7wywZT3nRyzrN/7z5Xg9IagGHCFtRhWx2MwsmaJl1Pm8aqbU41RLep7AFm63wyWL xGP1yqyEuzns9pxhTnrTd03d3neQp8cxeBYo8QfYZ3goNYh4objo1uh4YekzucnJxpi5B6nTSUp6 Z0n4CDpT2jo5h5qKETvqaitWGXtZoTt0+xujpitb1ssKDEw2TMw7fIx8C7bMPDH9DO2asEsyTS3R /YIdjeAd0l3+cB4unk2OvnH+3hDvwt4uiNQSL7+wX29fSpuVH/5UgYvE7UucfdscMGyIsJnCUAUx MYxY+0VOoYf83D3EuAAKBFFbOHbE9xFkgmDVSFo0CbGfSZUeWL5xSQFmvmIzaRog8q0RT50vhdLy mWXkqps6Y3oUKuAoTU8OUQVdFnXpVahZtUasU9VqOmtdDUnkWtbsVLB4jLXFakBsS61SMb5SABcv 2bhew6Ll2xfRJr3OBOYFrHZr4qeL6QA0Zdht2rqIcfptjPLvhseQIx896DnPXM2ZMWfg3Olt04mh NY4NXNnyadSDVa++JPc1acayJdG+a5voPNi8Res27fv3n+M9h+9u7dr5cwrKFSmFeR05dNaXe1eo vjz7RfHGu5cnfx4DeLbo9zKPLvO29gnrqTIF/N2eO2H58yPUx5UTfvkNJB1/6VnwX1IBFjaad5MZ yMdsCdq0YG6KHVgchPpRNyGFFfYXHHylaSgifbWdMp15Ee5HIoaJnIiii/e52CJxD3ASiYwzllij jQ3gmOOGH2LYo48MABnkSSwSWWSKR8KIiJJLitikkyFB6dNQllVp5EpYZjkkfJTB02VNwIGpZXpj klnmT1+iueOKD5ZYkpVmWgdnmq6tuVGbSObZ4Hl89gnineEBGqhGgxJaqJtnIjrgTnPKuVCjAvwJ 6Xt8LIqGhT++memUm7Y5i6dPPhpqiGlwSpGDO4Ca6ohwmEqQlZjGKqqA+tBqKHu4xmfpHTbY/Eos BNAUi+ypvyTLrJfLNgstMtBOm8y0zVZrLbPPZpvsttwiO8634Noirrb3lEssuegqUAAAOw== ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <0e8f01be9623$5f892dc0$fc66a8c0@guzman> /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkz ODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2Nj Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wAARCACtAGEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDuyoPU VBLaxydQKs0mKak1sDVzntT0lZAdq/pXI6lpHk5O2vTnUMMGsbUtNEoJIr0MNi3F2ZjOn1R5fJAV JyKgZK6fVLDy2O1axJIip5GK9qPJVjchNooNH7UwpV7ZmkMINc9XBQmWptGeVIpMVofY3f7ozTo9 NmaQDYcfSvNngXF76Fe0RUjtJ5RlI2I+lTR6XdyOFELflXe6LpyrbqHQZ+lbIsIxyEH5VnKnTi7C UpM87/4R4/8APzD/AN/F/wAaK7r+zU/uL/n8aK093v8AgV7KX8xvQyrKgYHrUtcp4V1gXdsqs3zA YNdUDkZrhlGzKjK6FpkiB1xT6Kko5/VLJNpOK4zUbUhyQMV6VdQiRTkVy2r2hwdq16eExHKzmnGz OLYbTzSBsGrN3A0bHIqO2tzM2K9xSTjci5o6TJC8oR8V2Nnp8LKGCiub0zQ281XrtrKAxRBTXiYu r72jLpq+4R26xjAAqXZT8CkIxXn8zZvZFbb70VLn3/X/AOvRWlzSx5P4dv2s79Rn5WNesWMwmgVg eorxGJijhh2Neq+FLz7RYpzyBUfFAxekvU6Etg06mSDvSocrWfQscRkYrM1GAFDhcmtSopl3IeKc JWYpK6PO9YtJCzNtwKwRcyW0nydq7jXEnZGEUR/KuOa2xcBZvlJPOa9rD1OeDizkdk9TofD2tPPK qOntXcRfMgNclo0en2oVhJHu9SRXU21xHIoKMCPavNxC10N6bJyKa1S8GmkVzpm1iruP+TRTt6/8 9P1/+vRWnMijxKVDHIVPUGu78B3BKtGT0Ga57xJY/Z7xmA4JrT8CPt1Ar6rXROly8zWxzc3Mkz0k jK0yM8kVIOgqvG3+kuvsDXEtmbMs0h5FLRSGYesTTRBlit2kOOvavOtZN087vcRmP0+XFemazfiy jB8iSUkZAQcfnXnWv6zPfyhJIBCqkkAg5/Ou7DS11OeS94xAZAeGP512XghL1rgu7MIAO54Jrj84 Oa2rPxZdWVusEEMQ29zmtq9OFOO+rKd29Eeqo4xyaduU8V5V/wAJnq7tkSIPYJXS+FtU1HUbp3uF zCwySBgAj0rg9npe5fNbQ6zA9v8AP40U35v7wopWNDjfGFp94qvvVHwEmdWf2jJ/UVv+LlxCT61m /D+3Jmu7g9AAn5nP9K7ZSvQuzlS95o7mqMT51aRPSMfzNX+1YdhcCbxDeKOijb+W3/GuGCun6G03 qjdoooqCzM1jVrTSYle7cjdnaqrkmuD8QeKbfUrdra2tGUMR+8kxkc9gK7/VLvT7WEHUZIFQ9BLg 5+grhPEOp+G7i1kSxtA1ww+WRI9gU579K2py5XciSuzlzilU+W4farYOcMMg1NaJBLcKlxOIEb+M qWA/Ku3sPBthLCsj3TTowyCmAD/OvTrVaaTTepGvYseGIdN1KxWdNPhjdTtYbB19jXURxJGAqqAB 2AqCwsoLG3WC2QJGvQCrJOM15M5czLirIMD3/Oio/NH+T/8AXopcrNTn/GDbbb61P4NtRbaFE+Pm mJc/ngVX8UKbh0t0Xc7naB7niugs4FtrWKBPuxoFH4V0VJWoxic0VebY+WRYYnkc4VVLE+wrlfBs rXN5eTucsQCT7sSf8Ku+NL37JoUiBsPcsIlx6Hr+gP51V8ARH+yZrgj/AF0xx9AMVEFy0pPuXJXk vI6yiiisDQy9V0TTtWCtqEO8xghW3lcD8DXCeKNF0TTrYvYXebgMB5PmhuO/vXR+IvCU2s3jXKai ycACJ1JVeO3PFcTqmmXvhm/jzMnmEbkeM9vcGqXmJkcOjX98qG1tZHDY524H59K9G8K6TNpOliG5 YNIzFyAchc9hWN4U8V3OpXgsbyOMkoSJEXBOPUdK7Rvu+hrWrU55Xta5KVhw4FMkbFIz4FVJZGao jG42xvn/AO1+v/16Kzd0n94/5/Giun2UTblLZsk1DUWedd0cJBAzjLdR+VbVRQRCKML1PUn1NUPE WqJpOky3GR5hG2IerHp/j+Fcsm5tJGKXKjhPHmqG81g28bZitRs4/vn73+H4V3nh2y/s/Q7S3Iww jBb6nk15j4fsX1jX4IpMupfzJSecgcnP16fjXsNXUdkooELUUpcRMY1BcA7QTgE9qlrE8ReIoNBj jMsTyyS52qvA49TWKKOT1W/8aJ5hmjlhj7+RGpAH1GT+tZ+nadHrUiyatripJ93y5XJkx6Zbp+ta tz8RXdSINOVT2LyZx+GK4uV5bq4eVstJKxY4Gck81V0I9b0fQNP0hCbOPdIy8yMdxb8f8K1TgjnI zxisDwXbXtroqrfb8liY0fqicYH9a3XYfU+9Ahj/AFqF8U92FVpXraKIkyllf74/z+NFVvP9x/n8 aK7eRm9zqncIMmvLvGettqWoeTE2beA4XH8R7mum8X64LOya3hf97IMcdhXB6VYyapqUcIBIZvmP oK4oR5depi5XO1+Hel+RaS6hIPnm+VPZR/if5V2pqtZ26WtrHDEu1EUKBVisJu7LWwhbAyay73Ud GlQx3lzZOB/DI6n9DV28iS4tZYGZlEilSVOCAR2Neba74TayDzWk2+IZJVzggfXvVQhzbbibtuQe Kf7CEqf2TjzM/OUJ2Y/z6U7Q/EdnpCgDS1Z+8vmZYn8Rx+Fc2OoBq3Bp89y+y3QyHvjt9a0hCc03 FbCdluep6Rr1rq8DPbllKHDI3BFXnkH41y/hnTE0uFi7lp5Mb8dOOgH51tPNwQDVqmRzolklzyfy qrLLjPNMklHrVaSTiuiFMxlMzPti/wB79aKzPOf+/wDr/wDXor1fYndYxr+8l1C8aRiSWPFd54M0 cWduLiQfvJB+QrmPC2kG8ulmkU7F5r062jEcaqBjFeBNtIwSu7LZFkcCmSvtQ4602SXaM1z+q+IY LNirtz7CsoQcmXKSRheI9Z1i0nfZ8kOeCFBFctd6zf3gKz3DMpGCOgNbmqeJYLqNkWMtn1Fcqxyx PrW1V8qXKyIK+6HKhbmpo7u4gY+TKyf7pqOI4FDKCc10KjL2ScHZvcptN6mna+ItQhkG+bzE7hq7 GC68yMMRyRXB2SwrIHlccHIBrorfUomACyKT9a0o03y++9TmrNJ+6jbeTvVaWXHeqzXG4dageb3r rjTsczkWP7C/2T/4Ff8A2uitD7Yv/PT9f/r0Vh9Yq9zk+uVv6uamj2MdnbqqqBgVptKFFUVmCr1q K4uhsODXC4OTPa5lFEt1qEaAgsBXF+JJLeZWZWG71qn4huZ1nO1yF9jWA8rv95ifqapyjS0aEk56 jD1pUGTTakQYrCkuaaNXsPFDdKKWvatzRsZFenKxVsg81Iyios4PFeRUoujJNs0TubVvdMYxuapX nyOtYYlcdDUqzseCa9KnioS0OaVDW5v/AG73P5//AF6KxvMl/vr+Zorm9jU/lZj9WidxeX3kxFs1 zNz4il3kKOKt3lwzxHIrmJ/9a31rTEN0o3ia0Upt3Jr2+ku2y9VDRRXlzqObuzsjFRVkFPQ1HThT pycZXEyUU8U1elOFe7Rd1cyYHpUDKQasnpTCKnEUFVQ07Fc0oODUknSou9ePVp+yna5oncl87/P+ TRUeaK2+sVe4rI//2Q== ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <0e9201be9623$5f99f6a0$fc66a8c0@guzman> /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4p LSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk//2wBDAQ4ODhMREyYVFSZPNS01T09PT09P T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0//wAARCABSAGIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD06iim O6xoXdgqqMkk4AFAD6gubqC1j8y5mSJfVjiuK13x0Qzw6MF2rw1y44/4CO9chdXs+oXLSvM07tzm Vvu/QdMVvCg3uZSqpbHpcvi/SUYiN5JsfxIvH61D/wAJhbN92HAxkFnx/Q15uC6dmLf3mH8qnQ/J yfmbk1o6MUJTkz0VPFlpuIkhcAd1O6rtv4g06fAE2wn++MV5zCSVyCdy/wAqtplh90g+uOK5qrhE 6adKUz01HWRQyMGU9CDT682t7+5sHJhnZG/ug5H49q6bR/E0V0whvQsUp4DD7rf4VhGrFuxrPDTi rnR0UgPFLWpzhRRRQAh6V5l418TG/mewtJCLKJtrspwZmHb6D/Paup8caq2n6N5ML7J7olFb+6v8 R/L+deTzOk7ZzsI4Gen/AOuumhTv7zMakugwu0rgD6BRXU+GvDP9rW0txcXH2a0Q7fMwP3jfj2FY GnafPd3MNvCuZLhxGrDkKD1P+fevUdRi0C202DQb+7WCNUUqu/aWA7k9OvNa1ajWiJhC+rOcv/Bj 2iRG01JJmmkEaIV2k598np1qDWdCvdHEck0ySRyHaChPGB3rU0DTNMi8XD+yrk3EEEBcsW3BXPy4 BHsa1dcT+0tL45MV9s/8e2/1rnlUkjohFXMG40G+sLBb2aRWjwN6qxyoNX7Dw2s2npdXd2YWcZUE DAHbOa6K6xepf2J52xAfiQf8KybgNfeC4HjyWiVSw/3eDXLyqc9TodaUaehi6jpk1g4ScKUP+rlX o3tWc8Y528Guh0KZdTt7jR7vLLs3xk9V/wA5Fc7PBLBM6v8AK8bFGJOM4706tSEXyyjddysNRqyV 4ys97dDqPC+tuZF0+8Yk4xE5/lXWV5ckg27oyRIv8Q4x9K9C0a9/tDTIbg43EYfHqOtOKtbW6exn VV23azWjRoUUUVRieZ/Eqctq0UOeI4Rj6kkn+QriCuTxXb/EWAnWo3UZLRA49a5CJf3qn05/LmvR o/AjkqfEbXg+/wBP07xELjUXKRxxFI2wWCt0zx/wL867S8i8Ka7cG5k1CPzWAGfO28D2avPdAs47 zW7aCaMyRsxLJ/eABOOPpWnNpay6dLONLmsJ45URI2LESls8ANzkfWs6kE5XuXTk7HX+FrXT7HV9 SjsrpJo0RMNkcDnPI4PapfC15DfDUYWKn/SmmUeoJyD+YrhDpl5bp86A7pBH8kit83PBweDV63sL u2aTz0ngYRM42jk49eeBXPUjbU6aa5tDtNJvo5/EeqIrLg7AvP3tvBqjpOrQWFxPZzY+zNK4VgMh ef5GuZFldLB9o8pxHjO729fpWraW9hBbW0d3HJJLcgNvD48oEkDA79K5aU7y5WjrxFFRhzJnRRvo WlvJexXESs69BJnj0Arhrq5+2alcTAYWdyQPqeP6VuPHFp8KRzWkNw8kzo7SLkgKQMD09c1i39i9 pqE0CgkRuQp9u1RiaUvsq6Ncvr0ldzdpeZFbffI9q7DwVMdt3BnhWVx+I/8ArVywj2O2BlmPAFdN 4KjO+7kPUhQR6da0UeSEYvcxqzVWc5x+HT7zrKKKK0OQ4/4i6f5+mw3yD5rdsN/ut/8AXx+deexs WfDqHyrc9+le23NvFdW0lvOoeORSrA9xXk2raTPomqGGZS0ecxydnWuqjVtBrsYyp8015lPTJUtL o3Cq2djoFJ6blIzn8afZvtvLdr2Qz28bgshc9M89ajddjsv+TTetY/WZN3toeh9RppcvN73qdIbu 0WGJFuImH22OU+XAsYVBn05J5psFyjXuqTSSZ8+ORYyf4ssMfpWECPK69Gqxb/OuRTjONTRbmU6M 6PvPY6F5IGsW3yxOfICRsoKS5wPlbsRU1kXNpaCawE8qnFvJ5mBjJ4I74NY0a8VZjurmK1eGKd0j J5UHjvXJUg4yudNKcZxsbIluJ57mS1W2miNwcGRcmJsff9h/hWPqNxHNezyqxcE8HPXHFUsMoIBO D196ETLjPTvUrEyirWKeApyd2x80xLFVAXscV3PhWzNppCMww8x3n6dv0rmdB0l9SvPMlXFujZc/ 3j6V3ygAYA4FVTcpy55mdfkpxVKmOooorY4wqlqmm2+p2hguV4PIbHKn1q7RQB5hrXh+409v3kZa MfdljGQw9/Q1kCAHo4/HivZGUOpVgCp6g1h6h4W0+7YyRKbeQ906H8K6aNdQXK9jDEU5VHzLc88F o7RPt254b7w/z3qOMuq7QCCp6V1s3hK+hOYJIZl9M7SRWU/hXWFlYmzDgngh1P8AWscQo8ylT3Z2 4KpPkcK+y2I4iXRWA61LtOwdOTnqKuQ+HdVbAa3K+7MtX4PCt3IwM80cSjsPmNby5GtWcKlJSfKj C2L3b8hWxpehzXeGZDHEert1P0FdDYaDZWRDBPNkH8UnOPoK1a5JRhfRHWqtS2rIba3jtoViiUKi jgVNRRTICiiigAooooAKKKKACkoooAWiiigQUUUUDCiiigAooooA/9k= ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <0e9501be9623$5fa197c0$fc66a8c0@guzman> R0lGODlhNwAeAPcAAAAAhAAAjAAIhBAAewAIjAAQjAAhjBghjAAhlAApjAAplAApnAAxjAghnBAp lBQtkAAxlAgxlBgxlAAxnBg5ewg5hAA5jAA5lAA5nAA5pQBClABCnABCpQBKlABKnABKpSEYjBw1 lBhKhCY/lzEhe0VGg84tLc48LucgBOcxEOc5COc5GN4pIeQhK+cpId48KedCCOdSCOdCEOdKEOdC GOdKGOdCIedKIec5KedCKedKKec5Mec5QudCMedKMedKPQRSmA5onCtgjjN1kEpWf1BYiE9gjkh9 jWNahF5vjGtviHhwjnOAjo53nomOopyxqOdSEOJSIeJSMeFiRM6EKeeDI8p3PdKIOblrVrd1br17 bc5vaLGMd9CgaLWUlrW4n5yttaLAt6+9t7rDtanOuarIwLLOurrOwMHStcbOvb3OzsPOztDTtc7e vc7Sxt7Qxb3exsbixsrmzr3t4tDkxdbnztPp1t7t2sb/99P58db/79b/99736d7/99b//97//+8Q AO8YAO8hAPEtBO85BPcxCO8xEO85EO8YIe8pKfslHO8hMfc1FO8xIe8xKe8pMe9CAO9KAPdCAO9C CO9CEO85GO9CGPc5GPdCGO85Ie9CIfdCIe85Ke9CKe85Oe9CNe9SAO9KCO9SCPdKCPdSCO9KEO9S EO9KGO9SGPdKGO9KIe9SIfdSIe9KKe9SKfNKNe9aAO9jAO9dCu9aGO9aIe9XM+9nNe9rOe9SQu9a Qu9jQu9rQu9rSu9zOe9zQu+JPu+ESvd7SveMSveUSu9jUu+MUu9ra+97hO+Mpe+cpe+lrfelre+1 re+lte+ttfOtwe/Ge+/WjO/ejPfWjO+1te+1ve/WnPfite+9vfe1ve/vzvf/zu/31u//1vf/1v/3 1v//1uf33uf/3u/e3u/n3u/v3u/33u//3vfW3vf33vf/3v//3uf35+f/5+/v5+/35+//5/f/5/// 5+f/7+/37+//7/f/7///7+//9/f39/f/9///9+f//+////f//////yH5BAEAAP8ALAAAAAA3AB4A QAj+ALlkUQMHzZk0Y4pQSILEiJEiRJA0RKKkxJg2WLJo2agRi5c2ToooUbKE5JKTTJosKeJkDMI0 Z74cwdDBQ4Qm6vKdq+Lih4tk/djBi2dP3ZAQ9uJFUhEDVSkYolBk01dGwJFt/7Jq3co1KxVNNm7U 8HHDxgwdNcDOmpHjRhRNNeJqupEii5+uePPiBbPGjRs1YJ7A0Uu4sGGubvR14/mjhbN+8M7Zs8dt yIUNGzBkjlA01ooZlkTBkDGomT4yAS54wMBawxh12saMORPHjZ09ffrwS2Nvm7py5dT5LlfnTr16 57Td0XaNHDx49brBqDSj+iQTcw4TptKoxw23OtD+RvFB/kYnE1zEzOnTT7t7rgPYvJ9PP2sXTj9w VOtXbyjlIZphlhkHGGjwwGSxZIJKDVDYIIsgppFRwAYEasDaBhNc4IU9+thTTz7qDIPIFEck4ASH iz3ikzL8PEeUURashpQ9S80gAwzVoeAMVQR8kNkSbNxx2BALaLDaBh4o0IQ9Ov3igg6PIFOPUJMh B8kKkcQggwyiEPLMGXXU9w8VuPAyRS+1TLHLFL7ssqYtak5hyy61rNnLFKGZgkIY/IjJ1RWURJHD CrToMMMNc91AgyaH2mADLafU4AIXePhJ2BW+AKNpMcX8MowUWKixh6ViisCBAUysQ+qqWnWRyDH+ Hz7nIRgJcADEBkB4YOsGHXAgwWSzcNKKK52gcsogyegDx4QBauBjEBtEEIIbk3GYzzVRtBGNCzzs YAw5kMEzWRgRZIZZB5odWA8sNVhyA3U16HhaAJlpZu8I6XRojzt3QNPCCS9gIcQa+vQDTQ4/7EAM Of2Ja08ZBmjGQQS/2hNLCjLEVUoMgexIBgEDYjDCG2mYIaReM10Awhv61BNNJTzwMMU4/bTjMBoK aDBCUZAccqMlNUSCQjX6hFEABhV8cY57AFKI5Mr65GMNDT3o8AM6QRFVzxN3qAMDjpaMJgMK2OjD xBP1DWHAAhZcoMEFETwwABj8RbPCDo+08My5c9Cpo4IlMdSAigyhpPAFO37akU8+9fTDeD6ON944 P/1U3g8/jfcTjworiDJLIXatekUlN/jQQw85hJdDW2StroMPq/tQgys1zFDJCXO0x+oVONAShQ42 6GCJDFEgKsN3NtRAiw00IHoKC2X0yapWVmQcBRSEfgfeozfQ0kknL5zgRe7Td0XFJjfkcLorPexg Xg7iq8Fe+YXdEbXji/ehHv3zlaBZAyQQA//EBIQEfGGAljogAi0VEAAAOw== ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <0e9801be9623$5fb260a0$fc66a8c0@guzman> R0lGODlhXQBGAPcAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzP+Z mf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zAP8A//8AzP8Amf8A Zv8AM/8AAMz//8z/zMz/mcz/Zsz/M8z/AMzM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZ M8yZAMxm/8xmzMxmmcxmZsxmM8xmAMwz/8wzzMwzmcwzZswzM8wzAMwA/8wAzMwAmcwAZswAM8wA AJn//5n/zJn/mZn/Zpn/M5n/AJnM/5nMzJnMmZnMZpnMM5nMAJmZ/5mZzJmZmZmZZpmZM5mZAJlm /5lmzJlmmZlmZplmM5lmAJkz/5kzzJkzmZkzZpkzM5kzAJkA/5kAzJkAmZkAZpkAM5kAAGb//2b/ zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAGaZ/2aZzGaZmWaZZmaZM2aZAGZm/2ZmzGZm mWZmZmZmM2ZmAGYz/2YzzGYzmWYzZmYzM2YzAGYA/2YAzGYAmWYAZmYAM2YAADP//zP/zDP/mTP/ ZjP/MzP/ADPM/zPMzDPMmTPMZjPMMzPMADOZ/zOZzDOZmTOZZjOZMzOZADNm/zNmzDNmmTNmZjNm MzNmADMz/zMzzDMzmTMzZjMzMzMzADMA/zMAzDMAmTMAZjMAMzMAAAD//wD/zAD/mQD/ZgD/MwD/ AADM/wDMzADMmQDMZgDMMwDMAACZ/wCZzACZmQCZZgCZMwCZAABm/wBmzABmmQBmZgBmMwBmAAAz /wAzzAAzmQAzZgAzMwAzAAAA/wAAzAAAmQAAZgAAM+4AAN0AALsAAKoAAIgAAHcAAFUAAEQAACIA ABEAAADuAADdAAC7AACqAACIAAB3AABVAABEAAAiAAARAAAA7gAA3QAAuwAAqgAAiAAAdwAAVQAA RAAAIgAAEe7u7t3d3bu7u6qqqoiIiHd3d1VVVURERCIiIhEREQAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQFCgD4ACwAAAAAXQBGAAcI/ADxCRxIsKDBgwgTKlzIsKHDhxAjSpxIseG9fPkI7stYsaPH hKwSemmViBU4f4m85Nu3z+C+VRv3+ftIU+G+f14QIvLCs6cXQYl2cszX719QRIkS1Vxq0F8/LzIO 9tvps+rIVuC+CarKgilTouC25hRoBSMro1bTqvXK9N+3qqxa9fsGrpXau1ajsv2YD+dduxDwCuY5 0MpeivnA4U0kSMdgwTRYzWW18bDCsoYF3lyMiMbjzz0RVbZMEFxWuqazIlrNGmlSkl5arz4qe3ZS 2khd3159j/TAfWJ5ImVFvBUrut++9Sv6rVXy5P3iLp/7fC51682ff6MKtbdvfPv5EEEYrwMRq1Xo V/n7x97fqrPs/9Fjv6pUevX+6C33x78//37+5cPCePZ8R9ZbPRkHyIJFyccfIKSsR09/q+BTBSkY klJKKYD8scp0IIIomRcQeKaXgSn1VNKCpbTXXx55nPVfKSrUAwh6pPzxRx5P5AFgdMsRByRxrHjh GWEG4sOKWIK0ss+CZ034Hyl5lEKPOv7QaON8WeqYxx+kzDcdkecR+dQMPrF0WFkmgZNik/twWMp0 TvVTSo/1AVJjmP/wt8qOf1j5jzpBkinZoUZWJYM93i11T1GtcPeTcasAkoeleZBCHCD1wJhHjXms 1x8rMHo4KH+HGkrcKvteoFnVYftImiArHOZRBY8wPlFPp56G2ieATgEa5X+pqppoVYKINppHRKFV FSKU2ldfrk+o0KOnYWLpH6CrOFioqsQda5Ug5DZaET12qUXpeuxNWGmvX95IZ3SllqIOlmOCW+SR dxXokbPjGgdffxNSCe8fHcKIIY0qgLkwNNHp+5RjeGHkUVh/Eedif4Bc++WlmHqq65c75rGKfvqG y+9diBTE0UMAPyvXyX3WuYoKKvRKSj8T0hoyyRiuFzGZQ7f6mXk8++OvQivtc1ZwVlEKTc12gopj jO1yWamON7L7q5DGUgyaF/YsjVC326WoVpPn4dfPzZ2KWsofRftJiaqOYEoo5beGeiH2Z/bUs9BN JO0W1G2If3PehhjWCAiX7pm8ceSXduvgf0DWhx5xO+V2OOKryQAAAPaQvlBfJFWnenU/vlvFyKL6 mWnsy+XRaYSXv+dUPoTxDto9pjO6kBX+2JWIf8j3B2Cf79qax9ROoXppUf992jAp6vRJJd39tGLP gOOVSMP4NIhP/vgQsAAARH3F1gqxIYJIT89UWgqIOnYvZ6l69NaIMCnqgcanboQe8ojtb2lRn7kY 0j5oYa5YEZtXrRb0nv3o70KksBTOMpUhVqiDShiCEQQQOBgaSKSB3yAWuCIIoFWAbEEw1BApcFay JzwBTPv9gAZ65tcxL+WhRGPjyYkcQjwvJOJ9/kgZqW6lHhq9EF66qgIMIXQy96xHgNbKEClGGESo sG8f9DDi+4JUikwZaoBO0ZWG8vQzkGUQgPNRWBmtBaZVQEMdQAziEBvyjZQgIoX6s2EpJPMePamg W/3A0NQA5LMFaTFDRSGFDWGUMwhNjT00IOFjIhIrI6bQKUsshcFeVw8rAPA9Uysj/xzJCnZlSVP0 4FCHdIQhy+GPi118WUPykZIjomqJlqqCMGE0RUfaED+Xgo/W1COfVTwSgPLBUiaDODqzNaRI0EJZ HuwhRQhlqJi5yllR+gEIQdktP9EklcMyZEf+TPwTNDTozT0WuBBWrAaQHbMHhOzTugxO8VIt+sdy 5lOz5KmjYxBqJa0ACKB3goYicUmE4kohkHI2qF2J3KcoWQS5/PiHTk75lKbYo46FviePoOlKRBLz mvOwsl3+wNf05LNQAH4Uc2ScY5WydyX3iLIUK3vMouhpE3W8BVrRYRz1/LOKKgTUXaIEYCvR8yMg lZFHT7gRSSmEIYd+JiLrKZxzkroh/ChPT8Py008zaDJUTUeSl8JQ3fzDCgz9xHCgQ9xt8kFUhBRp K8lCBLl+4hPBbiUfMggsEu2EIUyNM2Kaq48iL7ccFwLCaZKZDmpOMyYh9tUg82SBDEoUPgj7zKC0 qC2tEev0xjVyaWiS0SGGWDG/JLJVBWt8DyugQdCsRQwR9kjfQ+ZpDxl0UTiArBA+auki2Ca1ls4M 2a3YiZ5Laos/0toHECWyDwQFMRFvK+M9OJjWby2HQ9/8EkPPk6EN0facrEBYfQLjRYiwQm1jOyIb GWc5nJqptVJFJ/NyuzloYM6yMKEvCz57kE52Ebz8gap9mgtbVgACg3aksDOZ6R6q/ufCO2tFYGgg OIjM87gSjY9TRKkefA3NTjxyKgCz91Eq1Y1Q6alsHqywCnWIuDsSuQeKv3Eqpywsx98iRRVMyeL1 XLcfl5rP3tKTo+Ui0kQMToiDQZP7YgoBNINnqTBV0WMfA9usCrYclTP9+aF//HgsJ/TuZ1I8obct V1qvHdrU1KFDae3WyFWY2jmhUdYco4tfFJHzYyRaZ3Li4z29BSXRKhvZ9Ow4dqB04SnTQxz6km0i /YDaYCRKLCnSrLZ1ejGAZFsfUdqKFLxFlTN3fMpVFe9IwpuIcbmcXEDgAxADU16Fp1MpKhN4zZi6 EW0d5Gb6WvMhKrBHUBeTw0pZoZwSEnaxUgWj+9xno46sbtbm04oj6fKEsroLeKNzHyf/J4kVlkwG S+HRt3n73vI5Z7lHZ7qK9EOvAL+NXFYVWWEPaYV6cxenzdw2yqLKC/OcZ0XhrPBvngDlLoNNS1Ay ziRyMSk3hu1JJ1fTk2RlvCdZ3iUryheYRLCABeeLefhmQAOa07y0MzitzlPL8/LIAObkozn5TEug ZweZ3yyAFkqPy/SUeDotixqdowRSthLJYNdMvwsLimsVxqxMfaMTLelSPhFG1aOaXKcB1o10ddEm UAb8ennU71E2I32Pl0bjCQDqEfHAkd0j3qH76M7OdX6fnXTGHZ/6Dj94wg/kHvUom+QTRYOyJWkh 3ilb5Asi+LOXWCASR4jZAMACL7Dg85e3CFFDXxGxp/71CuE77Gfvm4AAACH5BAUKAPgALAAAAABd AEYABwj8APEJHEiwoMGDCBMqXMiwocOHECNKnEix4b18+awItAKoS8WPIBWySiioVaJW/vwl6tJF ECCNA610WeWyi7+QOBUC+ufloBVEXoIK9SIoUSIvVjTm6/cvESJEJ3NKLWglpZd8B/sBHcrVSyuU /rYKZTF16lKeQfEltZJvZtOucOOWlWrlnz+urfql/Ncqrt+uM+bizIc27lEafxOnVQtTcMQqXQp3 hSpIh+LENPilTLQKq2OEazMm3fnXKeLLqIMiEqTnc8GUsGM/nf3UaCKVXmjX1k3btlPdvmffcz0Q EFdEKPkl6qc3tr9+X50/Z84crPTrYYXOGE4cX75E+xDC60DkrzOgVf7+qV9fatX69f5YrZqPXj12 5rG7HAh/oLvAfHcJ1Qo/+egBSCn02AdbHoAkSI86sJUCCCmkuGdXStRlSB0r/XgBgQ46bOcfPkcJ lQg/gOjBIDQQYtiPE3qocyFzrOThxB9/kMKUixz2wwqHQP7oxWk9jcjPViXxI2EeBpJSCivTOZFH ehgC4gQAN+K4ijoQ+vjjl/J92SGRRK3imEyavRVUK6xICAggecR54Hz14NNjKXmooEIeFOJISpCA ggnkkFzNcAB3Ut3DVCtiEcXmfCmxAmeceQLAJyk26glIP/SwQoqff/DppaBfrkIoV41JVYUg+40K KF+C/tADzSpwOqGClHHamgcr9vUDJ45xrkLPqILyw8qpxyECiGcgdcFUiUOR96OCKdFKaR6h/lGK jLH9iuO2/xBLKrKTCYJoRf70FRebTF1Y5bXY/rGjXv1A8ysgvKpHI6lCktkVDf2BpCZcebWLYXy6 Xrtpl7BZqW2CXE7Hb4eW/YURSPQI4heb+VZ5Ja7YYlvhKtA8B42Nf7hHj4vifimIv3AhkiqzDg18 3HOrNLeKrfU4QQogob75M4MV/njrH7yuzKOYX3qIGiL87BhwQmzNxM8/rQ71KJ556llKep7m8bU6 /ZSSrY31YJv00vxWlppQB0yNkHth+0G7bj/W3pqHwf7AydSDeGNqo5Rz9tgymF5UjBrAdSokCF+2 9eabUfFZm4eFB8eZntLxfYrjH0Cn3CV9q5T6I1BO/Tb5UzMAAMABry9EmEnYSReutaRwC1s/mrub kudCUwhrjXng08XbQt0DgAr4HLqQFer0dVvtzkkKJylUutg7y3JW6A+XveZ5AAvhQUCD+TSkj376 7EPAAgDnLhRZbrsbriFzq1RRxZuFaz/ljKvIQ8/Oo56c2YU5NhJPUCyjOLjo4H3xUwhkeIIcHrWs bE5IG/+E9iQfMa8fXcKUnnLEJTihxx8izMOHkEcDieiBgrDh14+89CZWzOpn+3Ca1JUuVaujnccf NuKTDm9kPuRdJSIAol+kwLQKFeGLRkyBUpveRCknOIGKuWLQm9wTQGChbEIrRF5gHpKPr3lhevsC kq2w5yW88elHONygHOe0Cgox5VP8KxoriihGiFTlKOR5jqB2VoUnhalGKlhYDilEoQlNqD52Kd0/ WEE476mHHjRoYGoi0oWjTI9WX0qRBicVp3qowD0nu1ysyFbH8zgINuHK0xvVAyF1hBF5NFtIFb5z xvi8aUld4x+T4oQPAkroa/9I0D+gISH3RIxCq/jDrQiYTNhkEnmuk1tDOoQcvFHRCfgw0Bw5WDpo qAcazfFHKZC5MkrG/GmaFUpmi/pxy8vQ4B74jKBCjhRI6/GvPev8GUDd5KScBfCE8VHmykgBshxV CD/P8cc130YRftBOnf80GK2QeTsJDS1OUJqOc9ZZCkaatD3U4WNqyIJEldyGFV04UL4uRCsLKa1N HwVEejTkohtC80cldVJ7YJaYGdRDnwk5YW4GJNNLwiaAa3vqzyjUMSjaD08VktGw6vizP0w0Nal6 XnpMchJ/GMuAI92V78pDNOzNyEf3u97fHoSznwUlcpNL3eTygVSDWIEf0VqNIAY7m8FqLB+5MSyb AKECRs5rQ0yLEztj4ylS8CNqEJUOfvhxPJY2ZHwHmIH5ykfa0vuaNjeAGA4jt6S0lpECH2Lb3MEk RaH2zHA9EPtH6bSyH88yZDihNaJqfHWeVZC0R4GaVCJL8TcMBbCxQp0Ph5zTj4K24kMtjIggAoS8 k7RLHW0K6A/BhCc91JZXkcIUbElKUuNKl0Z8WsV1FwORVdgtNbdRUGXdxJRRGVc+6yydfEL1RrwF 2EfGbc98Xluh+XqBBX09CCDui5r8xrC2T9LXqGJVNqEKDhDm/Ad425MeEcunkUxqz3xp0LiH3IMF wrWwICdUihAfcIbUqWNQLXkhT6ksYgauLX0g4AVDSeQeMU5Pl3hHzdaOCn/sFZbvalpN2MwqwPMB BGJEJPsRQGQtMdNz7izdlUYaCTXDB/Mm5iJaXQVziB9ELpJEkvi229SLQ6nNMOfSyKEARjc2+COg k7EqSb6cxiMSqUp3BSkh/emZbUAtXnulK2aVCRJTepjPJR0MsIn4Q2P4Te8vbRvSlrmpdAlW8Hzy UAWS+chsetADie3jYOclegZ13mmqj3tjfpXYwCT92f7mU9Kg0UerKomzNh9ygHoQ1TCxUieWfwSr NoKJKWTDGbFLGuCAqno+5lwZP06TS4js8stwuQ14ZV1o+MTngiGNz7dJRx9OycqAdkmEDlwXO4r8 Ma8AR0nZrJDhC7VWhj566nkMJ5/5tIuuJRa3F/PuoQJ8VsQK/ShRUY4XF43RgCWs0o1hNTbywRJl sF3IB2FnsyyiCJawiTB5UCLskKWcj8iJYAEL2Mdz9Z3v5z8fbXhubtryEV2BNNh5z9tXvriFRHmu YwFy0ifcqpvIQ5ociqFclyiBxM18M8C11f0SN7EP5TBDeV/UjXpUwRyqHq6rR3BpYPYhhZ0FdR/L DIikc0PJPW5DihsN+kIkuOPzACqwtWu4cw/YAQDu4/MCv+H+eFynD3aUn3w96qSRe2z+7Qc4ldxH tBDuxG3zBWn84x9PEIsjRG71gDELWkx6h+jT9RXBOwBqz3uFtL33wHdNQAAAIfkEBQoA+AAsAAAA AF0ARgAHCPwA8QkcSLCgwYMIEypcyLChw4cQI0qcSLHhvStXCAbqUrGjR4WsEnpphQiRv2+JvHQJ FMhKwS78Nnbx97Gmwi7/vBy0gsiLz58+E6V0ie9Kv38lS7ayybSgFX/9vBAt2K8n0KsjW53EyqJp U6M5feJzaeUKTKRY06r1ytTKv29XEfXr589fK7V4sc5gWxNn3rsQ8goWK3Aq34hXwqq9q2PwYH51 Ea3KeDihlcuX8QVSnLZnY8egfSIKRLnyQH9v635TnbS10EStUrYumWi269e3X+O+Z3pgoLiIWvHj N7ff6m+r3wo3jrx48ebPjTufi9yqFxoqegu8kgiCdx37iFitGk/+n/nz9EoFOmoe6nhWdOn1g1a3 fn26daMe8H5A+3a4P7XCSiCAFFggK/b5w0oeeqD2Dz30QLMKKaSUQgogf8A33XTweQFBY3v5h491 I63SRYHjFVgKfFCVUg8g7UHVzyoY/pGHE3nQ1Q98rPTY4449XveTiPjwYx1JgJDCHo15kLLKXHnU s8qD+UGVRx5/ZFmKeXP52OOTP3oxA1CjGdYWTHXd5UVwgaxoHj3+0GggIPWocFR+OwKiApZ/bPmP Ol166eOMYl41wwG8NXXPUSRdJdwqqMHpHiBXqlCPE5C2eKMT9fDJyp918SgoP6zw4yFWZtZkRRf7 JAYoXowyUnrllRRu6oQTe2aZIZVQCSqokFiVtFFfjAYr4Kf/yAgVIDjOeuWtWK4iHilZTqmOjL56 CSxeiXZkF17HxjgjnXs6+wcprKjzZj/U9qnOtcVlGyQNedHQn0f/pNSZgNKuUooet1ra7JV/AMKe faRgSWGFgWYbFb15leURPa0CxS+luKqgghN6yDorKfTwCtUfTmR55SqAyhvkZ3klYlhpDuWrVnDj XgnIkxAySSmK9811a5YUqgukl0MX6hgixCV7r0JmrcIPWouJlyR79Fy7YB6ljEehtPmVcquT7P3T sK9esBzaAUsj9DRK+oIr9aeS1rWKE4D7oKbOhDc/2U+UTarL69jamu3YAfUstFlsuOmmWyvfzIiu yP6QUo+fcl944R8a/zElqHjC5+97rPSUuOK1zQAAAAegvlBisZ3k+nGvQzVpKfjJGOVRkjpuI6d9 c851P1eoNINZod0DQHaIVqHQU3clkuDzsicrZ9Y6snKruvaxQi3B52KfcIZzHcCCd97RYL75EMxw /vkQsABAtwz5FVx+Gm7YD4QKXpjkeP24qIe4c9lZwfY3nxtpbjzfaYwOFigY98EvfjmRS+eGRrQu lWJOGHvR31ihJ7olaWGfshGFbPSh0PiEBhJJzJq00iuH/Yguq+hYgW60J0CIh0n7N+oUIGg3o80x y2R5gADETJiqhTzFC4monspsBilSqACDc3rWrXDkpKpBSmx52BiFClRCE4oJIleA1Jp0tKN/2dBL UapbPzjlJH9h0Fz7Mw+tVpFFHH2QFEL04hchgpIxyigQt1pRDwOhsSlxUEn/oA8rLmighS0MGv8g BbQ2BbYJkYIGggNNRLqQkkSsxj16wAeF9PCseuihjfD5RynyAKl+FEhJDuqfDSOZJF097k8TmkEm HQMzhnBnTZ/s0c5IOSsZzkmSmKpLHmZ5njhdkR6WpBB73jWhLobmdGlrSFTmtyM9FA6KgdDfDKOk h6O4chUhi5s/0qkghW387l3506UX70HPBy4kdIhYjSudcIAkGYh27sEbIDrmp/mELFnQU8cPSRGp a/kDGpfcZV4owo/YfEM8VbhHhfxVCjcl60HQsFCSShGy+jgUT/jZmwoqpC6HzgWPQwRNVxBDj9rs iEZZC1n/SoGaBMlph0+6D0rLeEEVnNJJL3xpTB1zKHsqJBB1QWIryoisunQUkj5dJoWopyC9BWqV NHSkWBOGSS9C5ClvEQrjoJFKhMbpZu2ZyyqqsNKFdZRSmaqf1wpmV4GazAlBEQoiSEfYKzhVbT9p DRJrkxSVrMk6V7DCeiS0xSt9KlCf89fWHOQey4WnOK6LnXPoNYPD+xqEngeYgRDJx9rWunZNkQrp VjfXwhdaEpIPetMiZ/tCaECjdu/hx35mapF7pFaPovkGryxURYRSsIxTg9V8HEme8XTUuqTQQ9YQ IUQUbtIfyPUk/t56y84N6oKIzF2cmtTXLllyZx0NRGB0EpGKhle5MsJpVWU0NHbF0a10dELWOBo2 +czouk6bLwtMexBO3te5h6QttrwEiCo4qaczykMVeBqh8ZjnXS3NLCtaERh7RYQ3962PeJoEKXj1 94JVwJogFfSHKtTtT3dDJ+QmNB5ABeZQErlHeOV6V41W97dDS5iFEUwtG2OvcnfiL16n1ArSMjgh DjZhEh1H+ylRdvRxFBSP5zRLKVJgDz8TgpuMEqaHVUCSxIRJIYBCI14ud3TAZx4aJDt856w5N1TN 1ZQVqPePVowpzhGZM2g82R6OrshvyQpzcaw7YLf2imE9yq52yTOX+WJnIv6oWMuUC6cJ5fRBLn2u jjJbXSDRyEkW0kObpSWefsDZC4iiyKEXjV9/DNSj9gHcpDeqNUdWOGvMlVbI3iW2+WbzIfeox1JH fa1S4ONmnJ0g0cQj6+pG00Dexu27QlZln/QSMaJOiyfvpodBP1PbgpIl7eDl7XpLuD6I0MHpVEeR p9SGsIrTSv8GPeCUdmlHpBIUfXIrn+qyAsli/ltk6XBdz4pYoR/6GmwXZtYTGmz840gsSbDWBBTB NnbjIhe5ShQLFN4oryJGoYF3kDg+9a0PfapdrcxpoNqep28GPneta+llL5vfXObkQ9tHjHc6FgQn fciNemJPhZdDAaBwNkkU2tQHdKnnZetYuUtM3dd00+WaLYiqx+nqcVyeA4XnM2DBroEi9yGyQO6E M+4BriM+GvRk11evZ961kyjjrh11Y9q32k83JvOlbvGKR13hUVePaO+d6ErHx5V7wxu9X70gxlV7 PbAuEHomJG31YIEXWEB6IjnEqabviNwB4PraK6Tyts99bwICACH5BAUKAPgALAAAAABdAEYABwj8 APEJHEiwoMGDCBMqXMiwocOHECNKnEix4b18+awItBIoX8WPIBWySigoUaJW/vwlEpQvUCCNBF12 DOQvpE2Fgf55OWglkZefQL0gMunFisZ8/f6ZHJroptOCVlJ6mXGQFaKgWH+2QukvK4unT5Hq/InP qJV8gPj9u5q1bVuwTq386xp0a0qVbvNmpQo3ZL6xblt5gaC3MNmyMPtK/Ks3ESIdhgvT4JcyUUfF Cc1mNJqzMSIakUMDRXQZM8G7qFMiWs2aaSK8rVc7jt16aWyTuGffMz0wEFZEKBHxa8WKONfU/lgV X668OPLUx/2xnbqbN758iSBo14HI38xV+/36sQL/r3x5eqwAgffXb5X7VerKP3+ej4X2A9YF5qOr lV++PIAkNVcppPRDz1395HEPK/KtQgopq8iXUngUViheP4OBxld+PgHVCiKA6FHKef6UokeBE+pR Tx70zKXOKoD8QYo/c7F3YXM3KicIaIflx890xJUCCI13pafHequoUA+DB6ZEyh9/rEKPOuw1xwo/ yq2C41RBkaYYR5ThpRUrpTCYGikAoulEPXr802RKq0BJCiviKdcPllZeeacXPAI1A35gLejPh10m R15q/OSh6JpORJgaK4rK+EceBWKJZ3NYriLIDFklFlcg09XFz3oItqeCoqjCh+B4+07kAaWirNBT Z55XssJnW6uVBpJYHRY63oN6oJqHEwC0GikpQr467IpQyhjfrLTa2mdWq1X3kVSBkQmIE9x2W4+x k7o67LDdOgFlgOaFp9ylte5YGKAfKZWXoYAAUsq9BMaI6qQyvrdKslBG+I86VKpLK4bTtnUWSNLl RZx7NJpHD4yuBgvIjOa52U+MUbpZqpX84HlrYYl46hFE8uJqKI1vpqSoHn/oAQiTqTWbFJUTQlsn P1xGJpyZ1ibUUiBqhYrVw0m1nGQepTionptvrtLqzAPnbGeteAoCmWg/HQAvQo4SpdfD8DUZXh71 AEIPeg/2g3M//gCyor1a+1IIcp7ucn1APQvlpBJurOWGm6EQ5kwK30T6Q4p6CEqtwrlRFjyqls1R fhXgrtk2AwAAHND5Qn99OB9y/7R3MZ3JrSkwlQ7OWSXaaT4oH6R54OOFID/hHhoLAKiAzwFB8zSo F6+NjujiFxMIe4uoCQlhKXmooALja8uXoAoH2KeddjR0TwME3ocPAe8QAaJTdxPSaWGFpQgUIiCK Su9ozjD+Ab8Tjwu8Co3qnJ3HdkCBzNbcwrvgga4r6LMRP6BVq1KsCUD1ChasapSzSB0rPvDbn+Ki 5wQIDDA0NFjM+RDELhxhqV50glG96tW0ezktDwCAYL3gM67FLcpc++Dj2k9O9pD9CKVIIFOUesJD mX+wIjnIi6Cw8OeEFS4uQnFSlrkulkMdbqghLelK8Qy2QH7gb0Z1ag+llLNCJQoree55kD/o8aR6 2Q9C6qgi167IkKj4BH2zEo8XmSYeykUvQPSA38UedLF6Fa48L2JQgmJnr/jQ4IOiiQioiAentCiH FHqIoRnR1qjSKWp/VWudwN40F9g9iECloJEHdbhDiGCHkumxF5qiN716LfFpT+SfxhZnJifN6Q8q cELh/OGgpDxSh5z7WkNs1R0y2dAJ+IDgg5JoSDuVJzx3aRrLUndDqg2sH8jyxzG5tpt7GFAhP0If KxYns+TB/O0uTlth08STBw2yp0U1IoWxXFWK+FSNQKsYZyQnwg+TVLKQyJLY2kpURjNqEJuoQRaB 2oZIOCFLjrtbzN/8wQ9DTnN+EaXUNOEHICJRCDXhaV0pWoSzlBAoYYb50zkTEogD/XAVgXCPeLRJ weREEzzrXNycrGc3G/UDehCSEIWEJNDQQCQqcxkcnho0p5b2Qw8qGNFcgoqxnC3QqBujFHjsNp7a /cQ2gkurSfIxU4P0hC2suZ1tcCcIQawGdzOYAXAO1B6KgnVddGLFpKa5uGaNCxHKYU9y1DUr9iQi H9RxiAruwQIWfG97mM2sZilpUTjWSI9WIkU0CdvQQfs2LVrjUV8/EHGA8T3EnAfgFCt/+NlT2g1a JJ0esva3tin1dbc6jZj13tMKD4ZQkvzhWvFsJNR87W9WsxwkfM4zpRcRtmn+dBPBjtq04vboIQWd 7WvmQk985Atds3LQeACKyIIR8w9N+9fqJkTM3XrXCyxo60EC0Svl0ktBlHLhNRt7IAeBkr60OyIx QfkmcDJtFd6lgTIZQlnxtuJfErSteaqk2r6WaUoTap/aNIbdt63ikzglzJ8kcg/x+qNg/9ptRdOn p/a40G2vywP/WAeegqUHHxDCqYb0S1OjGWa8DRIwBQ2mvqDOMzyi1WqRIAblTwaWMEWZiA/96/sx YtpLQAjicAoBFF8hKSpxE/LXLEshoPvuRCJR0eF47wK/MnWZiJiCHpDxhckjVc2oBkZe0xDZij7x TSINE82c24MPuiVWzM0RknrG46+H2i2D/tpmdrpGZIRYQbahWTQg9nwvMzGwORFrT6X/da/FNbrS zBsUlifskAOoAKZ5ec2BROtoKZH3TjujU5cX/J6RrnDVN1MJj3ioZSO7pXgntoKdM5YSOpUQosmJ 76rfYyBZgXKrNODc5yhiR7WmFSXaglCsP4upK2EJ2zCqm7q4LTEqkcgn5jRnRayw2p8MJS93BYpd aVPXgtvV4AX3Qj7qOhvSQHbgB2dNXcV/ou+P5KPQ2iFeZWcQPvFBIK8cpwHHMXtZzW6ve5mlASJm YNmOew+zwAvJPcTNAuB0b7Y4B4pPVumWP3HuKbthQWxFDuqct0XoRT/ryH7CO86xYHMxh0s97uG5 zsWWT0Un+tOPznGgbNxz2GMBn7JHg5WAGgBTNyf2Oi3zgVS9Hp3jlLjhHnc+SbgedJ97PeB1j71P fe8j81p+KCwQr417IFRHO9oJUvGDfK0eYmfBoQcPkXM2niJPBwDlN8+QqXP+8/kJCAA7 ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <0e9b01be9623$5fc32980$fc66a8c0@guzman> R0lGODlhNgAhAPcAAABjtQBjvQBrvQBrxgBzrQBztQBzvQBzxgB7tRB7tSmMtTmMtUqMtVKMtVqU tWOUtXOUtXOctYSctYSltYyltZSlvZStvbW9tb3OzsbOxsbe587Ovc7Oxs7e59ZaANZaStaUjNac jNalnNa1pda9rda9tdbWxtbeztbe1tbn594YAN4YMd45Kd5CKd5jAN5jId5jMd69td7Oxt7Wvd7e xt7ezt7e1t7n1ucAAOcIAOcYAOchAOcpAOcxAOc5AOdCAOdKAOdKGOdSEOdaAOdaIedaKefexufn xufnzufn1ufn3ufv3u8AAO8QAO9KGO9SIe9SKe+EhO/nzu/n3u/35/cAAPcACPcAEPcAKfcQKfcY MfchQvcpSvcxUvdCUvdSY/daa/dje/drc/fO1vfe3vfn3vfv3vfv5/f33vf35/f37/f/5//e1v/n 3v/35//37////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAHAALAAAAAA2ACEA QAj+AKUIlILkiBEjSGbQMDJDYUOFJmjQiEhxoomLGE1gsEChwoQJEiI8GNmAwQKTChAwqcKS5UqX MFd6OfPGzZo1b27i3KnzZgYMVOAIHUq0qI6YLV9WUXqFTc43OdcoMVG0qtWrcH60dMmCxBSsYMOK HUu2LNmVStEmTQqmjc6nOKNG1dlhwAADdgcEIEDhAoobS6hQMUPl6FKYiGFqKQP3bdQlJpaYLcpj 6+HDaZmsKGFCyWSzQ3CMMPO59Ngml9cmfRnmTM/XsG9qCCAgQAC9twXUHqDbdoAciNWmXvrF7U24 c9+omdvhgAAAFVAEBWs48cvrVbiUebtT7s4aKEr+A0+rGiYWxo5xpqlRwzTRHeW3prVCJmqSE57d W+UhXL4KEDJIpp9ZWi31gQmkDTjgBgkq6CAcLsDwwgswFEFhEUIE8QQRUDgRBA9RTIGGGSOmsYYZ a6CBhokomoiGBrzxpptevdXWWwCoYbYWdlWI4RpPsa1h0011BWDAbbzdZlsBBCSwgAMQNMGjamoV FyRsUdUlAG8FSIBBflah1t9lwnlhXE+NcbdGCgFIIN1Y/KVGnlJdbLeGGtwltxxkYJJ1lHBKJbbF dkOmiZMZ+JkGnHU7spQFG3nOpcQJAy4q36UuYQFpdzhR0ZmDllo23EpY1BfVejY8KFRlo4ra0hg+ ayTBwQ2qEtXDcJYxgQMLIXAgYK1V+VAeEy2M0CewWAGxFQ4iJIGsWcriAMIUpDX4rFgexGDttWVt y21ZAQEAOw== ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <0e9e01be9623$5fe4bb40$fc66a8c0@guzman> R0lGODlhvQEBALMAAJkAAP/MAACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwHoAwAh+QQALAEAACwAAAAAvQEBAEMEHBDISau9N+jNu/9gKI5k aZ5oqq5s675wLM80FwEAIfkEACwBAAAsAAAAACMAAQBDBAdQyEmrvTcCADs= ------=_NextPart_000_0ECE_01BE9634.9BB5C7C0-- From rem-conf Wed May 05 03:19:16 1999 From rem-conf-request@es.net Wed May 05 03:19:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10eyjI-0006Jj-00; Wed, 5 May 1999 03:16:40 -0700 Received: from relay-0.ziplink.net (ziplink.net) [206.15.168.49] by mail1.es.net with esmtp (Exim 1.81 #2) id 10eyjH-0006JZ-00; Wed, 5 May 1999 03:16:39 -0700 Received: from tony (bay1-315.la.ziplink.net [208.196.122.76]) by ziplink.net (8.8.7/8.8.7) with SMTP id GAA09946 for rem-conf@es.net; Wed, 5 May 1999 06:16:36 -0400 (EDT) Date: Wed, 5 May 1999 06:16:36 -0400 (EDT) From: Joevarco@directnomail.com Message-Id: <199905051016.GAA09946@ziplink.net> To: Subject: Special Password Access for Tracker X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list TOP NOTCH INVESTMENTS FIND OUT YOURSELF HOW FAST A $2.50 PER SHARE STOCK CAN GO TO $30.00? !! First Worldwide Vehicle Recovery Company utilizing Satellite, Wireless technology & the internet plans to go Public 1999. PRIVATE PLACEMENT INVESTORS WANTED FOR RARE OPPORTUNITY. Exclusive information is available for you at www.finalimpact.com/tracker call me TOLL FREE 1- 877 435-1700 to Receive Your Special Password Access for Tracker International. Respectively, Joseph P. Varco II JOVARCO WIRELESS You need to be aware, this is neither an offer to sell securities nor the solicitation of an offer to buy securities. TOLL FREE 1 877 435-1700 - REMOVES Do not return a reply to this email, AutoResponders will include you in future subscriber mailings From rem-conf Wed May 05 09:21:41 1999 From rem-conf-request@es.net Wed May 05 09:21:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10f4H2-00024F-00; Wed, 5 May 1999 09:11:52 -0700 Received: from tapti.hss.hns.com [139.85.242.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 10f4Gm-00023U-00; Wed, 5 May 1999 09:11:39 -0700 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id WAA06314 for ; Wed, 5 May 1999 22:37:31 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256768.00582CD3 ; Wed, 5 May 1999 21:33:06 +0530 X-Lotus-FromDomain: HSS From: htejwani@hss.hns.com To: htejwani@ieee.org Message-ID: <65256768.00582962.51@sandesh.hss.hns.com> Date: Wed, 5 May 1999 21:33:59 +0530 Subject: Call for Papers and Participation in ADCOM-99 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend, ADCOM-99, the International Conference on Advanced Computing and Communications is being held at University of Roorkee Campus, Roorkee from 20-22 Dec '99. ADCOM-99 is being organized by Advanced Computing and Communications Society (ACS), India, along with University of Roorkee. It is co-sponsored by IEEE Computer Society, USA and is supported by C-DAC, India and Hughes Software Systems. Attached along with this mail is the Call For Papers and Participation Document along with other relevant details. We encourage you to actively participate in this prestigious Conference, which has become a premier forum of technical interaction over the years. And this just might be the last technical feast of this millennium!! The panoramic town of Roorkee is located north of New Delhi, at the foothills of the Himalayas, near to the holy cities of Haridwar, Rishikesh and several famous hill-stations. Please contact me or Dr. Ravi Mittal (rmittal@hss.hns.com) regarding any queries you might have. Cheers ! Harish Tejwani Member, Organizing Committee ADCOM-99 ----------------------------------------------------- SECOND CALL FOR PAPERS AND PARTICIPATION ADCOM-99 7th International Conference on Advanced Computing and Communications December 20-22, 1999 ROORKEE UNIVERSITY CAMPUS, ROORKEE, INDIA http://www.cse.psu.edu/adcom99 ORGANSIED BY Advanced Computing and Communications Society (ACS), India. Roorkee University CO-SPONSORED BY IEEE Computer Society, USA WITH SUPPORT FROM Centre for Development of Advanced Computing, India Hughes Software Systems, India ABOUT THE CONFERENCE The goal of the annual conference of ACS is to provide a forum to industry professionals, researchers and Government policy planners to share ideas, report findings, discuss products and define future directions. Over the past six years this conference has become one of the premium forums for the growing technical community in India. We commit to build on this success and increase the influence of ADCOM. The conference will have sessions with contributed papers, invited talks, practical experience reports, tutorial, panels, and vendor exhibitions. CALL FOR PAPERS Topics of interest include, but are not limited to: * Wireless and Personal Communications * High Speed Networks * Mobile Computing * Parallel, Distributed and Networked Computing * Advanced Computer Architecture * Dependable and Secure Computing * Real Time Computing * Multi-media Systems * High Performance Graphics, Visualization and Virtual Reality * Parallel and Distributed Databases and Data Warehousing * Web-based Computing * Applications of Advanced Computing in Scientific and Engineering Computations * Business Computing, Web and Governance Authors are requested to submit five copies of previously unpublished papers/experience reports to Program Chairs before May 30, 1999. The length is limited to 5000 words (20 double spaced pages). Authors will be notified of acceptance by July 30, 1999. Camera ready papers would be required by September 15, 1999. TUTORIALS Half day/full day tutorials are proposed to be held on the first day of the conference. Tutorial proposals on topics of interest to advanced computing and Communications are welcome. Please submit your proposals to the Tutorial Chairs by June 30, 1999. SPECIAL SESSIONS Proposals for organizing special sessions in some particular topics consisting of invite talks from eminent persons in the field are also welcome. Persons/industries interested in organizing such sessions are requested to contact the Program Chairs before June 30, 1999. EXHIBITION The conference provides opportunity to vendors of Computing and Communications Systems to display their products. In addition, a few sessions on vendor Presentations are planned. Vendors interested in exhibiting their products are requested to contact the Organizing Chairs before June 30, 1999. ADVISORY CHAIR N.C. Nigam Vice Chancellor, University of Roorkee GENERAL CHAIRS Dharma P. Agrawal University of Cincinnati PO Box 210030 Cincinnati, OH 45221-0030, USA Phone: +513-556-4756 Fax: +513-556-7326 Email:dpa@ece.uc.edu R. K. Arora Centre for Development of Advanced Computing Pune University Campus, Ganesh Khind Pune - 411007, India Phone: +91-20-355393 Fax: +91-20-357551 Email:rkarora@cdac.ernet.in PROGRAM CHAIRS Chita R. Das 232, Ponda Laboratory Dept. of Computer Science and Engineering Pennsylvania State University, University park, PA 16802, USA Phone: +814-865-0194 Fax: +814-865-3176 Email: das@cse.psu.edu R.C. Joshi Dept. of Electronics and Computer Engineering University of Roorkee, Roorkee, UP Phone:+91-1332-85701, 85235 (Off), 70040 (H) Fax: +91-1332-73560 Email:enadc@rurkiu.ernet.in ORGANIZING CHAIRS Kumkum Garg Dept. of Electronics and Computer engineering University of Roorkee, Roorkee, UP Phone: +91-1332-85701, 85235 Fax:+91-1332-73560 Email: eandc@rurkiu.ernet.in Ravi Mittal Hughes software Systems Electronics City, Plot 31, Sector 18 Gurgaon 122015 Tel : +91-124-346666 Ext. 2158 Fax: +91-124-343723 Email: rmittal@hss.hns.com TUTORIAL CHAIRS P. Mahapatra Dept. of Electrical & Computer Engineering 201, Cover Hall Iowa State University Ames, Iowa 50011 Phone: (515)-294-3959 Fax: (515)-294-8432 Email: prasant@ee.iastate.edu A. K. Sarje Dept. of Electronics and Computer Engineering University of Roorkee, Roorkee, uP Phone:+91-1332-65650, 65235 Fax: +91-1332-73560 Email: eandc@rurkiu.ernet.in PUBLICITY CHAIRS Rajeev Shorey IBM Solutions Research Center Block I, Indian Institute of Technology Hauz Khas, New Delhi - 110016 Email:srajeev@in.ibm.com Anand Sivasubramaniam Computer Science and Engineering The Pennsylvania State University University Park, PA 16802 Phone: 814-865-1406 Fax: 814-865-3176 Email: anand@cse.psu.edu ADVISORY COMMITTEE Alok Aggarwal (IBM Solutions Research Center) Dharma P. Agrawal (University of Cincinnati) Vijay P. Bhatkar (ETH. Inc, Pune) Laxmi N. Bhuyan (Texas A&M, USA) V. Chandrasekharan (Pentafour, Madras) Ajai Chowdhry (HCL Technologies) Ashok Desai, (Silicon Graphics, India) Sudhir Dixit (Nokia Telecommunication, USA) K. N. Gupta (CDOT, India) Ahsok Jhunjhunwala (IIT Madras) Michiko Hashimoto (ATM Forum Asia-Pacific Office, Tokyo) David Kahaner (ATIP Japan) Kannan Kasturi (Hughes Software Systems, Gurgaon) S. Sasi Kumar, (NIIT Bangalore) Rajeev C. Mody (Silicon Automation Systems) N. R. Narayana Murthy (Infosys Tech) S. Nagarajan (Philips Software Centre, Bangalore) Amitava Roy (HCL Technologies, Noida) D. Raychaudhuri (NEC C&C Research Laboratories) L. M. Patnaik (IISc Bangalore) S. Prasad (DRDO, Delhi) S. K. Sinha (IISc Bangalore) Arun Somani (IOWA State Univ) R. Srinivasan (Tata Elxsi) S. P. Sukhatme(IIT MUmbai) Vinod Sood (Hughes Software Systems, Gurgaon) Krishna Tanuku (Lucent Technologies, Bangalore) Kishor Trivedi (Duke University) PROGRAM COMMITTEE P. C. P. Bhatt, Kochi University of Technology, Japan K. K. Biswas (IIT Delhi) P. K. Chande (GSTI, Indore) H. M. Gupta (IIT Delhi) T. V. Geetha (Anna Univ) Timothy Gonsalves (IIT Madras) R. K. Ghosh, IIT Kanpur D. Janaki Ram (IIT Madras) Matthew T. Jacob, (IISc Bangalore) Abhay Karandikar (IIT Mumbai) S. C. Kothari, Iowa State University, USA Anup Kumar, University of Louisville, USA Suresh Kumar (IBM Solutions Research Center, India) Vipin Kumar, University of Minnesota, USA G. Manimaran, Iowa State University, USA S. L. Mehndiratta, IIT Bombay Deependra Moitra (Lucent Technologies) Vijay Narayan, Penn State University, USA S. Nandi (IIT Guwahati) Hyunmin Park, Myongji University, South Korea Girish Pathak, GTE, US P. S. Nagendra Rao (IISc) V. Ranganathan (PSG, Coimbatore) P. Raveendran (Univ of Malya) S. Sanyal, TIFR, Mumbai Pradeep K. Sinha (CDAC Pune) Dheeraj Sanghi (IIT Kanpur) Rajeev Sharma, Penn State University, USA Harpreet Singh, Wayne State University, USA Nitin Vaidya. Texas A&M, USA Vimal Singh (M. N. R. Engg College, Allahabad) Anand Sivasubramaniam, Penn State, USA ORGANIZING COMMITTEE P. K. Bansal (TIET Patiala) K. D. Singh (Univ of Roorkee) Harish Tejwani (Hughes Software Systems) IMPORTANT DATES Paper Submission: May 30, 1999 Proposal for Tutorials: June 30, 1999 Proposal for Special Sessions:June 30, 1999 Camera Ready Submission: Sept. 30, 1999 REGISTRATION FEES Regular Participants: Rs. 3000 Academic Institutes, Govt. R&D Labs: Rs. 2000 Students: Rs. 600 Foreign participants: US $120 The corresponding author need to submit the completed submission-form with the paper. ABOUT ROORKEE Roorkee is about 200 Kms from Delhi and about 30 Kms from the Holy City of Haridwar. Roorkee is on the Delhi-Haridwar-Rishikesh-Dehradun national highway. Roorkee houses University of Roorkee, one of the oldest and premier engineering Universities in India. Roorkee is also a center for research and Defence Establishments. There are many tourist attractions near Roorkee. From Roorkee, you may visit the holy cities of Haridwar, Rishikesh, Kedarnath, Badrinath, and many scenic places in Gadhwal and Himalaya Regions. Hill stations, namely Dehradun and Mussoorie are close to Roorkee. The weather at Roorkee in the month of December is cold with temperature ranging from 5 to 15 degree celsius. ADVANCED COMPUTING AND COMMUNICATIONS SOCIETY Chair : Lawrence Jenkins (IISc Bangalore) Vice Chair : K.M. Mehata (Anna University) Secretary : P.S. Nagendra Rao (IISc Bangalore) Jt. Secretary: Ravi Mittal (Hughes Software Systems) Treasurer : R.C. Hansdah (IISc Bangalore) ACS is engaged in fostering awareness about recent developments in Computing and Communications Systems. ACS organizes technical seminars, workshops, and conferences. For more information, please contact Prof. P.S. Nagendra Rao, (Secretary ACS), Dept. of Electrical Engineering, Indian Institute of Science, Bangalore - 560012 (Email:psnagendra@ee.uusc.ernet.in) India, or Dr. Ravi Mittal, (Jt. Secretary ACS), Hughes Software Systems, Plot 31, Sector 18, Gurgaon 122015, Haryana (Email:rmittal@hss.hns.com), India --------------------------------- Paper Submission Form ------------------------ -- Paper Title: ..................................... ..................................................... Author(s): ........................................ Corresponding Author: .............................. Title/Degree ........................................ Organization ........................................ Tel.: ................. E-mail: ..................... Mail Address: ..................................................... ..................................................... ..................................................... ..................................................... If the paper is accepted: I will send the final version before deadline (September 30, 1999); I will pay the participation fee and present my paper at ADCOM'99. Date: ................ Signature: .......... Note: In case of Electronic Submission of your paper, please mail or Fax this form to the Program Chair. --------------------End of Paper Submission Form------------------------------------ From rem-conf Wed May 05 20:23:53 1999 From rem-conf-request@es.net Wed May 05 20:23:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fEh0-0000In-00; Wed, 5 May 1999 20:19:22 -0700 Received: from dfssl.exchange.microsoft.com [131.107.88.59] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fEgy-0000Id-00; Wed, 5 May 1999 20:19:21 -0700 Received: by dfssl with Internet Mail Service (5.5.2580.0) id ; Wed, 5 May 1999 20:18:13 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: 'Colin Perkins' , Jonathan Rosenberg Cc: rem-conf@es.net Subject: RE: Usage of SDP with FEC Date: Wed, 5 May 1999 20:18:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > You'd have to include the full semantics of the "c=" field in the "a=fmtp" > attribute, so one could do... > > m=audio 5000 RTP/AVP 0 34 > c=IN IP6 ff15::8 > a=rtpmap:34 parityfec > a=fmtp:34 IN IP6 ff15::10 5002 1 So how would this work when SDP is used with RTSP? In that case, the "c=" field is usually empty, or contains a dummy IP address. IP addresses and port numbers are communicated by means of RTSP SETUP commands instead. SDP only provides the URLs that should be used with each SETUP command. In the above example, the last line would have to be changed to something like this: a=fmtp:34 control:rtsp://server.com/program?fec-stream Is this all right? Anders From rem-conf Wed May 05 23:55:06 1999 From rem-conf-request@es.net Wed May 05 23:55:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fHxx-0002Rc-00; Wed, 5 May 1999 23:49:05 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fHxw-0002RA-00; Wed, 5 May 1999 23:49:04 -0700 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA15872; Wed, 5 May 1999 23:48:01 -0700 (PDT) Date: Wed, 5 May 1999 23:47:45 -0700 (Pacific Daylight Time) From: Stephen Casner To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: Usage of SDP with FEC In-Reply-To: <372CFAFB.8006413E@dnrc.bell-labs.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan, Some comments on your first message in this thread: > 1. You can include multiple c lines, each with a different multicast > address, within a media section. For hierarchical video, each refers to > a different layer. For FEC, we could send two c lines, one referring to > the original media, and one the FEC. However, I could find nothing in > rfc2327 which indicates how a receiver knows which layer is the base, > and which are enhancements. Perhaps the RTP spec should say something about this with respect to layered codings (and potentially for FEC). In Section 10 of draft-ietf-avt-rtp-new-03, the ports are RECOMMENDED to be contiguous and in ascending order with the layers. The original Speer and McCanne draft on layered encodings specified contiguous multicast addresses in ascending order as well, but we decided that we cannot assume contiguous allocation. Nothing is said about order at the moment. We can't strictly specify ascending address order for the layers because some of the layers may get addresses allocated within admin scopes, and those may not nest according to numeric order. Addresses within a scope could be ordered. > Am I missing something in SDP which conveys > this? Is it implicit (first c line = base layer)? It seems reasonable to me to specify this. > We could use this to allow the FEC and audio on separate ports. But, > this mechanism only allows the audio and FEC on consecutive (consecutive > even, to be precise) ports. This is somewhat restricive. Do we care? We do accept this restriction for the layered encodings in the RTP spec draft. > As with the address case, which port is the FEC, and which is the audio? We could specify that the media is the lower address, FEC higher. > 3. SDP explicitly says for hierarchical video, there is no way for the > layers to be on different ports AND multicast groups. Again, it would > seem desirable to allow the FEC on a separate address and port. This seems like a problem. The RTP spec says that layered encodings should use different multicast addresses and different ports. > 4. Finally, if we directly use the hierarchical video mechanisms, how > does the recipient of the SDP know that we are talking about this FEC > mechanism, and not hierachical video? What do we do if the session has > BOTH? Yes, this seems like the most significant problem. On the other hand, regarding your second proposal, the need to repeat the c= syntax in fmtp bothers me. I have not figured out another alternative to suggest, though. -- Steve From rem-conf Thu May 06 05:56:23 1999 From rem-conf-request@es.net Thu May 06 05:56:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fNe5-0005We-00; Thu, 6 May 1999 05:52:57 -0700 Received: from galaxy.uci.agh.edu.pl (uci.agh.edu.pl) [149.156.96.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10fNds-0005WP-00; Thu, 6 May 1999 05:52:44 -0700 Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id OAA13247; Thu, 6 May 1999 14:49:22 +0200 (MET DST) Received: from madzia.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA28217; Thu, 6 May 1999 14:46:16 +0200 Received: by madzia.kt.agh.edu.pl (SMI-8.6/SMI-SVR4) id OAA08782; Thu, 6 May 1999 14:46:05 +0200 Date: Thu, 6 May 1999 14:46:05 +0200 From: pach@saturn.kt.agh.edu.pl (Andrzej Pach) Message-Id: <199905061246.OAA08782@madzia.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: opensig-announce@ctr.columbia.edu Subject: Broadband Access Conference (BAC'99), Poland: Submission deadline reminder - May 17 Cc: osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am sorry if you receive more than one copy of this e-mail! ============================================================ Announcement and Call for Papers BROADBAND ACCESS CONFERENCE (BAC99) Cracow, Poland, October 11-13, 1999 http://BAC99.kt.agh.edu.pl/ Sponsored by IEEE Poland Section and Cracow Communications Society Chapter Rapidly growing demand for Internet resources access and emerging broadband interactive applications attracts telecom operators' and service providers' attention to access technologies: copper (xDSL), fibre (FTTx) and wireles (WLL). The conference addresses a full spectrum of issues related to a residential access - from signal level, through network architectures and their life cycle costs up to live field trial description. The conference will help incumbent operators to determine their own technology migration path to the broadband forefront that will match their current status and prospected market niches. The conference programme is organised in three streamed sessions: * Digital Subscriber Line * Fibre in the Loop * Wireless Solutions Submitted extended abstracts will undergo three independent reviews and accepted papers will appear in the conference proceedings. Tutorials ========= Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise of the instructors, and on the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the BAC99 chairs. IMPORTANT DATES =============== * Submission of extended abstracts (max. 5 pages) due: May 17, 1999 * Authors notified: June 30, 1999 * Full paper camera ready due: September 10, 1999 SUBMISSION / REGISTRATION ========================= Submit extended abstracts by e_mail to one of the BAC99 chairs. For registration and general information contact a chair of the BAC99 organising Committee, dr Artur Lason. CONFERENCE COMMITTEE ==================== CONFERENCE CHAIRS Prof. Andrzej R. PACH General Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: pach@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 Prof. Zdzislaw PAPIR Program Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: papir@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 TECHNICAL PROGRAM COMMITTEE =========================== N.E. ANDERSEN, DSC Communications, Denmark K. ASATANI, Univ. Kogakuin, Japan A. AZCORRA, Univ. Carlos III of Madrid, Spain D. BEM, Wroclaw Univ. Of Technology, Poland W. Y. CHEN, Motorola, USA A. CIZMAR, Univ. Kosice, Slovakia A. DOBROGOWSKI, Poznan Univ. of Technology, Poland A. DZIECH, AGH Cracow Univ., Poland A.L. EKBLAD, Telia, Sweden U. FERRERO, CSELT, Italy K.-P. HO, Chinese Univ., Hong Kong A. JAJSZCZYK, ITTI Ltd. And ATR, Poland T. KESSLER, Deutsche Telecom, Germany K. KIKUSHIMA, NTT, Japan S. KUMAR, Ericsson, USA B. ORTH, Deutsche Telekom, Germany K. PAHLAVAN, Worcester Pol., USA T. POLLET, Bell Alcatel, Belgium M. POUSA, CET, Portugal S. SAY, Next Level Commun., USA A. SIMMONDS, Sheffield Hallam Univ., UK P. SPRUYT, Bell Alcatel, Belgium R. VALADAS, Univ. Aveiro, Portugal M. YANO, Fujitsu, Japan ORGANISING COMMITTEE ==================== Chair: Dr. Artur LASON Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: lason@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 From rem-conf Thu May 06 07:09:32 1999 From rem-conf-request@es.net Thu May 06 07:09:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fOmt-0006l8-00; Thu, 6 May 1999 07:06:07 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10fOms-0006ky-00; Thu, 6 May 1999 07:06:06 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu May 6 10:06:00 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.249]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA04386; Thu, 6 May 1999 10:05:58 -0400 (EDT) Message-ID: <3731A1D3.EAEBB924@dnrc.bell-labs.com> Date: Thu, 06 May 1999 10:06:11 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Usage of SDP with FEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > > > 1. You can include multiple c lines, each with a different multicast > > address, within a media section. For hierarchical video, each refers to > > a different layer. For FEC, we could send two c lines, one referring to > > the original media, and one the FEC. However, I could find nothing in > > rfc2327 which indicates how a receiver knows which layer is the base, > > and which are enhancements. > > Perhaps the RTP spec should say something about this with respect to > layered codings (and potentially for FEC). In Section 10 of > draft-ietf-avt-rtp-new-03, the ports are RECOMMENDED to be contiguous > and in ascending order with the layers. The original Speer and > McCanne draft on layered encodings specified contiguous multicast > addresses in ascending order as well, but we decided that we cannot > assume contiguous allocation. Nothing is said about order at the > moment. We can't strictly specify ascending address order for the > layers because some of the layers may get addresses allocated within > admin scopes, and those may not nest according to numeric order. > Addresses within a scope could be ordered. Why would you have hierarchical video with different layers within different scopes? Is this a likely scenario? If not, we could presumably make the rule "lowest address = base layer, increasing addresses = higher layers". > > 3. SDP explicitly says for hierarchical video, there is no way for the > > layers to be on different ports AND multicast groups. Again, it would > > seem desirable to allow the FEC on a separate address and port. > > This seems like a problem. The RTP spec says that layered encodings > should use different multicast addresses and different ports. This would seem hard to fix in the current model for SDP, since the port number is separate from the rest of the c line... > On the other hand, regarding your second proposal, the need to repeat > the c= syntax in fmtp bothers me. I have not figured out another > alternative to suggest, though. What bothers you? I don't think its all that bad... I can reuse my "c=" parser on the a=fmtp line, it conveys the neccesary information, and its backwards compatible. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu May 06 07:44:28 1999 From rem-conf-request@es.net Thu May 06 07:44:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fPLh-0007bF-00; Thu, 6 May 1999 07:42:05 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10fPLf-0007b5-00; Thu, 6 May 1999 07:42:03 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu May 6 10:41:14 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.249]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA05733; Thu, 6 May 1999 10:41:12 -0400 (EDT) Message-ID: <3731AA14.6E1CF794@dnrc.bell-labs.com> Date: Thu, 06 May 1999 10:41:24 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Anders Klemets (Exchange)" CC: "'Colin Perkins'" , rem-conf@es.net Subject: Re: Usage of SDP with FEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Anders Klemets (Exchange) wrote: > > > You'd have to include the full semantics of the "c=" field in the "a=fmtp" > > attribute, so one could do... > > > > m=audio 5000 RTP/AVP 0 34 > > c=IN IP6 ff15::8 > > a=rtpmap:34 parityfec > > a=fmtp:34 IN IP6 ff15::10 5002 1 > > So how would this work when SDP is used with RTSP? In that case, the "c=" > field is usually empty, or contains a dummy IP address. IP addresses and > port numbers are communicated by means of RTSP SETUP commands instead. SDP > only provides the URLs that should be used with each SETUP command. > > In the above example, the last line would have to be changed to something > like this: > > a=fmtp:34 control:rtsp://server.com/program?fec-stream This is really ugly... If the c line is normally empty, where do you put the URL for normal non-FEC usage (I'm not familiar with SDP usage in RTSP)? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu May 06 12:08:02 1999 From rem-conf-request@es.net Thu May 06 12:07:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fTN3-0002xR-00; Thu, 6 May 1999 11:59:45 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fTN2-0002vY-00; Thu, 6 May 1999 11:59:45 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 6 May 1999 11:58:43 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: 'Jonathan Rosenberg' Cc: 'Colin Perkins' , rem-conf@es.net Subject: RE: Usage of SDP with FEC Date: Thu, 6 May 1999 11:58:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > a=fmtp:34 control:rtsp://server.com/program?fec-stream > > This is really ugly... If the c line is normally empty, where do you put > the URL for normal non-FEC usage (I'm not familiar with SDP usage in > RTSP)? A little ugly, but probably consistent with current SDP usage and semantics. The RTSP URLs a placed in an attribute called "control". Like this, for example: a=control:rtsp//server.com/program/stream=A The SDP syntax allows for multiple "a=control" fields in the same SDP media description, but then there would be no way of knowing which field corresponds to which RTP payload type. This problem is identical to the problem with multiple "c=" fields. So, if we can move the extra "c=" field to the "a=fmtp" field, then I think it would be natural to treat "a=control" fields in a similar manner. Anders From rem-conf Thu May 06 17:56:46 1999 From rem-conf-request@es.net Thu May 06 17:56:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fYsy-00061a-00; Thu, 6 May 1999 17:53:04 -0700 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10fYsx-00061Q-00; Thu, 6 May 1999 17:53:03 -0700 Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA16573 for ; Thu, 6 May 1999 17:50:35 -0700 Message-Id: <3.0.5.32.19990506175130.00a36400@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 May 1999 17:51:30 -0700 To: rem-conf@es.net From: Marty Bickford Subject: Quality of Service Forum Reception and Network Demo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ziggy.stardust.com id RAA16573 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Quality of Service Forum is extending an invitation to join us at the Quality of Service Forum Networking Reception. The highlights of the reception will include the QoS Network Showcase demonstration and a great networking opportunity. QOSF Reception and QoS Network Showcase --------------------------------------- ~ QoS Network Showcase demonstration. We'll demonstrate end-to-end QoS capabilities in an extensive IP network. You'll see the difference betwee= n QoS and non-QoS impact on numerous application categories and via empiric= al measurement tools that graphically show the traffic impact of QoS capabilities. This network reveals current vendor support and interoperability between emerging products which support new QoS protocol= s. Network: http://www.stardust.com/iband2/network.jpg Description: http://www.stardust.com/iband2/qos-showcase.htm ~ Great networking opportunity to meet with QOSF members and non-members, ISP's, IP network engineers and the press. You'll learn how the Quality o= f Service Forum is playing an important role in the adoption of QoS. ~ Qosnetics will sponsor the QOSF Reception which will be held in concert with the QOS NetworkShowcase demonstration. You are invited to attend. ~ Participating companies include: 3Com, Abatis, Cisco Systems, Extreme, Fujitsu, IBM, Intel, IP Highway, IPivot, Lucent, Microsoft, Nortel, Novel= l, Orchestream, Qosnetics, Xedia, and NetCom Systems. Logistics --------- Where: San Francisco Airport Marriott (in coordination with iBAND2).=20 Signs will assist you to the meeting location. When: Sunday May 23, 1999 from 6:30pm - 7:30pm RSVP: Please RSVP to Sherryl Alameda by May 19th. sherryla@stardust.com iBAND2 - May 23-25, 1999. San Francisco --------------------------------------- The Quality of Service Forum is an Association Sponsor of iBAND2. iBAND2 is targeted at IP Network Professionals in enterprise, service provider and carrier organizations. At the heart of the event is a 3-trac= k conference in which the industry=92s leading technologists and business pioneers give leading edge sessions on the technology, deployment and business of smart bandwidth solutions. We encourage you to sign-up today at http://www.stardust.com/iband2/ Nortel Networks is the Platinum Sponsor, Intel and NetCom Systems are Gol= d Sponsors, the IP Multicast Initiative & the Quality of Service Forum are Alliance Sponsors, and America's Network, Data Communications, InternetWe= ek and tele.com are Publication Sponsors of iBAND2. Sincerely, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND2(sm) - The Internet Bandwidth Management Summit From rem-conf Thu May 06 18:37:45 1999 From rem-conf-request@es.net Thu May 06 18:37:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fZYd-00077H-00; Thu, 6 May 1999 18:36:07 -0700 Received: from (dthaler.microsoft.com) [131.107.1.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fZYb-00076r-00; Thu, 6 May 1999 18:36:06 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id UAA24987; Thu, 6 May 1999 20:22:22 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905070322.UAA24987@dthaler.microsoft.com> Subject: Review of draft-ietf-avt-mib-05.txt To: rem-conf@es.net Date: Thu, 6 May 1999 20:22:06 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Some high-level (hopefully constructive) criticisms in this message, I'll save details/nitpicks for after these have been discussed. Disclaimer: I haven't been following the AVT mailing list, and don't claim to understand the details of RTP. So if anything below would be obvious to someone familiar with RTP, then the draft may be just fine. That said, I'd like to start right from square one, and talk about the question "What is the purpose of this MIB?" Section 2.2 answers this by saying it's for (a) detecting and (b) diagnosing faults in RTP sessions, as well as for (c) configuring RTP monitors. Since the primary focus is apparently on fault diagnosis, I ask: What are the most important questions you (an NMS) want to ask? (The MIB doesn't say anything about *what* faults or how the objects can actually be used to diagnose any fault.) As an author of the MBone Debugging Handbook, I'll suggest a few strawman faults and questions to focus on, which I believe are important: "Health" fault: some receiver(s) are seeing packet loss, or are even unable to tell that a given source is sending anything. "Utilization/congestion" fault: some sender is sending "too much" data Questions the NMS wants to ask to detect/diagnose the above faults: 1a) What streams is the managed device sourcing? 1b) How much data is it sending on each stream? (Used to diagnose utilization/congestion problems) 2a) What streams is the managed device receiving? 2b) How much data is it receiving on each stream? (Also used to diagnose utilization/congestion problems) 3a) Who are all the sources (that the managed device knows of) to a given session? (Used to diagnose health problems) 3b) How much data is each one sending (utilization/congestion)? 3c) How much loss is the managed device seeing from each one? (health) 4a) Who are all the receivers (that the managed device knows of) to a given session? 4b) How much loss is each one seeing for each source? (health) I could go on for some time explaining why each of the above questions is important to be able to answer. Feel free to suggest other questions. If you agree with the above list of questions, then let's look at whether the MIB is effective or not in doing what it aims to do. (a) Detecting faults in RTP sessions If the NMS wants to detect faults, then it needs to either poll objects that can answer the necessary questions, or receive asynchronous notification. The MIB currently contains no traps, so I ask: should it? (If not, the DISMAN Expression and Event MIBs together might provide a sufficient alternative.) I expect that a NOC may want to poll for example, all of an RTP monitor's rtpRcvrLostPackets and rtpSenderPackets objects, so the MIB does allow answering 4b via polling a potentially huge number of objects. The descriptions of those two objects may want to mention that this is what they're for. However, the MIB should state why rtpRcvrPackets is needed... how is it different from rtpSenderPackets-rtpRcvrLostPackets? Likewise, 3b can be answered by polling rtpSenderOctets, so I think the MIB is fine here. (b) Diagnosing faults in RTP sessions I'll cover all the other questions here. 1a) I don't see any good way to answer this question without walking the entire rtpSenderTable. This can be very expensive, especially if there are either a bunch of streams the device is receiving-only, or a bunch of other senders to ones it is sending to, so I don't consider this question effectively answered by this MIB. Also, how do you know what SSRC value the managed device is using? 1b) rtpSenderOctets would be fine if you could answer 1a. 2a) It isn't clear to me whether you can discover what sessions the device is receiving by walking the rtpSessionTable, or whether you need to walk the entire rtpRcvrTable. (Does an entry in rtpSessionTable necessarily imply it's receiving RTP and not just RTCP? If not, walking the rtpRcvrTable may be very inefficient.) 2b) I don't see an easy way to answer this question using the rtpRcvrTable. I suppose you'd have to do a GET-NEXT to find the next rtpSessionIndex and rtpRcvsSRCSSRC values, and then a GET for the device's rtpRcvrSSRC value, and repeat until the end of the table. (Again, how do you know what its SSRC value is?) 3a) Source enumeration is fine once you've found the rtpSessionIndex. However, it appears to be impossible to locate the rtpSessionIndex without walking the rtpSessionTable, which could be very inefficient. So I don't consider this question effectively answered either. (3b was covered above) 3c) Finding what loss the device is seeing for a given group/port and source requires you determine the device's SSRC (how?), the source's SSRC (how?), and the rtpSessionIndex for the session (how?). I don't see how you determine any of these three in an efficient manner, but if you could, answering the question can be done with rtpSenderPackets and rtpRcvrLostPackets. 4a) Receiver enumeration is fine once you've found the rtpSessionIndex, as with 3a above. (4b was covered above) In summary, it looks to me like a lot of problems are introduced by the fact that the rtpSessionTable is indexed by an integer instead of by rtpSessionRemAddr and rtpSessionLocAddr (and rtpSessionDomain?). While this has the advantage of supporting other address families, it appears to prevent the MIB from being useful (at least by itself) for its intended purpose. If it's intended that all of the above questions be answered by some other (unmentioned) extension MIB, then I would contend that the purpose of the RTP MIB needs to be rephrased. (c) Configure RTP Monitors It does appear that this goal is adequately met. -Dave Thaler From rem-conf Fri May 07 02:23:09 1999 From rem-conf-request@es.net Fri May 07 02:23:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fghq-0003e7-00; Fri, 7 May 1999 02:14:06 -0700 Received: from olympus.noc.uoa.gr (noc.uoa.gr) [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fghn-0003dv-00; Fri, 7 May 1999 02:14:03 -0700 Received: from kissavos.noc.uoa.gr (kissavos.noc.uoa.gr [195.134.100.101]) by noc.uoa.gr (8.8.8/8.8.8) with ESMTP id MAA24466 for ; Fri, 7 May 1999 12:13:55 +0300 (EET DST) Received: from Aragorn (Aragorn.noc.uoa.gr [195.134.90.37]) by kissavos.noc.uoa.gr (8.8.8+Sun/8.8.8) with SMTP id MAA13314 for ; Fri, 7 May 1999 12:18:48 +0300 (EET DST) Message-ID: <001601be986a$00956a60$255a86c3@Aragorn.noc.uoa.gr> From: "Nikos Laoutaris" To: "Remote conf mailing list" Subject: jitter calculation in RTP Date: Fri, 7 May 1999 12:14:24 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BE9883.2554BA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BE9883.2554BA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I have a question about the impact of lost packets on the jitter = calculation in RTP. RFC1889 states that the formula J=3D J + ( |D(i-1,i)| - J ) / 16 is applied to = consequtive packets, not necessarily in order. Lets say that packet with sequence number i-2 is received correctly, = packet i-1 is lost and packet i is received correctly. Then the big time = gap due to the loss of packet i-1 will contribute a large amount of = jitter. Is that what happens? Shouldn't the protocol skip jitter = calculation when it observes discontinueties in sequence numbers? Thanks Nikos Laoutaris Network Operations Center National and Kapodestrian University of Athens, Greece e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0013_01BE9883.2554BA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
    I have a question = about the=20 impact of lost packets on the jitter calculation in RTP. RFC1889=20 states
that the = formula J=3D J + (=20 |D(i-1,i)| - J ) / 16 is applied to consequtive packets, not necessarily = in=20 order.
Lets say that packet with sequence number i-2 is = received=20 correctly, packet i-1 is lost and packet i is received correctly. Then = the big=20 time gap due to the loss of packet i-1 will contribute a large amount of = jitter.=20 Is that what happens? Shouldn't the protocol skip jitter calculation = when it=20 observes discontinueties in sequence numbers?
 
Thanks
 
Nikos Laoutaris
Network = Operations=20 Center
National and Kapodestrian University of Athens, = Greece
e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0013_01BE9883.2554BA40-- From rem-conf Fri May 07 12:08:19 1999 From rem-conf-request@es.net Fri May 07 12:08:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fpoZ-0001HR-00; Fri, 7 May 1999 11:57:39 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fpoW-0001GK-00; Fri, 7 May 1999 11:57:37 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id PAA04671; Fri, 7 May 1999 15:37:40 -0300 (EST) Date: Fri, 7 May 1999 15:37:40 -0300 (EST) From: "LANOMS'99" Message-Id: <199905071837.PAA04671@lrg.ufsc.br> To: Omar.Elloumi@enst-bretagne.fr, wwlu@ieee.org Subject: IEEE LANOMS99 - Problems with submissions Cc: bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@BBN.COM, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@BBN.COM, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: szh0lc1ZbGoX/DD/Hg8ZmA== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Many authors of papers had problems with the SUBMISSIONS by WEB. IF YOU WISH TO SUBMIT A PAPER TO IEEE LANOMS99, PLEASE, COULD YOU SEND YOUR PAPER (attached) BY EMAIL TO LANOMS99@LRG.UFSC.BR, that we will consider your submission. Despite these problems, THE IEEE LANOMS SUBMISSIONS HAS BEEN A SUCCESS. www.lrg.ufsc.br/~lanoms99 From rem-conf Fri May 07 12:11:46 1999 From rem-conf-request@es.net Fri May 07 12:11:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fpyw-0001Od-00; Fri, 7 May 1999 12:08:22 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fpys-0001NQ-00; Fri, 7 May 1999 12:08:19 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id PAA04798; Fri, 7 May 1999 15:47:56 -0300 (EST) Date: Fri, 7 May 1999 15:47:56 -0300 (EST) From: "LANOMS'99" Message-Id: <199905071847.PAA04798@lrg.ufsc.br> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, commsoft@cc.bellcore.com, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, enternet@BBN.COM, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, kia@usl.edu, multicomm@cc.bellcore.com, osimcast@BBN.COM, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@IEEE.ORG, xtp-relay@cs.concordia.ca, ekpark@cstp.umkc.edu, westphal@lrg.ufsc.br Subject: IEEE LANOMS99 - Problems with submissions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: szh0lc1ZbGoX/DD/Hg8ZmA== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Many authors of papers had problems with the SUBMISSIONS by WEB. IF YOU WISH TO SUBMIT A PAPER TO IEEE LANOMS99, PLEASE, COULD YOU SEND YOUR PAPER (attached) BY EMAIL TO LANOMS99@LRG.UFSC.BR, that we will consider your submission. Despite these problems, THE IEEE LANOMS SUBMISSIONS HAS BEEN A SUCCESS. www.lrg.ufsc.br/~lanoms99 From rem-conf Fri May 07 13:03:47 1999 From rem-conf-request@es.net Fri May 07 13:03:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10fqnT-0003E6-00; Fri, 7 May 1999 13:00:35 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10fqnQ-0003Dh-00; Fri, 7 May 1999 13:00:34 -0700 Received: (from lanoms99@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id QAA05201; Fri, 7 May 1999 16:11:06 -0300 (EST) Date: Fri, 7 May 1999 16:11:06 -0300 (EST) From: "LANOMS'99" Message-Id: <199905071911.QAA05201@lrg.ufsc.br> To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@lrg.ufsc.br Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl Subject: IEEE LANOMS99 - Problems with submissions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: szh0lc1ZbGoX/DD/Hg8ZmA== Many authors of papers had problems with the SUBMISSIONS by WEB. IF YOU WISH TO SUBMIT A PAPER TO IEEE LANOMS99, PLEASE, COULD YOU SEND YOUR PAPER (attached) BY EMAIL TO LANOMS99@LRG.UFSC.BR, that we will consider your submission. Despite these problems, THE IEEE LANOMS SUBMISSIONS HAS BEEN A SUCCESS. www.lrg.ufsc.br/~lanoms99 From rem-conf Mon May 10 06:37:00 1999 From rem-conf-request@es.net Mon May 10 06:36:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10gq1Z-00070Y-00; Mon, 10 May 1999 06:23:13 -0700 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 10gq1X-0006z1-00; Mon, 10 May 1999 06:23:11 -0700 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id 0C25BBEC09 for ; Mon, 10 May 1999 15:22:07 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Tue, 9 Feb 1999 14:33:43 +0100 Message-ID: <01BE5439.31D56410.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "rem-conf@es.net" Subject: Quicktime and DVI/H.261 Date: Tue, 9 Feb 1999 14:33:42 +0100 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 24 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi; I'm trying to experiment recieving feeds from the Mbone with QuickTime. I heard that it does support RTP. Anyway, when I type an address into the Open URL option of the Quicktime player. I get the following message: Couldn't open the URL because a software component needed by the movie could not be found. Have I got the wrong end of the stick here, does Quicktime not support this, according to the documentation it should work with DVI 4:1 and H.261 and H.263 I have tried all the below variations on the theme: 224.2.145.95:56360 224.2.145.95/56360 rtp://224.2.145.95:56360 rtp://224.2.145.95/56360 None of them worked, any ideas? Thanks Chris From rem-conf Mon May 10 10:36:02 1999 From rem-conf-request@es.net Mon May 10 10:36:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10gtl0-00020a-00; Mon, 10 May 1999 10:22:22 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10gtky-00020O-00; Mon, 10 May 1999 10:22:20 -0700 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA25494 for ; Mon, 10 May 1999 17:22:18 GMT Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 May 1999 10:22:17 -0700 Message-ID: From: "Baugher, Mark" To: "'Dave Thaler'" , rem-conf@es.net Subject: RE: Review of draft-ietf-avt-mib-05.txt Date: Mon, 10 May 1999 10:22:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave Pardon our delay in responding. I just moved and lost access to my mail account for a few days. Bill Strahm's wife just had a baby and Irina is preparing for the next SG16 meeting. Thanks for the thoughful comments. I'll try to give a thoughtful response to your points in the next day or so Mark > -----Original Message----- > From: Dave Thaler [mailto:dthaler@dthaler.microsoft.com] > Sent: Thursday, May 06, 1999 8:22 PM > To: rem-conf@es.net > Subject: Review of draft-ietf-avt-mib-05.txt > > > Some high-level (hopefully constructive) criticisms in this message, > I'll save details/nitpicks for after these have been discussed. > > Disclaimer: I haven't been following the AVT mailing list, and don't > claim to understand the details of RTP. So if anything below would > be obvious to someone familiar with RTP, then the draft may be just > fine. > > That said, I'd like to start right from square one, and talk about > the question "What is the purpose of this MIB?" Section 2.2 > answers this by saying it's for (a) detecting and (b) > diagnosing faults > in RTP sessions, as well as for (c) configuring RTP monitors. > > Since the primary focus is apparently on fault diagnosis, I ask: > What are the most important questions you (an NMS) want to ask? > (The MIB doesn't say anything about *what* faults or how the objects > can actually be used to diagnose any fault.) > As an author of the MBone Debugging Handbook, I'll suggest a few > strawman faults and questions to focus on, which I believe > are important: > > "Health" fault: some receiver(s) are seeing packet loss, or are > even unable to tell that a given source is sending anything. > "Utilization/congestion" fault: some sender is sending "too much" data > > Questions the NMS wants to ask to detect/diagnose the above faults: > 1a) What streams is the managed device sourcing? > 1b) How much data is it sending on each stream? > (Used to diagnose utilization/congestion problems) > > 2a) What streams is the managed device receiving? > 2b) How much data is it receiving on each stream? > (Also used to diagnose utilization/congestion problems) > > 3a) Who are all the sources (that the managed device knows > of) to a > given session? (Used to diagnose health problems) > 3b) How much data is each one sending (utilization/congestion)? > 3c) How much loss is the managed device seeing from each > one? (health) > > 4a) Who are all the receivers (that the managed device > knows of) to > a given session? > 4b) How much loss is each one seeing for each source? (health) > > I could go on for some time explaining why each of the above > questions is important to be able to answer. Feel free to suggest > other questions. If you agree with the above list of questions, > then let's look at whether the MIB is effective or not in doing > what it aims to do. > > (a) Detecting faults in RTP sessions > If the NMS wants to detect faults, then it needs to either > poll objects that can answer the necessary questions, or > receive asynchronous notification. The MIB currently contains > no traps, so I ask: should it? (If not, the DISMAN Expression > and Event MIBs together might provide a sufficient alternative.) > > I expect that a NOC may want to poll for example, all of an RTP > monitor's rtpRcvrLostPackets and rtpSenderPackets objects, so the > MIB does allow answering 4b via polling a potentially huge number > of objects. The descriptions of those two objects may > want to mention > that this is what they're for. However, the MIB should state > why rtpRcvrPackets is needed... how is it different from > rtpSenderPackets-rtpRcvrLostPackets? > > Likewise, 3b can be answered by polling rtpSenderOctets, so > I think the MIB is fine here. > > (b) Diagnosing faults in RTP sessions > I'll cover all the other questions here. > 1a) I don't see any good way to answer this question > without walking the entire rtpSenderTable. This can > be very expensive, especially if there are either a bunch > of streams the device is receiving-only, or a bunch of other > senders to ones it is sending to, so I don't consider this > question effectively answered by this MIB. > > Also, how do you know what SSRC value the > managed device is using? > > 1b) rtpSenderOctets would be fine if you could answer 1a. > > 2a) It isn't clear to me whether you can discover what > sessions the device is receiving by walking the > rtpSessionTable, > or whether you need to walk the entire rtpRcvrTable. > (Does an entry in rtpSessionTable necessarily imply it's > receiving RTP and not just RTCP? If not, walking > the rtpRcvrTable may be very inefficient.) > > 2b) I don't see an easy way to answer this question using > the rtpRcvrTable. I suppose you'd have to do a GET-NEXT > to find the next rtpSessionIndex and rtpRcvsSRCSSRC > values, and then a GET for the device's rtpRcvrSSRC value, > and repeat until the end of the table. (Again, how do you > know what its SSRC value is?) > > 3a) Source enumeration is fine once you've found the > rtpSessionIndex. However, it appears to be impossible > to locate the rtpSessionIndex without walking the > rtpSessionTable, which could be very inefficient. > So I don't consider this question effectively answered > either. > > (3b was covered above) > > 3c) Finding what loss the device is seeing for a given > group/port and > source requires you determine the device's SSRC (how?), the > source's SSRC (how?), and the rtpSessionIndex for the session > (how?). I don't see how you determine any of these > three in an efficient manner, but if you could, > answering the question can be done with rtpSenderPackets > and rtpRcvrLostPackets. > > 4a) Receiver enumeration is fine once you've found the > rtpSessionIndex, as with 3a above. > > (4b was covered above) > > In summary, it looks to me like a lot of problems are introduced > by the fact that the rtpSessionTable is indexed by an integer > instead of by rtpSessionRemAddr and rtpSessionLocAddr (and > rtpSessionDomain?). While this has the advantage of supporting > other address families, it appears to prevent the MIB from > being useful (at least by itself) for its intended purpose. > If it's intended that all of the above questions be answered > by some other (unmentioned) extension MIB, then I would contend > that the purpose of the RTP MIB needs to be rephrased. > > (c) Configure RTP Monitors > It does appear that this goal is adequately met. > > -Dave Thaler > From rem-conf Mon May 10 20:26:29 1999 From rem-conf-request@es.net Mon May 10 20:26:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10h37N-000782-00; Mon, 10 May 1999 20:22:05 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10h37K-00077s-00; Mon, 10 May 1999 20:22:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon May 10 23:21:03 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.208]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA14970; Mon, 10 May 1999 23:21:01 -0400 (EDT) Message-ID: <3737A22C.DBE54450@dnrc.bell-labs.com> Date: Mon, 10 May 1999 23:21:16 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Nikos Laoutaris CC: Remote conf mailing list Subject: Re: jitter calculation in RTP References: <001601be986a$00956a60$255a86c3@Aragorn.noc.uoa.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Nikos Laoutaris wrote: > > Hello > > I have a question about the impact of lost packets on the jitter > calculation in RTP. RFC1889 states > that the formula J= J + ( |D(i-1,i)| - J ) / 16 is applied to > consequtive packets, not necessarily in order. > Lets say that packet with sequence number i-2 is received correctly, > packet i-1 is lost and packet i is received correctly. Then the big > time gap due to the loss of packet i-1 will contribute a large amount > of jitter. Is that what happens? No. There is a larger difference in receive times, but the packets were also sent farther apart in time. Since the jitter is the difference in receive times minus the difference in send times, it works out fine. Consider a network which imparts a fixed delay d to each packet, and assume packets are sent spaced D apart. So, the send time of packet i is i*D, and its reception is i*D + d. For any two packets i and j, D(i,j) is: D(i,j) = (Rj-Ri) - (Sj-Si) = ((j*D + d) - (i*D + d)) - ((j*D) - (i*D)) = j*d - j*D - i*D + i*D -d +d = 0 that is, the jitter is ALWAYS zero, between any pair of packets, even though two packets may have been received far apart in time. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue May 11 02:50:31 1999 From rem-conf-request@es.net Tue May 11 02:50:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10h98A-0002b1-00; Tue, 11 May 1999 02:47:18 -0700 Received: from mickey.ee.pdx.edu [131.252.209.58] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10h988-0002ar-00; Tue, 11 May 1999 02:47:16 -0700 Received: from chip.ee.pdx.edu (videoc@chip.ee.pdx.edu [131.252.221.60]) by mickey.ee.pdx.edu (8.9.1/8.9.1) with ESMTP id CAA08831; Tue, 11 May 1999 02:32:46 -0700 (PDT) From: Video Compression Workshop Received: (from videoc@localhost) by chip.ee.pdx.edu (8.8.6/8.8.6) id CAA10924; Tue, 11 May 1999 02:03:19 -0700 (PDT) Date: Tue, 11 May 1999 02:03:19 -0700 (PDT) Message-Id: <199905110903.CAA10924@chip.ee.pdx.edu> To: videoc@ee.pdx.edu Subject: Video Compression Short Course in Portland 7/13-19/99 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subject: Video Compression Short Course in Portland 7/13-19/99 4 & 1/2 Days (July 19 - 23, 1999) in Portland Oregon on IMAGE AND VIDEO COMPRESSION: FUNDAMENTALS, STANDARDS, AND APPLICATIONS Featured: Majid Rabbani - Eastman Kodak M. Ibrahim Sezan - Sharp Labs. of America Thomas Gardos - Intel Corporation Organized by Fu Li and Rolf Schaumann Portland State University, Portland, Oregon, USA please visit http://www.ee.pdx.edu/short_courses/image_compression/ Contact Don Mueller at Telephone: (503) 725-3806 Facsimile: (503) 725-3807 Email: donm@eas.pdx.edu Comprehensive Coverage on JPEG-2000, MPEG -4 and -7, and H.26x Standards! With Latest Technology Demos Seats limited. Please register today! From rem-conf Wed May 12 09:09:49 1999 From rem-conf-request@es.net Wed May 12 09:09:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10hbIV-0003cV-00; Wed, 12 May 1999 08:51:51 -0700 Received: from mickey.ee.pdx.edu [131.252.209.58] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10hbIU-0003cK-00; Wed, 12 May 1999 08:51:50 -0700 Received: from dale.ee.pdx.edu (videoc@dale.ee.pdx.edu [131.252.220.134]) by mickey.ee.pdx.edu (8.9.1/8.9.1) with ESMTP id IAA04631; Wed, 12 May 1999 08:43:25 -0700 (PDT) From: Video Compression Workshop Received: (from videoc@localhost) by dale.ee.pdx.edu (8.8.6/8.8.6) id IAA06697; Wed, 12 May 1999 08:27:15 -0700 (PDT) Date: Wed, 12 May 1999 08:27:15 -0700 (PDT) Message-Id: <199905121527.IAA06697@dale.ee.pdx.edu> To: fli@ee.pdx.edu Subject: Video Compression Short Course in Portland 7/19-23/99 (date correction) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subject: Video Compression Short Course in Portland 7/19-23/99 4 & 1/2 Days (July 19 - 23, 1999) in Portland Oregon on IMAGE AND VIDEO COMPRESSION: FUNDAMENTALS, STANDARDS, AND APPLICATIONS Featured: Majid Rabbani - Eastman Kodak M. Ibrahim Sezan - Sharp Labs. of America Thomas Gardos - Intel Corporation Organized by Fu Li and Rolf Schaumann Portland State University, Portland, Oregon, USA please visit http://www.ee.pdx.edu/short_courses/image_compression/ Contact Don Mueller at Telephone: (503) 725-3806 Facsimile: (503) 725-3807 Email: donm@eas.pdx.edu Comprehensive Coverage on JPEG-2000, MPEG -4 and -7, and H.26x Standards! With Latest Technology Demos Seats limited. Please register today! From rem-conf Wed May 12 14:41:40 1999 From rem-conf-request@es.net Wed May 12 14:41:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10hggg-0007L2-00; Wed, 12 May 1999 14:37:10 -0700 Received: from uumail-relay-blr.ernet.in [202.141.1.17] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10hgcv-0007IL-00; Wed, 12 May 1999 14:33:19 -0700 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with ESMTP id DAA15407 for ; Thu, 13 May 1999 03:05:25 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id PAA00632; Wed, 12 May 1999 15:58:00 +0530 (GMT+0530) Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA13095; Tue, 11 May 99 20:31:42+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9905111501.AA13095@ece.iisc.ernet.in> Subject: Reliability with strict timing To: rem-conf@es.net Date: Tue, 11 May 99 20:31:41 GMT+5:30 X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have a multicast application that apart from transmitting audio, also tries to transmit a separate stream of annotations/figures to be played back at the remote nodes reliably, and in synchrony with audio. These annotations get displayed on a remote document (eg., postscript). The use of a scalable and reliable multicast protocol for the annotation stream does not serve the purpose well since it does not guarantee the timely delivery of the annotations (Please correct me if I am wrong). For my application timing is as equally very important as the reliability. The kind of problem I have at hand can be extended if there is more than one source. I have thought of a method. Please let me know if it is alright. I can think of the document as a "video" screen that is getting pixel information from one or more sources. The difference between video being the source and the annotations/figures being the source is that video is a synchronous media that periodically updates/refreshes the screen. If I send the annotations/figures at some periodic rate whether there are updates or not, not to the extent that heavy bandwidth is consumed, thus converting the asynchronous nature of these to a synchronous one, am I not achieving the desired purpose ? Reliability is achieved because the updations of the annotations/figures keep happening automatically at certain rate, unsolicited, and the timing is also taken care because the rate of sending these updates can be decided by the sources and the receiver can adjust its playout times accordingly. Also, one can use FEC to this newly converted synchronous media. I believe that the badwidth taken by annotation/figure description is not going to be high even when the refresh updates are sent periodically. I sincerely wish that I could convey atleast remotely what I wish to. Please let me have your thoughts on this. The other question to be asked is what type of media this newly created one comes under ? Thank you for your time. Regards Anand From rem-conf Wed May 12 16:16:20 1999 From rem-conf-request@es.net Wed May 12 16:16:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10hiC7-0000zE-00; Wed, 12 May 1999 16:13:43 -0700 Received: from sakura.sundai.ac.jp (sakura.) [210.129.158.34] by mail1.es.net with smtp (Exim 1.81 #2) id 10hiBu-0000yC-00; Wed, 12 May 1999 16:13:33 -0700 Received: from zappselling.com by sakura. (SMI-8.6/SMI-SVR4) id IAA11566; Thu, 13 May 1999 08:08:09 +0900 From: stonef@deskmail.com Message-Id: <199905122308.IAA11566@sakura.> Subject: NEW IT sales program Date: Wed, 12 May 1999 15:49:16 Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I got your name from an IT sales directory and would like to introduce you to our IT Sales Boot Camp. This is a sales training program that was especially created for you to win BIG major account IT business. Why should I come? Through 50 combined years of sales research and application with our Fortune 500 clients like ORACLE, SUN MICROSYSTEMS, NEC WANG etc. we have extracted all of the effective techniques and methods you will need to obtain large accounts in the global market place consistently for a fraction of their investment. How does it work? IT Sales Boot Camp is a two-day program designed for information Technology sales professionals to win business. The program presents proven competitive sales methodology based on political acumen, consultative sales approaches and partnering skills. The Boot Camp enables IT salespeople to have a clear major account strategy, teaching them new tactical approaches to engage and defeat the competition, while focusing on customer needs. Learn the inside story, firsthand, on how the process really works. For recorded information about pricing, location and dates please phone us TOLL-FREE at 1-877-77SALES (1-877-777-2537) Inquire about group discounts. Thank you in advance, Dr. Frank Stone Executive Vice President PS: If you are not in a position of Sales Management please forward this letter to those that are they will love you for it! To remove go to rmove@deskmail.com From rem-conf Thu May 13 00:31:17 1999 From rem-conf-request@es.net Thu May 13 00:31:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10hpuu-0005RJ-00; Thu, 13 May 1999 00:28:28 -0700 Received: from agora.rdrop.com [199.2.210.241] by mail1.es.net with esmtp (Exim 1.81 #2) id 10hput-0005R9-00; Thu, 13 May 1999 00:28:27 -0700 Received: from s.brower (ppp-db.rdrop.com [199.2.212.44]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id AAA14080; Thu, 13 May 1999 00:28:22 -0700 (PDT) Message-Id: <3.0.32.19990513003059.006fc994@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 May 1999 00:31:01 -0700 To: dthaler@dthaler.microsoft.com From: Mark Baugher Subject: Re: Review of draft-ietf-avt-mib-05.txt Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave My comments/answers appear in your note below. -----Original Message----- > From: Dave Thaler [mailto:dthaler@dthaler.microsoft.com] > Sent: Thursday, May 06, 1999 8:22 PM > To: rem-conf@es.net > Subject: Review of draft-ietf-avt-mib-05.txt > > > Some high-level (hopefully constructive) criticisms in this message, > I'll save details/nitpicks for after these have been discussed. > > Disclaimer: I haven't been following the AVT mailing list, and don't > claim to understand the details of RTP. So if anything below would > be obvious to someone familiar with RTP, then the draft may be just > fine. > > That said, I'd like to start right from square one, and talk about > the question "What is the purpose of this MIB?" Section 2.2 > answers this by saying it's for (a) detecting and (b) > diagnosing faults > in RTP sessions, as well as for (c) configuring RTP monitors. We mentioned capacity planning in the draft. We have used the MIB to audit participants in remote presentation sessions from an RTP monitor though this is not mentioned in the draft. > > Since the primary focus is apparently on fault diagnosis, I ask: > What are the most important questions you (an NMS) want to ask? > (The MIB doesn't say anything about *what* faults or how the objects > can actually be used to diagnose any fault.) > As an author of the MBone Debugging Handbook, I'll suggest a few > strawman faults and questions to focus on, which I believe > are important: > > "Health" fault: some receiver(s) are seeing packet loss, or are > even unable to tell that a given source is sending anything. > "Utilization/congestion" fault: some sender is sending "too much" data > > Questions the NMS wants to ask to detect/diagnose the above faults: > 1a) What streams is the managed device sourcing? > 1b) How much data is it sending on each stream? > (Used to diagnose utilization/congestion problems) > > 2a) What streams is the managed device receiving? > 2b) How much data is it receiving on each stream? > (Also used to diagnose utilization/congestion problems) > > 3a) Who are all the sources (that the managed device knows > of) to a > given session? (Used to diagnose health problems) > 3b) How much data is each one sending (utilization/congestion)? > 3c) How much loss is the managed device seeing from each > one? (health) > > 4a) Who are all the receivers (that the managed device > knows of) to > a given session? > 4b) How much loss is each one seeing for each source? (health) > > I could go on for some time explaining why each of the above > questions is important to be able to answer. Feel free to suggest > other questions. If you agree with the above list of questions, > then let's look at whether the MIB is effective or not in doing > what it aims to do. Good points. In fact we used an earlier implementation to answer these and other questions. We could also ask "What type of sessions are being sent or received?" or we could ask "What application tool is being used to send or receiver session data?" We could also ask application or configuration-specific questions like "How many receivers are sending?" Note that the last question may make sense in a particular multicast service that restricts receivers from being senders, but it is not an interesting question for H.323. I don't think there is such a thing as RTP management per se, but there is loosely-coupled conference management, tightly-coupled conference management, H-series management, etc. In all cases, RTP is one component of the solution. > > (a) Detecting faults in RTP sessions > If the NMS wants to detect faults, then it needs to either > poll objects that can answer the necessary questions, or > receive asynchronous notification. The MIB currently contains > no traps, so I ask: should it? (If not, the DISMAN Expression > and Event MIBs together might provide a sufficient alternative.) We discussed traps and implemented one in a prototype. The trap did not seem to be a "must have" feature so we did not include it in any draft version of the MIB. I did not like putting such a feature in hosts to detect problems because of the obvious issue of many hosts reporting similar problems. I think it is better to put this function in a management application when polling is not too great a burden on the network or systems. I think polling a monitor may be a better solution than asynchronous notifications from multicast receivers. > > I expect that a NOC may want to poll for example, all of an RTP > monitor's rtpRcvrLostPackets and rtpSenderPackets objects, so the > MIB does allow answering 4b via polling a potentially huge number > of objects. The descriptions of those two objects may > want to mention > that this is what they're for. However, the MIB should state > why rtpRcvrPackets is needed... how is it different from > rtpSenderPackets-rtpRcvrLostPackets? In host mode, the rtpSenderTable entry is kept by the sender and the rtpRcvrTable entry is kept by the receiver, which won't have the rtpSenderPackets object. > > Likewise, 3b can be answered by polling rtpSenderOctets, so > I think the MIB is fine here. > > (b) Diagnosing faults in RTP sessions > I'll cover all the other questions here. > 1a) I don't see any good way to answer this question > without walking the entire rtpSenderTable. This can > be very expensive, especially if there are either a bunch > of streams the device is receiving-only, or a bunch of other > senders to ones it is sending to, so I don't consider this > question effectively answered by this MIB. > > Also, how do you know what SSRC value the > managed device is using? I discuss the case of monitor mode several paragraphs below. In host mode, every entry in the rtpSenderTable is a stream being sourced by the managed device. So every entry is of interest. But it depends on the particular management application. An H.323 management application will likely access it using objects in other MIBs - Irina may want to comment on this. Walking the tables will get you the SSRCs, but the particular application, e.g., H.323, may store needed information in other MIB's objects to maintain linkage to the RTP MIB. > > 1b) rtpSenderOctets would be fine if you could answer 1a. > > 2a) It isn't clear to me whether you can discover what > sessions the device is receiving by walking the > rtpSessionTable, > or whether you need to walk the entire rtpRcvrTable. > (Does an entry in rtpSessionTable necessarily imply it's > receiving RTP and not just RTCP? If not, walking > the rtpRcvrTable may be very inefficient.) If the sender is not sending RTP or if the receiver is not receiving RTP, eventually each should stop sending RTCP - implementations are supposed to have a timeout parameter. Data about sessions that the device is receiving is in the rtpRcvrTable. Again, in host mode all entries in the rtpRcvrTable are of interest so there is no inefficiency in walking the table. > > 2b) I don't see an easy way to answer this question using > the rtpRcvrTable. I suppose you'd have to do a GET-NEXT > to find the next rtpSessionIndex and rtpRcvsSRCSSRC > values, and then a GET for the device's rtpRcvrSSRC value, > and repeat until the end of the table. (Again, how do you > know what its SSRC value is?) My comments about host mode and the type of application (e.g., H.323, loosely-coupled conferencing) that I made above apply here. We would poll rtpRcvrOctets values to answer 2b. Let's consider monitor mode and the case where we are using an NNS MIB browser to access the RTP MIB. I. Do a Get Next on the rtpSessionTable to obtain all of the rtpSessionIndex and other objects of interest from each conceptual row. II. Filter the rtpSessionIndex by rtpSessionLocAddr to identify those entries for the managed device of interest. III. Walk the rtpRcvrTable using the rtpSessionIndex values from step II to obtain objects of interest. A monitor does not have information about octets or packets received so a crude measure would need to be calculated based on, say, how much is being sent (rtpSenderOctets and rtpSenderPackets) and how much is being lost (rtpRcvrLostPackets). Answering question 2b in a monitor is hard using a MIB browser; we developed a management application. There are no inefficiencies in step III since all the information obtained is used. Steps I and II may be inefficient. In our monitor management application, we accessed all information from the session table, which served as the main interface to the monitor's MIB. In other cases, Steps I and II may be inefficient since we are walking the MIB and filtering in the NMS. I consider this issue further immediately below. > > 3a) Source enumeration is fine once you've found the > rtpSessionIndex. However, it appears to be impossible > to locate the rtpSessionIndex without walking the > rtpSessionTable, which could be very inefficient. > So I don't consider this question effectively answered > either. This is a good point that keeps coming up given the approach we have taken. Why do we do this? As you know, there's a space-time tradeoff and there is a tradeoff between NMS complexity and agent complexity. We could merge the Session table and the Sender table as well as the Session table and the Receiver table. This would reduce the number of requests that an NMS would need to make at the expense of a lot of redundant data in the host tables; we would practically double our table size and this seemed to be a bad approach since some RTP applications use multicast or are call gateways. There are also issues with the length of OIDs when there are many, particularly non-integer, indexes, and our composite Session-Sender and Session-Rcvr tables would have many such indices. We opted to keep the tables as small as they could be and to use very simple indexing. There may be an inefficiency with enumeration and filtering in some types of queries made to multicast RTP monitors. We did not find this a problem in our RTP monitor management application since we brought in the entire RTP session table to serve as an interface to the monitor's RTP MIB. I don't think it is a problem in H.323 devices because indexes are kept in other H-series MIBs as linkage to the RTP MIB. Finally, it is not a problem in hosts. At present, we cannot access the rtpSessionTable based upon the TAddress pair that identify an RTP session - an integer index is used to reduce the size of OIDs in Gets against this table and to make it simpler for the agent. How could we eliminate this and still minimize table size and use simple indexes? Perkins gives an example solution using inverse indexing: We could create another table that is indexed by the TAddress pair of the rtpSessionTable and which has one non-index column - rtpSessionIndex. This has come up in previous discussions at least three times. Each time we came to the conclusion that a table indexed by the TAddress pair that returns rtpSessionIndex could easily be added if shown to be essential. Each time we convinced ourselves that the MIB effectively answered the questions that you posed without adding this table. The people from Teleogy and Ascend who discussed this with us came to the same conclusion as I recall. > > (3b was covered above) > > 3c) Finding what loss the device is seeing for a given > group/port and > source requires you determine the device's SSRC (how?), the > source's SSRC (how?), and the rtpSessionIndex for the session > (how?). I don't see how you determine any of these > three in an efficient manner, but if you could, > answering the question can be done with rtpSenderPackets > and rtpRcvrLostPackets. I think I covered these topics above. > > 4a) Receiver enumeration is fine once you've found the > rtpSessionIndex, as with 3a above. > > (4b was covered above) > > In summary, it looks to me like a lot of problems are introduced > by the fact that the rtpSessionTable is indexed by an integer > instead of by rtpSessionRemAddr and rtpSessionLocAddr (and > rtpSessionDomain?). While this has the advantage of supporting > other address families, it appears to prevent the MIB from > being useful (at least by itself) for its intended purpose. These points were addressed above. > If it's intended that all of the above questions be answered > by some other (unmentioned) extension MIB, then I would contend > that the purpose of the RTP MIB needs to be rephrased. I like your points. I think we satisfy them. Mark > > (c) Configure RTP Monitors > It does appear that this goal is adequately met. > > -Dave Thaler > From rem-conf Thu May 13 08:06:10 1999 From rem-conf-request@es.net Thu May 13 08:06:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10hwz1-0002Ho-00; Thu, 13 May 1999 08:01:11 -0700 Received: from is1-50.antd.nist.gov (is1-55.antd.nist.gov) [129.6.50.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 10hwyz-0002He-00; Thu, 13 May 1999 08:01:09 -0700 Received: from nist.gov (camel.antd.nist.gov [129.6.50.54]) by is1-55.antd.nist.gov (8.8.8/8.8.8) with ESMTP id KAA20785 for ; Thu, 13 May 1999 10:54:46 -0400 (EDT) Sender: dongwen@antd.nist.gov Message-ID: <373AEAB1.EE1DB341@nist.gov> Date: Thu, 13 May 1999 11:07:29 -0400 From: Dongwen Wang Reply-To: dongwen@nist.gov Organization: NIST X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: rem-conf@es.net Subject: test Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is just a test! From rem-conf Thu May 13 16:21:00 1999 From rem-conf-request@es.net Thu May 13 16:20:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10i4do-0007WA-00; Thu, 13 May 1999 16:11:48 -0700 Received: from (dthaler.microsoft.com) [131.107.1.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10i4dl-0007W0-00; Thu, 13 May 1999 16:11:45 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id RAA06721; Thu, 13 May 1999 17:57:39 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905140057.RAA06721@dthaler.microsoft.com> Subject: Re: Review of draft-ietf-avt-mib-05.txt In-Reply-To: <3.0.32.19990513003059.006fc994@agora.rdrop.com> from Mark Baugher at "May 13, 1999 0:31: 1 am" To: mbaugher@rdrop.com (Mark Baugher) Date: Thu, 13 May 1999 17:57:39 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark, thanks for the response. My answers below. > > (a) Detecting faults in RTP sessions > > If the NMS wants to detect faults, then it needs to either > > poll objects that can answer the necessary questions, or > > receive asynchronous notification. The MIB currently contains > > no traps, so I ask: should it? (If not, the DISMAN Expression > > and Event MIBs together might provide a sufficient alternative.) > > We discussed traps and implemented one in a prototype. The trap did > not seem to be a "must have" feature so we did not include it in > any draft version of the MIB. I did not like putting such a feature > in hosts to detect problems because of the obvious issue of > many hosts reporting similar problems. I think it is better to put > this function in a management application when polling is not too great > a burden on the network or systems. I think polling a monitor may > be a better solution than asynchronous notifications from multicast > receivers. I agree that you probably don't want traps from receivers. However, an NMS probably would want traps from monitors. > > I expect that a NOC may want to poll for example, all of an RTP > > monitor's rtpRcvrLostPackets and rtpSenderPackets objects, so the > > MIB does allow answering 4b via polling a potentially huge number > > of objects. The descriptions of those two objects may > > want to mention > > that this is what they're for. However, the MIB should state > > why rtpRcvrPackets is needed... how is it different from > > rtpSenderPackets-rtpRcvrLostPackets? > > In host mode, the rtpSenderTable entry is kept by the sender and the > rtpRcvrTable entry is kept by the receiver, which won't have the > rtpSenderPackets object. That's not quite what the DESCRIPTION of rtpSenderTable says. It says that a receiver host MAY have rows in the sender table for each active source. THIS IS WHAT CAUSES THE PROBLEM, since you have to wade through everything else to find out what (if anything) the device itself is sourcing. In my opinion, you'd be much better off separating this into two tables, one table for what the device itself is sourcing, and another table for what remote sources it's receiving from. Without doing this separation, I still do not believe the MIB effectively supports fault diagnosis. (I do accept your answer about why you need each of rtpSenderPackets, rtpRcvrLostPackets, and rtpRcvrPackets, as long as it's optional for the receiver to keep a sender table.) > > Likewise, 3b can be answered by polling rtpSenderOctets, so > > I think the MIB is fine here. > > > > (b) Diagnosing faults in RTP sessions > > I'll cover all the other questions here. > > 1a) I don't see any good way to answer this question > > without walking the entire rtpSenderTable. This can > > be very expensive, especially if there are either a bunch > > of streams the device is receiving-only, or a bunch of other > > senders to ones it is sending to, so I don't consider this > > question effectively answered by this MIB. > > > > Also, how do you know what SSRC value the > > managed device is using? > > I discuss the case of monitor mode several paragraphs below. > > In host mode, every entry in the rtpSenderTable is a stream being > sourced by the managed device. So every entry is of interest. See my comment above. The DESCRIPTION clause of rtpSenderTable contradicts your answer here. If you fix the description to say explicitly that every entry in this table, regardless of whether the device is a receiver host, or a monitor, or both (which I assume must be legal), is for a stream the device is sourcing, then this table is fine. It doesn't support asking a monitor or a receiver what OTHER sources there are though, you'd need a separate table for that as I mentioned above. > > 1b) rtpSenderOctets would be fine if you could answer 1a. > > > > 2a) It isn't clear to me whether you can discover what > > sessions the device is receiving by walking the > > rtpSessionTable, > > or whether you need to walk the entire rtpRcvrTable. > > (Does an entry in rtpSessionTable necessarily imply it's > > receiving RTP and not just RTCP? If not, walking > > the rtpRcvrTable may be very inefficient.) > > If the sender is not sending RTP or if the receiver is not > receiving RTP, eventually each should stop sending RTCP - > implementations are supposed to have a timeout parameter. > > Data about sessions that the device is receiving is in the > rtpRcvrTable. Again, in host mode all entries in the > rtpRcvrTable are of interest so there is no inefficiency > in walking the table. I don't think this supports an entity which is both a monitor and a receiving host does it? This sounds broken to me. Again, I would expect to see two separate tables. > > 2b) I don't see an easy way to answer this question using > > the rtpRcvrTable. I suppose you'd have to do a GET-NEXT > > to find the next rtpSessionIndex and rtpRcvsSRCSSRC > > values, and then a GET for the device's rtpRcvrSSRC value, > > and repeat until the end of the table. (Again, how do you > > know what its SSRC value is?) > > My comments about host mode and the type of application (e.g., H.323, > loosely-coupled conferencing) that I made above apply here. We would > poll rtpRcvrOctets values to answer 2b. > > > 3a) Source enumeration is fine once you've found the > > rtpSessionIndex. However, it appears to be impossible > > to locate the rtpSessionIndex without walking the > > rtpSessionTable, which could be very inefficient. > > So I don't consider this question effectively answered > > either. > > This is a good point that keeps coming up given the approach we have > taken. Why do we do this? As you know, there's a space-time tradeoff > and there is a tradeoff between NMS complexity and agent complexity. > We could merge the Session table and the Sender table as well as the > Session table and the Receiver table. This would reduce the number > of requests that an NMS would need to make at the expense of a lot > of redundant data in the host tables; we would practically double > our table size and this seemed to be a bad approach since some > RTP applications use multicast or are call gateways. There are also > issues with the length of OIDs when there are many, particularly > non-integer, indexes, and our composite Session-Sender and > Session-Rcvr tables would have many such indices. We opted to keep > the tables as small as they could be and to use very simple indexing. In my opinion, this was a bad decision. OIDs can be up to 128 subids long, are typically never seen by a human, and the length of the OID has a negligible effect on performance. On the other hand, requiring an NMS to walk an entire table just to locate the one entry it wants can have a huge effect on performance, and is bound to be noticeable by a human. The agent implementation appears simpler WITHOUT a "special" integer, since it need not find an unused integer when it wants to add a row, or store any value other than what it already has to store anyway. The NMS implementation appears simpler WITHOUT a "special" integer, since it can directly access the information it needs without having to have lots of code to parse the whole table. > Finally, it is not a problem in hosts. I disagree. A host could easily be participating in a large number of low-bandwidth sessions, and walking the whole table in this case is just as bad as it is in a monitor. > At present, we cannot access the rtpSessionTable based upon > the TAddress pair that identify an RTP session - an integer > index is used to reduce the size of OIDs in Gets against this > table and to make it simpler for the agent. How could we eliminate > this and still minimize table size and use simple indexes? Perkins > gives an example solution using inverse indexing: We could create > another table that is indexed by the TAddress pair of the > rtpSessionTable and which has one non-index column - > rtpSessionIndex. That would be one acceptable solution, yes. > This has come up in previous discussions at least three times. Sounds like consensus that there's a problem then :) > Each time we came to the conclusion that a table indexed by the > TAddress pair that returns rtpSessionIndex could easily be added > if shown to be essential. I strongly believe that it is essential. (Either that or index the session table by the address.) > I like your points. I think we satisfy them. Obviously, I disagree. :) -Dave From rem-conf Thu May 13 16:44:29 1999 From rem-conf-request@es.net Thu May 13 16:44:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10i55T-0000Pg-00; Thu, 13 May 1999 16:40:23 -0700 Received: from (dthaler.microsoft.com) [131.107.1.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10i55R-0000PS-00; Thu, 13 May 1999 16:40:21 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id SAA06780; Thu, 13 May 1999 18:26:16 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905140126.SAA06780@dthaler.microsoft.com> Subject: Re: Review of draft-ietf-avt-rtp-mib-05.txt In-Reply-To: <3.0.32.19990513003059.006fc994@agora.rdrop.com> from Mark Baugher at "May 13, 1999 0:31: 1 am" To: mbaugher@rdrop.com (Mark Baugher), rem-conf@es.net Date: Thu, 13 May 1999 18:26:16 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here's the more editorial points I have: * The MIB boilerplate and references need to be updated to the new ones. * Syntax of phone numbers in the CONTACT-INFO clause aren't consistent with each other. * Why isn't rtpMonitorGroup not in the MANDATORY-GROUPS list of rtpMonitorCompliance? * I don't think it is appropriate for rtpSessionIfIndex to have a DEFVAL of 1. On some platforms, ifindex 1 is the loopback interface. I would suggest that a more appropriate way to do this is to use a SYNTAX of InterfaceIndexOrZero, a DEFVAL of { 0 }, and state in the DESCRIPTION clause that a value of 0 means that the device may choose any interface (i.e., the same semantics as using INADDR_ANY in the usual socket calls). * Why is rtpSessionMonitor required for hosts to implement? Also, if this MIB is to work for a device which is both a monitor and a receiving host, shouldn't the MAX-ACCESS be read-create? * In DESCRIPTION of rtpSenderTable, "reveiving" -> "receiving" * In DESCRIPTION of rtpSenderEntry, "the the" -> "the" * In DESCRIPTION of rtpSenderEntry, append "or when the rtpSessionEntry is deleted"? * In DESCRIPTION of rtpSenderSSRC, shouldn't "The RTP session address" be "The rtpSessionIndex" if you're going to use a session index in the MIB? * Re "rtpSRs". Usual practice is for same prefix to be used for the table as for all objects in the table. Hence, the name should be something like "rtpSenderSRs" or "rtpSenderReports". Similarly, "rtpRRs" should be "rtpRcvrRRs" or "rtpRcvrReports". * In DESCRIPTION of rtpSenderPT and rtpRcvrPT, it mentions "the RTP header". Which RTP header? The header of the first packet received? The last packet received? * In DESCRIPTION of rtpRcvrEntry, append "or when the rtpSessionEntry is deleted"? * In DESCRIPTION of rtpRcvrPackets and rtpRcvrOctets, it says if you don't have this entry you should return noSuchInstance. This sentence is unnecessary, as that's the behavior specified by SNMP if the object is not in the conformance information as mandatory to implement. The sentence is also misleading since it only applies to GETs but doesn't say so. I'd recommend just deleting the sentence. * Why is rtpSessionRowStatus in the rtpSystemGroup rather than the rtpMonitorGroup? Is the MIB intended to support row-creation and deletion on (non-monitor) hosts? * In DESCRIPTION of rtpHostCompliance's rtpHostGroup, it refers to "RTP host systems that are the source or the destination of RTP data packets." What other types of "RTP host systems" are there? * In the rtpMonitorCompliance statement, the rtpMonitorGroup contains only one object, and has a MIN-ACCESS of not-accessible. The DESCRIPTION says the group MUST be implemented. What is the MUST? Implementing a single object which is never accessible (and is not in the INDEX of any table) is the same as not implementing it. * The long list of objects under rtpMonitorCompliance whose MIN-ACCESS is not-accessible would be better done by putting them in a group which is listed as optional in the compliance statement. * Date on top of last page says February 26, 1998. -Dave From rem-conf Fri May 14 07:39:36 1999 From rem-conf-request@es.net Fri May 14 07:39:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10iIwS-0000ZK-00; Fri, 14 May 1999 07:28:00 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10iIwP-0000Z8-00; Fri, 14 May 1999 07:27:58 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 May 1999 15:27:39 +0100 To: release@cs.ucl.ac.uk, rem-conf@es.net Subject: RAT v4.0.1 is released Date: Fri, 14 May 1999 15:27:37 +0100 Message-ID: <6340.926692057@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are pleased to announce the release of RAT v4.0.1 RAT is an open source voice-over-IP application. It allows users to particpate in audio conferences over the internet. These can be between two participants directly, or between a group of participants on a common multicast group. No special features are required to use RAT in point to point mode, but to use the multiparty conferencing facilities of RAT, all participants must reside on a portion of the Internet which supports IP multicast. RAT is based on IETF standards, using RTP above UDP/IP as its transport protocol, and conforming to the RTP profile for audio and video conference with minimal control. RAT features sender based loss mitigation mechanisms and receiver based audio repair techniques to compensate for packet loss, and load adaption in response to host performance. It runs on a range of platforms: FreeBSD, IRIX, Linux, NetBSD, Solaris, and Windows 95/98/NT. The source code is publicly available for porting to other platforms and for modification by others. Additional features since RAT v3.0.34 include: - Improved audio quality. - Support for multiple sample formats (sampling rates of 8,16,32,48 kHz and mono and stereo). - Sample format conversion. - Additional codecs: Wide Band ADPCM Speech Codec (16kHz, 64 kbps), G726-3/4/5, VDVI. - Sound localization (3D positioning of audio sources). - Improved Automatic Gain Control. - Improved user interface. - Separation of audio engine and user interface components. - Conference bus for inter-component and inter-application communication. - Improved Windows audio support (mixer control and ACM format conversions). - Balloon help to explain all options. - Reception quality matrix. Since the previous experimental release (v4.0.0) we have added a number of new codecs, added transparant playout buffer skew adaptation, improved control of the audio mixer on Windows, lowered playout delays and improved the stability of the application. We look forward to any feedback, bug reports, patches and comments on experience. More information, including download instructions, is available from http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/experimental/ Please send all feedback to rat-trap@cs.ucl.ac.uk Colin Perkins/Orion Hodson Networked Multimedia Group University College London From rem-conf Fri May 14 20:02:57 1999 From rem-conf-request@es.net Fri May 14 20:02:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10iUXz-0004ME-00; Fri, 14 May 1999 19:51:31 -0700 Received: from caleta.mcolivia.com.ar (mcolivia.com.ar) [200.41.128.3] by mail1.es.net with smtp (Exim 1.81 #2) id 10iUXr-0004LR-00; Fri, 14 May 1999 19:51:25 -0700 Received: from duse.net by mcolivia.com.ar (SMI-8.6/SMI-SVR4) id XAA13697; Fri, 14 May 1999 23:34:32 +0300 Date: Fri, 14 May 1999 23:34:32 +0300 From: ventureway@duse.net Message-Id: <199905142034.XAA13697@mcolivia.com.ar> Reply-To: ventureway@duse.net To: ventureway@duse.net Subject: TOP 500 INC. COMPANY SEEKS: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list · Motivated individuals for National expansion. · Do you have a strong work ethic? · Are you a management/ leadership type person? · Start your own business now! · 12 year old Industry leader featured in Success Mag; Time Mag. and Inc 500 !!! · You will personally Work with # 1 team in USA. · Turn-key system with multiple support partners. · Breakthrough Hi-tech product (timing is everything). · Market is fantastic and growing each day !!! · Work from from your home or office, part-time or full-time. · Expense paid vacations, business or pleasure. · $800/mo. bonus car allowance !!! · Start up funding available. · You have the freedom to control your time and income. CLICK THE LINK BELOW and enter your information and we will contact you with complete details. =================================================== "mailto:prospernow@bigfoot.com" Please include the following: Without this information we CAN NOT contact you. -------------------------------------------------------------------------------------- 1. Name <<<<====Important (remember to include) 2. Home OR work phone number <<<<====Important (remember to include) 3. The best time to contact you <<<<====Important (remember to include) =================================================== To be added to our Remove list, reply to "mailto:list7477@bigfoot.com" with "remove in the subject heading. From rem-conf Sat May 15 10:43:35 1999 From rem-conf-request@es.net Sat May 15 10:43:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10iiMl-0003Xy-00; Sat, 15 May 1999 10:36:51 -0700 Received: from pc20.adinternet.co.jp (adinternet.co.jp) [206.3.8.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10iiMe-0003VD-00; Sat, 15 May 1999 10:36:45 -0700 Received: from smtp.adua.com (ABD15D6A.ipt.aol.com [171.209.93.106]) by adinternet.co.jp (8.8.7/3.6W) with SMTP id CAA22360; Sun, 16 May 1999 02:30:12 +0900 (JST) From: jnahs@boom.com Message-Id: <199905151730.CAA22360@adinternet.co.jp> To: Subject: best offer Date: Sat, 15 May 1999 09:59:49 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Have a WEBSITE? Need Traffic?? Use Banner Advertising. It's the most powerful advertising medium today. Imagine being able to instantly expose your site to the millions of potential customers for a fraction of the cost that our competitors charge. Well stop imagining and make it happen. You will be glad you did when the checks start pouring in! http://3626046468/ga2/traffica/index2.html We are the leaders in email marketing and we are ready to help you get the exposure that you deserve. We have over 3 years experience in advertising and have helped many small sites become extremely profitable. We take time with each individual customer to customize their advertising campaign and get the response that they are looking for. Our advertising services have helped increase gross sales by 15 percent up to 60 percent! Best Prices Around - As low as HALF the price of the competition. Offer ends June 12th. Visit Click Here DON'T DELAY!!!! ACT TODAY!!!! --------------------------------------------------------- To be removed, reply to asuashs@mail.usa.com with REMOVE in the subject line. Thank You. --------------------------------------------------------- From rem-conf Sun May 16 17:13:17 1999 From rem-conf-request@es.net Sun May 16 17:13:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jApa-0007a6-00; Sun, 16 May 1999 17:00:30 -0700 Received: from agora.rdrop.com [199.2.210.241] by mail1.es.net with esmtp (Exim 1.81 #2) id 10jApZ-0007Zv-00; Sun, 16 May 1999 17:00:29 -0700 Received: from s.brower (ppp-di.rdrop.com [199.2.212.51]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id RAA23452; Sun, 16 May 1999 17:00:20 -0700 (PDT) Message-Id: <3.0.32.19990516170300.006fc60c@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 16 May 1999 17:03:03 -0700 To: Dave Thaler From: Mark Baugher Subject: Re: Review of draft-ietf-avt-mib-05.txt Cc: dthaler@dthaler.microsoft.com, rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave This table permits the rtpSessionIndex to be found based upon the domain and TAddress pair that define an RTP session. If we added this table, would it address your biggest concerns about the RTP MIB? rtpSessionInverseTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps rptSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr to an unsigned integer index, rtpSessionInverseIndex, which has the rtpSessionIndex value that maps to the same rtpSessionDomain, rtpSessionAddr, and rtpSessionLocAddr in the rtpSessionTable. rtpSessionIndex can thereby be retrieved based upon the domain and TAdress pair that uniquely define an RTP Session." ::= { rtpMIBObjects x } rtpSessionInverseEntry OBJECT-TYPE SYNTAX RtpSessionInverseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the rtpSessionTable - the entry containing the triple, rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr." INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr } ::= { rtpSessionInverseTable 1 } RtpSessionInverseEntry ::= SEQUENCE { rtpSessionInverseIndex Integer32, rtpSessionInverseStartTime TimeStamp } rtpSessionInverseIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of an rtpSessionIndex, the index into the rtpSessionTable conceptual row that contains the values of rtpSessionDomain, rtpSessionRemAddr and rtpSessionLocAddr that index this conceptual row." ::= { rtpSessionInverseEntry 1} rtpSessionInverseStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSessionInverseEntry 2 } I have not yet compiled this table. Apart from the clarity of the DESCRIPTION clauses, which may or may not be an issue, there are some other issues regarding this table. First, should it be mandatory or optional? All of the information in this table may be copied from the rtpSessionTable, but it forces the agent to keep a sort on the session table by domain and TAddress pair. Second, should this table be created manually by the manager rather than being automatically created by the agent? I elected to make it dyanmically created by the agent, and I think it should be optional. Mark From rem-conf Sun May 16 20:07:27 1999 From rem-conf-request@es.net Sun May 16 20:07:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jDhC-0002Is-00; Sun, 16 May 1999 20:04:02 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 10jDhB-0002Ii-00; Sun, 16 May 1999 20:04:01 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id UAA19282 for ; Sun, 16 May 1999 20:04:01 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Sun, 16 May 1999 20:03:59 -0700 Received: from [17.219.158.123] ([17.219.158.123]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id UAA35074; Sun, 16 May 1999 20:03:57 -0700 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <01BE5439.31D56410.chris@arnes.si> Date: Sun, 16 May 1999 16:48:24 -0700 To: "chris@arnes.si" From: Dave Singer Subject: Re: Quicktime and DVI/H.261 Cc: "rem-conf@es.net" Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 2:33 PM +0100 2/9/99, Chris van der Merwe wrote: >Hi; > >I'm trying to experiment recieving feeds from the Mbone with QuickTime. I >heard that it does support RTP. Anyway, when I type an address into the >Open URL option of the Quicktime player. I get the following message: > >Couldn't open the URL because a software component needed by the movie >could not be found. We support HTTP, FTP, RTSP and FILE urls (though there are easier ways to open files!). > >Have I got the wrong end of the stick here, does Quicktime not support >this, according to the documentation it should work with DVI 4:1 and H.261 >and H.263 > Yes,we even include LPC decode (and GSM). To view a multicast, you'll need an SDP file. We don't support RTP URLs. Just open the SDP file in QTPLayer (a text file with a name ending .sdp) and then click play (it should auto-play). From there you can save it as a movie, add other content etc., and watch mbone in any qt application (e.g. excel, powerpoint...) if you wish. Note that you can open a multicast by http fetching the sdp file... >I have tried all the below variations on the theme: > >224.2.145.95:56360 >224.2.145.95/56360 >rtp://224.2.145.95:56360 >rtp://224.2.145.95/56360 > >None of them worked, any ideas? > >Thanks > Chris David Singer Apple Computer/QuickTime From rem-conf Mon May 17 10:44:29 1999 From rem-conf-request@es.net Mon May 17 10:44:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jRKa-0003uB-00; Mon, 17 May 1999 10:37:36 -0700 Received: from (dthaler.microsoft.com) [131.107.1.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10jRKZ-0003u1-00; Mon, 17 May 1999 10:37:35 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id MAA13830; Mon, 17 May 1999 12:23:09 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905171923.MAA13830@dthaler.microsoft.com> Subject: Re: Review of draft-ietf-avt-mib-05.txt In-Reply-To: <3.0.32.19990516170300.006fc60c@agora.rdrop.com> from Mark Baugher at "May 16, 1999 5: 3: 3 pm" To: mbaugher@rdrop.com (Mark Baugher) Date: Mon, 17 May 1999 12:22:45 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > This table permits the rtpSessionIndex to be found > based upon the domain and TAddress pair that define > an RTP session. If we added this table, would it > address your biggest concerns about the RTP MIB? One of them, yes. (The other big concern would require the receiver and sender tables to each be split into two, one for locally-received/sent information, and another for information on other senders/receivers kept only by monitors.) > RtpSessionInverseEntry ::= SEQUENCE { > rtpSessionInverseIndex Integer32, > rtpSessionInverseStartTime TimeStamp > } It isn't clear to me though, why you need a start time in this table, given that you already have one in the session table. Why is this? Finally, I would point out that row-creation/deletion would be simplified by having the rowstatus object in this table instead of the session table, since you would no longer need the rtpSessionNewIndex object, and it would simplify the implementation of the NMS. (The agent implementation would be pretty much the same, just with one less object to implement, but it would still do whatever reading rtpSessionNewindex did, it would just do it at row creation time in the inverse table.) > First, should it be mandatory or optional? In my opinion, it ought to be mandatory. > Second, should this table be > created manually by the manager rather than being automatically > created by the agent? In my opinion, no. Created automatically by the agent as you have it is much better. -Dave From rem-conf Tue May 18 00:43:23 1999 From rem-conf-request@es.net Tue May 18 00:43:21 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10jeOb-000080-00; Tue, 18 May 1999 00:34:37 -0700 Received: from 98ce8c1e.ipt.aol.com ([152.206.140.30] helo=unknown) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 10jeOZ-00007q-00; Tue, 18 May 1999 00:34:35 -0700 To: From: Subject: BULK MAILING SERVICES AND E MAILING LISTS Date: Fri, 4 Jan 1980 03:17:31 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list BULK MAILING SERVICES AND E MAILING LISTS INC GET MORE FOR YOUR MONEY WITH OUR BULK E MAILING SERVICES (WE GET THRU TO AOL) 50,000 MAILER BONUS ON GENERAL MAILINGS IF ORDER IS PLACED BY WEDNESDAY.20,000 BONUS ON TARGETED. ENDS MAY 19TH WEDNESDAY PLUS SOFTWARE BONUS TO FURTHER YOUR PROFITS. WE HAVE 5 COMPUTERS RUNNING 24HR/7 DAYS WK TO GIVE YOU EXCELLENT SERVICE ! INSTANT SECURE PAYMENTS ON LINE IF ACCESS TO THE NET. WE CAN START TODAY!HELPING YOU FURTHER YOUR PROFITS. WE ALSO HAVE....SAFE E MAIL MILLIONS CD (600,000 targeted biz opp seekers)These are fresh, 3 days old. Software bonus with purchase **WE ADVERTISE ALL PRODUCTS AND SERVICES AND WE MEAN EVERYTHING! 1-800-242-0363 EXT 1784 BONUS SPECIAL EXPIRES MAY 17TH MONDAY. Ask for extention if needed. (50,000 mailer BONUS)WE SELL MAILING LISTS TOO! PRICES INCLUDE BONUSES: GENERAL MAILINGS 125,000 $99.00 200,000 $150.00 250,000 $200.00 500,000 $350.00 1,000,000 $750.00 TARGETED MAILINGS : 35,000 $99.00 50,000 $125.00 120,000 this weeks special is $199.00 HIGHER AMOUNTS PLEASE INQUIRE From rem-conf Tue May 18 01:36:19 1999 From rem-conf-request@es.net Tue May 18 01:36:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jfKe-000504-00; Tue, 18 May 1999 01:34:36 -0700 Received: from typhoon.mail.pipex.net [158.43.128.27] by mail1.es.net with smtp (Exim 1.81 #2) id 10jfKd-0004zu-00; Tue, 18 May 1999 01:34:35 -0700 Received: (qmail 28639 invoked from network); 18 May 1999 08:34:32 -0000 Received: from userk832.uk.uudial.com (HELO mice1) (193.149.72.154) by smtp.dial.pipex.com with SMTP; 18 May 1999 08:34:32 -0000 To: rem-conf@es.net From: Michael@IrelandConferences.com Subject: Your request for availability Organization: Irish Convention Bu Message-Id: Date: Tue, 18 May 1999 01:34:35 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jonathan, As promised we have investigated availability of space here in Dublin for your conference in October '99 and are pleased to tell you that we have found the 350 bedrooms , 4 star hotels, for the 4 nights you want. I am sure this will be a relief to you and your colleagues at Glaxo Wellcome, and I look forward to organisnig your site inspection to Dublin next week. During this trip I will make arrangements for you to meet all the relevant persons from the hotels and conference centre. I look forward to meeting you next week. Mary Murphy Marketing Manager MaryM@IrelandConferences.com If you have an enquiry, please email your request and we will respond with availability, and prices within 24 hours. We will also arrange special air fares for your delegates, and make introductions for you to all the hotels and venues. For more information please email requests@IrelandConferences.com or telephone 00353 16335913. From rem-conf Tue May 18 02:07:49 1999 From rem-conf-request@es.net Tue May 18 02:07:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jfpJ-0005xW-00; Tue, 18 May 1999 02:06:17 -0700 Received: from pelican.tk.uni-linz.ac.at [140.78.188.41] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10jfpE-0005xH-00; Tue, 18 May 1999 02:06:15 -0700 Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA07464 for ; Tue, 18 May 1999 11:06:06 +0200 (MET DST) Reply-To: From: "Michael Welzl" To: Subject: Earlier quality feedback for adaptive applications Date: Tue, 18 May 1999 11:05:52 +0200 Message-ID: <000001bea10d$a2078080$2d5c4e8c@olibaer.Telekooperation> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, First, let me apologize for asking a question not directly related to your current work on payload formats, but I couldn't find an answer to this elsewhere. Currently, the only quality feedback senders of real-time streams can get to change their encoding-type is the RTCP (or some similar) receiver report. From the occurence of reduced bandwidth availability until the RR arrives at the sender, this means: - Bad quality for the receiver - Too much data being unnecessarily loaded on the net If senders would put some information about the necessary bandwidth in the packets they send away, routers could send feedback much earlier if their currently available bandwidth is less than that - forcing the senders to switch to a less consuming encoding scheme, hence reducing net load earlier. Of course, reality is somewhat more complicated than that: This concept would need support for IP multicast (what if one of those routers is close to a leaf of the distribution "tree" ?) and the routers would probably need to do do some calculations (to tell how much bandwidth is available from the current queue status, to deal with short network fallouts etc.), but the basic concept remains the same. I can't believe that this isn't already done one way or another. Please let me know what you think of that idea. Greetings, Michael ---------------------------------------------------------------------- Dipl.-Ing. Michael Welzl Research Assistant Telecooperation Group Dpt. of Computer Science University of Linz Altenberger Str. 69, A-4040 Linz, Austria Phone: +43/732/2468-9264 Fax: +43/732/2468-9829 ICQ # 38201212 http://www.tk.uni-linz.ac.at/~michael/ From rem-conf Tue May 18 02:46:01 1999 From rem-conf-request@es.net Tue May 18 02:46:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jgQo-00079j-00; Tue, 18 May 1999 02:45:02 -0700 Received: from pelican.tk.uni-linz.ac.at [140.78.188.41] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10jgQj-00079U-00; Tue, 18 May 1999 02:45:00 -0700 Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA09057 for ; Tue, 18 May 1999 11:44:53 +0200 (MET DST) Reply-To: From: "Michael Welzl" To: Subject: Earlier quality feedback pt. II Date: Tue, 18 May 1999 11:44:41 +0200 Message-ID: <000001bea113$0d96a6a0$2d5c4e8c@olibaer.Telekooperation> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Two things I forgot to mention in my previous message: 1.) Of course, the mechanisms in the routers would have to take care that their informational reports should not be sent too often, so that we don't increase net load while we want to reduce it :) 2.) The main reason why I decided to post all that here although it's not directly related to current RTP work is that I could imagine this mechanism being part of a new RTP specification. It applies to all realtime-streams, can be used for various different situations (even a receiver-driven variant would be thinkable) and wouldn't need a lot of change in the actual RTP packet format. Greetings, and apologies for splitting this up in two posts, Michael ---------------------------------------------------------------------- Dipl.-Ing. Michael Welzl Research Assistant Telecooperation Group Dpt. of Computer Science University of Linz Altenberger Str. 69, A-4040 Linz, Austria Phone: +43/732/2468-9264 Fax: +43/732/2468-9829 ICQ # 38201212 http://www.tk.uni-linz.ac.at/~michael/ From rem-conf Tue May 18 02:48:17 1999 From rem-conf-request@es.net Tue May 18 02:48:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jgTj-0007K9-00; Tue, 18 May 1999 02:48:03 -0700 Received: from p-biset.issy.cnet.fr [139.100.0.33] by mail1.es.net with smtp (Exim 1.81 #2) id 10jgTi-0007Jq-00; Tue, 18 May 1999 02:48:02 -0700 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2232.9) id ; Tue, 18 May 1999 11:47:59 +0200 Message-ID: <425A62747E7CD111B4570060974B1C6301495272@r-mhs.rennes.cnet.fr> From: LE MINOUS Nicole CNET/DSM/REN To: WEIBEL Xavier THINKONE/TI Cc: SOYER Patrice CNET/DSM/REN , =?iso-8859-1?Q?BABONNEAU_G=E9rard_CNET/DSM/REN?= , BJORGAN Stephen THINKONE/TD , "'arnaud.ansiaux@thinkone.com'" , 'Groupe AVT de l'IETF' Subject: RE: Quality of Service Forum Reception and Network Demo Date: Tue, 18 May 1999 12:00:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bonjour Xavier, Many thanks for your rapid answer. Many thanks in advance to Arnaud too = : Patrice Soyer (who is in charge of QoS from end to end in the DSM/RDC laboratory will probably send him some questions). Regarding our PGM studies, two tasks are going on : -On basis of our SDL/PGM code, we are implementing an OPNET version of = PGM (in order to make performance simulations). It will be ready for = summer. We intend then to test this implementation with different PGM parameters (planned between september and december). -A PGM version of IOS cisco routers is now installed in our laboratory. = We intend to test them with a simple configuration, in order to compare simulation and real results. We intend to use for these trials a simple Cisco test code (which is not commercialized) for source and receivers. Please, feel free to make suggestions about these trials/simulations in order to answer possibly to Continuum's special inquiries. What about your (at Thinkone) relationships with Tibco ? I (here in = France) have some difficulties to make contact since M. Tombroff left. Looking forward to your comments, sincerely, Nicole. ________________________________________________________________ FRANCE TELECOM =20 Nicole LE MINOUS-DAVID BD/CNET/DSM/RDC - CCETT 4, rue du Clos Courtel - BP 59 - 35512 CESSON SEVIGNE cedex -FRANCE Tel : 33-2-99-12-40-67 / Fax : 33-2-99-12-40-98 ________________________________________________________________ > ---------- > De : WEIBEL Xavier THINKONE/TI[SMTP:xavier.weibel@thinkone.com] > Date=A0: jeudi 13 mai 1999 04:24 > A : LE MINOUS Nicole CNET/DSM/REN > Cc : BJORGAN Stephen THINKONE/TD; ANSIAUX Arnaud THINKONE/TI > Objet : RE: Quality of Service Forum Reception and Network Demo >=20 > Bonjour Nicole,=20 >=20 > Arnaud ANSIAUX will go to the conference. He will make a report on = the > meeting. We took the fundings on the NECTAR project. The report will = be > forwarded to you, no worry. >=20 > In the meantime, if you have questions to submit, please feel free to = do > so. We will be more than welcome to ask them for you. >=20 > Regarding Continuum, Steven and myself would like to know more about = the > work you are currently doing on PGM. Can you tell us what the = progress of > your work currently is? >=20 > Sincerely,=20 >=20 >=20 >=20 >=20 > Xavier WEIBEL > R&D Project Manager >=20 > ThinkOne, Inc. >=20 > A joint company of France Telecom & Deutsche Telekom > http://www.thinkone.com >=20 > 1000 Marina Blvd, Suite 300 > BRISBANE, CA 94005, USA >=20 > +1 (650) 875-1515 (P) >=20 > +1 (650) 875-1505 (F) >=20 > email : xavier.weibel@thinkone.com >=20 >=20 >=20 >=20 > -----Original Message-----=20 > From:=A0=A0 LE MINOUS Nicole CNET/DSM/REN [ > mailto:nicole.leminous@cnet.francetelecom.fr]=20 > Sent:=A0=A0 Monday, May 10, 1999 5:52 AM=20 > To:=A0=A0=A0=A0 WEIBEL Xavier THINKONE/TI=20 > Cc:=A0=A0=A0=A0 LE GUYADEC Muri=E8le CNET/DSM/REN; SOYER Patrice = CNET/DSM/REN; > STEFFANN Jean-marc CNET/DSM/ISS=20 > Subject:=A0=A0=A0=A0=A0=A0=A0 TR: Quality of Service Forum Reception = and Network > Demo=20 >=20 > Bonjour Xavier,=20 >=20 > J'espere que tu vas bien depuis tout ce temps et que > l'ambiance n'est pas=20 > trop mauvaise de votre cote de l'Atlantique...=20 > En ce qui me concerne, je n'ai pas eu de nouvelle sur l'avancement > du projet=20 > DEDALE-CONTINUUM mais quoi qu'il en soit nos etudes sur PGM > continuent...=20 > j'espere qu'on aura l'occasion d'en rediscuter prochainement.=20 >=20 > C'est a propos du QoS forum que je t'=E9cris (voir ci-apr=E8s) > car le sujet me=20 > parait tres interessant ! c'est difficile pour nous d'y aller (temps > et=20 > budget) mais peut-etre l'un de vous a-t-il l'intention d'y aller et > pourrait=20 > en faire profiter les autres ???=20 >=20 > Merci de me prevenir si c'est le cas.=20 >=20 > A bientot !=20 >=20 > Nicole.=20 >=20 > =09 > ________________________________________________________________=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FRANCE = TELECOM=A0=A0=A0=A0=A0=A0=A0=A0=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Nicole LE MINOUS-DAVID=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 BD/CNET/DSM/RDC - CCETT=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4, rue du Clos Courtel - BP 59 - = 35512 CESSON SEVIGNE > cedex=20 > -FRANCE=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Tel : 33-2-99-12-40-67 / Fax : = 33-2-99-12-40-98=20 > ________________________________________________________________=20 >=20 > > ----------=20 > > De :=A0 Marty Bickford[SMTP:martinb@stardust.com]=20 > > Date=A0:=A0=A0=A0=A0=A0=A0=A0 vendredi 7 mai 1999 02:51=20 > > A :=A0=A0 rem-conf@es.net=20 > > Objet :=A0=A0=A0=A0=A0=A0 Quality of Service Forum Reception and = Network Demo=20 > >=20 > > The Quality of Service Forum is extending an invitation to join us > at the=20 > > Quality of Service Forum Networking Reception. The highlights of > the=20 > > reception will include the QoS Network Showcase demonstration and > a great=20 > > networking opportunity.=20 > >=20 > > QOSF Reception and QoS Network Showcase=20 > > ---------------------------------------=20 > >=A0 ~ QoS Network Showcase demonstration. We'll demonstrate > end-to-end QoS=20 > > capabilities in an extensive IP network. You'll see the difference > between=20 > > QoS and non-QoS impact on numerous application categories and via=20 > > empirical=20 > > measurement tools that graphically show the traffic impact of QoS=20 > > capabilities. This network reveals current vendor support and=20 > > interoperability between emerging products which support new QoS=20 > > protocols.=20 > >=20 > > Network: http://www.stardust.com/iband2/network.jpg=20 > >=20 > > Description: http://www.stardust.com/iband2/qos-showcase.htm=20 > >=20 > > ~ Great networking opportunity to meet with QOSF members and > non-members,=20 > > ISP's, IP network engineers and the press. You'll learn how the > Quality of=20 > > Service Forum is playing an important role in the adoption of QoS. >=20 > >=20 > > ~ Qosnetics will sponsor the QOSF Reception which will be held in > concert=20 > > with the QOS NetworkShowcase demonstration. You are invited to > attend.=20 > >=20 > > ~ Participating companies include: 3Com, Abatis, Cisco Systems, > Extreme,=20 > > Fujitsu, IBM, Intel, IP Highway, IPivot, Lucent, Microsoft, > Nortel,=20 > > Novell,=20 > > Orchestream, Qosnetics, Xedia, and NetCom Systems.=20 > >=20 > > Logistics=20 > > ---------=20 > > Where: San Francisco Airport Marriott (in coordination with > iBAND2).=20 > >=A0=A0=A0=A0=A0=A0=A0 Signs will assist you to the meeting = location.=20 > > When:=A0 Sunday May 23, 1999 from 6:30pm - 7:30pm=20 > > RSVP:=A0 Please RSVP to Sherryl Alameda by May 19th. > sherryla@stardust.com=20 > >=20 > > iBAND2 - May 23-25, 1999. San Francisco=20 > > ---------------------------------------=20 > > The Quality of Service Forum is an Association Sponsor of iBAND2.=20 > >=20 > > iBAND2 is targeted at IP Network Professionals in enterprise, > service=20 > > provider and carrier organizations. At the heart of the event is a > 3-track=20 > > conference in which the industry's leading technologists and > business=20 > > pioneers give leading edge sessions on the technology, deployment > and=20 > > business of smart bandwidth solutions.=20 > >=20 > > We encourage you to sign-up today at > http://www.stardust.com/iband2/=20 > >=20 > > Nortel Networks is the Platinum Sponsor, Intel and NetCom Systems > are Gold=20 > > Sponsors, the IP Multicast Initiative & the Quality of Service > Forum are=20 > > Alliance Sponsors, and America's Network, Data Communications,=20 > > InternetWeek=20 > > and tele.com are Publication Sponsors of iBAND2.=20 > >=20 > > Sincerely,=20 > > Marty=20 > > ---=20 > > Marty Bickford=A0 - 408.879.8080 (8081-fax)=20 > > Stardust Forums - http://www.stardust.com=20 > >=20 > > iBAND2(sm) - The Internet Bandwidth Management Summit=20 > >=20 >=20 >=20 From rem-conf Tue May 18 03:16:29 1999 From rem-conf-request@es.net Tue May 18 03:16:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jgtq-000118-00; Tue, 18 May 1999 03:15:02 -0700 Received: from monsoon.dial.pipex.net (monsoon.mail.pipex.net) [158.43.128.69] by mail1.es.net with smtp (Exim 1.81 #2) id 10jgto-00010i-00; Tue, 18 May 1999 03:15:00 -0700 Received: (qmail 20795 invoked from network); 18 May 1999 10:14:46 -0000 Received: from userag96.uk.uudial.com (HELO mice1) (62.188.132.182) by smtp.dial.pipex.com with SMTP; 18 May 1999 10:14:46 -0000 To: rem-conf@es.net From: Mary@IrelandConferences.com Subject: Your request for availability Organization: Irish Convention Bu Message-Id: Date: Tue, 18 May 1999 03:15:00 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jonathan, As promised we have investigated availability of space here in Dublin for your conference in October '99 and are pleased to tell you that we have found the 350 bedrooms , 4 star hotels, for the 4 nights you want. I am sure this will be a relief to you and your colleagues at Glaxo Wellcome, and I look forward to organisnig your site inspection to Dublin next week. During this trip I will make arrangements for you to meet all the relevant persons from the hotels and conference centre. I look forward to meeting you next week. Mary Murphy Marketing Manager MaryM@IrelandConferences.com If you have an enquiry, please email your request and we will respond with availability, and prices within 24 hours. We will also arrange special air fares for your delegates, and make introductions for you to all the hotels and venues. For more information please email requests@IrelandConferences.com or telephone 00353 16335913. From rem-conf Tue May 18 05:12:00 1999 From rem-conf-request@es.net Tue May 18 05:11:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jigr-0002YT-00; Tue, 18 May 1999 05:09:45 -0700 Received: from p-voyageur.issy.cnet.fr [139.100.0.39] by mail1.es.net with smtp (Exim 1.81 #2) id 10jigp-0002YJ-00; Tue, 18 May 1999 05:09:43 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2232.9) id ; Tue, 18 May 1999 14:09:36 +0200 Message-ID: <425A62747E7CD111B4570060974B1C6301495273@r-mhs.rennes.cnet.fr> From: LE MINOUS Nicole CNET/DSM/REN To: 'Groupe AVT de l'IETF' Subject: Mistake Date: Tue, 18 May 1999 14:22:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry for the last message : it was a mistake ! ________________________________________________________________ FRANCE TELECOM Nicole LE MINOUS-DAVID BD/CNET/DSM/RDC - CCETT 4, rue du Clos Courtel - BP 59 - 35512 CESSON SEVIGNE cedex -FRANCE Tel : 33-2-99-12-40-67 / Fax : 33-2-99-12-40-98 ________________________________________________________________ From rem-conf Tue May 18 15:05:36 1999 From rem-conf-request@es.net Tue May 18 15:05:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10jru7-0003MP-00; Tue, 18 May 1999 15:00:03 -0700 Received: from mail.nps.navy.mil [131.120.43.89] by mail1.es.net with esmtp (Exim 1.81 #2) id 10jru5-0003MA-00; Tue, 18 May 1999 15:00:01 -0700 Received: from nps.navy.mil (acoustic.stl.nps.navy.mil [131.120.178.143]) by mail.nps.navy.mil (8.8.8/8.8.8) with ESMTP id OAA06230 for ; Tue, 18 May 1999 14:59:52 -0700 (PDT) Message-ID: <3741E2D5.1DE2F447@nps.navy.mil> Date: Tue, 18 May 1999 14:59:49 -0700 From: Don Brutzman Organization: Naval Postgraduate School X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: AVT working group Subject: draft-ietf-avt-mib-05.txt question: MIB in XML? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Apologies if this question is out of scope for the group, redirects welcome. We are beginning to record RTP statistics and are considering XML tags for the data format. Does anyone know of work being done that might map MIB entities to an XML document type definition (DTD)? Looking downstream: should there be an XML DTD as part of the AVT MIB so that such tags are well specified and easily available? all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 831.656.2149 Monterey California 93943-5000 USA fax 831.656.3679 Virtual worlds/underwater robots/Internet http://web.nps.navy.mil/~brutzman From rem-conf Wed May 19 01:04:55 1999 From rem-conf-request@es.net Wed May 19 01:04:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10k1BO-0002PQ-00; Wed, 19 May 1999 00:54:30 -0700 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 10k1BM-0002Ow-00; Wed, 19 May 1999 00:54:28 -0700 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id B3F68BEB0B for ; Wed, 19 May 1999 09:53:17 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Wed, 19 May 1999 11:04:54 +0200 Message-ID: <01BEA1E7.6CA56AD0.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "rem-conf@es.net" Subject: Freeware, Experimentalware Videoconferencing Tools... Date: Wed, 19 May 1999 11:04:53 +0200 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 22 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi; At the moment, we're using the UCL's VIC as a video videoconferencing tool on Windows NT. I'd like to find out about any alternatives (not from the Commercial Sector) for the Windows Platform. I know that Berkeley has a port of VIC as a part of MASH, Microsoft made a port of VIC aswell as Georgia Tech. I wonder if there are any other ports of VIC available. There is also a tool called Rendez-Vous from INRIA. Apart from that, freeware video tools appear to be few and far between. Anyone know any different? As I mentioned before I'm looking for tools for the Windows Platforms and preferably tools which are still being developed and supported. I will be posting the findings on a Web page which I will let the list know about when it is published. Thanks Chris From rem-conf Wed May 19 03:42:47 1999 From rem-conf-request@es.net Wed May 19 03:42:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10k3j2-0004RL-00; Wed, 19 May 1999 03:37:24 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10k3j1-0004RB-00; Wed, 19 May 1999 03:37:23 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 May 1999 11:35:41 +0100 To: "chris@arnes.si" cc: "rem-conf@es.net" Subject: Re: Freeware, Experimentalware Videoconferencing Tools... In-reply-to: Your message of "Wed, 19 May 1999 11:04:53 +0200." <01BEA1E7.6CA56AD0.chris@arnes.si> Date: Wed, 19 May 1999 11:35:38 +0100 Message-ID: <672.927110138@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Chris van der Merwe writes: >At the moment, we're using the UCL's VIC as a video videoconferencing tool >on Windows NT. I'd like to find out about any alternatives (not from the >Commercial Sector) for the Windows Platform. > >I know that Berkeley has a port of VIC as a part of MASH, Microsoft made a >port of VIC aswell as Georgia Tech. I wonder if there are any other ports >of VIC available. To clarify, vic is originally from LBNL (http://www-nrg.ee.lbl.gov/vic/), and UCL distribute a modified version of their code (with additional codecs and some bug-fixes). -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: +44 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Wed May 19 05:54:19 1999 From rem-conf-request@es.net Wed May 19 05:54:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10k5nd-00063G-00; Wed, 19 May 1999 05:50:17 -0700 Received: from galaxy.uci.agh.edu.pl (uci.agh.edu.pl) [149.156.96.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10k5n0-00062h-00; Wed, 19 May 1999 05:49:41 -0700 Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id OAA15984; Wed, 19 May 1999 14:25:44 +0200 (MET DST) Received: from madzia.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA05672; Wed, 19 May 1999 14:20:41 +0200 Received: by madzia.kt.agh.edu.pl (SMI-8.6/SMI-SVR4) id OAA07990; Wed, 19 May 1999 14:20:33 +0200 Date: Wed, 19 May 1999 14:20:33 +0200 From: pach@saturn.kt.agh.edu.pl (Andrzej Pach) Message-Id: <199905191220.OAA07990@madzia.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: nm-australia@amazon.postech.ac.kr Subject: Broadband Access Conference - EXTENDED DEADLINE - MAY 31 ! Cc: nmkorea@amazon.postech.ac.kr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am sorry if you receive more than one copy of this e-mail! ============================================================ EXTENDED DEADLINE - MAY 31 !! Announcement and Call for Papers BROADBAND ACCESS CONFERENCE (BAC99) Cracow, Poland, October 11-13, 1999 http://BAC99.kt.agh.edu.pl/ Sponsored by IEEE Poland Section and Cracow Communications Society Chapter Rapidly growing demand for Internet resources access and emerging broadband interactive applications attracts telecom operators' and service providers' attention to access technologies: copper (xDSL), fibre (FTTx) and wireles (WLL). The conference addresses a full spectrum of issues related to a residential access - from signal level, through network architectures and their life cycle costs up to live field trial description. The conference will help incumbent operators to determine their own technology migration path to the broadband forefront that will match their current status and prospected market niches. The conference programme is organised in three streamed sessions: * Digital Subscriber Line * Fibre in the Loop * Wireless Solutions Submitted extended abstracts will undergo three independent reviews and accepted papers will appear in the conference proceedings. Tutorials ========= Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise of the instructors, and on the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the BAC99 chairs. IMPORTANT DATES =============== * Submission of extended abstracts (max. 5 pages) due: May 31, 1999 * Authors notified: June 30, 1999 * Full paper camera ready due: September 10, 1999 SUBMISSION / REGISTRATION ========================= Submit extended abstracts by e_mail to one of the BAC99 chairs. For registration and general information contact a chair of the BAC99 organising Committee, dr Artur Lason. CONFERENCE COMMITTEE ==================== CONFERENCE CHAIRS Prof. Andrzej R. PACH General Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: pach@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 Prof. Zdzislaw PAPIR Program Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: papir@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 TECHNICAL PROGRAM COMMITTEE =========================== N.E. ANDERSEN, DSC Communications, Denmark K. ASATANI, Univ. Kogakuin, Japan A. AZCORRA, Univ. Carlos III of Madrid, Spain D. BEM, Wroclaw Univ. Of Technology, Poland W. Y. CHEN, Motorola, USA A. CIZMAR, Univ. Kosice, Slovakia A. DOBROGOWSKI, Poznan Univ. of Technology, Poland A. DZIECH, AGH Cracow Univ., Poland A.L. EKBLAD, Telia, Sweden U. FERRERO, CSELT, Italy K.-P. HO, Chinese Univ., Hong Kong A. JAJSZCZYK, ITTI Ltd. And ATR, Poland T. KESSLER, Deutsche Telecom, Germany K. KIKUSHIMA, NTT, Japan S. KUMAR, Ericsson, USA B. ORTH, Deutsche Telekom, Germany K. PAHLAVAN, Worcester Pol., USA T. POLLET, Bell Alcatel, Belgium M. POUSA, CET, Portugal S. SAY, Next Level Commun., USA A. SIMMONDS, Sheffield Hallam Univ., UK P. SPRUYT, Bell Alcatel, Belgium R. VALADAS, Univ. Aveiro, Portugal M. YANO, Fujitsu, Japan ORGANISING COMMITTEE ==================== Chair: Dr. Artur LASON Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: lason@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 From rem-conf Wed May 19 17:01:16 1999 From rem-conf-request@es.net Wed May 19 17:01:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kGCM-0000z5-00; Wed, 19 May 1999 16:56:30 -0700 Received: from ctral1.vanderbilt.edu [129.59.1.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kGCJ-0000yc-00; Wed, 19 May 1999 16:56:27 -0700 Received: from ci39026-a (A162131.N1.Vanderbilt.Edu) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #U3177) id <01JBE4B5S1A88WW39Y@ctrvax.Vanderbilt.Edu> for rem-conf@es.net; Wed, 19 May 1999 18:53:12 CDT Received: from ci39026-a (A162131.N1.Vanderbilt.Edu) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #U3177) with SMTP id <01JBE4AYB9RW8WW4BE@ctrvax.Vanderbilt.Edu>; Wed, 19 May 1999 18:52:46 -0500 (CDT) Date: Wed, 19 May 1999 18:35:35 -0500 From: Bezalel Gavish Subject: 8th International Conference on Telecommunication Systems - CFP X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: <01JBE4AYDMJI8WW4BE@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_/+FToppAswCI9aR5dxV1pA)" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Boundary_(ID_/+FToppAswCI9aR5dxV1pA) Content-type: text/plain; charset="us-ascii" Enclosed is a copy of the Call for Papers for the 8th International Conference on Telecommunication Systems which will be held March 9-12, 2000 in Nashville, TN, USA I look forward to see you at the conference. Sincerely yours, Bezalel Gavish --Boundary_(ID_/+FToppAswCI9aR5dxV1pA) Content-type: text/plain; charset="us-ascii" Content-disposition: attachment; filename="CFPs 002.txt" C A L L for P A P E R S 8th International Conference on Telecommunication Systems, Modeling and Analysis March 9-12, 2000 Nashville, Tennessee, USA Sponsors: American Telecommunication Systems Management Association BellSouth Telecommunications, Inc. IFIP WG 7.3 "Computer system modeling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Owen Graduate School of Management, Vanderbilt University Vanderbilt Institute of Public Policy Studies http://munin.utdallas.edu/atsma/icts/icts2000.html The 8th International Conference on Telecommunication Systems - Modeling and Analysis will be held in Nashville on March 9-12, 2000. The conference will build on the tradition of the earlier conferences. The general idea is to encourage informal interaction and exchanges of ideas by limiting the number of participants, concentrating on a few topics, and by presenting new problems and problem areas. The objective is to advance the state of the modeling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. Papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. Abstracts and papers should be submitted directly to a Program Committee member who will handle its review. It is expected that this will expedite the paper review process. Social and cultural activities will be included in the 2000 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tennessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the ClubHouse Inn & Conference Center. (See description at the end of the message). Listed below are some of the potential segments: -- Configuration of ATM Networks -- DSL and Cable Based Systems -- Internet and its Impact on Commerce -- Internet and Intranet -- Mobility and Nomadicity -- Multimedia modeling and analysis -- Pricing and Economic Analysis of Internet and E-commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low and Medium Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modeling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Network Reliability, Availability and Survivability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact -- Standards The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is, whenever possible, to limit the number of parallel sessions to three. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, and to enable participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the Downtown area. Members of the Program Committee include: Abdullah Al-Dhelaan, King Saud University, Saudi Arabia Kemal Altinkemer, Purdue University, USA Mario Baldi, Politecnico di Torino, Italy Suk-Gwon Chang, Hanyang University, Republic of Korea Imrich Chlamtac, University of Texas at Dallas, USA Laurie G. Cuthbert, Queen Mary & Westfield College, UK Lou Dellaverson, Motorola, Radio Research Lab, USA Piet Demeester, University of Ghent - IMEC, Belgium Bezalel Gavish(Chairman), Vanderbilt University, USA Luis Gouveia, Universidade de Lisboa, Portugal Horst W. Hamacher, Universitaet Kaiserslautern, Germany Richard J. Harris, Royal Melbourne Institute of Technology, Australia Frank Huebner, AT&T Labs, USA Joakim Kalvenes, The University of Texas at Dallas, USA Johan M. Karlsson, Lund Institute of Technology, Sweden Konosuke Kawashima, NTT Advanced Technology Corp., JAPAN Hans Kruse, Ohio University, USA Nikos E. Mastorakis, Hellenic Naval Academy, Greece Armin R. Mikler, University of North Texas, USA Sverrir Olafsson, BT Laboratories, UK June S. Park, The University of Iowa, USA Hasan Pirkul, University of Texas at Dallas, USA Guy Pujolle, University of Versailles, France Dimitrios N. Serpanos, Foundation for Research and Technology - Hellas, Greece Yutaka Takahashi, Kyoto University, Japan J. L. van den Berg, KPN Research, The Netherlands Lipo Wang, Nanyang Technological University, Singapore Lars C. Wolf, Darmstadt University of Technology, Germany Due to the limit on the number of participants, early conference and hotel registration is recommended. The ClubHouse Inn & Conference Center is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to a Program Committee member, by September 15, 1999, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts and papers. If you would like to organize a panel on a specific subject, please send the proposal to Bezalel Gavish. 2. Use the forms at the end of this message to pre-register for the conference and the hotel. Let us also know if you would like to have a formal duty during the conference such as: Session Chair, or Discussant. 3. You will be notified by December 1, 1999, which abstract(s)/paper(s) have been selected for the conference. Detailed instructions on how to prepare camera-ready copies will be sent to authors of accepted presentations.February 1, 2000, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. 4. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" journal. If you do not wish for your paper to be submitted for publication consideration in the "Telecommunication Systems" journal, please specify it in the cover letter of your submission. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Professor Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to a Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish The 5th Informs Telecommunications Conference, BOCA 2000 sponsored by the Informs section on telecommunications will be held March 5-8, 2000 in Boca Raton, Florida. The conference announcement can be found at, http://www.crt.umontreal.ca/GERAD/boca2000/. The dates were selected so that you will be able to participate in both conferences. ----------------------------------------------------------------------- Cut Here ----------------------------------------------------------------------- Eighth International Conference on Telecommunication Systems Modeling and Analysis REGISTRATION FORM Dates: March 9, 2000 (afternoon) to March 12, 2000 Date: ______________ Name: ________________________________________ Title: ________________ Affiliation: ____________________________________________________________ Address: ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Phone: ____________________________ FAX: ____________________ E-mail: ____________________________________________________________________ Potential Title of Paper(s): _______________________________________________ ____________________________________________________________________________ I would like to Volunteer as Comments A Session Chair: Yes No _________________________________________ A Discussant: Yes No _________________________________________ Organize a Session: Yes No _________________________________________ _________________________________________ REGISTRATION RATES and DEADLINES: (Included in the registration fee are: Conference proceedings, a reception, two dinners, two lunches, coffee breaks, and cultural events.) Last Applicable Academic Industry Corporate Date Rate Rate Rate --------------- -------- -------- -------- 1. Pre-registration Until Dec. 15, 1999 $ 430 $ 550 $1,500 2. Registration Until Feb. 1, 2000 $ 530 $ 650 $1,500 3. On Site Registration After Feb. 1, 2000 $ 630 $ 800 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association". Please mark an "X" in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I do not wish to become an ATSMA member. Mail your registration form and check to: Ms. Dru Lundeng ATSMA, Inc. Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA Checks should be made payable to: ATSMA, Inc., Eighth Telecommunication Conference Refund Policy: Half refund, for requests received by January 15, 2000. No refund after January 15, 2000. ---------------------------------------------------------------------- HOTEL RESERVATIONS A block of rooms has been reserved at the ClubHouse Inn & Conference Center for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the "TELECOMMUNICATION SYSTEMS CONFERENCE," to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference block on February 7, 2000, so PLEASE BE SURE AND RESERVE YOUR ROOMS BEFORE FEBRUARY 7, 2000. ClubHouse Inn & Conference Center 920 Broadway at Tenth Avenue Nashville, TN 37203 USA Phone: 615-244-0150 or 1-800-258-2466 (Ask to be connected with the Nashville-Downtown ClubHouse.) Fax:615-244-0445 http://www.clubhouseinn.com RATES: $110.00 Single Occupancy Room $136.00 Double Occupancy Room $15.00 For Each Additional Person in the Room Rates are subject to state and local taxes, which currently total 12.25 percent. All rates include a complimentary full breakfast buffet each morning, also, each evening, ClubHouse offers a Managers' Reception serving complimentary beverages. Guests also receive free local phone calls. ACCESS INFORMATION: Recommended Airport: Nashville International Airport, 7 miles to the East. Transportation: Gray Line's "Downtown Airport Express" - A shuttle from Nashville International Airport to downtown hotels. Hours: 6:00 a.m. - 11:00 p.m. daily. Cost: $9.00 one way, $15.00 round trip. The shuttle can be caught at the lower level of the airport near baggage claim. Phone: 615-275-1180; 800-669- 9463 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CLUBHOUSE INN & CONFERENCE CENTER Reservation Request Form NAME OF CONFERENCE: 8th Int'l. Conference on Telecommunication Systems ("TELECOMMUNICATION SYSTEMS CONFERENCE") Reservations can be made at the following URL: http://www.clubhouseinn.com/5.reservations.shtml or Phone: 615-244-0150 Fax: 615-244-0445 You can also use the following form to mail or fax your reservation. MAIL/FAX TO: Reservations Manager ClubHouse Inn and Conference Center 920 Broadway Nashville, TN 37203 GUEST INFORMATION: Arrival Date: _______________________________________________________ Departure Date: _______________________________________________________ Time of Arrival: _______________________________________________________ No. of Rooms: _______________________________________________________ No. of People: _______________________________________________________ Guest Name: _______________________________________________________ Address: _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ Phone: _______________________________________________________ PAYMENT METHOD: [ ] Check or Money Order No:_______________ Amount:_______________ [ ] Credit Card Type:_____________ No:___________________ Expiration date:____________ Amount:_______ TYPE OF ROOM: [ ] Kingsize Bed [ ] Double Beds [ ] Smoking [ ] Nonsmoking Please note the ClubHouse Inn and Conference Center requires a deposit of one (1) night's room revenue or credit card to confirm all reservations. Any cancellations or no shows without forty-eight (48) hour advance notification will result in forfeiture of deposit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Travel Arrangements The official travel agent for the Conference is Betsie Wilkerson with Horizon Travel. Her e-mail address is: HORIZON4U and her phone numbers are: 615-383-7882 and 1-800-828-5529 Fax: 615-383-9181 --Boundary_(ID_/+FToppAswCI9aR5dxV1pA) Content-type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu --Boundary_(ID_/+FToppAswCI9aR5dxV1pA)-- From rem-conf Wed May 19 17:22:19 1999 From rem-conf-request@es.net Wed May 19 17:22:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kGYy-0001mc-00; Wed, 19 May 1999 17:19:52 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kGYx-0001mS-00; Wed, 19 May 1999 17:19:51 -0700 Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA04559; Wed, 19 May 1999 20:19:49 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id UAA00379; Wed, 19 May 1999 20:19:49 -0400 (EDT) (envelope-from lennox) Date: Wed, 19 May 1999 20:19:49 -0400 (EDT) Message-Id: <199905200019.UAA00379@conrail.cs.columbia.edu> From: Jonathan Lennox To: mbone@isi.edu, rem-conf@es.net Subject: UDPTunnel: a tool to tunnel UDP over a TCP connection X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UDPTunnel is a small program which can tunnel UDP packets bi-directionally over a TCP connection. Its primary purpose (and original motivation) is to allow multimedia conferences to traverse a firewall which allows only outgoing TCP connections. Information and source code is available at . We are considering adding this tool to the RTPTools suite in the future. Comments are welcome. -- Jonathan Lennox lennox@cs.columbia.edu From rem-conf Thu May 20 08:41:33 1999 From rem-conf-request@es.net Thu May 20 08:41:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kUlw-0002T9-00; Thu, 20 May 1999 08:30:12 -0700 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kUlq-0002Sr-00; Thu, 20 May 1999 08:30:10 -0700 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id E2283BEBD9 for ; Thu, 20 May 1999 17:28:59 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Thu, 20 May 1999 18:40:16 +0200 Message-ID: <01BEA2F0.3482F140.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "rem-conf@es.net" Subject: Synchronization of Video and Audio... Date: Thu, 20 May 1999 18:40:15 +0200 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 29 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All; After some videoconference testing on our local LAN, we came to some strange results. First let me note that we are using the stable versions of UCL's ports of VIC and RAT. Our Video fared very well, using H.261 even on the 1 (highest) quality setting, we experienced very little lag. However the Audio met with less success, using first DVI and then Linear16 and PCM we experienced rather long delays (well over a second, possibly two). I must admit, going into the experiment, I expected the Audio to fare better than the Video. The reality, however was different and the Audio consistantly arrived well after the Video (as mentioned above well over a second or two, Video appeared fairly instantaneously). So now after this experiment, I wonder if anyone could recommend any remedies for this situation. I see that the experimental version of RAT >from UCL supports syncing to video via the conference bus, would using the experimental version help? Also there is a experimental version of VIC (but no binaries at this stage I believe) Does VIC support syncronization at this stage? One thing we tried was Apple's Quicktime for receive-only, the synchronization between audio and video was fairly good, but the delay was very long (a few seconds!). Our goal at the moment though is videoconferencing and distance learning so we need two communication. Sorry that was a bit long, hope anyone can shed some light though. Thanks Chris From rem-conf Thu May 20 09:52:10 1999 From rem-conf-request@es.net Thu May 20 09:52:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kW0L-00044z-00; Thu, 20 May 1999 09:49:09 -0700 Received: from inet-user-gw-1.us.oracle.com [192.86.155.82] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kW0K-00044p-00; Thu, 20 May 1999 09:49:08 -0700 Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with SMTP id JAA16211 for ; Thu, 20 May 1999 09:46:20 -0700 (PDT) Received: from us.oracle.com by usmail04 with ESMTP (SMI-8.6/37.9) id JAA22545; Thu, 20 May 1999 09:49:06 -0700 Message-ID: <37443CF4.AAF5C629@us.oracle.com> Date: Thu, 20 May 1999 09:48:52 -0700 From: Dirk Pranke Organization: Oracle Corporation X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP server software Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are there any freely available RTP streaming servers capable of streaming RTP from QuickTime/AVI movies, as opposed to raw RTP elementary streams or as capture encoders? I'm looking for a test server, and don't want to have to capture broadcasts just to test my RTP playback. I believe I can use RAT to do audio-only streams (using AU or WAV files), but I'm not aware of anything that can stream A/V together, except for the new QT Streaming Server, but that only runs on Mac OS X, which I don't have anywhere. Thanks in advance, -- Dirk From rem-conf Thu May 20 09:52:10 1999 From rem-conf-request@es.net Thu May 20 09:52:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kW0u-00048C-00; Thu, 20 May 1999 09:49:44 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10kW0s-000480-00; Thu, 20 May 1999 09:49:43 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 May 1999 17:49:16 +0100 To: "chris@arnes.si" cc: "rem-conf@es.net" Subject: Re: Synchronization of Video and Audio... In-reply-to: Your message of "Thu, 20 May 1999 18:40:15 +0200." <01BEA2F0.3482F140.chris@arnes.si> Date: Thu, 20 May 1999 17:49:14 +0100 Message-ID: <7823.927218954@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Chris van der Merwe writes: >Hi All; > >After some videoconference testing on our local LAN, we came to some >strange results. >First let me note that we are using the stable versions of UCL's ports of >VIC and RAT. >Our Video fared very well, using H.261 even on the 1 (highest) quality >setting, we experienced very little lag. >However the Audio met with less success, using first DVI and then Linear16 >and PCM we experienced rather long delays (well over a second, possibly >two). I must admit, going into the experiment, I expected the Audio to fare >better than the Video. The reality, however was different and the Audio >consistantly arrived well after the Video (as mentioned above well over a >second or two, Video appeared fairly instantaneously). >So now after this experiment, I wonder if anyone could recommend any >remedies for this situation. I see that the experimental version of RAT >from UCL supports syncing to video via the conference bus, would using the >experimental version help? Also there is a experimental version of VIC (but >no binaries at this stage I believe) Does VIC support syncronization at >this stage? I would suspect that many of your problems are due to the playout calculation in rat-3.0.x, which is known to be rather broken. If you try rat-4.0.x from the experimental page the delay should be much lower. I don't think vic supports synchronisation with rat, although it's something we intend to add back in in the near future. Cheers, Colin From rem-conf Thu May 20 10:39:44 1999 From rem-conf-request@es.net Thu May 20 10:39:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kWlK-00062Y-00; Thu, 20 May 1999 10:37:42 -0700 Received: from havoc.maxagility.com (havoc.entera.com) [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kWlI-000627-00; Thu, 20 May 1999 10:37:40 -0700 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-52658U100L100S0V35) with SMTP id AAA266; Thu, 20 May 1999 10:44:56 -0700 Message-Id: <3.0.6.32.19990520103708.0096eb90@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 20 May 1999 10:37:08 -0700 To: Dirk Pranke ,rem-conf@es.net From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTP server software In-Reply-To: <37443CF4.AAF5C629@us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Check out http://www.streamingserver.org At 09:48 AM 5/20/99 -0700, Dirk Pranke wrote: >Are there any freely available RTP streaming servers capable of >streaming RTP from QuickTime/AVI movies, as opposed to raw RTP >elementary streams or as capture encoders? I'm looking for a test >server, and don't want to have to capture broadcasts just to test my >RTP playback. I believe I can use RAT to do audio-only streams >(using AU or WAV files), but I'm not aware of anything that can stream >A/V together, except for the new QT Streaming Server, but that >only runs on Mac OS X, which I don't have anywhere. > >Thanks in advance, > >-- Dirk > > -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 925 730 2225 From rem-conf Thu May 20 11:45:03 1999 From rem-conf-request@es.net Thu May 20 11:45:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kXjP-0007OU-00; Thu, 20 May 1999 11:39:47 -0700 Received: from mail.nps.navy.mil [131.120.43.89] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kXjN-0007OK-00; Thu, 20 May 1999 11:39:45 -0700 Received: from cs.nps.navy.mil (slippc10.cs.nps.navy.mil [131.120.1.180]) by mail.nps.navy.mil (8.8.8/8.8.8) with ESMTP id LAA08879 for ; Thu, 20 May 1999 11:39:36 -0700 (PDT) Message-ID: <374456BA.404A84D9@cs.nps.navy.mil> Date: Thu, 20 May 1999 11:38:50 -0700 From: Francisco Afonso X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: draft-ietf-avt-mib-05.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have some comments: a) Why using SNMP/MIB if most information( except round trip time ) can be taken from RTCP incomming packets ? b) Why the cummulative number of senders and receivers that joined the session and the cummulative number of BYEs received are important ? This data will vary between participants depending when the session was started. These are the only statistical data about the session. Shouldn't other data be added, as the number of active and passive participants, or the number of bad RTP/RTCP packets received ? c) The MIB only stores the last information about the session. So, when a new feedback from an SSRC to another SSRC arrives, the previous report is lost. Perhaps it would be useful if it could store statistics over time, say, last hour. I think that would help in detecting and diagnosing faults. Francisco Afonso Naval Postgraduate School From rem-conf Thu May 20 12:51:21 1999 From rem-conf-request@es.net Thu May 20 12:51:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kYmg-00011Y-00; Thu, 20 May 1999 12:47:14 -0700 Received: from calliope1.fm.intel.com [132.233.247.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kYmf-00011H-00; Thu, 20 May 1999 12:47:13 -0700 Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id MAA27327 for ; Thu, 20 May 1999 12:47:12 -0700 (PDT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 May 1999 12:47:12 -0700 Message-ID: From: "Baugher, Mark" To: "'Dave Thaler'" Cc: rem-conf@es.net Subject: RE: Review of draft-ietf-avt-mib-05.txt Date: Thu, 20 May 1999 12:47:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, Seems that we have three threads going on here. Let's try to resolve some of the issues in this note, then we can go back to the rtpSessionInverseTable thread, and finally there are a list of smaller issues that we discuss when the more structural questions are answered. ok? > -----Original Message----- > From: Dave Thaler [mailto:dthaler@dthaler.microsoft.com] > Sent: Thursday, May 13, 1999 5:58 PM > To: mbaugher@rdrop.com > Cc: dthaler@dthaler.microsoft.com; rem-conf@es.net > Subject: Re: Review of draft-ietf-avt-mib-05.txt > > > Mark, thanks for the response. My answers below. > > > > (a) Detecting faults in RTP sessions > > > If the NMS wants to detect faults, then it needs to either > > > poll objects that can answer the necessary questions, or > > > receive asynchronous notification. The MIB currently contains > > > no traps, so I ask: should it? (If not, the DISMAN Expression > > > and Event MIBs together might provide a sufficient > alternative.) > > > > We discussed traps and implemented one in a prototype. The trap did > > not seem to be a "must have" feature so we did not include it in > > any draft version of the MIB. I did not like putting such a feature > > in hosts to detect problems because of the obvious issue of > > many hosts reporting similar problems. I think it is better to put > > this function in a management application when polling is > not too great > > a burden on the network or systems. I think polling a monitor may > > be a better solution than asynchronous notifications from multicast > > receivers. > > I agree that you probably don't want traps from receivers. > However, an NMS probably would want traps from monitors. > For the monitor, we polled. Our management application permitted thresholds to be set on a variety of objects, such as loss, and these objects were polled to support a green/yellow/red type of indication on conditions of interest. I can't think of any events in the RTP MIB where there is a clear advantage to asynchronous notifications over polling. >> >> In host mode, the rtpSenderTable entry is kept by the sender and the >> rtpRcvrTable entry is kept by the receiver, which won't have the >> rtpSenderPackets object. > >That's not quite what the DESCRIPTION of rtpSenderTable says. >It says that a receiver host MAY have rows in the sender table >for each active source. THIS IS WHAT CAUSES THE PROBLEM, >since you have to wade through everything else to find out >what (if anything) the device itself is sourcing. We should have clearly stated that remote senders that are observed have entries in the rtpSenderTable when rptSessionMonitor is true. The DESCRIPTION clause you cite is unclear and should be clarified. Since we have the model that the RTP SNMP agent may be simple and the management application competent, we push the processing off the agent to the management app. So, if there is no manageable control layer for a particular RTP application, and if the RTP agent allows a management application to turn on monitoring, and if the monitoring management application does not collect management information such as to correlate SSRC with the sender or receiver TAddress, then the management application would have to 'wade through' information to identify local from remote senders. I think I do understand the issue you raise here. > >In my opinion, you'd be much better off separating this into >two tables, one table for what the device itself is sourcing, >and another table for what remote sources it's receiving from. This would make matters much worse. Now, in order to answer the 'who is sending' (or 'who is receiving') question, we would have to ask 'who is sending locally' and 'who is sending remotely' and then merge the results. since a local sender is just as much as a sender to a session as a remote one (same too for receivers), we could duplicate the local sender information into a single table but this would likely lead to consistency problems in many implementations in addition to redundancy. > >Without doing this separation, I still do not believe the MIB >effectively supports fault diagnosis. If there is a problem of filtering local and remote sender/receiver information that is received by an NMS from a monitor, and if we want the agent rather than the management application to do the filtering, then separating the table is overkill, is it not? > >(I do accept your answer about why you need each of >rtpSenderPackets, rtpRcvrLostPackets, and rtpRcvrPackets, >as long as it's optional for the receiver to keep a sender table.) > >> > Likewise, 3b can be answered by polling rtpSenderOctets, so >> > I think the MIB is fine here. >> > >> > (b) Diagnosing faults in RTP sessions >> > I'll cover all the other questions here. >> > 1a) I don't see any good way to answer this question >> > without walking the entire rtpSenderTable. This can >> > be very expensive, especially if there are either a bunch >> > of streams the device is receiving-only, or a bunch of other >> > senders to ones it is sending to, so I don't consider this >> > question effectively answered by this MIB. >> > >> > Also, how do you know what SSRC value the >> > managed device is using? >> >> I discuss the case of monitor mode several paragraphs below. >> >> In host mode, every entry in the rtpSenderTable is a stream being >> sourced by the managed device. So every entry is of interest. > >See my comment above. The DESCRIPTION clause of rtpSenderTable >contradicts your answer here. If you fix the description to >say explicitly that every entry in this table, regardless of >whether the device is a receiver host, or a monitor, or both >(which I assume must be legal), is for a stream the device is >sourcing, then this table is fine. I also addressed this above. > >It doesn't support asking a monitor or a receiver what OTHER >sources there are though, you'd need a separate table for that >as I mentioned above. > >> > 1b) rtpSenderOctets would be fine if you could answer 1a. >> > >> > 2a) It isn't clear to me whether you can discover what >> > sessions the device is receiving by walking the >> > rtpSessionTable, >> > or whether you need to walk the entire rtpRcvrTable. >> > (Does an entry in rtpSessionTable necessarily imply it's >> > receiving RTP and not just RTCP? If not, walking >> > the rtpRcvrTable may be very inefficient.) >> >> If the sender is not sending RTP or if the receiver is not >> receiving RTP, eventually each should stop sending RTCP - >> implementations are supposed to have a timeout parameter. >> >> Data about sessions that the device is receiving is in the >> rtpRcvrTable. Again, in host mode all entries in the >> rtpRcvrTable are of interest so there is no inefficiency >> in walking the table. > >I don't think this supports an entity which is both a monitor >and a receiving host does it? This sounds broken to me. >Again, I would expect to see two separate tables. addressed above. > >> > 2b) I don't see an easy way to answer this question using >> > the rtpRcvrTable. I suppose you'd have to do a GET-NEXT >> > to find the next rtpSessionIndex and rtpRcvsSRCSSRC >> > values, and then a GET for the device's rtpRcvrSSRC value, >> > and repeat until the end of the table. (Again, how do you >> > know what its SSRC value is?) >> >> My comments about host mode and the type of application (e.g., H.323, >> loosely-coupled conferencing) that I made above apply here. We would >> poll rtpRcvrOctets values to answer 2b. >> >> > 3a) Source enumeration is fine once you've found the >> > rtpSessionIndex. However, it appears to be impossible >> > to locate the rtpSessionIndex without walking the >> > rtpSessionTable, which could be very inefficient. >> > So I don't consider this question effectively answered >> > either. >> >> This is a good point that keeps coming up given the approach we have >> taken. Why do we do this? As you know, there's a space-time tradeoff >> and there is a tradeoff between NMS complexity and agent complexity. >> We could merge the Session table and the Sender table as well as the >> Session table and the Receiver table. This would reduce the number >> of requests that an NMS would need to make at the expense of a lot >> of redundant data in the host tables; we would practically double >> our table size and this seemed to be a bad approach since some >> RTP applications use multicast or are call gateways. There are also >> issues with the length of OIDs when there are many, particularly >> non-integer, indexes, and our composite Session-Sender and >> Session-Rcvr tables would have many such indices. We opted to keep >> the tables as small as they could be and to use very simple indexing. > >In my opinion, this was a bad decision. > >OIDs can be up to 128 subids long, are typically never seen >by a human, and the length of the OID has a negligible effect on >performance. I think this statement is wrong. OIDs are contained in the varbinds of every object you access and this is a SN problem for SNMP that we must handle in the MIB. Early versions of SNMP agents had a minimum PDU size of slightly more than 500 bytes so you could easily fill every packet with information about the information being accessed. I don't read any such lower bound in SNMPv2 but PDU length is negotiated between agent and manager. The length of the OIDs used for indexing have a very great impact on performance, namely message overhead. > >On the other hand, requiring an NMS to walk an entire table >just to locate the one entry it wants can have a huge effect >on performance, and is bound to be noticeable by a human. This is the same NMS that turned on the monitoring bit but failed to collect information from the table to correlate addresses with SSRCs, etc. > >The agent implementation appears simpler WITHOUT a "special" integer, >since it need not find an unused integer when it wants to >add a row, or store any value other than what it already has to store >anyway. I disagree. The agent will need to parse OIDs and then map them to a table location (e.g., find a "special" integer), and this increases the overhead required for the management function in the managed device. Finding an integer is an increment operation, modulo some number, right? > >The NMS implementation appears simpler WITHOUT a "special" integer, >since it can directly access the information it needs without >having to have lots of code to parse the whole table. > Once again, the design of this MIB pushes complexity from the agent to the manager. We are not trying to minimize code or path length in the manager but in the agent. >> Finally, it is not a problem in hosts. > >I disagree. A host could easily be participating in a large number >of low-bandwidth sessions, and walking the whole table in this >case is just as bad as it is in a monitor. The point I made in the previous note is that all of the entries in the host table are of interest so there is no 'wading' or 'filtering' problem for management applications of RTP hosts. > >> At present, we cannot access the rtpSessionTable based upon >> the TAddress pair that identify an RTP session - an integer >> index is used to reduce the size of OIDs in Gets against this >> table and to make it simpler for the agent. How could we eliminate >> this and still minimize table size and use simple indexes? Perkins >> gives an example solution using inverse indexing: We could create >> another table that is indexed by the TAddress pair of the >> rtpSessionTable and which has one non-index column - >> rtpSessionIndex. > >That would be one acceptable solution, yes. > >> This has come up in previous discussions at least three times. > >Sounds like consensus that there's a problem then :) Well, no. After the discussion we would ask the person asking for the feature if they wanted to implement it. Once the alternative ways of getting the needed information were uncovered, each said 'no' they would not implement it. > >> Each time we came to the conclusion that a table indexed by the >> TAddress pair that returns rtpSessionIndex could easily be added >> if shown to be essential. > >I strongly believe that it is essential. ok. would you make it optional or mandatory? I think it should be optional since H-series and potentially some other management applications do not need it and should not be forced to implement it. thanks, Mark >(Either that or index the session table by the address.) > >> I like your points. I think we satisfy them. > >Obviously, I disagree. :) > >-Dave > > From rem-conf Thu May 20 13:48:41 1999 From rem-conf-request@es.net Thu May 20 13:48:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kZgv-0002pJ-00; Thu, 20 May 1999 13:45:21 -0700 Received: from firebreath.prognet.com (virginia.dev.prognet.com) [204.71.154.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kZgu-0002p9-00; Thu, 20 May 1999 13:45:20 -0700 Received: from virginia (virginia@localhost [127.0.0.1]) by virginia.dev.prognet.com (8.7.5/8.7.3) with SMTP id NAA25541; Thu, 20 May 1999 13:44:15 -0700 Sender: virginia@virginia.dev.prognet.com Message-ID: <3744741E.29B2FC41@real.com> Date: Thu, 20 May 1999 13:44:14 -0700 From: Virginia Thomas Organization: RealNetworks,Inc X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.0.27 i586) MIME-Version: 1.0 To: Dirk Pranke CC: rem-conf@es.net Subject: Re: RTP server software References: <37443CF4.AAF5C629@us.oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The RealServer streams au and wav over RTP in when configured for scalable multicast. Download the evaluation version of the "Hosting Server" at: http://proforma.real.com/mario/eval/download.html - Virginia Dirk Pranke wrote: > > Are there any freely available RTP streaming servers capable of > streaming RTP from QuickTime/AVI movies, as opposed to raw RTP > elementary streams or as capture encoders? I'm looking for a test > server, and don't want to have to capture broadcasts just to test my > RTP playback. I believe I can use RAT to do audio-only streams > (using AU or WAV files), but I'm not aware of anything that can stream > A/V together, except for the new QT Streaming Server, but that > only runs on Mac OS X, which I don't have anywhere. > > Thanks in advance, > > -- Dirk From rem-conf Thu May 20 14:32:27 1999 From rem-conf-request@es.net Thu May 20 14:32:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kaNT-0004Mu-00; Thu, 20 May 1999 14:29:19 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kaNR-0004Mk-00; Thu, 20 May 1999 14:29:17 -0700 Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA16257; Thu, 20 May 1999 14:29:10 -0700 (PDT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 May 1999 14:29:10 -0700 Message-ID: From: "Baugher, Mark" To: "'Don Brutzman'" , AVT working group Subject: RE: draft-ietf-avt-mib-05.txt question: MIB in XML? Date: Thu, 20 May 1999 14:29:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Don I don't think this is within the scope of the RTP MIB. There is a list for general discussion of MIB-related issues at mibs-request@ops.ietf.org - though I'm not sure it is an SMI or SNMP issue, properly considered Mark > -----Original Message----- > From: Don Brutzman [mailto:brutzman@nps.navy.mil] > Sent: Tuesday, May 18, 1999 3:00 PM > To: AVT working group > Subject: draft-ietf-avt-mib-05.txt question: MIB in XML? > > > Apologies if this question is out of scope for the group, > redirects welcome. > > We are beginning to record RTP statistics and are considering XML tags > for the data format. Does anyone know of work being done > that might map > MIB entities to an XML document type definition (DTD)? > > Looking downstream: should there be an XML DTD as part of the AVT MIB > so that such tags are well specified and easily available? > > all the best, Don > -- > Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 > work 831.656.2149 > Monterey California 93943-5000 USA > fax 831.656.3679 > Virtual worlds/underwater robots/Internet > http://web.nps.navy.mil/~brutzman > From rem-conf Thu May 20 16:14:17 1999 From rem-conf-request@es.net Thu May 20 16:14:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kbz2-0006AJ-00; Thu, 20 May 1999 16:12:12 -0700 Received: from (dthaler.microsoft.com) [131.107.1.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kbyv-0006A9-00; Thu, 20 May 1999 16:12:05 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id RAA18882; Thu, 20 May 1999 17:57:18 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199905210057.RAA18882@dthaler.microsoft.com> Subject: Re: Review of draft-ietf-avt-mib-05.txt In-Reply-To: from "Baugher, Mark" at "May 20, 1999 12:47:11 pm" To: mbaugher@intel.com (Baugher Mark) Date: Thu, 20 May 1999 17:57:18 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > I agree that you probably don't want traps from receivers. > > However, an NMS probably would want traps from monitors. > > > For the monitor, we polled. Our management application permitted > thresholds to be set on a variety of objects, such as loss, > and these objects were polled to support a green/yellow/red > type of indication on conditions of interest. I can't > think of any events in the RTP MIB where there is a clear > advantage to asynchronous notifications over polling. One event would be when the packet loss seen by a given receiver (say, the monitor itself) crosses some threshold. In this case, polling would be unnecessary in some circumstances. This is not a big issue since as I pointed out in the initial messages, I believe you can define pretty much arbitrary traps using the DISMAN MIBs if you need them. > >> In host mode, the rtpSenderTable entry is kept by the sender and the > >> rtpRcvrTable entry is kept by the receiver, which won't have the > >> rtpSenderPackets object. > > > >That's not quite what the DESCRIPTION of rtpSenderTable says. > >It says that a receiver host MAY have rows in the sender table > >for each active source. THIS IS WHAT CAUSES THE PROBLEM, > >since you have to wade through everything else to find out > >what (if anything) the device itself is sourcing. > > We should have clearly stated that remote senders that are > observed have entries in the rtpSenderTable when ^ Insert "ONLY" if you modify the existing DESCRIPTION. > rptSessionMonitor is true. The DESCRIPTION clause you cite > is unclear and should be clarified. Since we have the model > that the RTP SNMP agent may be simple and the management > application competent, we push the processing off the agent > to the management app. So, if there is no manageable control > layer for a particular RTP application, (Not sure what you mean... isn't this MIB intended to be such a control layer? I thought configuring monitors was one if your purposes.) > and if the RTP agent > allows a management application to turn on monitoring, ...Or if the monitor turns on monitoring by default, like Kevin's msessmon(? I think it was, the one that joined all groups) does... > and if > the monitoring management application does not collect > management information such as to correlate SSRC with > the sender or receiver TAddress, I didn't follow how the NMS was supposed to do this part. (Also, you can not assume this was the same NMS that set the monitor value to true, more on this below.) > then the management > application would have to 'wade through' information to > identify local from remote senders. I think I do understand > the issue you raise here. Yes. > >In my opinion, you'd be much better off separating this into > >two tables, one table for what the device itself is sourcing, > >and another table for what remote sources it's receiving from. > > This would make matters much worse. Now, in order to answer the > 'who is sending' (or 'who is receiving') question, we would have > to ask 'who is sending locally' and 'who is sending remotely' > and then merge the results. But even then, such "merging" would be done by the manager, which you already say is "smart". So I'd maintain it's no worse, and it's better because you no longer need to waste the resources necessary to walk the whole table. > since a local sender is just as much > as a sender to a session as a remote one (same too for receivers), > we could duplicate the local sender information into a > single table but this would likely lead to consistency problems > in many implementations in addition to redundancy. I agree with the redundancy argument if it was duplicated as you say. I don't understand the consistency problem though. > >Without doing this separation, I still do not believe the MIB > >effectively supports fault diagnosis. > > If there is a problem of filtering local and remote sender/receiver > information that is received by an NMS from a monitor, and if we > want the agent rather than the management application to do the > filtering, then separating the table is overkill, is it not? I don't see why it's overkill. (I also expect that the monitor/agent will have separate tables internally anyway, so it would seem to be more work on the agent side to do the merging at query time.) > >OIDs can be up to 128 subids long, are typically never seen > >by a human, and the length of the OID has a negligible effect on > >performance. > > I think this statement is wrong. OIDs are contained in the > varbinds of every object you access and this is a SN problem > for SNMP that we must handle in the MIB. Early versions of > SNMP agents had a minimum PDU size of slightly more than 500 > bytes so you could easily fill every packet with information > about the information being accessed. I don't read any such > lower bound in SNMPv2 but PDU length is negotiated between > agent and manager. The length of the OIDs used for indexing > have a very great impact on performance, namely message overhead. Okay, I'm convinced that OID length has some impact on performance. (I still think the impact is less than walking an entire table with short OIDs though :) > This is the same NMS that turned on the monitoring bit but > failed to collect information from the table to correlate > addresses with SSRCs, etc. Not necessarily. You should never assume that there's only one NMS interested in an agent's objects. This may be a different NMS from the one that turned on the monitoring bit, and it wants to verify whether there's a problem with a given session. (For example, this is exactly what TroubleD would want to look up.) It could be different because it's a different piece of software >from the first NMS, or because it's another instance running on a different person's desktop, or even because the NMS has rebooted and lost state, or whatever. It could also be the case that monitoring was turned on via some method other than SNMP (such as for msessmon or whateveri) > >The agent implementation appears simpler WITHOUT a "special" integer, > >since it need not find an unused integer when it wants to > >add a row, or store any value other than what it already has to store > >anyway. > > I disagree. The agent will need to parse OIDs and then map them > to a table location (e.g., find a "special" integer), and this > increases the overhead required for the management function in > the managed device. Increases compared to the overhead of walking the entire table? I think not. > Finding an integer is an increment operation, modulo some number, right? Not quite that simple. Once you wrap (the "some number" above), it's not an increment, it's a "search for unused number" operation. > >> Each time we came to the conclusion that a table indexed by the > >> TAddress pair that returns rtpSessionIndex could easily be added > >> if shown to be essential. > > > >I strongly believe that it is essential. > > ok. would you make it optional or mandatory? I think it should > be optional since H-series and potentially some other management > applications do not need it and should not be forced to implement > it. Not sure if I understood your last sentence, since tables are implemented by agents, not management applications. I'm asking for such a table to be mandatory for agents to implement. Otherwise, my manager (e.g. TroubleD) will be eating up your agent resources as it walks whole tables just because it wants a single row. -Dave From rem-conf Thu May 20 16:19:45 1999 From rem-conf-request@es.net Thu May 20 16:19:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kc69-0006c1-00; Thu, 20 May 1999 16:19:33 -0700 Received: from piglet.dstc.edu.au [130.102.176.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kc67-0006bg-00; Thu, 20 May 1999 16:19:32 -0700 Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by piglet.dstc.edu.au (8.8.7/8.8.7) with ESMTP id JAA29931; Fri, 21 May 1999 09:19:27 +1000 (EST) Received: (from ggm@localhost) by azure.dstc.edu.au (8.8.5/8.8.4) id JAA30927; Fri, 21 May 1999 09:19:26 +1000 (EST) Date: Fri, 21 May 1999 09:19:26 +1000 (EST) From: George Michaelson Message-Id: <199905202319.JAA30927@azure.dstc.edu.au> To: end2end-interest@ISI.EDU Subject: delays/fragmentation in IPSEC vpn's Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We're testing netmeeting and vat/vic type apps down an IPSEC tunnel between two ATM-connected networks (2000km separated) We're seeing around 2mbits/sec outside of the VPN encapsulation and about 800-900kbits/sec inside. From a brief tcpdump on the IPSEC box, I do see rather a lot of fragmentation, which the Kame project acknowledge is a side-effect of their implementation right now (the VPN is running on FreeBSD with Kame) We also see around 1-2 sec of end-to-end delay where the base network is more usually providing 200-500msec delay. I was suprised that adding the crypto doubled delay (its the base 56kdes option, I want to play with rc5 and blowfish later on) I'm wondering if other people also see this, and the rather notable increase in end-to-end delay of doing tunnels with crypto, and if there are known tunings for endpoints, tunnels, apps which can mitigate things? Is this behaviour comparable to the kinds of delay problem people are discussing here? The b/w is obviously several orders of magnitude lower! cheers -George From rem-conf Thu May 20 16:45:44 1999 From rem-conf-request@es.net Thu May 20 16:45:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kcUk-0007j6-00; Thu, 20 May 1999 16:44:58 -0700 Received: from playground.sun.com [192.9.5.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kcUj-0007iw-00; Thu, 20 May 1999 16:44:57 -0700 Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.10.0.PreAlpha1+Sun/8.10.0.PreAlpha1) with ESMTP id QAA07211; Thu, 20 May 1999 16:44:50 -0700 (PDT) Received: from kebe.Eng.Sun.COM (kebe.Eng.Sun.COM [129.146.86.51]) by opal.eng.sun.com (8.10.0.PreAlpha1+Sun/8.10.0.PreAlpha1) with ESMTP id QAA120050; Thu, 20 May 1999 16:44:49 -0700 (PDT) Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.9.3+Sun/8.9.1) id QAA03763; Thu, 20 May 1999 16:44:48 -0700 (PDT) From: Dan McDonald Message-Id: <199905202344.QAA03763@kebe.Eng.Sun.COM> Subject: Re: delays/fragmentation in IPSEC vpn's To: ggm@dstc.edu.au (George Michaelson) Date: Thu, 20 May 1999 16:44:47 -0700 (PDT) Cc: end2end-interest@ISI.EDU, rem-conf@es.net In-Reply-To: <199905202319.JAA30927@azure.dstc.edu.au> from "George Michaelson" at May 21, 99 09:19:26 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > We also see around 1-2 sec of end-to-end delay where the base network > is more usually providing 200-500msec delay. I was suprised that adding > the crypto doubled delay (its the base 56kdes option, I want to play > with rc5 and blowfish later on) I'm not surprised at all. Crypto is very high latency, especially in software. Even worse, if you're doing crypto in interrupt context, it can jam the processing of other interrupts, potentially exacerbating your problems. DES is also really bad, given it was designed with small-number-of-bits hardware registers. You may want to give Blowfish or some other post-1990 cipher a spin. It may reduce your latency. Ooops, I almost forgot. If you're doing an HMAC with the encryption, that's yet another source of latency. Even though MD5 can get pretty fast w/o too much modification, it's still more overhead. And I'll bet it's taking two passes of the datagram (one encrypt, one HMAC) before it gets forwarded. Dan From rem-conf Thu May 20 17:49:20 1999 From rem-conf-request@es.net Thu May 20 17:49:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kdSS-00015o-00; Thu, 20 May 1999 17:46:40 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kdSQ-00015c-00; Thu, 20 May 1999 17:46:38 -0700 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id AAA13829 for ; Fri, 21 May 1999 00:46:32 GMT Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 May 1999 17:46:32 -0700 Message-ID: From: "Baugher, Mark" To: "'Dave Thaler'" Cc: rem-conf@es.net Subject: RE: Review of draft-ietf-avt-mib-05.txt Date: Thu, 20 May 1999 17:46:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list David, I think we're done with the trap discussion so I drop it from my response. Towards the end of this note, I propose an alternative solution to the problem that does not require splitting the rtpSenderTable and rtpRcvrTable. > -----Original Message----- > From: Dave Thaler [mailto:dthaler@dthaler.microsoft.com] > Sent: Thursday, May 20, 1999 5:57 PM > To: mbaugher@intel.com > Cc: dthaler@dthaler.microsoft.com; rem-conf@es.net > Subject: Re: Review of draft-ietf-avt-mib-05.txt > > > > > >> In host mode, the rtpSenderTable entry is kept by the > sender and the > > >> rtpRcvrTable entry is kept by the receiver, which won't have the > > >> rtpSenderPackets object. > > > > > >That's not quite what the DESCRIPTION of rtpSenderTable says. > > >It says that a receiver host MAY have rows in the sender table > > >for each active source. THIS IS WHAT CAUSES THE PROBLEM, > > >since you have to wade through everything else to find out > > >what (if anything) the device itself is sourcing. > > > > We should have clearly stated that remote senders that are > > observed have entries in the rtpSenderTable when > ^ > Insert "ONLY" if you modify the existing DESCRIPTION. ok. > > > rptSessionMonitor is true. The DESCRIPTION clause you cite > > is unclear and should be clarified. Since we have the model > > that the RTP SNMP agent may be simple and the management > > application competent, we push the processing off the agent > > to the management app. So, if there is no manageable control > > layer for a particular RTP application, > > (Not sure what you mean... isn't this MIB intended to be such > a control > layer? I thought configuring monitors was one if your purposes.) It could be H.245 or some other entity that configures and controls RTP services. In this case, RTP tables may be accessed through other tables, i.e., there is linkage to the RTP MIB objects and the RTP MIB get accessed through some other MIB. > > > and if the RTP agent > > allows a management application to turn on monitoring, > > ...Or if the monitor turns on monitoring by default, like Kevin's > msessmon(? I think it was, the one that joined all groups) does... good point. In fact, I was just told about a gateway product that does this. > > > and if > > the monitoring management application does not collect > > management information such as to correlate SSRC with > > the sender or receiver TAddress, > > I didn't follow how the NMS was supposed to do this part. > (Also, you can not assume this was the same NMS that > set the monitor value to true, more on this below.) that's true. In our usage we had an NMS that polled RTP monitors continuously during events and constructed tables of information about senders and receivers. So when you ask about how efficiently we can inquire about specific receivers, local or remote, or specific senders, it begs the question as to how we know who are the receivers or senders to a session. How do we get the identifying information to begin with? In our case, we polled and constructed tables of information in the NMS. > > > then the management > > application would have to 'wade through' information to > > identify local from remote senders. I think I do understand > > the issue you raise here. > > Yes. > > > >In my opinion, you'd be much better off separating this into > > >two tables, one table for what the device itself is sourcing, > > >and another table for what remote sources it's receiving from. > > > > This would make matters much worse. Now, in order to answer the > > 'who is sending' (or 'who is receiving') question, we would have > > to ask 'who is sending locally' and 'who is sending remotely' > > and then merge the results. > > But even then, such "merging" would be done by the manager, > which you already say is "smart". So I'd maintain it's no worse, > and it's better because you no longer need to waste the resources > necessary to walk the whole table. I said that as a design point we pushed complexity from the agent to the NMS, which could use a not-so-smart MIB browser. We used a few MIB browsers against earlier versions of the MIB and they worked okay in answering some of your basic questions such as 'who is sending' and 'who is receiving'. Splitting the tables is worse than not spliting them in that most MIB browsers won't be able to access the RTP MIB in a way that would allow someone to answer these questions effectively. > > > since a local sender is just as much > > as a sender to a session as a remote one (same too for receivers), > > we could duplicate the local sender information into a > > single table but this would likely lead to consistency problems > > in many implementations in addition to redundancy. > > I agree with the redundancy argument if it was duplicated as you say. > I don't understand the consistency problem though. If I have copies of object x, then it is possible for the copies to diverge if implemented incorrectly. We invite bugs. > > > >Without doing this separation, I still do not believe the MIB > > >effectively supports fault diagnosis. > > > > If there is a problem of filtering local and remote sender/receiver > > information that is received by an NMS from a monitor, and if we > > want the agent rather than the management application to do the > > filtering, then separating the table is overkill, is it not? > > I don't see why it's overkill. (I also expect that the monitor/agent > will have separate tables internally anyway, so it would seem > to be more work on the agent side to do the merging at query > time.) How about if we don't separate the tables but achieve what you want, efficient filtering by the agent, by alternative means? For the sake of argument, what if we simply added an index to the rtpSenderTable and the rtpRcvrTable to get the same effect? The index could be the TAddress that identifies the particular sender or receiver (and which currently appears in the sender and receiver tables). Or the index could be a 'local' or 'remote' bit that gets set. In either case, this additional index would allow the NMS to walk the table and Get only the local senders or remote senders. And it would be possible to walk the table to get all senders or receivers. > > > >OIDs can be up to 128 subids long, are typically never seen > > >by a human, and the length of the OID has a negligible effect on > > >performance. > > > > I think this statement is wrong. OIDs are contained in the > > varbinds of every object you access and this is a SN problem > > for SNMP that we must handle in the MIB. Early versions of > > SNMP agents had a minimum PDU size of slightly more than 500 > > bytes so you could easily fill every packet with information > > about the information being accessed. I don't read any such > > lower bound in SNMPv2 but PDU length is negotiated between > > agent and manager. The length of the OIDs used for indexing > > have a very great impact on performance, namely message overhead. > > Okay, I'm convinced that OID length has some impact on performance. > (I still think the impact is less than walking an entire table > with short OIDs though :) > > > This is the same NMS that turned on the monitoring bit but > > failed to collect information from the table to correlate > > addresses with SSRCs, etc. > > Not necessarily. You should never assume that there's only > one NMS interested in an agent's objects. Yes. > > This may be a different NMS from the one that turned on the > monitoring bit, and it wants to verify whether there's a problem > with a given session. (For example, this is exactly what > TroubleD would want to look up.) > > It could be different because it's a different piece of software > from the first NMS, or because it's another instance running on a > different person's desktop, or even because the NMS has rebooted > and lost state, or whatever. It could also be the case that > monitoring was turned on via some method other than SNMP > (such as for msessmon or whateveri) > > > >The agent implementation appears simpler WITHOUT a > "special" integer, > > >since it need not find an unused integer when it wants to > > >add a row, or store any value other than what it already > has to store > > >anyway. > > > > I disagree. The agent will need to parse OIDs and then map them > > to a table location (e.g., find a "special" integer), and this > > increases the overhead required for the management function in > > the managed device. > > Increases compared to the overhead of walking the entire table? > I think not. I'll concede this point. I've proposed ways to keep the shorter, integer index and to avoid splitting the sender and receiver tables. In one case we use the so-called rtpSessionInverseTable and in the second case we add an index to both the rtpSenderTable and rtpRcvrTable. > > > Finding an integer is an increment operation, modulo some > number, right? > > Not quite that simple. Once you wrap (the "some number" > above), it's not > an increment, it's a "search for unused number" operation. > > > >> Each time we came to the conclusion that a table indexed by the > > >> TAddress pair that returns rtpSessionIndex could easily be added > > >> if shown to be essential. > > > > > >I strongly believe that it is essential. > > > > ok. would you make it optional or mandatory? I think it should > > be optional since H-series and potentially some other management > > applications do not need it and should not be forced to implement > > it. > > Not sure if I understood your last sentence, since tables are > implemented > by agents, not management applications. I'm asking for such a table > to be mandatory for agents to implement. Sorry, I meant 'application' in the generic sense of the word; substitute 'uses' for 'application.' Some agents don't need it. I don't think an RTP agent for H.323 needs this - I have been told it does not. > > Otherwise, my manager (e.g. TroubleD) will be eating up your agent > resources as it walks whole tables just because it wants a single row. I'd like to talk to some of the people doing the H-series gateways on this point. thanks, Mark > > -Dave > From rem-conf Thu May 20 22:54:56 1999 From rem-conf-request@es.net Thu May 20 22:54:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kiEG-0003hx-00; Thu, 20 May 1999 22:52:20 -0700 Received: from mercury.sun.com [192.9.25.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kiEF-0003hn-00; Thu, 20 May 1999 22:52:19 -0700 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16259; Thu, 20 May 1999 22:52:18 -0700 (PDT) Received: from shorter.eng.sun.com (shorter.Eng.Sun.COM [129.144.125.35]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id WAA08306; Thu, 20 May 1999 22:52:17 -0700 (PDT) Received: from shorter.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA11960; Thu, 20 May 1999 22:51:58 -0700 From: ema.patki@eng.sun.com (Ema Patki) Message-Id: <199905210551.WAA11960@shorter.eng.sun.com> Date: Fri, 21 May 1999 11:26:14 +0-50-30 To: "Dirk Pranke" , , Reply-To: Subject: Re: RTP server software X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Dirk, The JavaMedia Framework 2.0 (http://java.sun.com/products/java-media/jmf) is being released in an early access version by the end of this week. JMF2.0 is capable of streaming QT, AVI, WAV, AIFF, AU files using a fully compliant RTP/RTCP implementation. JMF2.0 also supports RTP playback. JMF is available in an all Java version, a Windows performance pack and a Solaris performance pack. Please refer to the above URL for more information on supported encodings, API usage etc. Thanks Ema Ema Patki JavaMedia Engineering "Dirk Pranke" wrote: >Date: Thu, 20 May 1999 09:48:52 -0700 >Are there any freely available RTP streaming servers capable of >streaming RTP from QuickTime/AVI movies, as opposed to raw RTP >elementary streams or as capture encoders? I'm looking for a test >server, and don't want to have to capture broadcasts just to test my >RTP playback. I believe I can use RAT to do audio-only streams >(using AU or WAV files), but I'm not aware of anything that can stream >A/V together, except for the new QT Streaming Server, but that >only runs on Mac OS X, which I don't have anywhere. > >Thanks in advance, > >-- Dirk > From rem-conf Fri May 21 02:04:08 1999 From rem-conf-request@es.net Fri May 21 02:04:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kl9s-0005qX-00; Fri, 21 May 1999 02:00:00 -0700 Received: from imo19.mx.aol.com [198.81.17.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kl9q-0005pm-00; Fri, 21 May 1999 01:59:58 -0700 Received: from MsBevy@aol.com (526) by imo19.mx.aol.com (IMOv20) id qWDGa02744; Fri, 21 May 1999 04:52:19 -0400 (EDT) From: MsBevy@aol.com Message-ID: <42cc26db.247678c0@aol.com> Date: Fri, 21 May 1999 04:52:16 EDT Subject: Help Needed!! $5000 a Week!! MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 To: undisclosed-recipients:; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list QUIT YOUR JOB IN 2 WEEKS!! START EARNING $2000 TO $5000 PER WEEK EVERY WEEK- IMMEDIATELY. CLICK HERE FOR MORE INFORMATION! http://%34%38%38%39%32%37%35%33%31@3468296925/%6C%65%61%64%73 ENJOY THE FREEDOM TO BE YOUR OWN BOSS! CLICK HERE FOR MORE INFORMATION! http://%34%38%38%39%32%37%35%33%31@3468296925/%6C%65%61%64%73 ENJOY NOW HAVING TIME TO SPEND WITH YOUR FAMILY!! CLICK HERE FOR MORE INFORMATION! http://%34%38%38%39%32%37%35%33%31@3468296925/%6C%65%61%64%73 ENJOY THE FREEDOM TO TRAVEL!! CLICK HERE FOR MORE INFORMATION! http://%34%38%38%39%32%37%35%33%31@3468296925/%6C%65%61%64%73 JUST PLAIN ENJOY LIFE!! CLICK HERE FOR MORE INFORMATION! http://%34%38%38%39%32%37%35%33%31@3468296925/%6C%65%61%64%73 From rem-conf Fri May 21 05:18:58 1999 From rem-conf-request@es.net Fri May 21 05:18:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10koDY-00007B-00; Fri, 21 May 1999 05:16:00 -0700 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 10koDX-00005Q-00; Fri, 21 May 1999 05:15:59 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.9.3/8.9.3) with SMTP id OAA04850 for ; Fri, 21 May 1999 14:14:57 +0200 (MET DST) Received: by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA11766; Fri, 21 May 1999 14:14:56 +0200 Message-Id: <199905211214.AA11766@dxcoms.cern.ch> Subject: CERN MBone Announcement: Next LHCC To: rem-conf@es.net (List Mbone-WW) Date: Fri, 21 May 1999 14:14:56 +0200 (MET DST) From: "Daniel Davids CERN/CN" X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LARGE HADRON COLLIDER COMMITTEE =============================== Thursday 27 May 1999 Place: CERN Main Auditorium *** Times are UTC+1 *** 09.00-09.15 Status of the LHC project (L. Maiani) 09.15-10.00 Status of the LHC machine (L. Evans) 10.00-10.30 COFFEE BREAK 10.30-11.15 ALICE proposal addendum: Transition Radiation Detector (P. Braun-Munzinger) 11.15-12.00 Report from the Standard Model Workshop (G. Altarelli) The broadcast is announced via sdr as "CERN LHCC". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact: multicast@noc.cern.ch From rem-conf Fri May 21 07:53:36 1999 From rem-conf-request@es.net Fri May 21 07:53:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kqdc-0002IF-00; Fri, 21 May 1999 07:51:04 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kqdb-0002Ht-00; Fri, 21 May 1999 07:51:03 -0700 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id HAA03254; Fri, 21 May 1999 07:51:00 -0700 (PDT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 21 May 1999 07:51:00 -0700 Message-ID: From: "Baugher, Mark" To: "'Francisco Afonso'" , rem-conf@es.net Subject: RE: draft-ietf-avt-mib-05.txt Date: Fri, 21 May 1999 07:50:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Francisco > -----Original Message----- > From: Francisco Afonso [mailto:afonso@cs.nps.navy.mil] > Sent: Thursday, May 20, 1999 11:39 AM > To: rem-conf@es.net > Subject: draft-ietf-avt-mib-05.txt > > > I have some comments: > > a) Why using SNMP/MIB if most information( except round trip > time ) can > be taken from RTCP incomming packets ? There are at least seven objects in the MIB that aren't taken >from RTCP. The RTP MIB also provides a standard structure for accessing RTP management information by a network management station. The latter is also likely to be in a network operations center or some other location which should not receive all data from all multicast RTP sessions in order to receive management information about those sessions. There is also no other way for an NMS to get management information >from unicast RTP sessions where the RTCP is sent point-to-point. > > b) Why the cummulative number of senders and receivers that joined the > session and the cummulative number of BYEs received are important ? > This data will vary between participants depending when the > session was > started. These are the only statistical data about the session. > Shouldn't other data be added, as the number of active and passive > participants, or the number of bad RTP/RTCP packets received ? I'm not sure what you mean by bad RTP/RTCP packets received. We attempted to include buffer underflow (packets arriving too late) and buffer overflow (such as from packet bursts) but these are application-specific counts that are difficult to capture at the transport. The cumulative numbers give a rough count of the numeric size of the session that can be polled to estimate the rate at which participants join and leave a session. This can affect both network and RTP operation and may be correlated with problems in such things as the rate of RTCP messages sent by senders and receivers. > > c) The MIB only stores the last information about the > session. So, when > a new feedback from an SSRC to another SSRC arrives, the > previous report > is lost. Perhaps it would be useful if it could store statistics over > time, say, last hour. I think that would help in detecting and > diagnosing faults. This would be a task for the network management station rather than the RTP agent. Mark > > Francisco Afonso > Naval Postgraduate School > > > > > > From rem-conf Fri May 21 11:22:06 1999 From rem-conf-request@es.net Fri May 21 11:22:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ktjz-0004ud-00; Fri, 21 May 1999 11:09:51 -0700 Received: from mail.nps.navy.mil [131.120.43.89] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ktjy-0004uS-00; Fri, 21 May 1999 11:09:50 -0700 Received: from cs.nps.navy.mil (slippc11.cs.nps.navy.mil [131.120.1.190]) by mail.nps.navy.mil (8.8.8/8.8.8) with ESMTP id LAA10886 for ; Fri, 21 May 1999 11:09:44 -0700 (PDT) Message-ID: <3745A13D.2969ADBF@cs.nps.navy.mil> Date: Fri, 21 May 1999 11:09:02 -0700 From: Francisco Afonso X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf Subject: [Fwd: draft-ietf-avt-mib-05.txt] Content-Type: multipart/mixed; boundary="------------2CF807A936FE10487599A556" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------2CF807A936FE10487599A556 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------2CF807A936FE10487599A556 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3745A060.94739926@cs.nps.navy.mil> Date: Fri, 21 May 1999 11:05:20 -0700 From: Francisco Afonso X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Baugher, Mark" Subject: Re: draft-ietf-avt-mib-05.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > a) Why using SNMP/MIB if most information( except round trip > > time ) can > > be taken from RTCP incomming packets ? > > There are at least seven objects in the MIB that aren't taken > from RTCP. The RTP MIB also provides a standard structure > for accessing RTP management information by a network management > station. The latter is also likely to be in a network operations > center or some other location which should not receive all > data from all multicast RTP sessions in order to receive > management information about those sessions. There is also > no other way for an NMS to get management information > from unicast RTP sessions where the RTCP is sent point-to-point. What I mean is that all information can be extracted from monitoring a multicast RTP session, excluding the round trip time. > > b) Why the cummulative number of senders and receivers that joined the > > session and the cummulative number of BYEs received are important ? > > This data will vary between participants depending when the > > session was > > started. These are the only statistical data about the session. > > Shouldn't other data be added, as the number of active and passive > > participants, or the number of bad RTP/RTCP packets received ? > > I'm not sure what you mean by bad RTP/RTCP packets received. > We attempted to include buffer underflow (packets arriving too > late) and buffer overflow (such as from packet bursts) but > these are application-specific counts that are difficult > to capture at the transport. I am working with Sun's Java Media Framework and it has several Global Statistics about a session. Some are described below: - bad RTP Packets : the number of RTP data packets that failed the RTP header validation check such as RTP version number or length consistency - bad RTCP Packets : same as above for RTCP - malformed SR : the number of invalid Sender Reports due to length inconsistency ( same for RR, SDES and BYE) - remote collisions: the number of remote collisions ( I suppose it is about SSRC collisions) - local collisions: same as above for local I know that these kind of statistics are not defined in RTP standards and so they may not be applicable to an RTP MIB. > The cumulative numbers give a rough count of the numeric size > of the session that can be polled to estimate the rate at > which participants join and leave a session. This can > affect both network and RTP operation and may be > correlated with problems in such things as the > rate of RTCP messages sent by senders and receivers. > > > > > c) The MIB only stores the last information about the > > session. So, when > > a new feedback from an SSRC to another SSRC arrives, the > > previous report > > is lost. Perhaps it would be useful if it could store statistics over > > time, say, last hour. I think that would help in detecting and > > diagnosing faults. > > This would be a task for the network management station rather than > the RTP agent. > > Mark > Understood. Thanks for your answer. Francisco Afonso Naval Postgraduate School --------------2CF807A936FE10487599A556-- From rem-conf Fri May 21 11:50:48 1999 From rem-conf-request@es.net Fri May 21 11:50:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kuLT-00064K-00; Fri, 21 May 1999 11:48:35 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kuLS-000648-00; Fri, 21 May 1999 11:48:34 -0700 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id LAA17552; Fri, 21 May 1999 11:48:32 -0700 (PDT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 21 May 1999 11:48:31 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362DFB@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Francisco Afonso'" , "'rem-conf@es.net'" Subject: RE: [Fwd: draft-ietf-avt-mib-05.txt] Date: Fri, 21 May 1999 11:48:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Francisco, Some answers to your questions a) What if the RTP Stream is not multicast. Many uses of RTP are not designed for multicast, point - point conferencing for one Bill -----Original Message----- From: Francisco Afonso [mailto:afonso@cs.nps.navy.mil] Sent: Friday, May 21, 1999 11:09 AM To: rem-conf Subject: [Fwd: draft-ietf-avt-mib-05.txt] > > > a) Why using SNMP/MIB if most information( except round trip > > time ) can > > be taken from RTCP incomming packets ? > > There are at least seven objects in the MIB that aren't taken > from RTCP. The RTP MIB also provides a standard structure > for accessing RTP management information by a network management > station. The latter is also likely to be in a network operations > center or some other location which should not receive all > data from all multicast RTP sessions in order to receive > management information about those sessions. There is also > no other way for an NMS to get management information > from unicast RTP sessions where the RTCP is sent point-to-point. What I mean is that all information can be extracted from monitoring a multicast RTP session, excluding the round trip time. > > b) Why the cummulative number of senders and receivers that joined the > > session and the cummulative number of BYEs received are important ? > > This data will vary between participants depending when the > > session was > > started. These are the only statistical data about the session. > > Shouldn't other data be added, as the number of active and passive > > participants, or the number of bad RTP/RTCP packets received ? > > I'm not sure what you mean by bad RTP/RTCP packets received. > We attempted to include buffer underflow (packets arriving too > late) and buffer overflow (such as from packet bursts) but > these are application-specific counts that are difficult > to capture at the transport. I am working with Sun's Java Media Framework and it has several Global Statistics about a session. Some are described below: - bad RTP Packets : the number of RTP data packets that failed the RTP header validation check such as RTP version number or length consistency - bad RTCP Packets : same as above for RTCP - malformed SR : the number of invalid Sender Reports due to length inconsistency ( same for RR, SDES and BYE) - remote collisions: the number of remote collisions ( I suppose it is about SSRC collisions) - local collisions: same as above for local I know that these kind of statistics are not defined in RTP standards and so they may not be applicable to an RTP MIB. > The cumulative numbers give a rough count of the numeric size > of the session that can be polled to estimate the rate at > which participants join and leave a session. This can > affect both network and RTP operation and may be > correlated with problems in such things as the > rate of RTCP messages sent by senders and receivers. > > > > > c) The MIB only stores the last information about the > > session. So, when > > a new feedback from an SSRC to another SSRC arrives, the > > previous report > > is lost. Perhaps it would be useful if it could store statistics over > > time, say, last hour. I think that would help in detecting and > > diagnosing faults. > > This would be a task for the network management station rather than > the RTP agent. > > Mark > Understood. Thanks for your answer. Francisco Afonso Naval Postgraduate School From rem-conf Fri May 21 13:05:17 1999 From rem-conf-request@es.net Fri May 21 13:05:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kvVe-0007g9-00; Fri, 21 May 1999 13:03:10 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 10kvVd-0007fe-00; Fri, 21 May 1999 13:03:09 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 21 May 1999 20:06:02 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256778.006DED84 ; Fri, 21 May 1999 16:00:42 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: David_Franklin@nmss.com To: rem-conf@es.net Message-ID: <85256778.006DEC45.00@notes4.nmss.com> Date: Fri, 21 May 1999 16:01:33 -0400 Subject: Re: subscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe From rem-conf Fri May 21 14:22:11 1999 From rem-conf-request@es.net Fri May 21 14:22:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10kwhb-0001EU-00; Fri, 21 May 1999 14:19:35 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10kwha-0001EK-00; Fri, 21 May 1999 14:19:34 -0700 Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA27237; Fri, 21 May 1999 14:19:27 -0700 (PDT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 21 May 1999 14:19:27 -0700 Message-ID: From: "Baugher, Mark" To: "Strahm, Bill" , "'Francisco Afonso'" , "'rem-conf@es.net'" Subject: RE: [Fwd: draft-ietf-avt-mib-05.txt] Date: Fri, 21 May 1999 14:19:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm not sure who is said what below so I'll just make a general comment and pose a question. We considered adding collision counts and length inconsistency counts at one time, but decided that they were very rare occurrences and not worth monitoring. Now, I'm not sure that was the right decision. Do you think we should include these counts and also counts of length inconsistency and version failures? Our goal is to manage the protocol and not merely record RTCP. We count received octets, received packets, and other objects in the RTP MIB that cannot be "extracted" from the RTCP. We put them in to better manage RTP system operation. That's an argument in favor of counting the PDU errors as well. Mark > -----Original Message----- > From: Strahm, Bill [mailto:bill.strahm@intel.com] > Sent: Friday, May 21, 1999 11:48 AM > To: 'Francisco Afonso'; 'rem-conf@es.net' > Subject: RE: [Fwd: draft-ietf-avt-mib-05.txt] > > > Francisco, > > Some answers to your questions > a) What if the RTP Stream is not multicast. Many uses of RTP are not > designed for multicast, point - point conferencing for one > > Bill > -----Original Message----- > From: Francisco Afonso [mailto:afonso@cs.nps.navy.mil] > Sent: Friday, May 21, 1999 11:09 AM > To: rem-conf > Subject: [Fwd: draft-ietf-avt-mib-05.txt] > > > > > > > > a) Why using SNMP/MIB if most information( except round trip > > > time ) can > > > be taken from RTCP incomming packets ? > > > > There are at least seven objects in the MIB that aren't taken > > from RTCP. The RTP MIB also provides a standard structure > > for accessing RTP management information by a network management > > station. The latter is also likely to be in a network operations > > center or some other location which should not receive all > > data from all multicast RTP sessions in order to receive > > management information about those sessions. There is also > > no other way for an NMS to get management information > > from unicast RTP sessions where the RTCP is sent point-to-point. > > What I mean is that all information can be extracted from monitoring a > multicast RTP session, excluding the round trip time. > > > > > b) Why the cummulative number of senders and receivers > that joined the > > > session and the cummulative number of BYEs received are > important ? > > > This data will vary between participants depending when the > > > session was > > > started. These are the only statistical data about the session. > > > Shouldn't other data be added, as the number of active and passive > > > participants, or the number of bad RTP/RTCP packets received ? > > > > I'm not sure what you mean by bad RTP/RTCP packets received. > > We attempted to include buffer underflow (packets arriving too > > late) and buffer overflow (such as from packet bursts) but > > these are application-specific counts that are difficult > > to capture at the transport. > > I am working with Sun's Java Media Framework and it has several Global > Statistics about a session. Some are described below: > > - bad RTP Packets : the number of RTP data packets that failed the RTP > header validation check such as RTP version number or length > consistency > - bad RTCP Packets : same as above for RTCP > - malformed SR : the number of invalid Sender Reports due to length > inconsistency ( same for RR, SDES and BYE) > - remote collisions: the number of remote collisions ( I > suppose it is about > SSRC collisions) > - local collisions: same as above for local > > I know that these kind of statistics are not defined in RTP > standards and so > they may not be applicable to an RTP MIB. > > > > The cumulative numbers give a rough count of the numeric size > > of the session that can be polled to estimate the rate at > > which participants join and leave a session. This can > > affect both network and RTP operation and may be > > correlated with problems in such things as the > > rate of RTCP messages sent by senders and receivers. > > > > > > > > c) The MIB only stores the last information about the > > > session. So, when > > > a new feedback from an SSRC to another SSRC arrives, the > > > previous report > > > is lost. Perhaps it would be useful if it could store > statistics over > > > time, say, last hour. I think that would help in detecting and > > > diagnosing faults. > > > > This would be a task for the network management station rather than > > the RTP agent. > > > > Mark > > > > Understood. Thanks for your answer. > > Francisco Afonso > Naval Postgraduate School > From rem-conf Mon May 24 13:02:45 1999 From rem-conf-request@es.net Mon May 24 13:02:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10m0hE-0001ak-00; Mon, 24 May 1999 12:47:36 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10m0hD-0001aa-00; Mon, 24 May 1999 12:47:35 -0700 Received: from duke.cs.ucsb.edu (duke [128.111.49.49]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id MAA23097 for ; Mon, 24 May 1999 12:47:33 -0700 (PDT) Received: by duke.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id MAA05779 for rem-conf@es.net; Mon, 24 May 1999 12:47:32 -0700 (PDT) Date: Mon, 24 May 1999 12:47:32 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199905241947.MAA05779@duke.cs.ucsb.edu> To: rem-conf@es.net Subject: public multicast ftp X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I realize mftp is a Starburst product but is there any freeware (linux) that will do a quick and dirty version of the same thing? Emphasis on quick... specifically since I have an application that will run on a single Ethernet. -Kevin From rem-conf Tue May 25 13:25:51 1999 From rem-conf-request@es.net Tue May 25 13:25:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10mNaN-0006Ub-00; Tue, 25 May 1999 13:14:03 -0700 Received: from milou.comp.lancs.ac.uk [194.80.34.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 10mNaM-0006UR-00; Tue, 25 May 1999 13:14:02 -0700 Received: from tina.comp.lancs.ac.uk (tina.comp.lancs.ac.uk [194.80.34.25]) by milou.comp.lancs.ac.uk (8.9.3/8.9.3) with ESMTP id VAA12639 for ; Tue, 25 May 1999 21:08:42 +0100 (BST) Received: (from randa@localhost) by tina.comp.lancs.ac.uk (8.9.3/8.9.3) id VAA22243 for rem-conf@es.net; Tue, 25 May 1999 21:12:35 +0100 (BST) From: Randa Message-Id: <199905252012.VAA22243@tina.comp.lancs.ac.uk> Subject: IP traffic To: rem-conf@es.net Date: Tue, 25 May 1999 21:12:34 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all, I have a question regarding Internet traffic. I ran across a paper which states that the TCP traffic constitutes 95% of the bytes, 85-95 % of the packets, and 75-85% of the flows while the UDP traffic makes most of the remaining IP traffic on Internet MCI's commercial backbone. I do not know if anyone has other or similar experiences about Internet traffic, basically comparing TCP and UDP traffic. It appears to me from this paper that UDP traffic is negligable compared to TCP traffic. I am interested in UDP traffic as I want to show the importance of RTP and RTCP running over UDP in the Internet today. Would you please refer me to articles about recent Internet traffic comparing TCP and UDP traffic. The paper I mentioned is: "The nature of the beast: recent traffic measurements from an Internet backbone" by K. Claffy, Greg Miller and Kevin Thompson. A reference to an earlier version of the paper is: K. Thompson, G. Miller, and R. Wilder, "Wide-Area Internet Traffic Patterns and Characteristics", IEEE Network, Nov. 1997. http://www.vbns.net/presentations/papers/MCItraffic.ps Thanks Randa El-Marakby From rem-conf Wed May 26 07:57:44 1999 From rem-conf-request@es.net Wed May 26 07:57:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10meyK-0000ha-00; Wed, 26 May 1999 07:47:56 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10meyJ-0000hF-00; Wed, 26 May 1999 07:47:55 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 May 1999 08:46:54 -0600 Message-ID: <18A6A966D2B7D211AEDE0090273CE1BA1C83D7@el-postino.s-vision.com> From: Richard Shields To: rem-conf@es.net Subject: H.263 v1 & H.263 v2 payload headers Date: Wed, 26 May 1999 08:46:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >From the documents I have read it, I understand that H.263 v2 (H.263+) uses a different payload header scheme than H.263 v1 does. If an application is written to use H.263 v2 and wishes to communicate with another application what mechanism is used to understand which version of H.263 it supports and ultimately which payload header format it will use? If this is not the correct forum for this question please direct me to the appropriate one. Thanks, Richard From rem-conf Wed May 26 10:46:09 1999 From rem-conf-request@es.net Wed May 26 10:46:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10mhfE-0002kX-00; Wed, 26 May 1999 10:40:24 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10mhfD-0002kM-00; Wed, 26 May 1999 10:40:23 -0700 Received: from kubismus.cs.tu-berlin.de (stewe@kubismus.cs.tu-berlin.de [130.149.25.94]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id TAA13793; Wed, 26 May 1999 19:38:40 +0200 (MET DST) From: Stephan Wenger Received: by kubismus.cs.tu-berlin.de (8.9.0/8.9.0) id TAA15239; Wed, 26 May 1999 19:38:40 +0200 (MET DST) Message-Id: <199905261738.TAA15239@kubismus.cs.tu-berlin.de> Subject: Re: H.263 v1 & H.263 v2 payload headers To: richards@s-vision.com (Richard Shields) Date: Wed, 26 May 1999 19:38:39 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: <18A6A966D2B7D211AEDE0090273CE1BA1C83D7@el-postino.s-vision.com> from "Richard Shields" at May 26, 99 08:46:48 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Richard Shields > > >From the documents I have read it, I understand that H.263 v2 (H.263+) uses > a different payload header scheme than H.263 v1 does. If an application is > written to use H.263 v2 and wishes to communicate with another application > what mechanism is used to understand which version of H.263 it supports and > ultimately which payload header format it will use? If I recall the discussions in Washington and rem-conf correctly, then the only reason for not declaring the old payload spec RFC2190 as obsolete was that there are numerous products that use this spec. If interoperability with older versions of tools like NetMeeting is of your concern, then you will most likely have to implement RFC2190, too. RFC2190 is, however, not useful with H.263+, so that for all H.263+ capable applications 2429 is mandatory. RFC To complicate the situation there is a third payload spec for H.263V1, which is very close in syntax and functionality to RFC2190, defined in H.225. This one exists, because one major player of this business released a product based on an I-D, which was later slightly changed and became RFC2190. Again, if interoperability with old H.323-tools is your concern, then you should have a look into this payload spec, too. I'm unaware of any widely used non-H.323 system employing H.263 version 1 or 2. My best guess is, that for those non-H.323 systems RFC2429 is the correct way to go, even if your codec initially might only implement version 1 of H.263. > If this is not the correct forum for this question please direct me to the > appropriate one. I guess it is. Stephan -- -- Stephan Wenger stewe@cs.tu-berlin.de From rem-conf Wed May 26 13:40:10 1999 From rem-conf-request@es.net Wed May 26 13:40:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10mkIJ-0004gJ-00; Wed, 26 May 1999 13:28:55 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10mkIH-0004fo-00; Wed, 26 May 1999 13:28:54 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 May 1999 14:27:47 -0600 Message-ID: <18A6A966D2B7D211AEDE0090273CE1BA1C846C@el-postino.s-vision.com> From: Richard Shields To: Stephan Wenger Cc: rem-conf@es.net Subject: RE: H.263 v1 & H.263 v2 payload headers Date: Wed, 26 May 1999 14:27:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Interoperability with existing H.323 applications is a concern. Is there some mechanism in the H.323 specification that allows for identifying payload header schemes that will be used? If I'm about to communicate with an application that supports H.263 via H.323 how do I know which payload header is used when it sends me video packets? Thanks, Richard > -----Original Message----- > From: Stephan Wenger [SMTP:stewe@cs.tu-berlin.de] > Sent: Wednesday, May 26, 1999 11:39 AM > To: richards@s-vision.com > Cc: rem-conf@es.net > Subject: Re: H.263 v1 & H.263 v2 payload headers > > Richard Shields > > > > >From the documents I have read it, I understand that H.263 v2 (H.263+) > uses > > a different payload header scheme than H.263 v1 does. If an application > is > > written to use H.263 v2 and wishes to communicate with another > application > > what mechanism is used to understand which version of H.263 it supports > and > > ultimately which payload header format it will use? > > If I recall the discussions in Washington and rem-conf correctly, then > the only reason for not declaring the old payload spec RFC2190 as obsolete > was that there are numerous products that use this spec. If > interoperability > with older versions of tools like NetMeeting is of your concern, then > you will most likely have to implement RFC2190, too. RFC2190 is, however, > not useful with H.263+, so that for all H.263+ capable applications > 2429 is mandatory. > RFC > To complicate the situation there is a third payload spec for H.263V1, > which is very close in syntax and functionality to RFC2190, defined > in H.225. This one exists, because one major player of this business > released a product based on an I-D, which was later slightly changed and > became RFC2190. Again, if interoperability with old H.323-tools is > your concern, then you should have a look into this payload spec, too. > > I'm unaware of any widely used non-H.323 system employing H.263 > version 1 or 2. My best guess is, that for those non-H.323 systems > RFC2429 is the correct way to go, even if your codec initially > might only implement version 1 of H.263. > > > If this is not the correct forum for this question please direct me to > the > > appropriate one. > > I guess it is. > > Stephan > > > -- > -- > Stephan Wenger stewe@cs.tu-berlin.de > From rem-conf Wed May 26 14:05:35 1999 From rem-conf-request@es.net Wed May 26 14:05:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10mkpM-0005aq-00; Wed, 26 May 1999 14:03:04 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10mkpL-0005ag-00; Wed, 26 May 1999 14:03:03 -0700 Received: from kubismus.cs.tu-berlin.de (stewe@kubismus.cs.tu-berlin.de [130.149.25.94]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id WAA03632; Wed, 26 May 1999 22:57:27 +0200 (MET DST) From: Stephan Wenger Received: by kubismus.cs.tu-berlin.de (8.9.0/8.9.0) id WAA15864; Wed, 26 May 1999 22:57:26 +0200 (MET DST) Message-Id: <199905262057.WAA15864@kubismus.cs.tu-berlin.de> Subject: Re: H.263 v1 & H.263 v2 payload headers To: richards@s-vision.com (Richard Shields) Date: Wed, 26 May 1999 22:57:25 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: <18A6A966D2B7D211AEDE0090273CE1BA1C846C@el-postino.s-vision.com> from "Richard Shields" at May 26, 99 02:27:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Richard Shields > > Interoperability with existing H.323 applications is a concern. Is there > some mechanism in the H.323 specification that allows for identifying > payload header schemes that will be used? If I'm about to communicate with > an application that supports H.263 via H.323 how do I know which payload > header is used when it sends me video packets? I'm not 100% sure of the following and do not have the documents ready to double check, but I recall the following situation: H.245 version 3 contains codepoints for all three mentioned packetization schemes along with a quite complex capability description mechanism for the various optional modes of H.263+. H.263+ codecs implicitely use RFC2429. Old H.263 (non-plus) codecs might use either the custom packetization method, or RFC2180. If an H.263 (non-plus) codec wants to use RFC2429 then it can announce itself as an H.263+ codec, but with capabilities that are limited to a (non-plus) codec. All three packetization schemes do not have fixed payload types. Instead, dynamic payload types have to be used. H.225, RTP, and H.245 provide mapping mechanisms between a port and the virtual channel, which has a payload type and capabilities assigned. Stephan > > > -----Original Message----- > > From: Stephan Wenger [SMTP:stewe@cs.tu-berlin.de] > > Sent: Wednesday, May 26, 1999 11:39 AM > > To: richards@s-vision.com > > Cc: rem-conf@es.net > > Subject: Re: H.263 v1 & H.263 v2 payload headers > > > > Richard Shields > > > > > > >From the documents I have read it, I understand that H.263 v2 (H.263+) > > uses > > > a different payload header scheme than H.263 v1 does. If an application > > is > > > written to use H.263 v2 and wishes to communicate with another > > application > > > what mechanism is used to understand which version of H.263 it supports > > and > > > ultimately which payload header format it will use? > > > > If I recall the discussions in Washington and rem-conf correctly, then > > the only reason for not declaring the old payload spec RFC2190 as obsolete > > was that there are numerous products that use this spec. If > > interoperability > > with older versions of tools like NetMeeting is of your concern, then > > you will most likely have to implement RFC2190, too. RFC2190 is, however, > > not useful with H.263+, so that for all H.263+ capable applications > > 2429 is mandatory. > > RFC > > To complicate the situation there is a third payload spec for H.263V1, > > which is very close in syntax and functionality to RFC2190, defined > > in H.225. This one exists, because one major player of this business > > released a product based on an I-D, which was later slightly changed and > > became RFC2190. Again, if interoperability with old H.323-tools is > > your concern, then you should have a look into this payload spec, too. > > > > I'm unaware of any widely used non-H.323 system employing H.263 > > version 1 or 2. My best guess is, that for those non-H.323 systems > > RFC2429 is the correct way to go, even if your codec initially > > might only implement version 1 of H.263. > > > > > If this is not the correct forum for this question please direct me to > > the > > > appropriate one. > > > > I guess it is. > > > > Stephan > > > > > > -- > > -- > > Stephan Wenger stewe@cs.tu-berlin.de > > > -- -- Stephan Wenger stewe@cs.tu-berlin.de From rem-conf Thu May 27 04:30:52 1999 From rem-conf-request@es.net Thu May 27 04:30:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10myHj-0006mB-00; Thu, 27 May 1999 04:25:15 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10myHi-0006ln-00; Thu, 27 May 1999 04:25:14 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25034; Thu, 27 May 1999 07:24:11 -0400 (EDT) Message-Id: <199905271124.HAA25034@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtpsample-04.txt Date: Thu, 27 May 1999 07:24:10 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sampling of the Group Membership in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-04.txt Pages : 10 Date : 26-May-99 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. NOTE: This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the binning algorithm which is a part of the specification. This declaration is being made pursuant to the provisions of IETF IPR Policy , Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtpsample-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990526095743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990526095743.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri May 28 10:16:38 1999 From rem-conf-request@es.net Fri May 28 10:16:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10nQ4Q-0001j2-00; Fri, 28 May 1999 10:05:22 -0700 Received: from (jbtools.bernardino.org) [194.65.40.96] by mail1.es.net with esmtp (Exim 1.81 #2) id 10nFfi-0006qx-00; Thu, 27 May 1999 22:59:10 -0700 Received: from tqqps.comnets.rwth-aachen.de (zeus.host4u.net [216.71.64.21]) by jbtools.bernardino.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id K6S9YQNK; Fri, 28 May 1999 06:58:08 +0100 From: xfbypxiuxq@comnets.rwth-aachen.de To: afxuflnaoj@bangor.ac.uk Reply-To: Subject: NO SPONSORING REQUIRED!!!!! ytthi Message-Id: Date: Thu, 27 May 1999 22:59:10 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Life Without Debt" Easy Money Educational Training Course For 1998 ----------------------------------------------------------------- WE SHOW YOU HOW TO: ***Compound $5 weekly into $780 weekly to start! ***Then we show you how to compound $25 into $3,900 per week! ***Compound Leverage Your Way to Complete Financial Independence! ***Eliminate Your Debts From Creditors and Banks! Simply print out and return this letter with $25 CASH ONLY, or Money Order with "pay to" left blank. In an envelope. We will then mail our "Life Without Debt", INSTRUCTION GUIDE to you and place you into our $25 Easy Money Plan, to illustrate how the plan works! *No Sponsoring Required! *Pays out 80% PLUS on all levels! *Teaches you how to take control of your finances And get out of debt FAST! Topics of the educational package Cover Money, Credit, Debt, Taxes, Federal Reserve, Corruption In Administrative Agencies of Government, Corruption in the courts, And the U.C.C. "UNIFORM COMMERCIAL CODE for THEFT BY THE GOVERNMENT" *SOLID, 9-year-old debt free company, Has an established Customer base of over 100,000+! *Has an excellent support system to guide you, step by step Through the pay plans! *Best of all, you can GET STARTED on an Affordable "Shoestring Budget" of only $5 weekly! Then advance through the Entire system at your own pace. Let us HELP you get on an Extra income path without leaving Your "Comfort Zone" Get Started Today! Print out this letter, complete the details below and mail this letter along with $25 CASH or MONEY ORDER ONLY to: Computer center P.O. BOX 1511 Grapevine, Texas 76051 (817) 498-7506 NOTE: MEMBERS RESIDING OUTSIDE OF U.S.A MUST SEND $40.00 US CURRENCY. THIS WILL GET YOU PROCESSED AND ENTER YOU IN THE PROGRAM FOR THE FIRST MONTH! .....Please send CASH or MONEY ORDER ONLY with the pay space blank, as it is used to pay the upline daily, and ILLUSTRATE HOW the plan works! NO CHECKS! Your Name:_______________________________________________ Address:_________________________________________________ City:____________________ State:________ Zip_____________ Country if other than USA ______________________ Phone#:___________________ Fax#:_____________________ Mailers I.D.# 225 05 8499 1 If questions reply at address: tmaan@apexmail.com, subject line Debt Free FOR MORE INFORMATION: please join our Conference Call every Tuesday night at 6.00C.S.T., at (423) 362-4250 enter pin# 5433! From rem-conf Fri May 28 10:17:12 1999 From rem-conf-request@es.net Fri May 28 10:17:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10nQEj-0002VS-00; Fri, 28 May 1999 10:16:01 -0700 Received: from pi4.informatik.uni-mannheim.de [134.155.48.96] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10nOQu-00013Z-00; Fri, 28 May 1999 08:20:28 -0700 Received: from pi4.informatik.uni-mannheim.de (pi4 [134.155.48.96]) by pi4.informatik.uni-mannheim.de (8.8.8+Sun/8.8.8) with ESMTP id RAA20810 for ; Fri, 28 May 1999 17:20:45 +0200 (MET DST) Sender: mauve@pi4.informatik.uni-mannheim.de Message-ID: <374EB44D.C617DD40@pi4.informatik.uni-mannheim.de> Date: Fri, 28 May 1999 17:20:45 +0200 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP/I - using RTP for interactive media Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pi4.informatik.uni-mannheim.de id RAA20810 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, we would like to invite interested persons to have a look=20 at our work on RTP/I - an RTP profile for interactive media=20 (e.g. shared whiteboards, multi user 3D, dsitributed simulations,=20 etc.). RTP/I enables the development of generic services, such as recording or late-join, which can be reused without modifications for all applications using RTP/I.=20 At this time we are interested in any kind of feedback and comments. If you are interested, have a look at our RTP/I project pages at: http://www.informatik.uni-mannheim.de/informatik/pi4/projects/RTPI/index.= html These pages also include the following two papers on RTP/I: 1) Martin Mauve, Volker Hilt, Christoph Kuhm=FCnch, Wolfgang Effelsberg.=20 A General Framework and Communication Protocol for the Transmission=20 of Interactive Media with Real-Time Characteristics.=20 To appear in: Proc. of IEEE Multimedia Systems '99 (ICMCS'99),=20 Florence, Italy, June 1999. Abstract: In this paper we present RTP/I, an application-layer protocol for=20 the transmission of interactive media with real-time characteristics,=20 i.e. media involving user interaction. By identifying and supporting=20 the common aspects of interactive media RTP/I allows the development=20 of generic services for distributed, collaborative work involving the=20 transmission of interactive media. Derived from the experience gained=20 with audio and video transmission using the Real-Time Transport=20 Protocol (RTP), RTP/I is defined as a new RTP profile for interactive=20 media. 2) Volker Hilt, Martin Mauve, Christoph Kuhm=FCnch, Wolfgang Effelsberg.=20 A Generic Scheme for the Recording of Interactive Media Streams. To=20 appear in: Proc. of Interactive Distributed Multimedia Systems and=20 Telecommunication Services '99 (IDMS'99), Toulouse, France, 1999. Abstract:=20 Interactive media streams with real-time characteristics, such as=20 those produced by shared whiteboards, distributed Java applets or=20 shared VRML viewers, are rapidly gaining importance. Current solutions to the recording of interactive media streams are limited=20 to one specific application (e.g. one specific shared whiteboard).=20 In this paper we present a generic recording service that enables=20 the recording and playback of this new class of media. To facilitate the generic recording we have defined a profile for=20 the Real-Time Transport Protocol (RTP) that covers common aspects=20 of the interactive media class in analogy to the profile for audio=20 and video. Based on this profile we introduce a generalized recording service that enables the recording and playback of=20 arbitrary interactive media. thanks for reading, Volker Martin --=20 -------------------------------------------------------------------------= -- Martin Mauve University of Mannhe= im Praktische Informatik IV Phone: +49-621-292-54= 07 L 15,16 Fax : +49-621-292-57= 45 68131 Mannheim mauve@pi4.informatik.uni-mannheim.= de Germany -------------------------------------------------------------------------= -- From rem-conf Fri May 28 10:17:12 1999 From rem-conf-request@es.net Fri May 28 10:17:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10nQE1-0002Pf-00; Fri, 28 May 1999 10:15:17 -0700 Received: from law-f132.hotmail.com (hotmail.com) [209.185.131.195] by mail1.es.net with smtp (Exim 1.81 #2) id 10nHKn-0007AZ-00; Fri, 28 May 1999 00:45:41 -0700 Received: (qmail 44044 invoked by uid 0); 28 May 1999 07:17:59 -0000 Message-ID: <19990528071759.44043.qmail@hotmail.com> Received: from 210.56.11.36 by www.hotmail.com with HTTP; Fri, 28 May 1999 00:17:59 PDT X-Originating-IP: [210.56.11.36] From: "shahzad ahsan" To: rem-conf@es.net, vern@aciri.org Cc: ietf-info@ietf.org Subject: Date: Fri, 28 May 1999 00:17:59 PDT Mime-Version: 1.0 Content-type: text/plain; format=flowed; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Have you got any implementation i.e. source code of "real-time transport protocol" (RTP). I shall be keenly awaiting your reply in this regard. Thanks. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri May 28 15:43:35 1999 From rem-conf-request@es.net Fri May 28 15:43:33 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10nVIe-0005sV-00; Fri, 28 May 1999 15:40:24 -0700 Received: from mailhost.onramp.net ([199.1.11.3]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 10nVIc-0005sL-00; Fri, 28 May 1999 15:40:22 -0700 Received: from devsys (a201-31.ppp.dlls.tx.onramp.net [199.1.154.31]) by mailhost.onramp.net (8.8.7/8.8.7) with SMTP id RAA18747 for ; Fri, 28 May 1999 17:40:19 -0500 (CDT) Message-ID: <013d01bea95b$7ca41a00$0100a8c0@devsys.iplay.net> From: "John Barrett" To: Subject: List Help Date: Fri, 28 May 1999 17:43:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list How do I get off this list and what is the correct list for dicussing issues concerning application techniques for dynamically allocating multicast channels, and other application related issues ??? (all this talk about protocols and drafts is nice, if a bit over and above what I need to write the simulation system that I have in mind :)))) From rem-conf Fri May 28 19:25:43 1999 From rem-conf-request@es.net Fri May 28 19:25:41 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10nYdW-0000Co-00; Fri, 28 May 1999 19:14:10 -0700 Received: from pm05sm.pmm.cw.net ([208.159.98.154]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 10nYdV-0000Cc-00; Fri, 28 May 1999 19:14:09 -0700 Received: from cs.columbia.edu (usr53-dialup41.mix2.Boston.cw.net [166.62.199.41]) by PM05SM.PMM.CW.NET (PMDF V5.2-29 #35323) with ESMTP id <0FCH00DMN26DUA@PM05SM.PMM.CW.NET> for rem-conf@es.net; Sat, 29 May 1999 02:13:37 +0000 (GMT) Date: Fri, 28 May 1999 22:15:01 -0400 From: Henning Schulzrinne Subject: Re: To: shahzad ahsan Cc: rem-conf@es.net, vern@aciri.org, ietf-info@ietf.org Reply-to: hgs@cs.columbia.edu Message-id: <374F4DA5.2EFD72A3@cs.columbia.edu> Organization: Columbia University, Dept. of Computer Science MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-US,de References: <19990528071759.44043.qmail@hotmail.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list http://www.cs.columbia.edu/~hgs/rtp lists implementations. shahzad ahsan wrote: > > Hi > Have you got any implementation i.e. source code of "real-time transport > protocol" (RTP). I shall be keenly awaiting your reply in this regard. > > Thanks. > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com From rem-conf Sun May 30 09:06:35 1999 From rem-conf-request@es.net Sun May 30 09:06:33 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10o7xX-0007Lb-00; Sun, 30 May 1999 08:57:11 -0700 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 10o7xW-0007L8-00; Sun, 30 May 1999 08:57:10 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 30 May 1999 16:57:07 +0100 To: rem-conf@es.net Subject: AVT scheduling and agenda Date: Sun, 30 May 1999 16:57:05 +0100 Message-ID: <2501.928079825@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scheduling details for the AVT meeting in Oslo are included below. If you have items for the agenda, please contact me or Steve. Colin ------- Forwarded Message --> Marcia Beaulieu writes: >AVT is tentatively scheduled as follows: > > Wednesday, July 14 at 0900-1130 > other groups scheduled at that time: disman, manet, pkix, ipngwg > Thursday, July 15 at 0900-1130 > other groups scheduled at that time: idwg, opseare, ldapext > >Please submit an agenda for this meeting as soon as possible to >agenda@ietf.org >The deadline for submitting an agenda is July 1 at 1200 ET. > >Thanks, > >Marcia ------- End of Forwarded Message From rem-conf Sun May 30 12:30:04 1999 From rem-conf-request@es.net Sun May 30 12:30:02 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10oBFG-0001bh-00; Sun, 30 May 1999 12:27:42 -0700 Received: from ntmail.goto.fr ([194.51.85.200]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 10oBFE-0001bX-00; Sun, 30 May 1999 12:27:40 -0700 Received: from joinny (sdn-ar-001riprovP108.dialsprint.net [206.133.176.68]) by ntmail.goto.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id K0N32SDP; Sun, 30 May 1999 21:42:00 +0200 From: "Trent" Reply-To: Subject: Introducing The Best Non-Surgical Liposuction Alternative! To: allmembers38k@es.net X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 30 May 1999 12:47:17 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Re: The Best Non-Surgical Liposuction Alternative! Developed by a team of husband/wife Anti-Obesity and Anti-Aging Medicine M.D. Research physicians, this is a powerful three part topical gel product that is helping many win the "Battle of the Bulge". The gels are applied directly/locally to the most common fat prone areas of the body. Results have been phenomenol. Here is just one of the many testimonials we have on file regarding this gel product: "I am a small woman who just turned 50 years old. I have certain areas on my body where I could not lose the inches as I used to when I was younger. I lost 81/2 (eight and half) inches total in 24Hours with your topical gels. I will continue using this forever. It's absolutely amazing! I lost the inches in the areas I wanted. Thank You". ~ L.K.M - Business Entrepreneur. All the details about this amazing gel product for fast elimination of unsightly puckers of cellulite, is available in a ten page info document, which you can access by calling this 24Hour =46ax-On-Demand number fro= m any fax machine: 716-420-6542. If you do not have access to a fax machine, or if for some reason your fax machine can send faxes but cannot receive, then, either go to your nearest/local print shop and use their fax machine to access this important info. Or, fax your request for more info to 978-334-8039. Or, call this 24hr voice message line: 918-748-3701. When you call or send a fax requesting more info, leave either your fax number or your email address. If leaving your email address on the voicemail, please spell out any unusual names slowly and clearly. If requesting info by fax, please write out your email address and or fax number LEGIBLY, (best to type it out). It is a good idea to leave your phone number as well, in case we need to call you back to verify your email address etc. However, don't bank on us calling you back. Usually, the response to our ads, is "huge" and we normally won't have the time to call people back to verify illegibly written email addresses or email addresses or fax numbers that are not clear on the voicemail line. ***************************************************************** Please Remove at: mailto:jsmith1234@deskmail.com?subject=3Dremove *****************************************************************