From rem-conf Sun Jan 02 17:22:55 2000 From rem-conf-request@es.net Sun Jan 02 17:22:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 124vvB-0002Ak-00; Sun, 2 Jan 2000 17:04:29 -0800 Received: from oznet14.ozemail.com.au [203.2.192.115] by mail1.es.net with esmtp (Exim 1.81 #2) id 124vv9-0002Aa-00; Sun, 2 Jan 2000 17:04:27 -0800 Received: from ozemail.com.au (slsyd57p57.ozemail.com.au [203.108.18.185]) by oznet14.ozemail.com.au (8.9.0/8.6.12) with ESMTP id LAA12685; Mon, 3 Jan 2000 11:27:17 +1100 (EST) Message-ID: <386FE950.2F9F32C0@ozemail.com.au> Date: Mon, 03 Jan 2000 11:12:00 +1100 From: "Ollencio D'Souza" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Happy and properous millenium Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A warm hello from Sydney Autralia. I hope you and your family have had a great Christmas break as we did. I'd like to take this opportunity to wish you all a great start to, a happy and prosperous Millennium! Olly D'Souza Sydney Australia From rem-conf Sun Jan 02 19:47:02 2000 From rem-conf-request@es.net Sun Jan 02 19:47:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 124yPZ-0003yP-00; Sun, 2 Jan 2000 19:44:01 -0800 Received: from chmls06.mediaone.net [24.128.1.71] by mail1.es.net with esmtp (Exim 1.81 #2) id 124yPX-0003yF-00; Sun, 2 Jan 2000 19:43:59 -0800 Received: from Maldrich (h0060088f93b1.ne.mediaone.net [24.128.111.92]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA28108 for ; Sun, 2 Jan 2000 22:43:55 -0500 (EST) Message-Id: <4.3.0.25.20000102224152.00c6fc30@pop.ne.mediaone.net> X-Sender: maldrich@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.0.25 (Beta) Date: Sun, 02 Jan 2000 22:43:31 -0500 To: rem-conf@es.net From: Michael Aldrich Subject: Re:UNLIMITED Long Distance? In-Reply-To: <199911220922.GAA04554@tvn.cl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 12:30 AM 11/22/99 -0500, you wrote: >IMAGINE! > > >UNLIMITED Long Distance Calling for only $35/month flat rate! > > >We're in a pre launch! > > >It was bound to happen... there is a new telephone company > >offering UNLIMITED US Domestic Long Distance Calling for a > >flat rate of $35 per month... no computer required... > >phone to phone... "pin drop" quality. FREE Demo and rep > >information available: Please Hit Reply and leave us your : > >Name & e-mail address, very Important , NO information will be > >sent without your e-mail Address. We use an automated system > >that responds only to your e-mail address. > > >(you will receive your requested information within 24-72 hours) > > >Thank you! > > >Imagine being able to make UNLIMITED > >Long Distance calls for only $35 a month? > > > > > :::::::::::::=BB=A7=AB:*=B4`=B3=A4=B3=B4`*:=BB=A7=AB::::::::::::: > > > Making Dreams Come True! > > > :::::::::::::=BB=A7=AB:*=B4`=B3=A4=B3=B4`*:=BB=A7=AB::::::::::::: > > > > >This "Hot", new, technology will also > >allow you to (realistically) make > >$2-5,000 in less than 30 days part-time! > > > >_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ >If you have received this message in error, >please reply with the word remove in the subject. >_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Michael Aldrich Laser Sight & Sound 15 Kilrea Rd. Computer Consulting Derry NH.=20 03038=20 http://www.laserss.com 1-(603)-437-7087 An Informed Consumer is a intellectual consumer. So please be Informed, Especially when you are buying a computer. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=00=00=00a:=00=A0=C8=94=9C=00= =C0K=9C=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=20 From rem-conf Mon Jan 03 07:26:23 2000 From rem-conf-request@es.net Mon Jan 03 07:26:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1259IH-0005ar-00; Mon, 3 Jan 2000 07:21:13 -0800 Received: from smtp2.cluster.oleane.net [195.25.12.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 1259I6-0005Z7-00; Mon, 3 Jan 2000 07:21:02 -0800 Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp2.cluster.oleane.net with SMTP id QAA72889; Mon, 3 Jan 2000 16:20:34 +0100 (CET) Message-ID: <001d01bf55fd$c37254c0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: VoDSL 2000 Conference Date: Mon, 3 Jan 2000 16:18:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BF5606.1FBDFB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_001A_01BF5606.1FBDFB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 Regards ------=_NextPart_000_001A_01BF5606.1FBDFB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo= dsl.htm
 
Regards
 
------=_NextPart_000_001A_01BF5606.1FBDFB00-- From rem-conf Tue Jan 04 06:47:32 2000 From rem-conf-request@es.net Tue Jan 04 06:47:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 125UuL-0000Mq-00; Tue, 4 Jan 2000 06:25:57 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 125UuG-0000Mf-00; Tue, 4 Jan 2000 06:25:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28765; Tue, 4 Jan 2000 09:25:51 -0500 (EST) Message-Id: <200001041425.JAA28765@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-fecmime-00.txt Date: Tue, 04 Jan 2000 09:25:50 -0500 Sender: nsyracus@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 : Registration of parityfec MIME types Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fecmime-00.txt Pages : 6 Date : 03-Jan-00 The RTP payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity based channel codes. This payload format requires two new MIME types, audio/parityfec and video/parityfec. This document serves as the MIME type registration for those formats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-fecmime-00.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-fecmime-00.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-fecmime-00.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: <20000103132306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fecmime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fecmime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000103132306.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jan 04 16:55:45 2000 From rem-conf-request@es.net Tue Jan 04 16:55:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 125eXH-00014M-00; Tue, 4 Jan 2000 16:42:47 -0800 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 125eXG-00013y-00; Tue, 4 Jan 2000 16:42:46 -0800 Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA21033 for ; Tue, 4 Jan 2000 16:42:45 -0800 (PST) Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id QAA01919; Tue, 4 Jan 2000 16:42:45 -0800 (PST) Message-Id: <200001050042.QAA01919@rum.isi.edu> To: rem-conf@es.net Date: Tue, 04 Jan 2000 16:37:03 -0800 From: Joe Touch Reply-To: sigcomm2000-info@acm.org Organization: Sigcomm 2000 MIME-Version: 1.0 Subject: Sigcomm 2000 CFP - reminder Content-Type: multipart/mixed; boundary="------------37436CC801591A770F5655A2" Old-Status: O X-Lines: 148 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------37436CC801591A770F5655A2 Content-Type: text/plain; charset="us-ascii" X-Sun-Content-Length: 1124 Call for Papers ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org Paper submission: January 28, 2000 Tutorial proposals: February 28, 2000 Paper acceptance: April 21, 2000 The SIGCOMM 2000 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Proposals for tutorials, information on student paper award eligibility and procedures, and nominations for the SIGCOMM Award are also sought at this time. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu, or sigcomm2000-info@acm.org) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) --------------37436CC801591A770F5655A2 Content-Type: text/html; charset="us-ascii"; name="Sc2000CFP-short.html" Content-Disposition: inline; filename="Sc2000CFP-short.html" X-Sun-Content-Length: 2644 Sigcomm 2000 CFP - short

Call for Papers

ACM SIGCOMM 2000 Conference

August 28 - September 1, 2000
Grand Hotel, Stockholm, Sweden
http://www.acm.org/sigcomm/sigcomm2000
sigcomm2000-info@acm.org
 
Paper submission:  January 28, 2000
Tutorial proposals: February 28, 2000
Paper acceptance: April 21, 2000
The SIGCOMM 2000 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Proposals for tutorials, information on student paper award eligibility and procedures, and nominations for the SIGCOMM Award are also sought at this time.
 
