From rem-conf Sat Jan 02 07:59:07 1999 From rem-conf-request@es.net Sat Jan 02 07:59:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zwTFx-0001kv-00; Sat, 2 Jan 1999 07:46:25 -0800 Received: from pri-ra-1071.isdn.net.il (secure.com) [212.25.75.71] by mail1.es.net with smtp (Exim 1.81 #2) id 0zwTFp-0001j9-00; Sat, 2 Jan 1999 07:46:20 -0800 To: From: Subject: Free Tip Date: ש, 2 ינואר 1999 14:09:43 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Investor / Business person, Free Tip Iceberg would like you to have the following tip on world currency: Dollar is going to go up vs. the Swiss Franc between 5% and 8% in the next few weeks. We hope you find it useful. And remember, this is just the Tip of the Iceberg. regards, Free Tip Iceberg team. note: if you are not an investor or business person or otherwise do not want to get a free tip, please reply with subject "remove". From rem-conf Sun Jan 03 18:27:52 1999 From rem-conf-request@es.net Sun Jan 03 18:27:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zwzYG-0005Fn-00; Sun, 3 Jan 1999 18:15:28 -0800 Received: from client-151-200-119-77.bellatlantic.net (bellatlantic.net) [151.200.119.77] by mail1.es.net with smtp (Exim 1.81 #2) id 0zwzYE-0005Fd-00; Sun, 3 Jan 1999 18:15:26 -0800 From: sozni@listbot.com To: sozni@listbot.com Subject: Ordinary mom's & grandma's, free nude pic's! Message-Id: Date: Sun, 3 Jan 1999 18:15:26 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MOM's and GRANDMA's: http://www.teenfree.com/grandmalover Amateur women's, ALL over 40 (mom's, grandma's, wife's, neighboor's, secretary's, girlfriend's, etc...) waiting you wet. FREE PIC's by category: Straight, Double Fucking, Sucking, Lesbo, Nude on shower, Pissing, Anal, Big ass, Group SEX, Dildo's and a Special VISITORS GALLERY. AND MORE : sozni - http://www.biosys.net/sozni From rem-conf Mon Jan 04 00:12:56 1999 From rem-conf-request@es.net Mon Jan 04 00:12:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zx4yN-0007gE-00; Mon, 4 Jan 1999 00:02:47 -0800 Received: from dns.sersol.com [206.127.255.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zx4yK-0007g4-00; Mon, 4 Jan 1999 00:02:45 -0800 Received: (from root@localhost) by dns.sersol.com (8.8.7/SCO5) id VAA07170; Sun, 3 Jan 1999 21:57:09 -1000 (HST) Received: from www.glhawaii.org(206.127.255.229) by dns id sma007168; Sun Jan 3 21:56:52 1999 Old-X-Envelope-From: Reply-To: From: "James D. Wilson" To: "Abuse@Ftc. Gov" , , , , , , , , , , , , , , , , , , Subject: FW: Ordinary mom's & grandma's, free nude pic's! Date: Sun, 3 Jan 1999 21:57:30 -1000 Message-ID: <002a01be37b7$e119cd60$e5ff7fce@www.glhawaii.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 US Federal Trade Commission: documentation of interstate theft of electronic resources - please prosecute NKN.EDU/NKN.NET: These spammers are on your wire/are spamming on your watch and using websites on your network to collect the profits of their network abuse, network trespassing, and network theft of services. Please NUKE them to 5,000,000 deg. kelvin. Bellatlantic: they used your wires to steal their services. Please nuke. Biosys.net: the spammer is spamvertizing a webpage on your network. Please NUKE immediately. No honest business does business with thieves. Myriad.net: please ensure that Biosys nukes the crooks off the net. Listbot.com: they are using your email services - please nuke sozni the scumbag. Netforward.com: please dump the spammers. National Knowledge Networks, Inc. (NETBLK-NKN-BLK-1) NKN-BLK-1 207.55.128.0 - 207.55.223.255 Abid Mustafa (NETBLK-NKN-ADEA1) NKN-ADEA1 207.55.136.128 - 207.55.136.135 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.mil for NIPRNET Information. **complete** National Knowledge Networks, Inc. (NETBLK-NKN-BLK-1) 350 N. St. Paul - Suite 2410 Dallas, TX 75205 US Netname: NKN-BLK-1 Netblock: 207.55.128.0 - 207.55.223.255 Maintainer: NKN Coordinator: Pathos, Peter (PP46-ARIN) pathos@NKN.NET 214-880-0702 Domain System inverse mapping provided by: DFW.NKN.EDU 199.171.20.1 NS2.NKN.NET 199.171.20.31 Record last updated on 17-Nov-97. Database last updated on 1-Jan-99 16:11:45 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.mil for NIPRNET Information. **complete** Abid Mustafa (NETBLK-NKN-ADEA1) 3951 SW Gamwell Topeka, KS 66610 US Netname: NKN-ADEA1 Netblock: 207.55.136.128 - 207.55.136.135 Coordinator: Technical Support (TS135-ORG-ARIN) techsup@NKN.NET 214-954-0028 Fax- 214-740-1872 Record last updated on 29-Oct-97. Database last updated on 1-Jan-99 16:11:45 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.mil for NIPRNET Information. **complete** Host info www.biosys.net 2/3000/50/0; 01/03/99 21:52:10 Official name: www.biosys.net IP address: 204.57.67.39 ping 204.57.67.39 packet 2 failed, retcode = 11010 (Timed Out) Registrant: BioSys.Net Services (BIOSYS2-DOM) 700 University Drive East, Suite 106 College Station, TX 77840 US Domain Name: BIOSYS.NET Administrative Contact, Technical Contact, Zone Contact: NetForward Admin (NA174-ORG) admin@NETFORWARD.COM (409)693-8885 Fax- (409)693-6923 Billing Contact: NetForward Admin (NA174-ORG) admin@NETFORWARD.COM (409)693-8885 Fax- (409)693-6923 Record last updated on 08-Jun-97. Record created on 07-Mar-97. Database last updated on 3-Jan-99 17:57:14 EST. Domain servers in listed order: NS.MYRIAD.NET 204.57.67.2 NS2.MYRIAD.NET 204.57.67.20 - - James D. Wilson "non sunt multiplicanda entia praeter necessitatem" William of Ockham (1285-1347/49) - -----Original Message----- Return-Path: rem-conf-request@es.net Received: (from root@localhost) by dns.sersol.com (8.8.7/SCO5) id VAA06322 for ; Sun, 3 Jan 1999 21:11:32 -1000 (HST) Received: from mail1.es.net(198.128.3.181) by dns id sma006304; Sun Jan 3 21:11:13 1999 X-Envelope-From: Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zwzYG-0005Fn-00; Sun, 3 Jan 1999 18:15:28 -0800 Received: from client-151-200-119-77.bellatlantic.net (bellatlantic.net) [151.200.119.77] by mail1.es.net with smtp (Exim 1.81 #2) id 0zwzYE-0005Fd-00; Sun, 3 Jan 1999 18:15:26 -0800 From: sozni@listbot.com To: sozni@listbot.com Subject: Ordinary mom's & grandma's, free nude pic's! Message-Id: Date: Sun, 3 Jan 1999 18:15:26 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: listFrom: sozni@listbot.com [mailto:sozni@listbot.com] Sent: Sunday, January 03, 1999 4:15 PM To: sozni@listbot.com Subject: Ordinary mom's & grandma's, free nude pic's! MOM's and GRANDMA's: http://www.teenfree.com/grandmalover Amateur women's, ALL over 40 (mom's, grandma's, wife's, neighboor's, secretary's, girlfriend's, etc...) waiting you wet. FREE PIC's by category: Straight, Double Fucking, Sucking, Lesbo, Nude on shower, Pissing, Anal, Big ass, Group SEX, Dildo's and a Special VISITORS GALLERY. AND MORE : sozni - http://www.biosys.net/sozni -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 Comment: Spammers are NetAbusers - Jail Them With The Other Criminals iQA/AwUBNpB0ajAufbtGOmgdEQJ7PACeNEGv6/WbJRIXt3hJ3jK7BeFgiC4AoJI2 SrObcjcR8dvdJlxdNB6HQW6K =mvsa -----END PGP SIGNATURE----- From rem-conf Mon Jan 04 04:38:56 1999 From rem-conf-request@es.net Mon Jan 04 04:38:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zx99D-0002rP-00; Mon, 4 Jan 1999 04:30:15 -0800 Received: from motgate2.mot.com [129.188.136.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zx99C-0002rF-00; Mon, 4 Jan 1999 04:30:14 -0800 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id GAA12146 for ; Mon, 4 Jan 1999 06:32:01 -0600 (CST) Comments: ( Received on motgate2.mot.com from client mothost.mot.com, sender gvjohn@miel.mot.com ) Received: from schbbs.mot.com (schbbs.mot.com [129.188.137.102]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id GAA22907 for ; Mon, 4 Jan 1999 06:30:12 -0600 (CST) Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by schbbs.mot.com (8.8.5/8.8.5/MOT-3.8) with SMTP id GAA24479 for ; Mon, 4 Jan 1999 06:29:34 -0600 (CST) Received: from rex.miel.mot.com by hpux4.miel.mot.com with SMTP id AA02299 (5.67b/IDA-1.6 for rem-conf@es.net); Mon, 4 Jan 1999 17:51:47 +0500 Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA16609 (5.67b/IDA-1.5 for rem-conf@es.net); Mon, 4 Jan 1999 18:02:05 +0530 Sender: gvjohn@miel.mot.com Message-Id: <3690B2D0.75D6@miel.mot.com> Date: Mon, 04 Jan 1999 17:53:45 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: casner@cisco.com, van@ee.lbl.gov Cc: rem-conf@es.net, gvjohn@miel.mot.com Subject: RTP/UDP/IP header compression Content-Type: multipart/mixed; boundary="------------243D1A546F8" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------243D1A546F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, In the Internet Draft - IP Header Compression over PPP, assigned numbers for RTP/UDP/IP header compression packets are given (COMPRESSED_RTP, COMPRESSED_UDP, CONTEXT_STATE, etc) . Could any of you tell me what are the assigned numbers for rfc1294 encapsulation over Frame Relay ? What about X25 link ? Expecting your reply Rgds GVJohn --------------243D1A546F8 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from rex.miel.mot.com by earth.miel.mot.com with SMTP id AA15826 (5.67b/IDA-1.5 for gvjohn); Mon, 28 Dec 1998 19:01:58 +0530 Return-Path: Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA03111 (5.67b/IDA-1.5 for gvjohn@earth.miel.mot.com); Mon, 28 Dec 1998 19:09:16 +0530 Sender: gvjohn@miel.mot.com Message-Id: <36878844.658B@miel.mot.com> Date: Mon, 28 Dec 1998 19:01:48 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: casner@cisco.com Cc: van@ee.lbl.gov, gvjohn@miel.mot.com Subject: [Fwd: RUIH : [Fwd: RTP/UDP/IP header compression]] Content-Type: multipart/mixed; boundary="------------63FAD7033B4" This is a multi-part message in MIME format. --------------63FAD7033B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, In the Internet Draft - IP Header Compression over PPP, assigned numbers for RTP/UDP/IP header compression packets are given . Can one of you tell me what are assigned numbers for rfc1294 encapsulation over Frame Relay ? What about X25 link ? Does it hold the same value as FR. Expecting your reply Rgds GVJohn --------------63FAD7033B4 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from hpux4.miel.mot.com by earth.miel.mot.com with SMTP id AA25471 (5.67b/IDA-1.5 for gvjohn); Fri, 20 Nov 1998 09:45:06 +0530 Return-Path: Received: from sindhu.miel.mot.com by hpux4.miel.mot.com with SMTP id AA20363 (5.67b/IDA-1.6 for gvjohn@earth.miel.mot.com); Fri, 20 Nov 1998 09:40:55 +0500 Received: from miel.mot.com (xterm_84_210.miel.mot.com [217.1.84.210]) by sindhu.miel.mot.com with ESMTP (8.7.1/8.7.1) id JAA08326 for ; Fri, 20 Nov 1998 09:48:35 +0530 (IST) Message-Id: <3654EC98.9A00B8E0@miel.mot.com> Date: Fri, 20 Nov 1998 09:44:16 +0530 From: Sriharsha J X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: gvjohn@miel.mot.com Subject: RUIH : [Fwd: RTP/UDP/IP header compression] Content-Type: multipart/mixed; boundary="------------6688C0834256F5151C9EE612" This is a multi-part message in MIME format. --------------6688C0834256F5151C9EE612 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6688C0834256F5151C9EE612 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by akash.miel.mot.com (8.9.1/8.9.1) with SMTP id XAA01801 for ; Thu, 19 Nov 1998 23:02:47 +0530 (IST) Received: from pobox.mot.com by hpux4.miel.mot.com with SMTP id AA08262 (5.67b/IDA-1.6 for harsha@akash.miel.mot.com); Thu, 19 Nov 1998 22:53:07 +0500 Received: from motgate2.mot.com ([129.188.136.102]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id LAA12137 for ; Thu, 19 Nov 1998 11:32:38 -0600 (CST) Received: from ursamajor.cisco.com (ursamajor.cisco.com [171.69.63.56]) by motgate2.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id LAA17978 for ; Thu, 19 Nov 1998 11:34:32 -0600 (CST) Received: from CASNER-ISDN1 ([171.70.119.74]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA21068; Thu, 19 Nov 1998 09:32:35 -0800 (PST) Comments: ( Received on motgate2.mot.com from client ursamajor.cisco.com, sender casner@cisco.com ) Date: Thu, 19 Nov 1998 09:33:26 -0800 (Pacific Standard Time) From: Stephen Casner To: Sriharsha J Cc: van@ee.lbl.gov Subject: Re: RTP/UDP/IP header compression In-Reply-To: <3653D8CD.2E19D7EC@miel.mot.com> Message-Id: X-X-Sender: casner@ursamajor.cisco.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 1. What is the initial sequence number set to ? (zero ?) Doesn't matter since the FULL_HEADER packet will cause that sequence number, whatever it is, to be stored in the decompressor's context. Zero is fine. > 2. When the synchronization is lost, what does the sequence # field of > the CONTEXT_STATE packet set to ? > If you have received packet (X-1) and expecting (X), you got (X+k). > Then do you send (X-1 or X) ? It should be the last valid sequence number, i.e., X-1. You are right that this point is not clear enough in the first paragraph of 3.3.5, although it might be inferred from the second paragraph on advisory CONTEXT_STATE packets. In a sense, again it doesn't matter because if the I bit is set to 1, the compressor must send a FULL_HEADER packet regardless of what the sequence number in the CONTEXT_STATE packet is, and the FULL_HEADER packet will cause the sequence number in the decompressor to be set explicitly. The new value that it gets set to will usually NOT be X because the compressor does not buffer packets. > 3. How does the Compressor detect duplicate CONTEXT_STATE packets ? > (through sequence # ?) They are duplicate if they are identical; that is, yes, if the sequence number is the same. Clearly, the same sequence number will be used again after 16 more data packets, so the compressor must take timing into account. If there are 16 packets in flight on the link, the compressor might not be sure about which packet was indicated. But that represents such a long delay that the performance of this protocol on such a link is not likely to be acceptable, so it should not be used. > In the above context, does generation number has any role or not ? The generation number has no role. -- Steve --------------6688C0834256F5151C9EE612-- --------------63FAD7033B4-- --------------243D1A546F8-- From rem-conf Mon Jan 04 06:01:58 1999 From rem-conf-request@es.net Mon Jan 04 06:01:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxAVx-0004PH-00; Mon, 4 Jan 1999 05:57:49 -0800 Received: from boa.crl.mcmaster.ca [130.113.224.130] (todd) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zxAVw-0004P6-00; Mon, 4 Jan 1999 05:57:48 -0800 Received: from localhost (todd@localhost) by boa.crl.mcmaster.ca (8.8.7/8.8.7) with ESMTP id IAA00050; Mon, 4 Jan 1999 08:59:18 -0500 X-Authentication-Warning: boa.crl.mcmaster.ca: todd owned process doing -bs Date: Mon, 4 Jan 1999 08:59:18 -0500 (EST) From: Terry Todd X-Sender: todd@boa.crl.mcmaster.ca To: itc@ieee.org, comsoc-chapters@ieee.org, multicomm@cc.bellcore.com, commsoft@cc.bellcore.com, sigmedia@bellcore.com, end2end-interest@isi.edu, tcgn@ieee.org, hipparch@sophia.inria.fr, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, ieeetcpc@listserv.utoronto.ca, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, rem-conf@es.net Subject: Announcement for ICNP'99, in Toronto, Canada Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS 7th IEEE INTERNATIONAL CONFERENCE on NETWORK PROTOCOLS Toronto, Canada October 31 - November 3, 1999 http://www.cs.columbia.edu/~hgs/edas/icnp99/ In just 6 years ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, implementation, and performance tuning. Protocol functions of interest include (but are not limited to) network access, switching, routing, flow and congestion control, multimedia transport, wireless protocols, support for mobility, multicast, network security, Web protocols and applications, electronic commerce, network management, interoperability, and internetworking. ICNP uses a single-track format which provides an intimate setting for discussion and debate. The conference is known for its high quality papers from the research communities of IEEE COMSOC, IEEE Computer Society, and ACM SIGCOMM. To be considered for acceptance, a submission should present a significant contribution in its topic area. Selected papers will be forwarded for "fast track" consideration to IEEE/ACM Transactions on Networking. ICNP also includes panel sessions in which experts in a specific area offer their observations and opinions about a current topic. ICNP'99 will be held in Toronto, whose name is a Huron Indian word meaning "place of meeting". Toronto is Canada's largest city, the capital of the province of Ontario, and one of the most exciting, vibrant, and progressive cities in the world! It's attractions are far too numerous to list. The United Nations has designated Toronto as the world's "most ethnically-diverse city". It has the world's tallest building, the CN Tower, is the third-largest theatre centre in the English-speaking world, and contains over 5,000 restaurants and eateries. Toronto is also a very safe city with many family attractions. Important Dates --------------- Paper Submission Deadline: May 3, 1999 Notification of Acceptance: August 2, 1999 Camera Ready Due: August 25, 1999 Tutorials: October 31, 1999 Conference: November 1-3, 1999 Submission Information ---------------------- Submissions will be made via email. Details of the procedure are given at the ICNP'99 web site: http://www.cs.columbia.edu/~hgs/edas/icnp99/ General Chair ------------- Johnny Wong, University of Waterloo jwwong@bcr.uwaterloo.ca Program Chairs -------------- Joe Bannister, USC Information Sciences Institute Email: joseph@isi.edu Terry Todd, McMaster University Email: todd@mcmaster.ca Tutorial Chair -------------- Kevin Almeroth, UC Santa Barbara Email: almeroth@cs.ucsb.edu Local Arrangements Chair ------------------------ Bart Domzy, Trent University ICNP Steering Committee ----------------------- Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs ICNP is sponsored by the IEEE Computer Society From rem-conf Mon Jan 04 09:33:41 1999 From rem-conf-request@es.net Mon Jan 04 09:33:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxDjG-00079b-00; Mon, 4 Jan 1999 09:23:46 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxDjD-00079R-00; Mon, 4 Jan 1999 09:23:45 -0800 Received: from lynn.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Jan 1999 17:23:08 +0000 To: SKYSHOP OFFICE SUPPLIES cc: rem-conf , P.Kirstein@cs.ucl.ac.uk Subject: SP In-reply-to: Your message of "Tue, 29 Dec 1998 11:49:08 PST." <419.436158.61900648skyshop@excite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1239.915470586.1@cs.ucl.ac.uk> Date: Mon, 04 Jan 1999 17:23:07 +0100 Message-ID: <1240.915470587@cs.ucl.ac.uk> From: Peter KIRSTEIN X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <419.436158.61900648skyshop@excite.com>you write: >Are you paying to much for office supplies? Skyshop CAN save you money. > >If you would like to see our product line & website please email us back in th >e subject >line of the below email address and place the letters (SP) >Thank you! > skyshop@gte.net >Skyshop Office Supplies "We CAN save you MONEY & TIME" !! > > >To be removed from our list please place the word remove and no further email >will >be sent to you at this mailing skyshop@gte.net > > Peter X*********************************************************************X * Prof Peter Kirstein Telephone: +44 171 380 7286 * Department of Computer Science Fax: +44 171 387 1397 * University College London Telex: 28722 * Gower Street Internet: kirstein@cs.ucl.ac.uk * London * WC1E 6BT * U.K URL : http://www.cs.ucl.ac.uk/staff/kirstein X*********************************************************************X From rem-conf Mon Jan 04 14:46:52 1999 From rem-conf-request@es.net Mon Jan 04 14:46:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxIge-0002mj-00; Mon, 4 Jan 1999 14:41:24 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zxIgd-0002mU-00; Mon, 4 Jan 1999 14:41:23 -0800 Received: from casner-pc1.cisco.com (casner-pc1.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 OAA15506; Mon, 4 Jan 1999 14:40:13 -0800 (PST) Date: Mon, 4 Jan 1999 14:42:54 -0800 (Pacific Standard Time) From: Stephen Casner To: Geevarghese John cc: van@ee.lbl.gov, rem-conf@es.net Subject: Re: RTP/UDP/IP header compression In-Reply-To: <3690B2D0.75D6@miel.mot.com> Message-ID: X-X-Sender: casner@ursamajor.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 Mon, 4 Jan 1999, Geevarghese John wrote: > In the Internet Draft - IP Header Compression over PPP, > assigned numbers for RTP/UDP/IP header compression packets are > given (COMPRESSED_RTP, COMPRESSED_UDP, CONTEXT_STATE, etc) . > > Could any of you tell me what are the assigned numbers for rfc1294 > encapsulation over Frame Relay ? > > What about X25 link ? To my knowledge, no assignments have been made for Frame Relay or X25 link layers. Some link layers may inherit assignments from PPP, but for those that don't, it will be necessary to get assignments from the appropriate authorities in order to use CRTP. If it is not feasible to get multiple assignments for some link layer, one could define a multiplexing octet along the lines of what is in Section 13 of draft-degermark-ipv6-hc-08.txt. -- Steve From rem-conf Tue Jan 05 00:23:48 1999 From rem-conf-request@es.net Tue Jan 05 00:23:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxRaO-0006m7-00; Tue, 5 Jan 1999 00:11:32 -0800 Received: from alpha.xerox.com [13.1.64.93] (firewall-user) by mail1.es.net with smtp (Exim 1.81 #2) id 0zxRaM-0006lx-00; Tue, 5 Jan 1999 00:11:30 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <54676(1)>; Tue, 5 Jan 1999 00:11:23 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177534>; Tue, 5 Jan 1999 00:11:11 -0800 To: Yozo Toda cc: rem-conf@es.net Subject: Re: vic-2.8 problem. In-reply-to: Your message of "Tue, 22 Dec 98 19:09:40 PST." <199812230309.MAA16939@aohakobe.ipc.chiba-u.ac.jp> Date: Tue, 5 Jan 1999 00:11:05 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <99Jan5.001111pst.177534@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There are several memory leaks in vic-2.8 and vat-4.0 . The patches in the FreeBSD port system (http://www.freebsd.org/ports/mbone.html) fix the memory leaks and also allow building with tcl/tk 8.0 . I don't know if anyone is planning to do any more vic or vat releases. Bill From rem-conf Tue Jan 05 04:21:07 1999 From rem-conf-request@es.net Tue Jan 05 04:21:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxVMG-0000lZ-00; Tue, 5 Jan 1999 04:13:12 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxVMC-0000lO-00; Tue, 5 Jan 1999 04:13:09 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 5 Jan 1999 12:12:58 +0000 To: rem-conf@es.net Subject: Draft AVT minutes cc: casner@cisco.com Date: Tue, 05 Jan 1999 12:12:58 +0100 Message-ID: <1304.915538378@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The draft minutes from the AVT working group meeting in Orlando are enclosed. Due to the imminent submission deadline, I'd appreciate any comments on these as soon as possible. Colin ------------------------------------------------------------------------------- Minutes of the Audio/Video Transport Working Group Reported by Colin Perkins. The audio/video transport working group met twice at the 43rd IETF in Orlando. The main agenda items were discussion of RTP multiplexing, and the update of RTP and the audio/video profile for advancement to draft standard status. In addition, a number of RTP payload formats and the RTP MIB were discussed. The meeting opened with a review of the working group status, and documents completed since the last meeting. These include the payload formats for H.263+ video (RFC2429), BT.656 video (RFC2431) and JPEG video (RFC2435), together with AT&T's Error Resilient Video Transmission Technique (RFC2448). The RTP MIB (draft-ietf-avt-rtp-mib-03.txt) was presented by Mark Baugher. Changes since the previous draft have been motivated by comments and careful review by Bert Wijnen and the ITU SG16. The main differences are as follows: renamed MIB definitions to RTP-MB and module to RTPMIB; changed OID structure to current IETF conventions; several clarifications made to DESCRIPTION clauses; use "noSuchInstance" rather than "noSuchObject" in rtpRcvrRTT; changed media counters to be 64 bits; separated host and monitor compliance sections; and the use InterfaceIndexOrZero instead of redefining InterfaceIndex. There are a number of open issues with the use of multiple MIB agents in switches, the optional nature of the interface index and to permit easier selection of session entries by session address which have to be resolved, but it is expected that this will be complete within the next few weeks, at which time a new draft will be issued ready for working group last call. A reference implementation is available of the -02 draft, work is progressing on the latest version. The RTP MIB is now referenced in the ITU as H.341. The RTP payload format for DTMF and other telephone tones (draft-ietf-avt-dtmf-01.txt, draft-ietf-avt- tones-00.txt) was presented by Scott Petrack. The justification for using a new payload format is to reproduce the tones better than current, low rate, codecs; to apply redundancy differently for tones and speech; to separate detection of tones >from their interpretation; and to preserve the sounds associated with particular signals. Two payload formats are defined: a named signal event payload and a tone frequency format payload. The named signal event payload includes a named event (dialtone, busy, call-waiting, off-hook, etc), together with the volume and duration of that event. The tone frequency format sends a representation of the actual set of tones to be played, rather than either purpose (name), enabling a wider range of tones and the playout of foreign tones. Both formats may be conveyed in a single packet, using RFC2198 redundancy, for robustness. Mark Handley expressed some concern with the means by which this is done: in particular it is unclear how to playout these tones when a fraction of the tone is lost. The two drafts are to be merged within the next couple of months, and it is the desire of the authors to move the result to the standards track soon after. Some concern was expressed that this draft is not receiving sufficient exposure in bodies such as the ITU which may be able to provide relevant feedback - it must be ensured that these bodies have chance to comment before this document can progress in the IETF. The discussion of RTP multiplexing started with a presentation by Jonathan Rosenberg on issues in RTP multiplexing (draft-ietf-avt-muxissues-00.txt). As noted in this draft, there are two scenarios which are of interest: end-to-end and mid-network multiplexing. The scenario chosen will affect the choices made in designing the multiplexing scheme. These choices affect the delineation, identification, synchronisation and dynamism of the multiplexed data. There are three means by which data in a multiplexed packet may be delineated: by explicit length indicators (which have maximum flexibility but the largest overhead); implicitly based on payload type (many codecs are fixed length blocks); or implicitly by out of band signalling (which has the least bandwidth overhead, but requires signalling and makes changing encodings or packetisation difficult). If all multiplexed packets are of the same duration this problem becomes much simpler. Multiplexed data may be identified by an explicit ID, where the number of bits used depends on the number of simultaneous calls and the desired ID reuse latency. This ID may be the RTP SSRC in some cases. Alternatively the data may be channelised, where each user's data gets a slot in the packet. This latter approach requires out-of-band signalling and, of silence suppression is used, a bitmask to indicate which channels are active. The overheads of the two schemes vary with the number of channels being multiplexed, whether channels are active continually, and with the rate of change of the set of multiplexed streams. If each frame of multiplexed data within a packet has the same timestamp, the individual timestamps may be elided, and replaced by the single timestamp in the multiplexed packet's RTP header. If the timestamps are close, offsets relative to the outer timestamp may be used rather than complete timestamps (saving some number of bits). Alternatively if users have uncorrelated frame start times it is necessary to send the complete timestamp per user. The dynamism of codecs also affects the multiplexing format chosen. If codecs never change there is no need to include payload type indication within the multiplexed stream, and out of band signalling may be used. Similarly, of codecs change rarely out of band signalling may be appropriate, depending on how often codecs may change (synchronisation between the signalling of a payload type change and the media stream may be complex). If codecs change frequently, some form of in-band payload type indication is most appropriate - this need not necessarily be a complete RTP PT value if the set of allowable codecs is small a mapping table may be used instead. The marker bit may need to be transmitted depending on the use of the multiplexed stream. It was noted that this is a very large space, and a number of solutions to the multiplexing problem are possible. This group has a number of solutions presented to it, yet the precise problem definition for each of these has not been enunciated. It may help to focus the discussion if the question "why are you multiplexing?" is clearly answered, and if we derive a number of scenarios which require common solutions. Essentially, we need to focus on requirements. trying to do generic optimisation using a multiplexer is futile. It was noted that there is some RTP compression and transport work being conducted in the ATM forum which may be relevant to this discussion. The first multiplexing proposal (an update to draft-ietf-avt-mux-rtp-00.txt) was presented by Barani Subbiah. The stated goals of this proposal are to achieve the best possible fit with cellular/PSTN applications and to derive a payload format suitable for use in a switched IP telephone network. They are aiming for a simple format with a fixed header suitable for hardware implementation, providing a compromise between bandwidth saving (in addition to the outer RTP header, this proposal averages two bytes overhead per multiplexed stream) and complexity. The sequence number (2 bits) is new since the last draft, this means a reduction in the length field size to 5 bits. Concern was expressed that a 5 bit length field is insufficient for some audio codecs which may be desirable. The use of the 2 bit sequence number was questioned, since 4 packet losses are possible -- a longer field should probably be used. A transition bit is included to signal a change in the end-to-end flow parameters, allowing one state change per RTT. It was noted that if all packets with an RTT are lost, the state change will not be noted at the receiver. IT was also noted that payloads such as DTMF interspersed with voice can cause change in payload type more often than once per RTT. Tohru Hoshi presented draft-tanigawa-rtp-multiplex-01.txt. This is a simple proposal where multiple RTP packets are concatenated for transmission in a single UDP packet. The default packetisation interval specified for a codec in the audio/video profile is used such that no length indication is necessary. The draft now includes a section describing the efficiency gains for using this proposal according to various metrics. Call setup signalling is also defined. The next multiplexing proposal discussed was GeRM (draft-ietf-avt-germ-00.txt), presented by Mark Handley. The goal of this proposal is to transparantely multiplex a number of RTP streams. It operates using difference coding between the headers of packets to be multiplexed together. Clearly this will work better if the packet headers are similar (this can be achieved between co-operating gateways, although the traffic pattern will affect performance) but it will still work if the end points do no co- operate, and will perform no worse than simply concatenating packets. The GeRM protocol is well suited for scenarios where a mix of RTP packets are to be multiplexed, such as may be encountered in the transport of MPEG-4 streams, or for use between a pair of cooperating gateways multiplexing a large number of similar streams. It achieves considerable flexibility, at the expense of complex parsing and greater bandwidth overhead than other, less general, protocols. The final multiplexing presentation was by Dean Willis (no draft exists). The assumptions here are that large numbers of streams are being carried between end-point pairs, fast interfaces with minimal serialisation delay are used, and mixed codecs with silence suppression exist. The goal is to increase overall "network efficiency" by re-packing packets to increase the total MTU and reduce the number of packets sent. Two alternatives were considered: - RTP level: complex, no benefit to non-RTP traffic, issues with RTCP - UDP level: brute force level simplicity, aggregate UDP flows between end-points, allows IPsec at multiplexing level, transparent to the application, allows mid-network multiplexing, less efficient The UDP level approach is favoured. Following the presentations a considerable amount of discussion ensued. Concern was expressed that multiplexing is being used as an "RTP switching" solution, with application level routing: it was noted that IP has a number of perfectly reasonable routing algorithms already, and it is unnecessary to re-invent these within RTP. Many people expressed concern that the problem to be solved by multiplexing has not been clearly stated: is it to reduce the number of packets sent? the number of bytes sent? to perform application level RTP routing? etc. It is unclear that RTP multiplexing is the correct solution here: a generic UDP multiplexing protocol (as in the final proposal) may be more suitable in some cases. Concern was expressed that multiplexing streams with different transport level addressing into one is not clearly handled by these proposals. In some cases, the SSRC is assumed to provide a unique stream ID, which is not necessarily the case across multiple streams. The handling of RTCP data by a number of these proposals is also unclear. Concern was expressed that these payload formats should be independent of the signalling to be used. We may want to express signalling requirements, but should not tie these protocols to a specific scheme. Since it is unclear whether a single protocol can satisfy both aims, and which of the five proposals currently submitted to the group will go forwards, the group decided to conduct more simulation and analysis of the proposals, in order to facilitate a fair comparison. The next subject was the transport of MPEG-4 streams within RTP. A number of AVT members participated in the MPEG meeting in Atlantic City in October, leading to the formation of an ad-hoc group within MPEG to discuss MPEG transport using IP. The work conducted in that group to date was presented by Reha Civanlar. A number of alternatives for the transport of MPEG-4 streams in an IP network were considered: - directly on UDP - RTP followed by a full MPEG-4 SyncLayer packet - MPEG-4 SyncLayer packets mapped onto RTP packets - MPEG-4 elementary streams over RTP with natural payload formats The preferred approach would be to use the latter approach, but since the ES interface is not a normative part of MPEG-4 this is not possible. The approach chosen is, therefore, to map the MPEG-4 SyncLayer packets onto RTP packets, such that the common pieces of the header reside in the RTP header, with a small payload header providing the MPEG-4 specific features. A single payload format is therefore used for MPEG-4 streams transported within RTP, and the MPEG-4 model is maintained (although not the precise packet format). In this approach, an RTP multiplexing scheme is needed to fulfill the role of FlexMux in MPEG-4. The GeRM proposal seems to be a good fit for this. An internet draft detailing this work is in preparation. Those who wish to participate in this work are encouraged to join the ad-hoc group's mailing list: send email to 4onIP-sys-request@fzi.de in order to subscribe. Christine Guillemot presented an RTP generic payload with scalable and flexible error recovery (draft-guillemot-genrtp-00.txt). This draft takes a somewhat different view of the problem of transporting MPEG-4 content and is based on carrying elementary streams in a generic manner. The motivation for this is to transport many types of stream whilst avoiding having to define a payload format for each and allowing finer control of error correction with a set of different FEC mechanisms and the possibility of grouping AUs in a single packet. One of the aims of this work are to factorize the common features instead of developing specific formats for each codec/type of elementary stream and to be able to identify repeated data so that the network adaptive layer can identify and remove this if desired. The adaption layer can add FEC to entire packets or to portions of a stream within packets (adding redundancy in a similar manner to RFC2198). Concern was expressed that adding FEC to portions of a packet adds a lot of extra complexity, and unless this FEC is much smaller than that which would otherwise be present this complexity may not be justified. Some concern was expressed that this document includes a number of payload formats (redundancy, FEC, fragmentation and grouping) which may be better separated. This clearly depends on the details of the stream which is being packetised. It is unclear that this format is suitable as a generic RTP payload, however it may work well as a general purpose transport for MPEG-4 elementary streams. Steve Casner described the changes made to the main RTP specification since the last meeting. This is now stable, and unless major problems are found is believed ready for last-call for draft standard. The changes since the last meeting are described in draft-ietf-avt-rtp-new-02.txt and include: - SSRC sampling moved to separate draft (ietf-avt-rtpsample-01.txt) - Keep only unconditional reconsideration - Add IANA considerations section added; no longer suggest experimental registration of values - Y2036 (in)consequences explained - convert to MUST, SHOULD, MAY A plea was made for help checking: - Section 0: resolution of open issues - Section 6.2: RTCP transmission interval - Section 6.3: RTCP send and receive rules - Appendix A: does the code work? - Appendix B: changes from rfc1889 It was noted that the group must document "at least two independent and inter-operable implementations from different code bases" of "all of the options and features of the specification" in order to advance to draft standard status (RFC2026). Colin Perkins volunteered to produce a draft detailing those options and features as a checklist for vendors to check compliance, and Jonathan Rosenberg volunteered to produce a draft detailing tests for the timer reconsideration algorithms. The changes to the RTP profile (draft-ietf-avt-profile-new-04.txt) since the last meeting are less advanced: a clearer statement of the new policy of no more static assignments, and the addition of change bars. It is still necessary to complete the update with MUST, SHOULD, MAY, etc and to add text to allow default of 5% RTP bandwidth to be overridden. The registration of RTP payload format names as MIME types is still not complete: Philipe Hoscha volunteered to work on this, and to work out the details of the process. It is hoped that this may just be a statement we can put in the profile to specify how the registration is done, without changing the MIME registration process, but this is not yet clear. Steve Casner presented work on some new RTCP SDES items for Peter Parnes, who was unable to be present (draft-parnes-rtp-sdes-00.txt). These items include nickname, homepage, personal image, active media, (suggested earlier: organisation). Concern was expressed about the inclusion of URLs in an SDES packet which may be sent to a large multicast group, since simultaneous retrieval of these by many receivers can cause implosion problems. Some form of random backoff algorithm must be specified (as is done in this draft). Concern was expressed that we shouldn't try to turn RTCP into a general data transfer mechanism. The consensus of the group was that additional information to be carried in RTCP must be optional, and should not affect the operation of the application, and that an RFC must be present defining the new RTCP packets, and giving an applicability statement for each. No additional packet types will be added to the main RTP specification. The SSRC sampling algorithms (draft-ietf-avt-rtpsample-01.txt) were presented by Jonathan Rosenberg. These have been moved out of the main RTP specification because of the IPR issues (Lucent patent on the binning algorithm). The changes to this document are: - Uniformity of SSRC values usage: recommend hashing SSRC value, because some broken implementations doesn't choose uniformly distributed SSRC values - New section on performance of sampling in terms of coefficient variation added - An explicit statement of the IPR issues and licensing terms needs to be added Comments are requested. The document giving guidelines for writers of RTP payload formats (draft-ietf-avt-rtp-format-guidelines-01.txt) was noted as being essentially complete. One more revision will be produced to include the final round of comment, before last call for BCP status. Comments are sought as soon as possible. The payload format for PureVoice(TM) audio (draft-mckay-qcelp-01.txt) was noted as being in working group last call still, pending resolution of a number of open issues with the encryption of the payload data in a non-standard manner. The Generic FEC payload (draft-ietf-avt-fec-04.txt) was presented by Jonathan Rosenberg. Changes include the removal of Reed-Solomon coding (to a separate draft) and mask extension. The examples and code have been tested and bug-fixed, and the issues with encryption during key changes have been resolved. This document is essentially ready for last call as proposed standard - will do one more revision to get the MUST, SHOULDs, etc sorted. Comments are sought. The Reed-Solomon draft (draft-ietf-avt-reedsolomon-00.txt) was also presented by Jonathan Rosenberg. Help is required with this: if anyone is interested in seeing this work progress they should contact Jonathan, else the draft will not be updated. A proposal to use the RFC2198 redundancy format as a transport for interleaved audio (draft-ietf-avt-interleaving-00.txt) was presented by Colin Perkins. This may eventually be merged into that document, although this is at present undecided. Comments are sought. The meeting concluded with a brief presentation on the proposed charter revision. It was noted that this needs clarification regarding MPEG-4 payload formats, but is otherwise satisfactory. The revised charter will be sent for IESG approval in the near future. ------------------------------------------------------------------------------- From rem-conf Tue Jan 05 08:46:12 1999 From rem-conf-request@es.net Tue Jan 05 08:46:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxZVQ-0004GJ-00; Tue, 5 Jan 1999 08:38:56 -0800 Received: from (alpha.telecom-co.net) [200.21.27.100] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxZVO-0004G1-00; Tue, 5 Jan 1999 08:38:55 -0800 Received: by alpha.telecom-co.net; id AA07900; Tue, 5 Jan 1999 11:37:51 -0500 Message-Id: <36923FCC.566C3F48@alpha.telecom-co.net> Date: Tue, 05 Jan 1999 11:37:36 -0500 From: Carlos Eduardo Silva =?iso-8859-1?Q?Mart=EDnez?= Organization: Telecom X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: rem-conf@es.net Subject: Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I want to know what are the most important features that must be tested on a videoconference system (sony 5100), and how do it. From rem-conf Tue Jan 05 20:11:19 1999 From rem-conf-request@es.net Tue Jan 05 20:11:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxkFH-0002ds-00; Tue, 5 Jan 1999 20:06:59 -0800 Received: from pppa33-resalereno1-1r1045.saturn.bbn.com (4.16.90.44) [4.16.90.44] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxkFC-0002dE-00; Tue, 5 Jan 1999 20:06:55 -0800 From: obino@geocities.com To: You@es.net Subject: SERVICE:Your Web SIte Ranking! X-Reply-To: obino@geocities.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 5 Jan 1999 20:06:55 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ******************************************************* IMPORTANT! Read! - We acquired your email address from your website, we thought you may be interested in marketing your site more efficiently on the internet, If this was an error on our part PLEASE let us know by sending a reply to this email with REMOVE in the subject line, we keep track of all removes we get and you will not be mailed again. -- Thank you! Now for the good information! ******************************************************* Hi, I was just searching on AltaVista with the key word(s) "video" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! NO BULL. for more info about what we do see our website at:www.geocities.com/ Hi, I was just searching on AltaVista with the key words "computer printers" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! Try us out you have nothing to lose! for more info about what we do see our website at: http://www.geocities.com/RodeoDrive/Outlet/4974/index.html or email me at: obino@geocities.com From rem-conf Tue Jan 05 20:26:18 1999 From rem-conf-request@es.net Tue Jan 05 20:26:16 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zxkVN-0005TM-00; Tue, 5 Jan 1999 20:23:37 -0800 Received: from pppa18-resalereno1-1r1045.saturn.bbn.com ([4.16.90.29] helo=4.16.90.29) by mail2.es.net with smtp (Exim 1.92 #1) id 0zxkVJ-0005Sz-00; Tue, 5 Jan 1999 20:23:34 -0800 From: obino@geocities.com To: You@es.net Subject: SERVICE:Your Web SIte Ranking! X-Reply-To: obino@geocities.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 5 Jan 1999 20:23:34 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ******************************************************* IMPORTANT! Read! - We acquired your email address from your website, we thought you may be interested in marketing your site more efficiently on the internet, If this was an error on our part PLEASE let us know by sending a reply to this email with GET ME OFF, in the subject line, we keep track of all removes we get and you will not be mailed again. -- Thank you! Now for the good information! ******************************************************* Hi, I was just searching on AltaVista with the key word(s) "video" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! NO BULL. for more info about what we do see our website at:www.geocities.com/ Hi, I was just searching on AltaVista with the key words "computer printers" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! Try us out you have nothing to lose! for more info about what we do see our website at: http://www.geocities.com/RodeoDrive/Outlet/4974/index.html or email me at: obino@geocities.com From rem-conf Tue Jan 05 20:44:41 1999 From rem-conf-request@es.net Tue Jan 05 20:44:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxknU-0003iQ-00; Tue, 5 Jan 1999 20:42:20 -0800 Received: from pppa33-resalereno1-1r1045.saturn.bbn.com (4.16.90.44) [4.16.90.44] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxkmu-0003ef-00; Tue, 5 Jan 1999 20:41:45 -0800 From: obino@geocities.com To: You@es.net Subject: AD: Your Website Ranking X-Reply-To: obino@geocities.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 5 Jan 1999 20:41:45 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ******************************************************* IMPORTANT! Read! - We acquired your email address from your website, we thought you may be interested in marketing your site more efficiently on the internet, If this was an error on our part PLEASE let us know by sending a reply to this email with GET ME OFF, in the subject line, we keep track of all removes we get and you will not be mailed again. -- Thank you! Now for the good information! ******************************************************* Hi, I was just searching on AltaVista with the key word(s) "video" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! NO BULL. for more info about what we do see our website at:www.geocities.com/ Hi, I was just searching on AltaVista with the key words "computer printers" and I see your website does not come up in the top 10 listings. when someone queries the AltaVista search engine for a keyword related to your site's products or services, does your page appear in the top 10 matches, or does your competition? If you're listed but not within the first two or three pages of results, you lose, no matter how many engines you submitted your site to. A top 10 ranking in a major search engine like AltaVista will often generate more targeted traffic than an expensive banner advertising campaign - and, a good search engine position is like highly targeted advertising that is both FREE, and effective! Over 90% of the search engine traffic to most Web sites comes from 8 to 10 major search engines from there first THREE PAGES! Therefore, it is VERY important that your site comes up in the top 10 results. "After we used AstaLavista, our online sales went from a few thousand to over $75 thousand in one month from the time we signed up with them, (AstaLavista) we are now dominating the searches people make for our products". -One of our Customers (identity not reveled for security). We can get your page top 10 GUARANTEED!!! Try us out you have nothing to lose! for more info about what we do see our website at: http://www.geocities.com/RodeoDrive/Outlet/4974/index.html or email me at: obino@geocities.com From rem-conf Wed Jan 06 02:32:34 1999 From rem-conf-request@es.net Wed Jan 06 02:32:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zxq6g-0006FR-00; Wed, 6 Jan 1999 02:22:30 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zxq6e-0006FH-00; Wed, 6 Jan 1999 02:22:28 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Jan 1999 10:22:12 +0000 To: minutes@ietf.org Subject: AVT minutes from the Orlando meeting cc: rem-conf@es.net Date: Wed, 06 Jan 1999 10:22:12 +0100 Message-ID: <1136.915618132@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed is the final version of the AVT minutes from the Orlando IETF meeting. Copies of the presentation slides and these minutes may also be found at http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/ Colin ------------------------------------------------------------------------------- Minutes of the Audio/Video Transport Working Group Reported by Colin Perkins. The audio/video transport working group met twice at the 43rd IETF in Orlando. The main agenda items were discussion of RTP multiplexing, and the update of RTP and the audio/video profile for advancement to draft standard status. In addition, a number of RTP payload formats and the RTP MIB were discussed. The meeting opened with a review of the working group status, and documents completed since the last meeting. These include the payload formats for H.263+ video (RFC2429), BT.656 video (RFC2431) and JPEG video (RFC2435), together with AT&T's Error Resilient Video Transmission Technique (RFC2448). The RTP MIB (draft-ietf-avt-rtp-mib-03.txt) was presented by Mark Baugher. Changes since the previous draft have been motivated by comments and review by Bert Wijnen and the ITU SG16. The main differences are as follows: renamed MIB definitions to RTP-MIB and module to RTPMIB; changed OID structure to current IETF conventions; several clarifications made to DESCRIPTION clauses; use "noSuchInstance" rather than "noSuchObject" in rtpRcvrRTT; changed media counters to be 64 bits; separated host and monitor compliance sections; and the use InterfaceIndexOrZero instead of redefining InterfaceIndex. There are a number of open issues with the use of multiple MIB agents in switches, the optional nature of the interface index and to permit easier selection of session entries by session address which have to be resolved, but it is expected that this will be complete within the next few weeks, at which time a new draft will be issued ready for working group last call. A reference implementation is available of the -02 draft, work is progressing on the latest version. The RTP MIB will be referenced by H.341, the ITU's H-series management specification. The RTP payload format for DTMF and other telephone tones (draft-ietf-avt-dtmf-01.txt, draft-ietf-avt-tones-00.txt) was presented by Scott Petrack. The justification for using a new payload format is to reproduce the tones better than low-rate codecs can do; to apply redundancy differently for tones and speech; to separate detection of tones >from their interpretation; and to preserve the sounds associated with particular signals. Two payload formats are defined: a named signal event payload and a tone frequency format payload. The named signal event payload includes a named event (dialtone, busy, call-waiting, off-hook, etc), together with the volume and duration of that event. The tone frequency format sends a representation of the actual set of tones to be played, rather than their purpose (name), enabling a wider range of tones and the playout of foreign tones. Both formats may be conveyed in a single packet, using RFC2198 redundancy, for robustness. Mark Handley expressed some concern with the means by which this is done: in particular it is unclear how to playout these tones when a fraction of the tone is lost. The two drafts are to be merged within the next couple of months, and it is the desire of the authors to move the result to the standards track soon after. Some concern was expressed that this draft is not receiving sufficient exposure in bodies such as the ITU which may be able to provide relevant feedback - it must be ensured that these bodies have a chance to comment before this document can progress in the IETF. The discussion of RTP multiplexing started with a presentation by Jonathan Rosenberg on issues in RTP multiplexing (draft-ietf-avt-muxissues-00.txt). As noted in this draft, there are two scenarios which are of interest: end-to-end and mid-network multiplexing. The scenario chosen will affect the choices made in designing the multiplexing scheme. These choices affect the delineation, identification, synchronisation and dynamism of the multiplexed data. There are three means by which data in a multiplexed packet may be delineated: by explicit length indicators (which have maximum flexibility but the largest overhead); implicitly based on payload type (many codecs are fixed length blocks); or implicitly by out of band signalling (which has the least bandwidth overhead, but requires signalling and makes changing encodings or packetisation difficult). If all multiplexed packets are of the same duration this problem becomes much simpler. Multiplexed data may be identified by an explicit ID, where the number of bits used depends on the number of simultaneous calls and the desired ID reuse latency. This ID may be the RTP SSRC in some cases. Alternatively the data may be channelised, where each user's data gets a slot in the packet. This latter approach requires out-of-band signalling and, of silence suppression is used, a bitmask to indicate which channels are active. The overheads of the two schemes vary with the number of channels being multiplexed, whether channels are active continually, and with the rate of change of the set of multiplexed streams. If each frame of multiplexed data within a packet has the same timestamp, the individual timestamps may be elided, and replaced by the single timestamp in the multiplexed packet's RTP header. If the timestamps are close, offsets relative to the outer timestamp may be used rather than complete timestamps (saving some number of bits). Alternatively if users have uncorrelated frame start times it is necessary to send the complete timestamp per user. The dynamism of codecs also affects the multiplexing format chosen. If codecs never change there is no need to include a payload type indication within the multiplexed stream, and out of band signalling may be used. Similarly, as codecs change rarely, out of band signalling may still be appropriate, depending on how often codecs may change (synchronisation between the signalling of a payload type change and the media stream may be complex). If codecs change frequently, some form of in-band payload type indication is most appropriate - this need not necessarily be a complete RTP PT value if the set of allowable codecs is small a mapping table may be used instead. The marker bit may need to be transmitted depending on the use of the multiplexed stream. It was noted that this is a very large space, and a number of solutions to the multiplexing problem are possible. This group has a number of solutions presented to it, yet the precise problem definition for each of these has not been enunciated. It may help to focus the discussion if the question "why are you multiplexing?" is clearly answered, and if we derive a number of scenarios which require common solutions. Essentially, we need to focus on requirements. Trying to do generic optimisation using a multiplexer is futile. The first multiplexing proposal (an update to draft-ietf-avt-mux-rtp-00.txt) was presented by Barani Subbiah. The stated goals of this proposal are to achieve the best possible fit with cellular/PSTN applications and to derive a payload format suitable for use in a switched IP telephone network. They are aiming for a simple format with a fixed header suitable for hardware implementation, providing a compromise between bandwidth saving (in addition to the outer RTP header, this proposal averages two bytes overhead per multiplexed stream) and complexity. The sequence number (2 bits) is new since the last draft, this means a reduction in the length field size to 5 bits. Concern was expressed that a 5 bit length field is insufficient for some audio codecs which may be desirable. The use of the 2 bit sequence number was questioned, since 4 packet losses are possible -- a longer field should probably be used. A transition bit is included to signal a change in the end-to-end flow parameters, allowing one state change per RTT. It was noted that if all packets with an RTT are lost, the state change will not be noted at the receiver. It was also noted that payloads such as DTMF interspersed with voice can cause change in payload type more often than once per RTT. Tohru Hoshi presented draft-tanigawa-rtp-multiplex-01.txt. This is a simple proposal where multiple RTP packets are concatenated for transmission in a single UDP packet. The default packetisation interval specified for a codec in the audio/video profile is used such that no length indication is necessary (or can be signalled out-of-band, if a non-default interval is desired). The draft now includes a section describing the efficiency gains for using this proposal according to various metrics. Call setup signalling is also defined. The next multiplexing proposal discussed was GeRM (draft-ietf-avt-germ-00.txt), presented by Mark Handley. The goal of this proposal is to transparently multiplex a number of RTP streams. It operates using difference coding between the headers of packets to be multiplexed together. Clearly this will work better if the packet headers are similar (this can be achieved between cooperating gateways, although the traffic pattern will affect performance) but it will still work if the end points do not cooperate, and will perform no worse than simply concatenating packets. The GeRM protocol is well suited for scenarios where a mix of RTP packets are to be multiplexed, such as may be encountered in the transport of MPEG-4 streams, or for use between a pair of cooperating gateways multiplexing a large number of similar streams. It achieves considerable flexibility, at the expense of complex parsing and greater bandwidth overhead than other, less general, protocols. The final multiplexing presentation was produced by Dean Willis during the meeting, so no draft exists. The assumptions here are that large numbers of streams are being carried between end-point pairs, fast interfaces with minimal serialisation delay are used, and mixed codecs with silence suppression exist. The goal is to increase overall "network efficiency" by re-packing packets to increase the total MTU and reduce the number of packets sent. Two alternatives were considered: - RTP level: complex, no benefit to non-RTP traffic, issues with RTCP - UDP level: brute force level simplicity, aggregate UDP flows between end-points, allows IPsec at multiplexing level, transparent to the application, allows mid-network multiplexing, less efficient The UDP level approach is favoured. Following the presentations a considerable amount of discussion ensued. Concern was expressed that multiplexing is being used as an "RTP switching" solution, with application level routing: it was noted that IP has a number of perfectly reasonable routing algorithms already, and it is unnecessary to re-invent these within RTP. Many people expressed concern that the problem to be solved by multiplexing has not been clearly stated: is it to reduce the number of packets sent? the number of bytes sent? to perform application level RTP routing? etc. It is unclear that RTP multiplexing is the correct solution here: a generic UDP multiplexing protocol (as in the final proposal) may be more suitable in some cases. Carsten Bormann succinctly stated that if we are to define an RTP multiplexing scheme, it should be an absolute requirement to preserve the integrity of the RTP information. If it does not, then it is not RTP multiplexing, it is a new protocol. Concern was expressed that multiplexing streams with different transport level addressing into one is not clearly handled by these proposals. In some cases, the SSRC is assumed to provide a unique stream ID, which is not necessarily the case across multiple streams. The handling of RTCP data by a number of these proposals is also unclear. The proposals need to be extended to address these issues. Some of the proposals specify a particular form of signalling in addition to the payload format. These payload formats should be independent of the signalling to be used. The proposals may want to express signalling requirements, but should not tie the payload format to a specific scheme. Since it is unclear whether a single protocol can satisfy multiple aims, and which of the five proposals currently submitted to the group will go forward, the authors and other working group participants are requested to submit application scenarios in which multiplexing is to be applied. Within those scenarios, assumptions about traffic can be made explicit. We'll choose three or four scenarios and ask the authors to simulation or analysis to quantify the performance of their proposals under those scenarios, in order to facilitate a fair comparison. The next subject was the transport of MPEG-4 streams within RTP. A number of AVT members participated in the MPEG meeting in Atlantic City in October, leading to the formation of an ad-hoc group within MPEG to discuss MPEG transport using IP. The work conducted in that group to date was presented by Reha Civanlar. A number of alternatives for the transport of MPEG-4 streams in an IP network were considered: - directly on UDP - RTP followed by a full MPEG-4 SyncLayer packet - MPEG-4 SyncLayer packets mapped onto RTP packets - MPEG-4 elementary streams over RTP with natural payload formats The preferred approach would be to use the latter approach, but since the ES interface is not a normative part of MPEG-4 this may not be feasible. The approach chosen is, therefore, to map the MPEG-4 SyncLayer packets onto RTP packets, such that the common pieces of the header reside in the RTP header, with a small payload header providing the MPEG-4 specific features. A single payload format is used for MPEG-4 streams transported within RTP, and the MPEG-4 model is maintained (although not the precise packet format). In this approach, an RTP multiplexing scheme is needed to fulfill the role of FlexMux in MPEG-4. The GeRM proposal seems to be a good fit for this. An internet draft detailing this work is in preparation. Those who wish to participate in this work are encouraged to join the ad-hoc group's mailing list: send email to 4onIP-sys-request@fzi.de in order to subscribe. Christine Guillemot presented an RTP generic payload with scalable and flexible error recovery (draft-guillemot-genrtp-00.txt). This draft takes a somewhat different view of the problem of transporting MPEG-4 content and is based on carrying elementary streams in a generic manner. The motivation for this is to transport many types of stream whilst avoiding having to define a payload format for each and allowing finer control of error correction with a set of different FEC mechanisms and the possibility of grouping AUs in a single packet. One of the aims of this work are to factorize the common features instead of developing specific formats for each codec/type of elementary stream and to be able to identify repeated data so that the network adaptive layer can identify and remove this if desired. The adaptation layer can add FEC to entire packets or to portions of a stream within packets (adding redundancy in a similar manner to RFC2198). Concern was expressed that adding FEC to portions of a packet adds a lot of extra complexity, and unless this FEC is much smaller than that which would otherwise be present this complexity may not be justified. Some concern was expressed that this document includes a number of payload formats (redundancy, FEC, fragmentation and grouping) which may be better separated. This clearly depends on the details of the stream which is being packetised. It is unclear that this format is suitable as a generic RTP payload independent of MPEG-4, however it may work well as a general purpose transport for MPEG-4 elementary streams. Steve Casner described the changes made to the main RTP specification since the last meeting. This is now stable, and unless major problems are found is believed ready for last-call for draft standard. The changes since the last meeting are described in draft-ietf-avt-rtp-new-02.txt and include: - SSRC sampling moved to separate draft (ietf-avt-rtpsample-01.txt) - Keep only unconditional reconsideration - Add IANA considerations section added; no longer suggest experimental registration of values - Y2036 (in)consequences explained - convert to MUST, SHOULD, MAY A plea was made for help checking: - Section 0: resolution of open issues - Section 6.2: RTCP transmission interval - Section 6.3: RTCP send and receive rules - Appendix A: does the code work? - Appendix B: changes from rfc1889 It was noted that the group must document "at least two independent and inter-operable implementations from different code bases" of "all of the options and features of the specification" in order to advance to draft standard status (RFC2026). Colin Perkins volunteered to produce a draft detailing those options and features as a checklist for vendors to check compliance, and Jonathan Rosenberg volunteered to produce a draft detailing tests for the timer reconsideration algorithms. Since the meeting, Jonathan has done a careful check of the code in Appendix A and found several problems to be fixed. The changes to the RTP profile (draft-ietf-avt-profile-new-04.txt) since the last meeting are less advanced: a clearer statement of the new policy of no more static assignments, and the addition of change bars. It is still necessary to complete the update with MUST, SHOULD, MAY, etc and to add text to allow default of 5% RTP bandwidth to be overridden. The registration of RTP payload format names as MIME types is still not complete: Philipp Hoschka volunteered to work on this, and to work out the details of the process. It is hoped that this may just be a statement we can put in the profile to specify how the registration is done, without changing the MIME registration process, but this is not yet clear. The working group has agreed in previous IETF meetings that any additional RTCP SDES items should be defined in separate RFCs rather than adding them to the base RTP spec. This is in part to minimize changes at the transition from Proposed to Draft Standard but also because we did not want implementors to infer that all applications should include all the SDES items. Accordingly, Peter Parnes has written draft-parnes-rtp-sdes-00.txt to propose the addition of new SDES items Nickname, Homepage, Personal_image and Active_media. Steve Casner presented this proposal since the author could not attend. This proposal is similar to the set of potential new SDES items discussed at the 41st IETF in Los Angeles, though Organisation was included previously and Active_media is new here. Comments are requested from the group as to whether this is the right set of new SDES items to define at this point, or whether some others should be added or some of these deleted. The status of this RFC would be Experimental rather than Proposed Standard. Steve Casner repeated a concern expressed previously that about the inclusion of URLs in an SDES packet which may be sent to a large multicast group, since simultaneous retrieval of these by many receivers can cause implosion problems. This draft specifies that retrieval should either be done only in response to direct user action or if automated should be delayed by a random interval (after receipt of the RTCP packet). Is this specification sufficient? Mark Handley asserted that we shouldn't try to turn RTCP into a general data transfer mechanism, but did favor adding Organization since current practice is to include that information in the Name item. The consensus of the group was that it was reasonable to make extensions to RTCP, but the additional information must be optional, and should not be required for operation of the application. Extension RFCs should include an applicability statement for each item. Further comments on this draft will be requested on the mailing list to establish consensus for proceeding. The SSRC sampling algorithms (draft-ietf-avt-rtpsample-01.txt) were presented by Jonathan Rosenberg. These have been moved out of the main RTP specification because of the IPR issues (Lucent patent on the binning algorithm). The changes to this document are: - Uniformity of SSRC values usage: recommend hashing SSRC value, because some broken implementations doesn't choose uniformly distributed SSRC values - New section on performance of sampling in terms of coefficient variation added - An explicit statement of the IPR issues and licensing terms needs to be added Comments are requested. The document giving guidelines for writers of RTP payload formats (draft-ietf-avt-rtp-format-guidelines-01.txt) was noted as being essentially complete. One more revision will be produced to include some comments recently received, so others wishing to make comments should do so as soon as possible. That revision will be last called for BCP status. The payload format for PureVoice(TM) audio (draft-mckay-qcelp-01.txt) was noted as being in working group last call still, pending resolution of a question regarding the proposed scheme for encryption of the payload data in a non-standard manner. A compromise solution has been worked out in offline discussions with the authors, so a revision of the draft is expected soon so last call can be completed if there are no further objections. The Generic FEC payload (draft-ietf-avt-fec-04.txt) was presented by Jonathan Rosenberg. Changes include the removal of Reed-Solomon coding (to a separate draft) and mask extension. The examples and code have been tested and bug-fixed, and the issues with encryption during key changes have been resolved. This document is essentially ready for last call as proposed standard - will do one more revision to get the MUST, SHOULDs, etc sorted. Comments are sought. The Reed-Solomon draft (draft-ietf-avt-reedsolomon-00.txt) was also presented by Jonathan Rosenberg. Help is required with this: if anyone having expertise on the Reed-Solomon algorithm is interested in seeing this work progress they should contact Jonathan, else the draft will not be updated. A proposal to use the RFC2198 redundancy format as a transport for interleaved audio (draft-ietf-avt-interleaving-00.txt) was presented by Colin Perkins. This may eventually be merged into that document, although this is at present undecided. Comments are sought. The meeting concluded with a brief presentation on the proposed charter revision. It was noted that this needs clarification regarding MPEG-4 payload formats, but is otherwise satisfactory. The revised charter will be sent for IESG approval in the near future. ------------------------------------------------------------------------------- From rem-conf Thu Jan 07 19:12:27 1999 From rem-conf-request@es.net Thu Jan 07 19:12:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zySB0-0001gL-00; Thu, 7 Jan 1999 19:01:30 -0800 Received: from igate.nuera.com (fargo.nuera.com) [204.216.240.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zySAz-0001gB-00; Thu, 7 Jan 1999 19:01:29 -0800 Received: from NUERALAPTOP_163 ([172.16.3.124]) by fargo.nuera.com with SMTP id TAA15326 (8.7.5/IDA-1.6); Thu, 7 Jan 1999 19:07:15 -0800 (PST) Message-ID: <01a501be3ab3$a5a9d3c0$7c0310ac@NUERALAPTOP_163.nuera.com> From: "Michael W. Fox" To: Cc: Subject: Re: draft-ietf-avt-tones-00.txt Date: Thu, 7 Jan 1999 19:04:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A2_01BE3A70.961661F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01A2_01BE3A70.961661F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the named events, specifically those used for call progress = indication, I think that it would be useful to turn a named indication = on for a long duration then turn it off sometime less than the duration = later. This is useful for something like ringback, where one can not = predict when the answer will occur. I apologize if this is in the draft, = or discussed in Orlando, and I missed it. Best Regards, Mike Fox ------=_NextPart_000_01A2_01BE3A70.961661F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Regarding the named events, specifically those used = for call=20 progress indication, I think that it would be useful to turn a named = indication=20 on for a long duration then turn it off sometime less than the duration = later.=20 This is useful for something like ringback, where one can not predict = when the=20 answer will occur. I apologize if this is in the draft, or discussed in = Orlando,=20 and I missed it.
 
Best Regards,
Mike Fox
------=_NextPart_000_01A2_01BE3A70.961661F0-- From rem-conf Fri Jan 08 09:17:52 1999 From rem-conf-request@es.net Fri Jan 08 09:17:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zyfQg-0007bm-00; Fri, 8 Jan 1999 09:10:34 -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 0zyfQf-0007bc-00; Fri, 8 Jan 1999 09:10:33 -0800 Received: from jester (dhcp204-101.stardust.com [205.184.204.101]) by ziggy.stardust.com (8.8.8/8.8.8/Debian/GNU/Stardust) with SMTP id JAA06297; Fri, 8 Jan 1999 09:10:31 -0800 Message-Id: <3.0.5.32.19990108090945.016dea90@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 08 Jan 1999 09:09:45 -0800 To: mbone@ISI.EDU, rem-conf@es.net From: Marty Bickford Subject: White Paper: Managing IP Multicast Traffic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hey Everyone, Kevin Almeroth has completed a white paper called "Managing IP Multicast Traffic". The paper is supplied by IPMI as a part of the 3rd Annual IP Multicast Summit on Feb 7-9, 1999 in San Jose, CA USA. It is available at: http://www.ipmulticast.com/events/summit99/ or http://www.ipmulticast.com/events/summit99/whitepaper.htm If you haven't registered with IPMI, you'll be asked to. Sincerely, Marty ____________________________________________________ Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com 3rd Annual IP Multicast Summit - Feb 7-9, 1999 http://www.ipmulticast.com/events/summit99/ From rem-conf Fri Jan 08 10:09:53 1999 From rem-conf-request@es.net Fri Jan 08 10:09:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zygIe-0000uz-00; Fri, 8 Jan 1999 10:06:20 -0800 Received: from www2.flightsim.com [207.77.58.227] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zygIc-0000up-00; Fri, 8 Jan 1999 10:06:18 -0800 Received: from [207.240.233.21] (01-005.012.popsite.net [207.240.233.5]) by www2.flightsim.com (8.8.5/8.8.5) with ESMTP id MAA14482; Fri, 8 Jan 1999 12:45:10 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) Date: Fri, 8 Jan 1999 11:30:00 -0400 To: Tempting Tear-Outs From: Tempting Tear-Outs Subject: >>>>>> L@@K! Amazing Free Offer!!! Unbelievable, but True! <<<<<<< 82 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To be removed from our mailing list, please send email to: temptingtearouts@1stconnect.com with the subject line of "remove." FOR MORE INFO: please "cut out" the below form on the "cut" lines shown, and fax it, for the fastest reply to: 1-718-227-9125 (this is a fax # in the USA) or send via smail (first class mail or airmail) to: Tempting Tear-Outs Att. Free-catalogue-by-email Dept 3835 Richmond Ave. Suite #200 Staten Island NY 10312-3828 USA SORRY, BUT.... our software is not set up to accept the below form via return email; WE CAN ONLY acknowledge forms sent in via fax or smail. --> IMPORTANT complete directions, to ensure that you get a reply, and more info follow, below the reply form and the catalogue options. *------------cut here/begin-------------------------------------------* Name (First Middle Last): Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Cellular (Mobile) Tel. #: Beeper (Pager) Tel. #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 010699-ls82-lafoubt-la Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY: 1. you must call from an "unblocked number," ie. one that is not blocked >from caller id. We are very sorry for this requirement, but our fax software requires this before it allows an incoming fax call to connect. If you have a blocked number, you must first unblock it. In most cases this means dialing *82 from a touch-tone phone (or 1182 from a rotary phone) before you dial 1-718-227-9125. NOTE: If you are not sure if your number is blocked, just try dialing our fax # normally. If you don't get a recording telling you your number is blocked, your number has been transmitted and you may press the start button on your fax when you hear the fax tone from our fax. 2. no reply forms can be accepted by email....only via fax or smail. 3. your form must be typewritten or printed out on your computer printer before you fax it; sorry, but *no* handwritten forms will be acknowledged. If you can't find someone with a typewriter or a computer printer, we apologize for not being able to reply to you. 4. faxes with cover pages will be rejected. You must send *only* the reply form. 5. forms not *completely* filled in will not be acknowledged. 6. you will receive a reply within 1 business day directly from the company making the offer via email. Therefore you must have an email address. If you read this message, then you must have an email address, or access to one, at least. :-) 7. your fax must not exceed 1 page in length. Faxes of 2 or more pages will be sensed, then auto-terminated and deleted. Your fax goes directly onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1 page. 8. all faxes must begin with: *------------cut here/begin-------------------------------------------* and must end with: *------------cut here/end--------------------------------------------* 9. Any fax not conforming to this format will be sensed by our software, then auto-terminated and deleted from the hard drive, before any human ever gets to see it. 10. The type on your fax must be dark and legible. If in doubt, please print it out darker before faxing it in. If we can't read it, we can't reply to you or send you our FREE catalogue. :-( 11. If this all seems too complicated for faxing, just do it the old fashioned way via smail!!! WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER: The company making the offer is a magazine subscription agency based in the USA. They have over 1,100 popular USA titles available to be shipped to *any* country, including of course, to anywhere in the USA! They offer a FREE 1 yr. subscription to your choice of over 200 of the titles in their catalogue to any new customer using them for the first time. The dollar value of the freebies, based on the subscription prices directly >from the publishers, ranges from $6.97 all the way up to $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,100+ titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly >from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas customers. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new customers who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the two formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa, American Express, Diner's Club and Carte Blanche. Overseas, they accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche, even if your credit card is a local one in local currency (that most merchants in the USA would not normally be willing to accept). That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on advertising rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, 3835 Richmond Ave. Suite #200, Staten Island NY 10312-3828, USA. From rem-conf Fri Jan 08 10:54:23 1999 From rem-conf-request@es.net Fri Jan 08 10:54:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zygyY-0002WQ-00; Fri, 8 Jan 1999 10:49:38 -0800 Received: from magic.ensica.fr (magic) [192.70.110.76] by mail1.es.net with smtp (Exim 1.81 #2) id 0zygyO-0002Vp-00; Fri, 8 Jan 1999 10:49:28 -0800 Received: (from idms99@localhost) by magic (940816.SGI.8.6.9/8.6.12) id EAA06342 for rem-conf@es.net; Sat, 9 Jan 1999 04:49:38 +0100 Date: Sat, 9 Jan 1999 04:49:38 +0100 From: Compte idms99 Message-Id: <199901090349.EAA06342@magic> To: rem-conf@es.net Subject: IDMS99 call for papers X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list C a l l f o r p a p e r IDMS'99 6th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 12-15 October 1999, Toulouse, France Organized by LAAS-CNRS and ENSICA http://www.ensica.fr/idms99 email : idms99@ensica.fr The Sixth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services will be held in 1999 at ENSICA, Toulouse, France. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their 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. Case studies and papers describing experimental work are especially welcome. 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 * Development tools for distributed multimedia applications * Distributed multimedia database systems * 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'99 will consist of a three day 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 form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings edited by Springer Verlag in the Lecture Notes in Computer Science series. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published 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. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'99 web page: http://www.ensica.fr/idms99/. Authors without web access may email to owe@laas.fr for requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to Dr Philippe Owezarski. Important Dates Submission due: March 8, 1999 Notification acceptance: April 30, 1999 Camera ready version: June 14, 1999 Workshop: October 12 - 15, 1999 Co-chairs: Michel Diaz, Philippe Owezarski, Patrick Sיnac LAAS-CNRS, 7 Avenue du Colonel Roche, 31077 Toulouse cedex 4, France e-mail: {diaz, owe}@laas.fr, Phone: +33 5 61 33 63 17, Fax: +33 5 61 33 64 11 ENSICA, 1 Place Emile Blouin, 31056 Toulouse cedex, France e-mail: senac@ensica.fr, Phone: +33 5 61 61 86 81, Fax: +33 5 61 61 86 86 Program Committee Chairmen: Michel Diaz, Philippe Owezarski Organization Chairman: Patrick Sיnac Tutorial Chairman: Laurent Dairaine Publicity and Demonstration Chairman: Pierre de Saqui-Sannes Conference electronic support Chairman: Marc Boyer Program Committee H. Affifi, ENST Bretagne, France P.D. Amer, U. Delaware, USA E. Biersack, Institut Eurיcom, France G. v. Bochmann, U. Ottawa, Canada B. Butscher, GMD FOKUS, Germany A.T. Campbell, Columbia U., USA T.S. Chua, U. Singapore, SG J.-P. Courtiat, LAAS-CNRS, France J. Crowcroft, UCL, UK L. Delgrossi, U. Piacenza, Italy C. Diot, Sprint ATL, USA R. Dssouli, U. Montrיal, Canada M. Dudet, CNET France Tיlיcom, France W. Effelsberg, U. Mannheim, Germany F. Eliassen, U. Tromsר, Norway S. Fdida, LIP6, France D. Ferrari, U. Piacenza, Italy V. Goebel, UNIK, Norway T. Helbig, Philips, Germany J.-P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK W. Kalfa, TU Chemnitz, Germany T.D.C. Little, Boston U., USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA G. Neufeld, UBC Vancouver, Canada B. Pehrson, KTH Stockholm, Sweden T. Plagemann, UNIK, Norway B. Plattner, ETH Zurich, Switzerland L.A. Rowe, U. California Berkeley, USA H. Scholten, U. Twente, Netherlands A. Seneviratne, UTS, Australia R. Steinmetz, GMD, Germany J.B. Stיfani, CNET France Tיlיcom, France L. Wolf, TU Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany From rem-conf Fri Jan 08 12:36:38 1999 From rem-conf-request@es.net Fri Jan 08 12:36:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zyiZs-0004AT-00; Fri, 8 Jan 1999 12:32:16 -0800 Received: from smtp.tcon.net (tcslip.tcon.net) [204.120.67.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zyiZr-0004AJ-00; Fri, 8 Jan 1999 12:32:15 -0800 Received: from Alfaroh.tcon.net (s26.pm1.tcon.net [204.120.67.46]) by tcslip.tcon.net (8.8.5/8.8.5) with SMTP id PAA10699; Fri, 8 Jan 1999 15:53:44 -0500 (EST) Date: Fri, 8 Jan 1999 15:53:44 -0500 (EST) From: To: Message-Id: <18161.236168.63074167 sales@gky.com.au> Subject: FROM THE DESKTOP OF MAY..... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I tried them all and lost money...Does that sound familiar? Well, guess what? I finally found a program that works!!! WAIT A MINUTE! Before you say, " here's another one " and want to delete this: I urge you to read this through! This is changing my life for the better and it certainly will do the same for you! ***** Visit our website at: http://www.topsecrets100.com ***** CODE:59441 ______________________ Pros Make You a Fortune. The # 1 Homebased Business for the 2nd year in a row. No selling, just refer people to the company'S 800 #. Commission checks paid weekly! It's simple and easy. $500 to $5000 (or more) monthly! A solid company that's a member of the Better Business Bureau and the United Chamber of Commerce. HAVE YOU EXPERIENCED THIS? The amount of money earned in your program is only a fraction related to the MASSIVE AMOUNTS OF TIME, ENERGY AND MONEY YOU PUT OUT! We all have, right? Why? " PEOPLE DO NOT LIKE TO SELL, NEVER HAVE AND NEVER WILL " MOST PEOPLE ARE NOT INTERESTED IN: #1. SELLING ANYTHING TO ANYONE! #2. FOLLOWING UP BY E-MAIL, SNAILMAIL, OR PHONE! #3. MONTHLY REQUIRED PURCHASES! #4. RECRUITING ON AND OFF THE NET! #5. MAKING PERSONAL CONTACT WITH OTHERS! #6. CONFERENCE CALLING! #7. MEETINGS! #8. FILLING OUT APPLICATIONS! #9. KEEPING AN INVENTORY! SO NOW WHAT? HOW CAN WE EVER BE SUCCESSFUL? HERES HOW:REFER people to this TOLL - FREE NUMBER (where Professional Telemarketers will PRESENT, INFORM, ENTERTAIN, AND DO whatever is necessary to SIGN UP YOUR PROSPECTS and place them in your downline for you!) That's all you do period! If you can do that (REFER PEOPLE TO THE 800 NUMBER, ON and or OFF the NET) you could be successful beyond your wildest dreams! YOU OWE IT TO YOURSELF TO GET THE WHOLE STORY: CALL: 8am - 10pm CST Monday - Saturday 1-800-811-2141 Code: 59441 or call 1-800-226-0633 Code: 59441 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code: 59441 or 1-785-762-2442 Code: 59441 HOW WELL DOES IT WORK? Here are just a few Toll - Free recorded testimonials from company members. Don't just take my word for it...call them for yourself! They are real people just like you and me! CALL NOW: THE CALLS ARE FREE! Steve Fletcher: 888-438-4005 Jill Dietch: 888-703-5389 Jim Montgomery: 888-446-6949 William Sounder: 888--446-6951 Henry Wheeler: 888-256-4767 Tim Russell: 888-731-3457 Live operators will be happy to explain the program to you and why it virtually GUARANTEES your success! EVERY ASPECT OF SELLING IS DONE COMPLETELY BY THE COMPANY and YOU GET PAID FOR IT! The company handles all your calls, closes your sales and sends you WEEKLY commission checks! You receive $100 EVERY TIME THE COMPANY CLOSES A SALE FOR YOU! PLUS you become eligible to receive the GUARANTEED LOWEST PRICE on over 250,000 Name Brand Products and Services you're already buying now, conveniently delivered to your front door! SAVE $200 on groceries, $300 on dining out and save hundreds more on THOUSANDS of name brand products and services! Merchandise, Travel, Health Care, Professional Services, Discounts on food and Entertainment and much more! The manufacture's Warrantee is automatically doubled when you make a purchase. DOUBLE THE DIFFERENCE MONEY - BACK GUARANTEE you will save money using our program or we will honor a FULL REFUND! Purchasing from among these 250,000 Name Brand super discounted products and services IS NOT MANDATORY. YOU DON'T HAVE TO BUY ANYTHING. You may contact people and refer them to the Toll - Free 800# any way you choose: Classifieds, flyers, postcards (supplied by the company - including pre - qualified names), Posting in appropriate newsgroups, Bulk e-mail etc. Suppose you use Bulk e-mail, which I find very successful: 100,000 e-mails with a 1/10 of a percent (0.1%) sales rate, nets, $1000...not to bad. Also, Top Secrets pays up to 60% in bonuses to infinity! The most lucrative infinity plan ever made. When you call, consider the professionalism of the live operators handling your call. I'm convinced you will not find a more highly motivated and well trained team of people to close your sales for you, and remember they are available 14 hours a day - 6 days a week ON YOUR BEHALF! CALL: 8am - 10 pm CST Monday - Saturday 1-800-811-2141 Code:59441 or call 1-800-226-0633 Code: 59441 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code:59441 or 1-785-762-2442 Code: 59441 Get your own CODE# from the friendly operators and I'll RACE YOU TO THE BANK! DON'T DELAY! MAKE THAT CALL! I promise you'll be glad you did! Hazel ********* Visit our website at: http://www.topsecrets100.com ********* Code: 59441 P.S. After you come on board give me a call at: 317-722-7707 From rem-conf Fri Jan 08 15:06:46 1999 From rem-conf-request@es.net Fri Jan 08 15:06:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zykvS-0005qM-00; Fri, 8 Jan 1999 15:02:42 -0800 Received: from smtp.tcon.net (tcslip.tcon.net) [204.120.67.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zykvR-0005qC-00; Fri, 8 Jan 1999 15:02:41 -0800 Received: from Alfaroh.tcon.net (s26.pm1.tcon.net [204.120.67.46]) by tcslip.tcon.net (8.8.5/8.8.5) with SMTP id SAA14923; Fri, 8 Jan 1999 18:24:52 -0500 (EST) Date: Fri, 8 Jan 1999 18:24:52 -0500 (EST) From: To: Message-Id: <18161.236168.73565382 sharon-isaiah43@worldnet.att.net> Subject: FROM THE DESKTOP OF AL...... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I tried them all and lost money...Does that sound familiar? Well, guess what? I finally found a program that works!!! WAIT A MINUTE! Before you say, " here's another one " and want to delete this: I urge you to read this through! This is changing my life for the better and it certainly will do the same for you! ***** Visit our website at: http://www.topsecrets100.com ***** CODE:46948 ______________________ Pros Make You a Fortune. The # 1 Homebased Business for the 2nd year in a row. No selling, just refer people to the company'S 800 #. Commission checks paid weekly! It's simple and easy. $500 to $5000 (or more) monthly! A solid company that's a member of the Better Business Bureau and the United Chamber of Commerce. HAVE YOU EXPERIENCED THIS? The amount of money earned in your program is only a fraction related to the MASSIVE AMOUNTS OF TIME, ENERGY AND MONEY YOU PUT OUT! We all have, right? Why? " PEOPLE DO NOT LIKE TO SELL, NEVER HAVE AND NEVER WILL " MOST PEOPLE ARE NOT INTERESTED IN: #1. SELLING ANYTHING TO ANYONE! #2. FOLLOWING UP BY E-MAIL, SNAILMAIL, OR PHONE! #3. MONTHLY REQUIRED PURCHASES! #4. RECRUITING ON AND OFF THE NET! #5. MAKING PERSONAL CONTACT WITH OTHERS! #6. CONFERENCE CALLING! #7. MEETINGS! #8. FILLING OUT APPLICATIONS! #9. KEEPING AN INVENTORY! SO NOW WHAT? HOW CAN WE EVER BE SUCCESSFUL? HERES HOW:REFER people to this TOLL - FREE NUMBER (where Professional Telemarketers will PRESENT, INFORM, ENTERTAIN, AND DO whatever is necessary to SIGN UP YOUR PROSPECTS and place them in your downline for you!) That's all you do period! If you can do that (REFER PEOPLE TO THE 800 NUMBER, ON and or OFF the NET) you could be successful beyond your wildest dreams! YOU OWE IT TO YOURSELF TO GET THE WHOLE STORY: CALL: 8am - 10pm CST Monday - Saturday 1-800-811-2141 Code: 46948 or call 1-800-226-0633 Code: 46948 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code: 46948or 1-785-762-2442 Code: 46948 HOW WELL DOES IT WORK? Here are just a few Toll - Free recorded testimonials from company members. Don't just take my word for it...call them for yourself. They are real people just like you and me! CALL NOW: THE CALLS ARE FREE! Steve Fletcher: 888-438-4005 Jill Dietch: 888-703-5389 Jim Montgomery: 888-446-6949 William Sounder: 888--446-6951 Henry Wheeler: 888-256-4767 Tim Russell: 888-731-3457 Live operators will be happy to explain the program to you and why it virtually GUARANTEES your success! EVERY ASPECT OF SELLING IS DONE COMPLETELY BY THE COMPANY and YOU GET PAID FOR IT! The company handles all your calls, closes your sales and sends you WEEKLY commission checks! You receive $100 EVERY TIME THE COMPANY CLOSES A SALE FOR YOU! PLUS you become eligible to receive the GUARANTEED LOWEST PRICE on over 250,000 Name Brand Products and Services you're already buying now, conveniently delivered to your front door! SAVE $200 on groceries, $300 on dining out and save hundreds more on THOUSANDS of name brand products and services! Merchandise, Travel, Health Care, Professional Services, Discounts on food and Entertainment and much more! The manufacture's Warrantee is automatically doubled when you make a purchase. DOUBLE THE DIFFERENCE MONEY - BACK GUARANTEE you will save money using our program or we will honor a FULL REFUND! Purchasing from among these 250,000 Name Brand super discounted products and services IS NOT MANDATORY. YOU DON'T HAVE TO BUY ANYTHING. You may contact people and refer them to the Toll - Free 800# any way you choose: Classifieds, flyers, postcards (supplied by the company - including pre - qualified names), Posting in appropriate newsgroups, Bulk e-mail etc. Suppose you use Bulk e-mail, which I find very successful: 100,000 e-mails with a 1/10 of a percent (0.1%) sales rate, nets, $1000...not to bad. Also, Top Secrets pays up to 60% in bonuses to infinity! The most lucrative infinity plan ever made. When you call, consider the professionalism of the live operators handling your call. I'm convinced you will not find a more highly motivated and well trained team of people to close your sales for you, and remember they are available 14 hours a day - 6 days a week ON YOUR BEHALF! CALL: 8am - 10 pm CST Monday - Saturday 1-800-811-2141 Code:46948 or call 1-800-226-0633 Code # 46948 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code:46948 or 1-785-762-2442 Code # 46948 Get your own CODE# from the friendly operators and I'll RACE YOU TO THE BANK! DON'T DELAY! MAKE THAT CALL! I promise you'll be glad you did! Al ********* Visit our website at: http://www.topsecrets100.com ********* Code: 46948 P.S. After you come on board leave me a message at: 317-722-7707 From rem-conf Sat Jan 09 10:13:42 1999 From rem-conf-request@es.net Sat Jan 09 10:13:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zz2jQ-0005bE-00; Sat, 9 Jan 1999 10:03:28 -0800 Received: from host-209-214-61-141.gso.bellsouth.net (localhost) [209.214.61.141] by mail1.es.net with smtp (Exim 1.81 #2) id 0zz2jN-0005au-00; Sat, 9 Jan 1999 10:03:25 -0800 From: Subject: ADV:CREDIT CARD PROCESSING Date: Sat, 9 Jan 1999 06:20:10 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ********************************************************* This message is being brought to you by World Teknologies To be removed from from further mailings respond to this message with "remove" in the subject line. ********************************************************* Dear Friend, Discover how you can accept credit cards directly >from your website, telephone or fax for your products and services and never need to purchase or lease expensive credit card equipment or pay a large monthly fee for online ordering capabilities or real time processing transactions. **Brand New** Inteli-Charge Credit Card acceptance program allows you to accept Visa, MastercardTM, Amex and Discover any TIME,any WHERE through phone, fax or internet without the need to purchase or lease expensive credit card equipment. This brand new program will allow you to accept credit cards in 24-48 hours after submitting your application. You simply pick up your telephone, dial a special toll free 800# 24 hrs a day 7 days a week, input a passcode and the credit card # and receive an immediate authorization over the phone. Within 2 days the money is deposited in your bank account. This is an exciting program for all businesses. Before you spend any money on a credit card merchant program LOOK at this new program! We have virtually a 100% approval for most business types regardless of past credit history! If you have an interest in learning more about a Merchant Account for yourself or your business please email your Name, PHONE NUMBER (Don't forget your area code) and best time to call to: mailto:cardacct@bellsouth.net A representative will return your call within 24hrs. Or feel free to call us on our 24 hour voicemail at: 1-800-600-0343 Ext:2104 P.S. ALSO AS PART OF A SPECIAL NATIONAL PROMOTION, IF YOU ACT NOW YOU WILL RECEIVE A FREE ONLINE STORE WITH SECURE ORDERING CAPABILITIES TO SELL YOUR PRODUCTS ONLINE! This offer only applies to U.S. Residents only and some Canadians World Teknologies Inc. 7210 Jordan Ave. Canoga Park Ca. 91303 From rem-conf Mon Jan 11 16:16:12 1999 From rem-conf-request@es.net Mon Jan 11 16:16:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zzrMc-0003j0-00; Mon, 11 Jan 1999 16:07:18 -0800 Received: from george.lbl.gov [131.243.2.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zzrMc-0003iq-00; Mon, 11 Jan 1999 16:07:18 -0800 Received: (from mperry@localhost) by george.lbl.gov (8.8.8/8.8.8) id QAA28202; Mon, 11 Jan 1999 16:06:26 -0800 (PST) Date: Mon, 11 Jan 1999 16:06:26 -0800 (PST) From: Marcia Perry (ITG staff) Message-Id: <199901120006.QAA28202@george.lbl.gov> To: DAAgarwal@lbl.gov, Jason_Sylvester@3com.com, Ksiple@home.com, MPerry@lbl.gov, M_Howard-Jeweler@lbl.gov, Rowe@BMRC.Berkeley.edu, bjorn@it.kth.se, cpmcparland@lbl.gov, ferenc@deepthought.EECS.Berkeley.EDU, ikeda@hike.te.chiba-u.ac.jp, itf@mcs.anl.gov, jam@mattheij.nl, jim.myers@pnl.gov, mbone@isi.edu, olson@mcs.anl.gov, philippe.galvez@cern.ch, rem-conf@es.net, roland@irdu.nus.edu.sg, toonen@mcs.anl.gov, van@ee.lbl.gov Subject: Multithreaded devserv X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, The Unix versions of devserv have been multithreaded (to eliminate polling for receiving data over network sockets and to speed up device startup/powering off). A multi- threaded Windows version is planned for a future release. The updated binaries and source packages are available at ftp://george.lbl.gov/mbone/devserv; please look for the packages that contain "v1.0" in their titles. Please let me know if there are any problems and feel free to email feedback at any time. Marcia Perry _____________________________________________________________ Lawrence Berkeley National Lab 1 Cyclotron Road Berkeley, CA 94720 MPerry@lbl.gov Work Phone: (510) 486-6786 FAX #: (510) 486-6363 MS: 50B-2239 From rem-conf Tue Jan 12 02:17:09 1999 From rem-conf-request@es.net Tue Jan 12 02:17:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1000nF-00003k-00; Tue, 12 Jan 1999 02:11:25 -0800 Received: from pi4.informatik.uni-mannheim.de [134.155.48.125] (-2146555104) by mail1.es.net with esmtp (Exim 1.81 #2) id 1000nC-00003a-00; Tue, 12 Jan 1999 02:11:22 -0800 Received: from localhost (cjk@localhost) by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with SMTP id LAA19829; Tue, 12 Jan 1999 11:11:19 +0100 (MET) Date: Tue, 12 Jan 1999 11:11:19 +0100 (MET) From: Christoph Kuhmuench X-Sender: cjk@pi4 To: rem-conf@es.net cc: Gerald Kuehne Subject: Payload for MPEG 4 ES stream? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, we have got some questions concerning the AVT minutes: > A number of alternatives for the transport of MPEG-4 streams in an IP > network were considered: > - directly on UDP > - RTP followed by a full MPEG-4 SyncLayer packet > - MPEG-4 SyncLayer packets mapped onto RTP packets > - MPEG-4 elementary streams over RTP with natural payload > formats > The preferred approach would be to use the latter approach, but since > the ES interface is not a normative part of MPEG-4 this is not possible. > > The approach chosen is, therefore, to map the MPEG-4 SyncLayer packets > onto RTP packets, such that the common pieces of the header reside in > the RTP header, with a small payload header providing the MPEG-4 > specific features. A single payload format is therefore used for MPEG-4 > streams transported within RTP, and the MPEG-4 model is maintained > (although not the precise packet format). Are there any ideas for compensating paket loss in the RTP/SL paket scenario? Due to the lack of specific information about the media type in the paket, the receiver can not easily recover from paket loss by using RTP header information. Therefore, wouldn't it be useful to define at least some MPEG-4 ES payloads for use in applications that do not use all features of MPEG-4. Is there any work in progress or is the RTP payload for MPEG-4 SyncLayer pakets the way to go? Bye Gerald Kuehne Christoph Kuhmuench From rem-conf Tue Jan 12 07:14:32 1999 From rem-conf-request@es.net Tue Jan 12 07:14:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1005Qr-0002mX-00; Tue, 12 Jan 1999 07:08:37 -0800 Received: from 1cust108.tnt1.sylva.nc.da.uu.net (JOKES-4-U) [208.254.171.108] by mail1.es.net with smtp (Exim 1.81 #2) id 1005Qo-0002mM-00; Tue, 12 Jan 1999 07:08:35 -0800 From: JOKEFARM To: Message-Id: <419.436172.42554028url-jokefarm@usa.net> Subject: FREE PG13 JOKES DAILY-- JOIN OUR MAILING LIST IT'S FREE FREE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 12 Jan 1999 07:08:35 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JOKE FARMS =6 JOKES a week for FREE-FREE-FREE-FREE ************************************************************************************************* We do place URL's in each mornings mailing if you wish to have your's added just let us know at URL-JOKEFARM-DATA@USA.NET for more info with(URL) in the SUBJECT LINE. To PLACE a URL the cost is $15.00 per week for BUSINESS PAGES & $6.OO FOR HOMEPAGES For more information ask us at the above address on how to add your URL.***************************************************** ********************************************************************************************* NO PORNOGRAPHIC SITES OR MAILINGS, JUST GREAT CLEAN FUN. PG-13 ALL THE WAY !!!!!!!!!!!! To stay on the list : Place (YEP) in the suject area of < url-jokefarm-data@usa.net > _____________________________________________________________________ ON BOTTOM OF PAGE you can be removed by a diffrent address. JOKE-FARM JOKE OF THE DAY: Remember Stella Liebeck, who pried $640,000 out of McDonalds after spilling a cup of McCoffee she was balancing between her knees in her grandson's car. But did you hear about John Parker, who tried a similar between-the- legs McDonald's lawsuit - With a milkshake? (He lost). A guy sued Anheuser-Busch for emotional distress after drinking the company's beer without later having 'success with women.' A robber sued the bank, the manufacturer, the city, the police, and the hospital after a 'Security Pac' hidden in the stolen loot released tear gas and red dye. A minister and his wife sued a guide-dog school when a blind man stepped on the wife's toes in a shopping mall. A San Diego man sued the city for emotional trauma during a convert when he saw women using the men's rest room. A New York woman sued the company that makes The Clapper, claiming she 'had to clap too hard in order to turn her appliances on.' In a high-profile case last year, a Blue Cross-Blue Shield of Missouri worker unsuccessfully sued IBM, claiming that the 'faulty design' of IBM's keyboards produced pain that prevented her from working. In December 1996, a New York jury awarded $5.3 million to a secretary who claimed she was injured by a Digital Equipment Corporations keyboard. Rather than asserting that keyboards were defective, her lawyers contended that Digital neglected to warn its users about the dangers of typing. ************************************************************* ADVERTISE YOUR BUSINESS URL FOR $15.00 PER WEEK ADVERTISE YOUR HOMEPAGE FOR $6.00 PER WEEK WE TAKE VISA MASTERCARD & DISCOVER CARDS THOUSANDS WILL SEE IT: CALL US TOLL FREE AT 1-888-746-3311 TAKE A LOOK BELOW ************************************************************* www.intellicast.com Todays weather all over the world!! www.emergency.com Really neat to look at!! www.nasdaq.com Over the counter stocks!! www.babycenter.com Baby Center & Care http://maxpages.com/jokefarm Advertise your URL to thousands daily!! www.dogpile.com A whole lot of searching in one box ! www.rbc.net RBC www.weddingchannel.com The wedding channel. To be removed please place (DELETE) in SUBJECT. take-me-off-this-list@usa.net Thanks! Hope everyone has the day they deserve and have worked for & your dreams come true. From rem-conf Tue Jan 12 09:41:41 1999 From rem-conf-request@es.net Tue Jan 12 09:41:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1007kA-0004UU-00; Tue, 12 Jan 1999 09:36:42 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 1007k9-0004UK-00; Tue, 12 Jan 1999 09:36:41 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA07702; Tue, 12 Jan 1999 09:36:40 -0800 (PST) Message-Id: <3.0.3.32.19990112093702.00abb3c0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 12 Jan 1999 09:37:02 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 1/20 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Simplifying the Controls of an Interactive Movie Game (Wednesday January 20, 1999 12:30-2:00 PDT 405 Soda Hall) Jeff Johnson UI Wizards, Inc. Eight months before an interactive movie game was due to be shipped, its developers and funders decided that its user interface had to be radically simplified. The author was given the task of designing a new, simpler control scheme. This paper describes the redesign process, the design issues that arose and how they were resolved, the tests that were conducted to evaluate new design ideas, and concludes with an evaluation of the resulting design, lessons learned, and thoughts on user-interface design vs. game design. Reference: Johnson, J., Simplifying the Controls of an Interactive Movie Game, Proceedings of ACM CHI'98, pages 65-72. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Jan 12 14:15:50 1999 From rem-conf-request@es.net Tue Jan 12 14:15:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100C09-00002s-00; Tue, 12 Jan 1999 14:09:29 -0800 Received: from smtp.tcon.net (tcslip.tcon.net) [204.120.67.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 100C07-00002h-00; Tue, 12 Jan 1999 14:09:27 -0800 Received: from Alfaroh.tcon.net (s04.pm5.tcon.net [207.40.214.69]) by tcslip.tcon.net (8.8.5/8.8.5) with SMTP id RAA15557; Tue, 12 Jan 1999 17:34:06 -0500 (EST) Date: Tue, 12 Jan 1999 17:34:06 -0500 (EST) From: lezah To: Message-Id: <18161.236172.69890775 ronssyd@eudoramail.com> Subject: FROM THE DESKTOP OF MAY..... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are receiving this because you are on a Safe to e-mail list. Or someone sent me your address.If this has reached you in error, please follow Instructions as follows. To be removed please e-mail me and put " remove " in the subject box and I'll will honor your request Immediately! ************************************************************************************************************************** I tried them all and lost money...Does that sound familiar Well, guess what? I finally found a program that works!!! WAIT A MINUTE! Before you say, " here's another one " and want to delete this: I urge you to read this through! This is changing my life for the better and it certainly will do the same for you! ***** Visit our website at: http://www.topsecrets100.com ***** CODE:59441 ______________________ Pros Make You a Fortune. The # 1 Homebased Business for the 2nd year in a row. No selling, just refer people to the company'S 800 #. Commission checks paid weekly! It's simple and easy. $500 to $5000 (or more) monthly! A solid company that's a member of the Better Business Bureau and the United Chamber of Commerce. HAVE YOU EXPERIENCED THIS? The amount of money earned in your program is only a fraction related to the MASSIVE AMOUNTS OF TIME, ENERGY AND MONEY YOU PUT OUT! We all have, right? Why? " PEOPLE DO NOT LIKE TO SELL, NEVER HAVE AND NEVER WILL " MOST PEOPLE ARE NOT INTERESTED IN: #1. SELLING ANYTHING TO ANYONE! #2. FOLLOWING UP BY E-MAIL, SNAILMAIL, OR PHONE! #3. MONTHLY REQUIRED PURCHASES! #4. RECRUITING ON AND OFF THE NET! #5. MAKING PERSONAL CONTACT WITH OTHERS! #6. CONFERENCE CALLING! #7. MEETINGS! #8. FILLING OUT APPLICATIONS! #9. KEEPING AN INVENTORY! SO NOW WHAT? HOW CAN WE EVER BE SUCCESSFUL? HERES HOW:REFER people to this TOLL - FREE NUMBER (where Professional Telemarketers will PRESENT, INFORM, ENTERTAIN, AND DO whatever is necessary to SIGN UP YOUR PROSPECTS and place them in your downline for you!) That's all you do period! If you can do that (REFER PEOPLE TO THE 800 NUMBER, ON and or OFF the NET) you could be successful beyond your wildest dreams! YOU OWE IT TO YOURSELF TO GET THE WHOLE STORY: CALL: 8am - 10pm CST Monday - Saturday 1-800-811-2141 Code: 59441 or call 1-800-226-0633 Code: 59441 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code: 59441 or 1-785-762-2442 Code: 59441 HOW WELL DOES IT WORK? Here are just a few Toll - Free recorded testimonials from company members. Don't just take my word for it...call them for yourself! They are real people just like you and me! CALL NOW: THE CALLS ARE FREE! Steve Fletcher: 888-438-4005 Jill Dietch: 888-703-5389 Jim Montgomery: 888-446-6949 William Sounder: 888--446-6951 Henry Wheeler: 888-256-4767 Tim Russell: 888-731-3457 Live operators will be happy to explain the program to you and why it virtually GUARANTEES your success! EVERY ASPECT OF SELLING IS DONE COMPLETELY BY THE COMPANY and YOU GET PAID FOR IT! The company handles all your calls, closes your sales and sends you WEEKLY commission checks! You receive $100 EVERY TIME THE COMPANY CLOSES A SALE FOR YOU! PLUS you become eligible to receive the GUARANTEED LOWEST PRICE on over 250,000 Name Brand Products and Services you're already buying now, conveniently delivered to your front door! SAVE $200 on groceries, $300 on dining out and save hundreds more on THOUSANDS of name brand products and services! Merchandise, Travel, Health Care, Professional Services, Discounts on food and Entertainment and much more! The manufacture's Warrantee is automatically doubled when you make a purchase. DOUBLE THE DIFFERENCE MONEY - BACK GUARANTEE you will save money using our program or we will honor a FULL REFUND! Purchasing from among these 250,000 Name Brand super discounted products and services IS NOT MANDATORY. YOU DON'T HAVE TO BUY ANYTHING. You may contact people and refer them to the Toll - Free 800# any way you choose: Classifieds, flyers, postcards (supplied by the company - including pre - qualified names), Posting in appropriate newsgroups, Bulk e-mail etc. Suppose you use Bulk e-mail, which I find very successful: 100,000 e-mails with a 1/10 of a percent (0.1%) sales rate, nets, $1000...not to bad. Also, Top Secrets pays up to 60% in bonuses to infinity! The most lucrative infinity plan ever made. When you call, consider the professionalism of the live operators handling your call. I'm convinced you will not find a more highly motivated and well trained team of people to close your sales for you, and remember they are available 14 hours a day - 6 days a week ON YOUR BEHALF! CALL: 8am - 10 pm CST Monday - Saturday 1-800-811-2141 Code:59441 or call 1-800-226-0633 Code: 59441 Fax On Demand: 415-273-6020 (7 pgs.) Outside the USA and Canada call: 1-785-762-6715 Code:59441 or 1-785-762-2442 Code: 59441 Get your own CODE# from the friendly operators and I'll RACE YOU TO THE BANK! DON'T DELAY! MAKE THAT CALL! I promise you'll be glad you did! Hazel ********* Visit our website at: http://www.topsecrets100.com ********* Code: 59441 P.S. After you come on board give me a call at: 317-722-7707 From rem-conf Wed Jan 13 00:47:11 1999 From rem-conf-request@es.net Wed Jan 13 00:47:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100Lo6-0006ut-00; Wed, 13 Jan 1999 00:37:42 -0800 Received: from firewall.infonova.at [195.3.81.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 100Lo4-0006uj-00; Wed, 13 Jan 1999 00:37:40 -0800 Received: from mailsrv.infonova.at (mailsrv.infonova.at [195.3.81.25]) by Firewall.infonova.at (8.8.8/8.8.8) with ESMTP id JAA05516; Wed, 13 Jan 1999 09:37:27 +0100 (MET) Received: by mailsrv.infonova.at with Internet Mail Service (5.5.1960.3) id ; Wed, 13 Jan 1999 09:31:07 +0100 Message-ID: <573DE5317133D2119638006094B95B68212B2D@mailsrv.infonova.at> From: Stadler Wilhelm To: rem-conf@es.net Cc: jmf-interest@Sun.COM Subject: MPEG-2 Players capable of network streams? Date: Wed, 13 Jan 1999 09:31:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi ! Does anybody know of any (free or commercial) implementation of * A Windows-based MPEG-2 player (using SW or HW decoding based on DirectShow) that is capable of receiving MPEG-2 TS from a network connection - over an ATM connection (MPEG-2 over AAL5, CBR, push-mode) - over an IP connection (MPEG-2 over RTP/UDP/IP, pull or push) implemented as DirectShow plugin or JMF add-in (or something else...) Any tips appreciated! TiA Willi ------------------------- DI Wilhelm Stadler Head of Dept. Multimedia Systems INFONOVA Information Technology Karlauerguertel 1, A-8020 Graz Tel: ++43 316 715440-0 Fax: ++43 316 715440-2 mailto:wilhelm.stadler@infonova.at From rem-conf Wed Jan 13 01:26:02 1999 From rem-conf-request@es.net Wed Jan 13 01:26:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100MXQ-00009q-00; Wed, 13 Jan 1999 01:24:32 -0800 Received: from relay8.uu.net [192.48.96.84] by mail1.es.net with esmtp (Exim 1.81 #2) id 100MXP-00009g-00; Wed, 13 Jan 1999 01:24:31 -0800 Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfxyr27784; Wed, 13 Jan 1999 04:24:29 -0500 (EST) Received: by neserve0.uu.net id QQfxyr04891; Wed, 13 Jan 1999 04:24:22 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: MPEG-2 Players capable of network streams? In-Reply-To: <573DE5317133D2119638006094B95B68212B2D@mailsrv.infonova.at> from Stadler Wilhelm at "Jan 13, 1999 9:31: 6 am" To: wilhelm.stadler@infonova.at (Stadler Wilhelm) Date: Wed, 13 Jan 1999 04:24:22 -0500 (EST) Cc: rem-conf@es.net, jmf-interest@Sun.COM X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list How about winamp. IT appears to be able to do this. IT does not currently have multicasting extentions. Stadler Wilhelm said: > Hi ! > > Does anybody know of any (free or commercial) implementation of > > * A Windows-based MPEG-2 player (using SW or HW decoding based on > DirectShow) > that is capable of receiving MPEG-2 TS from a network > connection > > - over an ATM connection (MPEG-2 over AAL5, CBR, push-mode) > > - over an IP connection (MPEG-2 over RTP/UDP/IP, pull or push) > > > implemented as DirectShow plugin or JMF add-in (or something > else...) > > Any tips appreciated! > > TiA > > Willi > > ------------------------- > DI Wilhelm Stadler > Head of Dept. Multimedia Systems > INFONOVA Information Technology > Karlauerguertel 1, A-8020 Graz > Tel: ++43 316 715440-0 > Fax: ++43 316 715440-2 > mailto:wilhelm.stadler@infonova.at > > > From rem-conf Wed Jan 13 01:31:07 1999 From rem-conf-request@es.net Wed Jan 13 01:31:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100MdY-0000bY-00; Wed, 13 Jan 1999 01:30:52 -0800 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 100MdW-0000bJ-00; Wed, 13 Jan 1999 01:30:51 -0800 Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id KAA15308; Wed, 13 Jan 1999 10:30:24 +0100 (MET) Message-Id: <199901130930.KAA15308@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: jhall@UU.NET (Jeremy Hall) cc: wilhelm.stadler@infonova.at (Stadler Wilhelm), rem-conf@es.net, jmf-interest@Sun.COM Subject: Re: MPEG-2 Players capable of network streams? In-reply-to: Your message of "Wed, 13 Jan 1999 04:24:22 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jan 1999 10:30:23 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I think there was some video involved here as well :-) /P From rem-conf Wed Jan 13 02:05:28 1999 From rem-conf-request@es.net Wed Jan 13 02:05:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100N8s-0001Yu-00; Wed, 13 Jan 1999 02:03:14 -0800 Received: from firewall.infonova.at [195.3.81.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 100N8q-0001YZ-00; Wed, 13 Jan 1999 02:03:12 -0800 Received: from mailsrv.infonova.at (mailsrv.infonova.at [195.3.81.25]) by Firewall.infonova.at (8.8.8/8.8.8) with ESMTP id LAA05974; Wed, 13 Jan 1999 11:03:07 +0100 (MET) Received: by mailsrv.infonova.at with Internet Mail Service (5.5.1960.3) id ; Wed, 13 Jan 1999 10:56:47 +0100 Message-ID: <573DE5317133D2119638006094B95B68212B43@mailsrv.infonova.at> From: Stadler Wilhelm To: jhall@UU.NET Cc: rem-conf@es.net, jmf-interest@Sun.COM Subject: RE: MPEG-2 Players capable of network streams? Date: Wed, 13 Jan 1999 10:56:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I mean MPEG-2 video MP@ML which is encoded/multiplexed in hardware and played out by a special ATM NIC on server, you obviously mean MPEG-2 Layer3 audio, no? Regards, Willi > -----Original Message----- > From: jhall@UU.NET [mailto:jhall@UU.NET] > Sent: Wednesday, January 13, 1999 10:24 AM > To: wilhelm.stadler@infonova.at > Cc: rem-conf@es.net; jmf-interest@Sun.COM > Subject: Re: MPEG-2 Players capable of network streams? > > > How about winamp. IT appears to be able to do this. IT does > not currently > have multicasting extentions. > > Stadler Wilhelm said: > > Hi ! > > > > Does anybody know of any (free or commercial) implementation of > > > > * A Windows-based MPEG-2 player (using SW or HW decoding based on > > DirectShow) > > that is capable of receiving MPEG-2 TS from a network > > connection > > > > - over an ATM connection (MPEG-2 over AAL5, CBR, push-mode) > > > > - over an IP connection (MPEG-2 over RTP/UDP/IP, pull or push) > > > > > > implemented as DirectShow plugin or JMF add-in (or something > > else...) > > > > Any tips appreciated! > > > > TiA > > > > Willi > > > > ------------------------- > > DI Wilhelm Stadler > > Head of Dept. Multimedia Systems > > INFONOVA Information Technology > > Karlauerguertel 1, A-8020 Graz > > Tel: ++43 316 715440-0 > > Fax: ++43 316 715440-2 > > mailto:wilhelm.stadler@infonova.at > > > > > > > From rem-conf Wed Jan 13 06:35:27 1999 From rem-conf-request@es.net Wed Jan 13 06:35:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100Qcq-0003xi-00; Wed, 13 Jan 1999 05:46:24 -0800 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 100Qcp-0003xY-00; Wed, 13 Jan 1999 05:46:23 -0800 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfxzj03621; Wed, 13 Jan 1999 08:46:15 -0500 (EST) Received: by neserve0.uu.net id QQfxzj16864; Wed, 13 Jan 1999 08:45:50 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: MPEG-2 Players capable of network streams? In-Reply-To: <573DE5317133D2119638006094B95B68212B43@mailsrv.infonova.at> from Stadler Wilhelm at "Jan 13, 1999 10:56:41 am" To: wilhelm.stadler@infonova.at (Stadler Wilhelm) Date: Wed, 13 Jan 1999 08:45:50 -0500 (EST) Cc: jhall@UU.NET, rem-conf@es.net, jmf-interest@Sun.COM X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list approve yes that is what I mean. hehehe Stadler Wilhelm said: > I mean MPEG-2 video MP@ML which is encoded/multiplexed in hardware and > played out by a special ATM NIC on server, you obviously mean MPEG-2 > Layer3 audio, no? > Regards, > Willi > > > > -----Original Message----- > > From: jhall@UU.NET [mailto:jhall@UU.NET] > > Sent: Wednesday, January 13, 1999 10:24 AM > > To: wilhelm.stadler@infonova.at > > Cc: rem-conf@es.net; jmf-interest@Sun.COM > > Subject: Re: MPEG-2 Players capable of network streams? > > > > > > How about winamp. IT appears to be able to do this. IT does > > not currently > > have multicasting extentions. > > > > Stadler Wilhelm said: > > > Hi ! > > > > > > Does anybody know of any (free or commercial) implementation of > > > > > > * A Windows-based MPEG-2 player (using SW or HW decoding based on > > > DirectShow) > > > that is capable of receiving MPEG-2 TS from a network > > > connection > > > > > > - over an ATM connection (MPEG-2 over AAL5, CBR, push-mode) > > > > > > - over an IP connection (MPEG-2 over RTP/UDP/IP, pull or push) > > > > > > > > > implemented as DirectShow plugin or JMF add-in (or something > > > else...) > > > > > > Any tips appreciated! > > > > > > TiA > > > > > > Willi > > > > > > ------------------------- > > > DI Wilhelm Stadler > > > Head of Dept. Multimedia Systems > > > INFONOVA Information Technology > > > Karlauerguertel 1, A-8020 Graz > > > Tel: ++43 316 715440-0 > > > Fax: ++43 316 715440-2 > > > mailto:wilhelm.stadler@infonova.at > > > > > > > > > > > > From rem-conf Wed Jan 13 06:49:11 1999 From rem-conf-request@es.net Wed Jan 13 06:49:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100Qfa-00040A-00; Wed, 13 Jan 1999 05:49:14 -0800 Received: from relay8.uu.net [192.48.96.84] by mail1.es.net with esmtp (Exim 1.81 #2) id 100QfX-0003zL-00; Wed, 13 Jan 1999 05:49:11 -0800 Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfxzj20396; Wed, 13 Jan 1999 08:49:08 -0500 (EST) Received: by neserve0.uu.net id QQfxzj17036; Wed, 13 Jan 1999 08:49:04 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: MPEG-2 Players capable of network streams? In-Reply-To: <199901130930.KAA15308@basil.cdt.luth.se> from Peter Parnes at "Jan 13, 1999 10:30:23 am" To: peppar@cdt.luth.se (Peter Parnes) Date: Wed, 13 Jan 1999 08:49:04 -0500 (EST) Cc: jhall@UU.NET, wilhelm.stadler@infonova.at, rem-conf@es.net, jmf-interest@Sun.COM X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list approve well you know me, I'm not into video much. :-) Peter Parnes said: > I think there was some video involved here as well :-) > > /P > > From rem-conf Thu Jan 14 15:57:27 1999 From rem-conf-request@es.net Thu Jan 14 15:57:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100wTR-0004KK-00; Thu, 14 Jan 1999 15:46:49 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 100wTQ-0004KA-00; Thu, 14 Jan 1999 15:46:48 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id PAA18995; Thu, 14 Jan 1999 15:46:47 -0800 (PST) Message-Id: <3.0.3.32.19990114154708.00a9e170@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 14 Jan 1999 15:47:08 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder 1/20 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Simplifying the Controls of an Interactive Movie Game (Wednesday January 20, 1999 12:30-2:00 PDT 405 Soda Hall) Jeff Johnson UI Wizards, Inc. Eight months before an interactive movie game was due to be shipped, its developers and funders decided that its user interface had to be radically simplified. The author was given the task of designing a new, simpler control scheme. This paper describes the redesign process, the design issues that arose and how they were resolved, the tests that were conducted to evaluate new design ideas, and concludes with an evaluation of the resulting design, lessons learned, and thoughts on user-interface design vs. game design. Reference: Johnson, J., Simplifying the Controls of an Interactive Movie Game, Proceedings of ACM CHI'98, pages 65-72. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Jan 14 18:12:41 1999 From rem-conf-request@es.net Thu Jan 14 18:12:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 100yft-0005lY-00; Thu, 14 Jan 1999 18:07:49 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 100yfr-0005lO-00; Thu, 14 Jan 1999 18:07:47 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA16901 for ; Thu, 14 Jan 1999 21:07:45 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA11586 for ; Thu, 14 Jan 1999 21:07:44 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <369EA2EF.37D7DADB@cs.columbia.edu> Date: Thu, 14 Jan 1999 21:07:43 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: vic with Osprey 150? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Has anybody compiled vic for the Osprey 150 on Solaris 2.6? The Osprey 1500 version just shows a green local video image; the plain vanilla version crashes. Rendezvous works, btw. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Jan 14 20:51:50 1999 From rem-conf-request@es.net Thu Jan 14 20:51:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1011Bb-000733-00; Thu, 14 Jan 1999 20:48:43 -0800 Received: from mail.gmd.de [129.26.8.90] by mail1.es.net with esmtp (Exim 1.81 #2) id 1011Ba-00072H-00; Thu, 14 Jan 1999 20:48:42 -0800 Received: (from mayer@localhost) by mail.gmd.de (8.8.8/8.8.8) id FAA08542; Fri, 15 Jan 1999 05:45:35 +0100 (MET) Date: Fri, 15 Jan 1999 05:45:35 +0100 (MET) From: Hans Mayer Message-Id: <199901150445.FAA08542@mail.gmd.de> To: hgs@cs.columbia.edu, rem-conf@es.net Subject: Re: vic with Osprey 150? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Has anybody compiled vic for the Osprey 150 on Solaris 2.6? The Osprey >1500 version just shows a green local video image; the plain vanilla >version crashes. Rendezvous works, btw. I'm not shure about the 150. There is a version from University of Erlangen that works (more or less) with the 1100 and 1500 (I'm having problems with the initialisation of the card - default is NTSC and I have to start o1k_display to init the card to PAL but this program hangs (in 99%) my U30). Kind Regards, Hans Mayer, GMD - TKT From rem-conf Thu Jan 14 23:18:17 1999 From rem-conf-request@es.net Thu Jan 14 23:18:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1013T5-0000XE-00; Thu, 14 Jan 1999 23:14:55 -0800 Received: from q.inter.net.il [205.164.141.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 1013T2-0000X4-00; Thu, 14 Jan 1999 23:14:52 -0800 Received: from internet-zahav.net (Rhv-150-174.access.net.il [192.117.150.174]) by Q.inter.net.il (8.8.8/8.8.6/PA) with ESMTP id JAA20368; Fri, 15 Jan 1999 09:14:35 +0200 (IST) Message-ID: <369EEAEB.43ED7092@internet-zahav.net> Date: Fri, 15 Jan 1999 09:14:52 +0200 From: PUIU BIRNBAUM X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: IMPORT EXPORT SERVICES Content-Type: multipart/mixed; boundary="------------2C3B4A900B7DF220EB5B8C55" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------2C3B4A900B7DF220EB5B8C55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PAMONA INTERNATIONAL Import and Export Consulting. You need a good buyer for the goods you are exporting. You need a good manufacturer for the goods you are importing. " A good partner is the best business " This is what we offer you : A GOOD PARTNER. We will bring you the best partners to your desk. We have all the tools and 35 years of actual practice in import, export, consulting, international transport, banking, financing, and all the other aspects of the international trade. We offer you our services to solve the problems for which you don't have the time, or connections, or information. Tell us what you need and we will take care of it, against real reasonable agreed charges. Will be pleased to meet you, Puiu Birnbaum Dipl. M.A. Economist. PAMONA INTERNATIONAL 21/6 Miler Street Rehovot - 76284 Israel Phone :++972-8-9462120 Fax :++972-8-9471164 E-Mail : pamona@internet-zahav.net Web site : http://members.xoom.com/Pamona/partner.html --------------2C3B4A900B7DF220EB5B8C55 Content-Type: text/html; charset=us-ascii; name="partner.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="partner.html" pamona

PAMONA INTERNATIONAL

Import and Export Consulting

 "A good Partner is the best Business". You need a good buyer for the goods you are exporting. You need a good manufacturer for the goods you are importing. This is what we offer you : A GOOD PARTNER. We will bring you the best partners to your desk. We have all the tools and 35 years of actual practice in import, export, consulting, international transport, banking, financing, and all the other aspects of the international business. Tell us what you need and we will take care of it !

Will be pleased to meet you,

P. Birnbaum
Dipl. M.A. Economist.
Please contact us :
PAMONA INTERNATIONAL
21/6 Miler Street
Rehovot - 76284 Israel
Phone : ++972-8-9462120    Fax : ++972-8-9471164

E-Mail :
pamona@netscape.net
 
 

.
 
 
 
 
 
 
  --------------2C3B4A900B7DF220EB5B8C55-- From rem-conf Fri Jan 15 00:00:26 1999 From rem-conf-request@es.net Fri Jan 15 00:00:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10148k-0001OC-00; Thu, 14 Jan 1999 23:57:58 -0800 Received: from net01.axime.com (mailhost.axime.com) [160.92.120.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10148h-0001O2-00; Thu, 14 Jan 1999 23:57:56 -0800 Received: from [169.132.119.90] (ppp-18.ts-2.fpk.idt.net [169.132.119.90]) by mailhost.axime.com (8.8.8/[Atos MultiMedia]) with ESMTP id IAA23300; Fri, 15 Jan 1999 08:44:45 +0100 (MET) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Approved-by: Tempting Tear-Outs for general release X-Priority: 1 (Highest) Date: Thu, 14 Jan 1999 22:44:31 -0400 To: Tempting Tear-Outs From: Tempting Tear-Outs Subject: Hi X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ===>> FREE 1 yr USA Magazine Sub sent worldwide-200+ Choices! Up to $81.00 value! To be removed from our mailing list, please send email to: temptingtearouts@1stconnect.com with the subject line of "remove." FOR MORE INFO: please "cut out" the below form on the "cut" lines shown, and fax it, for the fastest reply to: 1-718-227-9125 (this is a fax # in the USA) or send via smail (first class mail or airmail) to: Tempting Tear-Outs Att. Free-catalogue-by-email Dept 3835 Richmond Ave. Suite #200 Staten Island NY 10312-3828 USA SORRY, BUT.... our software is not set up to accept the below form via return email; WE CAN ONLY acknowledge forms sent in via fax or smail. --> IMPORTANT complete directions, to ensure that you get a reply, and more info follow, below the reply form and the catalogue options. *------------cut here/begin-------------------------------------------* Name (First Middle Last): Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Cellular (Mobile) Tel. #: Beeper (Pager) Tel. #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 011499-l-hi Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY: 1. you must call from an "unblocked number," ie. one that is not blocked >from caller id. We are very sorry for this requirement, but our fax software requires this before it allows an incoming fax call to connect. If you have a blocked number, you must first unblock it. In most cases this means dialing *82 from a touch-tone phone (or 1182 from a rotary phone) before you dial 1-718-227-9125. NOTE: If you are not sure if your number is blocked, just try dialing our fax # normally. If you don't get a recording telling you your number is blocked, your number has been transmitted and you may press the start button on your fax when you hear the fax tone from our fax. 2. no reply forms can be accepted by email....only via fax or smail. 3. your form must be typewritten or printed out on your computer printer before you fax it; sorry, but *no* handwritten forms will be acknowledged. If you can't find someone with a typewriter or a computer printer, we apologize for not being able to reply to you. 4. faxes with cover pages will be rejected. You must send *only* the reply form. 5. forms not *completely* filled in will not be acknowledged. 6. you will receive a reply within 1 business day directly from the company making the offer via email. Therefore you must have an email address. If you read this message, then you must have an email address, or access to one, at least. :-) 7. your fax must not exceed 1 page in length. Faxes of 2 or more pages will be sensed, then auto-terminated and deleted. Your fax goes directly onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1 page. 8. all faxes must begin with: *------------cut here/begin-------------------------------------------* and must end with: *------------cut here/end--------------------------------------------* 9. Any fax not conforming to this format will be sensed by our software, then auto-terminated and deleted from the hard drive, before any human ever gets to see it. 10. The type on your fax must be dark and legible. If in doubt, please print it out darker before faxing it in. If we can't read it, we can't reply to you or send you our FREE catalogue. :-( 11. If this all seems too complicated for faxing, just do it the old fashioned way via smail!!! WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER: The company making the offer is a magazine subscription agency based in the USA. They have over 1,100 popular USA titles available to be shipped to *any* country, including of course, to anywhere in the USA! They offer a FREE 1 yr. subscription to your choice of over 200 of the titles in their catalogue to any new customer using them for the first time. The dollar value of the freebies, based on the subscription prices directly >from the publishers, ranges from $6.97 all the way up to $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,100+ titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly >from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas customers. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new customers who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the two formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa, American Express, Diner's Club and Carte Blanche. Overseas, they accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche, even if your credit card is a local one in local currency (that most merchants in the USA would not normally be willing to accept). That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on advertising rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, 3835 Richmond Ave. Suite #200, Staten Island NY 10312-3828, USA. From rem-conf Fri Jan 15 01:31:16 1999 From rem-conf-request@es.net Fri Jan 15 01:31:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1015WL-0002j4-00; Fri, 15 Jan 1999 01:26:25 -0800 Received: from babelfish.axion.bt.co.uk [132.146.17.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 1015WK-0002iG-00; Fri, 15 Jan 1999 01:26:24 -0800 Received: from sb48mhnt23.comnet.bt.co.uk by babelfish.axion.bt.co.uk (local) with ESMTP; Fri, 15 Jan 1999 09:23:36 +0000 Received: by sb48mhnt23.comnet.bt.co.uk with Internet Mail Service (5.5.2232.9) id ; Fri, 15 Jan 1999 09:24:49 -0000 From: "Swale,RP,NAM5 SWALERP M" To: rem-conf@es.net Subject: remove Date: Fri, 15 Jan 1999 09:21:16 -0000 X-Mailer: Internet Mail Service (5.5.2232.9) Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove begin 600 winmail.dat M>)\^(C()`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<` M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`02``0`'`````'```0````<```!R96UO=F4```(!<0`!````%@````&^0&AG M"5XI5NNL61'2K`@`H,E$1#D```(!"1`!````:0```&4```")````3%I&=:`* M2=H#``H``""`&``````#`````````1@`` M```8A0```````!X`)8`((`8``````,````````!&`````#:%```!`````0`` M```````>`":`""`&``````#`````````1@`````WA0```0````$````````` M'@`G@`@@!@``````P````````$8`````.(4```$````!``````````,`)@`` M`````P`V```````>`#%``0````T````X,#(U,C$Q-3`P,#$``````P`:0``` M```>`#!``0````T````X,#(U,C$Q-3`P,#$``````P`90``````#`(`0____ M_P(!^3\!````7`````````#:$"^`4``"##POE[8:$"^ M`1X`/0`!`````0`````````>`!T.`0````<```!R96UO=F4```L`*0`````` M"P`C```````#``80%7NZ*0,`!Q`&`````P`0$``````#`!$0`````!X`"!`! 1````!P```%)%34]610``"+`= ` end From rem-conf Fri Jan 15 02:47:03 1999 From rem-conf-request@es.net Fri Jan 15 02:47:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1016iV-0003jl-00; Fri, 15 Jan 1999 02:43:03 -0800 Received: from tac.inria.fr [138.96.24.102] (flyonnet) by mail1.es.net with esmtp (Exim 1.81 #2) id 1016iT-0003jb-00; Fri, 15 Jan 1999 02:43:01 -0800 Received: from tac.inria.fr by tac.inria.fr (8.8.8/8.8.5) with ESMTP id LAA09647; Fri, 15 Jan 1999 11:42:47 +0100 (MET) Message-Id: <199901151042.LAA09647@tac.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 To: Henning Schulzrinne Cc: rem-conf@es.net Subject: Re: vic with Osprey 150? In-Reply-To: Message from Henning Schulzrinne of "Thu, 14 Jan 1999 21:07:43 EST." <369EA2EF.37D7DADB@cs.columbia.edu> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_13771006000" Date: Fri, 15 Jan 1999 11:42:47 +0100 From: Frank Lyonnet X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multipart MIME message. --==_Exmh_13771006000 Content-Type: text/plain; charset=us-ascii > Has anybody compiled vic for the Osprey 150 on Solaris 2.6? The Osprey > 1500 version just shows a green local video image; the plain vanilla > version crashes. Rendezvous works, btw. There's some problems with the xil scaling procs under Solaris 2.6 and Osprey boards. I'm not sure it comes from the chip itself or the xil revision shipped with solaris 2.6 (I had the same problems with an early osprey board that was ok under 2.5 and no longer under 2.6). The reason why Rendezvous works is that I simply disable hardware scaling on such boards ... If you want to re-enable it define the O1KSCALEBUG in your environnement. Included is the source code of the xil driver for Rendez-vous. Frank Lyonnet Game And Internet Architecture - GAIA Project - INRIA Sophia Antipolis http://gaia.inria.fr/ Rendez-Vous home page http://www.inria.fr/rodeo/rv/ --==_Exmh_13771006000 Content-Type: text/plain; name="videograber_sunvideo.cc"; charset=us-ascii Content-Description: videograber_sunvideo.cc Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="videograber_sunvideo.cc" /* videograber_sunvideo.cc */ #include "videograber_sunvideo.h" #include "videostdsize.h" #include "mathutils.h" #include #include video_graber_sunvideo::video_graber_sunvideo(int _Width, int _Height, col= orspace _CSpace, digitizer_port _Port, digitizer_signal _Suggested, BOOLE= AN _DoubleBuffering, BOOLEAN * Successfull) : video_graber_hard(_Width, _= Height, _CSpace, _Port, _Suggested, _DoubleBuffering, Successfull) { #ifndef __SUNOS__ Image =3D NULL; RTVCImage =3D NULL; ScaledImageA =3D NULL; ScaledImageB =3D NULL; /* Open device */ *Successfull =3D open(NULL); = if(*Successfull) { /* Ok card is opened, now try to satisfy requested specs */ request_secam(); request_port(); request_size(); request_colorspace(); /* And allocate image */ allocate_image(); *Successfull =3D (get_format() !=3D SIGNAL_NONE); = }; #else *Successfull =3D FALSE; #endif } video_graber_sunvideo::~video_graber_sunvideo(void) { #ifndef __SUNOS__ /* Close device */ close(); #endif } void video_graber_sunvideo::change_colorspace(colorspace _CSpace) { #ifndef __SUNOS__ video_graber::change_colorspace(_CSpace); destroy_image(); request_colorspace(); allocate_image(); #endif } void video_graber_sunvideo::change_size(int _Width, int _Height) { #ifndef __SUNOS__ video_graber::change_size(_Width, _Height); destroy_image(); request_size(); allocate_image(); #endif } void video_graber_sunvideo::do_grab(void) { #ifndef __SUNOS__ /* Swap buffers */ if(DoubleBuffering) Image->swap_buffers(); /* Scale */ xil_scale(RTVCImage, ((video_sample_image_xil *)Image)->get_xil_image()= , "nearest", XScale, YScale); xil_toss(((video_sample_image_xil *)Image)->get_xil_image()); #endif } digitizer_signal video_graber_sunvideo::get_format(void) { #ifndef __SUNOS__ char * Format =3D NULL; digitizer_signal Ret; /* Description : Returns 0 if capturing from PAL, non-zero if capturing= from NTSC */ xil_get_device_attribute(RTVCImage, "FORMAT_V", (void **) &Format); = = if(Format =3D=3D NULL) { Ret =3D SIGNAL_PAL; } else { Ret =3D SIGNAL_NTSC; }; /* Sunvideo cannot determine if signal is none, detect black image */ { int i, j; XilMemoryStorage DataStore; video_sample * Ptr, * Ptr0; int PStr, LStr; /* Scale */ xil_scale(RTVCImage, ScaledImageA, "nearest", XScale, YScale); xil_toss(ScaledImageA); xil_get_memory_storage(ScaledImageA, &DataStore); Ptr =3D Ptr0 =3D DataStore.byte.data; PStr =3D DataStore.byte.pixel_stride; LStr =3D DataStore.byte.scanline_stride; for(j =3D 0; j < Height; j ++) { for(i =3D 0; i < Width; i ++) { /* Well none signal is noisy but no sup of 100 */ if(*Ptr > 100) goto retsignal; Ptr +=3D PStr; } Ptr0+=3DLStr; } } return(SIGNAL_NONE); retsignal : return(Ret); #else return(SIGNAL_NONE); #endif } void video_graber_sunvideo::request_colorspace(void) { #ifndef __SUNOS__ /* Card do only 444 YCBCR */ if(CSpace =3D=3D COLORSPACE_COLOR) CSpace =3D COLORSPACE_YCBCR_444; if(CSpace =3D=3D COLORSPACE_GRAY) CSpace =3D COLORSPACE_YCCIR; #endif } void video_graber_sunvideo::request_size(void) { #ifndef __SUNOS__ int RWidth, RHeight; int NBands; XilDataType DataType; int DivFactor2; xil_get_info(RTVCImage, (u_int *)&RWidth, (u_int *)&RHeight, (u_int *) = &NBands, &DataType); /* Only supported with SunVideo SBus */ if((strcmp(DeviceName, "o1k") =3D=3D 0) && (getenv("O1KSCALEBUG") =3D=3D= NULL)) { XScale =3D 1.0; YScale =3D 1.0; Width =3D RWidth; Height =3D RHeight; = return; } /* We got a probleme with NTSC cameras ... we cannot provide xCIF image= s directly, we use */ /* div2 larger format instead but it is way slower than PAL ... */ /* The scaler is fast only with simple scales */ /* Just use it, will stretch later */ /* Allow an image to be 80 % of requested */ #define ALLOWED_ROUND 0.8 /* Select div 2 factor */ DivFactor2 =3D 0; while(((RWidth / mypow2(DivFactor2 + 1)) >=3D (int)((float)Width * ALLO= WED_ROUND)) && ((RHeight / mypow2(DivFactor2 + 1)) >=3D (int)((float)Heig= ht * ALLOWED_ROUND))) DivFactor2 ++; if(DivFactor2 > 0) { XScale =3D 1.0 / mypow2(DivFactor2); YScale =3D 1.0 / mypow2(DivFactor2); Width =3D RWidth / mypow2(DivFactor2); Height =3D RHeight / mypow2(DivFactor2); } = else { XScale =3D 1.0; YScale =3D 1.0; Width =3D RWidth; Height =3D RHeight; } = #endif } void video_graber_sunvideo::request_secam(void) { #ifndef __SUNOS__ /* To do */ #endif } void video_graber_sunvideo::request_port(void) { #ifndef __SUNOS__ int PortNumber; switch(Port) { case PORT_COMPOSITE1 : PortNumber =3D 0; break; case PORT_COMPOSITE2 : PortNumber =3D 1; break; case PORT_SVIDEO1 : PortNumber =3D 2; break; case PORT_SVIDEO2 : PortNumber =3D 2; break; }; if(xil_set_device_attribute(RTVCImage, "PORT_V", (void *)((PortNumber += 1)%3)) =3D=3D XIL_FAILURE) { fatal_error("setting PORT_V attribute failed"); } #endif } void video_graber_sunvideo::allocate_image(void) { #ifndef __SUNOS__ int NBands; int RWidth, RHeight; XilDataType DataType; xil_get_info(RTVCImage, (u_int *)&RWidth, (u_int *)&RHeight, (u_int *) = &NBands, &DataType); if((ScaledImageA =3D xil_create(State, Width, Height, NBands, XIL_BYTE)= ) =3D=3D NULL) = { fatal_error("xil_create scaled_image failed"); }; if(DoubleBuffering) { if((ScaledImageB =3D xil_create(State, Width, Height, NBands, XIL_BYT= E)) =3D=3D NULL) = { fatal_error("xil_create scaled_image failed"); }; }; Image =3D new video_sample_image_xil(Width, Height, CSpace, NULL, Doubl= eBuffering, ScaledImageA, ScaledImageB); #endif } void video_graber_sunvideo::destroy_image(void) { #ifndef __SUNOS__ if(ScaledImageA !=3D NULL) xil_destroy(ScaledImageA); if(ScaledImageB !=3D NULL) xil_destroy(ScaledImageB); delete Image; #endif } BOOLEAN video_graber_sunvideo::open(char * Name) { #ifndef __SUNOS__ char SunDevice[256]; XilDevice Device; int RWidth, RHeight; int NBands; XilDataType DataType; = if(Name =3D=3D NULL) { if(system("\\ls /dev/o1k0 > /dev/null") =3D=3D 0) strcpy(DeviceName, "o1k"); else strcpy(DeviceName, "rtvc"); } = if(strcmp(DeviceName, "o1k") =3D=3D 0) { sprintf(SunDevice, "MMAC%s", DeviceName); } = else { sprintf(SunDevice, "SUNW%s", DeviceName); } RTVCImagePrimary =3D RTVCImage =3D NULL; if((State =3D xil_open()) =3D=3D NULL) = { debug_trace(DEBUG_DEVICE, "can't open xil library"); return(FALSE); } /* To turn on debugging put 1, else 0 */ = xil_state_set_show_action(State, 0); if(!(Device =3D xil_device_create(State, SunDevice))) = { debug_trace(DEBUG_DEVICE, "cannot create device object"); return(FALSE); } RTVCImagePrimary =3D xil_create_from_device(State, SunDevice, Device); xil_device_destroy(Device); if(RTVCImagePrimary =3D=3D NULL) { debug_trace(DEBUG_DEVICE, "can't open SunVideo software driver"); return(FALSE); } /* Here deal with the color ... */ /* Only supported with SunVideo SBus */ if(strcmp(DeviceName, "rtvc") =3D=3D 0) { xil_get_info(RTVCImagePrimary, (u_int *)&RWidth, (u_int *)&RHeight, (= u_int *) &NBands, &DataType); if(CSpace =3D=3D COLORSPACE_GRAY) RTVCImage =3D xil_create_child(RTVCImagePrimary, 0, 0, RWidth, RHei= ght, 0, 1); else RTVCImage =3D RTVCImagePrimary; } else RTVCImage =3D RTVCImagePrimary; return(TRUE); #else return(FALSE); #endif } void video_graber_sunvideo::close(void) { #ifndef __SUNOS__ if(RTVCImage !=3D NULL) xil_destroy(RTVCImage); if((RTVCImagePrimary !=3D RTVCImage) && (RTVCImagePrimary !=3D NULL)) xil_destroy(RTVCImagePrimary); if(State !=3D NULL) xil_close(State); #endif } --==_Exmh_13771006000-- From rem-conf Fri Jan 15 09:00:47 1999 From rem-conf-request@es.net Fri Jan 15 09:00:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 101CRE-0006zn-00; Fri, 15 Jan 1999 08:49:36 -0800 Received: from lima.irisa.fr [131.254.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 101CRC-0006zd-00; Fri, 15 Jan 1999 08:49:34 -0800 Received: from irisa.fr (borneo.irisa.fr [131.254.41.54]) by lima.irisa.fr (8.9.1a/8.9.1) with ESMTP id RAA18343; Fri, 15 Jan 1999 17:49:30 +0100 (MET) Message-ID: <369F7169.2279AD19@irisa.fr> Date: Fri, 15 Jan 1999 17:48:41 +0100 From: Christine Guillemot X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: cjk@pi4.informatik.uni-mannheim.de CC: rem-conf@es.net, Paul.Christ@rus.uni-stuttgart.de, wesner@rus.uni-stuttgart.de, Christine.Guillemot@irisa.fr Subject: Re: Payload for MPEG 4 ES ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Chistoph Kuhmuench wrote: > Hello, > we have got some questions concerning the AVT minutes: >> A number of alternatives for the transport of MPEG-4 streams in an IP >> network were considered: >> - directly on UDP >> - RTP followed by a full MPEG-4 SyncLayer packet >> - MPEG-4 SyncLayer packets mapped onto RTP packets >> - MPEG-4 elementary streams over RTP with natural payload >> formats >> The preferred approach would be to use the latter approach, but since >> the ES interface is not a normative part of MPEG-4 this is not possible. >> >> The approach chosen is, therefore, to map the MPEG-4 SyncLayer packets >> onto RTP packets, such that the common pieces of the header reside in >> the RTP header, with a small payload header providing the MPEG-4 >> specific features. A single payload format is therefore used for MPEG-4 >> streams transported within RTP, and the MPEG-4 model is maintained >> (although not the precise packet format). > Are there any ideas for compensating paket loss in the RTP/SL paket > scenario? Due to the lack of specific information about the media type in > the paket, the receiver can not easily recover from paket loss by using > RTP header information. > Therefore, wouldn't it be useful to define at least some MPEG-4 ES > payloads for use in applications that do not use all features of MPEG-4. > Is there any work in progress or is the RTP payload for MPEG-4 SyncLayer > pakets the way to go? At INRIA, together with the university of Stuttgart, we are working toward a payload for transporting directly MPEG-4 ES over RTP, that would also support mechanisms for protection against packet loss. A very preliminary draft has been presented at the IETF AVT Orlando meeting, the corresponding document, currently being amended/updated ... can be found in the IETF site under the name draft-guillemot-genrtp-00.txt. The implementation of this payload for transporting MPEG-4 ES over RTP, for validation purposes, is also in progress in the framework of a European project. Best Regards, Christine Guillemot. > Bye > Gerald Kuehne > Christoph Kuhmuench From rem-conf Sat Jan 16 02:52:06 1999 From rem-conf-request@es.net Sat Jan 16 02:52:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 101TA2-00070m-00; Sat, 16 Jan 1999 02:40:58 -0800 Received: from (mail.pond.net) [192.115.48.168] by mail1.es.net with smtp (Exim 1.81 #2) id 101T9z-00070Y-00; Sat, 16 Jan 1999 02:40:56 -0800 Received: (qmail 7395 invoked from network); 15 Jan 2000 13:32:34 -0000 Received: from unknown (HELO pond.net) (192.168.101.16) by 192.168.102.3 with SMTP; 15 Jan 2000 13:32:34 -0000 From: jackl@pond.net To: jackl@pond.net Subject: Hello Message-Id: Date: Sat, 16 Jan 1999 02:40:56 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DEGREE PROGRAMS ---- Increase your personal prestige and money earning power through an advanced university degree. Eminent, non-accredited universities will award you a degree for only $200. Degree granted based on your present knowledge and experience. No further effort necessary on your part. Just a short phone call is all that is required for a BA, MA, MBA, or PhD diploma in the field of your choice. For details, call 713-866-4087 From rem-conf Sat Jan 16 16:38:09 1999 From rem-conf-request@es.net Sat Jan 16 16:38:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 101g90-0005SI-00; Sat, 16 Jan 1999 16:32:46 -0800 Received: from 203-212-176.ipt.aol.com (Desktop Server 99) [152.203.212.176] by mail1.es.net with smtp (Exim 1.81 #2) id 101g8w-0005S8-00; Sat, 16 Jan 1999 16:32:44 -0800 From: "Best Value of America, Inc." To: Message-Id: <419.436176.80931690Desktop13@hotmail.com> Subject: Marketing Tools for Your Business - Free Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sat, 16 Jan 1999 16:32:44 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Supercharge your computer with Desktop Server 99 and get Atomic Harvester and Bulk Email List Manager Software for FREE Advertise your website or business to thousands of people a day for free! Are you ready to own the most HI-TECH new bulk email software on the net? Advertising with your PC has never been easier!! In the past you had to use your ISP's email server if you wanted to advertise via email. Desktop Server has changed all that forever!! Desktop Server turns your PC into a "Real" Bulk Email server. What does this mean? This means that instead of using your ISP's email server, your computer can now bypass their entire email system and send all mail out directly through your PC. And Desktop Server is fast too, sending up to 20,000 emails per hour on a good connection. Instead of using the email server resources of an internet provider, Desktop Server allows a personal PC to handle the work. Even those who are opposed to advertising via email will find one major benefit to using this software. Desktop Server prevents internet traffic and slow connection speeds. Because users of Desktop Server are not using their internet providers email servers, this type of software helps keep the internet running faster than ever. With so much controversy about what to do about "Bulk Email" in the news lately, Desktop Server offers a reasonable solution. If all email advertisements were sent using Desktop Server, there would be a lot less complaints from people opposed to advertising via Email. Desktop Server could very well be where the future of internet advertising is heading. If you want to supercharge your business and reach many potential customers using free advertising, Desktop Server is a must. SPECIAL OFFER - FREE ATOMIC HARVESTER ADDRESS EXTRACTOR PROGRAM WITH PURCHASE OF ANY EMAIL MARKETING TOOL. ($179 value) ALSO FREE BULK EMAIL LIST MANAGER FOR JUST VISITING MY SITE. To learn more about Desktop Server and other email address collection software and for your FREE copy of Bulk Email List Manager please email. From rem-conf Mon Jan 18 07:42:29 1999 From rem-conf-request@es.net Mon Jan 18 07:42:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102GbA-0003tw-00; Mon, 18 Jan 1999 07:28:16 -0800 Received: from 206-156-249.ipt.aol.com (Desktop Server 99) [152.206.156.249] by mail1.es.net with smtp (Exim 1.81 #2) id 102Gb6-0003tl-00; Mon, 18 Jan 1999 07:28:13 -0800 From: "Best Value of America, Inc." To: Message-Id: <419.436178.43115868Desktop@mygo.com> Subject: Marketing Tools for Your Business - Free Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Mon, 18 Jan 1999 07:28:13 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Supercharge your computer with Desktop Server 99 and get Atomic Harvester and Bulk Email List Manager Software for FREE Advertise your website or business to thousands of people a day for free! Are you ready to own the most HI-TECH new bulk email software on the net? Advertising with your PC has never been easier!! In the past you had to use your ISP's email server if you wanted to advertise via email. Desktop Server has changed all that forever!! Desktop Server turns your PC into a "Real" Bulk Email server. What does this mean? This means that instead of using your ISP's email server, your computer can now bypass their entire email system and send all mail out directly through your PC. And Desktop Server is fast too, sending up to 20,000 emails per hour on a good connection. Instead of using the email server resources of an internet provider, Desktop Server allows a personal PC to handle the work. Even those who are opposed to advertising via email will find one major benefit to using this software. Desktop Server prevents internet traffic and slow connection speeds. Because users of Desktop Server are not using their internet providers email servers, this type of software helps keep the internet running faster than ever. With so much controversy about what to do about "Bulk Email" in the news lately, Desktop Server offers a reasonable solution. If all email advertisements were sent using Desktop Server, there would be a lot less complaints from people opposed to advertising via Email. Desktop Server could very well be where the future of internet advertising is heading. If you want to supercharge your business and reach many potential customers using free advertising, Desktop Server is a must. SPECIAL OFFER - FREE ATOMIC HARVESTER ADDRESS EXTRACTOR PROGRAM WITH PURCHASE OF ANY EMAIL MARKETING TOOL. ($179 value) ALSO FREE BULK EMAIL LIST MANAGER FOR JUST VISITING MY SITE. To learn more about Desktop Server and other email address collection software and for your FREE copy of Bulk Email List Manager please email. From rem-conf Mon Jan 18 15:50:14 1999 From rem-conf-request@es.net Mon Jan 18 15:50:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102OMH-0000km-00; Mon, 18 Jan 1999 15:45:25 -0800 Received: from wombat.cs.rmit.edu.au [131.170.24.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 102OMF-0000kc-00; Mon, 18 Jan 1999 15:45:23 -0800 Received: from goanna.cs.rmit.edu.au (sam@goanna.cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.8.8/8.8.8/cshub) with ESMTP id KAA05325 for ; Tue, 19 Jan 1999 10:45:19 +1100 (EST) Received: (from sam@localhost) by goanna.cs.rmit.edu.au (8.8.8/8.8.8/csnode) id KAA02093 for rem-conf@es.net; Tue, 19 Jan 1999 10:45:17 +1100 (EST) From: Sam Makki Message-Id: <199901182345.KAA02093@goanna.cs.rmit.edu.au> Subject: International Symposium on Distributed Objects and Applications (DOA'99) To: rem-conf@es.net Date: Tue, 19 Jan 1999 10:45:17 +1100 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Our apologies if you have received multiple copies of this CPF. C A L L F O R P A P E R S ============================= ___ __ __ __ __ | | | | | | / |__||__| International Symposium on | | | | |--| / / DISTRIBUTED OBJECTS AND APPLICATIONS _|_| |__| | | / / Edinburgh, 5-6th September, 1999 . To be held in conjunction with VLDB int. conf. . Symposium URL: http://www.cs.rmit.edu.au/conf/doa99 . Publisher: IEEE Press . Sponsor: OMG, RMIT SCOPE ----- There is increasing agreement among IT researchers and practioners about the importance, potential and advances of distributed object systems made in recent years. These systems offer many promises for their use in various applications, including telecommunications and more recently banking applications. Distributed object systems offer solutions to technical problems, including interoperability across different software and database platforms. Distributed object systems are built according to different paradigms and architectures, such as OMG's CORBA and other object request broker principles and implementations, and contingent technologies such as SUN's Java and Microsoft's active objects, to provide a basis for building complex distributed applications. The future success of distributed object systems will be not only dependent on how the basic requirements (to develop open, scalable and reliable distributed and heterogeneous applications and platforms) are met but also how the underlying distributed object technology can be integrated with existing complementary technologies and applications, such as WWW, multimedia and databases. Also legacy systems may sometimes substantially benefit from a reengineering effort using distributed objects, e.g. to turn them into data warehouses. During this symposium we want attendees to be able to evaluate existing ORB middleware products; to propose solutions to major limitations of existing products; and to introduce promising future research directions for distributed objects. We are particularly interested in the evaluation of existing distributed object systems and how they are used to design and to implement large scale industrial distributed applications. We are also seeking theoretical and practical papers addressing innovating issues related to distributed objects. TOPICS OF INTEREST ------------------ The topics of this symposium include, but are not limited to: . Distributed business objects . Distributed and mobile agents . Design patterns for distributed object design . Database services, in particular, persistency, transaction, query and replication services . Intelligent traders . Interoperability supporting environments . Integration with database systems and interfaces . Methodologies to develop distributed object applications, to reintegrate legacy systems, and to design CORBA-based applications . Multimedia distributed objects . Multicast protocols for distributed objects . Object caching . Reliability, fault-tolerance and recovery . Real-time ORB middleware . Security . Specification and enforcement of quality of service . Wrapper libraries and wrapper implementation strategies In order to maximise the benefits of co-location with VLDB'98, authors are asked to give particular emphasis to issues relating to the deployment of distributed object technology in the provision and utilisation of database systems. IMPORTANT DATES --------------- Electronic submission deadline: April 1st, 1999 Notification of acceptance: May 15th, 1999 Camera-ready copies: June 15th, 1999 Symposium: September 5/6th, 1999 SUBMISSION DETAILS ------------------ Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of expression. All papers will be refereed by at least three members of the program committee. Papers should be in English and must not exceed 8000 words. Submissions must be in the form of a single uuencoded compressed PostScript file sent by e-mail to zahirt@cs.rmit.edu.au accompanied by a separate email message with the following information on the paper: . title . author(s) . affiliation(s) . e-mail and address of the contact author Please make sure that your PostScript file can be previewed with GhostScript and is printable on a standard PostScript printer. If electronic submission is not possible, please contact Zahir Tari zahirt@cs.rmit.edu.au to make special arrangements, at least one week before the deadline. The proceedings will be published by IEEE Press. ORGANISING COMMITTEE -------------------- . GENERAL CHAIR Asuman Dogac Middle East Technical University Ankara, Turkey asuman@srdc.metu.edu.tr . PROGRAM COMMITTEE CO-CHAIRS Omran Bukhres (USA) Robert Meersman (Belgium) Zahir Tari (Australia) . ORGANISING CHAIR Peter Thanisch The University of Edinburgh Department of Computer Science Mayfield Road, Edinburgh EH9 3JZ Scotland (Fax) 0131 667 7209 (E-mail) pt@dcs.ed.ac.uk . PUBLICITY CHAIR Sam Makki RMIT Dept. of Computer Science sam@cs.rmit.edu.au . PROGRAM COMMITTEE Gustavo Alonso (ETHZ, Zurich) Bill Appelbe (RMIT, Australia) Jose Blakeley (Microsoft, USA) Anthony Bloesch (Visio, USA) Sjaak Brinkkemper (Baan, The Netherlands) David Curtis (OMG, USA) Klaus Dittrich (University of Zurich, Switzerland) Chris Gokey (NASA, USA) Rachid Guerraoui (EPFL, Switzerland) Slimane Hammoudi (Univ. of Minho, Portugal) Dimitris Karagiannis (University of Vienna and B.O.C. GmbH, Austria) Sacha Krakowiak (University of Grenoble, France) Roger King (University of Collorado, USA) Ling Liu (Oregon Graduate Institute, USA) Frank Manola (Object Services and Consulting, USA) Michele Missikoff (CNR Roma, Italy) Tom Northcutt (NASA, USA) Tamer Ozsu (University of Alberta, Cannada) Mike P. Papazoglou (Tilburg University, The Netherlands) Richard Soley (OMG, USA) Kerry Raymond (DSTC, Australia) Hakki Toroslu (Middle East Technical University, Turkey) Irv Traiger (IBM Santa Teresa Lab, USA) Arkady Zaslavsky (Monash University, Australia) Roberto Zicari (Johann Wolfgang Goethe-Univ., Germany) Wilfried Verachtert (MediaGenix, Belgium) Andreas Vogel (Visigenic Software, USA) Andrew Watson (OMG, USA) SYMPOSIUM ATTENDANCE -------------------- Authors of accepted papers will be expected to present their work at the symposium. Attendees can also register to VLDB'99 conference which will be held early. Details about the VLDB'99 conference can be found at http://www.cs.rmit.edu.au/conf/doa99 From rem-conf Mon Jan 18 20:11:13 1999 From rem-conf-request@es.net Mon Jan 18 20:11:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102SQV-0002jf-00; Mon, 18 Jan 1999 20:06:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 102SQU-0002jU-00; Mon, 18 Jan 1999 20:06:02 -0800 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Mon Jan 18 23:05:50 EST 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.149]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA25146; Mon, 18 Jan 1999 23:05:48 -0500 (EST) Message-ID: <36A40463.A6288007@dnrc.bell-labs.com> Date: Mon, 18 Jan 1999 23:04:51 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Colin Perkins CC: casner@cisco.com, rem-conf@es.net Subject: Parity FEC draft and MIME and SDP References: <1231.916664305@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 In preparation of the parity FEC draft for last call, I ran into two open issues for which we need resolution. Both surround signaling of the use of parity within SDP. Since rfc2198 addresses SDP issues, it seems appropriate for them to be addressed in the parity draft. The first issue is that we need a new MIME type for the parity format. We can either define FEC as a sub-type of application, since it is neither audio or video specific: application/xor or define xor as a subtype of both audio and video: audio/xor video/xor Other names besides xor could be fec or parity. I'd probably vote for parity. With that done, the next issue is how to signal the usage of parity within SDP. Method 1 -------- Since FEC is a separate stream, it makes sense to define it as a new media type: m=fec 12345 RTP/AVP 110 m=audio 12345 RTP/AVP 0 1 a=rtpmap:110 xor/8000/1 This says that the FEC goes to the same port/address as the audio, and its using payload type 110. Problem here is that the m lines are supposed to be top level MIME types, and fec is not a top level MIME type. So, we could alternatively do: m=application 12345 RTP/AVP 110 m=audio 12345 RTP/AVP 0 1 a=rtpmap:110 parity/8000/1 Method 2 --------- This approach is more like rfc2198: m=audio 12345 RTP/AVP 0 1 110 a=rtpmap:110 xor/8000/1 The problem with this is that the FEC can go on a separate multicast group or port from the media itself, which can't be expressed in the above fashion. This is different from rfc2198, where the media and FEC are bound together. If one were using rfc2198 to carry the FEC as a redundant payload, then something like: m=audio 12345 RTP/AVP 121 0 110 a=rtpmap:121 red/8000/1 a=rtpmap:110 xor/8000/1 a=fmtp:121 0/110 seems right. Also, is it useful to indicate the payload types likely to be protected by parity? Something like: a=fmtp:110 0 Would indicate that payload type 0 is protected by FEC (the FEC payload type is 110). Is this needed? So, my proposal would be:: * use application/parity as the MIME type for FEC * use a separate media line, of the form m=application RTP/AVP , and an rtpmap of the form a=rtpmap: parity/8000/1, to indicate FEC. * allow an fmtp line to indicate the set of codecs covered by the FEC * when rfc2198 is used to carry FEC, indicate the FEC as a payload type for one of the redundant codecs, and then use an rtpmap to indicate that the codec is FEC. Comments? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Jan 18 23:01:41 1999 From rem-conf-request@es.net Mon Jan 18 23:01:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102V81-0004P5-00; Mon, 18 Jan 1999 22:59:09 -0800 Received: from whx-ca16-19.ix.netcom.com (hotmail.com) [205.187.202.243] by mail1.es.net with smtp (Exim 1.81 #2) id 102V7y-0004Ou-00; Mon, 18 Jan 1999 22:59:07 -0800 Date: Mon, 18 Jan 1999 23:00:49 -0800 From: "RiskTutor" Message-ID: To: "Rem Conf" Subject: Free Online Underwriting Newsletter X-Mailer: eMerge 1.53 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (To be removed from our mailing list, simply click reply and put REMOVE in the subject) RiskTutor is pleased to provide you with its January 1999 online underwriting newsletter that is the first in a two part series on UNDERWRITING TYPE 2 DIABETES. To read the newsletter simply go to the following Internet address: http://www.risktutor.com/demo/jan_99.html. To receive future issues of this free newsletter, simply register at the following Internet address: http://www.risktutor.com/demo/order_news.html Thank you... RiskTutor, Inc. www.risktutor.com Underwriting Knowledge Systems From rem-conf Tue Jan 19 01:18:10 1999 From rem-conf-request@es.net Tue Jan 19 01:18:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102XCD-00065m-00; Tue, 19 Jan 1999 01:11:37 -0800 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 102XCC-00065a-00; Tue, 19 Jan 1999 01:11:36 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id BAA26135; Tue, 19 Jan 1999 01:10:55 -0800 (PST) Message-Id: <3.0.5.16.19990119010838.2d6f4bd6@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 19 Jan 1999 01:08:38 To: Jonathan Rosenberg From: Ross Finlayson Subject: Re: Parity FEC draft and MIME and SDP Cc: rem-conf@es.net In-Reply-To: <36A40463.A6288007@dnrc.bell-labs.com> References: <1231.916664305@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Actually, I think I prefer your "Method 1" (for the case where FEC is carried as a separate stream): >Since FEC is a separate stream, it makes sense to define it as a new >media type: > >m=fec 12345 RTP/AVP 110 >m=audio 12345 RTP/AVP 0 1 >a=rtpmap:110 xor/8000/1 > >This says that the FEC goes to the same port/address as the audio, and >its using payload type 110. >Problem here is that the m lines are supposed to be top level MIME types I don't think we need to be so anal retentive about this, as m= lines are not actually *used* as MIME types. (Also, is "control" a top-level MIME type?) In this case "fec" clearly describes the medium - one which the SDP-handling application (e.g., session launcher) may know about and choose to handle (or ignore) independently of the audio/video tool. In contrast, "m=application ..." seems pretty pointless - it adds another level of indirection for no particular good reason. Ross. From rem-conf Tue Jan 19 03:33:23 1999 From rem-conf-request@es.net Tue Jan 19 03:33:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102ZMv-0007XR-00; Tue, 19 Jan 1999 03:30:49 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 102ZMt-0007XH-00; Tue, 19 Jan 1999 03:30:48 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 19 Jan 1999 11:30:36 +0000 To: Jonathan Rosenberg cc: casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP In-reply-to: Your message of "Mon, 18 Jan 1999 23:04:51 EST." <36A40463.A6288007@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 11:30:35 +0100 Message-ID: <911.916745435@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: >In preparation of the parity FEC draft for last call, I ran into two >open issues for which we need resolution. Both surround signaling of the >use of parity within SDP. Since rfc2198 addresses SDP issues, it seems >appropriate for them to be addressed in the parity draft. > >The first issue is that we need a new MIME type for the parity format. >We can either define FEC as a sub-type of application, since it is >neither audio or video specific: > >application/xor > >or define xor as a subtype of both audio and video: > >audio/xor >video/xor > >Other names besides xor could be fec or parity. I'd probably vote for >parity. I'd prefer the FEC schemes to be registered under both audio and video, seems to make things easier when defining the SDP. How about audio/parityfec and video/parityfec? >With that done, the next issue is how to signal the usage of parity >within SDP. > >Method 1 >-------- > >Since FEC is a separate stream, it makes sense to define it as a new >media type: > >m=fec 12345 RTP/AVP 110 >m=audio 12345 RTP/AVP 0 1 >a=rtpmap:110 xor/8000/1 > >This says that the FEC goes to the same port/address as the audio, and >its using payload type 110. Problem here is that the m lines are >supposed to be top level MIME types, and fec is not a top level MIME >type. So, we could alternatively do: > >m=application 12345 RTP/AVP 110 >m=audio 12345 RTP/AVP 0 1 >a=rtpmap:110 parity/8000/1 Both of these seem kind-of ugly... what we have is audio protected by FEC, so it makes sense to label it as audio -- that way the tool parsing the SDP knows what sort of media tool to start. >Method 2 >--------- >This approach is more like rfc2198: > >m=audio 12345 RTP/AVP 0 1 110 >a=rtpmap:110 xor/8000/1 > >The problem with this is that the FEC can go on a separate multicast >group or port from the media itself, which can't be expressed in the >above fashion. This is different from rfc2198, where the media and FEC >are bound together. If the FEC is sent as a separate stream, it should have a separate m= line. The problem is linking the FEC stream to the media, but that can be solved with "a=fmtp:" giving the media port to associate the FEC with... m=audio 1234 RTP/AVP 0 1 m=audio 1235 RTP/AVP 110 a=rtpmap:110 xor/8000/1 a=fmtp:110 1234 Not sure how that would work if the media was carried on a different address to the FEC though. Is that something we need to worry about? Colin From rem-conf Tue Jan 19 07:16:06 1999 From rem-conf-request@es.net Tue Jan 19 07:16:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102cn7-0001ws-00; Tue, 19 Jan 1999 07:10:05 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 102cn5-0001wi-00; Tue, 19 Jan 1999 07:10:03 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jan 19 10:08:26 EST 1999 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA27609; Tue, 19 Jan 1999 10:08:25 -0500 (EST) Message-ID: <36A49F5E.81D95F97@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 10:06:06 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP References: <911.916745435@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > >Method 1 > >-------- > > > >Since FEC is a separate stream, it makes sense to define it as a new > >media type: > > > >m=fec 12345 RTP/AVP 110 > >m=audio 12345 RTP/AVP 0 1 > >a=rtpmap:110 xor/8000/1 > > > >This says that the FEC goes to the same port/address as the audio, and > >its using payload type 110. Problem here is that the m lines are > >supposed to be top level MIME types, and fec is not a top level MIME > >type. So, we could alternatively do: > > > >m=application 12345 RTP/AVP 110 > >m=audio 12345 RTP/AVP 0 1 > >a=rtpmap:110 parity/8000/1 > > Both of these seem kind-of ugly... what we have is audio protected by FEC, > so it makes sense to label it as audio -- that way the tool parsing the SDP > knows what sort of media tool to start. The first method would also allow you to know this since the a:fmtp line would indicate which types are being protected by FEC. Its definitely easier, though, if its specifically an m=audio or m=video line, though. > > >Method 2 > >--------- > >This approach is more like rfc2198: > > > >m=audio 12345 RTP/AVP 0 1 110 > >a=rtpmap:110 xor/8000/1 > > > >The problem with this is that the FEC can go on a separate multicast > >group or port from the media itself, which can't be expressed in the > >above fashion. This is different from rfc2198, where the media and FEC > >are bound together. > > If the FEC is sent as a separate stream, it should have a separate m= line. > The problem is linking the FEC stream to the media, but that can be solved > with "a=fmtp:" giving the media port to associate the FEC with... > > m=audio 1234 RTP/AVP 0 1 > m=audio 1235 RTP/AVP 110 > a=rtpmap:110 xor/8000/1 > a=fmtp:110 1234 > > Not sure how that would work if the media was carried on a different > address to the FEC though. Is that something we need to worry about? Once its a separate m line, you can use a c line below the media line to indicate a different address. Also, I don't see the need for identifying the port number of the media in the a=fmtp line; why not indicate the payload type being protected? So then: m=audio 1234 RTP/AVP 0 1 c=IN IP4 224.2.1.1/127 m=audio 1235 RTP/AVP 110 c=IN IP4 224.2.1.2/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 0 This indicates that the FEC is on a group one higher, and port one higher, than the audio, and that the FEC is PTI 110, and it is protecting the audio with payload type 0. audio/parityfec and video/parityfec are fine by me; I agree these are more intuitive than application/parityfec. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Jan 19 08:14:17 1999 From rem-conf-request@es.net Tue Jan 19 08:14:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102dfm-0003E3-00; Tue, 19 Jan 1999 08:06:34 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 102dfk-0003Dt-00; Tue, 19 Jan 1999 08:06:32 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA19855; Tue, 19 Jan 1999 11:06:20 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Jonathan Rosenberg cc: Colin Perkins , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP In-reply-to: Your message of "Tue, 19 Jan 1999 10:06:06 EST." <36A49F5E.81D95F97@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 11:06:20 -0500 Message-ID: <19853.916761980@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Once its a separate m line, you can use a c line below the media line to >indicate a different address. Also, I don't see the need for identifying >the port number of the media in the a=fmtp line; why not indicate the >payload type being protected? So then: > > >m=audio 1234 RTP/AVP 0 1 >c=IN IP4 224.2.1.1/127 >m=audio 1235 RTP/AVP 110 >c=IN IP4 224.2.1.2/127 >a=rtpmap:110 parityfec/8000/1 >a=fmtp:110 0 > >This indicates that the FEC is on a group one higher, and port one >higher, than the audio, and that the FEC is PTI 110, and it is >protecting the audio with payload type 0. This isn't sufficient - I can have more than one audio media in a session, and even have different media with the same dynamic payload type. Eg, the following is valid: m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr m=audio 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 pt=0;addr=224.2.1.1;port=1234 The two audio streams are alternatives, and in this case I've even put them on the same port. In this case you can only distinguish them by address. An alternative is to add a tag attribute: m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en a=tag:1 m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr a=tag:2 m=audio 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 tag=1 The tag attribute would be useful in general, but might be difficult to implement in a backward compatible way because unlike most tags, it's not optional to understand it. Our problem with the mime type is because FEC isn't really a media type, but more analogous to a content-transfer-encoding. I'd be willing to argue for a top-level SDP type of "encoding" to serve this function: m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=tag:1 m=encoding 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 tag=1 This would mean that tools wouldn't mistakenly believe this is a new media stream. It doesn't quite fit with the "SDP-media-type = mime-toplevel-content-type" rule in the SDP spec though, so we might have to issue a new SDP ID including this and stating the exception. Finally, another alternative is to put the FEC information entirely in an fmtp attribute: m=audio 1234 RTP/AVP 0 110 c=IN IP4 224.2.1.1/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 addr=IN/IP4/224.2.1.2;port=1235 In this case there's no possibility of confusing it with being a new medium intended for presentation to the user. However, it's slightly misleading because the FEC data doesn't go to 224.2.1.1/1234 but to 224.2.1.2/1235 Cheers, Mark From rem-conf Tue Jan 19 08:28:53 1999 From rem-conf-request@es.net Tue Jan 19 08:28:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102dvJ-0003kT-00; Tue, 19 Jan 1999 08:22:37 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 102dvH-0003kA-00; Tue, 19 Jan 1999 08:22:35 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 19 Jan 1999 16:20:25 +0000 To: Mark Handley cc: Jonathan Rosenberg , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP In-reply-to: Your message of "Tue, 19 Jan 1999 11:06:20 EST." <19853.916761980@north.lcs.mit.edu> Date: Tue, 19 Jan 1999 16:20:25 +0100 Message-ID: <2008.916762825@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Mark Handley writes: ... >An alternative is to add a tag attribute: > >m=audio 1234 RTP/AVP 0 >c=IN IP4 224.2.1.1/127 >a=lang:en >a=tag:1 >m=audio 1234 RTP/AVP 0 >c=IN IP4 224.2.1.2/127 >a=lang:fr >a=tag:2 >m=audio 1235 RTP/AVP 110 >c=IN IP4 224.2.1.3/127 >a=rtpmap:110 parityfec/8000/1 >a=fmtp:110 tag=1 > >The tag attribute would be useful in general, but might be difficult >to implement in a backward compatible way because unlike most tags, >it's not optional to understand it. Or maybe... m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en a=tag:1 m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr a=tag:2 m=audio 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 a=depends-on-tag:1 which allows to indicate that the FEC is only useful if a particular media stream is also being received. We could also do "a=alternative-to-tag:" to make that explicit, giving: m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en a=tag:1 a=alternative-to-tag:2 m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr a=tag:2 a=alternative-to-tag:1 m=audio 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 a=depends-on-tag:1 Okay, we need to think of shorter a= names, but is the idea sensible? Colin From rem-conf Tue Jan 19 08:51:23 1999 From rem-conf-request@es.net Tue Jan 19 08:51:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102eJu-0004cX-00; Tue, 19 Jan 1999 08:48:02 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 102eJt-0004cN-00; Tue, 19 Jan 1999 08:48:01 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Tue Jan 19 11:46:16 EST 1999 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA28274; Tue, 19 Jan 1999 11:46:15 -0500 (EST) Message-ID: <36A4B64B.66E687B@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 11:43:55 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: Mark Handley , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP References: <2008.916762825@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > --> Mark Handley writes: > ... > >An alternative is to add a tag attribute: > > > >m=audio 1234 RTP/AVP 0 > >c=IN IP4 224.2.1.1/127 > >a=lang:en > >a=tag:1 > >m=audio 1234 RTP/AVP 0 > >c=IN IP4 224.2.1.2/127 > >a=lang:fr > >a=tag:2 > >m=audio 1235 RTP/AVP 110 > >c=IN IP4 224.2.1.3/127 > >a=rtpmap:110 parityfec/8000/1 > >a=fmtp:110 tag=1 > > > >The tag attribute would be useful in general, but might be difficult > >to implement in a backward compatible way because unlike most tags, > >it's not optional to understand it. > > Or maybe... > > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.1/127 > a=lang:en > a=tag:1 > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.2/127 > a=lang:fr > a=tag:2 > m=audio 1235 RTP/AVP 110 > c=IN IP4 224.2.1.3/127 > a=rtpmap:110 parityfec/8000/1 > a=fmtp:110 > a=depends-on-tag:1 > > which allows to indicate that the FEC is only useful if a particular media > stream is also being received. > > We could also do "a=alternative-to-tag:" to make that explicit, giving: > > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.1/127 > a=lang:en > a=tag:1 > a=alternative-to-tag:2 > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.2/127 > a=lang:fr > a=tag:2 > a=alternative-to-tag:1 > m=audio 1235 RTP/AVP 110 > c=IN IP4 224.2.1.3/127 > a=rtpmap:110 parityfec/8000/1 > a=fmtp:110 > a=depends-on-tag:1 > > Okay, we need to think of shorter a= names, but is the idea sensible? I'm not clear on the purpose of the alternative-to-tag attribute. Are you saying that its purpose is to indicate that the first and second media streams are alternatives? Another way to associate the fec stream to the media stream is implicitly by positioning; if a media stream thats FEC exists, it is associated with the m line above it. So: m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 m=audio 1234 RTP/AVP 110 a=rtpmap:110 parityfec/8000/1 c=IN IP4 224.1.2.3/127 m=audio 1235 RTP/AVP 0 c=IN IP4 224.2.1.1/127 m=audio 1235 RTP/AVP 110 a=rtpmap:110 parityfec/8000/1 c=IN IP4 224.1.2.3/127 There is then no ambiguity. The first audio FEC stream is associated with the media on port 1234, and the second for the media on port 1235. This avoids the messy use of tags. I think this is still backwards compatible. A tool that doesn't understand FEC might think there are four media streams, but anyway won't be able to parse the two FEC ones since they use a codec that is not understood (parityfec). In fact, same should hold true for the tag solutions. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Jan 19 08:51:23 1999 From rem-conf-request@es.net Tue Jan 19 08:51:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102eJl-0004cJ-00; Tue, 19 Jan 1999 08:47:53 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 102eJj-0004c8-00; Tue, 19 Jan 1999 08:47:51 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA19939; Tue, 19 Jan 1999 11:47:32 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Colin Perkins cc: Jonathan Rosenberg , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP In-reply-to: Your message of "Tue, 19 Jan 1999 16:20:25 +0100." <2008.916762825@cs.ucl.ac.uk> Date: Tue, 19 Jan 1999 11:47:32 -0500 Message-ID: <19937.916764452@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Or maybe... > >m=audio 1234 RTP/AVP 0 >c=IN IP4 224.2.1.1/127 >a=lang:en >a=tag:1 >m=audio 1234 RTP/AVP 0 >c=IN IP4 224.2.1.2/127 >a=lang:fr >a=tag:2 >m=audio 1235 RTP/AVP 110 >c=IN IP4 224.2.1.3/127 >a=rtpmap:110 parityfec/8000/1 >a=fmtp:110 >a=depends-on-tag:1 > >which allows to indicate that the FEC is only useful if a particular media >stream is also being received. Something we've been bad at in the past, but we need to be careful to find the right split between what we expect from the sdp-tool and what we expect from the media tool. In this case, I read your use of the depends-on-tag attribute to mean that there's a constraint on receiving the medium that we must also receive this other medium. Fine so far. But this is a general SDP thing, and is not FEC specific. What you want is *additionally* for the FEC decoder to have access to the information about the stream it depends on. If you want to have the depends-on-tag attribute to have generic meaning, you probably don't want to overload it's meaning in the context of FEC. I'd prefer something that specifies both relationships separately, and also avoids using the audio media type. m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en a=tag:1 m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr a=tag:2 m=encoding 1235 RTP/AVP 110 c=IN IP4 224.2.1.3/127 a=rtpmap:110 parityfec/8000/1 a=fmtp:110 tag=1 a=req:1 This is rather getting off the original topic, but: >We could also do "a=alternative-to-tag:" to make that explicit, >giving: An alternative way to phrase the same thing is to have a attribute that specifies a group-of-alternatives. Then you don't need the tag field unless it's required by something else. m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.1/127 a=lang:en a=goa:1 m=audio 1234 RTP/AVP 0 c=IN IP4 224.2.1.2/127 a=lang:fr a=goa:1 Anything with the same goa tag is one of a set of alternative streams. You realise this is a slippery slope... Cheers, Mark From rem-conf Tue Jan 19 09:00:34 1999 From rem-conf-request@es.net Tue Jan 19 09:00:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102eUa-0005S7-00; Tue, 19 Jan 1999 08:59:04 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 102eUZ-0005Ru-00; Tue, 19 Jan 1999 08:59:03 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA19976; Tue, 19 Jan 1999 11:58:54 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Jonathan Rosenberg cc: Colin Perkins , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP In-reply-to: Your message of "Tue, 19 Jan 1999 11:43:55 EST." <36A4B64B.66E687B@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 11:58:54 -0500 Message-ID: <19974.916765134@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Another way to associate the fec stream to the media stream is >implicitly by positioning; if a media stream thats FEC exists, it is >associated with the m line above it. So: > >m=audio 1234 RTP/AVP 0 >c=IN IP4 224.2.1.1/127 >m=audio 1234 RTP/AVP 110 >a=rtpmap:110 parityfec/8000/1 >c=IN IP4 224.1.2.3/127 >m=audio 1235 RTP/AVP 0 >c=IN IP4 224.2.1.1/127 >m=audio 1235 RTP/AVP 110 >a=rtpmap:110 parityfec/8000/1 >c=IN IP4 224.1.2.3/127 Unfortunately the SDP semantics give no meaning to the ordering of the media, and in this case there's no way for the SDP parser to know that the second medium is not a medium to be presented to the user at all. With hindsight, we made a number of mistakes with SDP, and one of them is that too much of the meaning is implicit. If we need to add semantics, I would like to see the semantics as explicit as possible given the limitations of the syntax. Cheers, Mark From rem-conf Tue Jan 19 09:31:33 1999 From rem-conf-request@es.net Tue Jan 19 09:31:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102ew5-0006uD-00; Tue, 19 Jan 1999 09:27:29 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 102ew4-0006u3-00; Tue, 19 Jan 1999 09:27:28 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA19270; Tue, 19 Jan 1999 09:27:27 -0800 (PST) Message-Id: <3.0.3.32.19990119092743.00aab200@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Jan 1999 09:27:43 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder 1/20 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Simplifying the Controls of an Interactive Movie Game (Wednesday January 20, 1999 12:30-2:00 PDT 405 Soda Hall) Jeff Johnson UI Wizards, Inc. Eight months before an interactive movie game was due to be shipped, its developers and funders decided that its user interface had to be radically simplified. The author was given the task of designing a new, simpler control scheme. This paper describes the redesign process, the design issues that arose and how they were resolved, the tests that were conducted to evaluate new design ideas, and concludes with an evaluation of the resulting design, lessons learned, and thoughts on user-interface design vs. game design. Reference: Johnson, J., Simplifying the Controls of an Interactive Movie Game, Proceedings of ACM CHI'98, pages 65-72. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Jan 19 17:36:50 1999 From rem-conf-request@es.net Tue Jan 19 17:36:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102mIq-0003sh-00; Tue, 19 Jan 1999 17:19:28 -0800 Received: from sgi.com [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 102mIo-0003sX-00; Tue, 19 Jan 1999 17:19:26 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA07205 for <@sgi.engr.sgi.com:rem-conf@es.net>; Tue, 19 Jan 1999 17:19:25 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id RAA37576 for <@cthulhu.engr.sgi.com:rem-conf@es.net>; Tue, 19 Jan 1999 17:19:24 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA07413; Tue, 19 Jan 1999 17:19:23 -0800 From: "Ram Kordale" Message-Id: <9901191719.ZM7411@relic.engr.sgi.com> Date: Tue, 19 Jan 1999 17:19:23 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: RTSP keep-alives? Cc: kordale@relic.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I could not find any relevant discussion in the confctrl and rem-conf archives. So, I am posting this here... Am I right in stating that an RTSP session is kept alive at a server until one of the following happens: (1) A TEARDOWN is received for that session (2) There is no activity on the RTSP channel for a period specified in the timeout parameter in the Session response header (or a default of 60 seconds) I fail to see the usefulness of (2) given that you can expect long periods of inactivity on the control channel in applications using RTSP (for example, when users watch movies). Moreover, many of the "dumb boxes" (like many settop boxes) do not send TEARDOWN messages when users switch them off. One way to solve this problem would be to have clients send periodic keep-alive messages. Any comments? -- Ram Kordale Advanced Media Products From rem-conf Tue Jan 19 18:53:17 1999 From rem-conf-request@es.net Tue Jan 19 18:53:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 102ngY-0004qL-00; Tue, 19 Jan 1999 18:48:02 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 102ngX-0004q5-00; Tue, 19 Jan 1999 18:48:01 -0800 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Tue Jan 19 21:46:11 EST 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.3]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA15440; Tue, 19 Jan 1999 21:46:09 -0500 (EST) Message-ID: <36A5433A.6DF9561C@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 21:45:14 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Mark Handley CC: Colin Perkins , casner@cisco.com, rem-conf@es.net Subject: Re: Parity FEC draft and MIME and SDP References: <19937.916764452@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Handley wrote: > > >which allows to indicate that the FEC is only useful if a particular media > >stream is also being received. > > Something we've been bad at in the past, but we need to be careful to > find the right split between what we expect from the sdp-tool and what > we expect from the media tool. > > In this case, I read your use of the depends-on-tag attribute to mean > that there's a constraint on receiving the medium that we must also > receive this other medium. Fine so far. But this is a general SDP > thing, and is not FEC specific. What you want is *additionally* for > the FEC decoder to have access to the information about the stream it > depends on. If you want to have the depends-on-tag attribute to have > generic meaning, you probably don't want to overload it's meaning in > the context of FEC. > > I'd prefer something that specifies both relationships separately, and > also avoids using the audio media type. > > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.1/127 > a=lang:en > a=tag:1 > m=audio 1234 RTP/AVP 0 > c=IN IP4 224.2.1.2/127 > a=lang:fr > a=tag:2 > m=encoding 1235 RTP/AVP 110 > c=IN IP4 224.2.1.3/127 > a=rtpmap:110 parityfec/8000/1 > a=fmtp:110 tag=1 > a=req:1 > If indeed you believe there are two separate things here - (1) that stream a depends on stream b, and (2) the FEC is over stream b, I'd rather stick to solving just the problem at hand instead of doing the other more general extension. So, how about: * using the encoding m line to indicate FEC * add a tag attribute for other m lines * define the fmtp line to indicate which media stream (via the tag) is being protected If we do more general extensions later (group of alternatives) we need the tags anyway and they can be used for that too. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Jan 20 13:23:34 1999 From rem-conf-request@es.net Wed Jan 20 13:23:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1034vs-00058q-00; Wed, 20 Jan 1999 13:13:00 -0800 Received: from f264.hotmail.com (hotmail.com) [207.82.251.155] by mail1.es.net with smtp (Exim 1.81 #2) id 1034vr-000580-00; Wed, 20 Jan 1999 13:12:59 -0800 Received: (qmail 2452 invoked by uid 0); 20 Jan 1999 21:11:51 -0000 Message-ID: <19990120211151.2451.qmail@hotmail.com> Received: from 204.178.20.14 by www.hotmail.com with HTTP; Wed, 20 Jan 1999 13:11:50 PST X-Originating-IP: [204.178.20.14] From: "Ethendranath Bommaiah" To: kordale@relic.engr.sgi.com, rem-conf@es.net Cc: ethen@dnrc.bell-labs.com Subject: Re: RTSP keep-alives? Date: Wed, 20 Jan 1999 13:11:50 PST Mime-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Current implementation of RTSP in Real G2 player/server uses ping messages from the server to the client. The ping message looks something like: SET_PARAMETER * RTSP/1.0 CSeq: 1 Ping: Pong the response to which looks like: RTSP/1.0 451 Parameter Not Understood CSeq: 1 Date: Sat, 12 Dec 1998 18:51:08 GMT Server is taking the initiative here which is probably okay -- what if the client is down ? Also, in case of playing long movies, the server should probably set the timer for timeout only after playing out the whole movie. If RTCP receiver reports are not received from the receiver, then maybe you should stop playing out the movie (on RTP) and start RTSP timer ? In some sense RTCP receiver reports serve as keep-alive messages for both RTSP and RTP. If RTCP is not supported, then we need RTSP keep alive messages -- which I guess should be server initiated. Ethen >I could not find any relevant discussion in the confctrl and rem-conf archives. >So, I am posting this here... > >Am I right in stating that an RTSP session is kept alive at a server until one >of the following happens: > (1) A TEARDOWN is received for that session > (2) There is no activity on the RTSP channel for a period specified in the > timeout parameter in the Session response header (or a default of 60 > seconds) > >I fail to see the usefulness of (2) given that you can expect long periods of >inactivity on the control channel in applications using RTSP (for example, when >users watch movies). > >Moreover, many of the "dumb boxes" (like many settop boxes) do not send >TEARDOWN messages when users switch them off. > >One way to solve this problem would be to have clients send periodic keep-alive >messages. > >Any comments? > >-- >Ram Kordale >Advanced Media Products > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Wed Jan 20 15:17:53 1999 From rem-conf-request@es.net Wed Jan 20 15:17:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1036px-0006if-00; Wed, 20 Jan 1999 15:15:01 -0800 Received: from sgi.com [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 1036pv-0006iR-00; Wed, 20 Jan 1999 15:14:59 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09003; Wed, 20 Jan 1999 15:14:43 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA31673; Wed, 20 Jan 1999 15:14:42 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08742; Wed, 20 Jan 1999 15:14:41 -0800 From: "Ram Kordale" Message-Id: <9901201514.ZM8740@relic.engr.sgi.com> Date: Wed, 20 Jan 1999 15:14:41 -0800 In-Reply-To: "Ethendranath Bommaiah" "Re: RTSP keep-alives?" (Jan 20, 1:11pm) References: <19990120211151.2451.qmail@hotmail.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Ethendranath Bommaiah" , rem-conf@es.net Subject: Re: RTSP keep-alives? Cc: ethen@dnrc.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yes. We can overload existing calls. The spec suggests using GET_PARAMETER with no entity body for this purpose as well. I was actually asking why keep-alives are not explicit as in RFC 2068. Using RTCP reports for keep-alives is not exactly a good idea for two reasons: 1) RTP data transport cannot be assumed. 2) Having the RTCP channel close the RTSP session initiated by the RTSP channel does not exactly make for good software either. Thanks for your input. Ram On Jan 20, 1:11pm, Ethendranath Bommaiah wrote: > Subject: Re: RTSP keep-alives? > > Current implementation of RTSP in Real G2 player/server uses ping > messages from the server to the client. The ping message looks > something like: > SET_PARAMETER * RTSP/1.0 > CSeq: 1 > Ping: Pong > > the response to which looks like: > RTSP/1.0 451 Parameter Not Understood > CSeq: 1 > Date: Sat, 12 Dec 1998 18:51:08 GMT > > Server is taking the initiative here which is probably okay -- what > if the client is down ? Also, in case of playing long movies, the server > should probably set the timer for timeout only after playing out the > whole movie. If RTCP receiver reports are not received from > the receiver, then maybe you should stop playing out the movie (on > RTP) and start RTSP timer ? In some sense RTCP receiver reports serve > as keep-alive messages for both RTSP and RTP. If RTCP is not supported, > then we need RTSP keep alive messages -- which I guess > should be server initiated. > > Ethen > -- Ram Kordale Advanced Media Products From rem-conf Wed Jan 20 18:03:26 1999 From rem-conf-request@es.net Wed Jan 20 18:03:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1039QM-0000jx-00; Wed, 20 Jan 1999 18:00:46 -0800 Received: from hplms26.hpl.hp.com [15.255.168.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 1039QK-0000jm-00; Wed, 20 Jan 1999 18:00:44 -0800 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by hplms26.hpl.hp.com (8.9.1a/HPL-PA Relay) with ESMTP id RAA03984; Wed, 20 Jan 1999 17:59:33 -0800 (PST) Received: from hplvdb (hplvdb.hpl.hp.com [15.4.88.163]) by hplms2.hpl.hp.com (8.8.6/8.8.6 HPLabs Hub) with SMTP id RAA27654; Wed, 20 Jan 1999 17:59:30 -0800 (PST) Reply-To: From: "Christian J. van den Branden Lambrecht" To: "Christian J. van den Branden Lambrecht" Subject: Session on Internet Telephony at the '99 SPIE Intl Symposium on Voice, Video, and Data Communications Date: Wed, 20 Jan 1999 17:59:29 -0800 Message-ID: <000d01be44e1$ae898110$a358040f@hplvdb.hpl.hp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01BE449E.A0557830" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MS-TNEF-Correlator: 00000000ED3442077888D11197E20060B08672E0A4796200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BE449E.A0557830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SPIE's International Symposium on Voice, Video, and Data Communications Conference on Multimedia Systems and Applications II (vv06) Session on Standards and Systems for Internet Telephony Dear Colleagues, We are organizing a session to be held within the conference on Multimedia Systems and Applications II of the SPIE's International Symposium on Voice, Video, and Data Communications. The session is intended to gather topical papers discussing Internet Telephony systems and standards. The session is meant to be tutorial and discuss all the aspects of internet telephony systems, including but not limited to: - H.323 protocol stack, - IETF standards for internet telephony, - Network management for internet telephony, - Signaling, - Audio compression, - Gateways/Gatekeepers, - Quality of Service management, - Interoperability. We are seeking to bring together researchers and practitioners and we are looking for review or tutorial papers as well as contributions describing original work. We are now soliciting contributions for this particular session. The timetable is as follows: Abstract due date: February 22, 1999 Abstract due date for on-site proceedings: February 8, 1999 Manuscript due date: August 23, 1999 Manuscript due date for on-site proceedings: June 28, 1999 The conference will be held in Boston, MA, September 19-22, 1999 at the Hynes Convention Center. Further information, call for papers, etc. can be found at http://www.spie.org/info/vv/. Further information for this session can be obtained by email to vdb@hpl.hp.com. Please feel free to forward this announcement to any interested person. ============================================================= Christian J. van den Branden Lambrecht Voice: 650-857-7658 Hewlett-Packard Laboratories Fax: 650-857-4691 1501 Page Mill Road, MS 1U20 Email: vdb@hpl.hp.com Palo Alto, CA 94304 vdb@ieee.org ============================================================= ------=_NextPart_000_000A_01BE449E.A0557830 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ih0BAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM8HAQAUABEAOwAAAAMAOgEB A5AGAFgKAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAZgAAAFNlc3Npb24gb24gSW50ZXJuZXQgVGVsZXBob255IGF0IHRoZSAnOTkgU1BJRSBJbnRs IFN5bXBvc2l1bSBvbiBWb2ljZSwgVmlkZW8sIGFuZCBEYXRhIENvbW11bmljYXRpb25zAAAAAgFx AAEAAAAWAAAAAb5E4a2PuDPHUrDSEdKYigBgsIZy4AAAAgEdDAEAAAAUAAAAU01UUDpWREJASFBM LkhQLkNPTQALAAEOAAAAAEAABg4ACq+c4US+AQIBCg4BAAAAGAAAAAAAAADtNEIHeIjREZfiAGCw hnLgwoAAAAsAHw4BAAAAAwAGEOvSyYgDAAcQdAYAAB4ACBABAAAAZQAAAFNQSUVTSU5URVJOQVRJ T05BTFNZTVBPU0lVTU9OVk9JQ0UsVklERU8sQU5EREFUQUNPTU1VTklDQVRJT05TQ09ORkVSRU5D RU9OTVVMVElNRURJQVNZU1RFTVNBTkRBUFBMSUMAAAAAAgEJEAEAAACiBQAAngUAAA0KAABMWkZ1 2fkvkQMACgByY3BnMTI1FjIA+Atgbg4QMDMz6QFVMzYB6CACpANjAgCIcHJxDlBmY2gKwOBzZXQw IAdtAoMAUP8EVRFzE8ER9whVB7ICgxHBbwPjEdkHEwKAfQqACMggqjsJbzAY72UOMDUCgFkKgXVj AFALA2MAQXU0bG4CIGULpgYAUEk0RScEIEkCMASRYXSeaQIgB0AGAAbAcG8AkDh1bSACIAqiCoBW b0EN4GUsIFZpAQBvoyAwAHBkIEQeQGEVUehtbXUDAGMeQxbQH5PzH4QIUG5mBJAJ8CAQH1FvBdAc gB5QB4BkBzAesXPNHgBtBCAgwkFwC1AhtgEd0EkgKHZ2MDa+KSI6BmAEEB5hI5JTAZD/INALESTk JIYCEAXAHeQSQEEScGVsZXBoAiB5WSI6RGUKwQhQbCpgYdJnClBzLCI6VyOACsBJI4FyZwBwaXoL gGcNILAgEjAnhHRvIGKdI4BoKlAg4APwdGgLgHsvAC9wIAWgIx8kLyU/b/5mMCMdfx6OIEAf/yEP AID+LhJwMEEulgQAOXA0sTdAvwmALwIt4DAxBcAvEHAhsXsDIAqwcASQBCAxwATwdfcngS5BKb95 LoAyGTIgKDWfOK8HgABwBUAvFHR1LxA/ByI3IzvVNyAsADAjYXP5O4BjdAQgM8E5sinzNMB3PT02 oAuAYwpAMcAuQWLdQOAgHKAFQCVwbS/QOhMCOh+ELSBILjMyPjM7UANgLxAI4T5iY2vnLIVHQDRQ VEY+aCljQ1+meUinB8B0dwWwa0AAfwBwLDAyQAnwBUBKL0s8U9xpZx6BLjFIp0FFUS8g3wWgHuAZ ACeDSKdHNQAH0OphMhAvUfJrCeA7gkindFF1T3F0PZAzwQZhdv82cUyJSKg0sjrwBJABoAMQ/VQB LiyfOOJSsC4yLxIFEP9Ys0zQOpNQ8SuhEfA7kjcy3xGQANA1EDUSWoZ3LWQJAP5vWJMpchkAVKAH 0QWxQNe/O2VCoFwRQjFe8TBxdAUQf0WxJcMBAATyVsAuQUEBZ38LgB6RTEI/AC1VHKAH4HP/BvAN 4FtRLkFfrClyL+EEIP8KsTUQPAALYAXALpU/BDGCfwGRKmA5cl7xAhAsAGKgc/NG1R+EQWIyIFsS O8AKUB87wFIBRtAMk2n4IEZlS1kQU9ByPZAyMjagMb45a8BoX2lkKWMCIC0AkH9tQUfBNoAxsQ8g Z9Fqbzj9a5pNAHA8EAUEaU9u91BQ9yxAMiBrYDNwL3E8bW9uf/ZKIZAxADJwGx+EOMIwee8D8EIx L0YwAUIfAC8QUVD9BdBBNqAGYAUwMkAvQAXAPWuwLWt2NyBAUTBBSHm3HMAEICLxdk0BJ6JDTQH7 BJBXK0YIcDqTC4ApcQDA/zUSNqA7IQMgKXI7ZDagEkD+Yz8AIcADoC9BAhAhkDdQP31xHDEOUByA L2ACQHA6aC8vd4TALkKwCJAuVS3BL4CiLyZQLxw5ID8/AIAvMSFkZy6WgtVvYvcBkAuAOhFiPZAy QAtwQkFBLyB2ZGJAaAtQLu2LQC5QsVcrUCwREjApYP8J4IGhCdEvAilxUjALIGSU/wBwHKAhkDaA TPMvEQBwPZD/TYMHkEZyO4Jl8SI1AEEiSb49kn+Tj5SflTcilWgFENcyIAcwA6BKPwB2A5EBAM97 MVagOfEDoExhBtAZAAcR8AVANkQ6IDY1MEAtODU3LTeZkDidH4RIB9AqYAJALVBIcX+OMphwBuBW oEDyB5Gce0ZEYXiZeDQ2OZGlMfmZoDEgmzBM0AXQemIIAMxhZHuxBfAxVR1BnHl+RYqCmXCLDIxV B0AvIEEDMXA3AUNBIDk0M/wwNJx8nHyLAgiQCeCFQv+SH6evqL+VT5E1C8OaRRvmXwLRFmIMAR+T GAEArcAAAAMAEBAAAAAAAwAREAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA AoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA APATAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUAAwAmgAggBgAAAAAA wAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAI IAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAA AAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAA AQAAAAAAAAALAMaACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsAyIALIAYAAAAAAMAAAAAA AABGAAAAAAWIAAAAAAAACwDqgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAPCACCAGAAAA AADAAAAAAAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAO00Qgd4iNERl+IAYLCGcuACAfoPAQAA ABAAAADtNEIHeIjREZfiAGCwhnLgAgH7DwEAAABaAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBT VFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcdXNlcnNcdmRiXG91dGxvb2tcbWFp bGJveC5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBFRDM0NDIwNzc4 ODhEMTExOTdFMjAwNjBCMDg2NzJFMEE0Nzk2MjAwAAAAACup ------=_NextPart_000_000A_01BE449E.A0557830-- From rem-conf Thu Jan 21 07:16:00 1999 From rem-conf-request@es.net Thu Jan 21 07:15:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 103LgJ-000663-00; Thu, 21 Jan 1999 07:06:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 103LgI-00065t-00; Thu, 21 Jan 1999 07:06:02 -0800 Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Thu Jan 21 10:05:16 EST 1999 Received: from localhost (ethen@localhost) by chair.dnrc.bell-labs.com (8.8.8/8.8.8) with SMTP id KAA04106; Thu, 21 Jan 1999 10:05:13 -0500 (EST) Date: Thu, 21 Jan 1999 10:05:12 -0500 (EST) From: Ethendranath Bommaiah X-Sender: ethen@chair Reply-To: Ethendranath Bommaiah To: Ram Kordale cc: Ethendranath Bommaiah , rem-conf@es.net Subject: Re: RTSP keep-alives? In-Reply-To: <9901201514.ZM8740@relic.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 20 Jan 1999, Ram Kordale wrote: > Using RTCP reports for keep-alives is not exactly a good idea for two reasons: > 1) RTP data transport cannot be assumed. > 2) Having the RTCP channel close the RTSP session initiated by the RTSP channel > does not exactly make for good software either. I agree with you that failures should be detected by RTSP independent of data channel. But they are not totally independent: If the client suffers buffer underflow (detected on data channel) because of net congestion or server failure, client might want to sent an RTSP message to the server... this might happen much before keep-alive timer at client expires. On Jan 20, 1:11pm, Ethendranath Bommaiah wrote: > > Server is taking the initiative here which is probably okay -- what > > if the client is down ? ^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ Ooops ! I guess RTSP keep-alive timers should be maintained at both client and the server...and when they expire they could send ping messages to the other party before tearing the connection down ?? (to handle network failures) Thanks, Ethen From rem-conf Thu Jan 21 10:24:13 1999 From rem-conf-request@es.net Thu Jan 21 10:24:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 103Ohf-0000vg-00; Thu, 21 Jan 1999 10:19:39 -0800 Received: from sgi.com [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 103Ohe-0000vV-00; Thu, 21 Jan 1999 10:19:38 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA00134; Thu, 21 Jan 1999 10:19:37 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA48895; Thu, 21 Jan 1999 10:19:36 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA09721; Thu, 21 Jan 1999 10:19:35 -0800 From: "Ram Kordale" Message-Id: <9901211019.ZM9719@relic.engr.sgi.com> Date: Thu, 21 Jan 1999 10:19:35 -0800 In-Reply-To: "Ethendranath Bommaiah" "Re: RTSP keep-alives?" (Jan 20, 1:11pm) References: <19990120211151.2451.qmail@hotmail.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Ethendranath Bommaiah" , rem-conf@es.net Subject: Re: RTSP keep-alives? Cc: ethen@dnrc.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Jan 20, 1:11pm, Ethendranath Bommaiah wrote: > Subject: Re: RTSP keep-alives? > > Current implementation of RTSP in Real G2 player/server uses ping > messages from the server to the client. The ping message looks > something like: > SET_PARAMETER * RTSP/1.0 > CSeq: 1 > Ping: Pong > > the response to which looks like: > RTSP/1.0 451 Parameter Not Understood > CSeq: 1 > Date: Sat, 12 Dec 1998 18:51:08 GMT > > Server is taking the initiative here which is probably okay -- what According to the spec, this will not necessarily work since the client is not required to have a persistent transport connection for the length of the RTSP session. > > Using RTCP reports for keep-alives is not exactly a good idea for two reasons: > > 1) RTP data transport cannot be assumed. > > 2) Having the RTCP channel close the RTSP session initiated by the RTSP channel > > does not exactly make for good software either. > > I agree with you that failures should be detected by RTSP independent of > data channel. But they are not totally independent: If the client suffers > buffer underflow (detected on data channel) because of net congestion or > server failure, client might want to sent an RTSP message to the server... > this might happen much before keep-alive timer at client expires. > Yes. This is a reasonable argument albeit only for the client side. Periodic "RTSP keep-alives" from the client based on a "keep-alive" header in the server's response to SETUP seems to be a clean solution in the general case(regardless of data transport protocol etc.). Ram -- Ram Kordale Advanced Media Products From rem-conf Fri Jan 22 20:38:59 1999 From rem-conf-request@es.net Fri Jan 22 20:38:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 103ugP-0000re-00; Fri, 22 Jan 1999 20:28:29 -0800 Received: from mx02.together.net [204.97.120.62] by mail1.es.net with esmtp (Exim 1.81 #2) id 103ugL-0000r0-00; Fri, 22 Jan 1999 20:28:25 -0800 Received: from sequoia.together.net (sequoia.together.net [204.97.120.25]) by mx02.together.net (8.8.8/8.8.8) with ESMTP id XAA22044; Fri, 22 Jan 1999 23:27:24 -0500 Received: from [208.13.204.194] (dial-66-MAX-RIQC-01.ramp.together.net [208.13.204.194]) by sequoia.together.net (8.8.8/8.8.8) with ESMTP id PAA14285; Fri, 22 Jan 1999 15:54:46 -0500 (EST) Date: Fri, 22 Jan 1999 15:54:46 -0500 (EST) X-Sender: portfoli@together.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: video Dubbing:; From: dawnc@TOGETHER.NET Subject: complete solution to your VIDEO DUPLICATION needs X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We at MIRRORCOM DUPLICATION would like to thank you for opening and reading this E-mail. The purpose of it is to introduce our self's to you or your company as the complete solution to your VIDEO DUPLICATION needs. Our goal is to provide our clients with the best rates possible for VHS dubs, Custom package design, and fulfillment of product. Please visit our web site at: http://www.together.net/~dawnc for more information about us. Or contact us at: 819-868-0428 . Once again thank you for your time. From rem-conf Sat Jan 23 08:37:26 1999 From rem-conf-request@es.net Sat Jan 23 08:37:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1045vb-0005Y7-00; Sat, 23 Jan 1999 08:28:55 -0800 Received: from mx01.together.net [204.97.120.61] by mail1.es.net with esmtp (Exim 1.81 #2) id 1045vX-0005XS-00; Sat, 23 Jan 1999 08:28:52 -0800 Received: from sequoia.together.net (sequoia.together.net [204.97.120.25]) by mx01.together.net (8.8.7/8.8.8) with ESMTP id LAA29274; Sat, 23 Jan 1999 11:28:18 -0500 Received: from together.net (dial-53-MAX-RIQC-01.ramp.together.net [208.13.204.181]) by sequoia.together.net (8.8.8/8.8.8) with SMTP id KAA23009; Fri, 22 Jan 1999 10:34:29 -0500 (EST) Message-ID: <354113E4.26D18FD6@together.net> Date: 22/01/99 From: MIRRORCOM DUPLICATION MIME-Version: 1.0 Subject: complete solutions Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx01.together.net id LAA29274 Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We at MIRRORCOM DUPLICATION would like to thank you for opening and readi= ng this E-mail. The purpose of it is to introduce our self=D5s to you or = your company as the complete solution to your VIDEO DUPLICATION needs. Ou= r goal is to provide our clients with the best rates possible for VHS dub= s, Custom package design, and fulfillment of product. Please visit our we= b site at: www.together.net/~dawnc for more information about us. Or contact us at: 819-868-0428 . Once again thank you for your time. From rem-conf Sun Jan 24 04:33:18 1999 From rem-conf-request@es.net Sun Jan 24 04:33:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 104OXr-0004OJ-00; Sun, 24 Jan 1999 04:21:39 -0800 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with esmtp (Exim 1.81 #2) id 104OXq-0004O5-00; Sun, 24 Jan 1999 04:21:38 -0800 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Sun, 24 Jan 1999 04:20:43 -0800 Message-ID: <69D8143E230DD111B1D40000F8485840073B4E5F@ED> From: "Anders Klemets (Exchange)" To: 'Ram Kordale' , rem-conf@es.net Subject: RE: RTSP keep-alives? Date: Sun, 24 Jan 1999 04:20:35 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Periodic "RTSP keep-alives" from the client based on a > "keep-alive" header in > the server's response to SETUP seems to be a clean solution > in the general > case(regardless of data transport protocol etc.). This is indeed what the spec already prescribes. The "Session" header in the SETUP response may have an attribute, called "timeout". It specifies the timeout of the RTSP Session. The client may send a dummy GET_PARAMETER command, specifying that particular Session ID, in order to keep the Session alive. I don't think the spec says that the client does not need to send these kind of "keep-alive" commands while data is streamed from the server. Because that would make assumptions about the data transport protocol. If the server is transmitting data over UDP, using unicast, the server may be able to detect that the client has failed through the receipt of ICMP error messages. But that may not be true for multicast, or other transport or network protocols. Anders From rem-conf Mon Jan 25 21:51:02 1999 From rem-conf-request@es.net Mon Jan 25 21:51:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1051H7-000627-00; Mon, 25 Jan 1999 21:42:57 -0800 Received: from plan.arch.pwr.wroc.pl [156.17.29.2] by mail1.es.net with smtp (Exim 1.81 #2) id 1051H6-00061r-00; Mon, 25 Jan 1999 21:42:56 -0800 Received: by plan.arch.pwr.wroc.pl; id AA02678; Tue, 26 Jan 1999 06:41:52 +0100 Received: from ARCHITEKT/SpoolDir by novell.arch.pwr.wroc.pl (Mercury 1.40); 26 Jan 99 06:41:29 +0200 Received: from SpoolDir by ARCHITEKT (Mercury 1.40); 26 Jan 99 06:19:10 +0200 Received: from H0yRtKAHH (207.215.161.83) by novell.arch.pwr.wroc.pl (Mercury 1.40); 26 Jan 99 06:19:02 +0200 Date: 25 Jan 99 9:05:43 PM From: pomnbvwq@yahoo.com Message-Id: Subject: Maximize your website's traffic. Increase your search engine rank! Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Maximize your website's traffic. INCREASE YOUR SEARCH ENGINE RANK! If your Web site isn't getting the traffic it should, it's likely that it's not ranked well on the major Internet search engines. According to recent Internet E-commerce studies, over 90% of consumers find the Web sites they visit by using "The Big Eight" search engines, which are Yahoo!, Excite, AltaVista, Infoseek, Lycos, Web Crawler, HotBot, and Northern Light. If your website isn't located in the top-30 listings of these engines, chances are your site will never be seen. The single most important thing you can do to increase your Web site's traffic is to increase your search engine ranking. ------------- "PUT YOUR NAME IN LIGHTS -- List your business with search engines to make sure potential customers can find it." -- BIZ Excite, PC Computing magazine, November 1998 ------------- THE BASICS: HOW SEARCH ENGINES RANK YOUR SITE When you submit your website to a search engine to be indexed in its database, it sends a "robot" to scan your page. Using complex algorithms to rank your page for keyword relevance, the "robot" determines whether you'll be ranked number 1 or 1,000,000 when potential visitors conduct a search looking for sites like yours. Because the search engines are constantly changing their algorithms to provide users with the best possible search results, there's only one true solution to high search engine placement--us. In short, submission alone isn't enough. *Good search engine ranking* is critical to your site's success. ------------- HERE'S WHAT WE DO -- A UNIQUE, SUCCESSFUL APPROACH In order to counter the ever-changing search engine algorithms, we create an entire series of "entry pages" that are optimized for the search engines--one for every keyword (or keyword phrase) that you provide. Each entry page is optimized for a different set of algorithm variables. In other words, instead of having only *one* page struggling to rank well on all engines, we create separate, search engine-specific entry pages for each keyword. As a result, your pages rank well because they contain information relevant to search queries that are related to your industry. ------------- HOW ENTRY PAGES AFFECT YOUR WEB SITE'S CURRENT STRUCTURE Put simply, they don't. When creating entry pages we *do not* make any changes to the existing structure, content, or functionality of your current site. The entry pages act as a welcome screen for your Web site when people enter from your highly ranked link on the search engine. The pages will say a few introductory words about your site, which are keyword and/or keyword phrase rich, and then provide a link that asks the visitor to "Click Here To Enter," which moves them directly to your current homepage. ------------ HERE'S WHAT WE DON'T *EVER* DO TO HELP YOUR SEARCH ENGINE RANK We *will not* build pages for irrelevant--yet "popular"--keywords. Also, we will *never* "spamdex" pages. "Spamdexing" is "stuffing" a Web page full of words for the search engine's robots. You may have seen spamdexing, which is placing many words in the same text color as a background onto a Web page. Spamdexing will actually get your pages "kicked" from search engine indexes. What we *will* do is simply present very relevant keywords for your site to the search engines in the way that they "like" to see it. ------------- "It's simple: If they can't find you on the search engines, they can't buy from you." -- J. LeRoss, Internet Sales Consultant ------------ HOW WELL DOES THE SERVICE WORK? We'll send you a detailed report of your current search engine ranking on "The Big Six" engines before we begin. Then, once your new entry pages have been indexed, we'll send you a second report showing how they've ranked. Here's a sampling of some results we've acheived for previous clients. (These examples are for competitive keywords--not just obscure words on which no one is conducting searches.) <> 6 top-10 rankings on Infoseek for different relevant keywords <> 18 top-10 rankings across the major search engines <> 3 top-10 rankings on Alta Vista for one keyword <> 16 total *number one* rankings <> 40 top-30 rankings, spread across the different engines. <> 1 to 2 hits per week increased to 500 per day <> 45,000 hits per month grew to 108,000. ------------ HOW MUCH DOES YOUR SERVICE COST? Our basic services start at only $385. The basic package includes: <> Construction of optimized entry pages for up to 20 keywords -- This gives you good "coverage" in your industry <> Submission of the keyword-dense entry pages to the "Big Six" search engines <> A complete report of your search engine rankings before we submit <> A complete report of your search engine rankings after submission--so you can see the ranking results When you contact us, ask about other services we provide that may be able to help your Internet initiatives succeed. We have special services that can be tailored for your specific Internet marketing needs. ------------ HOW DO I GET STARTED? <> Call us--we'll answer any questions you may have and provide a no-cost initial consultation. (410) 783-8269 <> Submit your keywords and/or keyword phrases (up to 20) to us ------------ COMMENTS FROM CLIENTS "Frankly, I'm impressed with the foregoing. So many solicitations from email sources turn out to be a phone line that hooks up to a voice mail system that is designed to give the impression of size, and people who never return phone calls/messages. . . So its a pleasant surprise to find that someone at the other end is really operating as a business!!!" --Alan B. "Incredible! Our site is now receiving more hits in a day than we used to get in an entire month. [My boss] is still eating his words." -- Bob W. "I knew the search engines were a fantastic marketing tool, but my company simply didn't have the time to devote to search engine placement. It has proven to be the best money we've ever spent on marketing." -- Shelley H. "I worked for weeks to get good search engine placement, but I could never crack the top 80 . . . my site was deserted. Within a month [after using your service], I'd had more hits than I'd had in the last year. I wouldn't believe it if it hadn't happened to me." -- Chris L. ------------ OUR JOB: INCREASE YOUR WEB SITE'S RANKING. We can't guarantee that better ranking will increase the number of visitors that "surf" to your Web site. Some highly-ranked websites still don't get much traffic--much depends on your particular industry and choice of keywords. However, high rankings, in most cases, do mean increased Web site traffic. And, we have never failed to increase a client's ranking. Ever. ------------ CONTACT A REPRESENTATIVE: Search Engine Success Group - Call us toll free at: (888) 283-2050 ----------------------- If you've received this message in error--and are not interested in our services--please click reply or call, (888)-248-2236, and we'll remove you from our list. From rem-conf Wed Jan 27 01:34:14 1999 From rem-conf-request@es.net Wed Jan 27 01:34:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105RBn-0002W4-00; Wed, 27 Jan 1999 01:23:11 -0800 Received: from radmail.rad.co.il [207.232.32.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 105RBk-0002Vu-00; Wed, 27 Jan 1999 01:23:10 -0800 Received: from roneng1.rad.co.il ([192.114.31.6]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-54115U1200L1200S0V35) with SMTP id il; Wed, 27 Jan 1999 11:23:54 +0200 X-Sender: roneng@radmail.rad.co.il X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Wed, 27 Jan 1999 11:20:36 +0200 To: rem-conf@es.net From: Ronen Goory Subject: RTP compression over Frame Relay Cc: ezra_k@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <19990127092354.AAA214@radmail.rad.co.il@roneng1.rad.co.il> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, In draft-ietf-avt-crtp-05.txt section 5 - Negotiating Compression it is written "The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol. It is expected that such negotiation will be defined separately for PPP [4], for example..." I would like to know if some know how it can be implemented over HDLC or Frame Relay lines, without a PPP encapsulation? Any help is appreciated. Thanks Ronen Goory RAD Data Communications 31 Habarzel st. Tel-Aviv, Israel Tel 972-3-6455433 Fax 972-3-6455305 From rem-conf Wed Jan 27 01:49:55 1999 From rem-conf-request@es.net Wed Jan 27 01:49:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105RYC-0002yz-00; Wed, 27 Jan 1999 01:46:20 -0800 Received: from dienstmann.informatik.uni-bremen.de [134.102.206.253] by mail1.es.net with esmtp (Exim 1.81 #2) id 105RYA-0002yn-00; Wed, 27 Jan 1999 01:46:18 -0800 Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id KAA13075 Wed, 27 Jan 1999 10:45:34 +0100 (MET) Date: Wed, 27 Jan 1999 10:45:34 +0100 (MET) Message-Id: <199901270945.KAA13075@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Ronen Goory Cc: rem-conf@es.net, ezra_k@es.net Subject: Re: RTP compression over Frame Relay In-Reply-To: <19990127092354.AAA214@radmail.rad.co.il@roneng1.rad.co.il> References: <19990127092354.AAA214@radmail.rad.co.il@roneng1.rad.co.il> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ronen Goory writes: > Hi, > > In draft-ietf-avt-crtp-05.txt section 5 - Negotiating Compression it is > written "The use of IP/UDP/RTP compression over a particular link is a > function of the link-layer protocol. It is expected that such negotiation > will be defined separately for PPP [4], for example..." > > I would like to know if some know how it can be implemented over HDLC or > Frame Relay lines, without a PPP encapsulation? You can always configure the ends to agree on the parameters needed. For an overview of these parameters, you might want to consult the IP compression over PPP draft, draft-engan-ip-compress-02.txt. Gruesse, Carsten From rem-conf Wed Jan 27 10:36:36 1999 From rem-conf-request@es.net Wed Jan 27 10:36:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105Zjf-0000St-00; Wed, 27 Jan 1999 10:30:43 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 105Zje-0000Sh-00; Wed, 27 Jan 1999 10:30:42 -0800 Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id A616D4CE7B; Wed, 27 Jan 1999 13:30:40 -0500 (EST) Received: from research.att.com (mathias@descant [135.207.17.202]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id NAA18132 for ; Wed, 27 Jan 1999 13:30:36 -0500 (EST) Sender: mathias@research.att.com Message-ID: <36AF5BEC.B4A4AB78@research.att.com> Date: Wed, 27 Jan 1999 13:33:16 -0500 From: Mathias Kretschmer X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP payload type/profile for MPEG II - AAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi guys, I'm wondering if there is a payload type/profile defined for AAC since it is not compatible with MPEG Audio Layer 1...3 (which is covered by MPA in RFC 1890). tx, Mathias -- Mathias Kretschmer, AT&T Labs Research mathias@research.att.com fax ++1-973-360-8455 From rem-conf Wed Jan 27 15:14:59 1999 From rem-conf-request@es.net Wed Jan 27 15:14:57 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 105e0b-0005FH-00; Wed, 27 Jan 1999 15:04:29 -0800 Received: from mailhost.vmlabs.com ([204.31.130.20] helo=galahad.vmlabs.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 105e0Z-0005F4-00; Wed, 27 Jan 1999 15:04:27 -0800 Received: from vmlabs.com ([192.1.1.143]) by galahad.vmlabs.com (8.8.7/8.8.7) with ESMTP id MAA26745 for ; Wed, 27 Jan 1999 12:56:03 -0800 (PST) Message-ID: <36AF7E85.6FEF5ACB@vmlabs.com> Date: Wed, 27 Jan 1999 13:00:53 -0800 From: "Wilson C. Chung" Organization: VM Labs X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: zh-CN,zh-TW,en MIME-Version: 1.0 To: rem-conf@es.net Subject: Traffic Shaping Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Guys: I am wondering is there any RFC that specifies "Traffic Shaping" in gateway(s) particularly for voice and video traffic. I am thinking more or less an "intelligent network" that change the rate(s) and transcode various protocols in audio and video in either gateway(s) or router(s), with some regards to the End-to-End QoS client/server negotiation. There is a big problem in a very heterogenous network where all sort of clients (in terms of MIPS) co-exist. regards, Wilson Wilson C. Chung, VM Labs wchung@vmlabs.com From rem-conf Wed Jan 27 16:59:11 1999 From rem-conf-request@es.net Wed Jan 27 16:59:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105ffh-0004el-00; Wed, 27 Jan 1999 16:51:01 -0800 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 105ffg-0004eb-00; Wed, 27 Jan 1999 16:51:00 -0800 Received: from arkas (arkas.ctr.columbia.edu [128.59.64.69]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with SMTP id TAA07818; Wed, 27 Jan 1999 19:50:22 -0500 (EST) Reply-To: From: "Prof. Alexandros Eleftheriadis" To: "Wilson C. Chung" , Subject: RE: Traffic Shaping Date: Wed, 27 Jan 1999 19:50:07 -0500 Message-ID: <002501be4a58$26b18c20$45403b80@arkas.ctr.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <36AF7E85.6FEF5ACB@vmlabs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: Wilson C. Chung [mailto:wchung@vmlabs.com] > Sent: Wednesday, January 27, 1999 4:01 PM > To: rem-conf@es.net > Subject: Traffic Shaping > > > Hi Guys: > > I am wondering is there any RFC that specifies "Traffic Shaping" in > gateway(s) particularly for voice and video traffic. I am thinking > more or less an "intelligent network" that change the rate(s) and > transcode various protocols in audio and video in either gateway(s) > or router(s), with some regards to the End-to-End QoS client/server > negotiation. There is a big problem in a very heterogenous network > where all sort of clients (in terms of MIPS) co-exist. > > regards, Wilson > > Wilson C. Chung, VM Labs > wchung@vmlabs.com Howdy. What you refer to is called rate shaping; traffic shaping implies that the average rate before and after remains the same. With rate shaping the output bit rate is reduced, keeping the same encoding format. I introduced rate shaping some years ago in my thesis where I designed algorithms for MPEG-1/2. A student of mine later on applied it on IP (using TCP-based flow control to ensure fair sharing with HTTP/FTP/ETC), and also did a real-time implementation for MPEG-1/MPEG-2 streams. You can find more info in http://www.ee.columbia.edu/~eleft and http://www.ee.columbia.edu/~sej. Other techniques have been proposed since, playing with different parts of the bitstream than I did, and making varied claims in terms of performance/complexity. However, I don't know of any implementation of them (let me know if you want paper refs). For transcoding, I recall a couple of messages flying around this list a year or so ago, referring to transcoding software, but I don't have immediately accessible info. Transcoding makes most sence if there is really a substantial difference between the source and target rates. It can also be quite expensive. It's much easier to fully utilize the features of your original bitstream to scale things down -- and all specs have many. Hope this helps. From rem-conf Wed Jan 27 21:28:03 1999 From rem-conf-request@es.net Wed Jan 27 21:28:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105jvo-0007m0-00; Wed, 27 Jan 1999 21:23:56 -0800 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 105jvn-0007lq-00; Wed, 27 Jan 1999 21:23:55 -0800 Received: from mg128-086.ricochet.net (mg128-086.ricochet.net [204.179.128.86]) by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id VAA25080; Wed, 27 Jan 1999 21:22:46 -0800 (PST) Message-Id: <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Wed, 27 Jan 1999 21:20:22 To: mbone@isi.edu, rem-conf@es.net From: Ross Finlayson Subject: A new tool for multicast MP3 audio streaming Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With more than 90% of the Internet's users still using low-bandwidth connections, we do multicast a disservice if we continue to promote and use it for high-bandwidth users only. As part of my ongoing campaign to help rectify this, I've released a new tool that can multicast "MP3" (i.e., MPEG 1 or 2, layer III) audio files - either at their 'native' bitrate (usually 128 kbps), or transcoded at a lower bitrate. The tool - "liveCaster" - is available (free) from Versions are currently available for Windows (95,98,or NT), Linux, FreeBSD, Solaris/SPARC and SGI Irix. To use liveCaster, just point it at a directory containing "*.mp3" files, and follow the setup instructions. Unlike "Shoutcast" (another MP3 streaming tool (unicast) that's been getting a lot of attention lately), "liveCaster" currently transcodes MP3 to lower bandwidths not by decoding the MPEG stream then re-encoding it, but instead by picking out (a subset of) the already-encoded samples from the original data, then repackaging them into new, smaller MPEG frames. This means, unfortunately, that (i) the audio quality is not as good as decoding/re-encoding, and (ii) MPEG 1 files can't be transcoded to less than 32 kbps. (On the other hand, liveCaster is *much* less CPU-hungry, and, because it doesn't require the presence of an MPEG encoder, runs on many more platforms beyond Windows.) Receiving multicast MP3 streams =============================== Unfortunately there currently seem to be few RTP-capable MP3 players (i.e., supporting RTP payload type 14, using the format described in RFC 2250). I'm currently compiling (on my web site) a list of such tools; if you provide such a tool, please let me know. (I already know about Roland Parviainen's "mIR" tool, although I have yet to try it.) A PLEA: Has anyone added MP3 decoding to "rat"? If not, this would make a great 'class project'. (FYI, there is 'open source' MP3 decoding software available at ; it may be possible to use this in "rat".) Limitations of the current version of liveCaster: - It doesn't do RTCP. (Yes, I know, "naughty, naughty"; I'll fix this soon) - I doesn't automatically create SDP announcements (instead, you'll need to announce your sessions 'by hand') - It doesn't yet use MALLOC for multicast address allocation (of course) - There's currently a bug in the transcoder - a small percentage of MP3 files seem to confuse it, causing it to generate garbage One final note: Please try to respect intellectual property rights, and try not to be cavalier about transmitting copyrighted MP3 content. The record companies are already freaking out over MP3 in general, and I'd hate to see the deployment and use of multicast suffer because of 'piracy' fears. Ross. From rem-conf Thu Jan 28 07:08:31 1999 From rem-conf-request@es.net Thu Jan 28 07:08:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105srH-00055L-00; Thu, 28 Jan 1999 06:55:51 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 105srF-000555-00; Thu, 28 Jan 1999 06:55:49 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 28 Jan 1999 14:55:31 +0000 To: Ross Finlayson cc: rem-conf@es.net Reply-To: rat-trap.cs.ucl.ac.uk@cs.ucl.ac.uk Subject: Re: A new tool for multicast MP3 audio streaming In-reply-to: Your message of "Wed, 27 Jan 1999 21:20:22." <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com> Date: Thu, 28 Jan 1999 14:55:28 +0100 Message-ID: <1182.917535328@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com>Ross Finlayson writes: > A PLEA: Has anyone added MP3 decoding to "rat"? If not, this would make a > great 'class project'. (FYI, there is 'open source' MP3 decoding software > available at ; it may > bepossible to use this in "rat".) Mark Handley suggested a while back that we add the mpg123 code (or something similar) and it is just one of those things I have never got around to doing. If someone is interested it should be reasonably straightforward to incorporate mpg123 decoder. The sources for the new codec interfaces in RAT are not yet available publicly, but if you are interested send a note to rat-trap@cs.ucl.ac.uk and we'll forward the codec components and some sample code. If someone takes this on I'll add the hooks for RAT to read coded files for transmission so it can send and receive layer-III files. There also are hooks in the experimental version of RAT to the Windows ACM codecs specifically for exploiting the Fraunhoffer Layer-3 codec (and G.723.1 but there's a key needed for this). The code is currently suffering from bit-rot, but should get fixed for the next release. cheers - Orion =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street London, WC1E 6BT, UK. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Thu Jan 28 07:16:22 1999 From rem-conf-request@es.net Thu Jan 28 07:16:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105t72-0005MG-00; Thu, 28 Jan 1999 07:12:08 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 105t70-0005L6-00; Thu, 28 Jan 1999 07:12:06 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jan 28 10:11:27 EST 1999 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA21635; Thu, 28 Jan 1999 10:11:26 -0500 (EST) Message-ID: <36B07D8A.7BCD6361@dnrc.bell-labs.com> Date: Thu, 28 Jan 1999 10:08:58 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Wilson C. Chung" CC: rem-conf@es.net Subject: Re: Traffic Shaping References: <36AF7E85.6FEF5ACB@vmlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Adaptation of the rate is done in the end systems (gateways and end users), and not in the routers. If the problem you are concerned about is different MIPS at the end systems (and thus varying abilities to support different codecs), this is best handled during call setup through the various negotiation protocols (SIP/SDP and H.323). There is the much harder problem, however, of adapting the rate at end systems based on network QoS. There is no RFC which mandates any kind of rate adaptation. There was a BoF called ADAPTS sometime back which was looking at doing perhaps an informational RFC on the subject, but I don't think anything came of it. I believe this to be an area where there can be significant product/vendor differentiation. The basic problem can be broken into a few parts: 1. the gateway must get information on what the end to end QoS is like (in terms of delay, loss, jitter) 2. the gateway must decide what rate to send media at based on this feedback 3. the gateway must change the rate of the media to meet the target in (2). Step (1) above is done using RTCP (the Real Time Control Protocol), part of the RTP (rfc1889) specification. RTCP provides feedback from receivers on delay, loss, and jitter. This information can be used by applications to do step (2). There are existing papers which cover (2), see in particular: Busse, Deffner, Schulzrinne, "Dynamic QoS Control of Multimedia Applications based on RTP", in the 1st International Workshop on High Speed networks and Open Distributed Plaitforms, 1995 Bolot, Garcia, "Control Mechanisms for Packet Audio in the Internet", Infocom 96 There is other work on emulating TCP behavior, but I don't have a specific reference (anyone?). Step (3) comes into the realm of codecs and source coding. -Jonathan R. Wilson C. Chung wrote: > > Hi Guys: > > I am wondering is there any RFC that specifies "Traffic Shaping" in > gateway(s) particularly for voice and video traffic. I am thinking > more or less an "intelligent network" that change the rate(s) and > transcode various protocols in audio and video in either gateway(s) > or router(s), with some regards to the End-to-End QoS client/server > negotiation. There is a big problem in a very heterogenous network > where all sort of clients (in terms of MIPS) co-exist. > > regards, Wilson > > Wilson C. Chung, VM Labs > wchung@vmlabs.com -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 28 07:18:08 1999 From rem-conf-request@es.net Thu Jan 28 07:18:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105t9l-0005a9-00; Thu, 28 Jan 1999 07:14:57 -0800 Received: from law-f49.hotmail.com (hotmail.com) [209.185.131.112] by mail1.es.net with smtp (Exim 1.81 #2) id 105t9k-0005WK-00; Thu, 28 Jan 1999 07:14:56 -0800 Received: (qmail 23532 invoked by uid 0); 28 Jan 1999 15:13:55 -0000 Message-ID: <19990128151355.23531.qmail@hotmail.com> Received: from 192.167.215.58 by www.hotmail.com with HTTP; Thu, 28 Jan 1999 07:13:55 PST X-Originating-IP: [192.167.215.58] From: "Gio tesista" To: rem-conf@es.net Subject: multicast Date: Thu, 28 Jan 1999 07:13:55 PST Mime-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I 'm italian student and I 'm making some experiments on multicast. I have Linux configured 3 PC with multicast support and one of these is a multicast router(mrouter).If we create a work session on our same network,when we run "SD" or "SDR" I see the session on other computers and it's O.K..The problem is ONLY mrouter see external session (by tunneling) out my network, but the other 2 computers no.What can I do to resolve this problem? Thanks Gio' ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Jan 28 07:45:08 1999 From rem-conf-request@es.net Thu Jan 28 07:45:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105tZF-0007aA-00; Thu, 28 Jan 1999 07:41:17 -0800 Received: from habanero.marratech.com [195.196.47.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 105tZD-0007Zy-00; Thu, 28 Jan 1999 07:41:16 -0800 Received: from marratech.com (prefect.marratech.com [195.196.47.38]) by habanero.marratech.com (8.9.1/8.8.8) with ESMTP id QAA17658 for ; Thu, 28 Jan 1999 16:41:13 +0100 (CET) (envelope-from Serge.Lachapelle@marratech.com) Message-ID: <36B08608.C3B89785@marratech.com> Date: Thu, 28 Jan 1999 16:45:12 +0100 From: Serge Lachapelle Organization: Marratech AB (http://www.marratech.com) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: fr-CA MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: A new tool for multicast MP3 audio streaming References: <1182.917535328@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, Another tool called mIR (multicast Interactive Radio) has been around for a while now. It is currently being managed and developed by Roland Parviainen. It is mostly written in Java (except the actual decoder) and supports mpg123 and WinAmp (depending on the platform you are on). It also supports DJ-like functions such as voting for the next song that should be played. Read more about mIR at: http://www.cdt.luth.se/~rolle/mIR/ /Serge Lachapelle Marratech AB Orion Hodson wrote: > <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com>Ross Finlayson writes: > > A PLEA: Has anyone added MP3 decoding to "rat"? If not, this would make a > > great 'class project'. (FYI, there is 'open source' MP3 decoding software > > available at ; it may > > bepossible to use this in "rat".) > > Mark Handley suggested a while back that we add the mpg123 code (or > something similar) and it is just one of those things I have never got > around to doing. If someone is interested it should be reasonably > straightforward to incorporate mpg123 decoder. The sources for the > new codec interfaces in RAT are not yet available publicly, but if you > are interested send a note to rat-trap@cs.ucl.ac.uk and we'll forward > the codec components and some sample code. > > If someone takes this on I'll add the hooks for RAT to read coded > files for transmission so it can send and receive layer-III files. > > There also are hooks in the experimental version of RAT to the Windows > ACM codecs specifically for exploiting the Fraunhoffer Layer-3 codec > (and G.723.1 but there's a key needed for this). The code is > currently suffering from bit-rot, but should get fixed for the next > release. > > cheers > - Orion > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Networked Multimedia Research Group Tel: ++(0)171 419 3704 > Department of Computer Science Fax: ++(0)171 419 1397 > University College London, Gower Street > London, WC1E 6BT, UK. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Thu Jan 28 07:48:13 1999 From rem-conf-request@es.net Thu Jan 28 07:48:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105td9-0007jT-00; Thu, 28 Jan 1999 07:45:19 -0800 Received: from lima.irisa.fr [131.254.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 105td8-0007j2-00; Thu, 28 Jan 1999 07:45:19 -0800 Received: from irisa.fr (magnolia.irisa.fr [131.254.42.32]) by lima.irisa.fr (8.9.1a/8.9.1) with ESMTP id QAA13205; Thu, 28 Jan 1999 16:44:59 +0100 (MET) Sender: Francois.Toutain@irisa.fr Message-ID: <36B085FB.85A27945@irisa.fr> Date: Thu, 28 Jan 1999 16:44:59 +0100 From: Francois Organization: INRIA / IRISA X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Wilson C. Chung" , rem-conf@es.net Subject: Re: Traffic Shaping References: <36AF7E85.6FEF5ACB@vmlabs.com> <36B07D8A.7BCD6361@dnrc.bell-labs.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lima.irisa.fr id QAA13205 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > There is other work on emulating TCP behavior, but I don't have a > specific reference (anyone?). > http://www.psc.edu/networking/tcp_friendly.html Fran=E7ois From rem-conf Thu Jan 28 08:04:51 1999 From rem-conf-request@es.net Thu Jan 28 08:04:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105tqF-0001A7-00; Thu, 28 Jan 1999 07:58:51 -0800 Received: from chico.rediris.es [130.206.1.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 105tps-00019w-00; Thu, 28 Jan 1999 07:58:49 -0800 Received: from rediris.es (october.rediris.es [130.206.1.169]) by chico.rediris.es (8.9.1/8.9.1) with ESMTP id QAA04369; Thu, 28 Jan 1999 16:52:58 +0100 (MET) Message-Id: <199901281552.QAA04369@chico.rediris.es> X-Mailer: exmh version 2.0.2 From: "Angel L. Mateo" To: "Gio tesista" cc: rem-conf@es.net Subject: Re: multicast Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 1999 16:50:28 +0100 Sender: angel.mateo@rediris.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list El d=EDa Thu, 28 Jan 1999 07:13:55 PST "Gio tesista" escribi=F3: > I 'm italian student and I 'm making some experiments on multicast. > I have Linux configured 3 PC with multicast support and one of these = > is a multicast router(mrouter).If we create a work session on our same = = > network,when we run "SD" or "SDR" I see the session on other computers = > and it's O.K..The problem is ONLY mrouter see external session (by = > tunneling) out my network, but the other 2 computers no.What can I do = > to resolve this problem? I think that you have to a route to the mrouter in the other computers. = For example, add: route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 to the /etc/rc.d/rc.local file Salu2 Angel From rem-conf Thu Jan 28 10:24:15 1999 From rem-conf-request@es.net Thu Jan 28 10:24:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 105w1Q-0003DX-00; Thu, 28 Jan 1999 10:18:32 -0800 Received: from law-f93.hotmail.com (hotmail.com) [209.185.131.156] by mail1.es.net with smtp (Exim 1.81 #2) id 105w1N-0003D5-00; Thu, 28 Jan 1999 10:18:30 -0800 Received: (qmail 15799 invoked by uid 0); 28 Jan 1999 18:17:28 -0000 Message-ID: <19990128181728.15798.qmail@hotmail.com> Received: from 192.167.215.245 by www.hotmail.com with HTTP; Thu, 28 Jan 1999 10:17:28 PST X-Originating-IP: [192.167.215.245] From: "Gio tesista" To: angel.mateo@rediris.es Cc: rem-conf@es.net Subject: Re: multicast Date: Thu, 28 Jan 1999 10:17:28 PST Mime-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> I 'm italian student and I 'm making some experiments on multicast. I have Linux configured 3 PC with multicast support and one of these is a multicast router(mrouter).If we create a work session on our same network,when we run "SD" or "SDR" I see the session on other computers and it's O.K..The problem is ONLY mrouter see external session (by tunneling) out my network, but the other 2 computers no.What can I do to resolve this problem? > > I think that you have to a route to the mrouter in the other computers. = >For example, add: > > route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 > >to the /etc/rc.d/rc.local file > > >Salu2 > >Angel > >Thanks,but there is alredy this line .Infact if I run "route",I see also > Destination Gatewey Genmask Flag metric Ref Use Iface .......... ....... ...... ......... . .......... ........... ............ 224.0.0.0 * 240.0.0.0 U 0 0 17 etho Is it a problem di mrouter?I think no.What do I do? Thanks. GIO, ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Jan 28 16:18:24 1999 From rem-conf-request@es.net Thu Jan 28 16:18:23 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 1061YK-0003Y1-00; Thu, 28 Jan 1999 16:12:52 -0800 Received: from mailhost.vmlabs.com ([204.31.130.20] helo=galahad.vmlabs.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 1061Y1-0003Xr-00; Thu, 28 Jan 1999 16:12:33 -0800 Received: from wilson ([192.1.1.143]) by galahad.vmlabs.com (8.8.7/8.8.7) with SMTP id QAA24818; Thu, 28 Jan 1999 16:00:46 -0800 (PST) Message-ID: <008301be4b1b$1c4a8ac0$8f0101c0@wilson.vmlabs.com> Reply-To: "Wilson C. Chung" From: "Wilson C. Chung" To: "Jonathan Rosenberg" Cc: Subject: Re: Traffic Shaping Date: Thu, 28 Jan 1999 16:05:41 -0800 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 On part Three of the problem, I assumed you have to go into the application layer and actually transcode the A/V bitstreams. Assumption number One is that bitstreams are not scalable in rate nor resolution, therefore we have to decode and encode again at gateway(s). Most of the broadcast and multimedia materials exist in the info structure aren't ready scalable in layers either. This will push the MIPS requirement on a full "intelligent gateway" concept infeasible for a "true" multicast scenerio. Any thoughts? Wilson Chung, VM Labs -----Original Message----- From: Jonathan Rosenberg To: Wilson C. Chung Cc: rem-conf@es.net Date: Thursday, January 28, 1999 7:06 AM Subject: Re: Traffic Shaping >Adaptation of the rate is done in the end systems (gateways and end >users), and not in the routers. > >If the problem you are concerned about is different MIPS at the end >systems (and thus varying abilities to support different codecs), this >is best handled during call setup through the various negotiation >protocols (SIP/SDP and H.323). > >There is the much harder problem, however, of adapting the rate at end >systems based on network QoS. There is no RFC which mandates any kind of >rate adaptation. There was a BoF called ADAPTS sometime back which was >looking at doing perhaps an informational RFC on the subject, but I >don't think anything came of it. I believe this to be an area where >there can be significant product/vendor differentiation. > >The basic problem can be broken into a few parts: > >1. the gateway must get information on what the end to end QoS is like >(in terms of delay, loss, jitter) > >2. the gateway must decide what rate to send media at based on this >feedback > >3. the gateway must change the rate of the media to meet the target in >(2). > >Step (1) above is done using RTCP (the Real Time Control Protocol), part >of the RTP (rfc1889) specification. RTCP provides feedback from >receivers on delay, loss, and jitter. This information can be used by >applications to do step (2). > >There are existing papers which cover (2), see in particular: > >Busse, Deffner, Schulzrinne, "Dynamic QoS Control of Multimedia >Applications based on RTP", in the 1st International Workshop on High >Speed networks and Open Distributed Plaitforms, 1995 > >Bolot, Garcia, "Control Mechanisms for Packet Audio in the Internet", >Infocom 96 > >There is other work on emulating TCP behavior, but I don't have a >specific reference (anyone?). > >Step (3) comes into the realm of codecs and source coding. > > >-Jonathan R. > > >Wilson C. Chung wrote: >> >> Hi Guys: >> >> I am wondering is there any RFC that specifies "Traffic Shaping" in >> gateway(s) particularly for voice and video traffic. I am thinking >> more or less an "intelligent network" that change the rate(s) and >> transcode various protocols in audio and video in either gateway(s) >> or router(s), with some regards to the End-to-End QoS client/server >> negotiation. There is a big problem in a very heterogenous network >> where all sort of clients (in terms of MIPS) co-exist. >> >> regards, Wilson >> >> Wilson C. Chung, VM Labs >> wchung@vmlabs.com > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 28 17:24:27 1999 From rem-conf-request@es.net Thu Jan 28 17:24:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1062Zd-0001eO-00; Thu, 28 Jan 1999 17:18:17 -0800 Received: from alpha.xerox.com [13.1.64.93] (firewall-user) by mail1.es.net with smtp (Exim 1.81 #2) id 1062Zc-0001eE-00; Thu, 28 Jan 1999 17:18:16 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <62723(5)>; Thu, 28 Jan 1999 17:18:00 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177534>; Thu, 28 Jan 1999 17:17:40 -0800 To: Ross Finlayson cc: mbone@isi.edu, rem-conf@es.net Subject: Re: A new tool for multicast MP3 audio streaming In-reply-to: Your message of "Wed, 27 Jan 99 13:20:22 PST." <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com> Date: Thu, 28 Jan 1999 17:17:34 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <99Jan28.171740pst.177534@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <3.0.5.16.19990127212022.2f6736fc@shell7.ba.best.com> Ross Finlayson wrote: >- I doesn't automatically create SDP announcements > (instead, you'll need to announce your sessions 'by hand') In order to facilitate creating these announcements, sdr users can install this plugin as ~/.sdr/plugins/sdr2.plugin.mpegaudio . It won't allow launching (it will launch /bin/true) but it will allow creation of the session with the MPEG Audio media type. Bill # # sdr2.plugin.mpegaudio # Allows creation of sessions with the MPEG Audio media type. media: audio proto: RTP/AVP tool: true protoname: RTP fmt: 14 { fmtname: MPEG Audio } From rem-conf Thu Jan 28 19:33:45 1999 From rem-conf-request@es.net Thu Jan 28 19:33:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1064Y5-0003B5-00; Thu, 28 Jan 1999 19:24:49 -0800 Received: from f155.hotmail.com (hotmail.com) [207.82.251.34] by mail1.es.net with smtp (Exim 1.81 #2) id 1064Y4-0003At-00; Thu, 28 Jan 1999 19:24:48 -0800 Received: (qmail 12379 invoked by uid 0); 29 Jan 1999 03:23:47 -0000 Message-ID: <19990129032347.12378.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Thu, 28 Jan 1999 19:23:47 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: jdrosen@dnrc.bell-labs.com, wchung@vmlabs.com Cc: rem-conf@es.net Subject: Re: Traffic Shaping Date: Thu, 28 Jan 1999 19:23:47 PST Mime-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do you have a source for this presentation? >Bolot, Garcia, "Control Mechanisms for Packet Audio in the Internet", >Infocom 96 > >There is other work on emulating TCP behavior, but I don't have a >specific reference (anyone?). Are you talking about providing some sort of acknowledgement-based negotiation protocol over UDP ... Does MGCP provide a mechanism for modifying connections in progress? Regards, Neal A. Schneider >> Hi Guys: >> >> I am wondering is there any RFC that specifies "Traffic Shaping" in >> gateway(s) particularly for voice and video traffic. I am thinking >> more or less an "intelligent network" that change the rate(s) and >> transcode various protocols in audio and video in either gateway(s) >> or router(s), with some regards to the End-to-End QoS client/server >> negotiation. There is a big problem in a very heterogenous network >> where all sort of clients (in terms of MIPS) co-exist. >> >> regards, Wilson >> >> Wilson C. Chung, VM Labs >> wchung@vmlabs.com > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Jan 28 20:05:56 1999 From rem-conf-request@es.net Thu Jan 28 20:05:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10650N-0003yK-00; Thu, 28 Jan 1999 19:54:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10650M-0003yA-00; Thu, 28 Jan 1999 19:54:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jan 28 22:52:27 EST 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.114]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA03855; Thu, 28 Jan 1999 22:52:25 -0500 (EST) Message-ID: <36B12F01.7D27E63A@dnrc.bell-labs.com> Date: Thu, 28 Jan 1999 22:46:09 -0500 From: Jonathan Rosenberg Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Neal Schneider CC: wchung@vmlabs.com, rem-conf@es.net Subject: Re: Traffic Shaping References: <19990129032347.12378.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > Do you have a source for this presentation? > > >Bolot, Garcia, "Control Mechanisms for Packet Audio in the Internet", > >Infocom 96 > > ftp://ftp-sop.inria.fr/rodeo/bolot/96.Audio_ctl.ps.gz > > >There is other work on emulating TCP behavior, but I don't have a > >specific reference (anyone?). > > Are you talking about providing some sort of acknowledgement-based > negotiation protocol over UDP No. I am talking about rate shaping in such a way that the rate used by the media stream is the same rate a TCP stream would use under the same loss conditions. ... Does MGCP provide a mechanism for > modifying connections in progress? MGCP can modify its current connections. However, I don't know if rate adaptation is something the protocol is aiming to control. I'm also not sure rate adaptation is best done in the MGC, since its a pure media function it could be done entirely in the MG. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 28 20:27:23 1999 From rem-conf-request@es.net Thu Jan 28 20:27:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1065RS-0004hz-00; Thu, 28 Jan 1999 20:22:02 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 1065RR-0004hp-00; Thu, 28 Jan 1999 20:22:01 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jan 28 23:20:21 EST 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.114]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA04369; Thu, 28 Jan 1999 23:20:19 -0500 (EST) Message-ID: <36B1358C.D9A789E5@dnrc.bell-labs.com> Date: Thu, 28 Jan 1999 23:14:04 -0500 From: Jonathan Rosenberg Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: "Wilson C. Chung" CC: rem-conf@es.net Subject: Re: Traffic Shaping References: <008301be4b1b$1c4a8ac0$8f0101c0@wilson.vmlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Wilson C. Chung wrote: > > On part Three of the problem, I assumed you have to go > into the application layer and actually transcode the A/V > bitstreams. Assumption number One is that bitstreams > are not scalable in rate nor resolution, therefore we have > to decode and encode again at gateway(s). No, the media arrives from the circuit uncompressed, so you need only compress once at the ingress gateway. The adaptation is done (for voice, at least), by codec selection since most codecs don't have tunable parameters to control the rate. G.723.1 is a minor exception - you can switch between 5.3 and 6.3 kbps. There is a lot more control for video (adjusting things like quantization parameters), and perhaps for high quality audio. Most of > the broadcast and multimedia materials exist in the info > structure aren't ready scalable in layers either. This will > push the MIPS requirement on a full "intelligent gateway" > concept infeasible for a "true" multicast scenerio. True, speech is not really amenable to layered coding since its so low bitrate to begin with. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 28 20:39:11 1999 From rem-conf-request@es.net Thu Jan 28 20:39:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1065e4-0005Mk-00; Thu, 28 Jan 1999 20:35:04 -0800 Received: from catarina.usc.edu [128.125.51.47] by mail1.es.net with smtp (Exim 1.81 #2) id 1065e2-0005Ma-00; Thu, 28 Jan 1999 20:35:03 -0800 Received: from newport.usc.edu (newport.usc.edu [128.125.51.78]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id UAA18204; Thu, 28 Jan 1999 20:35:00 -0800 Received: (reza@localhost) by newport.usc.edu (8.6.10/8.6.9) id UAA03061; Thu, 28 Jan 1999 20:34:59 -0800 Date: Thu, 28 Jan 1999 20:34:59 -0800 (PST) From: Reza Rejaie To: Jonathan Rosenberg cc: Neal Schneider , wchung@vmlabs.com, rem-conf@es.net Subject: Re: Traffic Shaping In-Reply-To: <36B12F01.7D27E63A@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 28 Jan 1999, Jonathan Rosenberg wrote: > Neal Schneider wrote: > > > > Do you have a source for this presentation? > > > > >Bolot, Garcia, "Control Mechanisms for Packet Audio in the Internet", > > >Infocom 96 > > > > > ftp://ftp-sop.inria.fr/rodeo/bolot/96.Audio_ctl.ps.gz > > > > > >There is other work on emulating TCP behavior, but I don't have a > > >specific reference (anyone?). > > > > Are you talking about providing some sort of acknowledgement-based > > negotiation protocol over UDP > > No. I am talking about rate shaping in such a way that the rate used by > the media stream is the same rate a TCP stream would use under the same > loss conditions. We have designed a TCP-friendly Rate Adaptation Protocol(RAP) for streaming applications that achieves this goal. For more details refer to : "RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet" Reza Rejaie, Mark Handely and Deborah Estrin, To appear in IEEE Infocom'99 http://netweb.usc.edu/reza/papers/infocom99.ps ReZa From rem-conf Fri Jan 29 03:43:35 1999 From rem-conf-request@es.net Fri Jan 29 03:43:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 106CEx-0001sA-00; Fri, 29 Jan 1999 03:37:35 -0800 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 106CEv-0001s0-00; Fri, 29 Jan 1999 03:37:33 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.9.2/8.9.2/best.out) with SMTP id DAA03165; Fri, 29 Jan 1999 03:37:06 -0800 (PST) Message-Id: <3.0.5.16.19990129033451.2d37befa@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Fri, 29 Jan 1999 03:34:51 To: mbone@isi.edu, rem-conf@es.net From: Ross Finlayson Subject: A MPEG/RTP audio tool for Windows Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Following up on my earlier message about liveCaster, I've hacked together a Windows application that receives RTP-encapsulated multicast MPEG audio packets, and plays the MPEG data using Nullsoft's "Winamp" audio player tool. This application - "playRTPMPEG" - is available from If you're using the "multikit" session browser, this application (once installed) will be run automatically if you launch a MPEG audio (i.e., payload type 14) session. Doing the same for other SDP browsers (e.g., "sdr") should be straightforward. How it works: It's basically a hack. It works by receiving RTP-encapsulated MPEG data, and streaming the decapsulated MPEG frames to Winamp using HTTP, i.e., by acting as a special-purpose HTTP server. (Thanks to Roland Parviainen for this suggestion.) It would have been straightforward to build Unix versions of this tool that work the same way - e.g., by streaming to "mpg123". I haven't done this, though, because (i) I don't have sound on any of my Unix development machines, and (ii) it's the wrong thing to do anyway. Instead the right thing to do would be to either (a) integrate a MPEG decoder into an existing open RTP/RTCP-based audio player (such as "rat"), or (b) integrate RTP/RTCP handling into an existing open MPEG player (such as "mpg123"). Ross. ps. BTW, I'm still not 100% sure whether or not liveCaster's implementation of MPEG-audio-in-RTP is correct, because I have yet to test it with any other receiving implementation. If anyone out there has their own RTP-capable MP3 player, please let me know whether liveCaster works (or doesn't work) with it. From rem-conf Sat Jan 30 01:42:49 1999 From rem-conf-request@es.net Sat Jan 30 01:42:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 106Wjo-0005jA-00; Sat, 30 Jan 1999 01:30:48 -0800 Received: from law-f59.hotmail.com (hotmail.com) [209.185.131.122] by mail1.es.net with smtp (Exim 1.81 #2) id 106Wjn-0005ii-00; Sat, 30 Jan 1999 01:30:47 -0800 Received: (qmail 15248 invoked by uid 0); 30 Jan 1999 09:29:46 -0000 Message-ID: <19990130092946.15247.qmail@hotmail.com> Received: from 157.27.1.33 by www.hotmail.com with HTTP; Sat, 30 Jan 1999 01:29:01 PST X-Originating-IP: [157.27.1.33] From: "Gio tesista" To: angel.mateo@rediris.es Cc: rem-conf@es.net Subject: Re: multicast Date: Sat, 30 Jan 1999 01:29:01 PST Mime-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> I think that you have to a route to the mrouter in the other >computers. = >>For example, add: >> >> route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 >> >>to the /etc/rc.d/rc.local file >> >> >>Salu2 >> >>Angel >> Thanks,but there is alredy this line .Infact if I run "route",I see also >Destination Gatewey Genmask Flag metric Ref Use Iface > >.......... ....... ...... ......... . >.......... ........... ............ >224.0.0.0 * 240.0.0.0 U 0 0 17 etho > >Is it a problem di mrouter?or is it a problem of setting TTL in mrouter? What can I do? >Thanks. > GIO, > > >>> I 'm italian student and I 'm making some experiments on multicast. >I have Linux configured 3 PC with multicast support and one of these >is a multicast router(mrouter).If we create a work session on our same > network,when we run "SD" or "SDR" I see the session on other computers >and it's O.K..The problem is ONLY mrouter see external session (by >tunneling) out my network, but the other 2 computers no.What can I do >to resolve this problem? >> >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Sat Jan 30 10:40:28 1999 From rem-conf-request@es.net Sat Jan 30 10:40:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 106fAG-0001p9-00; Sat, 30 Jan 1999 10:30:40 -0800 Received: from 109.newark-05-10rs.nj.dial-access.att.net (default) [12.78.172.109] by mail1.es.net with smtp (Exim 1.81 #2) id 106fA9-0001oy-00; Sat, 30 Jan 1999 10:30:36 -0800 From: BMC (USA) To: Message-Id: <419.436190.56198310bmc_mailing@bigfoot.com> Subject: ADV: Mail Forwarding Service Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sat, 30 Jan 1999 10:30:36 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Reader, This is a commercial message offering a mail forwarding service. If you wish to be removed from this mailing list, reply with "Remove" in the subject line, and you will be deleted from our list. We do not sell or share our mailing lists. MAIL FORWARDING SERVICE (ESTABLISHED 1995) Enjoy the benefits of having a real street address for the reception of your business or personal mail. We guarantee total confidentiality and security. Mail forwarded to you according to your instructions. Ideal for: - traveling businessmen, - students, - direct marketers, - non USA residents, - importers/exporters, - and others. Benefits: - confidential - cost effective MAIL RECEIVING We can receive letters and parcels from the US Postal Service and, unlike a P.O. Box, we can also recieve shipments from U.P.S., FedEx, DHL, and others. You can also receive registered and certified mail, should you authorize us to do so. Our mail receiving service provides you with a legitimate New Jersey street address, not a P.O. Box. This provides many benefits for individuals and businesses alike. Addresses in other areas are not available at this time. SECURITY We are specialists in the rental of private addresses, packaging and shipping services. We also adhere to the highest standards of confidentiality and security. Your mail is handled in a private, secure fashion by experienced professionals. The confidentiality of mail processing is our number one concern. MAIL FORWARDING SERVICE FEES We can redirect your mail anywhere in the world, according to the your instructions. The handling charges to redirect mail are: $0.50 per letter (business size envelope) plus postage/shipping costs $5.00 for boxed parcels plus postage/shipping costs The mail is forwarded to you according to your instructions, either daily, weekly or monthly. The address would look like this (example): (Your Name) or (Care of BM&Co.) 712 Wyoming Ave. Elizabeth, NJ 07208 USA RATES $10.00 USD per month (minimum rental is 6 months) Example: Rental for 6 months would cost: $ 60.00 USD (Rental) $ 50.00 USD (Deposit for Postage/Handling to redirect your mail) Total $110.00 USD Our rates are among the lowest in the industry and our service is among the best, and unlike others, we have absolutely no setup fees. To sign up for our mail forwarding service, please mail us: - Your name; - Address where you want your mail forwarded to; - Copy of photo ID; - Your e mail address; - Any special instructions; - Phone or fax number (optional). We accept payment by check or money order, in US dollars. We do not accept credit cards. Also inform us of any special arrangements for the handling of your mail. Upon receipt of payment, you will be sent your address via e mail. I look forward to hearing from you. If you have any questions, please call between 9 am to 6pm USA eastern time. At other hours, please leave a message and we will return your call. Sincerely, Bruno Teixeira Accounts Manager BMC (USA) bmc_mailing@bigfoot.com Tel: 00 1 908 820 0720 Fax: 00 1 908 820 4972 From rem-conf Sun Jan 31 00:50:21 1999 From rem-conf-request@es.net Sun Jan 31 00:50:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 106sU1-000687-00; Sun, 31 Jan 1999 00:43:57 -0800 Received: from (Telco) [194.247.228.161] by mail1.es.net with smtp (Exim 1.81 #2) id 106sTy-00067x-00; Sun, 31 Jan 1999 00:43:54 -0800 From: Telco Independent Agent To: Message-Id: <419.436191.36541655TimBrooks4@aol.com> Subject: Save Money on UK Telephone Calls Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 31 Jan 1999 00:43:54 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please take a second to learn how to SAVE 66% on BT residential bills, 80% on Orange or 1-2-1 call charges using the Telco freephone access service.... . - After free registration, simply dial a freephone access number then the destination number to save money on call charges - Free Monthly Itemised Billing - NO deposits, NO line rental, NO operators, NO new equipment For further informaiton please visit:- www.angelfire.com/co/telcoinfo/index.html Thank You From rem-conf Sun Jan 31 03:01:15 1999 From rem-conf-request@es.net Sun Jan 31 03:01:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 106uX3-0007QZ-00; Sun, 31 Jan 1999 02:55:13 -0800 Received: from 1cust128.tnt1.west-palm-beach.fl.da.uu.net (mail.mia.machine) [208.253.42.128] by mail1.es.net with smtp (Exim 1.81 #2) id 106uX1-0007QP-00; Sun, 31 Jan 1999 02:55:11 -0800 To: From: Subject: PUT MONEY INTO YOUR POCKET! BUSINESS OPPORTUNITY AD Date: Wed, 3 Feb 1999 09:17:17 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list VISA/MASTERCARD/AMEX/DISCOVER STOP LOSING MONEY ACCEPT CREDIT CARDS TODAY 67% OF YOUR COMPETITION ACCEPTS CREDIT CARDS. DON'T LET YOUR COMPETITION STEAL YOUR CUSTOMERS. RISK FREE OFFER NO EQUIPMENT NO LEASE NO EXCUSES E COMMERCE AND TELEPHONE PROCESSING CALL STEVE MILLER 1888-290-0617 THIS MESSAGE SENT BY EMAIL KING AND ASSOCIATES 1790 BONHILL RD MISSISSAUGA ON 905 564 5091 TO BE REMOVED DIAL 800 636-6773 X 4692 OR EMAIL bunniesam@EASTMAIL.COM From rem-conf Sun Jan 31 19:58:53 1999 From rem-conf-request@es.net Sun Jan 31 19:58:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 107ANS-0006Ey-00; Sun, 31 Jan 1999 19:50:22 -0800 Received: from 1cust216.tnt20.dfw5.da.uu.net (localhost) [208.254.189.216] by mail1.es.net with smtp (Exim 1.81 #2) id 107ANP-0006Eo-00; Sun, 31 Jan 1999 19:50:20 -0800 From: Subject: ADV:CREDIT CARD PROCESSING Date: Sun, 31 Jan 1999 16:12:17 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ********************************************************* This message is being brought to you by World Tek Inc. To be removed from from further mailings respond to this message with "remove" in the subject line. ********************************************************* Dear Friend, Discover how you can accept credit cards directly >from your website, telephone or fax for your products and services and never need to purchase or lease expensive credit card equipment or pay a large monthly fee for online ordering capabilities or real time processing transactions. **Brand New** Inteli-Charge Credit Card acceptance program allows you to accept Visa, MastercardTM, Amex and Discover any TIME,any WHERE through phone, fax or internet without the need to purchase or lease expensive credit card equipment. This brand new program will allow you to accept credit cards in 24-48 hours after submitting your application. You simply pick up your telephone, dial a special toll free 800# 24 hrs a day 7 days a week, input a passcode and the credit card # and receive an immediate authorization over the phone. Within 2 days the money is deposited in your bank account. This is an exciting program for all businesses. Before you spend any money on a credit card merchant program LOOK at this new program! We have virtually a 100% approval for most business types regardless of past credit history! If you have an interest in learning more about a Merchant Account for yourself or your business please email your Name, PHONE NUMBER (Don't forget your area code) and best time to call to: mailto:acctsvs@bellsouth.net A representative will return your call within 24hrs. Or feel free to call us on our 24 hour voicemail at: 1-800-600-0343 Ext:2104 P.S. ALSO AS PART OF A SPECIAL NATIONAL PROMOTION, IF YOU ACT NOW YOU WILL RECEIVE A FREE ONLINE STORE WITH SECURE ORDERING CAPABILITIES TO SELL YOUR PRODUCTS ONLINE! This offer only applies to U.S. Residents only and some Canadians with valid U.S. Social Security #'s World Tek Inc. 7210 Jordan Ave. Canoga Park Ca. 91303