General Co-Chairs
Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se)
Steve Pink, Luleå U. Tech., Sweden (steve@cdt.luth.se)
Program Co-Chairs
Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com)
Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu)
Publicity Chair
Joe Touch, USC/ISI, USA (touch@isi.edu, also sigcomm2000-info@acm.org)
Tutorials Chair
Steve Pink, Luleå U. Tech., Sweden (steve@cdt.luth.se)

  --------------37436CC801591A770F5655A2-- From rem-conf Tue Jan 04 22:21:48 2000 From rem-conf-request@es.net Tue Jan 04 22:21:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 125jjP-0005Je-00; Tue, 4 Jan 2000 22:15:39 -0800 Received: from sasi.com (samar.sasi.com) [164.164.56.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 125jjI-0005Ib-00; Tue, 4 Jan 2000 22:15:36 -0800 Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id LAA20637 for ; Wed, 5 Jan 2000 11:45:53 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by samar.sasi.com; Wed, 05 Jan 2000 11:45:52 +0000 (IST) Received: from sasi.com (pcg127.sasi.com [10.0.64.127]) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id LAA10036 for ; Wed, 5 Jan 2000 11:45:49 +0530 (IST) Message-ID: <3872E199.A1A317E0@sasi.com> Date: Wed, 05 Jan 2000 11:45:53 +0530 From: "Anil . H" Reply-To: anilh@sasi.com X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Questions on RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have some qustions on RTP mixers: 1.I would like to know if the mixer that is specified in H323 Multipoint processor is the same as the RTP level mixer. 2.Where can I find some more information and implementation of RTP mixers. Regards Anil From rem-conf Wed Jan 05 13:41:47 2000 From rem-conf-request@es.net Wed Jan 05 13:41:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 125xvu-0005Nl-00; Wed, 5 Jan 2000 13:25:30 -0800 Received: from babbage.csee.usf.edu [131.247.3.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 125xvs-0005Nb-00; Wed, 5 Jan 2000 13:25:28 -0800 Received: from kjc (kjc [131.247.3.42]) by babbage.csee.usf.edu (8.9.3/8.9.3) with ESMTP id PAA25689; Wed, 5 Jan 2000 15:16:45 -0500 (EST) Message-Id: <4.2.0.58.20000105152122.00a72100@babbage.csee.usf.edu> X-Sender: christen@babbage.csee.usf.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2000 15:22:44 -0500 To: christen@csee.usf.edu From: Ken Christensen Subject: Call For Papers - LCN 2000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS LCN 2000 The 25th Annual IEEE Conference on Local Computer Networks November 8 - 10, 2000 Embassy Suites USF, Tampa, Florida http://www.ieeelcn.org Sponsored by the IEEE Computer Society with support from GTE Data Services, Paradyne Corporation, and the University of South Florida College of Engineering. Important dates: ---------------- Paper submission: May 19, 2000 Notification of acceptance: July 14, 2000 Camera-ready copy due: August 18, 2000 General Information: -------------------- The IEEE LCN conference is the premier conference on leading edge and practical computer networking. The emphasis of this conference is on practical solutions to important problems in computer networking. During the 25 years of this conference, we have moved from problems in the local network to problems in the global Internet and World Wide Web. Our unique approach stimulates a workshop environment and enables an effective interchange among researchers, users, and product developers. We encourage you to submit original papers describing research results or practical solutions. Paper topics include, but are not limited to: - Local Area Networks - Home Networks - Wireless Networks - Storage Area Networks - Optical Networks - Realtime Networks - Active Networks - ATM - Gigabit Ethernet - LAN/WAN Internetworking - DSL Technologies - Network Management - Network Security - Network Reliability - Multicasting - Enabling QoS in High-Speed Networks - Always On / Always Connected - Internet / Intranet - Anything-over-IP - IP-over-Anything - Performance Evaluation - Protocol Design and Validation Authors are invited to submit full or short papers for presentation at the conference. Full papers should present novel perspectives on computer networking within the general scope of the conference topics listed above and may be up to 10 camera-ready pages in length. Short papers are an opportunity to present preliminary or interim results and are limited to 2 camera-ready pages in length. All papers will be reviewed by a minimum of three reviewers. A best paper award will be presented. Several student travel scholarships will be available courtesy of the LCN corporate supporters. All submitted papers must include title, complete contact information for all authors, abstract, and keywords on the cover page. The correspondence author must be clearly identified. Paper Submission Instructions: ------------------------------ Email one postscript version of your manuscript to the program chair at christen@csee.usf.edu. Alternatively, send five hard copies via postal mail to: Dr. Kenneth J. Christensen Department of Computer Science and Engineering 4202 East Fowler Avenue, ENB 118 University of South Florida Tampa, FL 33620 Tutorials: ---------- LCN 2000 will begin with one full day of tutorials. Individuals interested in giving a tutorial should contact the Tutorials Chair (Garry Kessler at kessler@symquest.com). LCN 2000 Committee: ------------------- General Chair: F. Huebner, AT&T (fhuebner@att.com) Program Chairs: K. Christensen, USF (christen@csee.usf.edu) P. Martini, Univ. of Bonn (martini@informatik.uni-bonn.de) IEEE Liaison: J. Bumblis, Seagate (Joseph_R_Bumblis@notes.seagate.com) Finance Chair: K. Prasad, UMass-Lowell (Kanti_Prasad@uml.edu) Tutorials Chair: G. Kessler, SymQuest (kessler@symquest.com) Panels Chairs: J. W. Atwood, Concordia (bill@cs.concordia.ca) T. Strayer, BBN (strayer@bbn.com) Arrangements Chairs: K. Christensen, USF (christen@csee.usf.edu) R. Sankar, USF (sankar@csee.usf.edu) Webmaster: G. Kessler, SymQuest (kessler@symquest.com) Overseas Advisors: S. Jah, UNSW, (Australia) (sjha@cse.unsw.edu.au) P. Martini, Univ of Bonn, (Europe) (martini@informatik.uni-bonn.de) Standing Committee: M. McKee, Bowling Green E. Nolley, Strategic Growth H. Salwen, OpenRoute --- =============================================================== = Kenneth J. Christensen, Ph.D., P.E. (Assistant Professor) = = Department of Computer Science and Engineering = = University of South Florida = = (813) 974-4761 = = http://www.csee.usf.edu/~christen = =============================================================== From rem-conf Thu Jan 06 00:58:47 2000 From rem-conf-request@es.net Thu Jan 06 00:58:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1268do-0002VW-00; Thu, 6 Jan 2000 00:51:32 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1268dm-0002VM-00; Thu, 6 Jan 2000 00:51:30 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Jan 2000 08:51:06 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id IAA04166; Thu, 6 Jan 2000 08:44:43 GMT Message-Id: <200001060844.IAA04166@cperkins-d.cs.ucl.ac.uk> To: alagu@entera.com (Alagu Periyannan) cc: rem-conf@es.net, yano@cs.berkeley.edu Subject: Re: RTCP Retransmission In-Reply-To: Message from alagu@entera.com (Alagu Periyannan) of "Tue, 28 Dec 1999 11:31:31 PST." <3.0.6.32.19991228113131.012c93a0@mailserver.entera.com> Date: Thu, 06 Jan 2000 08:44:43 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Alagu Periyannan writes: >At 01:56 PM 12/27/99 +0000, Colin Perkins wrote: >>--> Alagu Periyannan writes: >>> >>>A "time-based streaming" protocol in my definition is a protocol that >>>delivers timestamped packets period. It must cover the case of time bounded >>>delivery with no reliability guarantees and the case of 100% reliability >>>with no time bound. >> >>We have RTP over UDP for the first case, and the new profile draft >>specifies a TCP encapsulation for RTP which should deal with the case of >>"100% reliability with no time bound"? >> >>This leaves the case where we have a time bound, but desire enhanced reliability >>compared to UDP. We have some options here already (eg: redundant audio and >>parity FEC), and the RTCP retransmission draft offers another alternative. > >I was not aware of the RTP over TCP draft. (A pointer is appreciated.) It's in section 7 of draft-ietf-avt-profile-new-07.txt. >Nevertheless, in many cases one may need to mix the various cases I >mentioned in one RTP session. For example if we are streaming an animation >over RTP, we may want to send the "actor" information in a reliable fashion >and the motion vectors in a non-reliable fashion. > >This is not possible if the "100% reliability with no time bound" case is >covered in a separate profile that does not include features of the >standard A/V profile. It's in the standard profile, but I suspect we may need a minor SDP addition to signal it. At present we have something like m=video 49170/2 RTP/AVP 31 which indicates the "Realtime Transport Protocol using the Audio/Video profile carried over UDP" (quoting rfc2327). There's no defined way to signal RTP-over-TCP - we'd need to define m=video 49170/2 RTP/AVP/TCP 31 for example to allow this. Colin From rem-conf Thu Jan 06 01:08:49 2000 From rem-conf-request@es.net Thu Jan 06 01:08:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1268r3-0002lw-00; Thu, 6 Jan 2000 01:05:13 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 1268r1-0002kx-00; Thu, 6 Jan 2000 01:05:11 -0800 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with SMTP id com; Thu, 6 Jan 2000 01:19:46 -0800 Message-Id: <3.0.6.32.20000106011357.00e1f4d0@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 06 Jan 2000 01:13:57 -0800 To: Colin Perkins From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTCP Retransmission Cc: rem-conf@es.net,yano@cs.berkeley.edu In-Reply-To: <200001060844.IAA04166@cperkins-d.cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 08:44 AM 1/6/00 +0000, Colin Perkins wrote: >--> Alagu Periyannan writes: > >>Nevertheless, in many cases one may need to mix the various cases I >>mentioned in one RTP session. For example if we are streaming an animation >>over RTP, we may want to send the "actor" information in a reliable fashion >>and the motion vectors in a non-reliable fashion. >> >>This is not possible if the "100% reliability with no time bound" case is >>covered in a separate profile that does not include features of the >>standard A/V profile. > >It's in the standard profile, but I suspect we may need a minor SDP >addition to signal it. At present we have something like > m=video 49170/2 RTP/AVP 31 >which indicates the "Realtime Transport Protocol using the Audio/Video >profile carried over UDP" (quoting rfc2327). There's no defined way to >signal RTP-over-TCP - we'd need to define > m=video 49170/2 RTP/AVP/TCP 31 >for example to allow this. > >Colin > I want to cover the case where in a single RTP session we may want to send a few packets reliably and the rest unreliably. In the scheme you illustrate above I have to choose UDP or TCP for the entire session. -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 510 770 5225 From rem-conf Thu Jan 06 01:49:53 2000 From rem-conf-request@es.net Thu Jan 06 01:49:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1269Uq-0004hd-00; Thu, 6 Jan 2000 01:46:20 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1269Uo-0004hT-00; Thu, 6 Jan 2000 01:46:18 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Jan 2000 09:46:11 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id JAA04809; Thu, 6 Jan 2000 09:45:19 GMT Message-Id: <200001060945.JAA04809@cperkins-d.cs.ucl.ac.uk> To: alagu@entera.com (Alagu Periyannan) cc: rem-conf@es.net, yano@cs.berkeley.edu Subject: Re: RTCP Retransmission In-Reply-To: Message from alagu@entera.com (Alagu Periyannan) of "Thu, 06 Jan 2000 01:13:57 PST." <3.0.6.32.20000106011357.00e1f4d0@mailserver.entera.com> Date: Thu, 06 Jan 2000 09:45:19 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Alagu Periyannan writes: >I want to cover the case where in a single RTP session we may want to send >a few packets reliably and the rest unreliably. This is what RTCP-Rx is for! But that has to be a different profile, since it requires separate RTCP transmission rules (it can be an extension which uses the same payload formats as the current audio/video profile, if that is your concern). Alternatively, send the character data in parallel/in advance using a TCP stream, and the animation data over RTP. It depends on how much data you have to transmit - RTP is not, and should not be, a file transfer protocol. Colin From rem-conf Thu Jan 06 02:42:16 2000 From rem-conf-request@es.net Thu Jan 06 02:42:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 126AJC-00060b-00; Thu, 6 Jan 2000 02:38:22 -0800 Received: from khumbu.eeng.dcu.ie [136.206.35.10] by mail1.es.net with smtp (Exim 1.81 #2) id 126AJA-00060R-00; Thu, 6 Jan 2000 02:38:20 -0800 Received: from (eeng.dcu.ie) [136.206.35.77] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 126AJ5-0007js-00; Thu, 6 Jan 2000 10:38:15 +0000 Message-ID: <3874709C.DA3CDE73@eeng.dcu.ie> Date: Thu, 06 Jan 2000 10:38:20 +0000 From: Nikki Cranley <94426082@eeng.dcu.ie> X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins , rem-conf@es.net CC: Alagu Periyannan Subject: Re: RTCP Retransmission References: <200001060945.JAA04809@cperkins-d.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 Hi all, That is what I was trying to say earlier using RTP-Rx for streamed MPEG-4 data. There are just a few packets such as the BIF and the IOD which are more important to the transmission, the rest of the packets would hopefully get there but if they don't -well its no big deal if some of them get lost or delayed. Colin Perkins wrote: > --> Alagu Periyannan writes: > >I want to cover the case where in a single RTP session we may want to send > >a few packets reliably and the rest unreliably. > > This is what RTCP-Rx is for! But that has to be a different profile, since > it requires separate RTCP transmission rules (it can be an extension which > uses the same payload formats as the current audio/video profile, if that > is your concern). In MPEG-4 there is a back channel defined for feedback but it still has to be put into RTCP packets - I think that RTP-Rx is better. But there will need to be profiles defined. What is meant by separate RTCP transmission rules? > Alternatively, send the character data in parallel/in advance using a TCP > stream, and the animation data over RTP. It depends on how much data you > have to transmit - RTP is not, and should not be, a file transfer protocol. Or using SDP - some out of band means. This has to be done anyway to get the path MTU and QoS limitations etc. Nikki > > > Colin From rem-conf Thu Jan 06 08:03:49 2000 From rem-conf-request@es.net Thu Jan 06 08:03:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 126FFz-0002Lm-00; Thu, 6 Jan 2000 07:55:23 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 126FFx-0002Lc-00; Thu, 6 Jan 2000 07:55:21 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Jan 2000 15:53:50 +0000 To: Nikki Cranley <94426082@eeng.dcu.ie> cc: rem-conf@es.net, Alagu Periyannan Subject: Re: RTCP Retransmission In-reply-to: Your message of "Thu, 06 Jan 2000 10:38:20 GMT." <3874709C.DA3CDE73@eeng.dcu.ie> Date: Thu, 06 Jan 2000 15:53:50 +0000 Message-ID: <2488.947174030@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Nikki Cranley writes: >Colin Perkins wrote: >> --> Alagu Periyannan writes: >> >I want to cover the case where in a single RTP session we may want to send >> >a few packets reliably and the rest unreliably. >> >> This is what RTCP-Rx is for! But that has to be a different profile, since >> it requires separate RTCP transmission rules (it can be an extension which >> uses the same payload formats as the current audio/video profile, if that >> is your concern). > >In MPEG-4 there is a back channel defined for feedback but it still has to be >put into RTCP packets - I think that RTP-Rx is better. But there will need to >be profiles defined. > >What is meant by separate RTCP transmission rules? The current rules for when you send RTCP packets don't allow for its use to request retransmission. We have to update these rules, to allow this, and to specify congestion control for retransmission request traffic. Colin From rem-conf Thu Jan 06 09:01:55 2000 From rem-conf-request@es.net Thu Jan 06 09:01:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 126GD9-0003hD-00; Thu, 6 Jan 2000 08:56:31 -0800 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 126GD7-0003h3-00; Thu, 6 Jan 2000 08:56:29 -0800 Received: from kraftbus (130-149-145-65.dialup.cs.tu-berlin.de [130.149.145.65]) by mail.cs.tu-berlin.de (8.9.3/8.9.1) with SMTP id RAA00938; Thu, 6 Jan 2000 17:53:59 +0100 (MET) Message-Id: <4.1.20000106174151.009a5100@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jan 2000 17:59:32 +0100 To: Colin Perkins , Nikki Cranley <94426082@eeng.dcu.ie> From: Stephan Wenger Subject: Re: RTCP Retransmission Cc: rem-conf@es.net, Alagu Periyannan In-Reply-To: <2488.947174030@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear AVT: The more I follow this thread, the less I'm convinced that a combination of reliable and unreliable transmission using RTP is a good idea. I believe, that media coding specific feedback messages (e.g. for reference picture selection in H.263+ and MPEG-4 visual video version 2) make sense, and that such mechanisms fit into the current RTCP model. They just have to be defined in the payload specs. The same is the case for the more generic ARQ mechanisms of which some video people still believe that they are useful. But I don't think that we should allow 'reliable' transmission mechanisms based on UDP at all, for reasons like missing/to be defined congestion control, muliticast/broadcast scaling aspects, and so on. People who try to do this would have to re-invent most functionality of TCP, plus reliable multicast if they want to cover multicast transmission as well. I believe that a better alternative would be to use two transmission channels, one reliable using TCP/RTP and one unreliable using UDP/RTP. Synchronization of this two channels could be done using the RTP timestamps. MPEG-folk could come up with an Internet draft describing what data has to go over the unreliable, and what data should go over the reliable channel. I could also settle for a packet based re-transmission allowing a fixed, low number of attempts. H.223, for example, allows for video data (AL3) exactly one re-transmission attempt. This can greatly impove the transmission quality, without interfering too much with the real-time character of the protocol, or generating too many congestion problems. But, again, this is not reliable transmission, and likely not sufficent for MPEG needs. Frankly, MPEG made the mistake to define most of their work as media independent, and left the definition of transport aspects to the vaporware DMIF part. Now, after most people believe that DMIF is not going to happen, we (AVT) should not try to construct a completely new protocol (with all the resulting problems) to solve their problems. Especially not, as there is with RTP over TCP a solution that is just barely less efficient then the best we could, after significant work, come up with. My 2 cents. Stephan At 03:53 PM 1/6/00 +0000, Colin Perkins wrote: >--> Nikki Cranley writes: >>Colin Perkins wrote: >>> --> Alagu Periyannan writes: >>> >I want to cover the case where in a single RTP session we may want to send >>> >a few packets reliably and the rest unreliably. >>> >>> This is what RTCP-Rx is for! But that has to be a different profile, since >>> it requires separate RTCP transmission rules (it can be an extension which >>> uses the same payload formats as the current audio/video profile, if that >>> is your concern). >> >>In MPEG-4 there is a back channel defined for feedback but it still has to be >>put into RTCP packets - I think that RTP-Rx is better. But there will need to >>be profiles defined. >> >>What is meant by separate RTCP transmission rules? > >The current rules for when you send RTCP packets don't allow for its use to >request retransmission. We have to update these rules, to allow this, and to >specify congestion control for retransmission request traffic. > >Colin > From rem-conf Thu Jan 06 11:27:03 2000 From rem-conf-request@es.net Thu Jan 06 11:27:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 126IQl-0006N8-00; Thu, 6 Jan 2000 11:18:43 -0800 Received: from vortex.com [192.136.140.1] by mail1.es.net with smtp (Exim 1.81 #2) id 126IQj-0006Mx-00; Thu, 6 Jan 2000 11:18:41 -0800 Received: by vortex.com (Smail3.1.28.1 #75) id m126IQe-0006AyC; Thu, 6 Jan 2000 11:18 PST Message-Id: Date: Thu, 6 Jan 2000 11:18 PST From: lauren@vortex.com (Lauren Weinstein) To: rem-conf@es.net Subject: usnbu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe From rem-conf Fri Jan 07 17:11:45 2000 From rem-conf-request@es.net Fri Jan 07 17:11:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 126k6T-0001OC-00; Fri, 7 Jan 2000 16:51:37 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 126k6S-0001O1-00; Fri, 7 Jan 2000 16:51:36 -0800 Received: from tune.cs.columbia.edu (tune.cs.columbia.edu [128.59.19.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA22322 for ; Fri, 7 Jan 2000 19:51:35 -0500 (EST) Received: by tune.cs.columbia.edu (8.9.1/8.9.1) id TAA16185; Fri, 7 Jan 2000 19:51:34 -0500 (EST) Date: Fri, 7 Jan 2000 19:51:34 -0500 (EST) From: Henning Schulzrinne Message-Id: <200001080051.TAA16185@tune.cs.columbia.edu> To: rem-conf@es.net Subject: CFP on JCN Special Issue on Internet QOS - Deadline Extended List: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JOURNAL OF COMMUNICATIONS AND NETWORKING (JCN) CALL FOR PAPERS - SPECIAL ISSUE ON QoS IN IP NETWORKS JUNE, 2000 ---> DEADLINE EXTENDED to January 31, 2000 A Special Issue of JCN dedicated to the realization of QoS-sensitive services in IP networks will be published in June, 2000. It will be Guest Edited by Prof. Henning Schulzrinne of Columbia University, Prof. Hideo Miyahara of Osaka University, and Prof. Luigi Fratta of the University of Milan. The topics include but are not limited to: Differentiated Services Integrated Services MPLS Real-time multicast IP network traffic engineering Performance measurement and evaluation Pricing and billing User perception of QOS QOS policy management Adaptive and other new service models Light-weight reservation protocols and aggregation Continuing JCN's tradition of fast turnaround together with full peer reviews, the following schedule has been set: Jan. 31, 2000 Submit manuscript via web page (see below) Mar. 31, 2000 First reviews returned to author, revisions returned within three weeks June, 2000 Special Issue published The guest editors are Prof. Luigi Fratta Prof. Hideo Miyahara Prof. Henning Schulzrinne Papers should be submitted via the procedure described at http://www.cs.columbia.edu/~hgs/edas/JCN Only PostScript and PDF formats are accepted. Further information about JCN is available at http://JCN.snu.ac.kr. JCN is a high-quality quarterly archival journal, published by the Korean Institute of Communications Sciences with the technical cosponsorship of the IEEE Communications Society, covering the fields of Communication Theory and Systems, Wireless Communications, and Networks and Services. JCN began publication in March, 1999. From rem-conf Sun Jan 09 08:48:50 2000 From rem-conf-request@es.net Sun Jan 09 08:48:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 127LHE-00010L-00; Sun, 9 Jan 2000 08:33:12 -0800 Received: from road.daejin.ac.kr [203.237.66.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 127LHB-0000zp-00; Sun, 9 Jan 2000 08:33:09 -0800 Received: from default ([203.237.66.44]) by road.daejin.ac.kr (8.9.1/8.9.1) with SMTP id BAA16121; Mon, 10 Jan 2000 01:21:11 +0900 (KST) Message-ID: From: "nascar1@crescotek.com" Subject: DISTRIBUTE NASCAR/SPORTS MERCHANDISE Adv: (2729) Date: Thu, 30 Dec 1999 09:38:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Looking for motivated indiviuals to distribute Nascar/Sports merchandise, licensed by NASCAR,NFL,NBA, NHL,and College teams at wholesale prices. Exclusive territories and turnkey business. Get started and lock in your territory for only $26.95 FOR MORE INFORMATION PLEASE EMAIL: deanl@yifan.net WITH THE SUBJECT: SPORTS mailto:deanl@yifan.net?subject=SPORTS ****************** Remove Requests ******************* To be removed from future mailings just reply with Remove as the subject and you will be permanently removed from any future mailings. ********************************************* ********************************************* ******************************************* 14337 From rem-conf Tue Jan 11 02:58:33 2000 From rem-conf-request@es.net Tue Jan 11 02:58:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 127yj7-0002Ip-00; Tue, 11 Jan 2000 02:40:37 -0800 Received: from smtp1.cluster.oleane.net [195.25.12.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 127yj3-0002Ie-00; Tue, 11 Jan 2000 02:40:35 -0800 Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp1.cluster.oleane.net with SMTP id LAA18920; Tue, 11 Jan 2000 11:40:20 +0100 (CET) Message-ID: <007c01bf5c1f$e584f220$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 Date: Tue, 11 Jan 2000 11:37:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01BF5C28.461CC100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0079_01BF5C28.461CC100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: beyond H.323?=20 Discussing and debating in Paris May 10-12. A CFP is online at: http://www.upperside.fr/basip.htm ------=_NextPart_000_0079_01BF5C28.461CC100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SIP 2000: beyond H.323? =
Discussing and debating in Paris May = 10-12.
A CFP is online at:
http://www.upperside.fr/basip.= htm
 
------=_NextPart_000_0079_01BF5C28.461CC100-- From rem-conf Tue Jan 11 03:42:59 2000 From rem-conf-request@es.net Tue Jan 11 03:42:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 127zc6-0003Rm-00; Tue, 11 Jan 2000 03:37:26 -0800 Received: from ss3000e.cselt.it (ss3000e) [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 127zaA-0003Ou-00; Tue, 11 Jan 2000 03:37:25 -0800 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #37044) with ESMTP id <0FO6006094QMJQ@ss3000e.cselt.it> for rem-conf@es.net; Tue, 11 Jan 2000 12:18:22 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 12:21:26 +0100 Content-return: allowed Date: Tue, 11 Jan 2000 12:20:03 +0100 From: Franceschini Guido Subject: RE: RTCP Retransmission To: 'Stephan Wenger' , 'Gauthier Lafruit' , "'LIM, Young-Kwon'" Cc: rem-conf@es.net Message-id: <7FC1C9AF63BAD111ADEA0008C728A50FA77F91@xnole.cselt.it> 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 Dear Stephan, all, seems that the MPEG-4 message did not propagate clearly :( DMIF has specified what it was meant to specify, i.e. a reference architecture (and interfaces) to embrace the essential features of diverse control and transport protocol stacks, while covering diverse consumption scenarios (local, remote interactive, multicast or broadcast). This way it has been possible for the "core" part of MPEG-4 (Systems) to be specified in a delivery independent manner. The target environment for MPEG-4 applications ranges from Internet to mobile to broadcast and local consumption, with a variety of enabling technologies. QoS providing environments are considered. MPEG-4 refrained from 'invading' someone else's areas of 'jurisdiction', but is willing to co-operate to fill the holes. We did that with ITU-T (for mobile terminals), and are doing the same with this group. So far we have complete specs for delivering MPEG-4 over mobile, MPEG-2 TS, DAB or to save MPEG-4 on files. We have implementations for streaming MPEG-4 over TCP and UDP (with and without RSVP in the control plane), various solutions for RTP, a couple (at least) of implementations for IP multicast, others covering RTSP in the control plane. There is an implementation also for HTTP download and I even know of an implementation for native ATM. Almost all these implementations are built on top of the DMIF architecture provided in the MPEG-4 reference software implementation. The definition of RTCP-Rx is, IMHO, a quite interesting new feature per-se, which is fully in the scope of IETF. Specific MPEG-4 media may take advantage of it, or not. If yes, maybe details could be worked out together (IETF and MPEG). In MPEG-4 the Initial OD has to be delivered reliably. There is no compromise possible wrt real time delivery. In a broadcast MPEG-2 TS environment we achieve that by repeating that information in one of the carouseled MPEG-2 TS tables. In my IP multicast implementation I achieve reliability by fetching the IOD through HTTP. These are just examples. Anyway the IOD is not an elementary stream. MPEG-4 OD and BIFS streams have similar requirements, but in some cases some Access Unit may become useless if too late. We defined a BIFS Carousel algorithm (expecially for the broadcast scenario) to enable random tune-in within a running session and also cope with the non-0 possibility of AU loss. I know of people in MPEG-4 that are considering to use a backchannel to request the retransmission of portions of a scene, in case the scene itself is delivered unreliably. (As I understand it) the scene is in this case a complex SNHC graph and the intent is to preserve the real time nature of the media -thus avoid TCP like transmission- while maximising the possibility of rendering as much as possible of the graph itself. To my understanding, this people is defining a full syntax for requesting retransmissions, and simply assumes that the delivery layer provides a backchannel. Whether such backchannel, in the case of Internet best-effort, can be mapped into RTCP or not, is a matter that could be further investigated. Best regards Guido Franceschini CSELT, Via Reiss Romoli 274 , I-10148 Torino - Italy Tel + 39 011 228 6137 Fax + 39 011 228 6299 Email guido.franceschini@cselt.it From rem-conf Tue Jan 11 05:46:55 2000 From rem-conf-request@es.net Tue Jan 11 05:46:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1281XI-0005dk-00; Tue, 11 Jan 2000 05:40:36 -0800 Received: from khumbu.eeng.dcu.ie [136.206.35.10] by mail1.es.net with smtp (Exim 1.81 #2) id 1281XG-0005dX-00; Tue, 11 Jan 2000 05:40:35 -0800 Received: from (eeng.dcu.ie) [136.206.35.77] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 1281XD-0001Ag-00; Tue, 11 Jan 2000 13:40:31 +0000 Message-ID: <387B32DB.2A0B1514@eeng.dcu.ie> Date: Tue, 11 Jan 2000 13:40:44 +0000 From: Nikki Cranley <94426082@eeng.dcu.ie> X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTCP_Rx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, Would anyone have more information about the packet structure of RTCP_Rx in particular the different values for the Payload Types and the RXP values. Also have there been any further developments of RTCP_Rx for streamed multimedia content, in particular MPEG-4? I am hoping to try and implement this RTCP_Rx to provide QoS mechanisms to get near-reliability by tagging on the essential streams that are lost/delayed and then selectively requesting `for it to be sent again. Thanks for all your help, Nikki From rem-conf Tue Jan 11 10:06:14 2000 From rem-conf-request@es.net Tue Jan 11 10:06:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1285TL-0001N3-00; Tue, 11 Jan 2000 09:52:47 -0800 Received: from nscolmar.colmar.uha.fr (gate.colmar.uha.fr) [194.167.108.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 1285TJ-0001Mn-00; Tue, 11 Jan 2000 09:52:45 -0800 Received: by gate.colmar.uha.fr; (8.8.8/1.3/10May95) id SAA11556; Tue, 11 Jan 2000 18:43:48 +0100 (MET) From: Received: from somewhere by smtpxd Message-Id: <3.0.5.32.20000111185020.00907cc0@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 11 Jan 2000 18:50:20 +0100 To: conf@colmar.colmar.uha.fr Subject: ECUMN - Extended Deadline Feb 11th. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My sincere apology if you receive multiple copies of this CFP. Please feel free to pass the CFP to anyone who might be interested. Kind regards, ---------------------------------------------------------------------------- =09 CALL FOR PAPERS 1st IEEE European Conference on Universal Multiservice Networks ECUMN'2000 IP Networks Versus Conventional Switched Networks October 2-4, 2000 - CREF, Colmar, France URL: http://iutsun1.colmar.uha.fr/ECUMN2000.html Sponsors are the following national scientific societies in Europe, which cooperate under the roof of: EUREL, Brussels, Belgium: AEI, Milano (Italy), IEE, London (UK), =D6VE/GIT, Vienna (Austria), SEE, Paris (France), SEV/ITG, Fehraltorf, (Switzerland), VDE/ITG, Frankfurt (Germany), WSES as well as the IEEE Communications and Computer. Supported by: France Telecom Alcatel Newbridge Other Supporters pending: Conference Scope: This conference follows the two successful ATM conferences events held in Colmar, France in 1998 and 1999. The conference scope has been extended to deal with the different topics related to Multiservice Network Architectures, and Implementation, including among others, protocols, signaling, traffic flow, addressing schemes, =85 Fundamental questions still have to find an answer, such as: How will the Internet, symbol of freedom, compete with the world of traditional carrier networks or cooperate with it?=20 Will alternate Technologies be needed to meet high level quality of service requirements ? What restrictions, if any, will result on the desired degree of freedom ? Emphasis shall be put upon network convergence, including fixed/mobile convergence satisfying the needs of person to person communications, as well as Information and Entertainment applications. The scope of ECUMN'2000 encompasses but is not limited to: Evolution of Telecommunication Networks Architecture: * Core network * Access networks * CPN (Customer Premise Networks including home networks) * Multiservice mobile networks * Interoperability issues, Interfaces and Reference points Packet, frame and cell protocols: * Addressing * Multicasting * Switching and routing * Signaling * Traffic control and QoS Network management and control: * Network design - Migration strategies * Active networks versus Intelligent networks Service impact (multimedia, VPN, ...) on network architecture: * Fixed-Mobile Convergence * Packetized voice * Experimentation and fields trials With such a variety of problems to be solved, and such high economical interests at stake there is a definite interest to exchange ideas, technical results and proposals, between the academic and industrial communities and this is the major goal of the conference. Instructions for Authors: Mail four paper versions or E-mail preferably in Word 6 format, or alternately a postscript version of a 2000-word extended abstract summarizing an original work finalized or in progress. All the manuscripts must be written in English. The top of the first page of each paper should include the title of the paper, authors' name, position, address, telephone and fax numbers, Email of the author responsible for correspondence and a list of four keywords at least.=20 Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings. All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: +33 389202366=20 Fax: +33 389202359=20 Mobile: +33 603658042=20 E-mail: lorenz@colmar.uha.fr=20 Important Deadlines: Extended abstract due: February 11, 2000 Notification of acceptance: April 10, 2000 Camera-ready full papers due (2 columns, 8 pages max): June 10, 2000 Best papers will be forwarded for consideration in a special issue of the journal "Annals of telecommunications". A competition for the best student paper will be organized to recognize and encourage excellence in graduate studies. Tutorials: Tutorials will present overviews of current high interest topics. Proposals tutorials are due by February 11, 2000. Conference Committees General Chair: Pascal Lorenz (France) - University of Haute Alsace Technical Program Chair: Annie Gravey (France) - France Telecom Cnet Tutorials Chair: Sylvie Ritzenthaler (France) - Newbridge Learned Societies Liaison Chair: Renato Israel (France) - SEE Prosper Chemouil (France) - France Telecom Cnet Michel Levy (France) - Alcatel Jean-Louis Pernin (France) - Consultant Guy Pujolle (France) - University of Versailles-Saint-Quentin Pierre Rolin (France) - France Telecom Cnet Scientific Program Committee: H. Afifi (France) - ENST Bretagne E. Biersack (France) - Eurecom M. Boari (Italy) - University of Bologna D. Bonjour (France) - France Telecom Cnet=20 T. Braun (Switzerland) - University of Berne P. Brown (France) - France Telecom Cnet P. Chemouil (France) - France Telecom Cnet G. Colombo (Italy) - CSELT J.P. Coudreuse (France) - Mitsubishi W. Dabbous (France) - INRIA A. Danthine (Belgium) - University libre of Li=E8ge M . Diaz (France) - LAAS M. Erradi (Morocco) - ENSIAS=20 S. Fdida (France) - LIP6 F. Ferrero (Italy) - CSELT=20 G. Fiche (France) - Alcatel CIT A. Gravey (France) - France Telecom Cnet S.J. Halme (Finland) - Helsinki University of Technology G. H=E9buterne (France) - INT H.G. Hegering (Germany) - University of Munich D. Hutchinson (UK) - Lancaster R. Israel (France) - SEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy M. Joubert (France) - Cegetel F. Kamoun (Tunisia) - ENSI=20 M. Karpov (Russia) - St Petersburg University P. Key (UK) - Microsoft D. Kofman (France) - ENST Paris U. Korner (Sweden) - University of Lund U . Krieger (Germany) - Deutsche Telecom P. Kuhn (Germany) - University of Stuttgart G.S. Kuo (Taiwan) - National Central University M. Labetoulle (France) - Institut Eurecom Sophia-Antipolis M. Le Boudec (Switzerland) - EPFL F. Le Faucheur (France) - Cisco G. Leduc (Belgium) - University of Liege Y. Legrand (France) - Bouygues M. Levy (France) - Alcatel P. Lorenz (France) - University of Haute Alsace=20 M. Loukola (Finland) - Helsinki University of Technology B. Maglaris (Greece) - National Technical University Athens H. Maher (Switzerland) - EPFL Z. Mammeri (France) - University of Toulouse=20 S. Martignoni (Switzerland) - Ascom TechLtd N. Mastorakis (Greece) - Military Institutions of University Education U. Mocci (Italy) - FUB M. Nunes (Portugal) - IST/INESC G. Omiyar (USA) - Computer Sciences Corp J.J. Pansiot (France) - University of Strasbourg J.L. Pernin (France) - Consultant G. Petit (Belgium) - Alcatel Anvers M. Potts (Switzerland) - Martel=20 G. Pujolle (France) - University of Versailles-Saint-Quentin S. Rao (Switzerland) - TELSCOM=20 M. Renaldo (France) - SAGEM M. Riguidel (France) - Thomson S. Ritzenthaler (France) - Newbridge=20 J. Roberts (France) - France Telecom Cnet P. Rolin (France) - France Telecom Cnet=20 R. Schutz (France) - CS Telecom H. Tobiet (France) - Clemessy=20 S. Tohme (France) - ENST Paris L. Toutain (France) - ENST Bretagne P. Tran Gia (Germany) - University of W=FCrzburg P. Van Heck (The Netherlands) - Erasmus University P. Van Mieghem (The Netherlands) - Delft University of Technology E. Vazquez Gallo (Spain) - University of Madrid=20 V.A. Villagra (Spain) - University of Madrid M. Villen (Spain) - Telefonica I+D From rem-conf Tue Jan 11 23:35:41 2000 From rem-conf-request@es.net Tue Jan 11 23:35:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 128I93-0002Yn-00; Tue, 11 Jan 2000 23:24:41 -0800 Received: from batumi.basri.net [195.145.251.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 128I8w-0002Y6-00; Tue, 11 Jan 2000 23:24:35 -0800 Received: from 208.15.107.215 by batumi.basri.net (8.8.8/1.1.19.2/28Oct99-1024AM) id LAA09816; Wed, 12 Jan 2000 11:21:41 +0400 (Georgia) From: Message-Id: <200001120721.LAA09816@batumi.basri.net> To: bnk@aol.com Subject: Blast Your Ad To 1 Million Eager Prospects!$$$ Make BIG PROFITS NOW!!! Date: Wed, 12 Jan 00 02:13:37 Eastern Standard Time Reply-To: srv12@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; NOW YOUR ONLY REAL SOLUTION TO E-MAIL MARKETING...
BULK EMAIL YOUR AD OUT TO 1 MILLION EMAIL PROSPECTS!

Reach up to 1,000,000+ of potential customers at one time....anytime
you like and We SEND IT OUT FOR YOU!

Some customers recieve up to 10,000 LEADS and SALES for their Offers!

NEW! You Can Now Choose to have added NATION-WIDE Targeted
Fresh businesses by SIC code! ex: Physcians, Travel Agencies,
Consultants, Real Estate, Financial Brokers, Or Fresh Targeted MLM,
Business Opportunity Seekers Email Addresses for your Money Making Blast-Out!!

100,000 - $349
200,000 - $649
500,000 - $1,200
1,000,000 - $1,900
2,000,00 - $2,700

CALL TOLL FREE 1-888-821-1951
(Serious inquires only.)

PLUS 50% OFF Sale for Fax Numbers this week only.
100,000 Hot MLM/Biz- OPP FAX Numbers Only $300.

May HUGE $$Prosperity be YOURS for the New Millenium!

Thank you.

GSM
1-888-821-1951

 From rem-conf Wed Jan 12 05:53:04 2000 From rem-conf-request@es.net Wed Jan 12 05:53:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 128NuN-00079Z-00; Wed, 12 Jan 2000 05:33:55 -0800 Received: from nic.funet.fi [193.166.0.145] by mail1.es.net with esmtp (Exim 1.81 #2) id 128NuM-00079N-00; Wed, 12 Jan 2000 05:33:54 -0800 Received: from localhost ([127.0.0.1]:34655 "EHLO localhost" ident: "NO-IDENT-SERVICE" smtp-auth: TLS-CIPHER: ) by nic.funet.fi with ESMTP id ; Wed, 12 Jan 2000 15:33:28 +0200 To: rem-conf@es.net Subject: Enterprise Forum multicast X-Mailer: Mew version 1.95b3 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000112153328K.hks@nic.funet.fi> Date: Wed, 12 Jan 2000 15:33:28 +0200 From: "Harri K. Salminen" X-Dispatcher: imput version 991025(IM133) Lines: 121 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FUNET-TV will multicast the following lecture series live on the MBONE channel "FUNET-TV: Enterprise Forum". Transmission will use at least relatively high speed H.261 -video (around 1Mbit/s) and is aimed primarily for universities connected via FUNET, NORDUnet, TEN-155, Abilene or vBNS. First lecture starts on 20.1.2000 16:15 (CET), see the attached description and the web pages for exact schedule. We plan to use TTL 127 for a global multicast if that doesn't raise serious technical problems somewhere. Is there anymore any consensus on the global TTL levels or any plans for scopes covering just the high speed academic networks? The only documents I found are bit outdated and from days before native multicast etc. Otherwise we might have to use some lower TTL combined possibly with several unicasts... We have for example several FVC I-Studio's currently available so that we can arrange an RTP/MPEG-1 multicast fairly easily. We just also got some new software which may enable us to multicast UDP/MPEG-2 transport possibly using the SGI Mediabase in the middle which may interest you. It would be nice to know what would be the best TTL (we don't yet have scopes beoynd NORDUnet I think) for such streams (e.g. 4 Mbit/s). For uplink we have to use ATM/MJPEG codec at 20Mbit/s connected to cameras via a composite video mixer and use also SDI/analog conversions at our end so it might not look quite as good as it could be but it should usually be 25fps at least with "VHS quality" Lower speed streams are also possible although we haven't planned for them unless there's a real demand. We may have a low speed announcement video on the channel with a short high speed burst on the channel in the mean time for testing but it's not ready yet. http://tv.funet.fi/ohjelmat/tkk/ef-multicast.html or contact funet-tv@tv.funet.fi for more technical information and possibly available options like MPEG feeds. Harri Salminen Harri K. Salminen - Finnish University & Research Network hks@nic.funet.fi, Tel +358 9 4572005, fax +358 9 457 2302 http://www.funet.fi/~hks, http://www.funet.fi, OH2LGE CSC/FUNET, PL 405, 02101 Espoo, Finland - European Union Enterprise Forum The Enterprise Forum philosophy Enterprise Forum is expected to give a glance into the world the top executives live in. In Enterprise Forum, the people who make the decisions are brought together to discuss the issues they are facing, the topics that are in central role in the formation of our future. The aim of Enterprise Forum is to help the students and other spectators understand the world of business and politics, what is going on, who makes things happen, and how decisions are made. In the Enterprise Forum seminars we can meet these persons live and hear how they see the world. What is Enterprise Forum? Appearing first in the world and arranged every year since 1973, Enterprise Forum sessions have gained a lot of interest and publicity by providing the leaders of the business and political worlds with the opportunity to discuss the topics of today. During the latest years Enterprise Forum has covered topics such as the European Union, the transition process in Russia, the Internet and changes that different industries are undergoing. The insights into these questions are provided by the people who are in charge of the answering themselves. This year's seminar brings again the leading business executives and the top new entrepreneurs around the same table with the highest level political decision-makers. The seminar sessions are transmitted via Internet to a number of European universities and university towns. Many of those following the program through the Internet can state questions on-line during the sessions. This whole concept, Enterprise Forum of Helsinki University of Technology, is unique in the world and has gained wide recognition. We want to provide You part of it this year. Guest speakers of Enterprise Forum Every year the Enterprise Forum has been honored by very distinguished speakers. Persons like Bo Berggren, chairman of the board of Astra and Stora, Percy Barnevik, former CEO of ABB, Hermann Franz, former chairman of the supervisory board of Siemens AG, Jürgen Schrempp, chairman of the supervisory board of Deutsche Aerospace AG and chairman of the board of Daimler Benz, Umberto Columbo, former chairman of the supervisory board of Eni in Italy, Peter Wallenberg, former chairman of the board of Investor AB, Philip Kotler, Dr and Mrs Mauno Koivisto, former president of the Republic of Finland, and chairmen of the boards and CEOs of most of the biggest Scandinavian companies have been guest speakers at the Enterprise Forum. Enterprise Forum 2000 This year the Enterprise Forum is honored by very distinguished speakers including Marcus Wallenberg Jr, Vice President of Investor AB, Geoffrey Moore, Chairman and founder of the Chasm Group, Jorma Ollila, Chairman of the Board of the Nokia Corporation, presidential candidate Elisabeth Rehn, Martin Saarikangas, CEO of Masa Yards and Matti Honkala, CEO and Chairman of the board of Kesko. The Enterprise Forum sessions are broadcast live over the Internet on Thursday evenings between 17:15 and 19:00 (Finnish time = CET +1). The first seminar session is on Thursday 2000-01-20. More information about the schedule and topics can be found on the Enterprise Forum homepages. Contact information In terms of any questions, please contact us in order to discuss how we can fit the outcomes of Enterprise Forum to meet Your specific needs. Emeritus Professor Martti M Kaila, Professor Ilkka Kauranen, Mr Markku Multamäki and Ms Pia Back telephone int 358 9 4 514 822 facsimile int 358 9 4 513 095 e-mail enterprise.forum@hut.fi URL http://www.tuta.hut.fi/coursedata/tu91142/ From rem-conf Sun Jan 16 00:08:55 2000 From rem-conf-request@es.net Sun Jan 16 00:08:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 129kX2-0002s7-00; Sat, 15 Jan 2000 23:55:28 -0800 Received: from mail.lekkerland.de (dpxps001.lekkerland.de) [195.71.144.250] by mail1.es.net with esmtp (Exim 1.81 #2) id 129kWz-0002qt-00; Sat, 15 Jan 2000 23:55:25 -0800 Received: from LocalHost ([208.26.26.3]) by dpxps001.lekkerland.de (Netscape Messaging Server 3.6) with SMTP id AAA8B16; Sun, 16 Jan 2000 09:01:22 +0100 Date: Sun, 16 Jan 2000 02:42:34 Content-Type: text/plain Subject: Re: Adv: Web Site For You To: X-Accept-Language: en From: MessageID: Message-ID: <7735C1586F.AAA8B16@dpxps001.lekkerland.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Need full service web site hosting? You don't want to pay for every little extra? Then you need to take a look at this service; Affordable fees for hosting at your own domain. Domain name resolves with or without "www" prefix. At only 50 cents per meg per month down to only 20 cents per meg per month you will have your own cgi-bin with access to many free scripts such as discussion forum, counter, site statistics, password protection administration, error redirects, shopping cart, ect. We will submit your site to 900+ search engines and directories once every six months at no charge. We will do the paperwork for your domain name registration or transfer at no charge. You can have up to 10 POP accounts at no additional cost, as well as unlimited email aliases and forwarding. Do you need Front Page extensions? Also no charge. When you purchase a commerce account you will have the free use of a secure server to give your customers piece of mind when you accept their credit card info securely through an encrypted connection. Also, with the commerce accounts comes the use of your own private password protected directory on the secure server so that you may store the submitted info and retrieve that info safely without compromising security at any stage. When you pay for a year in advance you will get 25-30% off. We do not want to rip you off like many others charging insane amounts for typical add-ons. You will get it all Free! Please phone with any questions or to order: 1-888-352-5445 MB Price Per Month Price Per Year Basic 20 NA $120 Commerce 50 $25 $225 Pro Commerce 100 $35 $300 No Setup Fees (Setup fees are just plain silly) Purchase more than one account in your name during the course of a year and you will have reseller status. Resellers will get an additional 20% off! We have many design companies that take advantage of these super low prices to offer complete packages to their customers. You can mark it up as you see fit and still remain very competitive with your pricing. We will remain a silent partner, you can consider it your hosting service and advertise it as such. You would have your own administrative directory to control requests on all of your clients accounts. Interested? Call today! 1-888-352-5445 We also offer website design services at a very competitive rate. ****************** Remove Requests ******************* `\|||/ Wishing you the Best! (@@) ooO_(_)_Ooo________________________________ _____|_____|_____|_____|_____|_____|_____|_____| ___|____|_____|_____|_____|_____|_____|_____|____ _____|_____Please pardon the intrusion_|____|_____ To be removed from future mailings just reply to this email with "Remove" as the subject or phone us at: 1-888-352-5445(state your email address) and you will be permanently removed from any future mailings. From rem-conf Sun Jan 16 16:10:55 2000 From rem-conf-request@es.net Sun Jan 16 16:10:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 129zd3-0002vG-00; Sun, 16 Jan 2000 16:02:41 -0800 Received: from shez.lightrealm.com (webworksps.com) [207.159.139.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 129zd2-0002ux-00; Sun, 16 Jan 2000 16:02:40 -0800 Received: from LocalHost (Nic3.Crystalnet.net [209.103.204.11] (may be forged)) by webworksps.com (8.8.7/8.8.5) with SMTP id QAA24333; Sun, 16 Jan 2000 16:01:36 -0800 (PST) From: host4@crescotek.com Message-Id: <200001170001.QAA24333@webworksps.com> Subject: Ink Jet Cartridge Special with 1 Year Warranty! (jsd739) Content-Type: text/plain X-In-Response-To: 04B31B351 X-Other-References: 0D378BFDB X-See-Also: 042FEC89A X-Accept-Language: en To: References: 0348A1515 MessageID: <2p7zz1iqtz2ic1z.160120001804@LocalHost> Sensitivity: Public Date: Sun, 16 Jan 2000 18:04:30 X-Mailer: Internet Mail Service [26.3.2863.22] (Linux; I) X-References: 09241C16D, 0467E032B X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We carry inkjet cartridges for Epson, Canon and HP and have the following specials. One year warranty with all purchases. For more information mailto:inkcartridges@mibarrio.com, see below for removal Epson 400/500/600 Black cartridge (S020093) $7.95 Epson 400/600/800/1520 Color cartridge (S020089) $9.95 Epson 200/500 Color cartridge (S020097) $8.50 Epson 440/640 Black cartridge (S020187) $8.50 Epson 440/640 Black cartridge (S020189) $9.50 Epson 440/640/740 Color cartridge (S020191) $11.50 Epson 700 Color cartridge (S020110) $13.95 Epson 750 Color cartridge (S020193) $14.95 Epson 900 Black cartridge (T003011) $14.95 Epson 900 Color cartridge (T005011) $17.95 For more information mailto:inkcartridges@mibarrio.com, see below for removal Canon 4000/4100/4200 BC-21 Black cartridge $5.25 Canon 4000/4100/4200 BC-21 Color cartridge $7.95 Canon 600/610/620 BCMY Cartridge set $10.50 For more information mailto:inkcartridges@mibarrio.com, see below for removal HP 51626A Recycled cartridge $16.95 HP 51645A Recycled cartridge $16.95 HP 51629A Recycled cartridge $16.95 For more information mailto:inkcartrdiges@mibarrio.com, see below for removal Shipping is $3.50 for unlimited quantities. All packages are sent vis USPS third day. *All Epson and Canon cartridges are new compatibles. For more information mailto:inkcartridges@mibarrio.com, see below for removal +++++++++++++++++++++++++++++++++++++++++++++++++++ For Removal Please reply with Remove in the subject or call toll free 877-202-0942 and you will be permanently removed from future mailings. +++++++++++++++++++++++++++++++++++++++++++++++++++ From rem-conf Mon Jan 17 01:37:30 2000 From rem-conf-request@es.net Mon Jan 17 01:37:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12A8Hj-000060-00; Mon, 17 Jan 2000 01:17:15 -0800 Received: from teco68pc.teco.uni-karlsruhe.de [129.13.170.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 12A8Hh-00005q-00; Mon, 17 Jan 2000 01:17:13 -0800 Received: from teco154pc (teco154pc.teco.uni-karlsruhe.de [129.13.170.154]) by teco68pc.teco.uni-karlsruhe.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL8GFNP4; Mon, 17 Jan 2000 10:15:16 +0100 Reply-To: From: "Albrecht Schmidt" To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Cc: "Albrecht Schmidt" , Subject: CfP: Situated Interaction in Ubiquitous Computing Date: Mon, 17 Jan 2000 10:14:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Please apologize, if you receive multiple copies of this CfP) Workshop on ‘Situated Interaction in Ubiquitous Computing’ (http://www.teco.edu/chi2000ws/) at CHI 2000, April 3, 2000, The Hague, Netherlands (http://www.acm.org/chi2000) Workshop Proceedings to be published by Springer as Special Issue of Journal "Personal Technologies" (http://www.csm.uwe.ac.uk/cpim/PeTe.html) IMPORTANT DATES 28 January 2000 Extended Abstracts and Position papers must be received 4 February 2000 Notification to authors 3 April 2000 Workshop at CHI2000 OVERVIEW This workshop will bring together researchers and practitioners who are concerned with design, development, and implementation of novel interfaces for mobile devices and environment-based appliances. The availability of sensing technology provides the opportunity to include information about the situation of use as well as the surrounding environment (e.g. location, proximity, physical conditions, social setting, context, etc.) in human computer interaction. Situated interaction is especially attractive for mobile devices that are used while on the move e.g. - PDAs - wearable computers - smart mobile phones, and for shared appliances in common spaces, e.g. - city information systems, - ticket machines, - self-service check-in counters. The main goal of the workshop is to develop an understanding of how the situation of use influences the interaction process. TOPICS OF INTEREST INCLUDE: * Adaptation of input and output modalities to the situation of use * New interaction metaphors that include situation and context * Design rules and principles for context-aware systems and user interfaces * Design methodologies for developing situation-aware user interfaces * User-centered approaches to the design of situation-aware systems and interfaces * User models that help predict the behavior of users of situation-aware systems * Studies of adaptive and situation-aware user interfaces * Mechanisms and technologies for extracting, interpreting and using context information * Adaptation strategies that help to reduce the need for input or output * Strategies for choosing interruption time and mode appropriate to the situation * Interfaces for mobile devices that make use of information about the environment and the user's situation * User interface agents and active user interfaces * The use of situation and context in CSCW and groupware * Adaptive interfaces for users with disabilities * Adaptive multimodal user interfaces SUBMISSION DETAILS We encourage submissions from researchers and practitioners in academia, industry, government, and consulting. Authors are invited to submit an extended abstract (about 2000 words) describing original work in one or more of the areas listed above, or a position paper (about one page) highlighting the authors' interests. Please be specific about the status of the work and why you believe it should be of interest to the workshop audience. Submissions should be mailed in PDF or postscript format to Albrecht Schmidt (albrecht@teco.edu) at the University of Karlsruhe by the end of the day on 28 February 2000. All submissions will be reviewed and some of the submitters will be invited to present their ideas at the workshop. Participants will be selected based on the quality of the work and its likelihood to spur interesting discussion. Authors of accepted extended abstracts will be asked to present their work at the workshop. PUBLICATION The results of this workshop will be published in a special issue of the Springer Journal ‘Personal Technologies’ (http://www.csm.uwe.ac.uk/cpim/PeTe.html). Following the workshop all authors of extended abstracts will be invited to resubmit their abstracts as short papers to be reviewed for inclusion in this special issue. The review committee will consist of 10 recognized leaders of the HCI community and related fields. WORKSHOP ORGANIZATION The workshop will last one full day and will be limited to 20 participants. Accepted submissions will be made available online prior to the workshop and will also be distributed during the workshop. The workshop will consist of two parts. During the first part participants will present current research, while the second part is reserved for discussion. A set of possible discussion topics will be generated in advance from a questionnaire that will be sent to each participant prior to the workshop. WORKSHOP CHAIRS Albrecht Schmidt, Telecooperation Office (TecO), University of Karlsruhe, Germany Walter Van de Velde, Starlab Nv/Sa, Belgium Gerd Kortuem, Department of Computer Science, University of Oregon, USA For questions and further information, please contact Albrecht Schmidt Telecooperation Office (TecO) University of Karlsruhe Vincenz-Priessnitz-Str. 1 76131 Karlsruhe (Germany) Phone: +49 721 6902-29 Fax: +49 721 966 3418 Email: albrecht@teco.edu Workshop page: http://www.teco.edu/chi2000ws/ CHI2000 page: http://www.acm.org/sigchi/chi2000/ From rem-conf Mon Jan 17 06:41:13 2000 From rem-conf-request@es.net Mon Jan 17 06:41:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AD4H-0004Xp-00; Mon, 17 Jan 2000 06:23:41 -0800 Received: from hpheger3.nm.informatik.uni-muenchen.de [129.187.214.23] (vogt) by mail1.es.net with esmtp (Exim 1.81 #2) id 12AD4F-0004XA-00; Mon, 17 Jan 2000 06:23:39 -0800 Received: (from vogt@localhost) by hpheger3.nm.informatik.uni-muenchen.de (8.9.3 (PHNE_18979)/8.8.6) id PAA03438 for rem-conf@es.net; Mon, 17 Jan 2000 15:23:30 +0100 (MET) Date: Mon, 17 Jan 2000 15:23:30 +0100 (MET) Message-Id: <200001171423.PAA03438@hpheger3.nm.informatik.uni-muenchen.de> From: USM 2000 Organisation Committee To: USM 2000 Subject: USM 2000 - Last Call for Papers X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Please apologize, if you receive multiple copies of this CfP) USM 2000: LAST CALL FOR PAPERS 3rd IFIP/GI International Conference on Trends towards a Universal Service Market Munich, Germany September 12-14, 2000 General Information USM 2000 is the third event in a series of international IFIP conferences on Trends in Distributed Systems. It continues TreDS'96, held in Aachen, Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg, Germany. The technological progress in internet and telecommunication domains as well as deregulation efforts of the telecommunication markets currently under way in many countries enable an integration of data and telecommunication. Distributed platforms get adapted to the needs of telecommunication networks. This leads to a global distributed system with millions of objects, running on top of a middleware kernel and interacting with each other to provide services. USM 2000 brings together researchers, service vendors and users in the field of universal service markets. USM 2000 takes place in Munich, Germany, the city of the famous Oktoberfest which will start two days after the conference on September 16, 2000. Topics The USM 2000 considers services of a universal market in relation to middleware, distributed applications and management. Areas of special interest include: * Component Based Systems, Service Creation * Service Market Models, Accounting and Customer Care * Quality of Service for Distributed Applications * Trading, Brokering and Information Management * Management of Virtual Networks * Service and Application Management * Ubiquitous Services and Nomadic Computing * Distributed and Mobile Objects * Agent Technology for Integrated Management * Advances in Middleware, e.g. CORBA, DCOM, Jini * Telecommunication Architectures related to Distributed Systems Submissions You are encouraged to submit full technical papers describing original, unpublished research or experience of about 12 pages. Extended abstracts of 3-5 pages will be accepted for poster session papers. For submission guidelines please visit our web server. The proceedings will be published in "Lecture Notes in Computer Science", Springer-Verlag. Submissions due: January 30th, 2000 Notice of Acceptance: April 15th, 2000 Camera-ready Paper due: June 1st, 2000 Further Information Contact Person: Helmut Reiser - Phone (Fax): +49 89 2178 2163 (~2147) e-mail: usm2000@informatik.uni-muenchen.de, WWW: http://usm2000.informatik.uni-muenchen.de/ Address: Ludwig Maximilians University Institute for Computer Science Oettingenstr. 67 D-80538 Munich GERMANY Conference Chairs Claudia Linnhoff-Popien and Heinz-Gerd Hegering, LMU Munich Program Committee Sebastian Abeck, Uni Karlsruhe, Germany Andrew T. Campbell, Center for Telecommunications Research, Columbia Uni New York, USA John Dilley, Hewlett Packard, Palo Alto, USA Kurt Geihs, Uni Frankfurt, Germany Bernd Heinrichs, Cisco Systems Europe, Düsseldorf, Germany Yigal Hoffner, IBM Zurich Research Laboratory, Switzerland Axel Küpper, RWTH Aachen, Germany Lea Kutvonen, Uni Helsinki, Finland Winfried Lamersdorf, Uni Hamburg, Germany Luigi Logrippo, Uni Ottawa, Canada Michael Merz, Ponton, Hamburg, Germany Zoran Milosevic, DSTC Brisbane, Australia Elie Najm, Ecole Nationale Superieure des Telecommunications, Paris, France Bernhard Neumair, DeTeSystem, Germany Jerome Rolia, Uni Ottawa, Canada Alexander Schill, TU Dresden, Germany Doug Schmidt, ARL St. Louis, USA Gerd Schürmann, GMD FOKUS, Germany Morris Sloman, Imperial College, London, UK Otto Spaniol, RWTH Aachen, Germany Michael Stal, Siemens ZT, München, Germany Ralf Steinmetz, TU Darmstadt, Germany Volker Tschammer, GMD FOKUS, Berlin, Germany Conference Organisation Helmut Reiser (Chair), Christian Ensel, Markus Garschhammer, Rainer Hauck, Bernhard Kempter, Annette Kostelezky, Igor Radisic, Holger Schmidt, Gerald Vogt, LMU Munich Sponsors Ludwig-Maximilians-University (LMU) International Federation for Information Processing (IFIP) German Informatics Society (GI) Computing Centre of the Bavarian Academy of Sciences (LRZ) BMW AG DG Bank Bavaria's Software Initiative Munich Network Management Team (MNM) and others From rem-conf Mon Jan 17 07:49:14 2000 From rem-conf-request@es.net Mon Jan 17 07:49:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AEIh-0007Jf-00; Mon, 17 Jan 2000 07:42:39 -0800 Received: from ns.ciac.ac.cn (ciac.ac.cn) [159.226.166.1] by mail1.es.net with smtp (Exim 1.81 #2) id 12AEHt-0007F4-00; Mon, 17 Jan 2000 07:42:11 -0800 Received: from mail45.rasasjdsaiod.com by ciac.ac.cn (SMI-8.6/SMI-SVR4) id XAA21201; Mon, 17 Jan 2000 23:41:03 +0800 From: To: Date: Mon, 17 Jan 2000 07:05:07 Message-Id: <508.820917.823204@mail45.rasasjdsaiod.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Put Money Into Your Pocket! Use our bulk email service today! Send your message to lots and lots of people NOW! Half million email broadcast $550.00. One million email broadcast $1200.00. Call today, 1 877 205 9117 for details on how to put your cold calling days to an end! SENT BY E MAIL SPECIALTIES TORONTO CANADA ALL PRICES IN US FUNDS From rem-conf Mon Jan 17 08:42:42 2000 From rem-conf-request@es.net Mon Jan 17 08:42:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AFAH-00027F-00; Mon, 17 Jan 2000 08:38:01 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12AFAF-000273-00; Mon, 17 Jan 2000 08:37:59 -0800 Received: from p71.nas3.is3.u-net.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jan 2000 16:37:22 +0000 Message-ID: <002401bf6109$1b7f7100$47c566c3@tenaga> From: Farez To: rem-conf Subject: CFP: Asian International Mobile Computing Conference, Malaysia (AMOC 2000) Date: Mon, 17 Jan 2000 16:34:30 -0000 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My apologies if you have received this before. Farez -------------------------------------------------------------------------- Call for Papers FIRST ASIAN INTERNATIONAL MOBILE COMPUTING CONFERENCE (AMOC 2000) 1-3 November, 2000. Penang, Malaysia http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc *** Submission deadline: 30 May, 2000 *** Mobile computing is a new and highly dynamic field which combines modern computer science, networking and wireless communication technologies. This conference will provide a platform for researchers and practitioners to meet and discuss current issues in this field. The conference is also unique as it highly encourages contributions >from the Asian region alongside those from other parts of the globe. The focus on Asia is important because there are unique regional issues not given attention in typical international conferences, where technological issues in developed nations receive centre stage. These issues include different infrastructural and economic requirements; the effect of a more diverse socio-economic environment on technical specifications; the far-reaching impact of wireless communication in rural areas and the great interest in the rapid deployment of cutting edge technology due to the high progress rate of technological implementation in many Asian countries. The main objectives of this conference are: 1. To provide a platform for international and Asian researchers and professionals to meet and discuss issues pertinent to both universal and Asia-centric mobile computing issues. 2. To provide participants with up-to-date information regarding the development in this field. 3. To provide a yardstick by which researchers may compare the quality of their work to that of their peers in order to maintain a high standard of research. The topics of interest include, but are not limited to, those listed below: o Quality of Service(QoS) o handover & location management o systems infrastructure o satellite technology o internet access o power management o data services o lower layer protocols o rural wireless communications o data management o billing o security o e-commerce o agent technology o multimedia o hardware o Personal Communication Systems o terminal design & ergonomics o wireless LANs / WANs o nomadic systems Important Dates ------------------- Submission deadline: 30 May, 2000 Notification of acceptance: 30 August, 2000 Camera ready copy: 15 September, 2000 Submission Guidelines ---------------------------- Papers should be original, unpublished and not more than ten single-spaced pages with a minimum font size of 10 pt. Papers should be submitted in postscript format, and should only contain the paper title and the body of the paper, WITHOUT author names and affiliations. A separate document containing only the title, author names their respective affiliations, in plain text format, is required. Please send your paper (in postscript format) and your separate author page (in plain text format) in separate emails to amoc-submission@fsktm.um.edu.my by the 30th of May, 2000. For more information, please visit http://www.fsktm.um.edu.my/amoc/ or email amoc-submission@fsktm.um.edu.my Best Student Paper Award ------------------------ The best paper with a student as primary author will be awarded a really cool prize of US$500 during the conference. Student authors who would like to be considered for this award should write 'Student Paper' in the plain text document containing the paper title and author name(s) and affiliation(s). Organising Committee -------------------- Prof. Ir. Dr. Mashkuri Hj. Yaacob (Universiti Malaya) Dr Mazliza Othman (Universiti Malaya) Alfarez Abdul Rahman (University College London) Dr Roziati Zainuddin (Universiti Malaya) Dr. Zaitun Abu Bakar (Universiti Malaya) Rodziah Latih (Universiti Kebangsaan Malaysia) Norizan Mohd Yasin (Universiti Malaya) Omar Zakaria (Universiti Malaya) Mustaffa Kamal (Universiti Malaya) Technical Program Committee --------------------------- Assoc. Prof. David K. Asano, Shinshu University, Japan Prof. Boualem Boashash, Queensland University of Technology, Australia Dr. Che Nyan Husain, Telekom Malaysia Prof. Chuah Hean Teik, Universiti Multimedia Telekom, Malaysia Prof. Jon Crowcroft, University College London, UK Assoc. Prof. Dr Norsheila Faisal, Universiti Teknologi Malaysia Dr. Stephen Hailes, University College London, UK Ravi Jain, Telcordia, USA Dr. Minseok Kang, LG Corporate Institute of Technology, Korea Prof. Ryuji Kohno, Yokohama University, Japan Prof. Sung-Kwon Chung, Seoul National University, Korea Jong-Hyeon Lee, Cambridge University, UK Bo Li, University of Science & Technology, Hong Kong Prof. Jason Yi-Bing Lin, National Chiao Tung University, Taiwan Dr. Seng-Wai Loke, Monash University, Australia Dr. Jelena Misic, Hong Kong University of Science & Tech, Hong Kong Assoc. Prof. George Mohay, Queensland University of Tech, Australia Susan Pancho, Cambridge University, UK Prof. Yu-Chee Tseng, National Central University, Taiwan Dr. Arkady Zaslavsky, Monash University, Australia Dr. Jianying Zhou, Kent Ridge Digital Lab, Singapore From rem-conf Mon Jan 17 08:42:51 2000 From rem-conf-request@es.net Mon Jan 17 08:42:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AFAJ-00027R-00; Mon, 17 Jan 2000 08:38:03 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12AFAH-000273-00; Mon, 17 Jan 2000 08:38:02 -0800 Received: from p71.nas3.is3.u-net.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jan 2000 16:37:44 +0000 Message-ID: <002501bf6109$28b03620$47c566c3@tenaga> From: Farez To: rem-conf Subject: CFT: AMOC 2000 Date: Mon, 17 Jan 2000 16:35:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Tutorial Proposals FIRST ASIAN INTERNATIONAL MOBILE COMPUTING CONFERENCE (AMOC 2000) 1-3 November, 2000. Penang, Malaysia Tutorials: 31 October, 2000 http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc *** Proposal submission deadline: 1 March, 2000 *** The AMOC Programme Committee invites proposals for tutorials to be held on the 31st of October, 2000 in Penang, Malaysia. We invite proposals for three-hour tutorials on topics relating to the theory and/or practice of mobile and wireless computing and communications. The aim is to offer conference delegates both tutorials on up-to-date technologies, and case study tutorials on the application of the technologies to real-world problems. A list of suggested topics related to mobile/wireless computing/communications is given below as a guide; other topics will naturally be considered: o Quality of Service(QoS) o handover & location management o systems infrastructure o satellite technology o Internet access o power management o data services o lower layer protocols o rural wireless communications o data management o billing o security o e-commerce o agent technology o multimedia o hardware o Personal Communication Systems o terminal design & ergonomics Submission Procedures --------------------- All tutorial proposals should contain the following: - A brief description of the tutorial, suitable for inclusion in the conference registration brochure. - A detailed outline of the tutorial, including why the proposed topic is an important one and the content of the tutorial. - The necessary background and the potential target audience for the tutorial. - A description of why the tutorial topic is of interest to a substantial part of the AMOC audience. - A brief resumé of the presenter(s), which should include name, postal address, phone and fax numbers, email address if available, background in the tutorial area, references to any published work in the area and evidence of teaching experience, if any. This information may be included in the conference registration brochure. - Any audio-visual and room requirements. Tutorial proposals should be sent by email, in plain text format, to amoc-submission@fsktm.um.edu.my by 1 March, 2000. For more information, please visit http://www.fsktm.um.edu.my/amoc/ or email amoc-submission@fsktm.um.edu.my Important Dates --------------- Proposal submission deadline: 1 March, 2000 Notification of acceptance: 1 April, 2000 Tutorial abstract deadline: 1 May, 2000 Camera ready tutorial notes: 1 August, 2000 Additional Notes ---------------- Tutorial instructors will have their conference registration fees to AMOC waived. However, a maximum of two presenters' fees can be waived if there are two or more instructors. The AMOC organising committee reserves the right to cancel any tutorial if deadlines are missed or if the number of attendees is too low to support the costs related to organising and running the tutorial. From rem-conf Tue Jan 18 03:49:26 2000 From rem-conf-request@es.net Tue Jan 18 03:49:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AWv8-0002IL-00; Tue, 18 Jan 2000 03:35:34 -0800 Received: from agni.wipinfo.soft.net [164.164.6.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AWv2-0002I9-00; Tue, 18 Jan 2000 03:35:29 -0800 Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA04029 for ; Tue, 18 Jan 2000 17:03:59 +0500 (GMT) Received: from canine.wipinfo.soft.net (root@canine.wipinfo.soft.net [192.168.205.6]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA14564 for ; Tue, 18 Jan 2000 17:05:01 +0500 (GMT) Received: from canine.wipinfo.soft.net (rakeshj@canine.wipinfo.soft.net [192.168.205.6]) by canine.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA05833 for ; Tue, 18 Jan 2000 17:02:48 +0530 Date: Tue, 18 Jan 2000 17:02:48 +0530 (IST) From: rakesh jain To: rem-conf@es.net Subject: rtp time stamp in RTCP packet.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have one doubt about rtp time stamp value in RTCP SR packet. The units of the rtp time stamp field should be same in RTP and RTCP packets. In case of RTP packet, rtp time stamp depends on codec, It can start from random value, on first rtp packet, and incremented by number of samples in next rtp packets. I think it is cumulative. So in case of RTCP packet, we need to pass rtp time stamp value in sample period units. ( cumulative number of samples ) In case of each RTCP packet, we can calculate rtp time stamp value, using time difference between the sending time of the last RTCP packet and the sending time of the current RTCP packet, but after conversion from time units to sample period units, the value may not be perfect integer, can be float also, and we can send perfect integer value for rtp time stamp, so we need to do truncation. My question is, will this truncation effect seriously at receiver end in some calculations. If I am wrong or not clear please let me know. thanks in advance, rakesh jain From rem-conf Tue Jan 18 05:17:11 2000 From rem-conf-request@es.net Tue Jan 18 05:17:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AYR7-0004C2-00; Tue, 18 Jan 2000 05:12:41 -0800 Received: from cmlab.csie.ntu.edu.tw [140.112.29.131] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AYR0-0004Br-00; Tue, 18 Jan 2000 05:12:34 -0800 Received: from cmln4 (cmln4 [140.112.29.184]) by cmlab.csie.ntu.edu.tw (8.9.3+Sun/8.9.3) with SMTP id VAA01887; Tue, 18 Jan 2000 21:09:36 +0800 (CST) Message-ID: <000801bf61b5$524d5d80$b81d708c@cmln4> From: "CCFang" To: "rakesh jain" , References: Subject: Re: rtp time stamp in RTCP packet.... Date: Tue, 18 Jan 2000 21:09:28 +0800 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all... I think that the time stamp in RTCP packet should not be float. For example, in G.723, we send one RTP packet every 30 ms. The RTP time stamp will increase 240 every packet. It means that "we should increase 8 every ms". So, using the time difference between RTCP packets,or the time between RTP and RTCP, there is no xxx.xxx ms. I am new in this group, and my English is poor. *^_^* regards CCFang > Hi, > > I have one doubt about rtp time stamp value in RTCP SR packet. > The units of the rtp time stamp field should be same in RTP and > RTCP packets. In case of RTP packet, rtp time stamp depends on > codec, It can start from random value, on first rtp packet, and > incremented by number of samples in next rtp packets. I think > it is cumulative. > So in case of RTCP packet, we need to pass rtp time stamp value > in sample period units. ( cumulative number of samples ) > In case of each RTCP packet, we can calculate rtp time stamp > value, using time difference between the sending time of the last > RTCP packet and the sending time of the current RTCP packet, but > after conversion from time units to sample period units, the value > may not be perfect integer, can be float also, and we can send > perfect integer value for rtp time stamp, so we need to do > truncation. > My question is, will this truncation effect seriously at receiver > end in some calculations. If I am wrong or not clear please let > me know. > thanks in advance, From rem-conf Tue Jan 18 07:00:47 2000 From rem-conf-request@es.net Tue Jan 18 07:00:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Aa2K-0005tE-00; Tue, 18 Jan 2000 06:55:12 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Aa2I-0005t4-00; Tue, 18 Jan 2000 06:55:10 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhynr17189; Tue, 18 Jan 2000 14:54:30 GMT Message-ID: <388480A9.50636D98@dynamicsoft.com> Date: Tue, 18 Jan 2000 10:03:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rakesh jain CC: rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The RTP timestamp in sender report is used for correlating the real "wallclock" time with the RTP clock. It has nothing to do with the difference in transmission times of SR packets, nor with the sending time of the current RTCP packet. RFC1889 has the following to say about its construction: RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media- independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it is calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant. Thus, what you do is at some discrete sample time before the transmission of the RTCP SR (which therefore has an integral RTP timstamp value), you observe wallclock time. It is these two numbers that get placed in the RTP timestamp and NTP timestamp fields in the next SR. Note that this means the timestamp in the SR does *not* correspond to the RTP time when the SR is sent. -Jonathan R. rakesh jain wrote: > > > Hi, > > I have one doubt about rtp time stamp value in RTCP SR packet. > The units of the rtp time stamp field should be same in RTP and > RTCP packets. In case of RTP packet, rtp time stamp depends on > codec, It can start from random value, on first rtp packet, and > incremented by number of samples in next rtp packets. I think > it is cumulative. > So in case of RTCP packet, we need to pass rtp time stamp value > in sample period units. ( cumulative number of samples ) > In case of each RTCP packet, we can calculate rtp time stamp > value, using time difference between the sending time of the last > RTCP packet and the sending time of the current RTCP packet, but > after conversion from time units to sample period units, the value > may not be perfect integer, can be float also, and we can send > perfect integer value for rtp time stamp, so we need to do > truncation. > My question is, will this truncation effect seriously at receiver > end in some calculations. If I am wrong or not clear please let > me know. > thanks in advance, > > rakesh jain -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Jan 18 08:32:13 2000 From rem-conf-request@es.net Tue Jan 18 08:32:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AbTH-0007Gt-00; Tue, 18 Jan 2000 08:27:07 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AbTG-0007Gg-00; Tue, 18 Jan 2000 08:27:06 -0800 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id BAE254CE1D; Tue, 18 Jan 2000 11:26:59 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA02398; Tue, 18 Jan 2000 11:26:54 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA29242; Tue, 18 Jan 2000 08:26:54 -0800 (PST) Message-Id: <200001181626.IAA29242@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jdrosen@dynamicsoft.com Subject: Re: rtp time stamp in RTCP packet.... Cc: rakeshj@wipinfo.soft.net, rem-conf@es.net References: <388480A9.50636D98@dynamicsoft.com> Date: Tue, 18 Jan 2000 08:26:53 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Note that this means the timestamp in the SR does *not* >correspond to the RTP time when the SR is sent. I must be confused. The NTP timestamp is the time when the SR is sent: NTP timestamp: 64 bits Indicates the wallclock time ... when this report was sent ... and the RTP timestamp corresponds to the NTP timestamp: RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above) ... so how can the timestamp in the SR not correspond to the time when the SR is sent? Bill From rem-conf Tue Jan 18 08:53:53 2000 From rem-conf-request@es.net Tue Jan 18 08:53:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Abol-0000Lh-00; Tue, 18 Jan 2000 08:49:19 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Abok-0000LV-00; Tue, 18 Jan 2000 08:49:18 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhynz08987; Tue, 18 Jan 2000 16:48:32 GMT Message-ID: <38849B62.CA372ADB@dynamicsoft.com> Date: Tue, 18 Jan 2000 11:57:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: rakeshj@wipinfo.soft.net, rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill Fenner wrote: > > >Note that this means the timestamp in the SR does *not* > >correspond to the RTP time when the SR is sent. > > I must be confused. The NTP timestamp is the time when the SR is sent: > > NTP timestamp: 64 bits > Indicates the wallclock time ... when this report was sent ... > > and the RTP timestamp corresponds to the NTP timestamp: > > RTP timestamp: 32 bits > Corresponds to the same time as the NTP timestamp (above) ... > > so how can the timestamp in the SR not correspond to the time when > the SR is sent? The NTP timestamp doesn't need to be the exact time when its sent, it needs to be the time of the most recent RTP sample instant before it was sent. The timestamp in the SR is used for correlation purposes. It doesn't even need to be near the time of sending of the SR, in fact. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Jan 18 09:28:26 2000 From rem-conf-request@es.net Tue Jan 18 09:28:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AcMg-0001Wj-00; Tue, 18 Jan 2000 09:24:22 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AcMf-0001WP-00; Tue, 18 Jan 2000 09:24:21 -0800 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 028DC4CE23; Tue, 18 Jan 2000 12:24:20 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA04239; Tue, 18 Jan 2000 12:24:19 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA29905; Tue, 18 Jan 2000 09:24:19 -0800 (PST) Message-Id: <200001181724.JAA29905@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jdrosen@dynamicsoft.com Subject: Re: rtp time stamp in RTCP packet.... Cc: rem-conf@es.net References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> Date: Tue, 18 Jan 2000 09:24:19 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Not only am I confused, I'm also stubborn. >[The NTP timestamp] doesn't even need to be near the >time of sending of the SR, in fact. If this were the intent of the spec, I'd expect to see an additional correction factor in the section about calculating the RTT (the current algorithm assumes that the LSR echoed in the receiver's report is the transmission time of the SR.). Since LSR is expected to be the transmission time of the SR, and the description of the NTP timestamp field describes it as the transmission time of the SR, I can only conclude that the NTP timestamp field is meant to be the transmission time of the SR. Bill From rem-conf Tue Jan 18 10:51:40 2000 From rem-conf-request@es.net Tue Jan 18 10:51:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Addf-0003VQ-00; Tue, 18 Jan 2000 10:45:59 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Adde-0003VA-00; Tue, 18 Jan 2000 10:45:59 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhyoh15380; Tue, 18 Jan 2000 18:45:57 GMT Message-ID: <3884B6E6.76E311F2@dynamicsoft.com> Date: Tue, 18 Jan 2000 13:54:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> <200001181724.JAA29905@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill Fenner wrote: > > Not only am I confused, I'm also stubborn. > > >[The NTP timestamp] doesn't even need to be near the > >time of sending of the SR, in fact. > > If this were the intent of the spec, I'd expect to see an additional > correction factor in the section about calculating the RTT (the > current algorithm assumes that the LSR echoed in the receiver's > report is the transmission time of the SR.). Since LSR is expected > to be the transmission time of the SR, and the description of the > NTP timestamp field describes it as the transmission time of the SR, > I can only conclude that the NTP timestamp field is meant to be the > transmission time of the SR. I forgot about that; you're right, then, that it needs to be pretty much the send time. However, you'll still need to use the sample time of the last sample obtained before sending the packet, in order to get an integral number for the RTP timestamp. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Jan 18 11:18:10 2000 From rem-conf-request@es.net Tue Jan 18 11:18:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Ae4u-0004T8-00; Tue, 18 Jan 2000 11:14:08 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Ae4u-0004Sy-00; Tue, 18 Jan 2000 11:14:08 -0800 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 2C7E51E024; Tue, 18 Jan 2000 14:14:07 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA07360; Tue, 18 Jan 2000 14:14:06 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA00776; Tue, 18 Jan 2000 11:14:05 -0800 (PST) Message-Id: <200001181914.LAA00776@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jdrosen@dynamicsoft.com Subject: Re: rtp time stamp in RTCP packet.... Cc: rem-conf@es.net References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> <200001181724.JAA29905@windsor.research.att.com> <3884B6E6.76E311F2@dynamicsoft.com> Date: Tue, 18 Jan 2000 11:14:05 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >However, you'll still need to use the sample time of the >last sample obtained before sending the packet, in order to get an >integral number for the RTP timestamp. That's a little restrictive. Take a video codec with timestamps in units of 90kHz. If you're doing 60fps video, there are 1499 integral timestamp values in between each frame that could also be used as the RTP timestamp. Bill From rem-conf Tue Jan 18 11:47:34 2000 From rem-conf-request@es.net Tue Jan 18 11:47:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AeWp-0005fd-00; Tue, 18 Jan 2000 11:42:59 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AeWo-0005fN-00; Tue, 18 Jan 2000 11:42:58 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 014881E022; Tue, 18 Jan 2000 14:42:58 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA05046; Tue, 18 Jan 2000 14:42:56 -0500 (EST) Message-ID: <010501bf61eb$ab9a7ae0$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Bill Fenner" , Cc: References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> <200001181724.JAA29905@windsor.research.att.com> <3884B6E6.76E311F2@dynamicsoft.com> <200001181914.LAA00776@windsor.research.att.com> Subject: Re: rtp time stamp in RTCP packet.... Date: Tue, 18 Jan 2000 14:39:01 -0500 Organization: AT&T Labs - Research 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list And, I believe, among these 1499 values, the one that corresponds to the RTCP report send time as close as possible (not the sample time of the last sample) MUST be used as the RTP timestamp in that report... -Reha ----- Original Message ----- From: Bill Fenner > >However, you'll still need to use the sample time of the > >last sample obtained before sending the packet, in order to get an > >integral number for the RTP timestamp. > > That's a little restrictive. Take a video codec with timestamps in units > of 90kHz. If you're doing 60fps video, there are 1499 integral timestamp > values in between each frame that could also be used as the RTP timestamp. > > Bill From rem-conf Tue Jan 18 11:49:42 2000 From rem-conf-request@es.net Tue Jan 18 11:49:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Aea2-0005jZ-00; Tue, 18 Jan 2000 11:46:18 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Aea1-0005jK-00; Tue, 18 Jan 2000 11:46:17 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhyol28301; Tue, 18 Jan 2000 19:46:11 GMT Message-ID: <3884C503.FAEB6A54@dynamicsoft.com> Date: Tue, 18 Jan 2000 14:54:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> <200001181724.JAA29905@windsor.research.att.com> <3884B6E6.76E311F2@dynamicsoft.com> <200001181914.LAA00776@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Right again, Bill. I was thinking audio, where each sample = 1 tick. My (now minor) point is that you still need to pick an integer for this timestamp, so it may not be the actual send time, but rather the closest thing. -Jonathan R. Bill Fenner wrote: > > >However, you'll still need to use the sample time of the > >last sample obtained before sending the packet, in order to get an > >integral number for the RTP timestamp. > > That's a little restrictive. Take a video codec with timestamps in units > of 90kHz. If you're doing 60fps video, there are 1499 integral timestamp > values in between each frame that could also be used as the RTP timestamp. > > Bill -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Jan 18 11:59:41 2000 From rem-conf-request@es.net Tue Jan 18 11:59:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Aeiu-0006sv-00; Tue, 18 Jan 2000 11:55:28 -0800 Received: from alpha.xerox.com [13.1.64.93] by mail1.es.net with smtp (Exim 1.81 #2) id 12Aeit-0006rZ-00; Tue, 18 Jan 2000 11:55:27 -0800 Received: from blaze.parc.xerox.com ([13.1.102.57]) by alpha.xerox.com with SMTP id <68501(1)>; Tue, 18 Jan 2000 11:55:19 PST Received: from localhost (frederic@localhost) by blaze.parc.xerox.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA54865; Tue, 18 Jan 2000 11:55:17 -0800 (PST) Message-Id: <200001181955.LAA54865@blaze.parc.xerox.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Fenner cc: jdrosen@dynamicsoft.com, rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... In-reply-to: Your message of "Tue, 18 Jan 2000 11:18:33 PST." <200001181914.LAA00776@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Ron Frederick Date: Tue, 18 Jan 2000 11:55:19 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <200001181914.LAA00776@windsor.research.att.com> you write: > >> However, you'll still need to use the sample time of the >> last sample obtained before sending the packet, in order to get an >> integral number for the RTP timestamp. > > That's a little restrictive. Take a video codec with timestamps in units > of 90kHz. If you're doing 60fps video, there are 1499 integral timestamp > values in between each frame that could also be used as the RTP timestamp. > Actually, one of the reasons we chose the 90kHz clock for video was precisely so that you did have enough resolution to pick a sample time which is close enough to the actual report time to be reasonable. However, to avoid introducing errors in synchronization, you should do as others have said here and make sure the reported NTP time corresponds to an integral value of the RTP sample clock, picked to be as close as possible to the actual send time. -- Ron Frederick frederick@parc.xerox.com From rem-conf Tue Jan 18 12:20:52 2000 From rem-conf-request@es.net Tue Jan 18 12:20:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Af3c-0000IH-00; Tue, 18 Jan 2000 12:16:52 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Af3b-0000I7-00; Tue, 18 Jan 2000 12:16:51 -0800 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 7D3771E026; Tue, 18 Jan 2000 15:16:46 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA09708; Tue, 18 Jan 2000 15:16:45 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA01287; Tue, 18 Jan 2000 12:16:45 -0800 (PST) Message-Id: <200001182016.MAA01287@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: frederic@parc.xerox.com Subject: Re: rtp time stamp in RTCP packet.... Cc: rem-conf@es.net Date: Tue, 18 Jan 2000 12:16:45 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >However, to avoid introducing errors in synchronization, you should do >as others have said here and make sure the reported NTP time corresponds >to an integral value of the RTP sample clock, picked to be as close as >possible to the actual send time. Interestingly enough, the spec seems to disallow this -- the RTP timestamp "...MUST be calculated from the corresponding NTP timestamp...". If inter-media syncrhonization requires more resolution than RTT measurement (which seems likely in most applications), it makes sense to fudge the NTP time to exactly correspond to the RTP timestamp. Should the spec discuss this tradeoff? Bill From rem-conf Tue Jan 18 12:30:53 2000 From rem-conf-request@es.net Tue Jan 18 12:30:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AfDn-0000dp-00; Tue, 18 Jan 2000 12:27:23 -0800 Received: from alpha.xerox.com [13.1.64.93] by mail1.es.net with smtp (Exim 1.81 #2) id 12AfDm-0000de-00; Tue, 18 Jan 2000 12:27:22 -0800 Received: from blaze.parc.xerox.com ([13.1.102.57]) by alpha.xerox.com with SMTP id <68589(2)>; Tue, 18 Jan 2000 12:27:13 PST Received: from localhost (frederic@localhost) by blaze.parc.xerox.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA68875; Tue, 18 Jan 2000 12:27:10 -0800 (PST) Message-Id: <200001182027.MAA68875@blaze.parc.xerox.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Fenner cc: rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... In-reply-to: Your message of "Tue, 18 Jan 2000 12:16:53 PST." <200001182016.MAA01287@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Ron Frederick Date: Tue, 18 Jan 2000 12:27:11 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <200001182016.MAA01287@windsor.research.att.com> you write: > > >However, to avoid introducing errors in synchronization, you should do > >as others have said here and make sure the reported NTP time corresponds > >to an integral value of the RTP sample clock, picked to be as close as > >possible to the actual send time. > > Interestingly enough, the spec seems to disallow this -- the RTP timestamp > "...MUST be calculated from the corresponding NTP timestamp...". > > If inter-media syncrhonization requires more resolution than RTT > measurement (which seems likely in most applications), it makes sense > to fudge the NTP time to exactly correspond to the RTP timestamp. > Should the spec discuss this tradeoff? > Yes, I think this would be a good clarification to make... -- Ron Frederick frederick@parc.xerox.com From rem-conf Tue Jan 18 12:39:59 2000 From rem-conf-request@es.net Tue Jan 18 12:39:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AfLu-0001Fi-00; Tue, 18 Jan 2000 12:35:46 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AfLs-0001FY-00; Tue, 18 Jan 2000 12:35:45 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 099214CE1F; Tue, 18 Jan 2000 15:35:44 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA07533; Tue, 18 Jan 2000 15:35:42 -0500 (EST) Message-ID: <011901bf61f3$0a5c46b0$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Bill Fenner" , Cc: References: <200001182016.MAA01287@windsor.research.att.com> Subject: Re: rtp time stamp in RTCP packet.... Date: Tue, 18 Jan 2000 15:31:46 -0500 Organization: AT&T Labs - Research 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Or, you can wait until a suitable NTP time to send it. -Reha ----- Original Message ----- From: Bill Fenner To: Cc: Sent: Tuesday, January 18, 2000 3:16 PM Subject: Re: rtp time stamp in RTCP packet.... > > >However, to avoid introducing errors in synchronization, you should do > >as others have said here and make sure the reported NTP time corresponds > >to an integral value of the RTP sample clock, picked to be as close as > >possible to the actual send time. > > Interestingly enough, the spec seems to disallow this -- the RTP timestamp > "...MUST be calculated from the corresponding NTP timestamp...". > > If inter-media syncrhonization requires more resolution than RTT > measurement (which seems likely in most applications), it makes sense > to fudge the NTP time to exactly correspond to the RTP timestamp. > Should the spec discuss this tradeoff? > > Bill > > From rem-conf Tue Jan 18 20:36:03 2000 From rem-conf-request@es.net Tue Jan 18 20:36:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Amkb-0000qT-00; Tue, 18 Jan 2000 20:29:45 -0800 Received: from fsltl2.ltl.co.jp (LTL.co.jp) [210.162.81.20] by mail1.es.net with smtp (Exim 1.81 #2) id 12AmkZ-0000qJ-00; Tue, 18 Jan 2000 20:29:44 -0800 Received: from LocalHost ([209.164.106.1]) by fsltl2.ltl.co.jp; Wed, 19 Jan 2000 13:38:23 +0900 Subject: MS Project 98 OverStock Liquidation SALE!!! From: Content-Type: text/plain Date: Tue, 18 Jan 2000 22:29:48 MessageID: X-Accept-Language: en To: Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MS Project 98 OverStock Liquidation SALE!!! We bought in quantity so YOU could SAVE BIG! Microsoft Project 98 Full Version Retail Box The World's Leading Project Management Software Retails for as much as $469.95 Our Everyday Low Price is just $369.95 NOW ONLY $279.95!!! (Buy 5 or more and save even more!) But hurry, we have only 93 left in stock! To order, please call us at: 800-834-9043 To unsubscribe from our mailing list: mailto:invest4u@FreeMailForAll.com From rem-conf Tue Jan 18 20:36:05 2000 From rem-conf-request@es.net Tue Jan 18 20:36:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Ammq-0000r4-00; Tue, 18 Jan 2000 20:32:04 -0800 Received: from dns2.hostem.net [209.132.12.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Ammo-0000qs-00; Tue, 18 Jan 2000 20:32:03 -0800 Received: from LOCALHOST by dns2.hostem.net with SMTP (QuickMail Pro Server for Mac 2.0.1); 18-Jan-2000 20:29:59 -0800 To: From: MessageID: Date: Tue, 18 Jan 2000 22:30:56 X-In-Response-To: 0B0D4C12C Sensitivity: Restricted X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 MIME-Version: 1.0 X-Mailer: Microsoft Outlook Express 4.72.3110.7 Content-Type: text/plain Subject: Re:MS Project 98 OverStock Liquidation SALE!!! X-References: 023ADEB67, 0FB073907 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MS Project 98 OverStock Liquidation SALE!!! We bought in quantity so YOU could SAVE BIG! Microsoft Project 98 Full Version Retail Box The World's Leading Project Management Software Retails for as much as $469.95 Our Everyday Low Price is just $369.95 NOW ONLY $279.95!!! (Buy 5 or more and save even more!) But hurry, we have only 93 left in stock! To order, please call us at: 800-834-9043 To unsubscribe from our mailing list: mailto:invest4u@FreeMailForAll.com From rem-conf Tue Jan 18 22:02:06 2000 From rem-conf-request@es.net Tue Jan 18 22:02:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Ao3O-0002b4-00; Tue, 18 Jan 2000 21:53:14 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Ao3N-0002ZK-00; Tue, 18 Jan 2000 21:53:13 -0800 Received: from rtp-dial-1-68.cisco.com (rtp-dial-1-68.cisco.com [161.44.116.68]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA15233; Tue, 18 Jan 2000 21:49:28 -0800 (PST) Date: Tue, 18 Jan 2000 21:49:05 -0800 (Pacific Standard Time) From: Stephen Casner To: rakesh jain , Bill Fenner cc: rem-conf@es.net Subject: Re: rtp time stamp in RTCP packet.... In-Reply-To: <200001182016.MAA01287@windsor.research.att.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 On Tue, 18 Jan 2000, Bill Fenner wrote: > If inter-media syncrhonization requires more resolution than RTT > measurement (which seems likely in most applications), it makes sense > to fudge the NTP time to exactly correspond to the RTP timestamp. > Should the spec discuss this tradeoff? I claim not. First, I think the RTT measurement and the media sync require resolution of about the same magnitude. Furthermore, if the truncation involved in calculating an RTP timestamp from an NTP timestamp introduces too large an error for media sync, that is a bug in the design of the payload format. The RTP spec says: "The resolution of the [RTP timestamp] clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient)." On Tue, 18 Jan 2000, rakesh jain wrote: > In case of each RTCP packet, we can calculate rtp time stamp > value, using time difference between the sending time of the last > RTCP packet and the sending time of the current RTCP packet, but > after conversion from time units to sample period units, the value > may not be perfect integer, can be float also, and we can send > perfect integer value for rtp time stamp, so we need to do > truncation. The RTP spec says that you should calculate the RTP timestamp from the RTCP timestamp so that the correspond to the same time. That calculation can be done in floating point (double precision) or with multiple-precision integer arithmetic. In both cases, there will be a truncation to get the integer RTP timestamp. However, if you do this by accumulating differences between SR sending times as you are likely to have truncation errors that accumulate. Further, you won't account for drift between the sampling clock and the clock used for the NTP timestamps if these come from different oscillators (for example, a crystal on the audio board and a crystal on the motherboard from which the operating system clock is derived). The method I recommend is to periodically, at the time a sample buffer completes, establish a correspondence between the RTP timestamp that will correspond to the first sample in that buffer and the time that sample was taken according to the clock used for the NTP timestamps. That time is usually the current time minus the duration of the buffer and some allowance for interrupt or operating system latency. That correspondence is an offset in RTP timestamp units: offset = int(current_NTP_time * RTP_timestamp_clock_rate) - RTP_timestamp where current_NTP_time is in seconds and fraction. You don't need to do this calculation on every sample buffer, just often enough to accommodate the drift between the two oscillators. If they come from the same oscillator, you only need to do this once. Ideally, the capture interrupt routine would return a timestamp for the capture time from which you could form the NTP timestamp. Then, when it is time to send an RTCP SR packet, you get the current NTP time and calculate the RTP timestamp for the SR as: RTP_timestamp = int(current_NTP_time * RTP_timestamp_clock_rate) - offset Presto! I hope to produce an Internet-Draft on this topic (including synchronization). -- Steve From rem-conf Wed Jan 19 10:34:45 2000 From rem-conf-request@es.net Wed Jan 19 10:34:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12AziQ-0003Vz-00; Wed, 19 Jan 2000 10:20:22 -0800 Received: from helium.singnet.com.sg [165.21.101.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 12AziN-0003Vk-00; Wed, 19 Jan 2000 10:20:20 -0800 Received: from mail.nortrans.com.sg ([203.127.61.206]) by helium.singnet.com.sg (8.9.3/8.9.3) with SMTP id CAA01562; Thu, 20 Jan 2000 02:15:58 +0800 (SGT) From: U95qIiaWO@hyper.netchina.com.cn Received: from POP3 Client by mail.nortrans.com.sg (ccMail Link to SMTP R8.00.01) id AA948299638; Thu, 20 Jan 2000 02:16:26 +0800 Message-Id: <0001209482.AA948299638@mail.nortrans.com.sg> X-Mailer: ccMail Link to SMTP R8.00.01 Date: Wed, 19 Jan 2000 10:35:03 +0800 Subject: Read Only If Serious About Retiring in 2-3 Years.. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Look, we don't want to waste your time...or ours You must be determined to earn a bare minimum of $10,000 in the next 30 - 45 days and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 months. My mission is to help other people develop their life long dreams. And Part of what I'm looking for are those people who are committed to that BIG of a picture and are not afraid to work for it. We can help you: REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! NOT MLM or FRANCHISE Don't bother to call unless you are serious. Learn the Facts CALL 1-800-558-4158 (24 hrs) This is one of those "Fixed Cost" 800#s so feel free to call back if you don't get all of the exciting details. EASY $10,000 IN 30 - 45 DAYS ******************************************************************************** *** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:listcontrol@eastmail.com?subject=REMOVE PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction is not received. ******************************************************************************** ******** From rem-conf Wed Jan 19 18:33:33 2000 From rem-conf-request@es.net Wed Jan 19 18:33:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12B7IR-0001I5-00; Wed, 19 Jan 2000 18:26:03 -0800 Received: from ha1.rdc1.ov.nl.home.com (mail.rdc1.ov.nl.home.com) [212.120.66.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 12B7IP-0001Hv-00; Wed, 19 Jan 2000 18:26:02 -0800 Received: from cp11914a ([212.120.85.201]) by mail.rdc1.ov.nl.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <20000120022554.BASO10948.mail.rdc1.ov.nl.home.com@cp11914a> for ; Thu, 20 Jan 2000 03:25:54 +0100 Message-ID: <000801bf62ed$ee9b7580$c95578d4@dbsch1.nb.nl.home.com> From: "Peter Jansen" To: Subject: Date: Thu, 20 Jan 2000 03:27:43 +0100 Organization: @home MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF62F6.5025E1C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF62F6.5025E1C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello i want to know somebody's e-mail adress or icq number i only have = a ip number from this person is it possible to find it?????thank you for = your time i hope you answer me bey................... ------=_NextPart_000_0005_01BF62F6.5025E1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello i want to know somebody's e-mail = adress or=20 icq number i only have a ip number from this person is it possible to = find=20 it?????thank you for your time i hope you answer me=20 bey...................
------=_NextPart_000_0005_01BF62F6.5025E1C0-- From rem-conf Thu Jan 20 04:03:40 2000 From rem-conf-request@es.net Thu Jan 20 04:03:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BGCR-0006lp-00; Thu, 20 Jan 2000 03:56:27 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BGCP-0006lc-00; Thu, 20 Jan 2000 03:56:25 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24789; Thu, 20 Jan 2000 06:56:23 -0500 (EST) Message-Id: <200001201156.GAA24789@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-tones-06.txt,.ps Date: Thu, 20 Jan 2000 06:56:23 -0500 Sender: nsyracus@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 : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-06.txt,.ps Pages : 29 Date : 19-Jan-00 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-06.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-tones-06.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-tones-06.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: <20000119140337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140337.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jan 20 04:03:40 2000 From rem-conf-request@es.net Thu Jan 20 04:03:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BGCk-0006mL-00; Thu, 20 Jan 2000 03:56:46 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BGCj-0006mA-00; Thu, 20 Jan 2000 03:56:45 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24821; Thu, 20 Jan 2000 06:56:43 -0500 (EST) Message-Id: <200001201156.GAA24821@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-profile-new-08.txt,.ps Date: Thu, 20 Jan 2000 06:56:43 -0500 Sender: nsyracus@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 : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-profile-new-08.txt,.ps Pages : 37 Date : 19-Jan-00 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.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-profile-new-08.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-profile-new-08.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: <20000119140408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140408.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jan 20 04:03:40 2000 From rem-conf-request@es.net Thu Jan 20 04:03:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BGCt-0006mY-00; Thu, 20 Jan 2000 03:56:55 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BGCs-0006mN-00; Thu, 20 Jan 2000 03:56:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24837; Thu, 20 Jan 2000 06:56:52 -0500 (EST) Message-Id: <200001201156.GAA24837@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-rtp-new-06.txt,.ps Date: Thu, 20 Jan 2000 06:56:52 -0500 Sender: nsyracus@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 : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-06.txt,.ps Pages : 101 Date : 19-Jan-00 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-06.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-rtp-new-06.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-rtp-new-06.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: <20000119140419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140419.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jan 20 04:03:42 2000 From rem-conf-request@es.net Thu Jan 20 04:03:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BGCY-0006m1-00; Thu, 20 Jan 2000 03:56:34 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BGCX-0006lr-00; Thu, 20 Jan 2000 03:56:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24805; Thu, 20 Jan 2000 06:56:32 -0500 (EST) Message-Id: <200001201156.GAA24805@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-rtp-text-03.txt Date: Thu, 20 Jan 2000 06:56:31 -0500 Sender: nsyracus@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 : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-03.txt Pages : 8 Date : 19-Jan-00 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-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-rtp-text-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-rtp-text-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: <20000119140356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140356.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jan 20 13:10:08 2000 From rem-conf-request@es.net Thu Jan 20 13:10:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BOeG-000175-00; Thu, 20 Jan 2000 12:57:44 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BOeF-00016u-00; Thu, 20 Jan 2000 12:57:43 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.89.18.43]) id QQhyvz06993; Thu, 20 Jan 2000 20:49:11 GMT Message-ID: <388776D6.AAF14B04@dynamicsoft.com> Date: Thu, 20 Jan 2000 15:57:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mml+siplist@cslab.ericsson.se CC: sip@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: RTP packet size and use of ptime in SIP References: <14471.19542.334324.928871@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This rightly belongs on rem-conf, not on sip. mml+siplist@cslab.ericsson.se wrote: > > Hi, > > Questions in brief: > > 1. How much audio should there be in an RTP packet? Its flexible; there is a tradeoff between packet overheads (the more data, the less the overhead) and delay (the more data you put in the packet, the more delay before it can be sent). > > 2. Does anyone know of an implementation which changes > packet size mid stream (i.e. without another INVITE)? Actually, rfc1890 says receivers should be allowed to receive anywhere up to 200ms of data in a single packet: > constraints, a higher packetization delay may be appropriate. A > receiver should accept packets representing between 0 and 200 ms of > audio data. T > > 3. Does anyone know of an implementation which refuses > an INVITE with a ptime it doesn't like? Does this seem > like a reasonable thing to do? You don't need to do a re-INVITE to change packetization delays, actually. See the above. Why would you want to do this? > The AVP RFC says: 20ms is the "default packetisation interval", > but implementations should accept anything from 0 to 200ms. > > The intent seems to be "send any packet size you want, up > to 200ms. If you can't decide what packet size you'd > like to send, 20ms isn't a bad choice." (Right?) This is for sample based codecs. For frame based codecs, you should be prepared to receive any number of frames in a packet, up to the rounded up integer of 200 ms divided by the frame duration (so for g.723.1 is 7 frames). I don't think there is a recommendation of the default packetization interval. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Jan 20 14:27:37 2000 From rem-conf-request@es.net Thu Jan 20 14:27:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BPyF-0002wV-00; Thu, 20 Jan 2000 14:22:27 -0800 Received: from intergate.usr.com (mw.3com.com) [149.112.20.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BPyC-0002wL-00; Thu, 20 Jan 2000 14:22:26 -0800 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id QAA28799; Thu, 20 Jan 2000 16:22:09 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625686C.007AF31E ; Thu, 20 Jan 2000 16:22:56 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "James Kroll" To: rem-conf@es.net Message-ID: <8625686C.007AF137.00@mwgate02.mw.3com.com> Date: Thu, 20 Jan 2000 16:21:20 -0600 Subject: CN payload type 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 Hello: Can someone please clear up this confusion over the RTP CN payload type? In the most recent RTP profile document, both 13 and 19 are listed as reserved payload types. >From reading the intro, it sounds to me like the PT will ultimately be 13. Is this correct? Also, there is reference to a seperate draft which addresses CN frames. What is that draft called? Finally, what work is being done in the ITU related to this issue? Thanks for any help you can provide. James Kroll 3Com From rem-conf Thu Jan 20 17:15:16 2000 From rem-conf-request@es.net Thu Jan 20 17:15:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BSYD-0005XQ-00; Thu, 20 Jan 2000 17:07:45 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BSYC-0005Vq-00; Thu, 20 Jan 2000 17:07:44 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA14898; Thu, 20 Jan 2000 17:06:17 -0800 (PST) Date: Thu, 20 Jan 2000 17:08:57 -0800 (Pacific Standard Time) From: Stephen Casner To: James Kroll cc: rem-conf@es.net Subject: Re: CN payload type In-Reply-To: <8625686C.007AF137.00@mwgate02.mw.3com.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 On Thu, 20 Jan 2000, James Kroll wrote: > Can someone please clear up this confusion over the RTP CN payload type? > In the most recent RTP profile document, both 13 and 19 are listed as reserved > payload types. Here is an explanation from the minutes of the AVT meeting at IETF in November: The question of how to deal with proposed enhancements to the comfort noise payload format to include spectral shape parameters was raised. This work is ongoing in the ITU-T SG16, but will take time to complete - we don't want to wait for this, before we advance RTP. There are a number of options: - Leave the current comfort noise payload format as is, and define a new payload format for the extension - Enhance this format, so if it is longer than 1 byte it includes extra spectral information - Remove this payload format from the profile, so as not to hold the profile up, but leave the payload type assigned (with a note being added to the profile that payload type 13 is reserved for a comfort noise payload format which will be specified later). The chairs proposed taking this latter option, but this raised a number of questions about the status of the revised comfort noise draft (which is in use in a number of products) and the ability of the profile to reference it. After some discussion, a hybrid of these options was chosen: the comfort noise payload format will be extracted from the audio/video profile and submitted as a proposed standard RFC, referenced by the profile. Steve Casner will do this as part of editing the profile. The ITU-T will extend this, in the same manner as any other payload format is extended, with the expectation that it will cycle at proposed standard. > From reading the intro, it sounds to me like the PT will ultimately be 13. Is > this correct? Yes. If you have already implemented CN as it was specified in previous profile drafts, you can continue to use that CN paylod format with static payload type 13. > Also, there is reference to a seperate draft which addresses CN > frames. What is that draft called? I have done the extraction from the profile document, as you have observed, but I have not yet reconstituted that extracted part into the separate draft. That will be done ASAP, and will be the same as what was previously in the profile document. > Finally, what work is being done in the ITU related to this issue? The current spec is just a noise energy level. The additional work is to add spectral information, as noted in the minutes above. It will either be done in a backward-compatible way or as a second comfort noise payload format. -- Steve From rem-conf Thu Jan 20 17:28:20 2000 From rem-conf-request@es.net Thu Jan 20 17:28:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12BSnb-000662-00; Thu, 20 Jan 2000 17:23:39 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 12BSna-00064o-00; Thu, 20 Jan 2000 17:23:38 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA15268; Thu, 20 Jan 2000 17:22:10 -0800 (PST) Date: Thu, 20 Jan 2000 17:24:50 -0800 (Pacific Standard Time) From: Stephen Casner To: Jonathan Rosenberg cc: mml+siplist@cslab.ericsson.se, rem-conf@es.net Subject: Re: RTP packet size and use of ptime in SIP In-Reply-To: <388776D6.AAF14B04@dynamicsoft.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 On Thu, 20 Jan 2000, Jonathan Rosenberg wrote: > Actually, rfc1890 says receivers should be allowed to receive anywhere > up to 200ms of data in a single packet: More than "allowed", a receiver should be "prepared". > I don't think there is a recommendation of the default > packetization interval. There is in the last column of Table 1. But really this is only a suggestion. -- Steve From rem-conf Fri Jan 21 08:22:02 2000 From rem-conf-request@es.net Fri Jan 21 08:22:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Bgeq-0001Od-00; Fri, 21 Jan 2000 08:11:32 -0800 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Bgep-0001OT-00; Fri, 21 Jan 2000 08:11:31 -0800 Received: from super.du.uab.ericsson.se (root@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA07765 for ; Fri, 21 Jan 2000 17:11:28 +0100 (MET) Received: from martell.du.uab.ericsson.se (mml@martell [134.138.176.69]) by super.du.uab.ericsson.se (8.10.0.Beta11/8.10.0.Beta11/erix-1.7) with ESMTP id e0LGBND05812 for ; Fri, 21 Jan 2000 17:11:23 +0100 (MET) Received: by martell.du.uab.ericsson.se (8.9.1/client-1.7) id RAA04986; Fri, 21 Jan 2000 17:11:23 +0100 (MET) Message-ID: <14472.34091.209861.562272@gargle.gargle.HOWL> Date: Fri, 21 Jan 2000 17:11:23 +0100 (MET) From: mml+remconf@cslab.ericsson.se To: rem-conf@es.net Subject: Re: RTP packet size and use of ptime in SIP In-Reply-To: References: <388776D6.AAF14B04@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan> Actually, rfc1890 says receivers should be allowed to Jonathan> receive anywhere up to 200ms of data in a single packet: Stephen Casner writes: > More than "allowed", a receiver should be "prepared". What do receivers do to predict and limit resource consumption for incoming RTP, especially for sample-based codecs? If I accept an incoming 8kHz mulaw call, I seem to have no way of knowing whether that means I'll be getting 10 packets/s or 100 packets/s or, sanity aside, 1000 packets/s. 10 and 100 are both reasonable, but there's a huge difference in resource use, which gets interesting in a gateway. Matt (Aside: it's interesting that RFC 1890 put in the 200ms limit to keep buffer sizes bounded, but didn't put in anything to help keep other resource consumption, such as CPU, bounded.) From rem-conf Fri Jan 21 11:59:35 2000 From rem-conf-request@es.net Fri Jan 21 11:59:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Bk6D-000542-00; Fri, 21 Jan 2000 11:52:01 -0800 Received: from mailserv2.iuinc.com [206.245.164.55] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 12Bk6B-00053q-00; Fri, 21 Jan 2000 11:51:59 -0800 Received: (qmail 31110 invoked from network); 21 Jan 2000 19:51:58 -0000 Received: from unknown (HELO raymond) (216.181.56.35) by mailserv2.iuinc.com with SMTP; 21 Jan 2000 19:51:58 -0000 From: "Doug Sauder" To: , Subject: RE: RTP packet size and use of ptime in SIP Date: Fri, 21 Jan 2000 14:55:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <14472.34091.209861.562272@gargle.gargle.HOWL> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > What do receivers do to predict and limit resource consumption for > incoming RTP, especially for sample-based codecs? I think the answer is this: you make reasonable assumptions, complete = your implementation, then test for interoperability. If problems arise, = you make the changes and test again. > If I accept an incoming 8kHz mulaw call, I seem to have no way of > knowing whether that means I'll be getting 10 packets/s or 100 > packets/s or, sanity aside, 1000 packets/s. 10 and 100 are both > reasonable, but there's a huge difference in resource use, which gets > interesting in a gateway. We are fortunate, in that we will probably have to interoperate with = fewer than a dozen vendors products in a very controlled environment. = In a situation where the environment isn't so controlled, it's probably = not so easy. Nevertheless, being able to interoperate with the most = popular products probably gets you 99% interoperability. I think it's okay to make certain reasonable assumptions about what you = receive: it doesn't mean blatant disregard for the standards. We will = follow the standards very closely with regard to what we send. RTP = covers a lot of different application areas, but most implementations = are focused on only one area. In our case, we are focused on IP = telephony, and some features of the standard that make sense in the case = of an MBONE multicast often make no sense for us. >=20 > Matt >=20 > (Aside: it's interesting that RFC 1890 put in the 200ms limit to keep > buffer sizes bounded, but didn't put in anything to help keep other > resource consumption, such as CPU, bounded.) As an example of a reasonable assumption, with mu law encoding, a 200ms = packet size would be > 1600 bytes, which is more than the MTU on an = Ethernet. While 200ms might make sense with GSM or some low bandwidth = encoding, it makes no sense for mu law, where the packet would be = fragmented. -- Doug Sauder Software engineer Broadsoft, Inc. From rem-conf Sun Jan 23 06:26:17 2000 From rem-conf-request@es.net Sun Jan 23 06:26:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12CNgA-0005RR-00; Sun, 23 Jan 2000 06:07:46 -0800 Received: from ns.ohe.co.jp (ohe.co.jp) [210.161.76.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 12CNg9-0005RH-00; Sun, 23 Jan 2000 06:07:45 -0800 Received: from LocalHost ([209.82.3.2]) by ohe.co.jp (8.8.8+Sun/3.5Wbeta-881807283) with SMTP id XAA27007; Sun, 23 Jan 2000 23:03:56 +0900 (JST) From: great19@0ver-40.com Message-Id: <200001231403.XAA27007@ohe.co.jp> X-Mailer: Internet Mail Service [28.3.3274.54] (Solaris; I) Date: Sun, 23 Jan 2000 08:59:13 X-Accept-Language: en To: Subject: HP, Epson and Canon Ink Jet Cartridges (nmd847e) X-Other-References: 0C7314A85 X-In-Response-To: 0DA9C10A2 X-See-Also: 062C0E334 MessageID: <4toi8m3vc0f7c8q.230120000859@LocalHost> Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We carry inkjet cartridges for Epson, Canon and HP and have the following specials. One year warranty with all purchases. For more information mailto:inkjetpower@mibarrio.com, see below for removal. Epson 400/500/600 Black cartridge (S020093) $7.95 Epson 400/600/800/1520 Color cartridge (S020089) $9.95 Epson 200/500 Color cartridge (S020097) $8.50 Epson 440/640 Black cartridge (S020187) $8.50 Epson 440/640 Black cartridge (S020189) $9.50 Epson 440/640/740 Color cartridge (S020191) $11.50 Epson 700 Color cartridge (S020110) $13.95 Epson 750 Color cartridge (S020193) $14.95 Epson 900 Black cartridge (T003011) $14.95 Epson 900 Color cartridge (T005011) $17.95 For more information mailto:inkjetpower@mibarrio.com, see below for removal. Canon 4000/4100/4200 BC-21 Black cartridge $5.25 Canon 4000/4100/4200 BC-21 Color cartridge $7.95 Canon 600/610/620 BCMY Cartridge set $10.50 For more information mailto:inkjetpower@mibarrio.com, see below for removal. HP 51626A Recycled cartridge $16.95 HP 51645A Recycled cartridge $16.95 HP 51629A Recycled cartridge $16.95 For more information mailto:inkjetpower@mibarrio.com, see below for removal. Shipping is $3.50 for unlimited quantities. All packages are sent vis USPS third day. *All Epson and Canon cartridges are new compatibles. For more information mailto:inkjetpower@mibarrio.com, see below for removal. +++++++++++++++++++++++++++++++++++++++++++++++++++ For Removal Please reply with Remove in the subject or call toll free 877-202-0942 and you will be permanently removed from future mailings. +++++++++++++++++++++++++++++++++++++++++++++++++++ From rem-conf Mon Jan 24 03:43:04 2000 From rem-conf-request@es.net Mon Jan 24 03:43:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ChmF-0002dP-00; Mon, 24 Jan 2000 03:35:23 -0800 Received: from soleil.uvsq.fr [193.51.24.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12ChmC-0002bW-00; Mon, 24 Jan 2000 03:35:20 -0800 Received: from lucifer.prism.uvsq.fr (lucifer.prism.uvsq.fr [193.51.25.7]) by soleil.uvsq.fr (8.9.3/jtpda-5.3.3) with ESMTP id MAA09657 ; Mon, 24 Jan 2000 12:26:13 +0100 (CET) Received: from pujolle.com (kleber.prism.uvsq.fr [193.51.25.168]) by lucifer.prism.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id MAA02685 ; Mon, 24 Jan 2000 12:09:55 +0100 (MET) Message-ID: <388C3340.9EC3908D@pujolle.com> Date: Mon, 24 Jan 2000 12:10:56 +0100 From: Guy Pujolle Reply-To: Guy.Pujolle@prism.uvsq.fr X-Mailer: Mozilla 4.5 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Guy.Pujolle@prism.uvsq.fr Subject: Infocom 2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This Call for participation has been sent to several distribution lists. We apologize if you receive multiple copies of it _______________________________________________________ CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (LAST DAY!) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From rem-conf Mon Jan 24 07:59:25 2000 From rem-conf-request@es.net Mon Jan 24 07:59:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ClgW-0005Wz-00; Mon, 24 Jan 2000 07:45:44 -0800 Received: from osiris.lip6.fr [132.227.60.30] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12ClgR-0005Wc-00; Mon, 24 Jan 2000 07:45:39 -0800 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id QAA09566 for ; Mon, 24 Jan 2000 16:45:14 +0100 Received: from matisse (matisse.lip6.fr [132.227.61.26]) by rp.lip6.fr (8.8.8/jtpda-5.2) with SMTP id PAA16351 for ; Mon, 24 Jan 2000 15:50:15 +0100 (MET) Date: Mon, 24 Jan 2000 15:50:15 +0100 (MET) From: eric.horlait@lip6.fr Message-Id: <200001241450.PAA16351@rp.lip6.fr> MIME-Version: 1.0 X-Mailer: Smartcode ObjectSet 1.0 Sender: eric.horlait@lip6.fr Subject: MATA 2000 - CALL FOR PAPER To: rem-conf@es.net Content-Type: multipart/mixed; boundary="=PMail:=_1147@@6ic3RLsiZDg6w3M0NhTa" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=PMail:=_1147@@6ic3RLsiZDg6w3M0NhTa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable +------------------------------------------------------------= --+=0D=0A| This e-mail has been sent to several distribution list= s. We | =0D=0A| apologize if you receive multiple copies of= it. |=0D=0A+--------------------------------------------= ------------------+=0D=0A=0D=0A=09=09=09 CALL FOR PAPER=0D=0A=0D=0A=09=09=09 MATA -= 2000=0D=0A=0D=0A=09 Second International Workshop on Mobile Agents fo= r=0D=0A Telecommunication Applications=0D=0A=09=09Septem= ber 18-20, 2000, Paris, FRANCE=0D=0A=0D=0A=09=09 http://netconf.lip6.= fr/mata00=0D=0A=0D=0A=0D=0AThe aim of the workshop is to provide a unique= opportunity for =0D=0Aresearchers, software and application deve= lopers, and computer =0D=0Anetwork technologists to discuss new d= evelopments on the mobile =0D=0Aagent technology and applications= . After last year's very =0D=0Asuccessful workshop in Ottawa, Can= ada (110 attendees), this year's =0D=0Aworkshop will focus on mob= ile agent issues across the areas of =0D=0Anetwork management, mo= bile applications, Nomadic computing, =0D=0AE-commerce, ad-hoc ne= tworks and applications, feature interactions, =0D=0AInternet app= lications, QoS management, policy-based management, =0D=0Ainterac= tive multimedia, and Computer Telephony Integration.=0D=0A=0D=0AThank= you for reading!=0D=0AMay I ask you to distribute this CFP aroun= d you!=0D=0A --=PMail:=_1147@@6ic3RLsiZDg6w3M0NhTa-- From rem-conf Mon Jan 24 11:05:59 2000 From rem-conf-request@es.net Mon Jan 24 11:05:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Cof3-0000o8-00; Mon, 24 Jan 2000 10:56:25 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Coew-0000nt-00; Mon, 24 Jan 2000 10:56:23 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18963; Mon, 24 Jan 2000 13:56:10 -0500 (EST) Message-Id: <200001241856.NAA18963@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP Payload for Text Conversation to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jan 2000 13:56:10 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload for Text Conversation as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-03.txt From rem-conf Mon Jan 24 13:30:14 2000 From rem-conf-request@es.net Mon Jan 24 13:30:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12CqwQ-00037d-00; Mon, 24 Jan 2000 13:22:30 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12CqwO-00037S-00; Mon, 24 Jan 2000 13:22:28 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25270; Mon, 24 Jan 2000 16:22:22 -0500 (EST) Message-Id: <200001242122.QAA25270@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jan 2000 16:22:22 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-06.txt From rem-conf Mon Jan 24 22:01:08 2000 From rem-conf-request@es.net Mon Jan 24 22:01:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Cyvs-0007cY-00; Mon, 24 Jan 2000 21:54:28 -0800 Received: from ns.mii.co.jp (mail.mii.co.jp) [210.160.77.82] by mail1.es.net with smtp (Exim 1.81 #2) id 12Cyvp-0007c5-00; Mon, 24 Jan 2000 21:54:26 -0800 Received: from LocalHost [216.205.45.254] by mail.mii.co.jp (SMTPD32-4.05) id AA0C5D6014A; Tue, 25 Jan 2000 14:56:12 JST From: Subject: Stock Pick Of The Week & Win $5,000 (mewoj9) Content-Type: text/plain X-Accept-Language: en To: Date: Tue, 25 Jan 2000 00:48:13 MessageID: <4b2niihphtba3qi.250120000048@LocalHost> Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >======================================> January 25, 2000 =>=>=> SERIOUS INVESTORS CHECK THIS OUT! This newsletter is considered by many to be an industry leader Hundreds of hours of research go into finding growth companies that offer serious growth potential. +++++++++++++++++++++++++++++++++++++++ To sign up for your chance to WIN $5000 and receive a free trial subscription to our Investment Newsletters, please send a blank e-mail to mailto:stock10@mibarrio.com +++++++++++++++++++++++++++++++++++++++ Well stock fans, it doesn't get any better than what we are witnessing right now in this sizzling stock market. Recently an exciting merger took place. 9278 Distributors, Inc. and iLink Telecom, Inc merged. The new company will be called 9278 Communications, Inc (OTC BB: NTSE) iLink Telecom, Inc., is an integrator of telecom technologies, specializing in the development, management and maintenance of billing platforms for the pre-paid phone card market. 9278 Distributors, Inc. of New York is a pre-paid phone card distributor with annual sales for 1999 of $77 million. The merger allows 9278 Communications, Inc. to fully utilize its technical expertise in the operation and expansion of its telecom switching network, in cooperation with the mature distribution network established by 9278. The vertical integration of these two corporations allows for a projected margin enhancement of 8% on the existing telecom traffic currently re-sold by 9278. +>+>+>+>+>+>+>+>+>+>+>+>+>+>+> Symbol = OTC BB: NTSE Estimated Float = 3,800,000 Issued Shares = 19,659,629 Current Price = $3.31 per share +>+>+>+>+>+>+>+>+>+>+>+>+>+>+> =>=>=> INVESTMENT HIGHLIGHTS i. 9278 is a pre-paid phone card distributor primarily serving New York, New Jersey and Connecticut ii. There are presently 109 different pre-paid phone card products, distributed through a network of over 300 independent distributors iii. From fiscal 1998 to 1999, gross revenues have increased by 300% iv. In 1998 gross revenues were $21,681,559 with a net profit of $88,609, to 1999 where the gross revenues for the nine month period ended September 30th were $48,953,478 with a net profit of $736,119. v. Fiscal 1999 gross revenues were $77,000,000 dollars. vi. 9278 focuses its primary marketing efforts on the various ethnic markets in NY, NJ & CT, who utilize the pre-paid card products as a cost effective alternative to the incumbent carrier rates. vii. The telecom traffic currently produced by 9278 is 350,000,000 minutes per year and growing by a factor of 5% per month =>=>=> Conclusion The merged entity presently provides generated gross revenues in excess of $77 million for fiscal 1999 and has secured additional acquisition targets allowing the company to forecast fiscal 2000 revenues to exceed $150 million. This new combined company is in a growing market and they are profitable which is unheard of with todays Internet companies loosing millions each day! We rate this company a buy and we could possible see the stock price double this year. +++++++++++++++++++++++++++++++++++++++ To sign up for your chance to WIN $5000 and receive a free trial subscription to our Investment Newsletters, please send a blank e-mail to mailto:stock10@mibarrio.com +++++++++++++++++++++++++++++++++++++++ =>=>=> DISCLAIMER: All bulletins published by The Stock Pick Of The Month are paid advertisements by the Company and/or another party and has been sent to you for no charge. This is a service provided by The Stock Pick Of The Month to public companies so they can disseminate recent significant developments, which potentially can affect their share price. This is not an offer to buy and sell any security, which can only be made through a registered representative. The information contained herein is based upon sources that we consider reliable but is not guaranteed by The Stock Pick Of The Month. The Stock Pick Of The Month makes no warrantee as to the accuracy or completeness of the above information. Certain of the statements contained in our news releases are Forward-looking statements. While these statements reflect the Corporation's current beliefs, they are subject to uncertainties and risks that could cause actual results to differ materially. These factors include, but are not limited to, the demand for the Corporations products and services, economic and competitive conditions. The Stock Pick Of The Month may act as a consultant to the companies reviewed in this publication and may receive compensation in cash or stock for promotional or public relations services, including website development. The compensation received by The Stock Pick Of The Month from the companies reported upon should be viewed by readers as a potential conflict of interest. Furthermore, investing in Micro-cap or Small-cap securities is highly speculative and carries a high degree of risk. The stocks of these companies profiled by The Stock Pick Of The Month may experience huge gains in a short time frame upon dissemination of this report. Consult a professional broker for advice on trading and investing. The Stock Pick Of The Month may buy or sell the featured stocks at anytime. The Stock Pick Of The Month has been paid $1500 for their profile of 9278 Communications, Inc (OTC BB: NTSE) >======================================> +++++++++++++++++++++++++++++++++++++++++++++++++++ For Removal Please reply with Remove in the subject or call toll free 877-202-0942 and you will be permanently removed from future mailings. +++++++++++++++++++++++++++++++++++++++++++++++++++ From rem-conf Mon Jan 24 23:43:38 2000 From rem-conf-request@es.net Mon Jan 24 23:43:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12D0Z6-00019h-00; Mon, 24 Jan 2000 23:39:04 -0800 Received: from frodo.gezernet.co.il (mail.gezernet.co.il) [192.115.6.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 12D0Z3-00019X-00; Mon, 24 Jan 2000 23:39:01 -0800 Received: from 208.15.107.202 (dial02.futurelinc.com [208.15.107.202]) by mail.gezernet.co.il (8.9.3/8.8.7) with SMTP id DAA17984; Thu, 27 Jan 2000 03:29:24 +0200 From: clip3@aol.com Message-Id: <200001270129.DAA17984@mail.gezernet.co.il> To: clop2@aol.com Subject: FREE! Investors...The #1 Equestrian Newsletter! Date: Tue, 25 Jan 00 02:01:09 Eastern Standard Time Reply-To: clip3@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; clipclop.com (OTCBB: CLOPF) Progress Report

clipclop.com (OTCBB: CLOPF) Vancouver BC. January 20, 2000

clipclop.com, The Ultimate Source of Equine Information, addresses the $25.3
billion annual US equine market.

The Company has now completed the move of the clipclop.com web site from an
external ISP to its own in house system and has installed sufficient hardware
to not only offer much faster access times but also to offer web hosting
services to other equine web sites, a necessary move towards achieving the
aim of making clipclop.com THE horse industry web portal

The email hosting service is now in final testing and expected to be fully
functional within ten days. This type of free service is viewed as an
important "return visitor" traffic builder.

The "Ask the Vet" forum has proved so popular that it has been necessary to
double the team and two more prominent equine veterinarians have joined the
group.

Kim Marie Wood, popular author of "Young Rider Roundup" has agreed to join
clipclop.com's editorial team and her contributions will be published on a
new youth page twice a month thus increasing the amount of "real estate"
available on which to sell advertising.

In December clipclop.com completed a $615,000 private placement, providing
sufficient cash for the company to achieve its immediate development goals.

The advertising program is underway and generating encouraging traffic to the
site. You can now hear about clipclop.com weekly on The Horse Show with Rick
Lamb which is broadcast in 33 states on 65 radio stations. A 60,000 piece
test mailing to the companies listed on the horse business data base has been
completed and has received very positive feed back. During the three week
period immediately following an average of 4500 visitors, and 100 new
businesses per day logged on the site. Web site promotion ads in Western
Horseman, Pacific and Prairie Horse Journal and Dressage Today are scheduled
for distribution within the next two weeks and are expected to generate
significant new traffic.

e-commerce developments are proceeding at a satisfactory pace and the
deployment of the clipclop.com Online Auction, similar to that at Amazon.com
(AMZN : NASDAQ), is imminent and aimed at making clipclop.com the Ebay (EBAY
: NASDAQ) of the horse world.



Disclaimer: The publishers of this newsletter provide information
only. This is not a solicitation or offer to buy or sell any
security. The publishers are not stock brokers or financial
advisors, although it is strongly recommended that you seek the
services of a professional before investing in any profiled stock. We
will not be responsible for any losses, damages, monetary or
otherwise that may result due to any content provided. Past
performance is not indicative of future performance, investors can
and do loose money.
 From rem-conf Tue Jan 25 13:30:21 2000 From rem-conf-request@es.net Tue Jan 25 13:30:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DDAX-0000C1-00; Tue, 25 Jan 2000 13:06:33 -0800 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DDAW-0000Bk-00; Tue, 25 Jan 2000 13:06:32 -0800 Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA23468 for ; Tue, 25 Jan 2000 13:06:32 -0800 (PST) Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA25374; Tue, 25 Jan 2000 13:06:31 -0800 (PST) Message-Id: <200001252106.NAA25374@rum.isi.edu> To: rem-conf@es.net Date: Mon, 24 Jan 2000 16:37:03 -0800 From: Joe Touch Reply-To: sigcomm2000-info@acm.org Organization: Sigcomm 2000 Subject: Sigcomm 2000 CFP - reminder X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Stockholm, Sweden Reminder - the SIGCOMM Call for Papers deadline for submission is _this Friday_, January 28, 2000. For information on how to submit, see: http://www.acm.org/sigcomm/sigcomm2000 From rem-conf Wed Jan 26 02:39:54 2000 From rem-conf-request@es.net Wed Jan 26 02:39:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DPjs-0006Zw-00; Wed, 26 Jan 2000 02:31:52 -0800 Received: from smtp2.cluster.oleane.net [195.25.12.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DPjq-0006Zm-00; Wed, 26 Jan 2000 02:31:50 -0800 Received: from oleane (dyn-1-1-250.Vin.dialup.oleane.fr [195.25.4.250]) by smtp2.cluster.oleane.net with SMTP id LAA41950; Wed, 26 Jan 2000 11:31:40 +0100 (CET) Message-ID: <008601bf67e8$1fef18e0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 Call for Paper Date: Wed, 26 Jan 2000 11:28:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01BF67F0.7F6990E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0083_01BF67F0.7F6990E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: Beyond H.323? A scientific committe composed of the most = eminent experts in this technology will review the abstracts submitted = >from the Call For Papers: http://www.upperside.fr/basip.htm Take a look at the exhibition list. ------=_NextPart_000_0083_01BF67F0.7F6990E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SIP 2000: Beyond H.323? A scientific = committe=20 composed of the most eminent experts in this technology will review the=20 abstracts submitted from the Call For Papers:
http://www.upperside.fr/basip.= htm
Take a look at the exhibition=20 list.
------=_NextPart_000_0083_01BF67F0.7F6990E0-- From rem-conf Wed Jan 26 14:52:30 2000 From rem-conf-request@es.net Wed Jan 26 14:52:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Damq-000428-00; Wed, 26 Jan 2000 14:19:40 -0800 Received: from mail1.radix.net [207.192.128.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Damo-00041x-00; Wed, 26 Jan 2000 14:19:38 -0800 Received: from TheOTG.com (ip30.ascend1.du.radix.net [207.192.138.30]) by mail1.radix.net (8.9.3/8.9.3) with ESMTP id RAA06850; Wed, 26 Jan 2000 17:06:40 -0500 (EST) Message-ID: <388F70CA.F3543C90@TheOTG.com> Date: Wed, 26 Jan 2000 17:10:18 -0500 From: "John Weiler, OBJECTive Technology Group" Organization: Interoperability Clearinghouse, 703-768-0400 X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: info@ichnet.org Subject: World's Largest IT Organization Embraces Interoperability Clearinghouse Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.radix.net id RAA06850 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This announcement has been sent to several distribution lists. We apologize if you receive multiple copies of it. Dear Colleague, The Interoperability. Clearinghouse (ICH) is pleased to announce that it has received a formal endorsement from the world=92s largest and most influential IT consumer; The Office of the Secretary of Defense, Dept. of the CIO. Following a comprehensive validation effort, the OSD has issued a formal letter of sponsorship and endorsement of the ICH, which may be viewed at www.ICHnet.org. If your organization would like to leverage these architecture validation services, or seek additional information, (including the OSD report), please contact Skip McCormick, TD, ICH, 703-768-4975, or email him at skip@ICHnet.org Warm Regards, john -- http://www.E-interop.com (Interoperability Clearinghouse link) http://www.gcn.com/vol18_no24/enterprise/313-1.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://206.144.247.65/archives/gcn/1999/February8/1c.htm http://206.144.247.65/archives/gcn/1999/March29/16.htm http://www.healthcare-informatics.com/issues/1999/05_99/standards.htm http://www.omg.org/techprocess/meetings/ic.html ********************************************* John Weiler john@ICHnet.org Interoperability Clearinghouse "From Architectures to Reality" 703-768-0400(v) 703-765-9295(f) http://www.ICHnet.org "Nothing is more difficult than to introduce a new order. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new" - Nicolai Machiavelli, 1513 A.D. ********************************************* From rem-conf Wed Jan 26 18:49:54 2000 From rem-conf-request@es.net Wed Jan 26 18:49:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Desn-0006N5-00; Wed, 26 Jan 2000 18:42:05 -0800 Received: from mailhost.ttimail.com [209.136.128.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Desl-0006Mv-00; Wed, 26 Jan 2000 18:42:03 -0800 Received: by MAILHOST with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 20:44:02 -0600 Message-ID: From: Qishen Tang To: rem-conf@es.net Subject: RTP Jitter question... Date: Wed, 26 Jan 2000 20:44:01 -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 Hi, # Is there an industry guideline/threshold as to what RTP Jitter value should be??? Thanks, From rem-conf Wed Jan 26 20:02:27 2000 From rem-conf-request@es.net Wed Jan 26 20:02:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Dg14-0007X9-00; Wed, 26 Jan 2000 19:54:42 -0800 Received: from (m3.florida.net) [212.179.39.140] by mail1.es.net with smtp (Exim 1.81 #2) id 12Dg11-0007Wb-00; Wed, 26 Jan 2000 19:54:42 -0800 Received: (qmail 870 invoked by uid 507); 24 Jan 2000 22:24:33 -0000 Date: 24 Jan 2000 22:24:33 -0000 Message-ID: <20000124222433.866.qmail@m3.florida.net> Cc: recipient list not shown: ; From: jrrathborn Subject: hello To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CONTROL YOUR FUTURE You have control of your future when you have a Diploma or Advanced Degree from a prestigious University. Diplomas and Advanced Degrees mean success, wealth, and meaningful relationships. You can earn a non-accredited Diploma or Advanced Degree for your present knowledge and life experience without classes. Bachelors, Masters, MBA, and Doctorates (PhD) granted in the field of your choice. Open enrollment - All accepted regardless of background. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-602-294-9402 Call 24 hours a day, 7 days a week, including Sundays and holidays. . From rem-conf Thu Jan 27 07:16:49 2000 From rem-conf-request@es.net Thu Jan 27 07:16:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DqVo-00005V-00; Thu, 27 Jan 2000 07:07:08 -0800 Received: from utrhcs.cs.utwente.nl [130.89.10.247] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DqVf-00004p-00; Thu, 27 Jan 2000 07:06:59 -0800 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id QAA14493; Thu, 27 Jan 2000 16:06:50 +0100 (MET) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id QAA23476; Thu, 27 Jan 2000 16:01:43 +0100 (MET) Message-ID: <38905DD8.991EB504@cs.utwente.nl> Date: Thu, 27 Jan 2000 16:01:44 +0100 From: Clever Ricardo Guareis de Farias Organization: CTIT - Centre for Telematics and Information Technology X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: IDMS'2000: call for papers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Our apologies if you receive multiple copies of this CfP.] Announcement and Call for papers IDMS'2000 7th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services CTIT/Univ. of Twente, Enschede, The Netherlands, October 17-20, 2000 http://www.ctit.utwente.nl/Docs/news/idms_2000.htm The goal of the IDMS series of workshops is to bring together researchers, developers, and practitioners from academia and industry; and to provide a forum for discussion, presentation, and exploration of technologies and advances in the broad field of interactive distributed multimedia systems and telecommunication services, ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Relevant topics include, but are not limited to: * High-speed/ATM networks; * Mobile multimedia systems; * Multimedia over satellite; * Multimedia middleware; * Quality of service issues; * Media scaling; * Resource management; * Protocol design and implementation; * Distributed multimedia database systems; * Development tools for distributed multimedia applications; * Multimedia-specific intelligent agents; * Computer supported collaborative work; * Distributed virtual reality systems; * Distance education; * Conferencing; * Digital libraries; * Interactive television; * Video-on-demand systems; * Compression algorithms. IDMS 2000 will consist of a three days technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavor of a workshop, the number of participants will be restricted. Furthermore, we encourage contributions in the form of full papers and position papers. Full papers should describe innovative and significant work. Position papers are meant to enable researchers to present exciting ongoing work in early stages, opinions about current developments, and suggestions for future directions. The purpose of position papers is to provide a seed for debate and discussion. Both types of papers will be reviewed by the program committee and included in the workshop proceedings. The proceedings will be published by Springer-Verlag as a Lecture Notes in Computer Science (http://www.springer.de/comp/lncs/index.html). INFORMATION FOR AUTHORS: Authors are invited to submit full papers and position papers in electronic form (RTF, Latex, Postscript or PDF) to idms2000@ctit.utwente.nl. Submitted manuscripts must describe original work (not submitted elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. Further instructions can be found on http://www.springer.de/comp/lncs/authors.html. IMPORTANT DATES: * Submission due: March 15, 2000 * Notification of acceptance: May 15, 2000 * Camera ready version: June 15, 2000 PROGRAM CO-CHAIRS: Marten van Sinderen and Hans Scholten CTIT - Centre for Telematics and Information Technology, University of Twente, P.O. Box 217, 7500 AE, Enschede, The Netherlands E-mail: {sinderen; scholten}@cs.utwente.nl, Phone: +31/53.489.3677, Fax: +31/53.4894524 PROGRAM COMMITTEE:: H. Batteram, Lucent Techn., NL G. v. Bochmann, Univ. Montreal, CDN P. Bosch, CWI, NL B. Butscher, GMD-FOKUS, GER A. Campbell, Colombia Univ., USA L. Delgrossi, Univ. Piacenza, I M. Diaz, LAAS-CNRS, Fr H. Eertink, Telematica Instituut, NL W. Effelsberg, Univ. Mannheim, GER F. Eliassen, Univ. Oslo, No L. Ferreira Pires, Univ. Twente, NL V. Goebel, Univ. Oslo - UniK, No T. Helbig, Philips, GER D. Hutchison, Lancaster Univ., GB P. Jansen, Univ. Twente, NL W. Kalfa, TU Chemnitz, GER E. Moeller, GMD-FOKUS, GER K. Nahrstedt, Univ. Illinois, USA P. Owezarski, LAAS-CNRS, Fr S. Pink, SICS, SDN T. Plagemann, Univ. Oslo - UniK, No D. Quartel, Univ. Twente, NL G. Smit, Univ. Twente, NL R. Steinmetz, TU Darmstadt / GMD, GER L. Wolf, Univ. Karlsruhe, GER ORGANISING COMMITTEE: N. Diakov, Univ. Twente, NL C.R. Guareis de Farias, Univ. Twente, NL J. Kunnen, Univ. Twente, NL From rem-conf Thu Jan 27 08:34:19 2000 From rem-conf-request@es.net Thu Jan 27 08:34:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DrlY-0001Qp-00; Thu, 27 Jan 2000 08:27:28 -0800 Received: from uumail-relay-blr.ernet.in [202.141.1.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DrlT-0001QY-00; Thu, 27 Jan 2000 08:27:26 -0800 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 WAA03652 for ; Thu, 27 Jan 2000 22:01:56 +0530 Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id VAA27596 for ; Thu, 27 Jan 2000 21:57:35 +0530 (IST) Received: by ece.iisc.ernet.in (SMI-8.6/SMI-4.1) id VAA29751; Thu, 27 Jan 2000 21:56:36 +0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <200001271626.VAA29751@ece.iisc.ernet.in> Subject: Adaptive playout To: rem-conf@es.net Date: Thu, 27 Jan 0 21:56:35 GMT+5:30 X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Not sure if this is directly related to RTP. Hope you would not mind. In the presence of adaptive playout delay, are there any guidelines as to how often and to what extent we can introduce the playout delay in order that the original speech can faithfully be reproduced by preserving inter-word gaps apart from overcoming audio glitches ? There are problems in detecting the beginning of a new talk spurt. If say, a 100millsec gap between two consecutive audio samples is what I consider as a new talk spurt, and introduce new playout delay, then there is a possibilty that the new talk spurt either starts at 20millisec, or 500millisec after the end of the old talk spurt. This can result in a shrink or expansion of the original speech. Hope I am making some sense. Regards Anand From rem-conf Thu Jan 27 10:00:22 2000 From rem-conf-request@es.net Thu Jan 27 10:00:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Dt8G-000327-00; Thu, 27 Jan 2000 09:55:00 -0800 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Dt8E-00031t-00; Thu, 27 Jan 2000 09:54:58 -0800 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id JAA22607; Thu, 27 Jan 2000 09:54:40 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id JAA25324 for ; Thu, 27 Jan 2000 09:54:36 -0800 (PST) Date: Thu, 27 Jan 2000 09:54:36 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200001271754.JAA25324@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu Cc: nonnen@eurecom.fr Subject: Reminder, CFP: Integrating Multicast into the Internet X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Reminder, DEADLINE February 1, 2000 CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth@cs.ucsb.edu Email: nonnen@eurecom.fr IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Papers should be double spaced, 11pt font, and standard margins. Length should be 20 pages maximum not including figures, tables, and references. Maximum total length is 30 pages. Authors are requested to send e-mail to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@eurecom.fr) giving a URL from where a postscript or PDF file can be downloaded (papers can also be emailed though this is not the preferred format). Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. From rem-conf Thu Jan 27 10:03:21 2000 From rem-conf-request@es.net Thu Jan 27 10:03:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DtAo-00033Q-00; Thu, 27 Jan 2000 09:57:38 -0800 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DtAn-00033F-00; Thu, 27 Jan 2000 09:57:37 -0800 Received: from super.du.uab.ericsson.se (root@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA27072; Thu, 27 Jan 2000 18:57:31 +0100 (MET) Received: from martell.du.uab.ericsson.se (mml@martell [134.138.176.69]) by super.du.uab.ericsson.se (8.10.0.Beta12/8.10.0.Beta12/erix-1.7) with ESMTP id e0RHvUX04816; Thu, 27 Jan 2000 18:57:30 +0100 (MET) Received: by martell.du.uab.ericsson.se (8.9.1/client-1.7) id SAA08924; Thu, 27 Jan 2000 18:57:29 +0100 (MET) Message-ID: <14480.34569.701643.791267@gargle.gargle.HOWL> Date: Thu, 27 Jan 2000 18:57:29 +0100 (MET) From: Matthias.Lang@ericsson.com To: rem-conf@es.net Cc: Qishen Tang Subject: RTP Jitter question... In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Qishen Tang writes: > # Is there an industry guideline/threshold as to what RTP Jitter value > should be??? There are rules of thumb about what sort of delays you can get away with in a _telephone call_. Other uses of RTP will have different rules of thumb. A rough rule is that people don't notice a delay of up to 150ms and find a delay of above about 300ms annoying. The amount of jitter affects the delay the receiver has to add to compensate for jitter, so a stream that requires a 800ms playout delay to compensate for jitter is going to sound bad. A stream that jitters by 50ms will probably sound OK in the absence of other things causing large delay or the appearance of delay, such as router delays, propagation delays and frequency offsets in sampling clocks. Matt From rem-conf Thu Jan 27 10:24:00 2000 From rem-conf-request@es.net Thu Jan 27 10:23:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DtW0-0004XY-00; Thu, 27 Jan 2000 10:19:32 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DtVz-0004XO-00; Thu, 27 Jan 2000 10:19:31 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA07912; Thu, 27 Jan 2000 10:00:02 -0800 (PST) Message-Id: <3.0.3.32.20000127100000.00a86520@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 27 Jan 2000 10:00:00 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 2/2/2000 Estimation of Web Video Multiplicity -- Sen-ching Samson Cheung, EECS Department, U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Estimation of Web Video Multiplicity Wednesday February 2, 2000 1:10 - 2:30 PST Fujitsu Seminar Room (405 Soda Hall) Sen-ching Samson Cheung EECS Department, U.C. Berkeley With ever more popularity of video web-publishing, many popular contents are being mirrored, modified and republished, resulting in excessive content duplication. While such redundancy provides fault tolerance for continuous availability of information, it could potentially make multimedia web search results repetitious and cluttered. As such, developing techniques for detecting similarity and duplication is important to multimedia search engines. Content providers might also be interested in identifying duplicates of their content for business related reasons. In this talk, we will present an efficient algorithm, called video signature, to detect similar video sequences for large databases. The idea is to first form a "signature" for each video sequence by selecting a small number of its frames that are most similar to a number of randomly chosen seed images. Then the similarity between any two video sequences can be reliably estimated by comparing their respective signatures. Using this method, we achieve 85% recall and precision ratios on a test database of 377 video sequences. We have applied our proposed algorithm to a collection of 1800 hours of video corresponding to around 45000 clips from the web. Our results indicate that, on average, every video in our collection has around five similar copies. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Jan 27 11:31:39 2000 From rem-conf-request@es.net Thu Jan 27 11:31:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12DuXz-0005yI-00; Thu, 27 Jan 2000 11:25:39 -0800 Received: from oberon.dnai.com [207.181.194.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 12DuXx-0005xx-00; Thu, 27 Jan 2000 11:25:37 -0800 Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id LAA08194 for ; Thu, 27 Jan 2000 11:24:33 -0800 (PST) Received: from hariv (cheetah1 [216.15.52.38]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id LAA06315 for ; Thu, 27 Jan 2000 11:24:28 -0800 (PST) Message-ID: <007c01bf68fc$c7481320$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Re: Adaptive playout Date: Thu, 27 Jan 2000 11:29:07 -0800 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 Hi, I have a related question? How to decide the depth of the jitter-buffer? Can anyone send me references on this implementation? Regards Hari -----Original Message----- From: SVR Anand To: rem-conf@es.net Date: Thursday, January 27, 2000 8:47 AM Subject: Adaptive playout >Hi, > >Not sure if this is directly related to RTP. Hope you would not mind. > >In the presence of adaptive playout delay, are there any guidelines as to how >often and to what extent we can introduce the playout delay in order that >the original speech can faithfully be reproduced by preserving inter-word >gaps apart from overcoming audio glitches ? > There are problems in detecting the beginning of a new talk spurt. If >say, a 100millsec gap between two consecutive audio samples is what I consider >as a new talk spurt, and introduce new playout delay, then there is a >possibilty that the new talk spurt either starts at 20millisec, or 500millisec >after the end of the old talk spurt. This can result in a shrink or expansion >of the original speech. > > Hope I am making some sense. > >Regards >Anand > From rem-conf Thu Jan 27 11:57:37 2000 From rem-conf-request@es.net Thu Jan 27 11:57:36 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12DuyS-0007Au-00; Thu, 27 Jan 2000 11:53:00 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 12DuyQ-0007Ak-00; Thu, 27 Jan 2000 11:52:58 -0800 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhzvr08415; Thu, 27 Jan 2000 19:52:36 GMT Message-ID: <3890A435.7151B78C@dynamicsoft.com> Date: Thu, 27 Jan 2000 15:01:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hari Krishna Vuppaladhadiam CC: rem-conf@es.net Subject: Re: Adaptive playout References: <007c01bf68fc$c7481320$03000004@hariv.domain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Many papers on this subject have been written. Usually adaptive algorithms are used that adjust the depth dynamically. See: Ramachandran Ramjee, Jim Kurose, Don Towsley and Henning Schulzrinne, "Adaptive playout mechanisms for packetized audio applications in wide-area networks," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Toronto, Canada), pp. 680-688, Jun. 1994. Sue B. Moon, Jim Kurose and Don Towsley, "Packet audio playout delay adjustment: performance bounds and algorithms," ACM/Springer Multimedia Systems, vol. 5, no. 1, pp. 17--28, Jan. 1998. J. Rosenberg, L. Qiu, H. Schulzrinne, "Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet", to appear in Proceedings of IEEE Infocom 2000, March 2000, Tel Aviv, Israel. -Jonathan R. Hari Krishna Vuppaladhadiam wrote: > > Hi, > I have a related question? > > How to decide the depth of the jitter-buffer? Can anyone send me references > on this implementation? > > Regards > Hari > > -----Original Message----- > From: SVR Anand > To: rem-conf@es.net > Date: Thursday, January 27, 2000 8:47 AM > Subject: Adaptive playout > > >Hi, > > > >Not sure if this is directly related to RTP. Hope you would not mind. > > > >In the presence of adaptive playout delay, are there any guidelines as to > how > >often and to what extent we can introduce the playout delay in order that > >the original speech can faithfully be reproduced by preserving inter-word > >gaps apart from overcoming audio glitches ? > > There are problems in detecting the beginning of a new talk spurt. If > >say, a 100millsec gap between two consecutive audio samples is what I > consider > >as a new talk spurt, and introduce new playout delay, then there is a > >possibilty that the new talk spurt either starts at 20millisec, or > 500millisec > >after the end of the old talk spurt. This can result in a shrink or > expansion > >of the original speech. > > > > Hope I am making some sense. > > > >Regards > >Anand > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Jan 27 16:05:31 2000 From rem-conf-request@es.net Thu Jan 27 16:05:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Dyl2-0001hS-00; Thu, 27 Jan 2000 15:55:24 -0800 Received: from helios.cstp.umkc.edu [134.193.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Dyl0-0001hI-00; Thu, 27 Jan 2000 15:55:22 -0800 Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id RAA12824; Thu, 27 Jan 2000 17:54:30 -0600 (CST) Date: Thu, 27 Jan 2000 17:54:30 -0600 (CST) From: Eun Kyo Park Message-Id: <200001272354.RAA12824@helios.cstp.umkc.edu> 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, cnom@maestro.bellcore.com, 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 Subject: ICCCN2000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Our apologies if you receive this multiple times!!) IEEE IC3N'2000 CALL FOR PAPERS NINTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 16 - 18, 2000 Imperial Palace Hotel, Las Vegas, Nevada USA (Website: icccn.cstp.umkc.edu) Sponsored by IEEE Communications Society (tech. co-sponsor), Army Research Lab/Office, IBM, NOKIA, Siemens (pending approval of sponsorships) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results. The topics include, but are not limited to: Optical Communication Networks Wireless/Mobile/Satellite Comm Networks ATM Networking Internet Services/Applications Wireless Multimedia Applications Real-time Communications Quality of Services (QoS) Issues LAN/WAN Internetworking Network Interoperability Personal Communication Services Network Control Management Broadband Networks Intelligent Networks Multicast and Routing Protocols Network Security Media Access Control/Mobility Algorithms Network Reliability High Speed Network OAM/Protocols Video-on-Demand Data Traffic Engineering Network Management/Billing Global Infrastructure Network Evolution Network Processor Technology Performance Modeling/Analysis Communication Software Protocol Design/Validation/Testing Networked Databases Network Architectures Terabit optical switching/ routing architectures and signaling SUBMISSION: Authors are invited to submit complete and original papers. Papers that may be submitted should not have been previously published in another forum, or are not currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a submission as long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (go to the end of this CFP for more information; ps or pdf format is preferred. Please contact Dr. Park if you have to submit with hard copies). Manuscripts should be submitted by Friday, April 24, 2000 to ICCCN2000 website or contact program co-chairs with any questions: Dr. Ton Engbersen Professor E.K. Park IBM Research Laboratory Computer Science Telecommunications Saumerstrasse 4 University of Missouri 8803 Rueschlikon Robert Flarsheim Hall, Room 534 Switzerland 5100 Rockhill Road apj@zurich.ibm.com Kansas City, Missouri 64110 USA +41-1-7248302 (816)235-1497; (816)235-5159(fax) +41-1-7248599 (fax) ekpark@cstp.umkc.edu IMPORTANT DATES: Paper submission deadline : April 24, 2000 Notification of acceptance: June 26, 2000 Camera ready papers due : July 31, 2000 TUTORIALS: Proposals are solicited for tutorials. Please email your proposals in ASCII format by April 24, 1999 to one of the Program Chairs above. WEBSITE: We are currently setting up electronic paper submission procedures for the IEEE ICCCN2000 (will be ready by March), so please visit ICCCN2000 web site icccn.cstp.umkc.edu for more up-to-date information. From rem-conf Fri Jan 28 13:44:23 2000 From rem-conf-request@es.net Fri Jan 28 13:44:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12EImO-0003eR-00; Fri, 28 Jan 2000 13:18:08 -0800 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12EImN-0003eH-00; Fri, 28 Jan 2000 13:18:07 -0800 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 NAA23939; Fri, 28 Jan 2000 13:17:14 -0800 Message-Id: <3.0.5.32.20000128131709.009d35c0@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 28 Jan 2000 13:17:09 -0800 To: mbone@ISI.EDU, rem-conf@es.net, confctrl@ISI.EDU, ipmulticast@stardust.com From: Marty Bickford Subject: mcast: PIM Source Only - Connectionless Multicast - Multicast Debugging Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list PIM Source Only, Connectionless Multicast, and Multicast Debugging are just a few of the technical sessions @ mcast 2000. See more below... Scalable infrastructure and accelerated content delivery are the themes of this year's mcast conference and multi-vendor network demonstration. Join us at this prestigious and influential event on February 7-9, 2000 at the San Francisco Airport Marriott. http://www.stardust.com/mcast2000/ Price increase -------------- On Monday, January 31st, the price will increase to $1,295 - sign-up today at: https://www.stardust.com/events/mcast2000/register.htm Highlights ---------- Below we've highlighted the 3 things most interesting to this list - conference sessions/speakers, BOFs and the Multicast Splash. BOFs ---- - MINC (Multicast-based Inference of Network Characteristics)=20 to Infer Loss and Delay Inside the Network Sue B. Moon, Sprint ATL=20 - Standards/Multicasting Forum Steve Jacobson, RealNetworks - IP Multicast Datagram Forwarding using Non-Procedural=20 Packet Filters Charlie Jenkins, Solidum Systems - International Webcasting Peggy Miles, Intervox and IWA - Wireless Multimedia Forum Martin Hall, Stardust.com Sessions (portion of full agenda)=20 --------------------------------- - Attaching DVMRP Domains Safely to the New PIM Mbone Cyndi Jung, 3Com - E-Commerce and IP Multicast/Caching/Content Distribution Scott Bishop, Mirror Image Internet & Ken Miller, Starburst - Multicast on CA*net 3 David Bickle, Bell Nexxia - Towards Super-scalable Multicast J=F6rg Liebeherr, University of Virginia - Using the Java Reliable Multicast Service Miriam Kadansky, Sun Microsystems Labs - PIM Source Only Tom Pusateri, Juniper Networks - Coming Soon to Theaters and Televisions Near You Fred Kokaska, Logic Innovations - Enabling Internet TV with Intelligent Network Infrastructure Steven McCanne, FastForward Networks - Connectionless Multicast (CLM) Dirk Ooms, Alcatel Corporate Research Center - Deployment Issues for the Multicast Architecture Brian Neil Levine, University of Massachusetts Amherst - Fine Granular Scalability: a new framework for real-time=20 video streaming of multimedia content over the Internet Hayder Radha, Philips Research - Multicast Debugging Bill Fenner, AT&T Labs - Research - Caching =96 The Component Technology for Edge Delivery Rod Murchison, CacheFlow SPLASH II --------- New Internet Content Delivery Mechanisms Make Their Debut =20 * Are you following the multi-million dollar investments in Geocast? * Do you know what Virgin's put in place for digital music distribution? * Do you know what TV stations are doing to enable IP-based content delivery over their local broadcast spectrum? * Have you considered what it means for local TV stations to become Internet Service providers? * Have you experienced the delivery of Internet content to a PC through rabbit ear antennas? On Monday February 7, you can get answers to all these questions and more >from the following companies at the debut of the Splash project incorporating 6 months' work from these companies. * AT&T * Bloomberg * Hewlett-Packard Company * Hughes Network Systems * Internet Initiative Japan * KNTV NewsChannel 11 * Microspace= Communications * Netcom Systems * Nortel Networks * Priority Networks * Real Networks * * SkyStream Networks * Stardust.com * Teleglobe * UUNET * Virgin JamCast * * Yahoo * 1. Meet the people and companies who are developing new technologies,=20 products and services for the delivery of Internet content. 2. Experience first hand many of these new capabilities on show in many cases for the first time in the project codenamed "The Splash" engineered over the last 6 months by the companies listed above. When: 5:30-8:00pm, Monday Feb 7, 2000. Where: San Francisco Airport Marriott Hotel More Information ---------------- Get more information including a Multicast white paper and MP3's at http://www.stardust.com/mcast2000/ --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.com mcast 2000 - http://www.stardust.com/mcast2000/ 4th annual summit on scalable content delivery From rem-conf Sat Jan 29 07:53:50 2000 From rem-conf-request@es.net Sat Jan 29 07:53:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12EZx6-0003Jt-00; Sat, 29 Jan 2000 07:38:20 -0800 Received: from tiger1.nownuri.net [203.238.128.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 12EZx4-0003JT-00; Sat, 29 Jan 2000 07:38:19 -0800 Received: (from k3@localhost) by tiger1.nownuri.net (8.9.0/H/8.9.0) id AAA16118; Sun, 30 Jan 2000 00:37:10 +0900 (KST) Date: Sun, 30 Jan 2000 00:37:10 +0900 (KST) From: ¿À¿¬Èñ Message-Id: <200001291537.AAA16118@tiger1.nownuri.net> To: rem-conf@es.net Subject: Remove MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove yeonche@secsm.org --MIME Multi-part separator-- From rem-conf Sat Jan 29 21:49:31 2000 From rem-conf-request@es.net Sat Jan 29 21:49:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12En1l-00018P-00; Sat, 29 Jan 2000 21:36:01 -0800 Received: from abd10979.ipt.aol.com (mail01.homewknow.com) [171.209.9.121] by mail1.es.net with smtp (Exim 1.81 #2) id 12En1g-00017d-00; Sat, 29 Jan 2000 21:35:56 -0800 From: Subject: Free No Repay Cash Grants! Up To $50,000 Date: Sun, 30 Jan 2000 03:05:45 Message-Id: <323.668179.583445@mail01.homewknow.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE CASH GRANTS, NEVER REPAY! You Can Get The Money You Need... To Start Your Home Business... To Consolidate Your Debt... To Go To college... To Start Your Home Business... Almost ANY Worthwhile Reason... Why? Foundations all over the United States GIVE away Millions of Dollars of CASH GRANTS every year. They must give this MONEY away, in order to maintain their tax free status. Who Can Apply? ANYONE can apply for a Grant from 18 years old and up! We Can Help! We will show you HOW & WHERE to get Grants. This MONEY has to be given away, WHY not to YOU? Grants from $500.00 to $50,000.00 are possible! GRANTS don't have to be paid back! Grants can be ideal for people who are or were bankrupt or just have bad credit. The Good News! DON'T pay $79.00 to $129.00 for this information and list. We Will Show You How To Apply For Your Grants, Where To Apply, And Exactly What To Say. We Help You Do It All For Just $29.95. Even Better News, Our ULTRA PACKAGE! * Get All The Above & Below For Only $49.95. * Free Federal Programs! * Free Money-Government Programs! * Free State Money! * Minority Business Development Grants! * Women's Enterprises Grants! * Information On Free Legal Services! * Free Legal Services To Repair Your Credit! * How & Where To Sell Your Product Or Service To The Goverment! * Over Twice As Much As Our Regular Package Above, With Updates As We Get Them! If You Pay With Credit Card, All Information Will Be Sent To Your Email Address Within 24 to 48 Hours! We Gladly Accept Credit Cards & Checks Via Web and Postal Mail: American Express Master Card Visa Don't Delay, This Is A Limited Time Offer At This Amazing Low Price! Get That Grant Before College Rush Time Coming Up! Interested, Please Visit Our Website Below And Place Your Order! ********** http://www.geocities.com/Eureka/Network/3801/ ********** To Order by postal mail, please send $29.95 Plus $2.00 S & H for our regular package, or send $49.95 Plus $2.00 S & H for our Ultra Package to the below address. Make payable to Grant Gold 2000. Grant Gold 2000 3215 Merrimac Ave. Dayton, OH 45405 ********** From rem-conf Mon Jan 31 06:58:38 2000 From rem-conf-request@es.net Mon Jan 31 06:58:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12FI1Q-0002PX-00; Mon, 31 Jan 2000 06:41:44 -0800 Received: from hpheger0.nm.informatik.uni-muenchen.de [129.187.214.20] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12FI1O-0002PN-00; Mon, 31 Jan 2000 06:41:42 -0800 Received: from hpheger3.nm.informatik.uni-muenchen.de (vogt@hpheger3.nm.informatik.uni-muenchen.de [129.187.214.23]) by hpheger0.nm.informatik.uni-muenchen.de (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id PAA29376; Mon, 31 Jan 2000 15:34:41 +0100 (MET) Date: Mon, 31 Jan 2000 15:34:41 +0100 (MET) From: Gerald Vogt Reply-To: usm2000@informatik.uni-muenchen.de To: Undisclosed recipients: ; Subject: USM 2000 Submission deadline extended Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list USM 2000: DEADLINE EXTENDED 3rd IFIP/GI International Conference on Trends towards a Universal Service Market Munich, Germany September 12-14, 2000 After we received several requests to extend the deadline for submissions to the USM 2000 conference, we offically announce that the new deadline for submissions is Monday, February 14, 2000. Papers are to be submitted on http://usm2000.informatik.uni-muenchen.de/submission.shtml There you will find all necessary information. We would like to ask all authors that intend to submit a paper to USM 2000 to register their paper as soon as possible for organisational purposes. Afterwards you can upload your paper until the new deadline, February 14. We are looking forward to your submissions. Regards, USM 2000 Organisation Committee usm2000@informatik.uni-muenchen.de http://usm2000.informatik.uni-muenchen.de