From rem-conf Thu Mar 01 08:18:43 2001 From rem-conf-request@es.net Thu Mar 01 08:18:42 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YVTs-0004kx-00; Thu, 1 Mar 2001 07:59:04 -0800 Received: from illustrious.concentric.net (illustrious.cnchost.com) [207.155.252.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YVTr-0004kn-00; Thu, 1 Mar 2001 07:59:03 -0800 Received: from auvo.com (4032268D.ptr.dia.nextlink.net [64.50.38.141]) by illustrious.cnchost.com id KAA10333; Thu, 1 Mar 2001 10:59:02 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A9E71EB.6B1947AC@auvo.com> Date: Thu, 01 Mar 2001 09:59:39 -0600 From: Jeff Meunier Organization: Auvo Technologies Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: audio MIME types & (expired) RTP profile I-D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen, Henning, 1) What is the status of the now-expired update to the RTP profile draft-ietf-avt-profile-new-09.txt? 2) What is the status/progress in getting MIME types for the various audio encodings? Of those listed in the profile, it appears only L16 is registered to-date. From the expired I-D... ----- name of sampling default encoding sample/frame bits/sample rate ms/frame ms/packet __________________________________________________________________ 1016 frame N/A 8,000 30 30 DVI4 sample 4 var. 20 G722 sample 8 16,000 20 G723 frame N/A 8,000 30 30 G726-32 sample 4 8,000 20 G728 frame N/A 8,000 2.5 20 G729 frame N/A 8,000 10 20 G729D frame N/A 8,000 10 20 G729E frame N/A 8,000 10 20 GSM frame N/A 8,000 20 20 GSM-HR frame N/A 8,000 20 20 GSM-EFR frame N/A 8,000 20 20 L8 sample 8 var. 20 L16 sample 16 var. 20 LPC frame N/A 8,000 20 20 MPA frame N/A var. var. PCMA sample 8 var. 20 PCMU sample 8 var. 20 QCELP frame N/A 8,000 20 20 VDVI sample var. var. 20 Table 1: Properties of Audio Encodings (N/A: not applicable; var.: variable) ----- G.722 is not registered, however there is a registration for G.722.1. PCMU is partially covered by audio/basic. From RFC2046... The content of the "audio/basic" subtype is single channel audio encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz. Thanks, Jeff -- Jeff Meunier Auvo Technologies Inc. jmeunier@auvo.com From rem-conf Thu Mar 01 08:29:58 2001 From rem-conf-request@es.net Thu Mar 01 08:29:58 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YVoi-0005CX-00; Thu, 1 Mar 2001 08:20:36 -0800 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YVog-0005CN-00; Thu, 1 Mar 2001 08:20:35 -0800 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA00956 for ; Thu, 1 Mar 2001 09:20:33 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA24938 for ; Thu, 1 Mar 2001 09:20:32 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id KAA27998; Thu, 1 Mar 2001 10:20:31 -0600 (CST) Received: from cig.mot.com (d42-506b.cig.mot.com [160.15.80.107]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id KAA03249; Thu, 1 Mar 2001 10:20:30 -0600 (CST) Message-Id: <200103011620.KAA03249@agevole.cig.mot.com> Date: Thu, 01 Mar 2001 10:24:03 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Magnus Westerlund , rem-conf@es.net Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt References: <200102261208.HAA05438@ietf.org> <200102261932.NAA20611@agevole.cig.mot.com> <3A9B553E.ED964A00@era-t.ericsson.se> <3A9BB1BD.8C7FCF06@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I second Henning's opinion completely. Maybe we should take a look at adding the "I" option to the classic AMR payload format now (it's about to get into IESG last call), so that we only need one AMR payload format for both "classic" AMR and AMR WB codecs. -Qiaobing "Henning G. Schulzrinne" wrote: > > These are separate issues: it makes perfect sense to have two different > payload type *numbers* (for different sampling rates), yet re-use the > same *format*. This allows both code re-use and demultiplexing. Thus, > I'd really like to discourage gratuitous differences in payload formats, > as that simply increases end system complexity and testing effort. > > Magnus Westerlund wrote: > > > > Qiaobing, > > > > There are several reasons why there should be different payload formats, the two > > largest are: First, AMR and AMR WB are two different codecs, with totally separate > > implementations. As they are separate, the demultiplexing of codec used in a RTP > > stream are best handled by the payload type. Secondly they are using different > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with > > different rates in one payload format would be difficult. > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Mar 01 12:07:10 2001 From rem-conf-request@es.net Thu Mar 01 12:07:09 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YZBA-0001t0-00; Thu, 1 Mar 2001 11:56:00 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14YZB8-0001sq-00; Thu, 1 Mar 2001 11:55:58 -0800 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA05008; Thu, 1 Mar 2001 11:46:35 -0800 Message-ID: <3A9EA81C.4838CFD5@bmrc.berkeley.edu> Date: Thu, 01 Mar 2001 11:50:52 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 3/7 Distribution Architectures for Dynamic Internet Traffic -- Americ Azevedo, Interdisciplinary Studies -- U.C. Berkeley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Dynamic Integration of Large Live Classroom Lectures, Streaming Media, and Text-based Student Feedback Wednesday, March 07, 2001 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Americ Azevedo Interdisciplinary Studies U.C. Berkeley I started with a large 500 student lecture hall class (IDS110) at UC Berkeley. Classroom alienation and inadequate opportunities for student participation and feedback are major issues with such a class. I looked at current e-learning platforms on the market, but these products did not support discussions and feedback from students in an eloquent and easy way. They were content-centric, not discussion-feedback centric in their instructional metaphors. So we proceed to creation a new discussion-centric online format. Over a period of four weeks we built a discussion-centric e-learning platform and supporting "cultureware" for supporting rapid feedback and dialogue. One thing that was unique about this experiment is that students were in engaged in the process of creating the pattern language for the feedback system. As the system became more widely used by the students, we incorporated video playbacks (from BIBS). Some students discovered that they could try to communicate with the instructor while the lecture is live. That was an unexpected surprise. Assignment submission, creative problem writing, knowledge sharing, development of a learning community, and special student interest topics have been among the benefits noticed in this approach. Other impacts are the eventual change of the lab session structure and possible "publication" of the course ot wider audiences. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Mar 01 12:31:52 2001 From rem-conf-request@es.net Thu Mar 01 12:31:51 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YZi8-0003An-00; Thu, 1 Mar 2001 12:30:04 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14YZi7-0003A8-00; Thu, 1 Mar 2001 12:30:03 -0800 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA05298; Thu, 1 Mar 2001 12:23:40 -0800 Message-ID: <3A9EB0CD.48EFF61A@bmrc.berkeley.edu> Date: Thu, 01 Mar 2001 12:27:57 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 3/7 Berkeley Multimedia, Interfaces and Graphics Seminar Content-Type: multipart/alternative; boundary="------------8A174FADA979E381928DADA5" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------8A174FADA979E381928DADA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please disregard the subject line for the seminar announcement on 3/7. The title should be: Dynamic Integration of Large Live Classroom Lectures, Streaming Media, and Text-based Student Feedback. The rest of the information remains the same. --------------8A174FADA979E381928DADA5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please disregard the subject line for the seminar announcement on 3/7. The title should be:  Dynamic Integration of Large Live Classroom Lectures, Streaming Media, and Text-based Student Feedback. The rest of the information remains the same. --------------8A174FADA979E381928DADA5-- From rem-conf Thu Mar 01 13:35:43 2001 From rem-conf-request@es.net Thu Mar 01 13:35:43 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Yahs-0004nx-00; Thu, 1 Mar 2001 13:33:52 -0800 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Yahq-0004nn-00; Thu, 1 Mar 2001 13:33:51 -0800 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id QAA29792; Thu, 1 Mar 2001 16:33:41 -0500 (EST) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f21LXmd20015; Thu, 1 Mar 2001 16:33:48 -0500 Message-Id: <200103012133.f21LXmd20015@chiron.east.isi.edu> To: Jeff Meunier cc: rem-conf@es.net Subject: Re: audio MIME types & (expired) RTP profile I-D In-Reply-To: Your message of "Thu, 01 Mar 2001 09:59:39 CST." <3A9E71EB.6B1947AC@auvo.com> Date: Thu, 01 Mar 2001 16:33:48 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jeff Meunier writes: >Stephen, Henning, > >1) What is the status of the now-expired update to the RTP profile >draft-ietf-avt-profile-new-09.txt? Expect a new version to be submitted for this meeting. >2) What is the status/progress in getting MIME types for the various >audio encodings? Of those listed in the profile, it appears only L16 is >registered to-date. From the expired I-D... The MIME registration i-d draft-ietf-avt-rtp-mime-03.txt has also expired, but will be updated soon. Note that the following codecs will not be registered, and will be removed >from the profile, unless we get interop results: - Audio codecs: 1016, G.723, GSM-HR, GSM-EFR - Video codecs: MP2T, H.263, BT.656, MP1S, MP2P, BMPEG Colin From rem-conf Thu Mar 01 20:05:08 2001 From rem-conf-request@es.net Thu Mar 01 20:05:07 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Ygk1-0002pe-00; Thu, 1 Mar 2001 20:00:29 -0800 Received: from fe6.southeast.rr.com (Mail6.nc.rr.com) [24.93.67.53] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Ygjz-0002pU-00; Thu, 1 Mar 2001 20:00:27 -0800 Received: from v3f6b5 ([24.162.246.42]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 1 Mar 2001 23:00:26 -0500 From: "Injong Rhee" To: Subject: mp4 file format Date: Thu, 1 Mar 2001 22:54:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, could someone tell me where I can find the exact specification of mp4 file format? I looked into iso, but it seems that it does not have mpeg4 system version 2 available yet. Thanks in advance for the information. Injong Rhee Assistant Professor NCSU From rem-conf Thu Mar 01 23:32:18 2001 From rem-conf-request@es.net Thu Mar 01 23:32:17 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Yjz2-00060T-00; Thu, 1 Mar 2001 23:28:12 -0800 Received: from chonnam.chonnam.ac.kr [168.131.33.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Yjz0-000603-00; Thu, 1 Mar 2001 23:28:10 -0800 Received: from yojiny (pc85079.chonnam.ac.kr [168.131.85.79] (may be forged)) by chonnam.chonnam.ac.kr (8.10.0/8.10.0) with SMTP id f227RRj23374 for ; Fri, 2 Mar 2001 16:27:27 +0900 Reply-To: From: "Yang Yo-Jin" To: Subject: Date: Fri, 2 Mar 2001 16:23:50 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list DQpJIGFtIG5vdmljZSBpbiBydHAuDQpJIGRvdWJ0IHRoaXMgbWFpbGluZyBsaXN0IGlzIHByb3Bl ciBzaXRlIHRvIGlucXVpcnkuDQpJIHdhbnQgdG8ga25vdyBydHAgYW5kIHJ0Y3AgYW5kIGZ1bmN0 aW9uIG9mIHRoZW0uDQphbmQgbXVsdGltZWRpYSBkYXRhIGZvcm1hdCB3aXRoIHRoZW0uDQphbmQg aG93IHRvIHNlZ21lbnRlZCB0aGF0IGRhdGEgaW50byBwYWNrZXQuDQppZiBhbnlib2R5IGtub3cg Z29vZCBwb2ludCBhYm91dCBteSBxdWVzdGlvbi4NCnRlbGwgbWUgdGhlIGRpcmVjdGlvbi4NCg0K dGhhbmtzIGluIGRhdmFuY2UuDQpTaW5jZXJlbHkgeW91cnMuDQp5b2ppbnkgDQoNCllhbmcsIFlv LUppbiAgdTAwMjAzNjhAY2hvbm5hbS5jaG9ubmFtLmFjLmtyDQpDZWxsdWxhciAwMTEtNjEyLTM4 ODYNCkhhdmUgYSBuaWNlIGRheSEhIQ== From rem-conf Fri Mar 02 01:14:07 2001 From rem-conf-request@es.net Fri Mar 02 01:14:06 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YlaT-0000RX-00; Fri, 2 Mar 2001 01:10:57 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YlaS-0000RN-00; Fri, 2 Mar 2001 01:10:56 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id KAA27643; Fri, 2 Mar 2001 10:10:52 +0100 (MET) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma027641; Fri, 2 Mar 01 10:10:52 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA15580; Fri, 2 Mar 2001 10:10:51 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA25523; Fri, 2 Mar 2001 10:10:50 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900016306520; Fri, 2 Mar 2001 10:22:15 +0100 To: , Subject: RE: mp4 file format Message-ID: <0056900016306520000002L002*@MHS> Reply-To: <"CN=Philippe Gentric/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1"@unregistered.philips.com> Date: Fri, 2 Mar 2001 10:22:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/02/01 10:09:06" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The MPEG document you want is: W3850.doc, chapter 13 Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com Check our web site at: www.mpeg-4player.com > -----Original Message----- > From: rhee@eos.ncsu.edu [mailto:rhee@eos.ncsu.edu] > Sent: Friday, March 02, 2001 05:27 > To: rem-conf@es.net > Subject: mp4 file format > > > > Hi, > > could someone tell me where I can find the exact specification of mp4= file > format? I looked into iso, but it seems that it does not have mpeg4 s= ystem > version 2 available yet. > > Thanks in advance for the information. > > Injong Rhee > Assistant Professor > NCSU > = From rem-conf Fri Mar 02 01:31:23 2001 From rem-conf-request@es.net Fri Mar 02 01:31:22 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Yls1-0001L9-00; Fri, 2 Mar 2001 01:29:05 -0800 Received: from alc119.alcatel.be (relay1.alcatel.be) [195.207.101.119] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Ylrx-0001JL-00; Fri, 2 Mar 2001 01:29:03 -0800 Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f229RLf07670; Fri, 2 Mar 2001 10:27:21 +0100 (MET) Received: by bemail05.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A03.0033EDCD ; Fri, 2 Mar 2001 10:27:12 +0100 X-Lotus-FromDomain: ALCATEL From: Wim.Van_Den_Boeck@alcatel.be To: Qiaobing Xie cc: "Henning G. Schulzrinne" , Magnus Westerlund , rem-conf@es.net Message-ID: Date: Fri, 2 Mar 2001 10:27:06 +0100 Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, About the yes/not separation of the AMR (say(1)) and AMR WB (say (2)) payload drafts... I'm puzzling about which are the application domains of this new formats. Is it so that (1) was originally planned for use in UMTS, while (2) is proposed as a 'new GSM' codec ? Do the payload formats correspond with those 2 cases ? I guess so. Isn't it possible that both streams of information will one day pass over the same networks and that thus a uniform format might be interesting ? Therefore I also support the idea of adapting the classical "RTP payload format for AMR" draft, rather than producing 2 drafts. cheers Wim Qiaobing Xie on 01/03/2001 17:24:03 To: "Henning G. Schulzrinne" cc: Magnus Westerlund , rem-conf@es.net(bcc: Wim VAN DEN BOECK/BE/ALCATEL) Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt I second Henning's opinion completely. Maybe we should take a look at adding the "I" option to the classic AMR payload format now (it's about to get into IESG last call), so that we only need one AMR payload format for both "classic" AMR and AMR WB codecs. -Qiaobing "Henning G. Schulzrinne" wrote: > > These are separate issues: it makes perfect sense to have two different > payload type *numbers* (for different sampling rates), yet re-use the > same *format*. This allows both code re-use and demultiplexing. Thus, > I'd really like to discourage gratuitous differences in payload formats, > as that simply increases end system complexity and testing effort. > > Magnus Westerlund wrote: > > > > Qiaobing, > > > > There are several reasons why there should be different payload formats, the two > > largest are: First, AMR and AMR WB are two different codecs, with totally separate > > implementations. As they are separate, the demultiplexing of codec used in a RTP > > stream are best handled by the payload type. Secondly they are using different > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with > > different rates in one payload format would be difficult. > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Fri Mar 02 01:33:23 2001 From rem-conf-request@es.net Fri Mar 02 01:33:22 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YluV-0001Pm-00; Fri, 2 Mar 2001 01:31:39 -0800 Received: from alc119.alcatel.be (relay1.alcatel.be) [195.207.101.119] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YluU-0001Lp-00; Fri, 2 Mar 2001 01:31:38 -0800 Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f229SXs07998; Fri, 2 Mar 2001 10:28:33 +0100 (MET) Received: by bemail05.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A03.003409AF ; Fri, 2 Mar 2001 10:28:23 +0100 X-Lotus-FromDomain: ALCATEL From: Wim.Van_Den_Boeck@alcatel.be To: Qiaobing Xie cc: "Henning G. Schulzrinne" , Magnus Westerlund , rem-conf@es.net Message-ID: Date: Fri, 2 Mar 2001 10:28:17 +0100 Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, About the yes/not separation of the AMR (say(1)) and AMR WB (say (2)) payload drafts... I'm puzzling about which are the application domains of this new formats. Is it so that (1) was originally planned for use in UMTS, while (2) is proposed as a 'new GSM' codec ? Do the payload formats correspond with those 2 cases ? I guess so. Isn't it possible that both streams of information will one day pass over the same networks and that thus a uniform format might be interesting ? Therefore I also support the idea of adapting the classical "RTP payload format for AMR" draft, rather than producing 2 drafts. cheers Wim Qiaobing Xie on 01/03/2001 17:24:03 To: "Henning G. Schulzrinne" cc: Magnus Westerlund , rem-conf@es.net(bcc: Wim VAN DEN BOECK/BE/ALCATEL) Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt I second Henning's opinion completely. Maybe we should take a look at adding the "I" option to the classic AMR payload format now (it's about to get into IESG last call), so that we only need one AMR payload format for both "classic" AMR and AMR WB codecs. -Qiaobing "Henning G. Schulzrinne" wrote: > > These are separate issues: it makes perfect sense to have two different > payload type *numbers* (for different sampling rates), yet re-use the > same *format*. This allows both code re-use and demultiplexing. Thus, > I'd really like to discourage gratuitous differences in payload formats, > as that simply increases end system complexity and testing effort. > > Magnus Westerlund wrote: > > > > Qiaobing, > > > > There are several reasons why there should be different payload formats, the two > > largest are: First, AMR and AMR WB are two different codecs, with totally separate > > implementations. As they are separate, the demultiplexing of codec used in a RTP > > stream are best handled by the payload type. Secondly they are using different > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with > > different rates in one payload format would be difficult. > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Fri Mar 02 01:44:12 2001 From rem-conf-request@es.net Fri Mar 02 01:44:11 2001 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14Ym0t-00035A-00; Fri, 2 Mar 2001 01:38:15 -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 14Ym0s-00032u-00; Fri, 2 Mar 2001 01:38:14 -0800 Received: from ideon (dhcp35-152.vmlabs.com [10.1.35.152] (may be forged)) by galahad.vmlabs.com (8.8.8+Sun/8.8.8) with SMTP id BAA16731 for ; Fri, 2 Mar 2001 01:37:57 -0800 (PST) Reply-To: From: "Wilson C. Chung" To: Subject: MPEG4 FDIS v2.0 Document No Date: Fri, 2 Mar 2001 01:31:04 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0056900016306520000002L002*@MHS> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can someone tell me what is the documention number of MPEG4 FDIS v2.0? Tx, Wilson C. Chung Director of Network Product Dev, VM Labs From rem-conf Fri Mar 02 02:19:23 2001 From rem-conf-request@es.net Fri Mar 02 02:19:22 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Ymc8-0003wI-00; Fri, 2 Mar 2001 02:16:44 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 14Ymc7-0003w5-00; Fri, 2 Mar 2001 02:16:43 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Mar 2001 10:16:27 +0000 From: Orion Hodson To: Wim.Van_Den_Boeck@alcatel.be cc: Magnus Westerlund , rem-conf@es.net Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt In-reply-to: Your message of "Fri, 02 Mar 2001 10:28:17 +0100." Date: Fri, 02 Mar 2001 10:16:25 +0000 Message-ID: <427.983528185@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Wim.Van_Den_Boeck@alcatel.be writes: > > About the yes/not separation of the AMR (say(1)) and AMR WB (say > (2)) payload drafts... I'm puzzling about which are the application > domains of this new formats. Is it so that (1) was originally > planned for use in UMTS, while (2) is proposed as a 'new GSM' codec ? > > Do the payload formats correspond with those 2 cases ? I guess so. > > Isn't it possible that both streams of information will one day pass > over the same networks and that thus a uniform format might be > interesting ? Yes, but you cannot assume all endpoints support the formats - capabilities need to be negotiated (ergo SIP/SAP/SDP). And there are no static payloads for new formats so negotiation has to happen. > Therefore I also support the idea of adapting the classical "RTP > payload format for AMR" draft, rather than producing 2 drafts. The drafts are similar but the authors to decide how these payloads are described with least ambiguity. Describing 2 similiar, but subtlely different formats might be better in two documents. Kind Regards - Orion. BTW, I didn't fully understand the earlier comment about sampling rates and clocks preventing a single draft. Most of the RTP audio formats use the sampling clock for timestamps (eg. l16-8k uses 8kHz, l16-44100 uses 44.1kHz). It's easily resolved when using SDP, the 8kHz and 16kHz get different payload id's. > > Magnus Westerlund wrote: > > > > > > Qiaobing, > > > > > > There are several reasons why there should be different payload formats, the two > > > largest are: First, AMR and AMR WB are two different codecs, with totally separate > > > implementations. As they are separate, the demultiplexing of codec used in a RTP > > > stream are best handled by the payload type. Secondly they are using different > > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with > > > different rates in one payload format would be difficult. > > > > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > From rem-conf Fri Mar 02 03:50:53 2001 From rem-conf-request@es.net Fri Mar 02 03:50:52 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Yo0r-0005vk-00; Fri, 2 Mar 2001 03:46:21 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Yo0p-0005va-00; Fri, 2 Mar 2001 03:46:19 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25654; Fri, 2 Mar 2001 06:46:16 -0500 (EST) Message-Id: <200103021146.GAA25654@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-amr-05.txt Date: Fri, 02 Mar 2001 06:46:16 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for AMR Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt, Q. Xie, S. Gupta Filename : draft-ietf-avt-rtp-amr-05.txt Pages : 20 Date : 01-Mar-01 This document describes a proposed real-time transport protocol (RTP) payload format for AMR speech encoded signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-amr-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-amr-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010301141332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141332.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 02 08:40:00 2001 From rem-conf-request@es.net Fri Mar 02 08:39:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YsRV-0002gM-00; Fri, 2 Mar 2001 08:30:09 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YsRT-0002gC-00; Fri, 2 Mar 2001 08:30:07 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA19613 for ; Fri, 2 Mar 2001 17:30:04 +0100 (MET) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma019608; Fri, 2 Mar 01 17:30:04 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA22991 for ; Fri, 2 Mar 2001 17:30:02 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA05437 for ; Fri, 2 Mar 2001 17:30:01 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900016328495; Fri, 2 Mar 2001 17:41:26 +0100 To: Subject: new draft of MPEG-4 "generic" RTP payload format Message-ID: <0056900016328495000002L052*@MHS> Reply-To: <"CN=Philippe Gentric/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1"@unregistered.philips.com> Date: Fri, 2 Mar 2001 17:41:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/02/01 17:26:23" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just sent to ietf-drafts a new version of : draft-gentric-avt-mpeg4-multipleSL-02.txt that obsoletes draft-gentric-avt-mpeg4-multipleSL-01.txt This is the version that will be presented at the 50th IETF meeting in Minneapolis. ****************** PS: Changes between these versions are: - added section on segmentation rules - added section on handling scene description streams - added an acknowledgement section - fixed figures to fit better IETF style - updated section on multiplexing to refer to recent IETF draft - for improved clarity, changed "XXXX section" into names: "XXXXSection= " - removed name collision for SLPPSize into SLPPayloadSize (was same name for RTP field and SDP parameter) - fixed typos, updated references, dates, etc ************** Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com Check our web site at: www.mpeg-4player.com = From rem-conf Fri Mar 02 09:07:54 2001 From rem-conf-request@es.net Fri Mar 02 09:07:53 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Ysx7-0003uc-00; Fri, 2 Mar 2001 09:02:49 -0800 Received: from (appserver.edcncstate.org) [207.59.130.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Ysx6-0003uS-00; Fri, 2 Mar 2001 09:02:48 -0800 Received: from rhee (207.59.130.3 [207.59.130.3]) by appserver.edcncstate.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FKHBF6N0; Fri, 2 Mar 2001 11:59:22 -0500 From: "Injong Rhee" To: Cc: Subject: RE: mp4 file format Date: Fri, 2 Mar 2001 11:50:38 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0056900016306520000002L002*@MHS> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is this currently ISO document? I thought it is in system ISO/IEC 14496-1:1999, but the document does not have it. Is it in ISO/IEC 14496-6:2000? > -----Original Message----- > From: philippe.gentric@philips.com [mailto:philippe.gentric@philips.com] > Sent: Friday, March 02, 2001 4:22 AM > To: rem-conf@es.net; rhee@eos.ncsu.edu > Subject: RE: mp4 file format > > > > The MPEG document you want is: > > W3850.doc, chapter 13 > > Regards, > > Philippe Gentric > Software Architect > PHILIPS DIGITAL NETWORKS > Broadcast & Internet Delivery Solutions > Laboratoires d'Electronique Philips > B.P. 15 - 22, Av. Descartes > 94453 Limeil-Brevannes Cedex France > Phone : 33 (0)1 45 10 68 12 > Fax : 33 (0)1 45 10 69 60 > philippe.gentric@philips.com > Check our web site at: www.mpeg-4player.com > > > > -----Original Message----- > > From: rhee@eos.ncsu.edu [mailto:rhee@eos.ncsu.edu] > > Sent: Friday, March 02, 2001 05:27 > > To: rem-conf@es.net > > Subject: mp4 file format > > > > > > > > Hi, > > > > could someone tell me where I can find the exact specification > of mp4 file > > format? I looked into iso, but it seems that it does not have > mpeg4 system > > version 2 available yet. > > > > Thanks in advance for the information. > > > > Injong Rhee > > Assistant Professor > > NCSU > > > > From rem-conf Fri Mar 02 15:11:37 2001 From rem-conf-request@es.net Fri Mar 02 15:11:36 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14YyYK-0002WD-00; Fri, 2 Mar 2001 15:01:36 -0800 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 14YyYI-0002W3-00; Fri, 2 Mar 2001 15:01:35 -0800 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id SAA16601; Fri, 2 Mar 2001 18:01:25 -0500 (EST) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f22N1Vr21760; Fri, 2 Mar 2001 18:01:31 -0500 Message-Id: <200103022301.f22N1Vr21760@chiron.east.isi.edu> To: Orion Hodson cc: Wim.Van_Den_Boeck@alcatel.be, Magnus Westerlund , rem-conf@es.net Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt In-Reply-To: Your message of "Fri, 02 Mar 2001 10:16:25 GMT." <427.983528185@cs.ucl.ac.uk> Date: Fri, 02 Mar 2001 18:01:31 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is also worth noting that the AMR payload format has taken longer than would have been desirable, and that further delay could be problematic. My suggestion is that the authors of the AMR-WB payload format consider if it can be made identical to the standard AMR payload format. In that case, the draft can be a simple MIME registration plus a pointer to the other document. Otherwise we need to define a new payload format, which will need a new draft anyway. This avoid confusion and further delay to the AMR payload. Colin --> Orion Hodson writes: > >Wim.Van_Den_Boeck@alcatel.be writes: >> >> About the yes/not separation of the AMR (say(1)) and AMR WB (say >> (2)) payload drafts... I'm puzzling about which are the application >> domains of this new formats. Is it so that (1) was originally >> planned for use in UMTS, while (2) is proposed as a 'new GSM' codec ? >> >> Do the payload formats correspond with those 2 cases ? I guess so. >> >> Isn't it possible that both streams of information will one day pass >> over the same networks and that thus a uniform format might be >> interesting ? > >Yes, but you cannot assume all endpoints support the formats - >capabilities need to be negotiated (ergo SIP/SAP/SDP). And there are >no static payloads for new formats so negotiation has to happen. > >> Therefore I also support the idea of adapting the classical "RTP >> payload format for AMR" draft, rather than producing 2 drafts. > >The drafts are similar but the authors to decide how these payloads >are described with least ambiguity. Describing 2 similiar, but >subtlely different formats might be better in two documents. > >Kind Regards >- Orion. > >BTW, I didn't fully understand the earlier comment about sampling >rates and clocks preventing a single draft. Most of the RTP audio >formats use the sampling clock for timestamps (eg. l16-8k uses 8kHz, >l16-44100 uses 44.1kHz). It's easily resolved when using SDP, the >8kHz and 16kHz get different payload id's. > > >> > Magnus Westerlund wrote: >> > > >> > > Qiaobing, >> > > >> > > There are several reasons why there should be different payload formats, the two >> > > largest are: First, AMR and AMR WB are two different codecs, with totally separate >> > > implementations. As they are separate, the demultiplexing of codec used in a RTP >> > > stream are best handled by the payload type. Secondly they are using different >> > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with >> > > different rates in one payload format would be difficult. >> > > >> > >> > -- >> > Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> >> >> >> > From rem-conf Fri Mar 02 17:55:52 2001 From rem-conf-request@es.net Fri Mar 02 17:55:51 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Z1Bd-0005Ua-00; Fri, 2 Mar 2001 17:50:21 -0800 Received: from (public.info.gx.cn) [202.103.224.216] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Z1BQ-0005GS-00; Fri, 2 Mar 2001 17:50:08 -0800 Received: from rsvp-208-187-57-36.ac05.rcrd.eli.net_[208.187.57.36] [208.187.57.36] by public.info.gx.cn (SMTPD32-5.08) id A174CE0152; Fri, 02 Mar 2001 21:30:28 +0800 Received: from mail.ciberteca.es by rsvp-208-187-57-36.ac05.rcrd.eli.net with ESMTP; Fri, 02 Mar 2001 07:20:12 -0600 Message-ID: <00001d6777b8$000039fb$00001039@mail.ciberteca.es> To: From: maurice8384@desertmail.com Subject: LOW INTEREST ON CREDIT CARDS BILLS-YOU QUALIFY!! 4153 Date: Fri, 02 Mar 2001 07:20:04 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bobjones@sudanmail.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello

<= p>

From rem-conf Sat Mar 03 12:21:34 2001 From rem-conf-request@es.net Sat Mar 03 12:21:33 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ZII8-00064L-00; Sat, 3 Mar 2001 12:06:12 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ZII5-00064B-00; Sat, 3 Mar 2001 12:06:10 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id OAA04541 for ; Sat, 3 Mar 2001 14:56:19 -0500 Message-Id: <200103031956.OAA04541@purple.east.isi.edu> To: rem-conf@es.net Subject: New internet-draft: AV timing Date: Sat, 03 Mar 2001 14:56:19 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've been asked to forward the following... We're looking into the problems with the list. Colin ------- Forwarded Message --> Chuck Harrison writes: >Colin, > >I remain frustrated by the fact that my posts to rem-conf do not appear >and that rem-conf-request@es.net and postmaster@es.net have not >responded to my inquiries. > >May I ask you to forward this email to the list? > >Thanks, > Chuck > >----begin included text----- > >Greetings! > >I have submitted a draft regarding synchronization requirements for >professional audio/video transport. This draft suggests that RTP can be >applied, if a small number of new features are implemented. > >http://www.ietf.org/internet-drafts/draft-harrison-avt-precision-av-00.txt > >Cheers, > Chuck Harrison > Far Field Associates, LLC > member, SMPTE DC28.1 Steering Committee on Digital Cinema > +1 360 863 8340 (voice) GMT-0800 > >----end included text----- ------- End of Forwarded Message From rem-conf Sun Mar 04 07:30:21 2001 From rem-conf-request@es.net Sun Mar 04 07:30:21 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ZaLw-0001JY-00; Sun, 4 Mar 2001 07:23:20 -0800 Received: from bbip-t-001-pool-140.tmns.net.au (mail.bigpond.com) [139.134.173.140] by mail1.es.net with smtp (Exim 1.81 #2) id 14ZaLn-0001Iw-00; Sun, 4 Mar 2001 07:23:12 -0800 From: Subject: Make over a half million dollars every 4 to 5 months from your home Date: Mon, 5 Mar 2001 02:03:24 Message-Id: <744.754096.211058@mail.bigpond.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend & Future Millionaire: AS SEEN ON NATIONAL TV : ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time'' THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: '' Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ================================================================= ==== Here is another testimonial: ''' this program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ================ PRINT THIS NOW FOR YOUR FUTURE REFERENCE ========== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: ================ Order all 5 reports shown on the list below ================= For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. === Within a few days you will receive, vie e-mail, each of the 5 reports >from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them >from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. === IMPORTANT __ DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will lose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================================= ==== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you lose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ================================================================= ==== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ================================================================= ==== REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ================================================================= ==== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. ====================== AVAILABLE REPORTS==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ================================================================= ==== REPORT # 1 : ''The Insider's Guide to Advertising for Free on the Net'' Order Report # 1 from: Ross Wein Lot 50 Heritage Dr Bargara Queensland 4670 Australia _________________________________________________________________ REPORT # 2 : ''The Insider's Guide to Sending Bulk e-mail on the Net'' Order Report # 2 from : Kevin Dodd 150 Main St. North P.O. Box #74061 Brampton, Ontario LV6 1MO Canada _________________________________________________________________ REPORT # 3 : ''The Secret to Multilevel marketing on the net'' Order Report # 3 from: Kris H. Webber Sankt Hansgade 24,3th. Copenhagen 2200 Denmark ________________________________________________________________ REPORT # 4 : ''How to become a millionaire utilizing MLM & the Net'' Order Report # 4 from: Loren Stone P. O. Box 6232 Clearfield, UT 84089 USA ________________________________________________________________ REPORT # 5 : ''HOW TO SEND 1 MILLION E-MAILS FOR FREE'' Order Report # 5 from: A.S. Dorsey 521 Lee Street Hampton, VA 23669 USA ______________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ================================================================= ==== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ==================== MORE TESTIMONIALS====================== '' My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ================================================================= ==== '' Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada ================================================================= ==== '' I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. ================================================================= ==== '' It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand ================================================================= ==== ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ================================================================= ==== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. ============================THE END========================= This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. From rem-conf Sun Mar 04 17:26:57 2001 From rem-conf-request@es.net Sun Mar 04 17:26:56 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ZjbN-0003gL-00; Sun, 4 Mar 2001 17:15:53 -0800 Received: from (ish7.ericsson.com.au) [203.61.155.111] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ZjbL-0003fn-00; Sun, 4 Mar 2001 17:15:51 -0800 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA13495 for ; Mon, 5 Mar 2001 12:14:28 +1100 (EST) Received: from epa.epa.ericsson.se (epa [146.11.8.1]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA19160 for ; Mon, 5 Mar 2001 12:13:50 +1100 (EST) Received: from ericsson.com.au (mc2dh207.epa.ericsson.se [146.11.87.207]) by epa.epa.ericsson.se (8.9.1b+Sun/8.9.3) with ESMTP id MAA02374 for ; Mon, 5 Mar 2001 12:14:27 +1100 (EST) Message-ID: <3AA2E872.AC1C348A@ericsson.com.au> Date: Mon, 05 Mar 2001 12:14:26 +1100 From: Ian Rytina X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt References: <200103022301.f22N1Vr21760@chiron.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree with this suggestion. These are different codecs, with different applications (e.g. AMR-WB is better for hi-fi quality music, something that AMR struggles on). To answer a previous question, both codecs will be used by both UMTS and GSM, the AMR-WB spec is going for approval by 3GPP plenary in the next few weeks. Since they are both have an adaptive rate function, there will be shared functionality, but there is no reason why the AMR-WB spec cannot point back to the AMR spec for those particular functions. /Ian. Colin Perkins wrote: > It is also worth noting that the AMR payload format has taken longer than > would have been desirable, and that further delay could be problematic. > > My suggestion is that the authors of the AMR-WB payload format consider if > it can be made identical to the standard AMR payload format. In that case, > the draft can be a simple MIME registration plus a pointer to the other > document. Otherwise we need to define a new payload format, which will need > a new draft anyway. > > This avoid confusion and further delay to the AMR payload. > > Colin > > --> Orion Hodson writes: > > > >Wim.Van_Den_Boeck@alcatel.be writes: > >> > >> About the yes/not separation of the AMR (say(1)) and AMR WB (say > >> (2)) payload drafts... I'm puzzling about which are the application > >> domains of this new formats. Is it so that (1) was originally > >> planned for use in UMTS, while (2) is proposed as a 'new GSM' codec ? > >> > >> Do the payload formats correspond with those 2 cases ? I guess so. > >> > >> Isn't it possible that both streams of information will one day pass > >> over the same networks and that thus a uniform format might be > >> interesting ? > > > >Yes, but you cannot assume all endpoints support the formats - > >capabilities need to be negotiated (ergo SIP/SAP/SDP). And there are > >no static payloads for new formats so negotiation has to happen. > > > >> Therefore I also support the idea of adapting the classical "RTP > >> payload format for AMR" draft, rather than producing 2 drafts. > > > >The drafts are similar but the authors to decide how these payloads > >are described with least ambiguity. Describing 2 similiar, but > >subtlely different formats might be better in two documents. > > > >Kind Regards > >- Orion. > > > >BTW, I didn't fully understand the earlier comment about sampling > >rates and clocks preventing a single draft. Most of the RTP audio > >formats use the sampling clock for timestamps (eg. l16-8k uses 8kHz, > >l16-44100 uses 44.1kHz). It's easily resolved when using SDP, the > >8kHz and 16kHz get different payload id's. > > > > > >> > Magnus Westerlund wrote: > >> > > > >> > > Qiaobing, > >> > > > >> > > There are several reasons why there should be different payload formats, the two > >> > > largest are: First, AMR and AMR WB are two different codecs, with totally separate > >> > > implementations. As they are separate, the demultiplexing of codec used in a RTP > >> > > stream are best handled by the payload type. Secondly they are using different > >> > > sampling rates and therefore RTP timestamp rates. I belive combining codecs with > >> > > different rates in one payload format would be difficult. > >> > > > >> > > >> > -- > >> > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >> > >> > >> > >> > >> > > From rem-conf Sun Mar 04 21:46:38 2001 From rem-conf-request@es.net Sun Mar 04 21:46:37 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ZnkX-0001Nt-00; Sun, 4 Mar 2001 21:41:37 -0800 Received: from dns.big-vann.co.jp [211.123.76.82] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ZnkS-0001NF-00; Sun, 4 Mar 2001 21:41:33 -0800 Received: from [209.43.14.188] by dns.big-vann.co.jp (Post.Office MTA v3.5.3J release 223-101-J ID# 1001-68000U100L2S100V35J) with SMTP id jp; Mon, 5 Mar 2001 14:31:42 +0900 From: bxx8@aol.com To: mpk9@aol.com Subject: Do You Accept Credit Cards? Date: Mon, 05 Mar 01 00:29:04 Pacific Standard Time X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html;

ACCEPT ALL MAJOR CREDIT CARDS
98% OF OUR APPLICANTS ARE ACCEPTED!!

TERMINALS & PRINTERS OR PROCESS
DIRECTLY THROUGH YOU WEB SITE OR P.C.
0 DOWN W/GOOD CREDIT,
BAD CREDIT HISTORY? NO PROBLEM!
NO APPLICATION OR SETUP FEE WITH THIS AD.
LOWEST RATES, LOW MONTHLY PAYMENTS
SUPER QUICK APPROVAL AND SET UP!!
REAL TIME SECURE PROCESSING FROM YOUR
WEB SITE OR PHYSICAL STORE FRONT
INCREASE SALES BY UP TO 300%!!

CALL NOW!! 800-487-9955




From rem-conf Mon Mar 05 02:03:56 2001 From rem-conf-request@es.net Mon Mar 05 02:03:55 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14Zrmm-0006fe-00; Mon, 5 Mar 2001 02:00:12 -0800 Received: from gorilla.mchh.siemens.de [194.138.158.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 14Zrmk-0006f1-00; Mon, 5 Mar 2001 02:00:11 -0800 Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA18117; Mon, 5 Mar 2001 10:59:54 +0100 (MET) From: Tobias.Faerber@mch.siemens.de Received: from mchh9eea.mchh.siemens.de (mchh9eea.mchh.siemens.de [139.21.204.218]) by blues.mchh.siemens.de (8.9.1/8.9.1) with SMTP id KAA22063; Mon, 5 Mar 2001 10:59:55 +0100 (MET) Received: by mchh9eea.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Mar 2001 10:59:12 +0100 Message-ID: <07B0CDE3B76AD31190F700508B5D5D1D68A7EF@mchg9eba.mchh.siemens.de> To: ian.rytina@ericsson.com.au, rem-conf@es.net Subject: AW: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt Date: Mon, 5 Mar 2001 10:59:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi, I don't think that AMR-WB is well suitable for HI-FI- music, maybe yes = for speech over music, but for coding music the source model for AMR is the wrong one, so using other codecs (e.g. MPEG4-AAC or others) specially designed for coding music should be used in such a case. regards Tobi ------------------------------------------------------------------------= ---- ------- > Faerber Tobias Siemens AG > ICM MP RD MCH 83 Information and Communication Mobile >=20 > Tel: +49 89 722 58578 Grillparzerstrasse 10 a > Fax: +49 89 722 59070 81675 Munich, Germany mailto:tobias.faerber@mch.siemens.de ------------------------------------------------------------------------= ---- ------- > -----Urspr=FCngliche Nachricht----- > Von: Ian Rytina [SMTP:ian.rytina@ericsson.com.au] > Gesendet am: Montag, 5. M=E4rz 2001 02:14 > An: rem-conf@es.net > Betreff: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt >=20 >=20 > I agree with this suggestion. These are different codecs, with = different > applications (e.g. AMR-WB is better for hi-fi quality music, = something > that > AMR struggles on). To answer a previous question, both codecs will be > used by both UMTS and GSM, the AMR-WB spec is going for approval > by 3GPP plenary in the next few weeks. >=20 > Since they are both have an adaptive rate function, there will be = shared > functionality, but there is no reason why the AMR-WB spec cannot = point > back to the AMR spec for those particular functions. >=20 > /Ian. >=20 >=20 > Colin Perkins wrote: >=20 > > It is also worth noting that the AMR payload format has taken = longer > than > > would have been desirable, and that further delay could be = problematic. > > > > My suggestion is that the authors of the AMR-WB payload format = consider > if > > it can be made identical to the standard AMR payload format. In = that > case, > > the draft can be a simple MIME registration plus a pointer to the = other > > document. Otherwise we need to define a new payload format, which = will > need > > a new draft anyway. > > > > This avoid confusion and further delay to the AMR payload. > > > > Colin > > > > --> Orion Hodson writes: > > > > > >Wim.Van_Den_Boeck@alcatel.be writes: > > >> > > >> About the yes/not separation of the AMR (say(1)) and AMR WB (say > > >> (2)) payload drafts... I'm puzzling about which are the = application > > >> domains of this new formats. Is it so that (1) was originally > > >> planned for use in UMTS, while (2) is proposed as a 'new GSM' = codec ? > > >> > > >> Do the payload formats correspond with those 2 cases ? I guess = so. > > >> > > >> Isn't it possible that both streams of information will one day = pass > > >> over the same networks and that thus a uniform format might be > > >> interesting ? > > > > > >Yes, but you cannot assume all endpoints support the formats - > > >capabilities need to be negotiated (ergo SIP/SAP/SDP). And there = are > > >no static payloads for new formats so negotiation has to happen. > > > > > >> Therefore I also support the idea of adapting the classical "RTP > > >> payload format for AMR" draft, rather than producing 2 drafts. > > > > > >The drafts are similar but the authors to decide how these = payloads > > >are described with least ambiguity. Describing 2 similiar, but > > >subtlely different formats might be better in two documents. > > > > > >Kind Regards > > >- Orion. > > > > > >BTW, I didn't fully understand the earlier comment about sampling > > >rates and clocks preventing a single draft. Most of the RTP audio > > >formats use the sampling clock for timestamps (eg. l16-8k uses = 8kHz, > > >l16-44100 uses 44.1kHz). It's easily resolved when using SDP, the > > >8kHz and 16kHz get different payload id's. > > > > > > > > >> > Magnus Westerlund wrote: > > >> > > > > >> > > Qiaobing, > > >> > > > > >> > > There are several reasons why there should be different = payload > formats, the two > > >> > > largest are: First, AMR and AMR WB are two different codecs, = with > totally separate > > >> > > implementations. As they are separate, the demultiplexing of > codec used in a RTP > > >> > > stream are best handled by the payload type. Secondly they = are > using different > > >> > > sampling rates and therefore RTP timestamp rates. I belive > combining codecs with > > >> > > different rates in one payload format would be difficult. > > >> > > > > >> > > > >> > -- > > >> > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > >> > > >> > > >> > > >> > > >> > > > >=20 From rem-conf Mon Mar 05 08:03:54 2001 From rem-conf-request@es.net Mon Mar 05 08:03:54 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ZxM2-0005tl-00; Mon, 5 Mar 2001 07:56:58 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ZxLz-0005tb-00; Mon, 5 Mar 2001 07:56:56 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id KAA02177 for ; Mon, 5 Mar 2001 10:56:52 -0500 Message-Id: <200103051556.KAA02177@purple.east.isi.edu> To: rem-conf@es.net Subject: AVT meeting in Minneapolis Date: Mon, 05 Mar 2001 10:56:52 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The AVT working group is scheduled for two slots at the 50th IETF meeting. On the tentative agenda these are 3:30pm - 5:30pm on Wednesday 21st March and 1pm to 3pm on Thursday 22nd March. Those seeking agenda time should contact the working group chairs before 9th March. We currently have the following requests for agenda time: RTP payload format for MPEG-4 FlexMux streams (Catherine Roux) draft-curet-avt-rtp-mpeg4-flexmux-00.txt RTP payload format for AMR-WB (Ari Lakaniemi) draft-lakaniemi-avt-amrwb-00.txt Payload Formats for Retransmissions in RTP (Carsten Burmeister) draft-ietf-avt-rtp-selret-01.txt RTP payload format for Vorbis (Jack Moffitt) draft-moffitt-vorbis-rtp-00.txt DV audio (Casner/Kobayashi) draft-ietf-avt-dv-audio-02.txt MPEG-4 generic payload format (Philippe Gentric) draft-gentric-avt-mpeg4-multipleSL-02.txt Low delay feedback (Carsten Burmeister) draft-fukunaga-low-delay-rtcp-02.txt Colin From rem-conf Mon Mar 05 08:08:43 2001 From rem-conf-request@es.net Mon Mar 05 08:08:42 2001 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14ZxVb-0000XM-00; Mon, 5 Mar 2001 08:06:51 -0800 Received: from [207.33.37.137] (helo=boats_exch01.boats.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 14ZxVZ-0000X6-00; Mon, 5 Mar 2001 08:06:49 -0800 Received: by BOATS_EXCH01 with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Mar 2001 07:57:15 -0800 Message-ID: From: Stuart Johnstone To: "'rem-conf@es.net'" Subject: remove Date: Mon, 5 Mar 2001 07:57:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Mon Mar 05 12:01:12 2001 From rem-conf-request@es.net Mon Mar 05 12:01:11 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14a134-0003Mv-00; Mon, 5 Mar 2001 11:53:38 -0800 Received: from flmailgw1.interliant.com (mailgw.freelance.com) [198.3.182.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 14a132-0003Ld-00; Mon, 5 Mar 2001 11:53:37 -0800 Received: from batch1.freelance.com ([198.3.182.105]) by mailgw.freelance.com (Lotus Domino Release 5.0.6a) with ESMTP id 2001030513295654:9709 ; Mon, 5 Mar 2001 13:29:56 -0600 To: rem-conf@es.net From: infoProjects.IT.Espana@freelance.com Subject: =?iso-8859-1?Q?=A1Ya_es_hora_de_trabajar_de_otra_forma=21?= Message-ID: Date: Mon, 5 Mar 2001 13:29:02 -0600 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Batch1/Freelance(Release 5.0.6a |January 17, 2001) at 05/03/2001 01:29:02 PM, Itemize by SMTP Server on MailGW/Freelance(Release 5.0.6a |January 17, 2001) at 05/03/2001 13:29:56, Serialize by Router on MailGW/Freelance(Release 5.0.6a |January 17, 2001) at 05/03/2001 13:55:42, Serialize complete at 05/03/2001 13:55:42 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=iso-8859-1 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Buenos d=EDas, Este es un mensaje que se env=EDa de forma autom=E1tica. Si no est=E1s = interesado y no recibimos noticias tuyas, no contactaremos otra vez contigo. =A1Ya es hora de trabajar de otra forma! Hay trabajadores felices y hay trabajadores frustrados. Freelance.com, l=EDder mundial en la prestaci=F3n de servicios a freelances, permite q= ue consigas tu independencia. Con Freelance.com dispondr=E1s mejor de tu tiempo y tus perspectivas profesionales se multiplicar=E1n gracias al respaldo de nuestra red. Co= ntar=E1s con el apoyo personalizado de expertos que identificar=E1n los mejores proyectos para impulsar tu desarrollo profesional. Nuestra posici=F3n d= e l=EDder te garantiza la calidad y la posibilidad de elegir tus proyecto= s en todo el mundo y te ahorrar=E1 el esfuerzo que supone la b=FAsqueda de c= lientes. No busques m=E1s, nosotros lo hacemos por ti. Si eres experto en Nuevas= Tecnolog=EDas, reg=EDstrate en Freelance.com. Te invitamos a visitar nuestra p=E1gina web www.freelance.com para cono= cer Freelance.com, qui=E9nes somos y c=F3mo trabajamos: - inscr=EDbete en nuestra mailing-list de proyectos freelance para reci= bir las nuevas ofertas todos los d=EDas. Puedes recibir una lista completa = con todos los nuevos proyectos o introducir tus campos de preferencia y confeccionar tu propia lista personalizada. - env=EDanos tu CV para entrar a formar parte de nuestra base de datos = de expertos (la confidencialidad es total y no implica compromiso de ning=FA= n tipo); nos pondremos en contacto contigo cuando recibimos un proyecto q= ue se adapte a tu perfil. Estos servicios son totalmente gratuitos Un saludo, El equipo de Freelance.com www.freelance.com contacto@freelance.com Madrid Paseo de la Castellana, 147 Edificio Cuzco IV, planta 18 28046 Madrid Tel.: +34 91 749 80 77 Fax: +34 91 570 71 99 Barcelona Gran V=EDa de Carlos III, 84 Torres Trade 08028 Barcelona Tel.: +34 93 496 57 19 Fax: +34 93 496 57 01= From rem-conf Mon Mar 05 13:30:25 2001 From rem-conf-request@es.net Mon Mar 05 13:30:24 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14a2Rv-0005ge-00; Mon, 5 Mar 2001 13:23:23 -0800 Received: from cmailg7.svr.pol.co.uk [195.92.195.177] by mail1.es.net with esmtp (Exim 1.81 #2) id 14a2Rt-0005gU-00; Mon, 5 Mar 2001 13:23:21 -0800 Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14a2Jr-0004uM-00; Mon, 05 Mar 2001 21:15:03 +0000 Received: from modem-189.utah.dialup.pol.co.uk ([62.137.95.189] helo=mail.earthlink.net) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14ZyVf-0004u0-00; Mon, 05 Mar 2001 17:11:00 +0000 Received: from mailhost.earthlink.net(alt1.earthlink.net(208.9.77.65)) by earthlink.net (8.8.5/8.6.5) with SMTP id GAA02929 for ; Mon, 05 Mar 2001 16:29:11 -0600 (EST) Date: Mon, 05 Mar 01 16:29:11 EST From: robert@rsg1.fsnet.co.uk To: test@earthlink.net Subject: Important news vital for this weekend! Message-ID: <199702170025.GAA08056@earthlink.net> Reply-To: test@earthlink.net X-UIDL: 73635342536475896784635209876543 Comments: Authenticated sender is X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list How will you be spending this weekend? Those 'in the know' will be doing this - Just send a blank e-mail to the following address and you will receive information on what you SHOULD be doing this weekend: must-read-info@aweber.com or here mailto:must-read-info@aweber.com?subject=NOW_CLICK_SEND! ************************ For any queries regarding this service or your subscription to this service, send an e-mail to robert@rsg1.fsnet.co.uk ************************ From rem-conf Mon Mar 05 16:48:52 2001 From rem-conf-request@es.net Mon Mar 05 16:48:51 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14a5ZA-0001o5-00; Mon, 5 Mar 2001 16:43:04 -0800 Received: from mail.kornet.net [168.126.72.70] by mail1.es.net with esmtp (Exim 1.81 #2) id 14a5Z8-0001nv-00; Mon, 5 Mar 2001 16:43:02 -0800 Received: from www.e-modelhouse.com ([211.196.189.2]) by mail.kornet.net (8.11.1/8.11.1) with SMTP id f260gX016165 for ; Tue, 6 Mar 2001 09:42:35 +0900 (KST) Received: from pwief.gotofreehost.com (unverified [209.69.222.185]) by www.e-modelhouse.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 06 Mar 2001 09:47:18 +0900 To: rem-conf@es.net Reply-To: jigtomfrog3@ematic.com Subject: Super Fast Online Browsing!! Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: From: benzing@gotofreehost.com Received: from pwief.gotofreehost.com [192.168.222.16] by 0tlf.pwief.gotofreehost.com with SMTP; Mon, 05 Mar 2001 19:46:21 -0500 Date: Mon, 05 Mar 2001 19:46:21 -0500 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

"WE HAVE DEVELOPED THE TECHNOLOGY TO OFFER YOU THE MOST
COMPETITIVE AND HIGH SPEED DSL SERVICE IN THE COUNTRY!!!"

Hello, We are writing to inform you of an invaluable web based technology to determine the best and most competitive DSL Internet service in the country. We developed this technology to serve the growing needs for high-speed Internet services. 
We have decided to offer FREE public access to this service to help you SAVE MONEY on the future of high speed DSL Internet. This in turn helps keep our DSL Internet technology in high demand.
IT IS A WIN-WIN for you and for us!

We will Comparison-shop most of the high speed DSL Internet Providers for the best service and rates in the country IN SECONDS! NO ONE ELSE CAN OFFER YOU SUCH POWER.

>>>>>> FIND OUT NOW IF DSL IS AVAILABLE AT YOUR HOME OR BUSINESS. <<< <<<
HERE IS THE WHAT WE WILL OFFER YOU:

- Instant DSL locator, verification and sign-up!
- The most competitive rates!
- Sign-up instantly on-line now!
- Speed up your connection up to 50 times faster!
- 24/7 technical support and service!
- Always On - Always stay connected!
- Free Installation!
Click Below To Order YOUR DSL
Order DSL OnLine CLICK HERE!

ADDITIONAL BENEFITS:

- Downloads and File Transfers in a fraction of the time.
- Access your email anywhere in the World via our exclusive WEB-MAIL.
- Coming soon… State-Of-The-Art Java online applications.
- Access services; In the future take advantage of group purchasing power.

PLEASE FILL OUT THE FORM at our Web page:

and receive INSTANT VERIFICATION of availability as well as above benefits. Help a family member or a friend with their DSL service by FORWARDING THIS
EMAIL TO THEM!

Best Regards,

HEREisDSL

To be removed please reply with REMOVE in the subject line.

From rem-conf Mon Mar 05 22:36:37 2001 From rem-conf-request@es.net Mon Mar 05 22:36:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aAws-0000NG-00; Mon, 5 Mar 2001 22:27:54 -0800 Received: from (ms.samsung.com) [211.45.29.136] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aAwr-0000Lj-00; Mon, 5 Mar 2001 22:27:53 -0800 Received: from bright ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G9RJ4Y00.S4R for ; Tue, 6 Mar 2001 15:24:34 +0900 From: chjkim@samsung.com To: "Rtp" Subject: lastest doc. Date: Tue, 6 Mar 2001 15:28:41 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C0A652.1F7E8BD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C0A652.1F7E8BD0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3YW50IHRoZSBsYXN0ZXN0IGRvY3VtZW50cyBzdWNoIGFzIHByb2ZpbGUgc3BlY2lmaWNhdGlv biBhbmQgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbiBvZiBSVFAvUlRDUC4NClBsZWFzZSBs ZXQgbWUgd2hlcmUgYW5kIGhvdyBJIGNhbiBnZXQgdGhlbS4NCg0KVGhhbmtzIGluIGFkdmFuY2Uu DQoNClNpbmNlcmVseSwNCg0KQ2hlb2wgSnUNCg0KDQo= ------=_NextPart_000_0033_01C0A652.1F7E8BD0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+ PFNQQU4gY2xhc3M9OTUzMjMyMzA2LTA2MDMyMDAxPjxGT05UIHNpemU9Mj5JIHdhbnQgdGhlIGxh c3Rlc3QgZG9jdW1lbnRzIA0Kc3VjaCBhcyBwcm9maWxlIHNwZWNpZmljYXRpb24gYW5kIHBheWxv YWQgZm9ybWF0IHNwZWNpZmljYXRpb24gb2YgDQpSVFAvUlRDUC48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz05NTMyMzIzMDYtMDYwMzIwMDE+PEZPTlQgc2l6ZT0yPlBsZWFz ZSANCmxldCZuYnNwO21lPC9GT05UPiZuYnNwOzxGT05UIHNpemU9Mj53aGVyZSBhbmQgaG93IEkg Y2FuIGdldCANCnRoZW0uPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTUz MjMyMzA2LTA2MDMyMDAxPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K PERJVj48U1BBTiBjbGFzcz05NTMyMzIzMDYtMDYwMzIwMDE+PEZPTlQgc2l6ZT0yPlRoYW5rcyBp biANCmFkdmFuY2UuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTUzMjMy MzA2LTA2MDMyMDAxPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz05NTMyMzIzMDYtMDYwMzIwMDE+PEZPTlQgc2l6ZT0yPlNpbmNlcmVseSw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05NTMyMzIzMDYtMDYwMzIwMDE+ PEZPTlQgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNz PTk1MzIzMjMwNi0wNjAzMjAwMT48Rk9OVCBzaXplPTI+Q2hlb2wgSnU8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiBjbGFzcz05NTMyMzIzMDYtMDYwMzIwMDE+PEZPTlQgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk1MzIzMjMwNi0wNjAz MjAwMT48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_0033_01C0A652.1F7E8BD0-- From rem-conf Tue Mar 06 03:39:03 2001 From rem-conf-request@es.net Tue Mar 06 03:39:03 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aFiJ-00061g-00; Tue, 6 Mar 2001 03:33:11 -0800 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aFiH-00061T-00; Tue, 6 Mar 2001 03:33:09 -0800 Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f26BX5C05209 for ; Tue, 6 Mar 2001 12:33:05 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 06 12:33:03 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Mar 2001 12:29:12 +0100 Message-ID: From: "Elisabetta Carrara (ERA)" To: "'rem-conf@es.net'" Cc: "David A. McGrew (E-mail)" , "David Oran (E-mail)" , =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29_=5Bmats=2En?= =?iso-8859-1?Q?aslund=40era-t=2Eericsson=2Ese=5D_=28E-mail=29?= Subject: Security: RTCP prefix and CNAME Date: Tue, 6 Mar 2001 12:05:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, we are working on security issues related to RTP, and we have submitted a draft (draft-ietf-avt-srtp-00.txt). We would like to point out some parts in draft-ietf-avt-rtp-new-08.txt that should be discussed. In section 9.1., there is written: "For RTCP, a 32-bit random number MUST be prepended to the unit before encryption to deter known plaintext attacks." We think it should not be mandatory, but we suggest that it is replace with a MAY. The reason is that for stream ciphers, the prefix gives no gain in security. Section 6.1. is affected similarly. Still section 9.1. allows for the splitting of a RTCP compound packet "into two lower-layer packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors that are not privy to the encryption key". However, section 6.1. mandates the following: "An SDES packet containing a CNAME item must be included in each compound RTCP packet". Our interpretation of this is that the two splitted packets both need to carry a SDES CNAME item. This would be in contradiction with section 9.1 and also the example in figure 4. For privacy reasons, the unencrypted part should not contain a CNAME. If our interpretation is correct, we suggest to resolve in the following way: When an encrypted compound packet with a correct SDES CNAME item is sent, the unencrypted compound packet MAY contain a zero length SDES CNAME string. This would make the unencrypted RTCP packet a valid packet according to the rules in section 6.1 and the CNAME may remain private information. Thanks, regards. From rem-conf Tue Mar 06 03:42:00 2001 From rem-conf-request@es.net Tue Mar 06 03:42:00 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aFof-000686-00; Tue, 6 Mar 2001 03:39:45 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aFoe-00067m-00; Tue, 6 Mar 2001 03:39:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07071; Tue, 6 Mar 2001 06:39:41 -0500 (EST) Message-Id: <200103061139.GAA07071@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-smpte292-video-02.txt Date: Tue, 06 Mar 2001 06:39:41 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for SMPTE 292M Author(s) : L. Gharai, G. Goncher, C. Perkins, D. Richardson, A. Mankin Filename : draft-ietf-avt-smpte292-video-02.txt Pages : 10 Date : 05-Mar-01 This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 292M into a payload format for the Real-Time Transport Protocol (RTP). The RTP packet counter is extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte292-video-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-smpte292-video-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-smpte292-video-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305124039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-smpte292-video-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-smpte292-video-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305124039.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Mar 06 03:42:00 2001 From rem-conf-request@es.net Tue Mar 06 03:42:00 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aFok-00068i-00; Tue, 6 Mar 2001 03:39:50 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aFoi-00068S-00; Tue, 6 Mar 2001 03:39:49 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07083; Tue, 6 Mar 2001 06:39:47 -0500 (EST) Message-Id: <200103061139.GAA07083@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-selret-01.txt Date: Tue, 06 Mar 2001 06:39:47 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Retransmission Payload Format Author(s) : A. Miyazaki et al. Filename : draft-ietf-avt-rtp-selret-01.txt Pages : 13 Date : 05-Mar-01 This document describes new RTP payload formats to enable multiple and optional selective retransmissions in RTP. They are especially applicable to environments where low delay feedback is available, such as described in [LDF,LDF2]. These payload formats can be used to separate the media stream according to prioritization of packets or according to the status of the transmission (i.e. transmission or retransmission). This serves as a retransmission framework, where we give examples how this can be used for different retransmission schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-selret-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-selret-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-selret-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010305124353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-selret-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-selret-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305124353.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Mar 06 06:41:49 2001 From rem-conf-request@es.net Tue Mar 06 06:41:48 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aIYp-0003zi-00; Tue, 6 Mar 2001 06:35:35 -0800 Received: from ece.wpi.edu [130.215.16.20] (abhijit) by mail1.es.net with esmtp (Exim 1.81 #2) id 14aIYo-0003zY-00; Tue, 6 Mar 2001 06:35:34 -0800 Received: from localhost (abhijit@localhost) by ece.wpi.edu (8.11.2/8.11.2) with ESMTP id f26EZWC25259 for ; Tue, 6 Mar 2001 09:35:32 -0500 (EST) Date: Tue, 6 Mar 2001 09:35:32 -0500 (EST) From: Abhijit Pandey cc: Subject: Software required In-Reply-To: <200103061139.GAA07083@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are there any tools or software that generates RTP packets and also in response RTCP packets that could be downloaded or purchased. Thanks, Abhijit Abhijit Pandey Cell 508-579-5905 Masters Computers and Communication Networks Program Get me at http://www.abhijitpandey.com From rem-conf Tue Mar 06 09:30:16 2001 From rem-conf-request@es.net Tue Mar 06 09:30:16 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aL9N-0000Du-00; Tue, 6 Mar 2001 09:21:29 -0800 Received: from ns.live.com [208.184.148.162] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aL9M-0000DS-00; Tue, 6 Mar 2001 09:21:28 -0800 Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id JAA85705; Tue, 6 Mar 2001 09:21:26 -0800 (PST) (envelope-from rsf) Message-Id: <4.3.1.1.20010306091736.00c318f0@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 06 Mar 2001 09:21:22 -0800 To: Abhijit Pandey From: Ross Finlayson Subject: Re: Software required Cc: rem-conf@es.net In-Reply-To: References: <200103061139.GAA07083@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 06:35 AM 3/6/01, Abhijit Pandey wrote: >Are there any tools or software that generates >RTP packets and also in response RTCP packets that could be downloaded or >purchased. There are many pieces of software out there. If you want software with source code, then you could take a look at . (In particular, note the simple "testServer" and "testClient" programs.) Ross. From rem-conf Tue Mar 06 11:02:56 2001 From rem-conf-request@es.net Tue Mar 06 11:02:56 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aMgW-0001nm-00; Tue, 6 Mar 2001 10:59:48 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aMgU-0001nc-00; Tue, 6 Mar 2001 10:59:46 -0800 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id E20151E182 for ; Tue, 6 Mar 2001 13:59:27 -0500 (EST) Received: from research.att.com (sugih.attlabs.att.com [135.197.2.51]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA24897 for ; Tue, 6 Mar 2001 13:59:26 -0500 (EST) Sender: julian@research.att.com Message-ID: <3AA53368.76E7CE57@research.att.com> Date: Tue, 06 Mar 2001 10:58:48 -0800 From: Julian Chesterfield Organization: AT&T Labs X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: New Draft - RTCP for SSM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please find a new draft available online at:- http://search.ietf.org/internet-drafts/draft-chesterfield-avt-rtcpssm-00.txt This is a proposal for the adaption of RTCP to operate in a Source Specific Multicast Session where there is no 'many to many' communication for which the protocol was originally designed. This is my first shot at writing drafts, so I suspect there are a number innaccuracies! However, the main points which are being proposed are:- - Receivers unicast reports to the source/sender in the session. - The source is responsible for distributing the reports on the SSM RTCP channel to ensure the scaling algorithm still works. - The source has 2 options for distributing the data. The first is a Sender Report in which the Report Blocks correspond to the individual reports from the receivers. Since the source is the only member generating SRs, I think this should be fairly clear to the receivers. The second is a proposed new packet format named Sender Summary Report (SSR) in which the redundant Timestamp information is removed to enable less packet size overhead. I would appreciate comments and feedback on the draft. My personal reason for pushing ahead with this is that I am working on Multicast Network Monitoring tools, and RTCP data is a key part in providing information. I want to be able to retrieve that information in Source Specific Multicast sessions as well. Many Thanks, Julian Chesterfield AT&T Labs Research, Menlo Park, CA From rem-conf Tue Mar 06 11:08:01 2001 From rem-conf-request@es.net Tue Mar 06 11:08:01 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aMnf-0002HM-00; Tue, 6 Mar 2001 11:07:11 -0800 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aMnd-0002GJ-00; Tue, 6 Mar 2001 11:07:09 -0800 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA21935; Tue, 6 Mar 2001 14:10:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Mar 2001 14:09:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Abhijit Pandey'" Cc: rem-conf@es.net Subject: RE: Software required Date: Tue, 6 Mar 2001 14:09:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: Abhijit Pandey [mailto:abhijit@ece.wpi.edu] > Sent: Tuesday, March 06, 2001 9:36 AM > To: rem-conf@es.net > Cc: rem-conf@es.net > Subject: Software required > > > > Are there any tools or software that generates > RTP packets and also in response RTCP packets that could be > downloaded or > purchased. > Thanks, > Abhijit > The RTPLib library is available, in source form, from: http://www1.bell-labs.com/topic/swdist/ it comes with some example programs that send RTP and RTCP packets. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From rem-conf Tue Mar 06 11:29:17 2001 From rem-conf-request@es.net Tue Mar 06 11:29:17 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aN4F-0003MB-00; Tue, 6 Mar 2001 11:24:19 -0800 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aN4E-0003M1-00; Tue, 6 Mar 2001 11:24:18 -0800 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA28942; Tue, 6 Mar 2001 14:24:11 -0500 (EST) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f26JOFK03938; Tue, 6 Mar 2001 14:24:16 -0500 Message-Id: <200103061924.f26JOFK03938@chiron.east.isi.edu> To: Jonathan Rosenberg cc: "'Abhijit Pandey'" , rem-conf@es.net Subject: Re: Software required In-Reply-To: Your message of "Tue, 06 Mar 2001 14:09:16 EST." Date: Tue, 06 Mar 2001 14:24:15 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: >> -----Original Message----- >> From: Abhijit Pandey [mailto:abhijit@ece.wpi.edu] >> Sent: Tuesday, March 06, 2001 9:36 AM >> To: rem-conf@es.net >> Cc: rem-conf@es.net >> Subject: Software required >> >> Are there any tools or software that generates >> RTP packets and also in response RTCP packets that could be >> downloaded or >> purchased. >> Thanks, >> Abhijit > >The RTPLib library is available, in source form, from: >http://www1.bell-labs.com/topic/swdist/ >it comes with some example programs that send RTP and RTCP packets. There is also an RTP library available from UCL, as part of the mbone conferencing archive. Go to http://www-mice.cs.ucl.ac.uk/multimedia/software/ and get the source for the common multimedia library. Colin From rem-conf Tue Mar 06 12:12:50 2001 From rem-conf-request@es.net Tue Mar 06 12:12:50 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aNmv-0004fr-00; Tue, 6 Mar 2001 12:10:29 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14aNmu-0004fh-00; Tue, 6 Mar 2001 12:10:28 -0800 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA25223; Tue, 6 Mar 2001 12:02:57 -0800 Message-ID: <3AA54376.79AE2A63@bmrc.berkeley.edu> Date: Tue, 06 Mar 2001 12:07:18 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 3/7 Berkeley Multimedia, Interfaces and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Dynamic Integration of Large Live Classroom Lectures, Streaming Media, and Text-based Student Feedback March 07, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Americ Azevedo Interdisciplinary Studies U.C. Berkeley I started with a large 500 student lecture hall class (IDS110) at UC Berkeley. Classroom alienation and inadequate opportunities for student participation and feedback are major issues with such a class. I looked at current e-learning platforms on the market, but these products did not support discussions and feedback from students in an eloquent and easy way. They were content-centric, not discussion-feedback centric in their instructional metaphors. So we proceed to creation a new discussion-centric online format. Over a period of four weeks we built a discussion-centric e-learning platform and supporting "cultureware" for supporting rapid feedback and dialogue. One thing that was unique about this experiment is that students were in engaged in the process of creating the pattern language for the feedback system. As the system became more widely used by the students, we incorporated video playbacks (from BIBS). Some students discovered that they could try to communicate with the instructor while the lecture is live. That was an unexpected surprise. Assignment submission, creative problem writing, knowledge sharing, development of a learning community, and special student interest topics have been among the benefits noticed in this approach. Other impacts are the eventual change of the lab session structure and possible "publication" of the course to wider audiences. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Mar 06 13:07:54 2001 From rem-conf-request@es.net Tue Mar 06 13:07:54 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aOfL-0005yU-00; Tue, 6 Mar 2001 13:06:43 -0800 Received: from mx.serv.net [205.153.153.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aOfK-0005yE-00; Tue, 6 Mar 2001 13:06:42 -0800 Received: from iname.com (dialup344.serv.net [207.207.70.237]) by mx.serv.net (8.9.1/8.9.1) with ESMTP id NAA21853 for ; Tue, 6 Mar 2001 13:06:32 -0800 (PST) Message-ID: <3AA5510E.6189318A@iname.com> Date: Tue, 06 Mar 2001 13:05:18 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Timing Information Stream (TIS) payload - abstract Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ladies & Gents: In association with a previous internet-draft http://www.ietf.org/internet-drafts/draft-harrison-avt-precision-av-00.txt I am preparing a new draft for multi-stream timing information. This is a work in progress and has not yet been submitted to the IETF. I give the abstract below and I will place the current draft in a subsequent message. Your comments are solicited. Cheers, Chuck Harrison Far Field Associates, LLC member, SMPTE DC28.1 Steering Committee on Digital Cinema +1 360 863 8340 (voice) GMT-0800 -----begin included text------ Abstract This memo describes an RTP payload format (TIS) which transports timing information about media streams. The media streams themselves are transported independently, and may or may not be carried by RTP. The payload carried over TIS contains the information necessary for synchronizing different media streams to arbitrarily high precision. This supports time-coordinated program playout from different servers (e.g. commercial insertion, multilingual services) and is suitable for professional audiovisual capture, editing, and exhibition. ------end included text-------- From rem-conf Tue Mar 06 13:07:54 2001 From rem-conf-request@es.net Tue Mar 06 13:07:54 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aOeb-0005wo-00; Tue, 6 Mar 2001 13:05:57 -0800 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aOeV-0005we-00; Tue, 6 Mar 2001 13:05:56 -0800 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA07613 for ; Tue, 6 Mar 2001 13:05:26 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Mar 2001 13:05:25 -0800 Received: from [17.202.37.152] (il0203a-dhcp24.apple.com [17.202.37.152]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id NAA05856; Tue, 6 Mar 2001 13:05:13 -0800 (PST) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: References: Date: Tue, 6 Mar 2001 13:01:31 -0800 To: Abhijit Pandey , rem-conf@es.net From: Kevin Marks Subject: Re: Software required Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 9:35 am -0500 6/3/01, Abhijit Pandey wrote: >Are there any tools or software that generates >RTP packets and also in response RTCP packets that could be downloaded or >purchased. QuickTime player will receive RTP packets and generate RTCPs: http://quicktime.tv QuickTime Streaming Server will generate RTP streams and send RTCPs http://www.apple.com/quicktime/products/qtss/ Both are freely downloadable and the source for QTSS is open. From rem-conf Tue Mar 06 13:08:15 2001 From rem-conf-request@es.net Tue Mar 06 13:08:15 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14aOgU-0005zM-00; Tue, 6 Mar 2001 13:07:54 -0800 Received: from mx.serv.net [205.153.153.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 14aOgT-0005yi-00; Tue, 6 Mar 2001 13:07:53 -0800 Received: from iname.com (dialup344.serv.net [207.207.70.237]) by mx.serv.net (8.9.1/8.9.1) with ESMTP id NAA22009 for ; Tue, 6 Mar 2001 13:07:42 -0800 (PST) Message-ID: <3AA55155.6634D62B@iname.com> Date: Tue, 06 Mar 2001 13:06:29 -0800 From: Chuck Harrison X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Timing Information Stream (TIS) payload - text Content-Type: multipart/mixed; boundary="------------BA885D37DF17EED901A74209" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------BA885D37DF17EED901A74209 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ladies & Gents: In association with a previous internet-draft http://www.ietf.org/internet-drafts/draft-harrison-avt-precision-av-00.txt I am preparing a new draft for multi-stream timing information. This is a work in progress and has not yet been submitted to the IETF. Your comments are solicited. Cheers, Chuck Harrison Far Field Associates, LLC member, SMPTE DC28.1 Steering Committee on Digital Cinema +1 360 863 8340 (voice) GMT-0800 --------------BA885D37DF17EED901A74209 Content-Type: text/plain; charset=us-ascii; name="draft-harrison-avt-tis-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-harrison-avt-tis-00.txt" Network Working Group C. Harrison Internet-Draft Far Field Associates, LLC Expires: September 4, 2001 March 6, 2001 RTP Payload Format for Timing Information Stream (TIS) draft-harrison-avt-tis-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes an RTP payload format (TIS) which transports timing information about media streams. The media streams themselves are transported independently, and may or may not be carried by RTP. The payload carried over TIS contains the information necessary for synchronizing different media streams to arbitrarily high precision. This supports time-coordinated program playout from different servers (e.g. commercial insertion, multilingual services) and is suitable for professional audiovisual capture, editing, and exhibition. Harrison Expires September 4, 2001 [Page 1] Internet-Draft TIS Payload Format March 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios of Use . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Scheduled Playout Scenario . . . . . . . . . . . . . . . . . . 5 2.2 Simultaneous Synchronous Playout of Tracks Scenario . . . . . 6 2.3 Professional Editing Scenario . . . . . . . . . . . . . . . . 7 2.4 Concurrent Timebases . . . . . . . . . . . . . . . . . . . . . 7 3. Timing Information Stream . . . . . . . . . . . . . . . . . . 10 3.1 Packet Structure . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Sync Messages . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Ratio Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 4. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Model for Resolving Timebases . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 Harrison Expires September 4, 2001 [Page 2] Internet-Draft TIS Payload Format March 2001 1. Introduction In the course of audiovisual production, it is necessary to combine elements that were recorded at various times on various media into a well-coordinated program. When two or more signal sources ("tracks") must be combined (e.g. audio mixing, video cross-fades, soundtrack- to-picture "lip sync"), the system must ensure that time synchronization is maintained among all the tracks. The degree of required precision varies from tens of milliseconds (general purpose lip-sync) to tens of microseconds (musical audio) to a few nanoseconds (broadcast video). Professional audiovisual procedures use a variety of methods for keeping track of time, including SMPTE time code, footage/frame counts, and others. When timed events (such as edit points) must be recorded the resulting time codes may be called Temporally Related Identifiers (TRIs) [3]. During postproduction, a number of different timecode systems apply concurrently to the program, and the offsets between them must be precisely managed. In traditional audiovisual production, the end product is a single program with a single video track and with the audio "mixed down" to a small number of channels (2-5). The distribution medium (movie film, videotape, DVD, etc) incorporates a device-dependent method of maintaining synchronization among the video and audio tracks. In most applications, simply pressing "play" at the right time is all the external synchronization that is required. However, this traditional model is being overtaken by the sophistication of modern digital media delivery. Even within today's prerecorded DVDs, there are alternative timelines and "viewing angle" controls. In new online entertainment applications we may expect coordinated audio and video streams to originate from different "edge servers" and to be combined at the viewing location. Similar coordination may be required in professional applications such as Digital Cinema where alternative language tracks, sign language inserts, and closed-caption data may be delivered separately to the exhibitor. In order to reconstruct the program precisely the way its creators intended, accurate timing information must be provided to the presentation equipment, whether it is a home PC or a commercial cinema. This timing information is similar to that utilized during program editing and discussed above. The RTP [1] protocol was developed for multimedia teleconference applications and provides a flexible framework for transporting multimedia content over the Internet. In the existing RTP model, each source contains an internal free-running timebase, from which its video or audio sampling is derived. In the case of an audio Harrison Expires September 4, 2001 [Page 3] Internet-Draft TIS Payload Format March 2001 channel and video channel which must maintain lip sync, the receiver must correlate the independent media timestamps on the audio and video streams. This may be achieved by referring to the "wallclock" timestamps which are periodically provided by each source in its SR (Sender Report) messages. RTP has provided acceptable service for its original "live teleconference" application. However, it has not demonstrated a capability to obtain the sample-accurate synchronization that is routine in professional postproduction equipment. As noted in an earlier internet-draft [2], achieving fully professional temporal control within the RTP framework requires two new features: o multiple, concurrent timebases referring to a single stream o the ability for source timebases to speed up or slow down in response to external commands The TIS payload format answers the first requirement. Harrison Expires September 4, 2001 [Page 4] Internet-Draft TIS Payload Format March 2001 2. Scenarios of Use Use of TIS payload streams allows information about time-of-play and synchronization to be separated from the media itself. This supports a range of applications from simple scheduled playout to complex edit sessions. It facilitates the construction of large, flexible systems by modularization: individual media sources need not be cognizant of their relationship to other media sources individually; they need only be aware of their relationship to a timeline transmitted over a TIS stream. 2.1 Scheduled Playout Scenario In this example we consider a single multiplexed audiovisual stream (e.g. an MPEG-4 stream) being played to a single destination. This might be a video-on-demand system. The receiving device has a presentation timebase, which we shall assume represents local wallclock time. The program is scheduled to begin at precisely 7:00pm local time and to run for 30 minutes. In a conventional RTP implementation, the only information carried by the media session is the media timestamp (in the RTP packets) and the sender's wallclock time (in the RTCP SR messages). The sender's wallclock time is used by the receiver to construct a local presentation timebase, but the methods for doing this are undefined and variable. In many applications, this is acceptable. TIS addresses those situations in which variability is unacceptable and precise control of the playout time is desired. This may relate to coordination with other events (e.g. commercial inserts). We recognize the existence of a presentation timebase and provide correlation information (sample number X corresponds to presentation time Y) in the TIS stream. The TIS definition is extensible and supports a broad range of timebase formats: SMPTE code (drop and non- drop), NTP, UTC, feet-and-frames, etc. TIS also permits presentation time to be specified indirectly. A server may commonly provide a media stream which is timestamped with a "show clock", for example SMPTE time code starting at 00:00:00:00 (hh:mm:ss:ff). A separate TIS stream, which may originate on the same server or elsewhere, states that 00:00:00:00 on the "show clock" corresponds to 19:00:00:00 (7:00pm) on the presentation clock. Software combines the information in the two TIS streams, in a process we call "resolving", to establish the sampleclock-to- presentation relationship required by the receiving device. At 19:29:59:29, the last frame of the half-hour show is played out. If another show, from another server, is scheduled to begin at Harrison Expires September 4, 2001 [Page 5] Internet-Draft TIS Payload Format March 2001 7:30pm, its first frame can appear at 19:30:00:00 using TIS coordination. This precision of coordination has not generally been possible in previous RTP implementations. It should be noted that this 30-minute show contains precisely 53946 frames (running at NTSC standard speed of 29.97 frames per second). In order that every frame is presented to the viewer, the sender's and receiver's timebases must advance at the same rate. There are basically three methods to achieve this: receiver slaved to sender ("push"), sender slaved to receiver ("pull"), and both slaved to an independent reference ("master sync"). The choice of method involves considerations outside of the scope of the TIS payload format, but will be discussed in another internet-draft [5]. 2.2 Simultaneous Synchronous Playout of Tracks Scenario An audiovisual program is logically constructed of several parallel "tracks", for example: video, left audio, and right audio. In motion pictures, as in other programs which are prepared for widespread commercial release, the number of parallel tracks can be large. These may include soundtrack versions with 2, 3, 5, 8, or more channels, prepared in a variety of languages. Sometimes soundtracks may be separated into music-and-effects (M&E) and dialog mixes. Subtitles may exist as encoded text or video overlays. Closed- captioning for the hearing impaired and descriptive narration tracks may exist in several languages. A sign-language video track may be present. In traditional media, a subset of these tracks is "mastered" into a particular localized release for a particular market. We anticipate that such programs will be made available over the internet via Content Distribution Networks. However, technical and business considerations make it unlikely that all possible localized versions will be hosted as individual multiplexed programs at all edge servers. In this situation, it is appropriate to host individual tracks or groups of tracks independently, and to assemble the correct program "on the fly". In most cases, the separate tracks will be hosted at a single edge-server facility. In the more general case, we might find that a server at a separate facility provides a specialized value-added service (e.g. descriptive narration in Urdu). In order for multi-stream coordinated playout to satisfy the requirements of prime content owners and their creative staffs, the final presentation must be identical to the one which was created and approved during the mastering process. The time coordination between tracks should be sample-accurate, producing a result indistinguishable from what is obtained from a premastered Harrison Expires September 4, 2001 [Page 6] Internet-Draft TIS Payload Format March 2001 multiplexed stream. TIS provides a means to provide this level of coordination over an RTP conference. Each track must be referenced to a common timebase or "show clock". A server which sources a dozen coordinated streams may announce the relationship of all 12 RTP media clocks to the "show clock" over a single TIS stream. If additional servers are involved for additional tracks, they may provide additional TIS streams to announce the appropriate sampleclock-to-showclock correspondences. As in the "Scheduled Playout Scenario" above, additional TIS messages define the correspondence between the "show clock" and the presentation timebase. Ultimately, the various messages in various TIS streams must be resolved by software, producing a playout-specific correspondence between a local presentation clock and the sample count carried by RTP packets. The resolving may be performed at an individual receiver. Alternatively, an RTP mixer/translator may resolve the TIS information and combine the streams into a multiplexed format like MPEG-4. 2.3 Professional Editing Scenario During the preparation of an audiovisual program (post-production), sound and picture elements are combined from disparate shooting and recording sessions. In general, each original element contains some form of timebase, but the relationship between these element timebases and the show or scene timebase cannot be established until editing decisions are made. This situation can also be represented by TIS messages, with yet more layers of indirection. The individual element's timecode is correlated with the scene timeline, which is correlated with the show timeline, which is correlated with the wallclock each time a particular scratch mix is played out. ....(incomplete) 2.4 Concurrent Timebases In a traditional teleconference situation, the content is transient: it is created, transported, and rendered in real time, then lost. In this situation, the idea of a single timeline -- "now" -- is adequate for most purposes. However, when content has lasting value, it is likely to be recorded, edited, and played back many times. Immediately, four timebases become apparent: 1. Capture time (wallclock time during original recording). 2. Program time (offset from the start of this album or show). Harrison Expires September 4, 2001 [Page 7] Internet-Draft TIS Payload Format March 2001 3. Presentation time (wallclock time during this playback). 4. Sampleclock time (numerical count of samples, with arbitrary zero reference). Depending on the application, additional concurrent timebases (e.g. offset from the start of this song) may be relevant as well. We may assume that, by definition, a "timebase" advances uniformly and monotonically. Usually, then, the three or more timebases attached to a particular stream are moving in lock-step, and their relationship can be described by constant offsets. Only at certain instants -- e.g. at the end of one song and the beginning of another -- will the offsets change. This suggests that a low-bandwidth information stream carrying this offset data would be adequate to express everything that needs to be known here about the stream timing. This timing information stream (TIS) can provide precise synchronization information among the several media streams in a session by correlating the sampleclock time of each media stream to a common program timeline. There are certain situations in which prerecorded programs are intentionally played out off-speed. For example, material originated on film at 24.00 fps may be played in a European television environment at 25 fps, or in a U.S. television environment at 23.98 fps. In these situations the timing information stream will carry offset information which changes slowly over time as the presentation timebase drifts uniformly relative to the capture and/or program timebase. The implementation of the concurrent timebase model defined here, using the RTP framework, is based on a new media stream type: TIS. A single TIS stream can carry information about several timebases. A timebase which belongs to an RTP media stream is identified by its SSRC (Synchronization Source) identifier. "Virtual" timebases, like program time, are identified by a label, unique within that TIS. A typical message within a TIS stream states, effectively, "point A on timebase X is coincident with point B on timebase Y." Fractional clock resolution in these messages is appropriate. It is highly desirable that new sources be able to join an ongoing session and synchronize properly. That is one reason that multiple concurrent TIS streams are supported. A reference to the label of a virtual timebase may be made unique within a session by pairing it with the SSRC of the corresponding TIS stream. While genuine sampleclock timebases are constrained by the RTP standard to move smoothly forward in time, this is not generally the Harrison Expires September 4, 2001 [Page 8] Internet-Draft TIS Payload Format March 2001 case with the virtual timebases which appear in a TIS. For example, the "time offset within song" timebase will jump back to zero at the beginning of each song. It is useful to append an arbitrary instance identifier to each virtual-timebase label, so that this type of event is treated as the termination of one timebase instance and the initiation of another timebase instance. This retains monotonicity. Messages about the upcoming initiation and termination of timebases are embedded in the TIS data stream. A particularly important timebase in multimedia applications is the presentation timebase. A presentation timebase exists at each location where content is seen or heard. Sometimes there are several separate pieces of playback hardware at the same location; such cases can lead to critical requirements for inter-equipment synchronization. For example, two broadcast-video streams might be brought back to a TV studio, and converted to analog video by two separate workstations. The two analog video signals are connected to a video switcher, where an operator may perform wipes, crossfades, or cuts. This functionality requires that the two video signals be synchronized within a few tens of nanoseconds. In practice, each workstation will receive a reference signal (black burst) which serves as a presentation timebase for this studio. Such a reference signal may carry abolute time code in accordance with SMPTE standards and this time code can be referenced as the presentation timebase in a TIS data stream. Any existing professional audiovisual "hardwired" synchronization scheme can be linked with an RTP session in a similar way. Harrison Expires September 4, 2001 [Page 9] Internet-Draft TIS Payload Format March 2001 3. Timing Information Stream 3.1 Packet Structure Timing information is carried by a sequence of RTP packets. Each packet contains one or more TIS messages. Two types of TIS messages are defined: sync_msg and ratio_msg. These messages are of variable length, but always a whole number of 32-bit words. While the payload format permits arbitrarily many TIS messages to be combined in a single RTP packet, applications should limit the size of RTP packets in order to avoid fragmentation. A TIS stream is usually delivered concurrently with other media streams. The timing information carried via TIS is "about" particular time points in these media streams. However, the TIS data may be delivered in advance of the media it describes; this is useful for systems which must schedule disk accesses, pre-roll tape media, etc. There is no requirement that the TIS messages come in any particular order (e.g. monotonically) with respect to any media timebase. The scheduling of the TIS stream relative to various media streams is application-dependent and is controlled by parameters in the session description or by methods outside the scope of this payload format. The TIS stream may describe events that are expected to occur in the future. It is possible that the sending application may subsequently discover that its prediction was erroneous. Therefore there is provision for the TIS sender to cancel a message which was previously transmitted. Harrison Expires September 4, 2001 [Page 10] Internet-Draft TIS Payload Format March 2001 The structure of an RTP packet in a TIS stream is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |C| T | V | message length | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : message of type T (sync_msg or ratio_msg) : | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : : : : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |C| T | V | message length | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : message of type T (sync_msg or ratio_msg) : | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 1. TIS Packet. The first several words of the TIS packet comprise a standard RTP [1] header. A TIS stream usually refers to one or more media streams transported separately. If, as is often the case, these streams are carried in the same RTP session, each such stream is normally considered a "contributing source" and corresponds to a CSRC entry in the packet header. Up to 15 CSRC entries may occur in a single RTP packet. If more than 15 concurrent RTP media streams are to be synchronized, the TIS sending application may build several messages and transmit them in separate RTP packets. Alternatively, the sending and receiving applications may negotiate (by means outside of this payload format description) to refer to these media clocks by specific TB identifiers (see below) instead of using the CSRC mechanism. Harrison Expires September 4, 2001 [Page 11] Internet-Draft TIS Payload Format March 2001 Every TIS message begins with a header word containing a message type T and a message length (in 32-bit words). Receiving applications which do not recognize a particular message type T should skip to the next message in the packet and process it normally. 3.2 Sync Messages A sync message states that two or more temporally related identifiers, on two different timebases, correspond to the same instant in time. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| T=0 |V=0| message length | sequence | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | TB identifier |TB inst| TB format | W |e|s/s| rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | : : | timestamp extension(s) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : : : : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | TB identifier |TB inst| TB format | W |e|s/s| rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | : : | timestamp extension(s) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 2. The sync_msg payload (T=0). The sync_msg payload begins with a 32-bit header word and is optionally followed by a sequence of temporally related identifiers (TRIs). The fields of the header word are: 'C': This is a boolean cancellation flag. If C=0, the message describes a valid synchronization point. If C=1, the message revokes an earlier sync_msg, identified by the 'sequence' field (see below). If an application receives two or more TIS messages with the same sequence value, and any one of the messages contains C=1 (regardless of order of receipt), the synchronization information contained in all the messages should be treated as invalid. Harrison Expires September 4, 2001 [Page 12] Internet-Draft TIS Payload Format March 2001 'T': This is a 3-bit message type field. The value T=0 identifies this as a sync_msg. 'V': This is a 2-bit message version field. The value V=0 identifies the first version of the sync_msg specification. 'message length': This is an unsigned 10-bit number representing the number of 32-bit words following the header word. For cancellation messages, the value will be 0. 'sequence': This is a 16-bit unsigned sequence number which should be incremented by the sending application for every TIS message transmitted. Its purpose is to allow cancellation of messages as described above. Each TRI contains a header word and timestamp information. The fields are as follows: 'TB identifier': This 12-bit field identifies a timebase associated with this session. Values 0 through 15 refer to the media clocks of specific RTP streams. Value 0 refers to the TIS stream itself, and values 1 through 15 refer to the CSRC entries in the RTP packet header. Value 16 refers to generic "wallclock time". [When precise synchronization to UTC is desired, applications should negotiate a specific method and assign a separate timebase identifier.] Values 7 through 4095 are assigned in the session description or by means outside of this payload specification. 'TB inst': This 4-bit field identifies an instance of a timebase, and qualifies the TB identifier. Only one instance of a timebase may be active at any time. However, one instance of a timebase may terminate and another instance may be initiated, in order to describe non-monotonic timebase behavior. For example, when a program is presented twice in succession, the "offset into program" timebase may be reset to zero at the beginning of the second showing. The "offset into program" timebase will typically retain its TB identifier but will adopt a new TB instance value for each showing of the program. TB instance value 0 is reserved with the meaning "the currently active instance". 'TB format': This 6-bit field identifies the format in which the timestamp is encoded. Values 0 thru 3 are permanently assigned in this payload format. Values 4 thru 63 are assigned dynamically in the session description or by means outside of this payload specification. Value 0 represents a generic incrementing timestamp (e.g. sample count) with a word size defined by the W and f fields. Value 1 represents NTP format. Values 2 and 3 are reserved. Applications which do not recognize the TB format in a Harrison Expires September 4, 2001 [Page 13] Internet-Draft TIS Payload Format March 2001 TRI should use the W field to skip over this TRI and should process the remaining TRIs in the message normally. 'W': This 3-bit field represents the number of 32-bit words following the TRI header. 'e': This boolean flag indicates whether the timestamp includes a 32- bit extension word subdividing the lowest-order bit of the "native" format defined by the 'TB format' field. The extension word is present when e=1 and absent when e=0. If the extension word is present, it is included in the word count represented by the W field. 's/s': This two-bit field represents "start/stop" information about the initiation or termination of a timebase instance. The values are: msb lsb 0 0 - continuing timebase (normal condition) 0 1 - "start" - this timebase instance commences at this time 1 0 - "stop" - this timebase instance terminates at this time 1 1 - reserved 'rsrvd': This 4-bit field is reserved and should be transmitted as zero. 'timestamp' (and extension): These words represent an instant in time according to the referenced timebase. The format of representation is determined by the 'TB format' field. 3.3 Ratio Messages It is common for several timebases to proceed in exact synchronism (i.e. with a constant time offset) for a considerable duration. The timebases may be identical format (e.g. SMPTE time code) or they may be different formats describing the same material (e.g. SMPTE time code and media sample clock). By use of a ratio_msg, these situations can be described quite concisely in the TIS stream, thereby saving bandwidth. The ratio_msg defines a ratio between two or more timebases. In the simple case of identical formats proceeding in sync, the ratio is 1. In the case of different timebases operating at different rates but Harrison Expires September 4, 2001 [Page 14] Internet-Draft TIS Payload Format March 2001 phase locked to each other, the ratio will be different. For example, 25 fps video encoded with a 90 kHz media clock will exhibit a ratio between SMPTE/EBU timecode and media clock of 1:3600. It is important to distinguish those cases (such as the video example given above), in which two timebases are natively phase locked, from those cases where the timebases are independent of each other but operating at a known speed ratio. In this latter situation, periodic sync_msg's should be sent to maintain accurate phasing in the face of drift. The ratio_msg contains an L flag ("locked") to identify phase-locked timebases. It is possible for the ratio between two timebases to change. For example, relationship to wallclock time will vary widely when "trick play" modes (freeze frame, slow-mo, etc.) are used. Thus a particular ratio_msg may need to come into effect (or go out of effect) at particular instants in time. Every ratio_msg has the option of carrying a "start/stop" flag and a TRI in order to specify its time of effectiveness. Harrison Expires September 4, 2001 [Page 15] Internet-Draft TIS Payload Format March 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| T=1 |V=0| message length | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TB identifier |TB inst| TB format | W |e|s/s| rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) | : timestamp : | timestamp extension(s) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | TB identifier |TB inst| Rfmt| W |L| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : timebase ratio : | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : : : : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | TB identifier |TB inst| Rfmt| W |L| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : timebase ratio : | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 3. The ratio_msg payload (T=1). The ratio_msg payload begins with a 32-bit header word and is optionally followed by a TRI and sequence of ratio statements. The fields of the header word are: 'C': This is a boolean cancellation flag as in the sync_msg. 'T': This is a 3-bit message type field. The value T=1 identifies this as a ratio_msg. 'V': This is a 2-bit message version field. The value V=0 identifies the first version of the ratio_msg specification. 'message length': This is an unsigned 10-bit number representing the number of 32-bit words following the header word. For cancellation messages, the value will be 0. 'sequence': This is a 16-bit unsigned sequence number as in the sync_msg. Harrison Expires September 4, 2001 [Page 16] Internet-Draft TIS Payload Format March 2001 The header is followed by a temporally related identifier (TRI). This defines the "anchor" timebase against which all ratios are specified. The TRI header word may be followed by a timestamp field. This field is required if the "start/stop" field is 01 or 10. The fields of the TRI are identical to the usage in the sync_msg, except for the meaning of the 's/s' field: 's/s': This two-bit field represents "start/stop" information about the effectivity of a ratio statement. The values are: msb lsb 0 0 - continuing applicability (normal condition) 0 1 - "start" - this ratio commences at this time 1 0 - "stop" - this ratio terminates at this time 1 1 - reserved In the normal condition ('s/s'=00), the 'W' field should be set to zero and no timestamp field should be transmitted. If a receiving application is unable to recognize the TRI, it should ignore the entire ratio_msg and process the next TIS message in the packet normally. The TRI is followed by one or more ratio statements. Each ratio statement begins with a statement header with the following fields: 'TB identifier': This 12-bit field is identical to that in the sync_msg 'TB inst': This 4-bit field is identical to that in the sync_msg 'Rfmt': This 3-bit field identifies the format of the timebase ratio data. Values 0 thru 3 are permanently assigned in this payload format. Values 4 thru 7 are assigned dynamically in the session description or by means outside of this payload specification. Values 0, 1, and 2 are shown in fig. 4. Value 3 is reserved. 'W': This 3-bit field represents the number of 32-bit words following the statement header, as in the sync_msg. 'L': This boolean flag indicates whether the timebase in this statement is phase-locked to the anchor timebase. When the timebases are locked, L=1; when they are independent, L=0. 'reserved': This 9-bit field is reserved and should be transmitted as Harrison Expires September 4, 2001 [Page 17] Internet-Draft TIS Payload Format March 2001 zero. An application which is unable to interpret a particular ratio statement should ignore it and process any remaining ratio statements normally. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | numerator (2's compl) | denominator (unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Rfmt=0; 16:16 ratio) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | numerator (2's compl) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | denominator (unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Rfmt=1; 32:32 ratio) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IEEE floating point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Rfmt=2; floating point ratio) Figure 4. Timebase ratio formats. The fraction or real number in a ratio statement is interpreted as the number of quantized units in the specified timebase which pass during each quantized unit in the anchor timebase. The "quantized unit" is part of the definition of a timebase format. Typically the quantized unit might be one second, one frame, or one sample. Note that some formats (e.g. NTP time) include a fractional part, so the quantized unit may be much larger than the resolution step. Harrison Expires September 4, 2001 [Page 18] Internet-Draft TIS Payload Format March 2001 4. SDP Parameters Parameters of a TIS stream may be published to receiving applications by means of the Session Description Protocol (SDP) [4]. ...(incomplete) m=application 3456 RTP/AVP 99 : dynamically assigned payload type a=rtpmap:99 tis/1000 : TIS with 1kHz ticks a=tis-fmt-map:12 smpte-24-bcd : dynamically assigned TB format a=tis-fmt-map:13 keycode-4perf-35 : dynamically assigned TB format a=tis-rate-map:5 ieee-double : dynamically assigned Rfmt a=tb-name:100 show clock : name is informative only a=tb-ref:100 virtual : no media stream, virtual timebase a=tb-ref:123 rtp 1234 : media stream, RTP on port 1234 a=tb-ref:124 virtual : no media stream, virtual timebase a=tb-name:124 dialog timecode : name is informative only a=tb-ref:125 tis 25 rtp 3460 : link to TB id = 25 in TIS stream on port 3460 Harrison Expires September 4, 2001 [Page 19] Internet-Draft TIS Payload Format March 2001 5. Model for Resolving Timebases ...(incomplete) Harrison Expires September 4, 2001 [Page 20] Internet-Draft TIS Payload Format March 2001 6. Security Considerations The proposals in this memo present few new security considerations. It is possible that a defective or malicious application may send inconsistent information in a TIS stream which would affect the performance of a receiver. Receiving applications should respond in a safe manner to inconsistent timing information. Harrison Expires September 4, 2001 [Page 21] Internet-Draft TIS Payload Format March 2001 References [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [2] Harrison, C., "Audiovisual Transport with Precision Timing", draft-harrison-avt-precision-av-00.txt (work in progress), February 2001. [3] , ., "Proposed SMPTE Standard for Television, Audio, and Film - Temporally Related Identifier (TRI)", SMPTE Draft S22.251-2246B, February 2001. [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Harrison, C., "Timbase Interlock in RTP Conferences (unwritten draft)", , March 2001. Author's Address Chuck Harrison Far Field Associates, LLC 18815 111th Pl SE Snohomish, WA 98290 US Phone: +1 360 863 8340 EMail: chuck_harrison@iname.com Harrison Expires September 4, 2001 [Page 22] Internet-Draft TIS Payload Format March 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Harrison Expires September 4, 2001 [Page 23] --------------BA885D37DF17EED901A74209-- From rem-conf Wed Mar 07 03:20:41 2001 From rem-conf-request@es.net Wed Mar 07 03:20:40 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14abmK-0000G1-00; Wed, 7 Mar 2001 03:06:48 -0800 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 14abmJ-0000Fr-00; Wed, 7 Mar 2001 03:06:47 -0800 Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f27B6aS28397 for ; Wed, 7 Mar 2001 13:06:40 +0200 (EET) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Mar 2001 13:06:36 +0200 Received: by esebh11nok with Internet Mail Service (5.5.2652.78) id ; Wed, 7 Mar 2001 13:06:33 +0200 Message-ID: <25B79E9476BAD211811B0008C7894CDC04D0A467@treis04nok> From: ari.lakaniemi@nokia.com To: csp@isi.edu Cc: rem-conf@es.net Subject: RE: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt Date: Wed, 7 Mar 2001 13:06:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hello Colin & others, We agree with Colin that any further delays in finalizing the AMR RTP payload should be avoided if possible. The AMR RTP format will be also used by 3GPP release4 specifications (that are currently being finalized), and it would be important to have the final AMR RTP format available (as RFC) as soon as possible to enable vendors to start their implementations. We would also see benefit in keeping the AMR and AMR-WB RTP specifications in separate documents. This is likely to avoid extra confusion by emphasizing the fact that despite quite similar names these two are completely different and separate speech codecs. The similarity to the AMR RTP payload was one design criteria for our proposal for AMR-WB RTP payload format. I think that format we are proposing enables the re-use of most of the AMR RTP payload implementation, and the small differences (due to proposed optional interleaving, different interpretation of 'codec mode request' bits, and reversed order of FT & Q bits in ToC to be aligned with 3GPP AMR-WB frame format) are justified. on behalf of the AMR-WB RTP authors, Ari Lakaniemi Nokia Research Center > -----Original Message----- > From: ext Colin Perkins [mailto:csp@isi.edu] > Sent: 03. March 2001 1:02 > To: Orion Hodson > Cc: Wim.Van_Den_Boeck@alcatel.be; Magnus Westerlund; rem-conf@es.net > Subject: Re: I-D ACTION:draft-lakaniemi-avt-amrwb-00.txt > > > It is also worth noting that the AMR payload format has taken > longer than > would have been desirable, and that further delay could be > problematic. > > My suggestion is that the authors of the AMR-WB payload > format consider if > it can be made identical to the standard AMR payload format. > In that case, > the draft can be a simple MIME registration plus a pointer to > the other > document. Otherwise we need to define a new payload format, > which will need > a new draft anyway. > > This avoid confusion and further delay to the AMR payload. > > Colin > > > > --> Orion Hodson writes: > > > >Wim.Van_Den_Boeck@alcatel.be writes: > >> > >> About the yes/not separation of the AMR (say(1)) and AMR WB (say > >> (2)) payload drafts... I'm puzzling about which are the > application > >> domains of this new formats. Is it so that (1) was originally > >> planned for use in UMTS, while (2) is proposed as a 'new > GSM' codec ? > >> > >> Do the payload formats correspond with those 2 cases ? I guess so. > >> > >> Isn't it possible that both streams of information will > one day pass > >> over the same networks and that thus a uniform format might be > >> interesting ? > > > >Yes, but you cannot assume all endpoints support the formats - > >capabilities need to be negotiated (ergo SIP/SAP/SDP). And there are > >no static payloads for new formats so negotiation has to happen. > > > >> Therefore I also support the idea of adapting the classical "RTP > >> payload format for AMR" draft, rather than producing 2 drafts. > > > >The drafts are similar but the authors to decide how these payloads > >are described with least ambiguity. Describing 2 similiar, but > >subtlely different formats might be better in two documents. > > > >Kind Regards > >- Orion. > > > >BTW, I didn't fully understand the earlier comment about sampling > >rates and clocks preventing a single draft. Most of the RTP audio > >formats use the sampling clock for timestamps (eg. l16-8k uses 8kHz, > >l16-44100 uses 44.1kHz). It's easily resolved when using SDP, the > >8kHz and 16kHz get different payload id's. > > > > > >> > Magnus Westerlund wrote: > >> > > > >> > > Qiaobing, > >> > > > >> > > There are several reasons why there should be > different payload formats, the two > >> > > largest are: First, AMR and AMR WB are two different > codecs, with totally separate > >> > > implementations. As they are separate, the > demultiplexing of codec used in a RTP > >> > > stream are best handled by the payload type. Secondly > they are using different > >> > > sampling rates and therefore RTP timestamp rates. I > belive combining codecs with > >> > > different rates in one payload format would be difficult. > >> > > > >> > > >> > -- > >> > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >> > >> > >> > >> > >> > > > From rem-conf Wed Mar 07 04:43:36 2001 From rem-conf-request@es.net Wed Mar 07 04:43:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14adBl-0001bA-00; Wed, 7 Mar 2001 04:37:09 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14adBj-0001b0-00; Wed, 7 Mar 2001 04:37:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00725; Wed, 7 Mar 2001 07:37:05 -0500 (EST) Message-Id: <200103071237.HAA00725@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-interop-05.txt Date: Wed, 07 Mar 2001 07:37:05 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Audio/Video Profile Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-profile-interop-05.txt Pages : 7 Date : 06-Mar-01 It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-interop-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-interop-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-interop-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-interop-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-interop-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125221.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Mar 07 04:43:36 2001 From rem-conf-request@es.net Wed Mar 07 04:43:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14adBo-0001bM-00; Wed, 7 Mar 2001 04:37:12 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14adBn-0001bC-00; Wed, 7 Mar 2001 04:37:11 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00738; Wed, 7 Mar 2001 07:37:10 -0500 (EST) Message-Id: <200103071237.HAA00738@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-interop-07.txt Date: Wed, 07 Mar 2001 07:37:09 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-rtp-interop-07.txt Pages : 8 Date : 06-Mar-01 It is required to demonstrate interoperability of RTP implementations in order to move the RTP specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-interop-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-interop-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-interop-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125240.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Mar 07 11:48:20 2001 From rem-conf-request@es.net Wed Mar 07 11:48:19 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ajo8-0006sA-00; Wed, 7 Mar 2001 11:41:12 -0800 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ajo7-0006qd-00; Wed, 7 Mar 2001 11:41:11 -0800 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21690 for ; Wed, 7 Mar 2001 11:40:29 -0800 (PST) Received: from cisco.com (mchiba-dsl3.cisco.com [10.19.32.188]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABI03942 (AUTH mchiba); Wed, 7 Mar 2001 11:40:09 -0800 (PST) Sender: mchiba@cisco.com Message-ID: <3AA68CA3.FE06506D@cisco.com> Date: Wed, 07 Mar 2001 11:31:48 -0800 From: Murtaza Chiba Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Privacy with conferencing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, For conferencing purposes are there protocols for ensuring privacy? That is can I broadcast on the MBone and make it available only to people with whom I share a secret. I understand currently the entire network is in an experimental stage. Thanks, Murtaza From rem-conf Wed Mar 07 12:01:54 2001 From rem-conf-request@es.net Wed Mar 07 12:01:53 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ak6z-0007YQ-00; Wed, 7 Mar 2001 12:00:41 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ak6s-0007Y4-00; Wed, 7 Mar 2001 12:00:39 -0800 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA16581 for ; Wed, 7 Mar 2001 12:00:15 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Mar 2001 12:00:08 -0800 Received: from [17.202.37.152] (il0203a-dhcp24.apple.com [17.202.37.152]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id LAA03420; Wed, 7 Mar 2001 11:59:58 -0800 (PST) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <200102281820.NAA09950@purple.east.isi.edu> References: <200102281820.NAA09950@purple.east.isi.edu> Date: Wed, 7 Mar 2001 11:58:45 -0800 To: Colin Perkins From: Kevin Marks Subject: Re: RTP Interoperability testing Cc: rem-conf Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 1:20 pm -0500 28/2/01, Colin Perkins wrote: >we're currently missing interop results for : > - Video codecs: H.263, If you mean payload 34, QT will decode this if anyone is sending it. H263-1998 interoperates with Minerva too. From rem-conf Wed Mar 07 17:46:47 2001 From rem-conf-request@es.net Wed Mar 07 17:46:46 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14apJS-0003s2-00; Wed, 7 Mar 2001 17:33:54 -0800 Received: from fusberta.elet.polimi.it [131.175.21.8] (wmi2001) by mail1.es.net with esmtp (Exim 1.81 #2) id 14apJQ-0003rs-00; Wed, 7 Mar 2001 17:33:52 -0800 Received: from host localhost and sender wmi2001@localhost; by mail relay Fusberta.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier CAA24007; on date and time Thu, 8 Mar 2001 02:31:57 +0100 (MET). Date: Thu, 8 Mar 2001 02:31:57 +0100 (MET) From: Wireless Mobile Internet 2001 To: Wireless Mobile Internet 2001 Subject: Wireless Mobile Internet Workshop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Sorry if this is a duplicate email] CALL FOR PAPER: WIRELESS MOBILE INTERNET ======================================== The first ACM Wireless Mobile Internet Workshop will take place in conjunction with the International Conference on Mobile Computing and Networking, Mobicom 2001, to be held in Rome, Italy, on July 16-21, 2001. This is an excellent opportunity to participate in two events covering a wide range of research in mobile computing and Internet related technologies. The workshop will be one-day long. It is a single track event and will have presentation of selected and invited papers as well as a panel discussion. Important dates: ---------------- - April 1, 2001: Electronic Paper Submission Deadline - May 30, 2001: Acceptance/Rejection Notification - July 21, 2001: Workshop day Conference site and email ------------------------- http://cerbero.elet.polimi.it/wmi2001 wmi2001@fusberta.elet.polimi.it Submission Instructions: ------------------------ http://cerbero.elet.polimi.it/wmi2001/subm.html Journal publication: -------------------- Selected workshop papers will be considered for publication on a Special Issue of the Journal "Wireless Communications and Mobile Computing", Wiley Publ. Workshop general objectives --------------------------- This workshop will explore the emerging area of Wireless Mobile Internet. The tremendous success of Internet related technologies coupled with higher wireless access speeds promised by new and emerging technologies and standards such as GPRS, EDGE and UMTS brings about opportunities to support new applications and services. The emergence of highly miniaturized, compact, and sophisticated Personal Digital Assistance (PDA) devices brought about by advances in display technologies, circuit design, and embedded software technologies together with promises of wireless access to the Internet brings about new frontiers in usage and applications which represent what has come to be known as pervasive computing. The workshop focuses on major aspects of this revolution, with focus on problems related to IP-based mobile Internet and problems related to the wireless access to the Internet. On the networking front, the emergence of mobility has introduced new challenging problems such as QOS, control, management and routing. The emergence of new wireless access technologies, ranging from Bluetooth to UMTS and satellite systems confronts us on how to smoothly merge these diverse technologies. Together, they offer new capabilities to applications such as mobile commerce, information retrieval and such. This workshop will be the first open forum to address these problems. Leaders and thinkers of the field from academia, industry and research laboratories will assemble to share their views on technical problems and pave the road for the visions of tomorrow. Detailed workshop topics ------------------------ Authors are invited to submit original papers describing current research and visions of the future. Papers should address issues related to wireless internet protocols, services and platforms, as well as issues regarding transmission, access, and mobility technologies specifically designed to support Internet traffic and applications. A list of detailed topics includes, but is not limited to: - Access protocols and modulation schemes - Network architectures for wireless Internet access - mobility management mechanisms - Handover and admission control - Traffic models for wireless internet applications - QoS support in wireless access networks. - Performance enhancements of Internet protocols over wireless links - Power efficiency - Mobile services, applications, middleware - Security and billing - Internet Appliances Organizing Committee: - Giuseppe Bianchi, University of Palermo, Italy, bianchi@elet.polimi.it - Parviz Kermani, IBM T.J. Watson Res. Center, NY, USA, parviz@us.ibm.com - Silvano Pupolin, University of Padova, Italy, pupolin@fiore.dei.unipd.it Technical Program Committee: - Andrea Baiocchi, University La Sapienza, Rome, Italy (baiocchi@infocom.uniroma1.it) - Pravin Bhagwat, ATT Research, USA (pravinb@research.att.com) - Giuseppe Bianchi, University of Palermo, Italy (bianchi@elet.polimi.it) - Chatschik Bisdikian, IBM T.J. Watson Research Center, NY, USA (bisdik@us.ibm.com) - Shyam S. Chakraborty, Helsinky University of Technologies, Finland (Shyam.Chakraborty@hut.fi) - Francesca Cuomo, University La Sapienza, Rome, Italy (franci@infocom.uniroma1.it) - Gabor Fodor, Ericsson Telecommunications, Sweden (Fodor@era-t.ericsson.se) - Zygmunt Haas, Cornell University, USA (zjh1@cornell.edu) - Sung-Ju Lee, Hewlett-Packard Labs, USA (sjlee@hpl.hp.com) - Nitin Vaidya, Texam A&M University, USA (vaidya@cs.tamu.edu) - Lorenzo Vangelista, Telital, Italy (lorenzo.vangelista@telital.it) From rem-conf Wed Mar 07 19:30:55 2001 From rem-conf-request@es.net Wed Mar 07 19:30:54 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ar6H-0005aS-00; Wed, 7 Mar 2001 19:28:25 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ar6E-0005aI-00; Wed, 7 Mar 2001 19:28:23 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA01911; Wed, 7 Mar 2001 22:21:12 -0500 Message-Id: <200103080321.WAA01911@purple.east.isi.edu> To: Kevin Marks cc: rem-conf Subject: Re: RTP Interoperability testing In-Reply-To: Message from Kevin Marks of "Wed, 07 Mar 2001 11:58:45 PST." Date: Wed, 07 Mar 2001 22:21:12 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Kevin Marks writes: >At 1:20 pm -0500 28/2/01, Colin Perkins wrote: >>we're currently missing interop results for : >> - Video codecs: H.263, > >If you mean payload 34, QT will decode this if anyone is sending it. Does vic support it? Colin From rem-conf Wed Mar 07 19:30:55 2001 From rem-conf-request@es.net Wed Mar 07 19:30:54 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ar6N-0005ah-00; Wed, 7 Mar 2001 19:28:31 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ar6L-0005aI-00; Wed, 7 Mar 2001 19:28:30 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA01628; Wed, 7 Mar 2001 22:06:09 -0500 Message-Id: <200103080306.WAA01628@purple.east.isi.edu> To: Murtaza Chiba cc: rem-conf@es.net Subject: Re: Privacy with conferencing In-Reply-To: Message from Murtaza Chiba of "Wed, 07 Mar 2001 11:31:48 PST." <3AA68CA3.FE06506D@cisco.com> Date: Wed, 07 Mar 2001 22:06:09 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Murtaza Chiba writes: >Hi, > For conferencing purposes are there protocols for ensuring >privacy? > That is can I broadcast on the MBone and make it available only to >people with whom I share a secret. I understand currently the entire >network is in an experimental stage. There are encryption hooks in RTP (RFC 1889) and also a new proposal for a secure RTP profile (draft-ietf-avt-srtp-00.txt). Perhaps a more interesting problem is group key exchange: see the MSEC working group. Colin From rem-conf Thu Mar 08 00:13:32 2001 From rem-conf-request@es.net Thu Mar 08 00:13:32 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14avU6-0001q0-00; Thu, 8 Mar 2001 00:09:18 -0800 Received: from (exchange.Ic4ic.com) [194.90.135.194] by mail1.es.net with smtp (Exim 1.81 #2) id 14avU5-0001pq-00; Thu, 8 Mar 2001 00:09:17 -0800 content-class: urn:content-classes:message Subject: RTP/UDP/IP Compression over PPP Date: Thu, 8 Mar 2001 10:07:10 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D3687@exchange.Ic4ic.com> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: RTP/UDP/IP Compression over PPP Thread-Index: AcCnpsZld9VeXjgETZaTxRBzKI/Uhw== X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Daniel Feldman" To: , "rem-conf" Cc: "Eyal Gutman" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone know how to set up a PPP connection for RTP/UDP/IP compressed? I know it is possible to it for TCP/IP compressed. Thanks a lot, ~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC ltd. office: +972-4-9594644 ext. 121 mobile: +972-53-980442 fax: +972-4-9594944 ~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Thu Mar 08 02:40:14 2001 From rem-conf-request@es.net Thu Mar 08 02:40:13 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14axn1-00047L-00; Thu, 8 Mar 2001 02:36:59 -0800 Received: from nmh.informatik.uni-bremen.de [134.102.224.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14axmz-00047B-00; Thu, 8 Mar 2001 02:36:57 -0800 Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f28AaTn00758; Thu, 8 Mar 2001 11:36:29 +0100 (MET) From: "Dr. Carsten Bormann" To: "Daniel Feldman" , , "rem-conf" Cc: "Eyal Gutman" Subject: RE: RTP/UDP/IP Compression over PPP Date: Thu, 8 Mar 2001 11:36:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <88BC9E379956AE4DB689CC5FF6F5A43D3687@exchange.Ic4ic.com> Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list See RFC2509 (which references RFC2507 and 2508 for the compression method itself). If your links are lossy with relatively high RTT (e.g., cellular), an alternative is draft-ietf-rohc-over-ppp-01.txt (which references the soon-to-be-published robust header compression protocols, see draft-ietf-rohc-rtp-09.txt). Gruesse, Carsten > -----Original Message----- > From: Daniel Feldman [mailto:daniel@Ic4ic.com] > Sent: Thursday, March 08, 2001 09:07 > To: ietf-ppp@merit.edu; rem-conf > Cc: Eyal Gutman > Subject: RTP/UDP/IP Compression over PPP > > > Does anyone know how to set up a PPP connection for RTP/UDP/IP > compressed? I know it is possible to it for TCP/IP compressed. > Thanks a lot, > > ~~~~~~~~~~~~~~~~~~~~~~~~ > Daniel Feldman > System Engineer, IC4IC ltd. > office: +972-4-9594644 ext. 121 > mobile: +972-53-980442 > fax: +972-4-9594944 > ~~~~~~~~~~~~~~~~~~~~~~~~ > > From rem-conf Thu Mar 08 04:45:12 2001 From rem-conf-request@es.net Thu Mar 08 04:45:12 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14azbB-0005uI-00; Thu, 8 Mar 2001 04:32:53 -0800 Received: from patan.sun.com [192.18.98.43] by mail1.es.net with esmtp (Exim 1.81 #2) id 14azb9-0005u8-00; Thu, 8 Mar 2001 04:32:51 -0800 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15127; Thu, 8 Mar 2001 04:32:45 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01868; Thu, 8 Mar 2001 07:32:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f28CXJG97407; Thu, 8 Mar 2001 07:33:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15015.31759.318909.361837@gargle.gargle.HOWL> Date: Thu, 8 Mar 2001 07:33:19 -0500 (EST) From: James Carlson To: "Daniel Feldman" Cc: , "rem-conf" , "Eyal Gutman" Subject: Re: RTP/UDP/IP Compression over PPP In-Reply-To: Daniel Feldman's message of 8 March 2001 10:07:10 References: <88BC9E379956AE4DB689CC5FF6F5A43D3687@exchange.Ic4ic.com> X-Mailer: VM 6.75 under Emacs 20.7.1 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Daniel Feldman writes: > Does anyone know how to set up a PPP connection for RTP/UDP/IP > compressed? I know it is possible to it for TCP/IP compressed. Are you asking a question about the protocol? If so, then see RFC 2509. If you're asking a question about a particular implementation, then this is the wrong place to ask. Try contacting the manufacturer involved, or a related newsgroup, or search the web. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From rem-conf Thu Mar 08 06:48:08 2001 From rem-conf-request@es.net Thu Mar 08 06:48:07 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14b1ey-0000du-00; Thu, 8 Mar 2001 06:44:56 -0800 Received: from (exchange.Ic4ic.com) [194.90.135.194] by mail1.es.net with smtp (Exim 1.81 #2) id 14b1ew-0000dk-00; Thu, 8 Mar 2001 06:44:55 -0800 content-class: urn:content-classes:message Subject: RTP/UDP/IP Compression Date: Thu, 8 Mar 2001 16:42:44 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D368B@exchange.Ic4ic.com> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: RTP/UDP/IP Compression Thread-Index: AcCn3gkloaK3TX2JRDuElUb/e7sdYg== X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Daniel Feldman" To: "James Carlson (E-mail)" , "Carsten Bormann (E-mail)" Cc: "rem-conf" , "Eyal Gutman" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks a lot!!! ~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC ltd. office: +972-4-9594644 ext. 121 mobile: +972-53-980442 fax: +972-4-9594944 ~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Thu Mar 08 07:43:20 2001 From rem-conf-request@es.net Thu Mar 08 07:43:20 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14b2Xu-0001y6-00; Thu, 8 Mar 2001 07:41:42 -0800 Received: from (borg.limmat.ch) [62.12.130.253] by mail1.es.net with esmtp (Exim 1.81 #2) id 14b2Xt-0001xu-00; Thu, 8 Mar 2001 07:41:41 -0800 Received: from blainejensen.com (hobbes.limmat.ch [195.49.39.46]) by borg.limmat.ch (8.9.3/8.9.3) with SMTP id QAA08693; Thu, 8 Mar 2001 16:36:37 +0100 From: removeplease4@cn899.com Message-ID: <000027a13764$0000799b$00001e8d@hqportland.com> To: Subject: Achieving Date: Thu, 08 Mar 2001 09:35:08 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enjoy the benefits of working at home? Build a Financial Future for you and your family? Earn $100 to $500 a day without leaving Your home! Not a MLM or Network Marketing Not a get rich quick scheme Learn to use the power of the Interne to generate long term residual income. ******* FREE Download Bonus e-Manual ******** "Microsoft, Viagra & Your Business Success" given to the first 100 people to respond within the next 24 hours, You FREE reports will be fulfilled in the order in which they were received. Instant Information Request Directions 1. Simply send an e-mail to: mailto:freereports@cn899.com?subject=More-Info-cdrom311d Or cut and paste the e-mail address freereports@cn899.com with More-Info-cdrom311d in the subject. 2. You will receive the complete info on the reports via e-mail within 24 hours. Simple Removal Instructions: To be removed from our in-house list simply hit reply and put remove in the subject line You will then be deleted from our e-mail database forever, Thank You. Enjoy the benefits of working at home? From rem-conf Thu Mar 08 11:33:00 2001 From rem-conf-request@es.net Thu Mar 08 11:32:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14b62p-0005HB-00; Thu, 8 Mar 2001 11:25:51 -0800 Received: from farley.cisco.com (cisco.com) [171.71.153.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 14b62n-0005Gf-00; Thu, 8 Mar 2001 11:25:49 -0800 Received: from rkumar-ntl.cisco.com (dhcp-171-71-9-122.cisco.com [171.71.9.122]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA25001; Thu, 8 Mar 2001 11:24:45 -0800 (PST) Message-Id: <4.3.2.7.2.20010308112325.00dd1220@farley.cisco.com> X-Sender: rkumar@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Mar 2001 11:30:31 -0800 To: rem-conf@es.net From: Rajesh Kumar Subject: rem-conf@es.net Cc: Error@cisco.com.in.rfc2833? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4873077==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_4873077==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed AVT group, The following discrepancy was brought to my notice: in rfc2833, Table 6 (Trunk events) has MF S1...S3 assigned to 142...143 Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right. Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group. Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- --=====================_4873077==_.ALT Content-Type: text/html; charset="us-ascii" AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.

 
Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------
--=====================_4873077==_.ALT-- From rem-conf Thu Mar 08 12:03:37 2001 From rem-conf-request@es.net Thu Mar 08 12:03:36 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14b6Qe-0006KB-00; Thu, 8 Mar 2001 11:50:28 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14b6Qd-0006K1-00; Thu, 8 Mar 2001 11:50:27 -0800 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA06319; Thu, 8 Mar 2001 11:38:16 -0800 Message-ID: <3AA7E0B0.D376FBBB@bmrc.berkeley.edu> Date: Thu, 08 Mar 2001 11:42:40 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 3/14 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ActiveSpaces: The Access Grid, Active Mural and Advanced Visualization Systems March 14, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Rick Stevens Mathematics and Computer Science Division Argonne National Laboratories At Argonne, Chicago and elsewhere work has begun to explore the concept of integrated whole room scale visual environments. These environments consists of group work rooms that have been augmented with multiple displays including: large-format whole wall displays (e.g. ActiveMural our high-resolution rear projected tiled display), driven by PC clusters, or multi-processor visualization engines, semi-immersive or immersive displays (Workbenches, ImmersaDesks, CAVEs), multiple desktop devices, and multiple front projection systems. These rooms may also have active or passive tracking systems, multiple channels of audio support, and support for multiple wireless hand-held controllers and navigation devices. These room-sized environments can be linked via the national "Grid" to form compelling collaborative visualization environments (e.g. "The Access Grid"). We believe these systems represent a new type of visual application development target and delivery mechanism. We call these ensembles Active Spaces. In this talk I will explore with the audience some of the ideas we are working on to facilitate the delivery of highness scientific visualization to groups of users and to create new types of electronically augmented spaces explicitly designed to support rapid collaborative exploration and visual analysis of complex data. --------------- The seminar is broadcast live on the Internet Bone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Mar 08 14:57:25 2001 From rem-conf-request@es.net Thu Mar 08 14:57:24 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14b9IO-0001k5-00; Thu, 8 Mar 2001 14:54:08 -0800 Received: from ns2.packetvideo.com [63.214.191.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 14b9IN-0001jt-00; Thu, 8 Mar 2001 14:54:07 -0800 Received: from misty.packetvideo.com ([63.214.191.76]) by ns2.packetvideo.com (8.9.3/8.9.3) with ESMTP id OAA69366 for ; Thu, 8 Mar 2001 14:53:02 -0800 (PST) (envelope-from sherwood@PacketVideo.com) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id <15TXD3D9>; Thu, 8 Mar 2001 14:47:08 -0800 Message-ID: <72660A24B978D411BB8A00B0D03DFE01178EC6@misty.packetvideo.com> From: Greg Sherwood To: "'rem-conf@es.net'" Subject: Change requested for AMR payload format (draft-ietf-avt-rtp-amr-0 5.txt) Date: Thu, 8 Mar 2001 14:47:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list After reviewing the current draft of the RTP payload for AMR (draft-ietf-avt-rtp-amr-05.txt), I noticed two very significant problems for its use with our streaming application: - the required bit stuffing/packing (i.e., no octet alignment) - no audio frame-level interleaving. These problems are severe enough for streaming applications that another payload format may need to be defined at future date if the current draft is not modified. I have written up the details of the problems and proposed one possible solution which can accommodate the current format and allow the octet alignment and frame-level interleaving. The proposed solution is certainly not the only one available. Depending on the desired tradeoff between bandwidth efficiency and complexity, many different payload header and TOC entry formats are possible which accomplish the same goals. 1) Packed Format The bit packed format was proposed to improve bandwidth efficiency, but the cost is increased complexity for both the sender and receiver. Consider the case of a video-on-demand server which is serving hundreds or thousands of simultaneous clients, each accessing different portions of a stream independently. The server will have to perform significant data manipulations and copying to translate the frame format within the file to the packed format proposed for the RTP packet. With octet-alignment within the RTP packet, the server could directly utilize blocks of memory read from the file. The amount of bandwidth savings from packing is not enough to outweigh the complexity cost for many applications. The table below summaries bits required for octet-alignment for the AMR audio frames according to mode. total AMR Mode | speech bits | pad bits | percent overhead ------------------------------------------------------------- 4.75 | 95 | 1 | 1.05 5.15 | 103 | 1 | 0.97 5.9 | 118 | 2 | 1.69 6.7 | 134 | 2 | 1.49 7.4 | 148 | 4 | 2.70 7.95 | 159 | 1 | 0.63 10.2 | 204 | 4 | 1.96 12.2 | 244 | 4 | 1.63 SID | 39 | 1 | 2.56 To octet align the payload header, which occurs once per packet, it would need to be extended from 6 to 8 bits. Similarly, each table of contents entry (one per audio frame) would need to be extended >from 6 to 8 bits. The worst-case percentage overhead compared to the packed format occurs when a packet (with no CRC in the TOC entry) contains a single 7.4 kpbs AMR frame giving an overhead of 5%. To put that number in perspective, the RTP headers without any header compression add an overhead of 60%. Clearly in the typical case, several audio frames will be placed in a single packet to reduce the packet header overhead. As more frames are added, the overhead gets closer to the numbers for the AMR bits alone (worst-case is about 3.8% overhead counting the TOC entry overhead and frame overhead for 7.4 kbps mode). Along these lines payload formats for other speech codecs such as EVRC (see draft-ietf-avt-evrc-01.txt) and PureVoice (see RFC 2658) use an octet-aligned format. 2) Frame-level Interleave. The draft introduces an optional bit-level interleave to provide some error resilience in the presence of certain bit error patterns (for link layers that pass up packets with errors). However, it is just as important to have error resilience in the presence of packet loss. For many systems, the only errors they will experience is packet loss (i.e., no bit errors) due to the behavior of the network stack. Frame level interleaving is a well-known and proven method for improving error resilience. Many audio and speech payload formats have mechanisms defined for frame level interleaving including: AAC (draft-ietf-avt-rtp-mpeg2aac-01.txt), AMR-WB (draft-lakaniemi-avt-amrwb-00.txt), EVRC (draft-ietf-avt-evrc-01.txt), MP3 (draft-ietf-avt-rtp-mp3-06.txt), and PureVoice (RFC 2658). The interleaving reduces the impact of a packet loss. A mechanism similar to that described in AMR-WB (draft-lakaniemi-avt-amrwb-00.txt) is probably a good candidate since the payload formats are otherwise identical. 3) Proposed modifications. The best solution may be to change to an octet-aligned format given the amount of bandwidth that can be saved by packing. However, if there are compelling applications where the bit packing is critical, perhaps the format can be modified to allow both octet-aligned and packed formats. One possible method of supporting both with minimal impact to the current draft, is to augment the payload header by 2 bits to indicate bit-level packing and frame-level interleaving. The payload header would change to (the exact order of the bits is not important so it could be changed as needed): 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|C|R|B|I| CMR | +-+-+-+-+-+-+-+-+ where B (1 bit): indicates whether the payload is packed (i.e., no octet alignment). The bit packed format should only be used if support is indicated. I (1 bit): Indicates the presence of frame-level interleaving. If the bit is set then an optional interleave header would follow the payload header with the format described in the AMR-WB proposal (draft-lakaniemi-avt-amrwb-00.txt). If the payload is octet-aligned then all TOC entries and AMR frames would be padded to the next octet boundary. For the bit packed format, as in the current draft, the only addition is the extra two bits in the payload header which may extend the payload by up to 1 octet depending on how many bits were needed to pad the payload to an octet boundary. However, the typical case is only a few extra bits. When robust sorting is used, the bit packed format would always be used. Please keep in mind that if the additional octet is completely unacceptable for some application there are many ways to tweak the payload header and TOC entries to reduce the overhead in certain cases. Almost certainly the only case of concern is the single frame per packet case since the percentage overhead decreases as more frames are packed together. Even for the one frame case, the additional overhead is already in the 3% range. In the one frame per packet case, the S and I bits are not relevant. Also variable length coding can be used to code the frame type (FT) as another alternative. The point is that there are no fundamental technical barriers to providing the additional information without causing unacceptable overhead compared to the current draft format. The bit packed mode should only be used if support is signaled via the optional parameters described in section 8.3 (MIME Registration) of the draft. A flag similar to the existing 'crc' and 'robust-sorting' can be added called 'bit-packing' for example. With these changes, it is likely that the AMR and AMR-WB formats can be merged into a single format (since the AMR-WB is very to AMR draft). Greg Sherwood, Ph.D. Sr. Member of Technical Staff PacketVideo Corporation From rem-conf Thu Mar 08 23:24:24 2001 From rem-conf-request@es.net Thu Mar 08 23:24:23 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bHBL-00005y-00; Thu, 8 Mar 2001 23:19:23 -0800 Received: from (ecom1.business-e.com) [205.253.122.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bHBJ-00005n-00; Thu, 8 Mar 2001 23:19:21 -0800 Received: from ecom1.business-e.com [205.253.122.120] by ecom1.business-e.com with ESMTP (SMTPD32-5.01) id A1AC9A40122; Thu, 08 Mar 2001 23:09:41 PST Content-type: text/html Date: Thu, 08 Mar 2001 22:15:58 +0700 From: bert5@janeva.com Subject: Media Delivery for the Internet - FREE Trial Included To: rem-conf@es.net Message-Id: <200103082309.SM00235@ecom1.business-e.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list rem-conf@es.net PowerPoint Media Delivery for the Internet with Animation & Sound - FREE Trial Included- No Plug In Needed http://f.orums.com
Thanks rem-conf@es.net for taking a quick look at what we have to offer.

HOME  |  PRODUCT INFORMATION  |  FREE TRIAL

.

This message contains a rich media presentation. If you can't see this presentation, please click here to launch it in your web browser.
To Be Removed:  Just hit reply with remove in the subject header.

Under Bills 1618 Title III  passed by the 105th U.S. Congress this  mail can not be considered Spam as  long as we include contact information and  and a link for removal from  our mailing list. To be  removed  from our mailing  list  reply with "REMOVE" in the  subject heading and your  email address in the body. Include complete address and/or domain/aliases to be removed. If you still get the emails, please call us at the numbers given above.
 
From rem-conf Fri Mar 09 00:20:23 2001 From rem-conf-request@es.net Fri Mar 09 00:20:22 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bI5S-0001gh-00; Fri, 9 Mar 2001 00:17:22 -0800 Received: from (mailman.packetdesign.com) [65.192.41.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bI5R-0001ft-00; Fri, 9 Mar 2001 00:17:21 -0800 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f298Exe80530; Fri, 9 Mar 2001 00:14:59 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 9 Mar 2001 00:15:47 -0800 (PST) From: Stephen Casner Sender: casner@packetdesign.com To: rem-conf@es.net Subject: AVT WG last call on RTP spec and profile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: This message is to announce the repeat WG last call on the RTP spec and A/V profile to end in two weeks at the IETF meeting in Minneapolis. These drafts are to go to Draft Standard RFC status. Note that we already completed a WG last call on these drafts a year ago, but we've had some trouble completing the interoperability matrix. A new last call is being issued because SOME ITEMS HAVE BEEN DELETED and because there has some additional text has been added on congestion control in response to the discussions at the last two meetings. Please review these changes, and also please take this opportunity to check that problems you have told me about before have been addressed. If I missed some, please tell me again. The drafts should appear on the official Internet Drafts repositories soon, but in the meantime you can fetch them at the URLs below. Changes to the RTP spec: The only changes in this revision of the draft from the previous one were the addition of a reference to RFC 2914 in Section 10 on congestion control and a clarification of splitting RTCP between encrypted and unencrypted packets in Section 9. There are a few items in the main RTP spec still not completed in the interop matrix, but we have commitments for each to be done by the meeting or shortly thereafter. Changes to the A/V profile: o An paragraph further explaining the requirements for congestion control was added to Section 2. *** We agreed to leave the text mostly as is, which I have done, but I've attempted to address Reha Civanlar's argument that we need to specify a timescale, and I tried to reflect Sally Floyd's comments about the nature of the TCP fairness criterion. o Packetization of G.726 audio at rates 40, 24 and 16 kb/s is specified in addition to 32 kb/s, because those have been waiting for an implementation and now we have two. o The mapping of a user pass-phrase string into an encryption key was deleted from Section 2 because two interoperable implementations were not found. o The specification of a two-byte encapsulation for RTP over TCP was deleted because two interoperable implementations were not found. o The audio payload formats 1016, G723, GSM-HR and GSM-EFR were removed because two interoperable implementations were not found. o The video payload formats H263, BT656, MP2T, MP1S, MP2P and BMPEG were removed because two interoperable implementations were not found. In addition to the RTP spec and profile, the RTP MIME registration draft was also updated to bring the H263-2000 parameter definitions in line with recent ITU changes. This draft and the SDP Bandwidth Modifiers for RTCP Bandwidth draft are to go to Proposed Standard. The package of drafts is available at: ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-mime-04.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtcp-bw-03.txt Thanks in advance for your help in reviewing these drafts. -- Steve Casner AVT Co-Chair From rem-conf Fri Mar 09 00:20:41 2001 From rem-conf-request@es.net Fri Mar 09 00:20:40 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bI6v-0001h3-00; Fri, 9 Mar 2001 00:18:53 -0800 Received: from farley.cisco.com (cisco.com) [171.71.153.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bI6u-0001gp-00; Fri, 9 Mar 2001 00:18:52 -0800 Received: from rkumar-ntl.cisco.com ([144.254.252.22]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA06753; Fri, 9 Mar 2001 00:17:51 -0800 (PST) Message-Id: <4.3.2.7.2.20010309002324.00d0b340@farley.cisco.com> X-Sender: rkumar@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 00:23:37 -0800 To: rem-conf@es.net From: Rajesh Kumar Subject: rem-conf@es.net Cc: Error@cisco.com.in.rfc2833? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_41325583==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_41325583==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed AVT group, The following discrepancy was brought to my notice: in rfc2833, Table 6 (Trunk events) has MF S1...S3 assigned to 142...143 Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right. Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group. Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- --=====================_41325583==_.ALT Content-Type: text/html; charset="us-ascii" AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.

 
Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------
--=====================_41325583==_.ALT-- From rem-conf Fri Mar 09 00:24:58 2001 From rem-conf-request@es.net Fri Mar 09 00:24:57 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bI9N-0001vu-00; Fri, 9 Mar 2001 00:21:25 -0800 Received: from farley.cisco.com (cisco.com) [171.71.153.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bI9M-0001hc-00; Fri, 9 Mar 2001 00:21:24 -0800 Received: from rkumar-ntl.cisco.com ([144.254.252.22]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA06896 for ; Fri, 9 Mar 2001 00:20:23 -0800 (PST) Message-Id: <4.3.2.7.2.20010309002536.00ca2780@farley.cisco.com> X-Sender: rkumar@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 00:26:09 -0800 To: rem-conf@es.net From: Rajesh Kumar Subject: Error in rfc2833? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_41477431==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_41477431==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed AVT group, The following discrepancy was brought to my notice: in rfc2833, Table 6 (Trunk events) has MF S1...S3 assigned to 142...143 Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right. Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group. Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- --=====================_41477431==_.ALT Content-Type: text/html; charset="us-ascii" AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.

 
Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------
--=====================_41477431==_.ALT-- From rem-conf Fri Mar 09 00:51:43 2001 From rem-conf-request@es.net Fri Mar 09 00:51:42 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bIYC-0004K4-00; Fri, 9 Mar 2001 00:47:04 -0800 Received: from (ibsweb.ibsinc.co.jp) [210.154.1.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bIYB-0004Ju-00; Fri, 9 Mar 2001 00:47:03 -0800 Received: from RP86 ([126.2.0.59]) by ibsweb.ibsinc.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GQ3WT6L4; Fri, 9 Mar 2001 17:52:43 +0900 Message-ID: <2002890.984127679370@ibsinc.co.jp> Date: Fri, 9 Mar 2001 17:47:59 +0900 (JST) From: =?iso-2022-jp?B?GyRCIUozdCFLJSIlJCEmJVMhPCEmJSglORsoQg==?= Reply-To: xml@ibsinc.co.jp To: rem-conf@es.net Subject: =?iso-2022-jp?B?GyRCI1gjTSNMJV0hPCU/JWslNSUkJUgkciRhGyhC?==?iso-2022-jp?B?GyRCJDYkNyRGGyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset =iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: adToOne version 3.5.9.2 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list $B#X#M#L%]!<%?%k%5%$%H$r$a$6$7$F(B XML$B$N%]!<%?%k%5%$%H$r3+@_CW$7$^$7$?!#El5~H,2&;R;T$N%"%$!&%S!\:Y$O2<5-%5%$%H$r;2>H$7$F(B $B$/$@$5$$!#!K(BBizTech$B$+$i0zMQ!'(B http://biztech.nikkeibp.co.jp/wcs/show/leaf?CID=onair/biztech/comp/123567 $B$3$N$h$&$K4k6H$,%$%s%?!<%M%C%H$K$*$1$k%S%8%M%9$N8@8l$H$7$F(BXML$B$r5^B.$K:NMQ$7;O(B $B$a$F$$$k>u67$,JF9q$G82Cx$K$J$j!":#G/$O9qFb$G$b$3$N798~$O6/$^$k$H;W$o$l$^$9!#(B $BEv%5%$%H$OBgC@$K$b$3$N(BXML$B$N%]!<%?%k%5%$%H$rL\;X$7$F$*$j$^$9!#$b$7?7$7$$%5%$%H(B $B$r8+$F$40U8+$d$4MWK>$,$"$l$P@'Hs$*J9$+$;2<$5$$!#$^$?!"J@e$2$^$9!#(B $B>0!":#2s$N%a!<%k$OJ@ Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wenger-avt-rtcp-feedback-02.txt Date: Fri, 09 Mar 2001 07:36:01 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTCP-based Feedback: Concepts and Message Timing Rules Author(s) : S. Wenger, J. Ott Filename : draft-wenger-avt-rtcp-feedback-02.txt Pages : 21 Date : 08-Mar-01 Real-time media streams are not resilient against packet losses. RTP [1] provides all the necessary mechanisms to restore ordering and timing to properly reproduce a media stream at the recipient. RTP also provides continuous feedback about the overall reception quality >from all receivers -- thereby allowing the sender(s) in the mid-term (in the order of several seconds to minutes) to adapt their coding scheme and transmission behavior to the observed network QoS. However, except for a few payload specific mechanisms [2], RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retro-active FEC, or media-specific mechanisms such as reference picture selection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wenger-avt-rtcp-feedback-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wenger-avt-rtcp-feedback-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-wenger-avt-rtcp-feedback-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wenger-avt-rtcp-feedback-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-wenger-avt-rtcp-feedback-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110858.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 04:58:00 2001 From rem-conf-request@es.net Fri Mar 09 04:57:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM63-0007kX-00; Fri, 9 Mar 2001 04:34:15 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bM62-0007kN-00; Fri, 9 Mar 2001 04:34:14 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11476; Fri, 9 Mar 2001 07:34:11 -0500 (EST) Message-Id: <200103091234.HAA11476@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtcp-bw-03.txt Date: Fri, 09 Mar 2001 07:34:11 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : SDP Bandwidth Modifiers for RTCP Bandwidth Author(s) : S. Casner Filename : draft-ietf-avt-rtcp-bw-03.txt Pages : 6 Date : 08-Mar-01 This document defines an extension to the Session Description Pro- tocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a Real-Time Transport Protocol (RTP) session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-bw-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-bw-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-bw-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-bw-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110718.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 04:58:00 2001 From rem-conf-request@es.net Fri Mar 09 04:57:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM95-0007mQ-00; Fri, 9 Mar 2001 04:37:23 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 14bM93-0007mG-00; Fri, 9 Mar 2001 04:37:21 -0800 Received: from borg.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Mar 2001 12:37:02 +0000 To: Greg Sherwood cc: rem-conf@es.net Subject: Re: Change requested for AMR payload format (draft-ietf-avt-rtp-amr-0 5.txt) In-Reply-To: Your message of "Thu, 08 Mar 2001 14:47:07 PST." <72660A24B978D411BB8A00B0D03DFE01178EC6@misty.packetvideo.com> Date: Fri, 09 Mar 2001 12:38:01 +0000 From: Orion Hodson Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <72660A24B978D411BB8A00B0D03DFE01178EC6@misty.packetvideo.com>Greg Sherwood wri tes: > > After reviewing the current draft of the RTP payload for AMR > (draft-ietf-avt-rtp-amr-05.txt), > I noticed two very significant problems for its use with our streaming > application: > - the required bit stuffing/packing (i.e., no octet alignment) > - no audio frame-level interleaving. Rather than placing frame-level interleaving within a single format it might be better to have a generic frame-level interleaving profile. This way we avoid replicating the same functionality (with subtle differences) in the audio payloads. If this is of interest there is an outline of a draft I intend to submit after the IETF on this at: http://www.cs.ucl.ac.uk/staff/O.Hodson/misc/draft-ietf-avt-audio-interleaving.pdf Comments appreciated, Kind Regards - Orion From rem-conf Fri Mar 09 04:58:02 2001 From rem-conf-request@es.net Fri Mar 09 04:58:02 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM5p-0007jr-00; Fri, 9 Mar 2001 04:34:01 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bM5o-0007jh-00; Fri, 9 Mar 2001 04:34:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11440; Fri, 9 Mar 2001 07:33:57 -0500 (EST) Message-Id: <200103091233.HAA11440@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-dv-audio-03.txt Date: Fri, 09 Mar 2001 07:33:57 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-audio-03.txt Pages : 15 Date : 08-Mar-01 This document specifies the packetization scheme for encapsulating the 12-bit nonlinear, 20-bit linear and 24-bit linear audio data streams into a payload of the Real-time Transport Protocol (RTP). This draft also specifies the way of SDP announcement, when the audio data is preemphasized before sampling. The treatment of preemphasized audio data specified this document could be used in other audio formats such as L16. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-audio-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-audio-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-audio-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-audio-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-audio-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110648.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 04:58:03 2001 From rem-conf-request@es.net Fri Mar 09 04:58:02 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM5n-0007jf-00; Fri, 9 Mar 2001 04:33:59 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bM5l-0007jV-00; Fri, 9 Mar 2001 04:33:57 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11428; Fri, 9 Mar 2001 07:33:53 -0500 (EST) Message-Id: <200103091233.HAA11428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mime-04.txt Date: Fri, 09 Mar 2001 07:33:53 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : MIME Type Registration of RTP Payload Formats Author(s) : S. Casner, P. Hoschka Filename : draft-ietf-avt-rtp-mime-04.txt Pages : 18 Date : 08-Mar-01 This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mime-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mime-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mime-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mime-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110618.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 04:58:03 2001 From rem-conf-request@es.net Fri Mar 09 04:58:02 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM5u-0007k3-00; Fri, 9 Mar 2001 04:34:06 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bM5t-0007jt-00; Fri, 9 Mar 2001 04:34:05 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11452; Fri, 9 Mar 2001 07:34:02 -0500 (EST) Message-Id: <200103091234.HAA11452@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-10.txt,.ps Date: Fri, 09 Mar 2001 07:34:02 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-profile-new-10.txt,.ps Pages : 39 Date : 08-Mar-01 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-new-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110700.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 04:58:03 2001 From rem-conf-request@es.net Fri Mar 09 04:58:03 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bM5y-0007kL-00; Fri, 9 Mar 2001 04:34:10 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bM5x-0007kB-00; Fri, 9 Mar 2001 04:34:09 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11464; Fri, 9 Mar 2001 07:34:06 -0500 (EST) Message-Id: <200103091234.HAA11464@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-09.txt,.ps Date: Fri, 09 Mar 2001 07:34:06 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-09.txt,.ps Pages : 102 Date : 08-Mar-01 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-new-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308110709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308110709.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 09 08:02:17 2001 From rem-conf-request@es.net Fri Mar 09 08:02:16 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bPCS-0000yD-00; Fri, 9 Mar 2001 07:53:04 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bPCP-0000y3-00; Fri, 9 Mar 2001 07:53:02 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id KAA03401; Fri, 9 Mar 2001 10:52:51 -0500 Message-Id: <200103091552.KAA03401@purple.east.isi.edu> To: Rajesh Kumar cc: rem-conf@es.net Subject: Re: Error in rfc2833? In-Reply-To: Message from Rajesh Kumar of "Fri, 09 Mar 2001 00:26:09 PST." <4.3.2.7.2.20010309002536.00ca2780@farley.cisco.com> Date: Fri, 09 Mar 2001 10:52:51 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Rajesh Kumar writes: > >AVT group, > >The following discrepancy was brought to my notice: > >in rfc2833, Table 6 (Trunk events) has > >MF S1...S3 assigned to 142...143 > >Evidently, there are three events (S1, S2, S3) on the left hand side and >only two event number values on the right. > >Have others noticed this problem? What would be a standard, inter-operable >way for the industry to work around it? If we were to assign S1=142 and >S2=143, which number should we assign to S3? > >I request Henning Schulzrinne or Scott Petrack to make a decision and >circulate it to the group. Definitely a bug in the spec. Are there any implementations? What do they do for these and the other events? The choice would seem to be either to move the rest of the table down, fixing the problem in the logical way but changing the definitions of several tones, or to move MF S3 to be at 174. If people have implemented the other tones, we should probably move MF S3. Comments? Colin From rem-conf Fri Mar 09 08:30:48 2001 From rem-conf-request@es.net Fri Mar 09 08:30:47 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bPfq-0001vL-00; Fri, 9 Mar 2001 08:23:26 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bPfn-0001v8-00; Fri, 9 Mar 2001 08:23:24 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA03828 for ; Fri, 9 Mar 2001 11:23:18 -0500 Message-Id: <200103091623.LAA03828@purple.east.isi.edu> To: rem-conf@es.net Subject: DRAFT AVT agenda Date: Fri, 09 Mar 2001 11:23:18 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please send comments, corrections or additions to the working group chairs as soon as possible (and by the end of Monday at the lastest). Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group Agenda Wednesday, 21st March 2001, 15:30 - 17:30 ========================================= Introduction and status update (Casner) 10 draft-ietf-avt-dv-audio-02.txt RTP specification and audio/video profile (Casner/Perkins) 20 draft-ietf-avt-rtp-new-09.txt, .ps draft-ietf-avt-profile-new-10.txt, .ps draft-ietf-avt-rtp-mime-04.txt draft-ietf-avt-rtcp-bw-03.txt draft-ietf-avt-rtp-interop-07.txt draft-ietf-avt-profile-interop-05.txt RTCP Extension for Source Specific Multicast Sessions (Chesterfield) 15 draft-chesterfield-avt-rtcpssm-00.txt Low Delay RTCP Feedback Format (Burmeister) 15 draft-fukunaga-low-delay-rtcp-02.txt RTP Retransmission Payload Format (Burmeister) 15 draft-ietf-avt-rtp-selret-01.txt The Secure Real Time Transport Protocol (Carrara) 15 draft-ietf-avt-srtp-00.txt An RTP Payload Format for Generic FEC with ULP (Li) 15 draft-ietf-avt-ulp-00.txt Thursday, 22nd March 2001, 13:00 - 15:00 ======================================== RTP payload format and file storage format for AMR audio 15 draft-ietf-avt-rtp-amr-05.txt RTP payload format for AMR-WB (Lakaniemi) 15 draft-lakaniemi-avt-amrwb-00.txt An RTP Payload Format for EVRC Speech (Li) 15 draft-ietf-avt-evrc-01.txt RTP payload format for Vorbis (Moffit) 15 draft-moffitt-vorbis-rtp-00.txt RTP Payload Format for MPEG-4 Streams (Gentric) 15 draft-gentric-avt-mpeg4-multipleSL-02.txt RTP payload format for MPEG-4 FlexMultiplexed streams (Roux) 15 draft-curet-avt-rtp-mpeg4-flexmux-00.txt We strongly encourage participants to read all relevent drafts before the meeting, and for those making presentations to assume that the audience has read the draft. Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe the changes from the previous draft, highlight unresolved problems, propose future directions. Authors are also reminded of the contents of section 10 of RFC 2026. In particular, the requirement for disclosure of intellectual property relating to contributions. From rem-conf Fri Mar 09 10:03:26 2001 From rem-conf-request@es.net Fri Mar 09 10:03:25 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bRC9-0004Nc-00; Fri, 9 Mar 2001 10:00:53 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bRC4-0004NF-00; Fri, 9 Mar 2001 10:00:51 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 5C6DE1E038; Fri, 9 Mar 2001 13:00:40 -0500 (EST) Received: from vtpc3 ([135.207.132.105]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id NAA08960; Fri, 9 Mar 2001 13:00:37 -0500 (EST) Message-ID: <00e601c0a8c3$048fdcc0$6984cf87@vtpc3> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Orion Hodson" Cc: References: Subject: Re: Change requested for AMR payload format (draft-ietf-avt-rtp-amr-0 5.txt) Date: Fri, 9 Mar 2001 13:01:50 -0500 Organization: AT&T Labs - Research MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I strongly support having a generic frame-level interleaving profile. This is a "very" common tool being used by many payloads and having a generic format can definitely help making RTP implementations simpler and more uniform. I have two suggestions for improvement: 1. I think, interleaving should not be specific to audio payloads. This may involve just a name change but, some of the field sizes may need to be evaluated for general applicability. 2. This profile could generalize the "redundant coding (RFC 2198)" or Multiple Description Coding mechanisms, where frames redundantly coded with different qualities are "interleaved" for improved loss resilience (e.g., http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg2aac-01.txt ) ---------------------------------------------------------------------------- ------ M. Reha Civanlar Speech & Image Processing Services Research Lab AT&T Labs - Research civanlar@research.att.com ----- Original Message ----- From: "Orion Hodson" To: "Greg Sherwood" Cc: Sent: Friday, March 09, 2001 7:38 AM Subject: Re: Change requested for AMR payload format (draft-ietf-avt-rtp-amr-0 5.txt) > <72660A24B978D411BB8A00B0D03DFE01178EC6@misty.packetvideo.com>Greg Sherwood wri > tes: > > > > After reviewing the current draft of the RTP payload for AMR > > (draft-ietf-avt-rtp-amr-05.txt), > > I noticed two very significant problems for its use with our streaming > > application: > > - the required bit stuffing/packing (i.e., no octet alignment) > > - no audio frame-level interleaving. > > Rather than placing frame-level interleaving within a single format it > might be better to have a generic frame-level interleaving profile. > This way we avoid replicating the same functionality (with subtle > differences) in the audio payloads. > > If this is of interest there is an outline of a draft I intend to > submit after the IETF on this at: > > http://www.cs.ucl.ac.uk/staff/O.Hodson/misc/draft-ietf-avt-audio-interleavin g.pdf > > Comments appreciated, > Kind Regards > - Orion > > > > > > > > > > From rem-conf Fri Mar 09 12:18:17 2001 From rem-conf-request@es.net Fri Mar 09 12:18:15 2001 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14bTE6-00001W-00; Fri, 9 Mar 2001 12:11:02 -0800 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 14bTE3-00001M-00; Fri, 9 Mar 2001 12:11:00 -0800 Received: from flf960r1.ems.att.com ([135.71.244.37]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f29K9LZ09184; Fri, 9 Mar 2001 15:09:21 -0500 (EST) Received: from njb140bh2.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA05866; Fri, 9 Mar 2001 15:06:49 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 15:09:20 -0500 Message-ID: <1B08859602C8D211B66F0000C0769CFA05B2F26B@njc240po03.mt.att.com> From: "Hussain, Arshad, NNAD" To: Rajesh Kumar , rem-conf@es.net Subject: RE: Error in rfc2833? Date: Fri, 9 Mar 2001 15:09:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8D4.D20E2790" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A8D4.D20E2790 Content-Type: text/plain; charset="iso-8859-1" My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else. Arshad Hussain A2-3D17 200 Laurel Ave. S. Middletown, NJ 07748 (732) 420-5915 -----Original Message----- From: Rajesh Kumar [mailto:rkumar@cisco.com] Sent: Friday, March 09, 2001 3:26 AM To: rem-conf@es.net Subject: Error in rfc2833? AVT group, The following discrepancy was brought to my notice: in rfc2833, Table 6 (Trunk events) has MF S1...S3 assigned to 142...143 Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right. Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group. Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- ------_=_NextPart_001_01C0A8D4.D20E2790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

M= y proposal will be to use the next number, i.e. S3=3D144 unless it is = used by some thing else.

<= ![if = !supportEmptyParas]> 

=

Arshad Hussain<= /p>

A2-3D17

200 Laurel Ave. S.

Middletown, NJ 07748

(732) 420-5915

=  

=

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Friday, March 09, = 2001 3:26 AM
To: rem-conf@es.net
Subject: Error in = rfc2833?

 

AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side = and only two event number values on the right.

Have others noticed this problem? What would be a standard, = inter-operable way for the industry to work around it? If we were to assign S1=3D142 and = S2=3D143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision = and circulate it to the group.

 
Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------- =

------_=_NextPart_001_01C0A8D4.D20E2790-- From rem-conf Fri Mar 09 12:49:49 2001 From rem-conf-request@es.net Fri Mar 09 12:49:48 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bTnO-0000N0-00; Fri, 9 Mar 2001 12:47:30 -0800 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bTnM-0000MW-00; Fri, 9 Mar 2001 12:47:28 -0800 Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id NAA04545 for ; Fri, 9 Mar 2001 13:47:18 -0700 (MST) Posted-Date: Fri, 9 Mar 2001 13:47:18 -0700 (MST) Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Fri Mar 09 13:47:22 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id NAA09413 for ; Fri, 9 Mar 2001 13:47:06 -0700 (MST) Received: from agcs.com ([130.131.26.189]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA4D85; Fri, 9 Mar 2001 13:47:16 -0700 Message-ID: <3AA94154.6E1E692A@agcs.com> Date: Fri, 09 Mar 2001 13:47:17 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hussain, Arshad, NNAD" CC: Rajesh Kumar , rem-conf@es.net Subject: Re: Error in rfc2833? References: <1B08859602C8D211B66F0000C0769CFA05B2F26B@njc240po03.mt.att.com> Content-Type: multipart/alternative; boundary="------------72493F5CAC10E41D125322E9" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------72493F5CAC10E41D125322E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, that would make life interesting for folks who have already implemented events in the range of 144 and above. Events 144-159 are the ABCD trunking events. I know of several implementations using those that would be impacted by your suggestion. There are probably more out there. It sounds like implementations using MF S1..S3 are just now being considered since nobody has noticed this yet. I propose that we deprecate event numbers 142 and 143 and assign new event numbers for S1..S3 at the end of the current range. That will keep existing implementations from being impacted. Best Regards, Rex Coldren "Hussain, Arshad, NNAD" wrote: > My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else. > > Arshad Hussain > > A2-3D17 > > 200 Laurel Ave. S. > > Middletown, NJ 07748 > > (732) 420-5915 > > -----Original Message----- > From: Rajesh Kumar [mailto:rkumar@cisco.com] > Sent: Friday, March 09, 2001 3:26 AM > To: rem-conf@es.net > Subject: Error in rfc2833? > > AVT group, > > The following discrepancy was brought to my notice: > > in rfc2833, Table 6 (Trunk events) has > > MF S1...S3 assigned to 142...143 > > Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number > values on the right. > > Have others noticed this problem? What would be a standard, inter-operable way for the industry to > work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? > > I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group. > > > Thanks. > > Rajesh > ------------------------------------- > Dr. Rajesh Kumar, Principal Engineer > Cisco Voice Technology Center > Tel: 408-527-0811, Fax: 408-853-1101 > Epage: mailto:rkumar@epage.cisco.com > ------------------------------------- > --------------72493F5CAC10E41D125322E9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Well, that would make life interesting for folks who have already implemented
events in the range of 144 and above.  Events 144-159 are the ABCD trunking
events.  I know of several implementations using those that would be impacted
by your suggestion.  There are probably more out there.

It sounds like implementations using MF S1..S3 are just now being considered
since nobody has noticed this yet.  I propose that we deprecate event numbers
142 and 143 and assign new event numbers for S1..S3 at the end of the current
range.  That will keep existing implementations from being impacted.

Best Regards,
Rex Coldren

"Hussain, Arshad, NNAD" wrote:

My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else. 

Arshad Hussain

A2-3D17

200 Laurel Ave. S.

Middletown, NJ 07748

(732) 420-5915

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Friday, March 09, 2001 3:26 AM
To: rem-conf@es.net
Subject: Error in rfc2833?

AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.


Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------- 

--------------72493F5CAC10E41D125322E9-- From rem-conf Fri Mar 09 13:18:45 2001 From rem-conf-request@es.net Fri Mar 09 13:18:44 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bUDL-0001cO-00; Fri, 9 Mar 2001 13:14:19 -0800 Received: from farley.cisco.com (cisco.com) [171.71.153.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bUDK-0001Zb-00; Fri, 9 Mar 2001 13:14:18 -0800 Received: from rkumar-ntl.cisco.com (dhcp-171-71-9-122.cisco.com [171.71.9.122]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA29274; Fri, 9 Mar 2001 13:12:40 -0800 (PST) Message-Id: <4.3.2.7.2.20010309131647.00d7a8a0@farley.cisco.com> X-Sender: rkumar@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 13:18:27 -0800 To: coldrenr@agcs.com From: Rajesh Kumar Subject: Re: Error in rfc2833? Cc: "Hussain, Arshad, NNAD" , rem-conf@es.net, cdahm@cisco.com, khouder@cisco.com, bfoster@cisco.com, flemming Andreasen In-Reply-To: <3AA94154.6E1E692A@agcs.com> References: <1B08859602C8D211B66F0000C0769CFA05B2F26B@njc240po03.mt.att.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9090271==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_9090271==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:47 PM 3/9/01 -0700, Rex Coldren wrote: >Well, that would make life interesting for folks who have already implemented >events in the range of 144 and above. Events 144-159 are the ABCD trunking >events. I know of several implementations using those that would be impacted >by your suggestion. There are probably more out there. > >It sounds like implementations using MF S1..S3 are just now being considered >since nobody has noticed this yet. I propose that we deprecate event numbers >142 and 143 and assign new event numbers for S1..S3 at the end of the current >range. That will keep existing implementations from being impacted. I agree with Rex. This will provide maximum regularity with the least upset to other numbers.--Rajesh >Best Regards, >Rex Coldren > >"Hussain, Arshad, NNAD" wrote: >>My proposal will be to use the next number, i.e. S3=144 unless it is used >>by some thing else. >> >>Arshad Hussain >> >>A2-3D17 >> >>200 Laurel Ave. S. >> >>Middletown, NJ 07748 >> >>(732) 420-5915 >> >>-----Original Message----- >>From: Rajesh Kumar [mailto:rkumar@cisco.com] >>Sent: Friday, March 09, 2001 3:26 AM >>To: rem-conf@es.net >>Subject: Error in rfc2833? >> >>AVT group, >> >>The following discrepancy was brought to my notice: >> >>in rfc2833, Table 6 (Trunk events) has >> >>MF S1...S3 assigned to 142...143 >> >>Evidently, there are three events (S1, S2, S3) on the left hand side and >>only two event number values on the right. >> >>Have others noticed this problem? What would be a standard, >>inter-operable way for the industry to work around it? If we were to >>assign S1=142 and S2=143, which number should we assign to S3? >> >>I request Henning Schulzrinne or Scott Petrack to make a decision and >>circulate it to the group. >> >> >>Thanks. >> >>Rajesh >>- Thanks. Rajesh ------------------------------------------------ Dr. Rajesh Kumar, Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------------------ --=====================_9090271==_.ALT Content-Type: text/html; charset="us-ascii" At 01:47 PM 3/9/01 -0700, Rex Coldren wrote:
Well, that would make life interesting for folks who have already implemented
events in the range of 144 and above.  Events 144-159 are the ABCD trunking
events.  I know of several implementations using those that would be impacted
by your suggestion.  There are probably more out there.

It sounds like implementations using MF S1..S3 are just now being considered
since nobody has noticed this yet.  I propose that we deprecate event numbers
142 and 143 and assign new event numbers for S1..S3 at the end of the current
range.  That will keep existing implementations from being impacted.


I agree with Rex. This will provide maximum regularity with the least upset to other numbers.--Rajesh


Best Regards,
Rex Coldren

"Hussain, Arshad, NNAD" wrote:
My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else.

Arshad Hussain

A2-3D17

200 Laurel Ave. S.

Middletown, NJ 07748

(732) 420-5915

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Friday, March 09, 2001 3:26 AM
To: rem-conf@es.net
Subject: Error in rfc2833?

AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.


Thanks.

Rajesh
-

Thanks.

Rajesh
------------------------------------------------
Dr. Rajesh Kumar, Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------------------

--=====================_9090271==_.ALT-- From rem-conf Fri Mar 09 14:02:58 2001 From rem-conf-request@es.net Fri Mar 09 14:02:57 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14bUw3-0003KG-00; Fri, 9 Mar 2001 14:00:31 -0800 Received: from albatross.prod.itd.earthlink.net [207.217.120.120] by mail1.es.net with esmtp (Exim 1.81 #2) id 14bUw2-0003K6-00; Fri, 9 Mar 2001 14:00:30 -0800 Received: from mborden.tollbridgetech.com (dialup-63.214.117.85.Boston1.Level3.net [63.214.117.85]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id OAA04289; Fri, 9 Mar 2001 14:00:22 -0800 (PST) Message-Id: <4.3.2.7.2.20010309165603.00ce4e70@mail.earthlink.net> X-Sender: mbordentb@earthlink.net@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 17:00:19 -0500 To: coldrenr@agcs.com, "Hussain, Arshad, NNAD" From: Marty Borden Subject: Re: Error in rfc2833? Cc: Rajesh Kumar , rem-conf@es.net In-Reply-To: <3AA94154.6E1E692A@agcs.com> References: <1B08859602C8D211B66F0000C0769CFA05B2F26B@njc240po03.mt.att.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree.  Rex's approach is sound.
marty


At 03:47 PM 03/09/01, Rex Coldren wrote:
Well, that would make life interesting for folks who have already implemented
events in the range of 144 and above.  Events 144-159 are the ABCD trunking
events.  I know of several implementations using those that would be impacted
by your suggestion.  There are probably more out there.

It sounds like implementations using MF S1..S3 are just now being considered
since nobody has noticed this yet.  I propose that we deprecate event numbers
142 and 143 and assign new event numbers for S1..S3 at the end of the current
range.  That will keep existing implementations from being impacted.

Best Regards,
Rex Coldren

"Hussain, Arshad, NNAD" wrote:
My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else.

Arshad Hussain

A2-3D17

200 Laurel Ave. S.

Middletown, NJ 07748

(732) 420-5915

-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Friday, March 09, 2001 3:26 AM
To: rem-conf@es.net
Subject: Error in rfc2833?

AVT group,

The following discrepancy was brought to my notice:

in rfc2833, Table 6 (Trunk events) has

MF S1...S3 assigned to 142...143

Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number values on the right.

Have others noticed this problem? What would be a standard, inter-operable way for the industry to work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3?

I  request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group.


Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------
From rem-conf Sun Mar 11 09:53:12 2001 From rem-conf-request@es.net Sun Mar 11 09:53:11 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14c9lG-00009l-00; Sun, 11 Mar 2001 09:36:06 -0800 Received: from (www5.chinadns.com) [211.99.199.74] by mail1.es.net with smtp (Exim 1.81 #2) id 14c9lE-00009b-00; Sun, 11 Mar 2001 09:36:04 -0800 Received: (qmail 28505 invoked from network); 11 Mar 2001 17:38:46 -0000 Received: from unknown (HELO localhost) (211.96.141.118) by 211.99.199.74 with SMTP; 11 Mar 2001 17:38:46 -0000 X-Sender: reducer@cngoldline.com From: Kathy To: rem-conf@es.net Date: Mon, 12 Mar 2001 01:41:21 +0800 Subject: mechanical speed reducer. Reply-To: reducer@cngoldline.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir / Madam, It is a great honour to have the chance to introduce our company(Guangdong Xingguang Mechnical &Electric Co.Ltd.) and our main products. Guangdong Xingguang Mechnical &Electric Co.Ltd. is located in Guangdong province mainland China,engaged in manufacting mechanical speed reducer. Our main three series reducers are WJ series of worm reducer, JWB-X series and JWB-XB Series. They all own advantages of good appearance,small column,quick radiating,flexible mounting,stable transmissionand low noise level. The WJ warm reducers conform to GB/T 19002-1994 idt ISO9002-1994,which includes WJ basic worm reducer, WJ build-up worm reducer, WJ worm reducer with variator,and WJ gear worm reducer. JWB-X series infinite speed reducer conform to JB/T6950-93,it is the best choice for auto manufact line such as ceramic, berverage,food,electronic,medicine,chemical and textile field. JWB-XB series full-close infinite speed reducer is superior to JB/T6950-93,besides above advantages,which own no-leakage,full-close etc,specialized in environment protection transmission equipment. if you are interested in our products, please contact us withou hesitate. yours truely Kathy. Guangdong Xingguang Mechnical &Electric Co.Ltd Tel: £º£¨86 757£©2270276 2710876 Fax: £¨86 757£©2272927 E-mail:reducer@cngoldline.com http://www.xgc.com.cn Contact person: Ms.Kathy From rem-conf Sun Mar 11 16:15:35 2001 From rem-conf-request@es.net Sun Mar 11 16:15:34 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cFvB-0006bi-00; Sun, 11 Mar 2001 16:10:45 -0800 Received: from mailhost.ppra.fr (mwall.ppra.fr) [62.161.232.93] (mailer) by mail1.es.net with esmtp (Exim 1.81 #2) id 14cFuK-0006au-00; Sun, 11 Mar 2001 16:09:56 -0800 Received: by mwall.ppra.fr; id EAA24653; Mon, 12 Mar 2001 04:08:49 +0100 (CET) From: Received: from ip205.schiller-park9.il.pub-ip.psi.net(38.31.126.205) by mwall.ppra.fr via smap (4.0) id xma024512; Mon, 12 Mar 2001 04:03:45 +0100 Message-ID: <000017700fd3$000036c8$000019d4@pob23uifesi.cic.org.ar ([61.48.316.4]) by ris5s2.daidacent14sere1.chua.cesaimtv.net.ie (8.9.1a/8.9.1/1.0) with SMTP id NAE11975 ([217.45.256.4])> To: Subject: Excellent News For USA Homeowners! Date: Sun, 11 Mar 2001 14:31:40 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: whpost10986@ahtech.com.cn X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Lender

The Lender's Network Mortgage Specialists =

<= font color=3D"#FFFFFF">For U.S.A. Homeowners Only
Interest Rates have Dropped....Start Saving Now!

We Shop The Best Loan For You!

The Lenders Network is = a 100% free service which lets you shop for a mortgage conveniently and securely from the comf= ort of your home. Using our vast network of lenders across the U.S., we will search our database of loan programs for the best loans that fit your need= s.  Even if you're currently working with another lender or have been turned down before, we can still help. 

Our loan programs can get you the cash you need for:

  • Debt Consolidation
  • 2nd Mortgage
  • Refinance
  • Credit Repair
  • Home Improvement
  • New Car
  • Dream Vacation
  • College Tuition
  • To start a new business ..and much, much more!

Funding borr= owers with less than perfect credit is our specialty!

W= e can get you the loan you need. 
Regardless of whether you have good or bad credit, we can help you.

Ready to get started? 
Simply fill out the our 60 second form, and we= 'll begin shopping for your loan.
  
It's that easy!  We Make the Lenders Compete for Y= OUR Business!

Please complete this form.
Our loan specialist will be contacting you at your convenience.
Thank You.

 
Contact Information: * Required Info
Name: *
Address: *
City: *
State (USA Only): *
Zip/Postal Code: *<= /td>
Home Phone:  *
Work Phone: *
Email Address: *
Best Time to Call:
Do You Own Your Home?: Mobile Homes DO NOT Qualify
Property Value: *
Property Type:
Purchase Price: *
Year Acquired: *
1st Mortgage Balance Owed: *
1st Mortgage Interest Rate: *
Is 1st Adjustable or Fixed?: *
2nd Mortgage Balance Owed:
Amount You Wish To Borrow: *
Employer:
Monthly Gross Household Income: *
Mon= thly Debt:: 
Credit Rating: *
Loan Interested In: *

 

Removal Instructions
Click on the below link to be exclude from further communication.
Click= Here

From rem-conf Sun Mar 11 19:12:59 2001 From rem-conf-request@es.net Sun Mar 11 19:12:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cIhC-0002NE-00; Sun, 11 Mar 2001 19:08:30 -0800 Received: from (ms.samsung.com) [211.45.29.136] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cIhA-0002N4-00; Sun, 11 Mar 2001 19:08:28 -0800 Received: from bright ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id GA2DWI00.A69 for ; Mon, 12 Mar 2001 12:05:06 +0900 From: chjkim@samsung.com To: "Rtp" Subject: Some questions on RTP/RTCP Date: Mon, 12 Mar 2001 12:10:05 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0AAED.5F6E9E70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0AAED.5F6E9E70 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIEknbSBDaGVvbCBKdSwgS2ltLCBhbmQgc3R1ZHlpbmcgUlRQL1JUQ1Agd2l0aCBtcGVn LTQgdHJhbnNmZXIoYmVnaW5uZXIgaW4gdGhpcyBhcmVhKS4NCg0KSSdtIHNvcnJ5IHRvIGRpc3R1 cmIgeW91LCBidXQgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gUlRQL1JUQ1AsIEkg d2FudCBzb21lIGhlbHAgZnJvbSB5b3UuDQoNCjEuIE9uIFNTUkMNCklzIHRoZSBTU1JDIHNvbWV0 aGluZyB0byBpZGVudGlmeSB0aGUgcGFydGljaXBhbnRzKHNlbmRlcnMpIGluIGEgc2Vzc2lvbiBv ciB0aGUgZGF0YSB0byBiZSB0cmFuc3BlcmVkIGF0IG9uZSB0aW1lPyBJZiBpdCBpcyB0byBpZGVu dGlmeSBwYXJ0aWNpcGFudHMsIGRvIHRoZSBwYXJ0aWNpcGFudHMgaW4gYSBzZXNzaW9uIGhhdmUg b3duIFNTUkM/IG9yIGlmIHRvIGlkZW50aWZ5IHRoZSBkYXRhLCBpcyB0aGUgU1NSQyBpbml0aWFs aXplZCBhdCByYW5kb20gYXQgZXZlcnkgdGltZSBvZiB0cmFuc2ZlcnJpbmcgZGF0YT8NCg0KMi4g T24gUlRDUCBwZXJpb2QNCkkgd2FudCB0byBrbm93IHRoZSBwZXJpb2QgdG8gdHJhbnNmZXIgdGhl IFJUQ1AgcGFja2V0LiBJbiBhIGJvb2soIklQIHRlbGVwaG9ueSwgYnkgT2xpdmVyIEhlcnNlbnQs IGV0IGFsLiksIHNlbmRpbmcgcmF0ZSBpcyByYW5kb21pemVkIGJ5IGEgZmFjdG9yIDAuNX4xLjUs IHdoYXQgZG9lcyBpdCBtZWFucz8gQW5kIHdoYXQgZG9lcyBpdCBtZWFucyB0aGF0IFJUQ1AgY2hh bm5lbCBpcyBzaGFyZWQ/IElmIHRoZSBSVENQIGNoYW5uZWwgaXMgc2hhcmVkIHdpdGggYWxsIHRo ZSBwYXJ0aWNpcGFudHMsIHRoZSBzZW5kaW5nIHJhdGUgaXMgbGltaXRlZCBzbyBtdWNoLg0KDQpZ b3VyIHJlcGx5IHdpbGwgYmUgdmVyeSBoZWxwZnVsIHRvIG1lLCB0aGFua3MgaW4gYWR2YW5jZS4N Cg0KU2luY2VyZWx5DQoNCkNoZW9sIEp1Lg0K ------=_NextPart_000_0014_01C0AAED.5F6E9E70 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0xMTM1MDQwMDEtMTIwMzIwMDE+PFNQQU4g DQpjbGFzcz01NjAwNDA4MDMtMTIwMzIwMDE+SGVsbG8sIDwvU1BBTj48L1NQQU4+PFNQQU4gY2xh c3M9MTEzNTA0MDAxLTEyMDMyMDAxPkknbSANCkNoZW9sIEp1LCBLaW08U1BBTiBjbGFzcz01NjAw NDA4MDMtMTIwMzIwMDE+LCA8L1NQQU4+YW5kIHN0dWR5aW5nIA0KUlRQL1JUQ1AmbmJzcDt3aXRo IG1wZWctNCB0cmFuc2ZlcjxTUEFOIGNsYXNzPTU2MDA0MDgwMy0xMjAzMjAwMT4oYmVnaW5uZXIg aW4gDQp0aGlzIGFyZWEpPC9TUEFOPi48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz0xMTM1MDQwMDEtMTIwMzIwMDE+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48L1NQQU4+PFNQQU4g Y2xhc3M9MTEzNTA0MDAxLTEyMDMyMDAxPjxGT05UIA0Kc2l6ZT0yPkknbSBzb3JyeSB0byBkaXN0 dXJiIHlvdSwgYnV0IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyByZWxhdGVkIHRvIFJUUC9SVENQLCAN Ckkgd2FudCBzb21lIGhlbHAgZnJvbSB5b3UuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9MTEzNTA0MDAxLTEyMDMyMDAxPjxTUEFOIGNsYXNzPTgwMjExMjgwMi0xMDAzMjAw MT48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9MTEzNTA0MDAxLTEyMDMyMDAxPjxTUEFOIGNsYXNzPTgwMjExMjgwMi0xMDAz MjAwMT48Rk9OVCANCnNpemU9Mj4xLiBPbiBTU1JDPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48U1BBTiBjbGFzcz04MDIxMTI4 MDItMTAwMzIwMDE+PEZPTlQgDQpzaXplPTI+SXMgdGhlIFNTUkMgc29tZXRoaW5nIHRvIGlkZW50 aWZ5IHRoZSBwYXJ0aWNpcGFudHMoc2VuZGVycykgaW4gYSBzZXNzaW9uIA0Kb3IgdGhlIGRhdGEg dG8gYmUgdHJhbnNwZXJlZCBhdCBvbmUgdGltZT8gSWYgaXQgaXMgdG8gaWRlbnRpZnkgcGFydGlj aXBhbnRzLCBkbyANCnRoZSBwYXJ0aWNpcGFudHMgaW4gYSBzZXNzaW9uIGhhdmUgb3duIFNTUkM/ IG9yIGlmIHRvIGlkZW50aWZ5IHRoZSBkYXRhLCBpcyB0aGUgDQpTU1JDIGluaXRpYWxpemVkIGF0 IHJhbmRvbSBhdCBldmVyeSZuYnNwO3RpbWUgb2YgdHJhbnNmZXJyaW5nIA0KZGF0YT88L0ZPTlQ+ PC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTEzNTA0MDAxLTEyMDMyMDAx PjxTUEFOIGNsYXNzPTgwMjExMjgwMi0xMDAzMjAwMT48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PC9T UEFOPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MTEzNTA0MDAxLTEyMDMy MDAxPjxTUEFOIGNsYXNzPTgwMjExMjgwMi0xMDAzMjAwMT48Rk9OVCANCnNpemU9Mj4yLiBPbiBS VENQIHBlcmlvZDwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0x MTM1MDQwMDEtMTIwMzIwMDE+PFNQQU4gY2xhc3M9ODAyMTEyODAyLTEwMDMyMDAxPjxGT05UIA0K c2l6ZT0yPkkgd2FudCB0byBrbm93IHRoZSBwZXJpb2QgdG8gdHJhbnNmZXIgdGhlIFJUQ1AgcGFj a2V0LiBJbiBhIGJvb2soIklQIA0KdGVsZXBob255LCBieSBPbGl2ZXIgSGVyc2VudCwgZXQgYWwu KSwgc2VuZGluZyByYXRlIGlzIHJhbmRvbWl6ZWQgYnkgYSBmYWN0b3IgDQowLjV+MS41LCB3aGF0 IGRvZXMgaXQgbWVhbnM/IEFuZCB3aGF0IGRvZXMgaXQgbWVhbnMgdGhhdCBSVENQIGNoYW5uZWwg aXMgc2hhcmVkPyANCklmIHRoZSBSVENQIGNoYW5uZWwgaXMgc2hhcmVkIHdpdGggYWxsIHRoZSBw YXJ0aWNpcGFudHMsIHRoZSBzZW5kaW5nIHJhdGUgaXMgDQpsaW1pdGVkIHNvIG11Y2guPC9GT05U PjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0xMTM1 MDQwMDEtMTIwMzIwMDE+PFNQQU4gDQpjbGFzcz04MDIxMTI4MDItMTAwMzIwMDE+PFNQQU4gDQpj bGFzcz01NjAwNDA4MDMtMTIwMzIwMDE+PC9TUEFOPjwvU1BBTj48L1NQQU4+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0xMTM1MDQwMDEtMTIwMzIwMDE+PFNQQU4gY2xhc3M9 ODAyMTEyODAyLTEwMDMyMDAxPjxGT05UIA0Kc2l6ZT0yPllvdXIgcmVwbHkgd2lsbCBiZSB2ZXJ5 IGhlbHBmdWwgdG8gbWUsIHRoYW5rcyBpbiANCmFkdmFuY2UuPC9GT05UPjwvU1BBTj48L1NQQU4+ PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48U1BBTiBjbGFzcz04 MDIxMTI4MDItMTAwMzIwMDE+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwvU1BBTj48L1NQQU4+Jm5i c3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48U1BBTiBjbGFz cz04MDIxMTI4MDItMTAwMzIwMDE+PEZPTlQgDQpzaXplPTI+U2luY2VyZWx5PC9GT05UPjwvU1BB Tj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48U1BB TiBjbGFzcz04MDIxMTI4MDItMTAwMzIwMDE+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwvU1BBTj48 L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTExMzUwNDAwMS0xMjAzMjAwMT48 U1BBTiBjbGFzcz04MDIxMTI4MDItMTAwMzIwMDE+PEZPTlQgDQpzaXplPTI+Q2hlb2wgSnUuPC9G T05UPjwvU1BBTj48L1NQQU4+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0014_01C0AAED.5F6E9E70-- From rem-conf Sun Mar 11 19:44:16 2001 From rem-conf-request@es.net Sun Mar 11 19:44:15 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cJEC-0003Tn-00; Sun, 11 Mar 2001 19:42:36 -0800 Received: from (ms.samsung.com) [211.45.29.136] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cJEA-0003TV-00; Sun, 11 Mar 2001 19:42:34 -0800 Received: from bright ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id GA2FHG00.F7X for ; Mon, 12 Mar 2001 12:39:16 +0900 From: chjkim@samsung.com To: "Rtp" Subject: Some questions on RTP/RTCP... Date: Mon, 12 Mar 2001 12:44:14 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list KHJlLXNlbnQgaW4gdGV4dCBmb3JtYXQpDQoNCkhlbGxvLCBJJ20gQ2hlb2wgSnUsIEtpbSwgYW5k IHN0dWR5aW5nIFJUUC9SVENQIHdpdGggbXBlZy00IHRyYW5zZmVyKGJlZ2lubmVyIGluIHRoaXMg YXJlYSkuDQoNCkknbSBzb3JyeSB0byBkaXN0dXJiIHlvdSwgYnV0IEkgaGF2ZSBzb21lIHF1ZXN0 aW9ucyByZWxhdGVkIHRvIFJUUC9SVENQLCBJIHdhbnQgc29tZSBoZWxwIGZyb20geW91Lg0KDQox LiBPbiBTU1JDDQpJcyB0aGUgU1NSQyBzb21ldGhpbmcgdG8gaWRlbnRpZnkgdGhlIHBhcnRpY2lw YW50cyhzZW5kZXJzKSBpbiBhIHNlc3Npb24gb3IgdGhlIGRhdGEgdG8gYmUgdHJhbnNwZXJlZCBh dCBvbmUgdGltZT8gSWYgaXQgaXMgdG8gaWRlbnRpZnkgcGFydGljaXBhbnRzLCBkbyB0aGUgcGFy dGljaXBhbnRzIGluIGEgc2Vzc2lvbiBoYXZlIG93biBTU1JDPyBvciBpZiB0byBpZGVudGlmeSB0 aGUgZGF0YSwgaXMgdGhlIFNTUkMgaW5pdGlhbGl6ZWQgYXQgcmFuZG9tIGF0IGV2ZXJ5IHRpbWUg b2YgdHJhbnNmZXJyaW5nIGRhdGE/DQoNCjIuIE9uIFJUQ1AgcGVyaW9kDQpJIHdhbnQgdG8ga25v dyB0aGUgcGVyaW9kIHRvIHRyYW5zZmVyIHRoZSBSVENQIHBhY2tldC4gSW4gYSBib29rKCJJUCB0 ZWxlcGhvbnksIGJ5IE9saXZlciBIZXJzZW50LCBldCBhbC4pLCBzZW5kaW5nIHJhdGUgaXMgcmFu ZG9taXplZCBieSBhIGZhY3RvciAwLjV+MS41LCB3aGF0IGRvZXMgaXQgbWVhbnM/IEFuZCB3aGF0 IGRvZXMgaXQgbWVhbnMgdGhhdCBSVENQIGNoYW5uZWwgaXMgc2hhcmVkPyBJZiB0aGUgUlRDUCBj aGFubmVsIGlzIHNoYXJlZCB3aXRoIGFsbCB0aGUgcGFydGljaXBhbnRzLCB0aGUgc2VuZGluZyBy YXRlIGlzIGxpbWl0ZWQgc28gbXVjaC4NCg0KWW91ciByZXBseSB3aWxsIGJlIHZlcnkgaGVscGZ1 bCB0byBtZSwgdGhhbmtzIGluIGFkdmFuY2UuDQoNClNpbmNlcmVseQ0KDQpDaGVvbCBKdS4= From rem-conf Sun Mar 11 20:31:40 2001 From rem-conf-request@es.net Sun Mar 11 20:31:39 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cJvv-0004yo-00; Sun, 11 Mar 2001 20:27:47 -0800 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cJvt-0004ye-00; Sun, 11 Mar 2001 20:27:45 -0800 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02981; Sun, 11 Mar 2001 23:30:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 11 Mar 2001 23:29:49 -0500 Message-ID: From: Jonathan Rosenberg To: "'chjkim@samsung.com'" , Rtp Subject: RE: Some questions on RTP/RTCP... Date: Sun, 11 Mar 2001 23:29:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: chjkim@samsung.com [mailto:chjkim@samsung.com] > Sent: Sunday, March 11, 2001 10:44 PM > To: Rtp > Subject: Some questions on RTP/RTCP... > > > (re-sent in text format) > > Hello, I'm Cheol Ju, Kim, and studying RTP/RTCP with mpeg-4 > transfer(beginner in this area). > > I'm sorry to disturb you, but I have some questions related > to RTP/RTCP, I want some help from you. > > 1. On SSRC > Is the SSRC something to identify the participants(senders) > in a session or the data to be transpered at one time? If it > is to identify participants, do the participants in a session > have own SSRC? or if to identify the data, is the SSRC > initialized at random at every time of transferring data? The SSRC identifies the participants. As a result, each have their own SSRC. Its value is chosen randomly when a user joins a session. As there is a possibility that the value chosen is already in use, RTP specifies a collision algorithm to detect this case. The result is that the user will change the value of their SSRC. > > 2. On RTCP period > I want to know the period to transfer the RTCP packet. In a > book("IP telephony, by Oliver Hersent, et al.), sending rate > is randomized by a factor 0.5~1.5, what does it means? It means that the interval between successive RTCP packets is always changing. Every time an RTCP packet is sent, the participant chooses a number between 2.5 and 7.5 seconds (assuming small group size), and sets a timer to that value. When the timer expires, the packet is sent. This algorithm is somewhat more complex for larger multicast groups. And > what does it means that RTCP channel is shared? If the RTCP > channel is shared with all the participants, the sending rate > is limited so much. Correct. If there are 1000 participants, each sends at 1/1000 of the total RTCP rate. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From rem-conf Sun Mar 11 21:42:47 2001 From rem-conf-request@es.net Sun Mar 11 21:42:46 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cL2I-0006e7-00; Sun, 11 Mar 2001 21:38:26 -0800 Received: from swan.prod.itd.earthlink.net [207.217.120.123] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cL2E-0006df-00; Sun, 11 Mar 2001 21:38:23 -0800 Received: from runbox.com (1Cust156.tnt71.nyc3.da.uu.net [63.59.76.156]) by swan.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA03758 for ; Sun, 11 Mar 2001 21:38:19 -0800 (PST) From: tyrrert23@runbox.com Date: Mon, 12 Mar 2001 00:38:13 -0500 Reply-To: please.tell.me.more@pobox.com Message-ID: To: rem-conf@es.net Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+ Choices! Up to $81. 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 With your first purchase of any size of any new or renewal subscription AT OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay us and will even go back 6 months later if you find a better deal and refund you the difference!); customers living overseas pay only for FPH (foreign postage & handling) on the free subscription. ____________________________________________________________ FOR MORE INFO: Just fill out the below form and return to us via email, with the subject line of "TELL ME MORE" at: please.tell.me.more@pobox.com ____________________________________________________________ TO BE REMOVED FROM OUR LIST: Just send a blank email message with the subject line of: "REMOVE" from the email address that you would like to have removed to: please.tell.me.more@pobox.com ____________________________________________________________ Remove requests will be immediately honored and requests for more information will be fulfilled within 24 hours. ____________________________________________________________ ***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the email bounces due to our servers being overloaded from those replying, or if it bounces for any other reason, then just fax us at: 1-602-294-5643 in the USA or write us via smail at: or send via smail (first class mail or airmail) to: Tempting Tear-Outs / Att. Free-catalogue-by-email Dept PMB 200 3835 Richmond Ave. Staten Island NY 10312-3828 USA ____________________________________________________________ When replying for more information, your subject line must say "TELL ME MORE" and the body of your message must include only this form, completely filled out*: (*If you can't figure out how to cut and past this text, just type it out in the same format): *------------cut here/begin-------------------------------------------* ***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the email bounces due to our servers being overloaded from those replying, or if it bounces for any other reason, then just fax us at: 1-602-294-5643 in the USA Yes, please send me more info. I realize I am not committing myself to buying anything at this time and I would just like more info on the offer and a FREE copy of your magazine subscription catalogue. Here are my details: 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 031001-ls 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, 712K 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 ~712K - 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. 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 AND THE FREE OFFER ITSELF: 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 $81.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 email, 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 marketing & consulting rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, 3835 Richmond Ave. #200, Staten Island NY 10312-3828, USA. This email message has been sent to you by: Tempting Tear-Outs, 3835 Richmond Ave. #200, Staten Island NY 10312-3828, USA. From rem-conf Sun Mar 11 21:56:36 2001 From rem-conf-request@es.net Sun Mar 11 21:56:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cLIM-0007kZ-00; Sun, 11 Mar 2001 21:55:02 -0800 Received: from iisc.ernet.in [144.16.64.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cLIK-0007kN-00; Sun, 11 Mar 2001 21:55:01 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id LAA66222 for ; Mon, 12 Mar 2001 11:30:09 +0530 (IST) Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id LAA21297; Mon, 12 Mar 2001 11:24:35 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200103120554.LAA21297@eis.iisc.ernet.in> Subject: Interactive Telephony To: rem-conf@es.net Date: Mon, 12 Mar 2001 11:24:35 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am contemplating on the following observation regarding Voice telephony. Can you please let me know if it is OK ? I hope it is fine to discuss it on this mailing list. While it is true that IP telephony recommends a strict delay bounds to have any sensible conversations, there are occasions during the conversation wherein one of the parties dominates. During such occasions, we can treat the session to be one way. One of the benefits of finding these is we can put relaxations on the playout delay at the receiver and ensure that the audio is played out continuously without breaks. If we can *somehow* detect the one-wayness do you think we can improve the voice quality ? I appreciate your feedback on this. Thanks for your patience. Regards Anand From rem-conf Sun Mar 11 22:17:47 2001 From rem-conf-request@es.net Sun Mar 11 22:17:46 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cLbK-00011c-00; Sun, 11 Mar 2001 22:14:38 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cLbJ-00011S-00; Sun, 11 Mar 2001 22:14:37 -0800 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA24986; Sun, 11 Mar 2001 23:14:32 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id XAA26793; Sun, 11 Mar 2001 23:09:46 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id AAA17565; Mon, 12 Mar 2001 00:14:25 -0600 (CST) Received: from cig.mot.com (t-il01ac-port21.corp.mot.com [199.5.169.223]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id AAA21942; Mon, 12 Mar 2001 00:14:23 -0600 (CST) Message-Id: <200103120614.AAA21942@agevole.cig.mot.com> Date: Mon, 12 Mar 2001 00:18:58 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Sherwood CC: "'rem-conf@es.net'" Subject: Re: Change requested for AMR payload format (draft-ietf-avt-rtp-amr-05.txt) References: <72660A24B978D411BB8A00B0D03DFE01178EC6@misty.packetvideo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, all, Greg's comments below make me feel more strongly that the addition of the "I" flag to the classic AMR format is indeed a sensible thing to do. By adding the "I" flag to the classic AMR we will not only solve Greg's audio frame-level interleaving problem, but also eliminate the need of the AMR-WB format. This is in my opinion a very elegant solution to both AMR-NB and AMR-WB. I understand Colin's concern but I don't think adding this will cause any significant delay to the AMR draft. After all frame-level interleaving is a well defined and widely used technology by many codecs. It will only take one revision of the draft to get it done, and the changes to the draft should be fairly localized. Apparently people feel this is a desirable feature to add. I'd think that one or two weeks of delay should be well justifiable if we can make the design more complete and useful in the long run. regards, -Qiaobing Greg Sherwood wrote: > I noticed two very significant problems for its use with our streaming > application: > - the required bit stuffing/packing (i.e., no octet alignment) > - no audio frame-level interleaving. > These problems are severe enough for streaming applications that another > payload > format may need to be defined at future date if the current draft is not > modified. > > I have written up the details of the problems and proposed one possible > solution which can > accommodate the current format and allow the octet alignment and frame-level > interleaving. > The proposed solution is certainly not the only one available. Depending on > the desired > tradeoff between bandwidth efficiency and complexity, many different payload > header and > TOC entry formats are possible which accomplish the same goals. > > 1) Packed Format > The bit packed format was proposed to improve bandwidth efficiency, but > the cost is increased complexity for both the sender and > receiver. Consider the case of a video-on-demand server which is serving > hundreds or thousands of simultaneous clients, each accessing different > portions of a stream independently. The server will have to perform > significant data manipulations and copying to translate the frame format > within the file to the packed format proposed for the RTP packet. > With octet-alignment within the RTP packet, the server could directly > utilize > blocks of memory read from the file. > > The amount of bandwidth savings from packing is not enough to outweigh the > complexity cost for many applications. The table below summaries bits > required > for octet-alignment for the AMR audio frames according to mode. > > total > AMR Mode | speech bits | pad bits | percent overhead > ------------------------------------------------------------- > 4.75 | 95 | 1 | 1.05 > 5.15 | 103 | 1 | 0.97 > 5.9 | 118 | 2 | 1.69 > 6.7 | 134 | 2 | 1.49 > 7.4 | 148 | 4 | 2.70 > 7.95 | 159 | 1 | 0.63 > 10.2 | 204 | 4 | 1.96 > 12.2 | 244 | 4 | 1.63 > SID | 39 | 1 | 2.56 > > To octet align the payload header, which occurs once per packet, it would > need to be > extended from 6 to 8 bits. Similarly, > each table of contents entry (one per audio frame) would need to be extended > from 6 to 8 bits. The > worst-case percentage overhead compared to the packed format occurs when a > packet (with no CRC in the > TOC entry) contains a single 7.4 kpbs AMR frame giving an overhead of 5%. > To put that number in perspective, the > RTP headers without any header compression add an overhead of 60%. Clearly > in the typical case, several > audio frames will be placed in a single packet to reduce the packet header > overhead. As more frames are > added, the overhead gets closer to the numbers for the AMR bits alone > (worst-case is about 3.8% overhead counting > the TOC entry overhead and frame overhead for 7.4 kbps mode). > > Along these lines payload formats for other speech codecs such as EVRC > (see draft-ietf-avt-evrc-01.txt) and PureVoice (see RFC 2658) use an > octet-aligned format. > > 2) Frame-level Interleave. > The draft introduces an optional bit-level interleave to provide some error > resilience in the presence of certain bit error patterns (for link layers > that pass up packets > with errors). However, it is just as important to have error resilience in > the presence of > packet loss. For many systems, the only errors they will experience is > packet loss (i.e., no bit > errors) due to the behavior of the network stack. Frame level interleaving > is a well-known > and proven method for improving error resilience. Many audio and speech > payload formats > have mechanisms defined for frame level interleaving including: > AAC (draft-ietf-avt-rtp-mpeg2aac-01.txt), AMR-WB > (draft-lakaniemi-avt-amrwb-00.txt), > EVRC (draft-ietf-avt-evrc-01.txt), MP3 (draft-ietf-avt-rtp-mp3-06.txt), and > PureVoice (RFC 2658). > The interleaving reduces the impact of a packet loss. A mechanism similar > to that described in > AMR-WB (draft-lakaniemi-avt-amrwb-00.txt) is probably a good candidate since > the payload formats > are otherwise identical. > > 3) Proposed modifications. > > The best solution may be to change to an octet-aligned format given the > amount of > bandwidth that can be saved by packing. However, if there are compelling > applications where > the bit packing is critical, perhaps the format can be modified to allow > both octet-aligned > and packed formats. One possible method of supporting both with minimal > impact to the current draft, is to > augment the payload header by 2 bits to indicate bit-level packing and > frame-level interleaving. > The payload header would change to (the exact order of the bits is not > important so it could > be changed as needed): > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |S|C|R|B|I| CMR | > +-+-+-+-+-+-+-+-+ > > where > B (1 bit): indicates whether the payload is packed (i.e., no octet > alignment). The > bit packed format should only be used if support is > indicated. > I (1 bit): Indicates the presence of frame-level interleaving. If > the bit is set > then an optional interleave header would follow the > payload header > with the format described in the AMR-WB proposal > (draft-lakaniemi-avt-amrwb-00.txt). > > If the payload is octet-aligned then all TOC entries and AMR frames would be > padded to the > next octet boundary. > > For the bit packed format, as in the current draft, the only addition > is the extra two bits in the payload header which may extend the payload by > up to 1 octet > depending on how many bits were needed to pad the payload to an octet > boundary. > However, the typical case is only a few extra bits. When robust sorting is > used, the bit packed > format would always be used. > > Please keep in mind that if the additional octet is completely unacceptable > for some application > there are many ways to tweak the payload header and TOC entries to reduce > the overhead in > certain cases. Almost certainly the only case of concern is the single > frame per packet case since > the percentage overhead decreases as more frames are packed together. Even > for the one frame case, the > additional overhead is already in the 3% range. In the one frame per packet > case, the S and I bits are > not relevant. Also variable length coding can be used to code the frame > type (FT) as another alternative. > The point is that there are no fundamental technical barriers to providing > the additional information without > causing unacceptable overhead compared to the current draft format. > > The bit packed mode should only be used if support is signaled via the > optional parameters described > in section 8.3 (MIME Registration) of the draft. A flag similar to the > existing 'crc' and > 'robust-sorting' can be added called 'bit-packing' for example. > > With these changes, it is likely that the AMR and AMR-WB formats can be > merged into a single > format (since the AMR-WB is very to AMR draft). > > Greg Sherwood, Ph.D. > Sr. Member of Technical Staff > PacketVideo Corporation > From rem-conf Mon Mar 12 10:29:46 2001 From rem-conf-request@es.net Mon Mar 12 10:29:45 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cWt2-0007aS-00; Mon, 12 Mar 2001 10:17:40 -0800 Received: from (192.168.1.9) [195.188.128.245] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cWt0-0007aI-00; Mon, 12 Mar 2001 10:17:39 -0800 Received: from 195.22.168.66 - 209.255.54.121 by 192.168.1.9 with Microsoft SMTPSVC(5.5.1774.114.11); Mon, 12 Mar 2001 18:19:28 +0000 To: aisha@dial.pipex.com From: sjdv@forum.dk Date: Sun, 11 Mar 2001 01:15:17 -0-1200 Subject: <> Save up to 70% on Your Life Insurance -FREE Quote f Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: <3fyfty0f.n4gr7i5gho6q@195.22.168.66> X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Insurance
Save up to 70% on your Life Insurance!
Why Spend More Than You Have To?
Check out these example monthly rates...
10-year level premium term insurance
(20 and 30 year rates also available)
$250,000 $500,000 $1,000,000
Age Male Female Male Female Male Female
30$12$11$19$15$31$27
40$15$13$26$21$38$37
50$32$24$59$43$107$7 8
60$75$46$134$87$259$ 161
(Smoker rates also available)

Take a minute to fill out the simple form below and receive a FREE quote
comparing the best values from among hundreds of the nation's top insurance companies!

*All Fields required
First Name:
Last Name:
Address:
City:
State:
Zip:
Day Phone: (xxx-xxx-xxxx)
Evening Phone:
Fax: (xxx-xxx-xxxx)
Email:
Male or Female:
Date of Birth: (mm/dd/yy)
Type of Insurance:
Insurance Amount:
Height:
Weight: lbs
Tobacco Use:
Health Status:
Health conditions?
YesNo		Explain:
Prescription medications?
YesNo		Explain:
Do you engage in any hazardous activities?
(i.e. scuba,skydiving,private pilot,etc.)
YesNo		Explain:
Did your parents or siblings have
heart disease or cancer prior to age 60?
YesNo		Explain:

We will open your email application to submit your inquiry. All quotes will be from insurance companies rated A-, A, A+ or A++ by A.M. Best. Actual premiums and coverage availability will vary depending upon age, sex, state, health history and tobacco use. THIS IS NOT AN OFFER OR CONTRACT TO BUY INSURANCE PRODUCTS, but rather a confidential informational inquiry. All information submitted is strictly confidential, and will be given to an insurance professional licensed in your state of residence, who will contact you and provide your quote directly. Further transmissions of this email may be stopped at no cost to you. PLEASE CLICK HERE AND TYPE REMOVE.
From rem-conf Mon Mar 12 12:08:22 2001 From rem-conf-request@es.net Mon Mar 12 12:08:21 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cYVl-00028k-00; Mon, 12 Mar 2001 12:01:45 -0800 Received: from (painet.panthers.com.au) [203.108.26.154] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cYVj-00028a-00; Mon, 12 Mar 2001 12:01:43 -0800 Received: from ns0.emc.com (1Cust88.tnt34.dfw9.da.uu.net [63.62.253.88]) by painet.panthers.com.au (8.8.5/8.8.5) with SMTP id GAA16432; Tue, 13 Mar 2001 06:43:15 +1100 From: b4h443@arabia.com Message-ID: <00005fd01294$00002352$000029b1@ns0.emc.com> To: Subject: Tires of Cable TV raising there rates!!! Date: Mon, 12 Mar 2001 10:23:04 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Tired of Cable TV raising their rates!!!
Get Satellite TV
YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
YES ---YOU CAN GET LOCAL STATIONS
Order Dish Network System with a one year plan, get FREE two receivers<= BR> and the 18" Dish with FREE basic professional installation.

Why Bother? For $40.99 Get both receivers and the Top 100 Stations!
With only one receiver and the Dish $35.99 Local Channels add $5.00
You will be charged a one time $49.99 fee when you order which includes=
your first months service for FREE.
THAT S IT!
FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...
YOU'LL LOVE IT.
Ready? Order by phone 1-888-235-5285 or e-mail us dishpeople@mail.com
REQUIREMENT- 1. One year service commitment.
2. Major credit Card
3. Southwest exposure to the sky.

to be remove from future mailings e-mail us with the word "remove" in t= he subject lineat --- getmeoff@arabia.com

Headquarters:
470 State Highway 10 West
Ledgewood, New Jersey 07852-0338
(973)252-9000
www.1800technostores.com

Tired of Cable TV raising their rates!!!

From rem-conf Mon Mar 12 18:35:04 2001 From rem-conf-request@es.net Mon Mar 12 18:35:03 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ceXX-0001XS-00; Mon, 12 Mar 2001 18:27:59 -0800 Received: from (www5.chinadns.com) [211.99.199.74] by mail1.es.net with smtp (Exim 1.81 #2) id 14ceXV-0001X0-00; Mon, 12 Mar 2001 18:27:57 -0800 Received: (qmail 48916 invoked from network); 13 Mar 2001 02:30:18 -0000 Received: from unknown (HELO localhost) (211.96.141.117) by 211.99.199.74 with SMTP; 13 Mar 2001 02:30:18 -0000 X-Sender: audio@cngoldline.com From: Sonia To: rem-conf@es.net Date: Tue, 13 Mar 2001 10:33:16 +0800 Subject: audio products Reply-To: audio@cngoldline.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir or Madam, It is an honor to send this message to you introducing our factory and products. Coby Electronics Corporation is a "prime" manufacturer of quality consumer electronics that are designed to provide years of outstanding performance and sound reproduction.The brand of our products is from U.S. and the factory is located in Foshan, Guangdong, mainland China . Unlike many other consumer electronics companies, Coby possesses an in-house art & design department and an in-house research & development department. These departments have been responsible for creating award winning packaging designs and exclusive & patented products. Currently Coby has a wide variety of products which were created to fill every desire and need. Those products include personal CD players, portable CD stereos, MP3 players, MP3 CD players, portable stereos, personal portable stereos, AM/FM radios, NOAA weather alert radios, short wave multi band radios, fashion & feature telephones, caller ID products, telephones with built-in digital answering machine, professional stereo headphones & earphones, mini-speaker systems, hands-free cellular & cordless telephone accessories, audio/video accessories, audio & video cleaning care products, and microphones. If you are interested in our products or want to establish a corporation with us, Please contact us without hesitate. Tel:0086-757-6239656 Fax:0086-757-6336141 E-mail:audio@cngoldline.com Website: http://www.cobyusa.com Contact Person: Ms.Sonia From rem-conf Tue Mar 13 00:29:15 2001 From rem-conf-request@es.net Tue Mar 13 00:29:14 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ck5h-0000I2-00; Tue, 13 Mar 2001 00:23:37 -0800 Received: from (vivaldi.vcon.co.il) [216.72.33.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ck5V-0000Hh-00; Tue, 13 Mar 2001 00:23:35 -0800 Received: by vivaldi.vcon.co.il with Internet Mail Service (5.5.2650.21) id <1Q5AZ6LV>; Tue, 13 Mar 2001 10:26:17 +0200 Message-ID: <28620B5447EFD311919000600860FCB2BBF95B@vivaldi.vcon.co.il> From: Haggai Carmon To: "'rem-conf@es.net'" Subject: remove Date: Tue, 13 Mar 2001 10:26:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AB97.45CE4010" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AB97.45CE4010 Content-Type: text/plain; charset="windows-1255" ------_=_NextPart_001_01C0AB97.45CE4010 Content-Type: text/html; charset="windows-1255" remove
------_=_NextPart_001_01C0AB97.45CE4010-- From rem-conf Tue Mar 13 01:32:57 2001 From rem-conf-request@es.net Tue Mar 13 01:32:56 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cl8O-0002AO-00; Tue, 13 Mar 2001 01:30:28 -0800 Received: from ada.cs.ucy.ac.cy [194.42.7.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cl8K-0002AE-00; Tue, 13 Mar 2001 01:30:25 -0800 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id LAA48148; Tue, 13 Mar 2001 11:26:52 +0200 Message-ID: <063f01c0ab9f$c87b08b0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , , , , "comm-theory" , , , , , "Conferencesa" , , , , , , , , , , , , , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , Subject: INFOCOM 2001, Anchorage Alaska, 22-26 April 2001 --> Call for participation Date: Tue, 13 Mar 2001 11:26:05 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_063C_01C0ABB0.646AAB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_063C_01C0ABB0.646AAB80 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit !!! PLEASE ACCEPT OUR SICNERE APOLOGIES FOR MULTIPLE COPIES. !!! C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration is April 2, 2001 (5pm Eastern Standard Time). Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. HOTEL REGISTRATION: Please book your hotel room early at the Hilton. Rooms are filling up fast. If the Hilton gets filled up, the Marriott is our alternative hotel for the conference (same room rate as the Hilton). TOURS: Several tours of Alaska's natural treasures are planned. Please visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications Quality of Service (QoS) Support for Broadband Wireless Networks Traffic Engineering in IP/MPLS Networks TCP Congestion Controls: Algorithms and Models Video Over IP Bluetooth and Pervasive Wireless Networking Control and Management for Optical Networks: An IP-Centric Approach Principles of Multicast Protocols and Services PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model ------=_NextPart_000_063C_01C0ABB0.646AAB80 Content-Type: text/plain; name="cfpart.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cfpart.txt" C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration=20 is April 2, 2001 (5pm Eastern Standard Time).=20 Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our=20 website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001.=20 HOTEL REGISTRATION: Please book your hotel room early at the Hilton. Rooms are filling up fast. If the Hilton gets filled up, the Marriott is our alternative hotel for the conference (same room rate as the = Hilton). TOURS: Several tours of Alaska's natural treasures are planned. Please = visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications=20 Quality of Service (QoS) Support for Broadband Wireless Networks=20 Traffic Engineering in IP/MPLS Networks=20 TCP Congestion Controls: Algorithms and Models=20 Video Over IP=20 Bluetooth and Pervasive Wireless Networking=20 Control and Management for Optical Networks: An IP-Centric Approach=20 Principles of Multicast Protocols and Services=20 PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model ------=_NextPart_000_063C_01C0ABB0.646AAB80-- From rem-conf Tue Mar 13 06:38:57 2001 From rem-conf-request@es.net Tue Mar 13 06:38:57 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cptq-0000Xm-00; Tue, 13 Mar 2001 06:35:46 -0800 Received: from zcars04e.nortelnetworks.com [47.129.242.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cpto-0000Vu-00; Tue, 13 Mar 2001 06:35:44 -0800 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 13 Mar 2001 09:32:17 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Mar 2001 09:32:18 -0500 Message-ID: From: "Glenn Parsons" To: rem-conf@es.net Cc: 'IETF VPIM List' Subject: RE: AVT WG last call on RTP spec and profile Date: Tue, 13 Mar 2001 09:32:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABCA.67CE7120" X-Orig: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABCA.67CE7120 Content-Type: text/plain; charset="ISO-8859-1" Hi, Is there any interest in aligning the G.726 MIME content-type between email and RTP? That is, do we need both audio/32kadpcm and audio/g726-32 ? I would think that if they are both essentially the same, there is no need to have two. In RFC2422, we have defined 32kb/s G.726 for use with the VPIM spec (RFC 2421) for transmitting voice messages via email. We are in the process of moving this to Draft Standard (see draft-ietf-vpim-vpimv2r2-32k-00.txt) I believe we have defined the packing order the same (although with different wording :-) but we have not used the other data rates. Perhaps you would prefer all the G.726 MIME content-types to follow the same style? Cheers, Glenn Parsons VPIM WG co-chair > ---------- > From: Stephen Casner > Sent: Friday, March 9, 2001 3:15 am > To: rem-conf@es.net > Subject: AVT WG last call on RTP spec and profile > > To the AVT working group: > > This message is to announce the repeat WG last call on the RTP spec > and A/V profile to end in two weeks at the IETF meeting in > Minneapolis. These drafts are to go to Draft Standard RFC status. > > Note that we already completed a WG last call on these drafts a year > ago, but we've had some trouble completing the interoperability > matrix. A new last call is being issued because SOME ITEMS HAVE BEEN > DELETED and because there has some additional text has been added on > congestion control in response to the discussions at the last two > meetings. > > Please review these changes, and also please take this opportunity to > check that problems you have told me about before have been > addressed. If I missed some, please tell me again. > > The drafts should appear on the official Internet Drafts repositories > soon, but in the meantime you can fetch them at the URLs below. > > Changes to the RTP spec: > > The only changes in this revision of the draft from the previous > one were the addition of a reference to RFC 2914 in Section 10 on > congestion control and a clarification of splitting RTCP between > encrypted and unencrypted packets in Section 9. > > There are a few items in the main RTP spec still not completed in > the interop matrix, but we have commitments for each to be done by > the meeting or shortly thereafter. > > Changes to the A/V profile: > > o An paragraph further explaining the requirements for congestion > control was added to Section 2. *** We agreed to leave the > text mostly as is, which I have done, but I've attempted to > address Reha Civanlar's argument that we need to specify a > timescale, and I tried to reflect Sally Floyd's comments > about the nature of the TCP fairness criterion. > > o Packetization of G.726 audio at rates 40, 24 and 16 kb/s is > specified in addition to 32 kb/s, because those have been > waiting for an implementation and now we have two. > > o The mapping of a user pass-phrase string into an encryption key > was deleted from Section 2 because two interoperable > implementations were not found. > > o The specification of a two-byte encapsulation for RTP over TCP > was deleted because two interoperable implementations were not > found. > > o The audio payload formats 1016, G723, GSM-HR and GSM-EFR were > removed because two interoperable implementations were not > found. > > o The video payload formats H263, BT656, MP2T, MP1S, MP2P and > BMPEG were removed because two interoperable implementations > were not found. > > In addition to the RTP spec and profile, the RTP MIME registration > draft was also updated to bring the H263-2000 parameter definitions in > line with recent ITU changes. This draft and the SDP Bandwidth > Modifiers for RTCP Bandwidth draft are to go to Proposed Standard. > > The package of drafts is available at: > > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.txt > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.ps > > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.t > xt > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.p > s > > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-mime-04.txt > > ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtcp-bw-03.txt > > Thanks in advance for your help in reviewing these drafts. > > -- Steve Casner > AVT Co-Chair > > > > ------_=_NextPart_001_01C0ABCA.67CE7120 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: AVT WG last call on RTP spec and profile

Hi,

Is there any interest in = aligning the G.726 MIME content-type between email and RTP?  That = is, do we need both audio/32kadpcm and audio/g726-32 ?  I would = think that if they are both essentially the same, there is no need to = have two.

In RFC2422, we have defined = 32kb/s G.726 for use with the VPIM spec (RFC 2421) for transmitting = voice messages via email.  We are in the process of moving this to = Draft Standard (see draft-ietf-vpim-vpimv2r2-32k-00.txt)

I believe we have defined the = packing order the same (although with different wording :-) but we have = not used the other data rates.  Perhaps you would prefer all the = G.726 MIME content-types to follow the same style?

Cheers,
Glenn Parsons
VPIM WG co-chair


    ----------
    From:   Stephen Casner
    Sent:   Friday, March 9, 2001 3:15 am
    To:     = rem-conf@es.net
    Subject: =        AVT = WG last call on RTP spec and profile

    To the AVT working group:

    This message is to announce the repeat = WG last call on the RTP spec
    and A/V profile to end in two weeks = at the IETF meeting in
    Minneapolis.=A0 These drafts are to = go to Draft Standard RFC status.

    Note that we already completed a WG = last call on these drafts a year
    ago, but we've had some trouble = completing the interoperability
    matrix.=A0 A new last call is being = issued because SOME ITEMS HAVE BEEN
    DELETED and because there has some = additional text has been added on
    congestion control in response to the = discussions at the last two
    meetings. =

    Please review these changes, and also = please take this opportunity to
    check that problems you have told me = about before have been
    addressed.=A0 If I missed some, = please tell me again.

    The drafts should appear on the = official Internet Drafts repositories =
    soon, but in the meantime you can = fetch them at the URLs below.

    Changes to the RTP spec:

    =A0=A0 The only changes in this = revision of the draft from the previous =
    =A0=A0 one were the addition of a = reference to RFC 2914 in Section 10 on =
    =A0=A0 congestion control and a = clarification of splitting RTCP between =
    =A0=A0 encrypted and unencrypted = packets in Section 9.

    =A0=A0 There are a few items in the = main RTP spec still not completed in =
    =A0=A0 the interop matrix, but we = have commitments for each to be done by =
    =A0=A0 the meeting or shortly = thereafter.

    Changes to the A/V = profile:

    =A0=A0=A0=A0=A0=A0 o An paragraph = further explaining the requirements for congestion
    =A0=A0=A0=A0=A0=A0=A0=A0 control was = added to Section 2.=A0 *** We agreed to leave the
    =A0=A0=A0=A0=A0=A0=A0=A0 text mostly = as is, which I have done, but I've attempted to
    =A0=A0=A0=A0=A0=A0=A0=A0 address Reha = Civanlar's argument that we need to specify a
    =A0=A0=A0=A0=A0=A0=A0=A0 timescale, = and I tried to reflect Sally Floyd's comments
    =A0=A0=A0=A0=A0=A0=A0=A0 about the = nature of the TCP fairness criterion. =

    =A0=A0=A0=A0=A0=A0 o Packetization of = G.726 audio at rates 40, 24 and 16 kb/s is =
    =A0=A0=A0=A0=A0=A0=A0=A0 specified in = addition to 32 kb/s, because those have been
    =A0=A0=A0=A0=A0=A0=A0=A0 waiting for = an implementation and now we have two. =

    =A0=A0=A0=A0=A0=A0 o The mapping of a = user pass-phrase string into an encryption key
    =A0=A0=A0=A0=A0=A0=A0=A0 was deleted = >from Section 2 because two interoperable =
    =A0=A0=A0=A0=A0=A0=A0=A0 = implementations were not found.

    =A0=A0=A0=A0=A0=A0 o The specification = of a two-byte encapsulation for RTP over TCP
    =A0=A0=A0=A0=A0=A0=A0=A0 was deleted = because two interoperable implementations were not
    =A0=A0=A0=A0=A0=A0=A0=A0 = found.

    =A0=A0=A0=A0=A0=A0 o The audio payload = formats 1016, G723, GSM-HR and GSM-EFR were =
    =A0=A0=A0=A0=A0=A0=A0=A0 removed = because two interoperable implementations were not
    =A0=A0=A0=A0=A0=A0=A0=A0 = found.

    =A0=A0=A0=A0=A0=A0 o The video payload = formats H263, BT656, MP2T, MP1S, MP2P and =
    =A0=A0=A0=A0=A0=A0=A0=A0 BMPEG were = removed because two interoperable implementations
    =A0=A0=A0=A0=A0=A0=A0=A0 were not = found.

    In addition to the RTP spec and = profile, the RTP MIME registration
    draft was also updated to bring the = H263-2000 parameter definitions in
    line with recent ITU changes.=A0 This = draft and the SDP Bandwidth
    Modifiers for RTCP Bandwidth draft = are to go to Proposed Standard.

    The package of drafts is available = at:

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-rtp-new-09.txt
    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-rtp-new-09.ps

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-profile-new-10.txt
    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-profile-new-10.ps

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-rtp-mime-04.txt

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-= avt-rtcp-bw-03.txt

    Thanks in advance for your help in = reviewing these drafts.

    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 -- Steve Casner =
    =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AVT Co-Chair =




------_=_NextPart_001_01C0ABCA.67CE7120-- From rem-conf Tue Mar 13 06:53:37 2001 From rem-conf-request@es.net Tue Mar 13 06:53:36 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cqA5-0001N7-00; Tue, 13 Mar 2001 06:52:33 -0800 Received: from mail.nww.com (server.nww.com) [198.3.122.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cqA4-0001Mx-00; Tue, 13 Mar 2001 06:52:32 -0800 Received: from tkistner (254.new-york-19rh15rt-ny.dial-access.att.net [12.88.196.254]) by server.nww.com (8.9.3/8.9.1) with SMTP id JAA16207 for ; Tue, 13 Mar 2001 09:46:30 -0500 (EST) Reply-To: From: "Toni Kistner" To: Subject: remove Date: Tue, 13 Mar 2001 09:50:19 -0500 Message-ID: <001401c0abcc$ed617880$fec4580c@tkistner> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C0ABA3.048B7080" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C0ABA3.048B7080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: AVT WG last call on RTP spec and profile -----Original Message----- From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] Sent: Tuesday, March 13, 2001 9:32 AM To: rem-conf@es.net Cc: 'IETF VPIM List' Subject: RE: AVT WG last call on RTP spec and profile Hi, Is there any interest in aligning the G.726 MIME content-type between email and RTP? That is, do we need both audio/32kadpcm and audio/g726-32 ? I would think that if they are both essentially the same, there is no need to have two. In RFC2422, we have defined 32kb/s G.726 for use with the VPIM spec (RFC 2421) for transmitting voice messages via email. We are in the process of moving this to Draft Standard (see draft-ietf-vpim-vpimv2r2-32k-00.txt) I believe we have defined the packing order the same (although with different wording :-) but we have not used the other data rates. Perhaps you would prefer all the G.726 MIME content-types to follow the same style? Cheers, Glenn Parsons VPIM WG co-chair ---------- From: Stephen Casner Sent: Friday, March 9, 2001 3:15 am To: rem-conf@es.net Subject: AVT WG last call on RTP spec and profile To the AVT working group: This message is to announce the repeat WG last call on the RTP spec and A/V profile to end in two weeks at the IETF meeting in Minneapolis. These drafts are to go to Draft Standard RFC status. Note that we already completed a WG last call on these drafts a year ago, but we've had some trouble completing the interoperability matrix. A new last call is being issued because SOME ITEMS HAVE BEEN DELETED and because there has some additional text has been added on congestion control in response to the discussions at the last two meetings. Please review these changes, and also please take this opportunity to check that problems you have told me about before have been addressed. If I missed some, please tell me again. The drafts should appear on the official Internet Drafts repositories soon, but in the meantime you can fetch them at the URLs below. Changes to the RTP spec: The only changes in this revision of the draft from the previous one were the addition of a reference to RFC 2914 in Section 10 on congestion control and a clarification of splitting RTCP between encrypted and unencrypted packets in Section 9. There are a few items in the main RTP spec still not completed in the interop matrix, but we have commitments for each to be done by the meeting or shortly thereafter. Changes to the A/V profile: o An paragraph further explaining the requirements for congestion control was added to Section 2. *** We agreed to leave the text mostly as is, which I have done, but I've attempted to address Reha Civanlar's argument that we need to specify a timescale, and I tried to reflect Sally Floyd's comments about the nature of the TCP fairness criterion. o Packetization of G.726 audio at rates 40, 24 and 16 kb/s is specified in addition to 32 kb/s, because those have been waiting for an implementation and now we have two. o The mapping of a user pass-phrase string into an encryption key was deleted from Section 2 because two interoperable implementations were not found. o The specification of a two-byte encapsulation for RTP over TCP was deleted because two interoperable implementations were not found. o The audio payload formats 1016, G723, GSM-HR and GSM-EFR were removed because two interoperable implementations were not found. o The video payload formats H263, BT656, MP2T, MP1S, MP2P and BMPEG were removed because two interoperable implementations were not found. In addition to the RTP spec and profile, the RTP MIME registration draft was also updated to bring the H263-2000 parameter definitions in line with recent ITU changes. This draft and the SDP Bandwidth Modifiers for RTCP Bandwidth draft are to go to Proposed Standard. The package of drafts is available at: ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new-09.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-profile-new-10.ps ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-mime-04.txt ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtcp-bw-03.txt Thanks in advance for your help in reviewing these drafts. -- Steve Casner AVT Co-Chair ------=_NextPart_000_0015_01C0ABA3.048B7080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AVT WG last call on RTP spec and profile
 
-----Original Message-----
From: Glenn Parsons=20 [mailto:gparsons@nortelnetworks.com]
Sent: Tuesday, March = 13, 2001=20 9:32 AM
To: rem-conf@es.net
Cc: 'IETF VPIM=20 List'
Subject: RE: AVT WG last call on RTP spec and=20 profile

Hi,

Is there any interest in = aligning the G.726=20 MIME content-type between email and RTP?  That is, do we need = both=20 audio/32kadpcm and audio/g726-32 ?  I would think that if they = are both=20 essentially the same, there is no need to have two.

In RFC2422, we have defined = 32kb/s G.726 for=20 use with the VPIM spec (RFC 2421) for transmitting voice messages via=20 email.  We are in the process of moving this to Draft Standard = (see=20 draft-ietf-vpim-vpimv2r2-32k-00.txt)

I believe we have defined the = packing order=20 the same (although with different wording :-) but we have not used the = other=20 data rates.  Perhaps you would prefer all the G.726 MIME = content-types to=20 follow the same style?

Cheers,
Glenn Parsons
VPIM WG=20 co-chair


    ----------
    From:   Stephen=20 Casner
    Sent: =   Friday, March 9, 2001 3:15 am     =
    To:         rem-conf@es.net
    Subject:        = AVT WG last call on RTP spec and = profile

    To the AVT working group:=20

    This message is to announce the = repeat WG last=20 call on the RTP spec
    and A/V profile to end in two weeks at the IETF meeting=20 in
    Minneapolis.  These drafts are to go to Draft Standard = RFC=20 status.

    Note that we already completed a WG = last call on=20 these drafts a year
    ago, but we've had some trouble completing the=20 interoperability
    matrix.  A new last call is being issued because SOME = ITEMS HAVE=20 BEEN
    DELETED and=20 because there has some additional text has been added on
    congestion = control in=20 response to the discussions at the last two=20
    meetings.=20

    Please review these changes, and also = please take=20 this opportunity to
    check that problems you have told me about before have=20 been
    addressed.  If I missed some, please tell me = again.

    The drafts should appear on the = official Internet=20 Drafts repositories
    soon, but in the meantime you can fetch them at the URLs=20 below.

    Changes to the RTP spec:=20

       The only changes in this = revision of=20 the draft from the previous =
       one were the addition of a = reference to RFC=20 2914 in Section 10 on
       congestion control and a clarification of = splitting RTCP=20 between
       encrypted and unencrypted packets in Section=20 9.

       There are a few items in = the main=20 RTP spec still not completed in =
       the interop matrix, but we have = commitments=20 for each to be done by
       the meeting or shortly thereafter.

    Changes to the A/V = profile:

           = o An=20 paragraph further explaining the requirements for = congestion
             control = was added to=20 Section 2.  *** We agreed to leave the=20
             text = mostly as is,=20 which I have done, but I've attempted to=20
             address = Reha=20 Civanlar's argument that we need to specify a=20
             timescale, = and I=20 tried to reflect Sally Floyd's comments=20
             about the = nature of=20 the TCP fairness criterion.

           = o=20 Packetization of G.726 audio at rates 40, 24 and 16 kb/s = is
             specified = in=20 addition to 32 kb/s, because those have been=20
             waiting = for an=20 implementation and now we have two. =

           = o The=20 mapping of a user pass-phrase string into an encryption = key
             was = deleted from=20 Section 2 because two interoperable =
            =20 implementations were not found. =

           = o The=20 specification of a two-byte encapsulation for RTP over = TCP
             was = deleted because=20 two interoperable implementations were not =
             = found.

           = o The audio=20 payload formats 1016, G723, GSM-HR and GSM-EFR were=20
             removed = because two=20 interoperable implementations were not=20
             = found.

           = o The video=20 payload formats H263, BT656, MP2T, MP1S, MP2P and=20
             BMPEG were = removed=20 because two interoperable implementations=20
             were not=20 found.

    In addition to the RTP spec and = profile, the RTP=20 MIME registration
    draft was also updated to bring the H263-2000 parameter = definitions=20 in
    line with=20 recent ITU changes.  This draft and the SDP = Bandwidth
    Modifiers for = RTCP Bandwidth=20 draft are to go to Proposed Standard. =

    The package of drafts is available=20 at:

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-ne= w-09.txt
    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-new= -09.ps

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-pr= ofile-new-10.txt
    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-pro= file-new-10.ps

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtp-m= ime-04.txt

    ftp://ftp.packetdesign.com/outgoing/casner/draft-ietf-avt-rtcp-b= w-03.txt

    Thanks in advance for your help in = reviewing=20 these drafts.

              &nbs= p;            = ;            =             &= nbsp;  =20 -- Steve Casner
              &nbs= p;            = ;            =             &= nbsp;     =20 AVT Co-Chair=20




------=_NextPart_000_0015_01C0ABA3.048B7080-- From rem-conf Tue Mar 13 07:00:11 2001 From rem-conf-request@es.net Tue Mar 13 07:00:11 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cqGo-0001xR-00; Tue, 13 Mar 2001 06:59:30 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cqGg-0001wx-00; Tue, 13 Mar 2001 06:59:25 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id JAA02157 for ; Tue, 13 Mar 2001 09:56:24 -0500 Message-Id: <200103131456.JAA02157@purple.east.isi.edu> To: rem-conf@es.net Subject: Revised AVT Agenda Date: Tue, 13 Mar 2001 09:56:24 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I enclose a revised draft of the AVT agenda for Minneapolis. Send any comments or corrections to the chairs today, please. Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group Agenda Wednesday, 21st March 2001, 15:30 - 17:30 ========================================= Introduction and status update (Casner) 10 draft-ietf-avt-dv-audio-02.txt The Secure Real Time Transport Protocol (Carrara) 15 draft-ietf-avt-srtp-00.txt RTCP Extension for Source Specific Multicast Sessions (Chesterfield) 15 draft-chesterfield-avt-rtcpssm-00.txt RTCP-based Feedback: Concepts and Message Timing Rules (Ott) 15 draft-wenger-avt-rtcp-feedback-02.txt Low Delay RTCP Feedback Format (Burmeister) 15 draft-fukunaga-low-delay-rtcp-02.txt RTP Retransmission Payload Format (Burmeister) 15 draft-ietf-avt-rtp-selret-01.txt RTP specification and audio/video profile (Casner/Perkins) 20 draft-ietf-avt-rtp-new-09.txt, .ps draft-ietf-avt-profile-new-10.txt, .ps draft-ietf-avt-rtp-mime-04.txt draft-ietf-avt-rtcp-bw-03.txt draft-ietf-avt-rtp-interop-07.txt draft-ietf-avt-profile-interop-05.txt Thursday, 22nd March 2001, 13:00 - 15:00 ======================================== An RTP Payload Format for Generic FEC with ULP (Li) 15 draft-ietf-avt-ulp-00.txt RTP payload format and file storage format for AMR (Westerlund) 15 draft-ietf-avt-rtp-amr-05.txt RTP payload format for AMR-WB (Lakaniemi) 15 draft-lakaniemi-avt-amrwb-00.txt An RTP Payload Format for EVRC Speech (Li) 15 draft-ietf-avt-evrc-01.txt RTP payload format for Vorbis (Moffit) 15 draft-moffitt-vorbis-rtp-00.txt RTP Payload Format for MPEG-4 Streams (Gentric) 15 draft-gentric-avt-mpeg4-multipleSL-02.txt RTP payload format for MPEG-4 FlexMultiplexed streams (Roux) 15 draft-curet-avt-rtp-mpeg4-flexmux-00.txt We strongly encourage participants to read all relevent drafts before the meeting, and for those making presentations to assume that the audience has read the draft. Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe the changes from the previous draft, highlight unresolved problems, propose future directions. Authors are also reminded of the contents of section 10 of RFC 2026. In particular, the requirement for disclosure of intellectual property relating to contributions. From rem-conf Tue Mar 13 08:57:03 2001 From rem-conf-request@es.net Tue Mar 13 08:57:02 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cs2r-0005Ai-00; Tue, 13 Mar 2001 08:53:13 -0800 Received: from (vivaldi.vcon.co.il) [212.29.219.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cs2d-0005A9-00; Tue, 13 Mar 2001 08:53:12 -0800 Received: by vivaldi.vcon.co.il with Internet Mail Service (5.5.2650.21) id <1Q5AZ7SS>; Tue, 13 Mar 2001 18:52:01 +0200 Message-ID: <28620B5447EFD311919000600860FCB2BBF97F@vivaldi.vcon.co.il> From: Haggai Carmon To: rem-conf@es.net Subject: remove Date: Tue, 13 Mar 2001 18:51:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ABDD.EB9FE2A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ABDD.EB9FE2A0 Content-Type: text/plain; charset="windows-1255" ------_=_NextPart_001_01C0ABDD.EB9FE2A0 Content-Type: text/html; charset="windows-1255" remove
------_=_NextPart_001_01C0ABDD.EB9FE2A0-- From rem-conf Tue Mar 13 09:11:21 2001 From rem-conf-request@es.net Tue Mar 13 09:11:20 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14csIs-0006Fh-00; Tue, 13 Mar 2001 09:09:46 -0800 Received: from (LEMON.flavorsoftware.com) [64.232.157.3] by mail1.es.net with smtp (Exim 1.81 #2) id 14csIq-0006DS-00; Tue, 13 Mar 2001 09:09:44 -0800 Received: by LEMON.flavorsoftware.com with Internet Mail Service (5.5.1960.3) id ; Tue, 13 Mar 2001 12:02:50 -0500 Message-ID: From: Hari Kalva To: "'rem-conf@es.net'" Subject: MP4 Player Available for Download Date: Tue, 13 Mar 2001 12:02:48 -0500 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 Flavor Software is proud to release the first commercial MPEG-4 player and authoring software. The Mild Flavor(tm) player and sample MP4 files featuring New York City indi bands "The Pasties", "Brave New Girl", and "The Rosenbergs" are available for download from the Flavor Software web site. Go to http://www.flavorsoftware.com and click on downloads. Spread the joy... tell your friends to go to the Flavor web site and get into MP4! Even better... create your own MP4 files and send them to your friends! -- The Flavor Team From rem-conf Tue Mar 13 09:49:54 2001 From rem-conf-request@es.net Tue Mar 13 09:49:53 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cssF-0007bM-00; Tue, 13 Mar 2001 09:46:19 -0800 Received: from cmr2.ash.ops.us.uu.net [198.5.241.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cssE-0007bC-00; Tue, 13 Mar 2001 09:46:18 -0800 Received: from neserve0.corp.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQkgex24037; Tue, 13 Mar 2001 17:46:16 GMT Received: by neserve0.corp.us.uu.net id QQkgex03581; Tue, 13 Mar 2001 12:46:04 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: MP4 Player Available for Download In-Reply-To: from Hari Kalva at "Mar 13, 2001 12:02:48 pm" To: Hari Kalva Date: Tue, 13 Mar 2001 12:46:04 -0500 (EST) CC: "'rem-conf@es.net'" X-Mailer: ELM [version 2.4ME+ PL60 (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 When will the Linuxclient be released? _J In the new year, Hari Kalva wrote: > Flavor Software is proud to release the first commercial MPEG-4 player > and > authoring software. The Mild Flavor(tm) player and sample MP4 files > featuring > New York City indi bands "The Pasties", "Brave New Girl", and "The > Rosenbergs" > are available for download from the Flavor Software web site. > > Go to http://www.flavorsoftware.com and click on downloads. > > Spread the joy... tell your friends to go to the Flavor web site and get > into > MP4! Even better... create your own MP4 files and send them to your > friends! > -- The Flavor Team > From rem-conf Tue Mar 13 10:07:22 2001 From rem-conf-request@es.net Tue Mar 13 10:07:21 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ct9H-0000uV-00; Tue, 13 Mar 2001 10:03:55 -0800 Received: from mail.nww.com (server.nww.com) [198.3.122.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ct9F-0000tt-00; Tue, 13 Mar 2001 10:03:53 -0800 Received: from tkistner (21.new-york-19rh16rt-ny.dial-access.att.net [12.88.197.21]) by server.nww.com (8.9.3/8.9.1) with SMTP id MAA23999 for ; Tue, 13 Mar 2001 12:57:53 -0500 (EST) Reply-To: From: "Toni Kistner" To: Subject: remove pls Date: Tue, 13 Mar 2001 13:01:41 -0500 Message-ID: <003701c0abe7$a8fc8390$41c3580c@tkistner> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Jeremy Hall [mailto:jhall@UU.NET] Sent: Tuesday, March 13, 2001 12:46 PM To: Hari Kalva Cc: 'rem-conf@es.net' Subject: Re: MP4 Player Available for Download When will the Linuxclient be released? _J In the new year, Hari Kalva wrote: > Flavor Software is proud to release the first commercial MPEG-4 player > and > authoring software. The Mild Flavor(tm) player and sample MP4 files > featuring > New York City indi bands "The Pasties", "Brave New Girl", and "The > Rosenbergs" > are available for download from the Flavor Software web site. > > Go to http://www.flavorsoftware.com and click on downloads. > > Spread the joy... tell your friends to go to the Flavor web site and get > into > MP4! Even better... create your own MP4 files and send them to your > friends! > -- The Flavor Team > From rem-conf Tue Mar 13 10:51:36 2001 From rem-conf-request@es.net Tue Mar 13 10:51:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ctmE-0002cx-00; Tue, 13 Mar 2001 10:44:10 -0800 Received: from utrhcs.cs.utwente.nl [130.89.10.247] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ctmA-0002cI-00; Tue, 13 Mar 2001 10:44:06 -0800 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id TAA08859; Tue, 13 Mar 2001 19:42:30 +0100 (MET) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id TAA01396; Tue, 13 Mar 2001 19:40:59 +0100 (MET) Message-ID: <3AAE69BC.556C6E5B@cs.utwente.nl> Date: Tue, 13 Mar 2001 19:41:01 +0100 From: Clever Ricardo Guareis de Farias Organization: CTIT - Centre for Telematics and Information Technology X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: PROMS 2001: call for papers Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id TAA08859 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Our apologies if you receive multiple copies of this CfP.] First Call for Papers 6th International Conference on Protocols for Multimedia Systems - PROMS 2001 17-19 October, Enschede, The Netherlands Organised by Center for Telematics and Information Technology at the University of Twente Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS 2001 conference is intended to contribute to a scientific, strategic and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS 2001 will cover papers and demonstrations on research and achievements related to the following topics: =B7 design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; =B7 application, media, and protocol integration: synchronization of media streams; =B7 multiparty and group communication protocols; =B7 mobile networking and routing: multimedia communication architectures for mobile networks; =B7 multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; =B7 content based searching and querying; =B7 techniques for the specification of communication services required by multimedia applications; =B7 methods for real-time testing and analysis of service implementations; =B7 integration of media storage and communication mechanisms, operating system and high-performance issues; =B7 experiences with service provisioning using distributed multimedia applications; =B7 performance of protocols and applications: modelling, simulation and optimization in different networks; =B7 multimedia traffic engineering; =B7 applications and platforms for service management and provisioning; =B7 definition, provisioning, and supervision of QoS parameters for networked applications and services; =B7 intelligent management tools pertaining to costs and QoS, network access, accounting, security, and system resilience; =B7 service access - security, authentication, privacy; =B7 accounting and tariff policing for multimedia teleservices. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (PDF); editorial requirements can be found at http://www.ctit.utwente.nl/news/proms_2001. IMPORTANT DATES =B7 Full papers due 15 May 2001 =B7 Authors notified 15 June 2001 =B7 Full paper camera ready due 15 July 2001 Conference Chairmen Marten van Sinderen (chair), University of Twente, The Netherlands, sinderen@ctit.utwente.nl Lambert Nieuwenhuis (co-chair), KPN Research and University of Twente, The Netherlands, bart@cs.utwente.nl Further information email: castaned@ctit.utwente.nl phone: +31-53-4893779 fax: +31-53-4894524 postal address: PROMS 2001, CTIT, University of Twente PO BOX 217, NL-7500 AE Enschede, The Netherlands From rem-conf Tue Mar 13 10:51:36 2001 From rem-conf-request@es.net Tue Mar 13 10:51:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14ctli-0002c8-00; Tue, 13 Mar 2001 10:43:38 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14ctlc-0002by-00; Tue, 13 Mar 2001 10:43:34 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id NAA02989; Tue, 13 Mar 2001 13:37:51 -0500 Message-Id: <200103131837.NAA02989@purple.east.isi.edu> To: jhall@UU.NET (Jeremy Hall) cc: Hari Kalva , "'rem-conf@es.net'" Subject: Re: MP4 Player Available for Download In-Reply-To: Message from jhall@UU.NET (Jeremy Hall) of "Tue, 13 Mar 2001 12:46:04 EST." Date: Tue, 13 Mar 2001 13:37:51 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list And, to try to bring this slightly on-topic for this list, how do you transport the MPEG-4 in RTP? Colin --> Jeremy Hall writes: >When will the Linuxclient be released? > >_J > >In the new year, Hari Kalva wrote: >> Flavor Software is proud to release the first commercial MPEG-4 player >> and authoring software. The Mild Flavor(tm) player and sample MP4 files >> featuring New York City indi bands "The Pasties", "Brave New Girl", and >> "The Rosenbergs" are available for download from the Flavor Software web >> site. >> >> Go to http://www.flavorsoftware.com and click on downloads. >> >> Spread the joy... tell your friends to go to the Flavor web site and get >> into MP4! Even better... create your own MP4 files and send them to your >> friends! -- The Flavor Team From rem-conf Tue Mar 13 11:28:27 2001 From rem-conf-request@es.net Tue Mar 13 11:28:26 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cuQn-00059S-00; Tue, 13 Mar 2001 11:26:05 -0800 Received: from (LEMON.flavorsoftware.com) [64.232.157.3] by mail1.es.net with smtp (Exim 1.81 #2) id 14cuQm-00057A-00; Tue, 13 Mar 2001 11:26:04 -0800 Received: by LEMON.flavorsoftware.com with Internet Mail Service (5.5.1960.3) id ; Tue, 13 Mar 2001 14:19:08 -0500 Message-ID: From: Hari Kalva To: 'Colin Perkins' , 'Jeremy Hall' Cc: "'rem-conf@es.net'" Subject: RE: MP4 Player Available for Download Date: Tue, 13 Mar 2001 14:19:07 -0500 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 We do not have streaming support in this release. We will have streaming capability in the next release. -Hari > -----Original Message----- > From: Colin Perkins [mailto:csp@isi.edu] > Sent: Tuesday, March 13, 2001 1:38 PM > To: Jeremy Hall > Cc: Hari Kalva; 'rem-conf@es.net' > Subject: Re: MP4 Player Available for Download > > > And, to try to bring this slightly on-topic for this list, how do you > transport the MPEG-4 in RTP? > > Colin > > > --> Jeremy Hall writes: > >When will the Linuxclient be released? > > > >_J > > > >In the new year, Hari Kalva wrote: > >> Flavor Software is proud to release the first commercial > MPEG-4 player > >> and authoring software. The Mild Flavor(tm) player and > sample MP4 files > >> featuring New York City indi bands "The Pasties", "Brave > New Girl", and > >> "The Rosenbergs" are available for download from the > Flavor Software web > >> site. > >> > >> Go to http://www.flavorsoftware.com and click on downloads. > >> > >> Spread the joy... tell your friends to go to the Flavor > web site and get > >> into MP4! Even better... create your own MP4 files and > send them to your > >> friends! -- The Flavor Team > > From rem-conf Tue Mar 13 11:37:17 2001 From rem-conf-request@es.net Tue Mar 13 11:37:16 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cuab-00063r-00; Tue, 13 Mar 2001 11:36:13 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14cuaa-000635-00; Tue, 13 Mar 2001 11:36:12 -0800 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA29592; Tue, 13 Mar 2001 11:26:32 -0800 Message-ID: <3AAE7574.54A22519@bmrc.berkeley.edu> Date: Tue, 13 Mar 2001 11:31:00 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 3/14 Berkeley Multimedia, Interfaces and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ActiveSpaces: The Access Grid, Active Mural and Advanced Visualization Systems March 14, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Rick Stevens Mathematics and Computer Science Division Argonne National Laboratories At Argonne, Chicago and elsewhere work has begun to explore the concept of integrated whole room scale visual environments. These environments consists of group work rooms that have been augmented with multiple displays including: large-format whole wall displays (e.g. ActiveMural our high-resolution rear projected tiled display), driven by PC clusters, or multi-processor visualization engines, semi-immersive or immersive displays (Workbenches, ImmersaDesks, CAVEs), multiple desktop devices, and multiple front projection systems. These rooms may also have active or passive tracking systems, multiple channels of audio support, and support for multiple wireless hand-held controllers and navigation devices. These room-sized environments can be linked via the national "Grid" to form compelling collaborative visualization environments (e.g. "The Access Grid"). We believe these systems represent a new type of visual application development target and delivery mechanism. We call these ensembles Active Spaces. In this talk I will explore with the audience some of the ideas we are working on to facilitate the delivery of highness scientific visualization to groups of users and to create new types of electronically augmented spaces explicitly designed to support rapid collaborative exploration and visual analysis of complex data. --------------- The seminar is broadcast live on the Internet Bone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Mar 13 11:56:56 2001 From rem-conf-request@es.net Tue Mar 13 11:56:56 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cush-0007Jh-00; Tue, 13 Mar 2001 11:54:55 -0800 Received: from omneon.com (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cusf-0007GP-00; Tue, 13 Mar 2001 11:54:53 -0800 Received: by webmail1.omneon.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Mar 2001 11:54:03 -0800 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B1417970@webmail1.omneon.com> From: Bill Nowicki To: 'Hari Kalva' Cc: "'rem-conf@es.net'" Subject: RE: MP4 Player Available for Download Date: Tue, 13 Mar 2001 11:54:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We just tried the obvious experiment. The ".mp4" files on the "Flavor" site do not play with the Philips player, and the Philips ".mp4" files do not play with the Flavor player. Sounds like a litle inter-operability testing might have been in order before calling them the same name! (and of course file format standards are outside the charter of IETF, but are still useful) From rem-conf Tue Mar 13 12:18:16 2001 From rem-conf-request@es.net Tue Mar 13 12:18:16 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cvCM-0000rD-00; Tue, 13 Mar 2001 12:15:14 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cvCM-0000pN-00; Tue, 13 Mar 2001 12:15:14 -0800 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23802; Tue, 13 Mar 2001 12:14:04 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-68.cisco.com [10.21.64.68]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABI62836; Tue, 13 Mar 2001 12:14:01 -0800 (PST) Message-Id: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 12:13:13 -0800 To: "'rem-conf@es.net'" From: Mark Baugher Subject: SRTP and cryptographic context management Cc: "Elisabetta Carrara (ERA)" , "David A. McGrew (E-mail)" , "David Oran (E-mail)" , "Mats =?iso-8859-1?Q?N=E4slund?= (ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I think we will need the ability to alter or replace the cryptographic context during an RTP session. As I read it, the cryptographic context is identified by the SSRC of the sender and the RTP destination transport-address. That suggests to me that you cannot change the crypto context during the life of an RTP session. It may not be necessary to, say, replace an AES key for the life of the longest RTP session imaginable. But it is common to manage access control to session data by managing the key. There's no way to do that with a fixed crypto context. thanks, Mark From rem-conf Tue Mar 13 12:26:59 2001 From rem-conf-request@es.net Tue Mar 13 12:26:59 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cvMj-0001il-00; Tue, 13 Mar 2001 12:25:57 -0800 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cvMi-0001Zv-00; Tue, 13 Mar 2001 12:25:56 -0800 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22872; Tue, 13 Mar 2001 12:25:14 -0800 (PST) Received: from DMACKIEW2K (dhcp-171-71-97-243.cisco.com [171.71.97.243]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AJF02791; Tue, 13 Mar 2001 12:24:54 -0800 (PST) From: "David Mackie" To: "Hari Kalva" Cc: Subject: RE: MP4 Player Available for Download Date: Tue, 13 Mar 2001 12:18:33 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI: We have an open source project at http://mpeg4ip.sourceforge.net/ that creates MP4 audio/video files with RTP hint tracks (RFC 3016 for video, a simple "RFC 2250-like" payload for AAC audio) The resulting files can be streamed from the Apple Darwin Streaming Server. The package also contains a player that can receive streamed MPEG-4 or play back locally from file. Primary platform is Linux, with a Windows port in the works. Some of the code may be useful to you for interoperability testing or reference. Dave Mackie Cisco Systems Inc. > -----Original Message----- > From: Hari Kalva [mailto:hari@FLAVORSOFTWARE.com] > Sent: Tuesday, March 13, 2001 11:19 AM > To: 'Colin Perkins'; 'Jeremy Hall' > Cc: 'rem-conf@es.net' > Subject: RE: MP4 Player Available for Download > > > We do not have streaming support in this release. We will have streaming > capability in the next release. > -Hari > > > -----Original Message----- > > From: Colin Perkins [mailto:csp@isi.edu] > > Sent: Tuesday, March 13, 2001 1:38 PM > > To: Jeremy Hall > > Cc: Hari Kalva; 'rem-conf@es.net' > > Subject: Re: MP4 Player Available for Download > > > > > > And, to try to bring this slightly on-topic for this list, how do you > > transport the MPEG-4 in RTP? > > > > Colin > > > > > > --> Jeremy Hall writes: > > >When will the Linuxclient be released? > > > > > >_J > > > > > >In the new year, Hari Kalva wrote: > > >> Flavor Software is proud to release the first commercial > > MPEG-4 player > > >> and authoring software. The Mild Flavor(tm) player and > > sample MP4 files > > >> featuring New York City indi bands "The Pasties", "Brave > > New Girl", and > > >> "The Rosenbergs" are available for download from the > > Flavor Software web > > >> site. > > >> > > >> Go to http://www.flavorsoftware.com and click on downloads. > > >> > > >> Spread the joy... tell your friends to go to the Flavor > > web site and get > > >> into MP4! Even better... create your own MP4 files and > > send them to your > > >> friends! -- The Flavor Team > > > > > From rem-conf Tue Mar 13 12:43:11 2001 From rem-conf-request@es.net Tue Mar 13 12:43:10 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cvaZ-000310-00; Tue, 13 Mar 2001 12:40:15 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cvaY-00030i-00; Tue, 13 Mar 2001 12:40:14 -0800 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA11598; Tue, 13 Mar 2001 12:39:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE21726; Tue, 13 Mar 2001 12:39:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA08002; Tue, 13 Mar 2001 12:39:08 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15022.34156.204692.692119@thomasm-u1.cisco.com> Date: Tue, 13 Mar 2001 12:39:08 -0800 (PST) To: Mark Baugher Cc: "'rem-conf@es.net'" , "Elisabetta Carrara (ERA)" , "David A. McGrew (E-mail)" , "David Oran (E-mail)" , "Mats =?iso-8859-1?Q?N=E4slund?= (ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: SRTP and cryptographic context management In-Reply-To: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Baugher writes: > Hi > I think we will need the ability to alter or replace the > cryptographic context during an RTP session. As I > read it, the cryptographic context is identified by > the SSRC of the sender and the RTP destination > transport-address. That suggests to me that you cannot > change the crypto context during the life of an RTP session. > It may not be necessary to, say, replace an AES > key for the life of the longest RTP session imaginable. > But it is common to manage access control to > session data by managing the key. There's no way > to do that with a fixed crypto context. Mark, While I agree that it may be good to have the ability to rekey, the mechanisms for rekeying are (obviously?) out of scope for SRTP. Is there something in particular about SRTP that makes rekeying synchronization difficult/impossible? Also: is it strictly necessasry to solve this in the RTP plane? Ie, would it be possible to just create a new session (SSRC) and delete the old one to affect the keying cutover? Mike From rem-conf Tue Mar 13 12:51:33 2001 From rem-conf-request@es.net Tue Mar 13 12:51:33 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cvjF-0003dU-00; Tue, 13 Mar 2001 12:49:13 -0800 Received: from dominion.cisco.com [161.44.224.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cvjD-0003Ws-00; Tue, 13 Mar 2001 12:49:12 -0800 Received: from pots.cisco.com (mirapoint@pots.cisco.com [161.44.224.224]) by dominion.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA10140; Tue, 13 Mar 2001 15:48:14 -0500 (EST) Received: from ORANLT (ch2-dhcp140-155.cisco.com [161.44.140.155]) by pots.cisco.com (Mirapoint) with ESMTP id AGG05914; Tue, 13 Mar 2001 15:48:03 -0500 (EST) From: "David R. Oran" To: "'Mark Baugher'" , Cc: "'Elisabetta Carrara \(ERA\)'" , "'David A. McGrew \(E-mail\)'" , "=?iso-8859-1?Q?'Mats_N=E4slund__\=28ERA\=29_=5Bmats.n__aslund@era-t.erics?= =?iso-8859-1?Q?son.se=5D_\=28E-mail\=29'?=" Subject: RE: SRTP and cryptographic context management Date: Tue, 13 Mar 2001 15:49:45 -0500 Organization: Cisco Systems Message-ID: <01b301c0abff$27b90160$0bd245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 In-Reply-To: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Don't you need a signaling exchange to negotiate the new key? That could just start a new RTP session, or re-sync on an SSRC change via RTCP. > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com]=20 > Sent: Tuesday, March 13, 2001 3:13 PM > To: 'rem-conf@es.net' > Cc: Elisabetta Carrara (ERA); David A. McGrew (E-mail); David=20 > Oran (E-mail); Mats N=E4slund (ERA) [mats.n=20 > aslund@era-t.ericsson.se] (E-mail) > Subject: SRTP and cryptographic context management >=20 >=20 > Hi > I think we will need the ability to alter or replace the > cryptographic context during an RTP session. As I > read it, the cryptographic context is identified by > the SSRC of the sender and the RTP destination=20 > transport-address. That suggests to me that you cannot=20 > change the crypto context during the life of an RTP session.=20 > It may not be necessary to, say, replace an AES key for the=20 > life of the longest RTP session imaginable. But it is common=20 > to manage access control to session data by managing the key.=20 > There's no way to do that with a fixed crypto context. >=20 > thanks, Mark=20 >=20 >=20 From rem-conf Tue Mar 13 13:00:09 2001 From rem-conf-request@es.net Tue Mar 13 13:00:09 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cvrD-0004fj-00; Tue, 13 Mar 2001 12:57:27 -0800 Received: from garcia.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14cvrB-0004fV-00; Tue, 13 Mar 2001 12:57:25 -0800 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 833302; Tue, 13 Mar 2001 15:58:16 -0500 Message-ID: <3AAE88D9.646BD859@21rst-century.com> Date: Tue, 13 Mar 2001 15:53:46 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Michael Thomas CC: Mark Baugher ,"'rem-conf@es.net'" , "Elisabetta Carrara (ERA)" ,"David A. McGrew (E-mail)" ,"David Oran (E-mail)" ,"Mats =?iso-8859-1?Q?N=E4slund?=(ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: Re: SRTP and cryptographic context management References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> <15022.34156.204692.692119@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > Mark Baugher writes: > > Hi > > I think we will need the ability to alter or replace the > > cryptographic context during an RTP session. As I > > read it, the cryptographic context is identified by > > the SSRC of the sender and the RTP destination > > transport-address. That suggests to me that you cannot > > change the crypto context during the life of an RTP session. > > It may not be necessary to, say, replace an AES > > key for the life of the longest RTP session imaginable. > > But it is common to manage access control to > > session data by managing the key. There's no way > > to do that with a fixed crypto context. > > Mark, > > While I agree that it may be good to have the > ability to rekey, the mechanisms for rekeying are > (obviously?) out of scope for SRTP. Is there > something in particular about SRTP that makes > rekeying synchronization difficult/impossible? > Also: is it strictly necessasry to solve this in > the RTP plane? Ie, would it be possible to just > create a new session (SSRC) and delete the old one > to affect the keying cutover? > > Mike Any multicast X-on-demand or subscription channels based on encryption is likely to have some sort of frequent rekeying, probably based on a "wheel with wheels" scheme - with frequently changing short keys sent out encrypted to be decoded with longer lasting keys sent out of band. It's hard to see how else to avoid people sharing keys. I do not think that if you are rekeying every 10 seconds you will want to create a new session each time. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Tue Mar 13 13:15:44 2001 From rem-conf-request@es.net Tue Mar 13 13:15:44 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cw76-00067e-00; Tue, 13 Mar 2001 13:13:52 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cw74-000670-00; Tue, 13 Mar 2001 13:13:50 -0800 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06275; Tue, 13 Mar 2001 13:12:45 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-68.cisco.com [10.21.64.68]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABI63910; Tue, 13 Mar 2001 13:12:43 -0800 (PST) Message-Id: <4.3.2.7.2.20010313130232.00b66358@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 13:11:52 -0800 To: Michael Thomas From: Mark Baugher Subject: Re: SRTP and cryptographic context management Cc: "'rem-conf@es.net'" , "Elisabetta Carrara (ERA)" , "David A. McGrew (E-mail)" , "David Oran (E-mail)" , =?iso-8859-1?Q?=22Mats_N=E4slund_=28ERA=29_=5Bmats=2En__aslund=40era-t=2Eeric?= =?iso-8859-1?Q?sson=2Ese=5D_=28E-mail=29=22?= In-Reply-To: <15022.34156.204692.692119@thomasm-u1.cisco.com> References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi, At 12:39 PM 3/13/2001 -0800, Michael Thomas wrote: >Mark, > >While I agree that it may be good to have the >ability to rekey, the mechanisms for rekeying are >(obviously?) out of scope for SRTP. Is there >something in particular about SRTP that makes >rekeying synchronization difficult/impossible? >Also: is it strictly necessasry to solve this in >the RTP plane? Ie, would it be possible to just >create a new session (SSRC) and delete the old one >to affect the keying cutover? I'm not sure it's necessary to solve this in SRTP, but SRTP needs to support a variety of key management alternatives. I have not considered this at length, but maybe a separate profile could be developed for SRTP and for each key management protocol. Otherwise, a key management index (like a SPI) would probably need to be added to SRTP if we all believe that it's necessary to be able to change the cryptographic context of an existing session. Changing keys is quite common in the TV broadcast world with vendors advertising their product's ability to change keys multiple times per second. Mark > Mike From rem-conf Tue Mar 13 13:30:07 2001 From rem-conf-request@es.net Tue Mar 13 13:30:06 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cwKp-00077i-00; Tue, 13 Mar 2001 13:28:03 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cwKn-00077I-00; Tue, 13 Mar 2001 13:28:01 -0800 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA16524; Tue, 13 Mar 2001 13:26:56 -0800 (PST) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABW01736 (AUTH mcgrew); Tue, 13 Mar 2001 13:26:52 -0800 (PST) Sender: mcgrew@cisco.com Message-ID: <3AAE9178.85D394C5@cisco.com> Date: Tue, 13 Mar 2001 16:30:32 -0500 From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher CC: "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , "Mats =?iso-8859-1?Q?N=E4slund?=(ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: Re: SRTP and cryptographic context management References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark, Mark Baugher wrote: > > Hi > I think we will need the ability to alter or replace the > cryptographic context during an RTP session. As I > read it, the cryptographic context is identified by > the SSRC of the sender and the RTP destination > transport-address. That suggests to me that you cannot > change the crypto context during the life of an RTP session. > It may not be necessary to, say, replace an AES > key for the life of the longest RTP session imaginable. > But it is common to manage access control to > session data by managing the key. There's no way > to do that with a fixed crypto context. > > thanks, Mark thanks for representing the multicast perspective here! If I understand correctly, you are thinking of using SRTP encryption as an access control method in a multicast scenario. That usage would certainly be in scope. In the current draft, there is a real need to have a unique SSRC-to-key mapping, since SRTP uses the synchronization information that's already in RTP (the SSRC is used to identify a context, and the RTP sequence number is used as well). I suppose that it would be possible to change keys in a context as long as the new key were identified with a particular sequence number (so that all receivers would know when to start using that key). This approach might work, though I hadn't considered it before; we've made the simplifying assumption of ssrc/key uniqueness. I recall that a similar issue has come up in SMUG before (Brian Weis pointed out some of the problems with changing keys in an IPSEC SA without changing the SPI), though I'm not sure what happend to that proposal. In large group security (a la SMUG), it may not be necessary to change the group key every time a group member is added. For the purposes of access control (e.g., pay tv), changing the keys is most likely not needed. (If someone wants to watch Lethal Weapon XIV five minutes after that movie has started, who cares whether or not they can decrypt the first five minutes?) OTOH, in a high security setting (e.g., a general addressing his entire army via multicast), changing the group key when a member is added would be a good thing. I think that SRTP as it stands supports digital rights management reasonably well - it's secure for one sender, many receivers (though without digital signatures on packets), and possible to add members at any time. Please let me know if I've missed something, though. thanks, David From rem-conf Tue Mar 13 14:13:56 2001 From rem-conf-request@es.net Tue Mar 13 14:13:55 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cx0p-0001N3-00; Tue, 13 Mar 2001 14:11:27 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cx0n-0001MG-00; Tue, 13 Mar 2001 14:11:26 -0800 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA20244; Tue, 13 Mar 2001 14:10:27 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-68.cisco.com [10.21.64.68]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABI65173; Tue, 13 Mar 2001 14:10:20 -0800 (PST) Message-Id: <4.3.2.7.2.20010313131214.03ee2b00@mail.potlnd1.or.home.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 14:09:31 -0800 To: "David R. Oran" From: Mark Baugher Subject: RE: SRTP and cryptographic context management Cc: "'Mark Baugher'" , , "'Elisabetta Carrara \(ERA\)'" , "'David A. McGrew \(E-mail\)'" , =?iso-8859-1?Q?=22=27Mats_N=E4slund__=5C=28ERA=5C=29_=5Bmats=2En__aslund=40era-t=2E?= =?iso-8859-1?Q?erics_son=2Ese=5D_=5C=28E-mail=5C=29=27=22?= In-Reply-To: <01b301c0abff$27b90160$0bd245ab@cisco.com> References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 03:49 PM 3/13/2001 -0500, David R. Oran wrote: >Don't you need a signaling exchange to negotiate the new key? That could >just start a new RTP session, or re-sync on an SSRC change via RTCP. Right. The signalling is outside of RTP though there needs to be some interface between the key management process and SRTP processing if we want to support a variety of key management systems for SRTP. I think we want SRTP to be able to use a variety of key management systems. It strikes me as being a better solution if we don't have to disrupt the RTP session to change the cryptographic context. Mark > > -----Original Message----- > > From: Mark Baugher [mailto:mbaugher@cisco.com] > > Sent: Tuesday, March 13, 2001 3:13 PM > > To: 'rem-conf@es.net' > > Cc: Elisabetta Carrara (ERA); David A. McGrew (E-mail); David > > Oran (E-mail); Mats N=E4slund (ERA) [mats.n > > aslund@era-t.ericsson.se] (E-mail) > > Subject: SRTP and cryptographic context management > > > > > > Hi > > I think we will need the ability to alter or replace the > > cryptographic context during an RTP session. As I > > read it, the cryptographic context is identified by > > the SSRC of the sender and the RTP destination > > transport-address. That suggests to me that you cannot > > change the crypto context during the life of an RTP session. > > It may not be necessary to, say, replace an AES key for the > > life of the longest RTP session imaginable. But it is common > > to manage access control to session data by managing the key. > > There's no way to do that with a fixed crypto context. > > > > thanks, Mark > > > > From rem-conf Tue Mar 13 15:37:21 2001 From rem-conf-request@es.net Tue Mar 13 15:37:21 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14cyIo-0004P5-00; Tue, 13 Mar 2001 15:34:06 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14cyIm-0004N8-00; Tue, 13 Mar 2001 15:34:04 -0800 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA25899; Tue, 13 Mar 2001 15:33:01 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-68.cisco.com [10.21.64.68]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABI67158; Tue, 13 Mar 2001 15:32:58 -0800 (PST) Message-Id: <4.3.2.7.2.20010313150232.03ef86e8@mail.potlnd1.or.home.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 15:32:08 -0800 To: "David A. McGrew" From: Mark Baugher Subject: Re: SRTP and cryptographic context management Cc: Mark Baugher , "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , =?iso-8859-1?Q?=22Mats_N=E4slund=28ERA=29_=5Bmats=2En__aslund=40era-t=2Eerics?= =?iso-8859-1?Q?son=2Ese=5D_=28E-mail=29=22?= In-Reply-To: <3AAE9178.85D394C5@cisco.com> References: <4.3.2.7.2.20010313105202.03f06358@mail.potlnd1.or.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi David, At 04:30 PM 3/13/2001 -0500, David A. McGrew wrote: >thanks for representing the multicast perspective here! If I understand >correctly, you are thinking of using SRTP encryption as an access control >method >in a multicast scenario. That usage would certainly be in scope. I think there are reasons for changing the cryptographic context for unicast RTP sessions. If TV Conditional Access vendors change the key for digital broadcast, I expect they may choose to do the same thing for on-demand streams. Why they do it is another matter and the number of reasons may be as numerous as the number of proprietary CA products on the market. There are subscription schemes that I have heard of that control access by forcing the user to refresh a key prior to the end of a pre-determined lifetime. Seems odd to do that in the middle of an RTP session, but I would not rule that out. Finally, you may have a short key and a long RTP session, which forces the need to refresh the key from time to time. Do we really want to tear down the RTP session to accomplish that? >In the current draft, there is a real need to have a unique SSRC-to-key >mapping, >since SRTP uses the synchronization information that's already in RTP (the >SSRC >is used to identify a context, and the RTP sequence number is used as >well). I >suppose that it would be possible to change keys in a context as long as >the new >key were identified with a particular sequence number (so that all receivers >would know when to start using that key). This approach might work, though I >hadn't considered it before; we've made the simplifying assumption of ssrc/key >uniqueness. If the context were associated with a particular source to an RTP Session, then you would have the SSRC-to-key mapping, right? But if you are changing the keys then there would be two contexts mapping to the SSRC for a period of time, until the key change is accomplished for all receivers. Now could the RTP sequence number serve as the index into the security context? I think this could be a problem for RTP Translators. I don't know if it would be good to overload the sequence number in that way. >I recall that a similar issue has come up in SMUG before (Brian Weis >pointed out >some of the problems with changing keys in an IPSEC SA without changing the >SPI), though I'm not sure what happend to that proposal. GDOI needs an index into the cryptographic context, which would be an application-layer SA for SRTP. GDOI allows the cryptographic context to be changed using a GROUPKEY-PUSH message that can be sent unicast or multicast to members. But the SPI or index to the context must change if the key changes in GDOI. >In large group security (a la SMUG), it may not be necessary to change the >group >key every time a group member is added. For the purposes of access control >(e.g., pay tv), changing the keys is most likely not needed. (If someone >wants >to watch Lethal Weapon XIV five minutes after that movie has started, who >cares >whether or not they can decrypt the first five minutes?) OTOH, in a high >security setting (e.g., a general addressing his entire army via multicast), >changing the group key when a member is added would be a good thing. > >I think that SRTP as it stands supports digital rights management reasonably >well - it's secure for one sender, many receivers (though without digital >signatures on packets), and possible to add members at any time. Please >let me >know if I've missed something, though. Do you agree that some provision must be made for changing the key, and thus the crypto context, during the life of an RTP session? Mark >thanks, > >David From rem-conf Tue Mar 13 17:09:21 2001 From rem-conf-request@es.net Tue Mar 13 17:09:21 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14czjs-0006uk-00; Tue, 13 Mar 2001 17:06:08 -0800 Received: from pop137-mc.mail.com [165.251.48.113] by mail1.es.net with esmtp (Exim 1.81 #2) id 14czjm-0006ua-00; Tue, 13 Mar 2001 17:06:07 -0800 Received: from 62.157.95.1 (node103dd.a2000.nl [24.132.3.221]) by pop137-mc.mail.com (Postfix) with SMTP id 325B8218D0; Tue, 13 Mar 2001 20:05:44 -0500 (EST) Message-ID: <00004aa140dc$00002543$00003f08@195.8.78.28> To: From: 5436787441@mailandnews.com Subject: you gotta check this out Date: Mon, 12 Mar 2001 20:12:40 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: 5436787441@mailandnews.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

I Miss You SOOOOOOOO Bad!!!!

I am sitting here at work thinking = about how good it would feel to have your hands sliding up my skirt.(I don't hav= e any panties on!) I'm so horny right now!

I just remembered. I have my d= igital camera with me. I'll take some pictures for you to look at. Hehe. I'm so b= ad today.

Click here to see the pics I took for you bad boy.

Click here if you don't want any more naughty letters from me.

Do ya soon!

Misty

From rem-conf Tue Mar 13 17:51:34 2001 From rem-conf-request@es.net Tue Mar 13 17:51:33 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d0Pi-0001BJ-00; Tue, 13 Mar 2001 17:49:22 -0800 Received: from mc4as17-81-152-26.cw-visp.com (Lazy Income) [212.137.152.26] by mail1.es.net with smtp (Exim 1.81 #2) id 14d0Pf-0001B9-00; Tue, 13 Mar 2001 17:49:21 -0800 From: Robert Gregory To: Message-Id: <419.436964.08123947must-read-info@my-word-is-my-bond.co.uk> Subject: How's this for a 'brain-storming' idea?!? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 13 Mar 2001 17:49:21 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Visit this site and I GUARANTEE your weekends will never be the same again. The information on this site must be read over twice, because the first time you read it, you simply will not believe it! Now - don't read another e-mail until you have visited: http://www.lazyincome.co.uk ************************** AOL users: Click Here ************************** ************************ For any queries regarding this service or your subscription to this service, send an e- mail to bobty@lycos.com ************************ From rem-conf Tue Mar 13 18:23:19 2001 From rem-conf-request@es.net Tue Mar 13 18:23:18 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d0uC-0002R6-00; Tue, 13 Mar 2001 18:20:52 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d0uA-0002Qw-00; Tue, 13 Mar 2001 18:20:50 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA07390; Tue, 13 Mar 2001 21:04:28 -0500 Message-Id: <200103140204.VAA07390@purple.east.isi.edu> To: "David A. McGrew" cc: Mark Baugher , "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , "Mats Ndslund(ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: Re: SRTP and cryptographic context management In-Reply-To: Message from "David A. McGrew" of "Tue, 13 Mar 2001 16:30:32 EST." <3AAE9178.85D394C5@cisco.com> Date: Tue, 13 Mar 2001 21:04:28 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "David A. McGrew" writes: >Mark, > >Mark Baugher wrote: >> >> Hi >> I think we will need the ability to alter or replace the >> cryptographic context during an RTP session. As I >> read it, the cryptographic context is identified by >> the SSRC of the sender and the RTP destination >> transport-address. That suggests to me that you cannot >> change the crypto context during the life of an RTP session. >> It may not be necessary to, say, replace an AES >> key for the life of the longest RTP session imaginable. >> But it is common to manage access control to >> session data by managing the key. There's no way >> to do that with a fixed crypto context. >> >> thanks, Mark > >thanks for representing the multicast perspective here! If I understand >correctly, you are thinking of using SRTP encryption as an access control method >in a multicast scenario. That usage would certainly be in scope. > >In the current draft, there is a real need to have a unique SSRC-to-key mapping, >since SRTP uses the synchronization information that's already in RTP (the SSRC >is used to identify a context, and the RTP sequence number is used as well). I >suppose that it would be possible to change keys in a context as long as the new >key were identified with a particular sequence number (so that all receivers >would know when to start using that key). This approach might work, though I >hadn't considered it before; we've made the simplifying assumption of ssrc/key >uniqueness. It sounds feasible, so long as it is possible to inform all receivers of the new key within a single cycle of the RTP sequence number. That might be a problem with high-rate streams, or with large groups. Colin From rem-conf Tue Mar 13 18:52:39 2001 From rem-conf-request@es.net Tue Mar 13 18:52:38 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d1MM-0003kw-00; Tue, 13 Mar 2001 18:49:58 -0800 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d1MK-0003kf-00; Tue, 13 Mar 2001 18:49:56 -0800 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA11013; Tue, 13 Mar 2001 18:41:33 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE31440; Tue, 13 Mar 2001 18:41:12 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA08050; Tue, 13 Mar 2001 18:41:12 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15022.55880.75594.861987@thomasm-u1.cisco.com> Date: Tue, 13 Mar 2001 18:41:12 -0800 (PST) To: Colin Perkins Cc: "David A. McGrew" , Mark Baugher , "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , "Mats Ndslund(ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: Re: SRTP and cryptographic context management In-Reply-To: <200103140204.VAA07390@purple.east.isi.edu> References: <3AAE9178.85D394C5@cisco.com> <200103140204.VAA07390@purple.east.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins writes: > --> "David A. McGrew" writes: > >In the current draft, there is a real need to have a unique SSRC-to-key mapping, > >since SRTP uses the synchronization information that's already in RTP (the SSRC > >is used to identify a context, and the RTP sequence number is used as well). I > >suppose that it would be possible to change keys in a context as long as the new > >key were identified with a particular sequence number (so that all receivers > >would know when to start using that key). This approach might work, though I > >hadn't considered it before; we've made the simplifying assumption of ssrc/key > >uniqueness. > > It sounds feasible, so long as it is possible to inform all receivers of > the new key within a single cycle of the RTP sequence number. That might > be a problem with high-rate streams, or with large groups. Probably no need to be constrained that way: so long as the virtual longword sequence number is the thing that is used to identify the actual sequence number, there shouldn't be a time constraint. Since SRTP keeps that counter anyway (and is periodically advertised in RTCP), I wouldn't think that that would be much of a problem. Mike From rem-conf Tue Mar 13 18:57:05 2001 From rem-conf-request@es.net Tue Mar 13 18:57:05 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d1RZ-0004HF-00; Tue, 13 Mar 2001 18:55:21 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d1RW-0004G7-00; Tue, 13 Mar 2001 18:55:19 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA07491; Tue, 13 Mar 2001 21:18:26 -0500 Message-Id: <200103140218.VAA07491@purple.east.isi.edu> To: coldrenr@agcs.com cc: "Hussain, Arshad, NNAD" , Rajesh Kumar , rem-conf@es.net, schulzrinne@cs.columbia.edu, scott.petrack@metatel.com Subject: Re: Error in rfc2833? In-Reply-To: Message from Rex Coldren of "Fri, 09 Mar 2001 13:47:17 MST." <3AA94154.6E1E692A@agcs.com> Date: Tue, 13 Mar 2001 21:18:26 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Seems like we have agreement. Henning or Scott, can you prepare an Internet draft with this change? We can then consider issuing a new RFC to obsolete RFC 2833 (depending on how urgent people consider this fix, we can either cycle at proposed standard, or go for draft standard once RTP itself has advanced). Colin --> Rex Coldren writes: >Well, that would make life interesting for folks who have already implemented >events in the range of 144 and above. Events 144-159 are the ABCD trunking >events. I know of several implementations using those that would be impacted >by your suggestion. There are probably more out there. > >It sounds like implementations using MF S1..S3 are just now being considered >since nobody has noticed this yet. I propose that we deprecate event numbers >142 and 143 and assign new event numbers for S1..S3 at the end of the current >range. That will keep existing implementations from being impacted. > >Best Regards, >Rex Coldren > >"Hussain, Arshad, NNAD" wrote: > >> My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else. >> >> Arshad Hussain >> >> A2-3D17 >> >> 200 Laurel Ave. S. >> >> Middletown, NJ 07748 >> >> (732) 420-5915 >> >> -----Original Message----- >> From: Rajesh Kumar [mailto:rkumar@cisco.com] >> Sent: Friday, March 09, 2001 3:26 AM >> To: rem-conf@es.net >> Subject: Error in rfc2833? >> >> AVT group, >> >> The following discrepancy was brought to my notice: >> >> in rfc2833, Table 6 (Trunk events) has >> >> MF S1...S3 assigned to 142...143 >> >> Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number >> values on the right. >> >> Have others noticed this problem? What would be a standard, inter-operable way for the industry >to >> work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? >> >> I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group >. >> >> >> Thanks. >> >> Rajesh >> ------------------------------------- >> Dr. Rajesh Kumar, Principal Engineer >> Cisco Voice Technology Center >> Tel: 408-527-0811, Fax: 408-853-1101 >> Epage: mailto:rkumar@epage.cisco.com >> ------------------------------------- From rem-conf Tue Mar 13 20:08:12 2001 From rem-conf-request@es.net Tue Mar 13 20:08:12 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d2Uj-0007CL-00; Tue, 13 Mar 2001 20:02:41 -0800 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d2Uh-0007CB-00; Tue, 13 Mar 2001 20:02:39 -0800 Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id VAA10160 for ; Tue, 13 Mar 2001 21:02:38 -0700 (MST) Posted-Date: Tue, 13 Mar 2001 21:02:38 -0700 (MST) Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Tue Mar 13 21:02:40 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id VAA26911 for ; Tue, 13 Mar 2001 21:02:23 -0700 (MST) Received: from agcs.com ([130.131.56.107]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA2427; Tue, 13 Mar 2001 21:02:34 -0700 Message-ID: <3AAEED5B.493DD8F2@agcs.com> Date: Tue, 13 Mar 2001 21:02:35 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: "Hussain, Arshad, NNAD" , Rajesh Kumar , rem-conf@es.net, schulzrinne@cs.columbia.edu, scott.petrack@metatel.com Subject: Re: Error in rfc2833? References: <200103140218.VAA07491@purple.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks, Colin. I hadn't heard anything since this exchange and was wondering if my rem-conf subscription had expired! Anyway, it seems like the only way to fix this problem. Not a big deal, though. The RFC is technically sound. This was just an editorial oversight for sure. Rex Colin Perkins wrote: > Seems like we have agreement. Henning or Scott, can you prepare an Internet > draft with this change? We can then consider issuing a new RFC to obsolete > RFC 2833 (depending on how urgent people consider this fix, we can either > cycle at proposed standard, or go for draft standard once RTP itself has > advanced). > > Colin > > --> Rex Coldren writes: > >Well, that would make life interesting for folks who have already implemented > >events in the range of 144 and above. Events 144-159 are the ABCD trunking > >events. I know of several implementations using those that would be impacted > >by your suggestion. There are probably more out there. > > > >It sounds like implementations using MF S1..S3 are just now being considered > >since nobody has noticed this yet. I propose that we deprecate event numbers > >142 and 143 and assign new event numbers for S1..S3 at the end of the current > >range. That will keep existing implementations from being impacted. > > > >Best Regards, > >Rex Coldren > > > >"Hussain, Arshad, NNAD" wrote: > > > >> My proposal will be to use the next number, i.e. S3=144 unless it is used by some thing else. > >> > >> Arshad Hussain > >> > >> A2-3D17 > >> > >> 200 Laurel Ave. S. > >> > >> Middletown, NJ 07748 > >> > >> (732) 420-5915 > >> > >> -----Original Message----- > >> From: Rajesh Kumar [mailto:rkumar@cisco.com] > >> Sent: Friday, March 09, 2001 3:26 AM > >> To: rem-conf@es.net > >> Subject: Error in rfc2833? > >> > >> AVT group, > >> > >> The following discrepancy was brought to my notice: > >> > >> in rfc2833, Table 6 (Trunk events) has > >> > >> MF S1...S3 assigned to 142...143 > >> > >> Evidently, there are three events (S1, S2, S3) on the left hand side and only two event number > >> values on the right. > >> > >> Have others noticed this problem? What would be a standard, inter-operable way for the industry > >to > >> work around it? If we were to assign S1=142 and S2=143, which number should we assign to S3? > >> > >> I request Henning Schulzrinne or Scott Petrack to make a decision and circulate it to the group > >. > >> > >> > >> Thanks. > >> > >> Rajesh > >> ------------------------------------- > >> Dr. Rajesh Kumar, Principal Engineer > >> Cisco Voice Technology Center > >> Tel: 408-527-0811, Fax: 408-853-1101 > >> Epage: mailto:rkumar@epage.cisco.com > >> ------------------------------------- From rem-conf Tue Mar 13 21:31:59 2001 From rem-conf-request@es.net Tue Mar 13 21:31:58 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d3mR-0001sN-00; Tue, 13 Mar 2001 21:25:03 -0800 Received: from e1.ny.us.ibm.com [32.97.182.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d3mP-0001s0-00; Tue, 13 Mar 2001 21:25:02 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA97852; Wed, 14 Mar 2001 00:23:43 -0500 Received: from d02ml251.somers.hqregion.ibm.com (d02ml251.sby.ibm.com [9.45.4.178]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id AAA39162; Wed, 14 Mar 2001 00:20:45 -0500 Importance: Normal Subject: Re: SRTP and cryptographic context management To: Mark Baugher Cc: "David A. McGrew" , Mark Baugher , "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , "Mats =?iso-8859-1?Q?N=E4slund=28ERA=29_[mats=2En_aslund=40era-t=2Eericsson=2E?= =?us-ascii?Q?se?= =?us-ascii?Q?]_=28?= =?us-ascii?Q?E?= =?us-ascii?Q?-mail?= =?us-ascii?Q?=29?=" X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Peter Schirling" Date: Wed, 14 Mar 2001 13:21:54 +0900 X-MIMETrack: Serialize by Router on D02ML251/02/M/IBM(Release 5.0.6a |January 17, 2001) at 03/14/2001 12:24:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark, all, Mark's rationale and requirement are sound... an example may be that th= e first 5 minutes are free to air and the remainder are paid... Broadcasters/multicasters alike will always want to change key sets sometimes are as often as once every 5-10 seconds and in some case even= more often. The MPEG-2 mux has a 2 bit field to signal which key set to use. The ke= y data is pre-loaded via a set of tables (themselves encrypted) such that= when the field in the stream switches value, the decryption engine alre= ady has the new key to use... This needs to be the same sort of simple key switch signalling capabili= ty. Pete Schirling Digital Media Standards and Commercialisation IBM Research Division Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362 Mobile text messaging 8022382036@msg.myvzw.com Internet e-mail: schirlin@us.ibm.com Mark Baugher on 03/14/2001 08:32:08 AM To: "David A. McGrew" cc: Mark Baugher , "'rem-conf@es.net'" , Elisabetta Carrara (ERA) , David Oran (E-mail) , "Mats N=E4slund(ERA) [mats.n aslund@era-t.ericsson.se] (E-mail)" Subject: Re: SRTP and cryptographic context management Hi David, At 04:30 PM 3/13/2001 -0500, David A. McGrew wrote: >thanks for representing the multicast perspective here! If I understa= nd >correctly, you are thinking of using SRTP encryption as an access cont= rol >method >in a multicast scenario. That usage would certainly be in scope. I think there are reasons for changing the cryptographic context for unicast RTP sessions. If TV Conditional Access vendors change the key for digital broadcast, I expect they may choose to do the same thing for on-demand streams. Why they do it is another matter and the number of reasons may be as numerous as the number of proprietary CA products on the market. There are subscription schemes that I have heard of that control access by forcing the user to refresh a key prior to the end of a pre-determined lifetime. Seems odd to do that in the middle o= f an RTP session, but I would not rule that out. Finally, you may have a short key and a long RTP session, which forces the need to refresh th= e key from time to time. Do we really want to tear down the RTP session to accomplish that? >In the current draft, there is a real need to have a unique SSRC-to-ke= y >mapping, >since SRTP uses the synchronization information that's already in RTP = (the >SSRC >is used to identify a context, and the RTP sequence number is used as >well). I >suppose that it would be possible to change keys in a context as long = as >the new >key were identified with a particular sequence number (so that all receivers >would know when to start using that key). This approach might work, though I >hadn't considered it before; we've made the simplifying assumption of ssrc/key >uniqueness. If the context were associated with a particular source to an RTP Sessi= on, then you would have the SSRC-to-key mapping, right? But if you are changing= the keys then there would be two contexts mapping to the SSRC for a period of ti= me, until the key change is accomplished for all receivers. Now could the RTP sequence number serve as the index into the security context? I think this coul= d be a problem for RTP Translators. I don't know if it would be good to overload the sequence number in that way. >I recall that a similar issue has come up in SMUG before (Brian Weis >pointed out >some of the problems with changing keys in an IPSEC SA without changin= g the >SPI), though I'm not sure what happend to that proposal. GDOI needs an index into the cryptographic context, which would be an application-layer SA for SRTP. GDOI allows the cryptographic context = to be changed using a GROUPKEY-PUSH message that can be sent unicast or multicast to members. But the SPI or index to the context must chan= ge if the key changes in GDOI. >In large group security (a la SMUG), it may not be necessary to change= the >group >key every time a group member is added. For the purposes of access control >(e.g., pay tv), changing the keys is most likely not needed. (If some= one >wants >to watch Lethal Weapon XIV five minutes after that movie has started, = who >cares >whether or not they can decrypt the first five minutes?) OTOH, in a = high >security setting (e.g., a general addressing his entire army via multicast), >changing the group key when a member is added would be a good thing. > >I think that SRTP as it stands supports digital rights management reasonably >well - it's secure for one sender, many receivers (though without digi= tal >signatures on packets), and possible to add members at any time. Plea= se >let me >know if I've missed something, though. Do you agree that some provision must be made for changing the key, and= thus the crypto context, during the life of an RTP session? Mark >thanks, > >David = From rem-conf Wed Mar 14 00:51:36 2001 From rem-conf-request@es.net Wed Mar 14 00:51:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d6ur-0007KP-00; Wed, 14 Mar 2001 00:45:57 -0800 Received: from (vivaldi.vcon.co.il) [212.29.219.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d6up-0007I7-00; Wed, 14 Mar 2001 00:45:55 -0800 Received: by vivaldi.vcon.co.il with Internet Mail Service (5.5.2650.21) id <1Q5AZ8Q3>; Wed, 14 Mar 2001 10:48:56 +0200 Message-ID: <28620B5447EFD311919000600860FCB2BBF984@vivaldi.vcon.co.il> From: Haggai Carmon To: rem-conf@es.net Subject: Date: Wed, 14 Mar 2001 10:48:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC63.94955BD0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AC63.94955BD0 Content-Type: text/plain; charset="windows-1255" Remove ------_=_NextPart_001_01C0AC63.94955BD0 Content-Type: text/html; charset="windows-1255"

Remove

------_=_NextPart_001_01C0AC63.94955BD0-- From rem-conf Wed Mar 14 00:51:40 2001 From rem-conf-request@es.net Wed Mar 14 00:51:39 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14d6uh-0007K8-00; Wed, 14 Mar 2001 00:45:47 -0800 Received: from (vivaldi.vcon.co.il) [212.29.219.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 14d6uf-0007I6-00; Wed, 14 Mar 2001 00:45:46 -0800 Received: by vivaldi.vcon.co.il with Internet Mail Service (5.5.2650.21) id <1Q5AZ8QN>; Wed, 14 Mar 2001 10:48:46 +0200 Message-ID: <28620B5447EFD311919000600860FCB2BBF983@vivaldi.vcon.co.il> From: Haggai Carmon To: rem-conf@es.net Subject: Date: Wed, 14 Mar 2001 10:48:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AC63.8F7149C0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AC63.8F7149C0 Content-Type: text/plain; charset="windows-1255" Unsubscribe ------_=_NextPart_001_01C0AC63.8F7149C0 Content-Type: text/html; charset="windows-1255"

Unsubscribe

------_=_NextPart_001_01C0AC63.8F7149C0-- From rem-conf Wed Mar 14 04:42:11 2001 From rem-conf-request@es.net Wed Mar 14 04:42:10 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dAVN-0005ub-00; Wed, 14 Mar 2001 04:35:53 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dAVL-0005uR-00; Wed, 14 Mar 2001 04:35:51 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA07565; Wed, 14 Mar 2001 13:35:45 +0100 (MET) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma007558; Wed, 14 Mar 01 13:35:46 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA28489; Wed, 14 Mar 2001 13:35:42 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA14172; Wed, 14 Mar 2001 13:35:41 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900016599671; Wed, 14 Mar 2001 13:47:22 +0100 To: , Cc: Subject: RE: MP4 Player Available for Download Message-ID: <0056900016599671000002L012*@MHS> Reply-To: <"CN=Philippe Gentric/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1"@unregistered.philips.com> Date: Wed, 14 Mar 2001 13:47:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/14/01 13:34:06" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: BNowicki@Omneon.com [mailto:BNowicki@Omneon.com] > Sent: Tuesday, March 13, 2001 21:09 > To: hari@FLAVORSOFTWARE.com > Cc: rem-conf@es.net > Subject: RE: MP4 Player Available for Download >=20 > We just tried the obvious experiment. >=20 > The ".mp4" files on the "Flavor" site do not play with the > Philips player, and the Philips ".mp4" files do not play with > the Flavor player. Sounds like a litle inter-operability > testing might have been in order before calling them the same > name! >=20 > (and of course file format standards are outside the charter > of IETF, but are still useful) Well trying to breed a mouse and an elephant does not work either (so far) although both are mamals :-) ************************************* - Our player plays MPEG-4 video and MPEG-4 audio (AAC or CELP depending on target total bit rate) and that is what our .mp4 files contain. - FlavorSoftware has a completely different type of content: it seems to be a slide show (did not dig in to get the picture type ?) with some .mp3 (?) audio encapsulated in an .mp4 file ************************************* The issue here is that .mp4 is a very versatile container format into which a very large number of very different content can be stored. (BTW 3GPP recently adopted .mp4 for AMR and H263 in audio/video message/record applications) In general MPEG-4 can be seen as a "toolbox" (just as previous MPEGs were). Interop requires that other bodies (such as DVD, DVB etc did for MPEG-2) specify for given applications the exact set of tools/profiles/levels that are required for conformance/interop. This is *exactly* the purpose of ISMA (http://www.isma.tv) which recent forum attracted=20 more than 75 companies. Interop tests are a key item=20 in the ISMA agenda. Furthermore the MPEG-4 Industry Forum (M4IF http://www.m4if.org) is also organizing interop testing around "focus groups" i.e. companies/organizations focusing on a specific subset of the toolbox useful for specific applications. ************************************* So stay tuned, these are only the first "MPEG-4 products" of a rapidly rising MPEG-4 wave and we simply need more key words to=20 accurately describe them... Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com Check our web site at: www.mpeg-4player.com = From rem-conf Wed Mar 14 06:20:06 2001 From rem-conf-request@es.net Wed Mar 14 06:20:05 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dC2f-00010P-00; Wed, 14 Mar 2001 06:14:21 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dC2Y-00010D-00; Wed, 14 Mar 2001 06:14:19 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA26923; Wed, 14 Mar 2001 09:14:03 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3AAF7CAB.8AF7A33F@cs.columbia.edu> Date: Wed, 14 Mar 2001 09:14:03 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: Colin Perkins , "Hussain, Arshad, NNAD" , Rajesh Kumar , rem-conf@es.net, schulzrinne@cs.columbia.edu, scott.petrack@metatel.com Subject: Re: Error in rfc2833? References: <200103140218.VAA07491@purple.east.isi.edu> <3AAEED5B.493DD8F2@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Rex Coldren wrote: > > Thanks, Colin. I hadn't heard anything since this exchange and was wondering > if my rem-conf subscription had expired! Anyway, it seems like the only way to > fix this problem. Not a big deal, though. The RFC is technically sound. This > was just an editorial oversight for sure. I'll take care of it after the IETF meeting; there have been a few other minor editorial clarifications. I would prefer to go to Draft, assuming there are enough implementations out there. We don't have to contribute to the "the Internet runs on Proposed Standards" problem :-) > > Rex > > Colin Perkins wrote: > > > Seems like we have agreement. Henning or Scott, can you prepare an Internet > > draft with this change? We can then consider issuing a new RFC to obsolete > > RFC 2833 (depending on how urgent people consider this fix, we can either > > cycle at proposed standard, or go for draft standard once RTP itself has > > advanced). > > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Mar 14 06:40:32 2001 From rem-conf-request@es.net Wed Mar 14 06:40:30 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dCP1-0001y0-00; Wed, 14 Mar 2001 06:37:27 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dCOz-0001xI-00; Wed, 14 Mar 2001 06:37:25 -0800 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA26188; Wed, 14 Mar 2001 06:36:11 -0800 (PST) Received: from cisco.com ([171.70.196.154]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABX08785 (AUTH mcgrew); Wed, 14 Mar 2001 06:36:04 -0800 (PST) Sender: mcgrew@cisco.com Message-ID: <3AAF82AA.A9BE2A1F@cisco.com> Date: Wed, 14 Mar 2001 09:39:38 -0500 From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Schirling CC: Mark Baugher , "'rem-conf@es.net'" , "Elisabetta Carrara (ERA)" , "David Oran (E-mail)" , "=?iso-8859-1?Q?MatsN=E4slund?=(ERA) [mats.n aslund@era-t.ericsson.se ] ( E-mail )" Subject: Re: SRTP and cryptographic context management References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-1.cisco.com id GAA26188 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Peter, thanks for your input, more inline: Peter Schirling wrote: >=20 > Mark, all, >=20 > Mark's rationale and requirement are sound... an example may be that th= e > first 5 minutes are free to air and the remainder are paid... > Broadcasters/multicasters alike will always want to change key sets > sometimes are as often as once every 5-10 seconds and in some case even > more often. >=20 what's the reason for the frequent changes? Do you think that this class= of users will find it essential to enforce such fine-grained access control? > The MPEG-2 mux has a 2 bit field to signal which key set to use. The ke= y > data is pre-loaded via a set of tables (themselves encrypted) such that > when the field in the stream switches value, the decryption engine alre= ady > has the new key to use... Could you please provide me with a pointer to a description of this syste= m? >=20 > This needs to be the same sort of simple key switch signalling capabili= ty. We certainly need to consider supporting five-second key lifetimes, if th= at's the model currently used by MPEG-2. This will definitely be on the agend= a next week! thanks, David mcgrew@cisco.com >=20 > Pete Schirling >=20 > Digital Media Standards and Commercialisation > IBM Research Division > Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362 > Mobile text messaging 8022382036@msg.myvzw.com > Internet e-mail: schirlin@us.ibm.com >=20 > Mark Baugher on 03/14/2001 08:32:08 AM >=20 > To: "David A. McGrew" > cc: Mark Baugher , "'rem-conf@es.net'" > , Elisabetta Carrara (ERA) > , David Oran (E-mail) > , "Mats N=E4slund(ERA) [mats.n > aslund@era-t.ericsson.se] (E-mail)" > Subject: Re: SRTP and cryptographic context management >=20 > Hi David, >=20 > At 04:30 PM 3/13/2001 -0500, David A. McGrew wrote: >=20 > >thanks for representing the multicast perspective here! If I understa= nd > >correctly, you are thinking of using SRTP encryption as an access cont= rol > >method > >in a multicast scenario. That usage would certainly be in scope. >=20 > I think there are reasons for changing the cryptographic context for > unicast > RTP sessions. If TV Conditional Access vendors change the key for > digital broadcast, I expect they may choose to do the same thing for > on-demand streams. Why they do it is another matter and the number of > reasons may be as numerous as the number of proprietary CA products > on the market. There are subscription schemes that I have heard of > that control access by forcing the user to refresh a key prior to the > end of a pre-determined lifetime. Seems odd to do that in the middle o= f > an RTP session, but I would not rule that out. Finally, you may have > a short key and a long RTP session, which forces the need to refresh th= e > key from time to time. Do we really want to tear down the RTP session > to accomplish that? >=20 > >In the current draft, there is a real need to have a unique SSRC-to-ke= y > >mapping, > >since SRTP uses the synchronization information that's already in RTP = (the > >SSRC > >is used to identify a context, and the RTP sequence number is used as > >well). I > >suppose that it would be possible to change keys in a context as long = as > >the new > >key were identified with a particular sequence number (so that all > receivers > >would know when to start using that key). This approach might work, > though I > >hadn't considered it before; we've made the simplifying assumption of > ssrc/key > >uniqueness. >=20 > If the context were associated with a particular source to an RTP Sessi= on, > then > you would have the SSRC-to-key mapping, right? But if you are changing= the > keys > then there would be two contexts mapping to the SSRC for a period of ti= me, > until > the key change is accomplished for all receivers. Now could the RTP > sequence > number serve as the index into the security context? I think this coul= d be > a problem > for RTP Translators. I don't know if it would be good to overload the > sequence number > in that way. >=20 > >I recall that a similar issue has come up in SMUG before (Brian Weis > >pointed out > >some of the problems with changing keys in an IPSEC SA without changin= g > the > >SPI), though I'm not sure what happend to that proposal. >=20 > GDOI needs an index into the cryptographic context, which would be an > application-layer SA for SRTP. GDOI allows the cryptographic context = to > be changed using a GROUPKEY-PUSH message that can be sent unicast > or multicast to members. But the SPI or index to the context must chan= ge > if the key changes in GDOI. >=20 > >In large group security (a la SMUG), it may not be necessary to change= the > >group > >key every time a group member is added. For the purposes of access > control > >(e.g., pay tv), changing the keys is most likely not needed. (If some= one > >wants > >to watch Lethal Weapon XIV five minutes after that movie has started, = who > >cares > >whether or not they can decrypt the first five minutes?) OTOH, in a = high > >security setting (e.g., a general addressing his entire army via > multicast), > >changing the group key when a member is added would be a good thing. > > > >I think that SRTP as it stands supports digital rights management > reasonably > >well - it's secure for one sender, many receivers (though without digi= tal > >signatures on packets), and possible to add members at any time. Plea= se > >let me > >know if I've missed something, though. >=20 > Do you agree that some provision must be made for changing the key, and > thus the crypto context, during the life of an RTP session? >=20 > Mark >=20 > >thanks, > > > >David From rem-conf Wed Mar 14 09:39:18 2001 From rem-conf-request@es.net Wed Mar 14 09:39:17 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dF9W-00063H-00; Wed, 14 Mar 2001 09:33:38 -0800 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dF9V-000637-00; Wed, 14 Mar 2001 09:33:37 -0800 Received: from robla350.real.com ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id JAA05149; Wed, 14 Mar 2001 09:33:32 -0800 (PST) Message-Id: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com> X-Sender: robla@goobox.prognet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 14 Mar 2001 09:35:09 -0800 To: Bill Nowicki , "'Hari Kalva'" From: Rob Lanphier Subject: File formats (RE: MP4 Player Available for Download) Cc: "'rem-conf@es.net'" In-Reply-To: <03AB3CB11CBED3118A4F009027B0C2B1417970@webmail1.omneon.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote: >We just tried the obvious experiment. > >The ".mp4" files on the "Flavor" site do not play with the >Philips player, and the Philips ".mp4" files do not play with >the Flavor player. Sounds like a litle inter-operability >testing might have been in order before calling them the same >name! > >(and of course file format standards are outside the charter >of IETF, but are still useful) Not that I'm disagreeing with you here, but an honest question for you: whose charter includes specifying file formats? Clearly, ISO/MPEG have taken it on, but they've also created a situation where I think genuine interoperability is out of the question for anyone who either doesn't have a patent licensing agreement from 30 different companies, or who chooses to ignore the issue. Is there a standards group out there who does file formats who would actually work toward an unencumbered format? Rob From rem-conf Wed Mar 14 10:11:41 2001 From rem-conf-request@es.net Wed Mar 14 10:11:41 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dFeT-0007Nb-00; Wed, 14 Mar 2001 10:05:37 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dFeM-0007NQ-00; Wed, 14 Mar 2001 10:05:35 -0800 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA17399 for ; Wed, 14 Mar 2001 10:05:12 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 10:05:03 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA27435; Wed, 14 Mar 2001 10:05:03 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com> References: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com> Date: Wed, 14 Mar 2001 10:00:03 -0800 To: Rob Lanphier From: Dave Singer Subject: Re: File formats (RE: MP4 Player Available for Download) Cc: "'rem-conf@es.net'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 9:35 AM -0800 3/14/01, Rob Lanphier wrote: >At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote: >>We just tried the obvious experiment. >> >>The ".mp4" files on the "Flavor" site do not play with the >>Philips player, and the Philips ".mp4" files do not play with >>the Flavor player. Sounds like a litle inter-operability >>testing might have been in order before calling them the same >>name! >> >>(and of course file format standards are outside the charter >>of IETF, but are still useful) > >Not that I'm disagreeing with you here, but an honest question for >you: whose charter includes specifying file formats? Clearly, >ISO/MPEG have taken it on, but they've also created a situation >where I think genuine interoperability is out of the question for >anyone who either doesn't have a patent licensing agreement from 30 >different companies, or who chooses to ignore the issue. > >Is there a standards group out there who does file formats who would >actually work toward an unencumbered format? > >Rob I hate to carry on an off-topic thread, but the MPEG-4 file format is not heavily encumbered. To my knowledge, we (Apple) are the only IPR owners in the file format per se, and the license needed would be the same as for the QT file format (i.e. it's the same IPR), for which we have plenty of examples of licensees (including Real Networks). ISMA will be testing interop very carefully, as Philippe says. And there have been interop tests done under the conformance group at MPEG-4. Now, the encumbrance of MPEG-4 in general is a different matter, as anyone who follows m4if will attest.... -- David Singer Apple Computer/QuickTime From rem-conf Wed Mar 14 10:13:18 2001 From rem-conf-request@es.net Wed Mar 14 10:13:18 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dFgq-0007TS-00; Wed, 14 Mar 2001 10:08:04 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dFga-0007Sb-00; Wed, 14 Mar 2001 10:08:03 -0800 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA18559 for ; Wed, 14 Mar 2001 10:07:32 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 10:07:14 -0800 Received: from [17.202.37.152] (il0203a-dhcp24.apple.com [17.202.37.152]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA15442; Wed, 14 Mar 2001 10:07:14 -0800 (PST) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com> References: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com> Date: Wed, 14 Mar 2001 09:59:58 -0800 To: Rob Lanphier , Bill Nowicki , "'Hari Kalva'" From: Kevin Marks Subject: Re: File formats (RE: MP4 Player Available for Download) Cc: "'rem-conf@es.net'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 9:35 am -0800 14/3/01, Rob Lanphier wrote: >At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote: >>We just tried the obvious experiment. >> >>The ".mp4" files on the "Flavor" site do not play with the >>Philips player, and the Philips ".mp4" files do not play with >>the Flavor player. Sounds like a litle inter-operability >>testing might have been in order before calling them the same >>name! >> >>(and of course file format standards are outside the charter >>of IETF, but are still useful) > >Not that I'm disagreeing with you here, but an honest question for >you: whose charter includes specifying file formats? Clearly, >ISO/MPEG have taken it on, but they've also created a situation >where I think genuine interoperability is out of the question for >anyone who either doesn't have a patent licensing agreement from 30 >different companies, or who chooses to ignore the issue. > >Is there a standards group out there who does file formats who would >actually work toward an unencumbered format? The QuickTime file format is open, documented and freely licensable (its also the basis of the mpeg-4 format). Surely the the patent licensing is associated with the codecs involved, not the file format? From rem-conf Wed Mar 14 10:22:20 2001 From rem-conf-request@es.net Wed Mar 14 10:22:20 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dFpB-0000ev-00; Wed, 14 Mar 2001 10:16:41 -0800 Received: from (LEMON.flavorsoftware.com) [64.232.157.3] by mail1.es.net with smtp (Exim 1.81 #2) id 14dFpA-0000UT-00; Wed, 14 Mar 2001 10:16:40 -0800 Received: by LEMON.flavorsoftware.com with Internet Mail Service (5.5.1960.3) id ; Wed, 14 Mar 2001 13:09:47 -0500 Message-ID: From: Hari Kalva To: 'Rob Lanphier' , 'Bill Nowicki' Cc: "'rem-conf@es.net'" Subject: RE: File formats (RE: MP4 Player Available for Download) Date: Wed, 14 Mar 2001 13:09:41 -0500 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 > -----Original Message----- > From: Rob Lanphier [mailto:robla@real.com] > Sent: Wednesday, March 14, 2001 12:35 PM > To: Bill Nowicki; Hari Kalva > Cc: 'rem-conf@es.net' > Subject: File formats (RE: MP4 Player Available for Download) > > > At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote: > >We just tried the obvious experiment. > > > >The ".mp4" files on the "Flavor" site do not play with the > >Philips player, and the Philips ".mp4" files do not play with > >the Flavor player. Sounds like a litle inter-operability > >testing might have been in order before calling them the same > >name! > > > >(and of course file format standards are outside the charter > >of IETF, but are still useful) > > Not that I'm disagreeing with you here, but an honest question for > you: whose charter includes specifying file formats? > Clearly, ISO/MPEG > have taken it on, but they've also created a situation where I think > genuine interoperability is out of the question for anyone who either > doesn't have a patent licensing agreement from 30 different > companies, or > who chooses to ignore the issue. > > Is there a standards group out there who does file formats who would > actually work toward an unencumbered format? > > Rob I really don't think achieving interoperability is difficult in this particular case of MP4 formats. MPEG has defined Profiles/Levels to essentially make this possible. There is also a conformance group looking into these issues. I disagree that patents/licensing would be an issue for interoperability -- MPEG-2 is a good example for this. -hari From rem-conf Wed Mar 14 10:25:35 2001 From rem-conf-request@es.net Wed Mar 14 10:25:35 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dFvW-0001FH-00; Wed, 14 Mar 2001 10:23:14 -0800 Received: from (LEMON.flavorsoftware.com) [64.232.157.3] by mail1.es.net with smtp (Exim 1.81 #2) id 14dFvV-00017n-00; Wed, 14 Mar 2001 10:23:13 -0800 Received: by LEMON.flavorsoftware.com with Internet Mail Service (5.5.1960.3) id ; Wed, 14 Mar 2001 13:16:20 -0500 Message-ID: From: Hari Kalva To: "'philippe.gentric@philips.com'" , "'BNowicki@Omneon.com'" Cc: "'rem-conf@es.net'" Subject: RE: MP4 Player Available for Download Date: Wed, 14 Mar 2001 13:16:19 -0500 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 We did testing with Philips files and were able to parse the files that were submitted recently to MPEG -- this may not be the same files available on the Philips web site. Parsing MP4 files does not necessarily translate to playing MP4 files because of the profiles/levels supported by the players and the decoders available in the players. -hari > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Wednesday, March 14, 2001 7:47 AM > To: BNowicki@Omneon.com; Hari Kalva > Cc: rem-conf@es.net > Subject: RE: MP4 Player Available for Download > > > > -----Original Message----- > > From: BNowicki@Omneon.com [mailto:BNowicki@Omneon.com] > > Sent: Tuesday, March 13, 2001 21:09 > > To: hari@FLAVORSOFTWARE.com > > Cc: rem-conf@es.net > > Subject: RE: MP4 Player Available for Download > > > > We just tried the obvious experiment. > > > > The ".mp4" files on the "Flavor" site do not play with the > > Philips player, and the Philips ".mp4" files do not play with > > the Flavor player. Sounds like a litle inter-operability > > testing might have been in order before calling them the same > > name! > > > > (and of course file format standards are outside the charter > > of IETF, but are still useful) > > > Well trying to breed a mouse and an elephant > does not work either (so far) although both are mamals :-) > > ************************************* > > - Our player plays MPEG-4 video and MPEG-4 audio > (AAC or CELP depending on target total bit rate) > and that is what our .mp4 files contain. > > - FlavorSoftware has a completely different type of content: > it seems to be a slide show (did not dig in > to get the picture type ?) with some .mp3 (?) audio > encapsulated in an .mp4 file > > ************************************* > > The issue here is that .mp4 is a very versatile > container format into which a very large number > of very different content can be stored. > > (BTW 3GPP recently adopted .mp4 for AMR and H263 > in audio/video message/record applications) > > In general MPEG-4 can be seen as a "toolbox" > (just as previous MPEGs were). > > Interop requires that other bodies > (such as DVD, DVB etc did for MPEG-2) > specify for given applications > the exact set of tools/profiles/levels > that are required for conformance/interop. > > This is *exactly* the purpose > of ISMA (http://www.isma.tv) > which recent forum attracted > more than 75 companies. > Interop tests are a key item > in the ISMA agenda. > > Furthermore the MPEG-4 Industry Forum > (M4IF http://www.m4if.org) is > also organizing interop testing > around "focus groups" i.e. > companies/organizations > focusing on a specific > subset of the toolbox > useful for specific applications. > > ************************************* > > So stay tuned, these are only the first > "MPEG-4 products" of a rapidly rising MPEG-4 wave > and we simply need more key words to > accurately describe them... > > Regards, > > Philippe Gentric > Software Architect > PHILIPS DIGITAL NETWORKS > Broadcast & Internet Delivery Solutions > Laboratoires d'Electronique Philips > B.P. 15 - 22, Av. Descartes > 94453 Limeil-Brevannes Cedex France > Phone : 33 (0)1 45 10 68 12 > Fax : 33 (0)1 45 10 69 60 > philippe.gentric@philips.com > Check our web site at: www.mpeg-4player.com > > > > From rem-conf Wed Mar 14 10:54:26 2001 From rem-conf-request@es.net Wed Mar 14 10:54:26 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14dGGu-0003AO-00; Wed, 14 Mar 2001 10:45:20 -0800 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 14dGGt-00039z-00; Wed, 14 Mar 2001 10:45:19 -0800 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA22720 for ; Wed, 14 Mar 2001 10:44:37 -0800 (PST) Received: from cisco.com (sunithak-lnx.cisco.com [128.107.140.122]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACB18648 (AUTH sunithak); Wed, 14 Mar 2001 10:44:16 -0800 (PST) Sender: sunithak@cisco.com Message-ID: <3AAFBBFC.47285928@cisco.com> Date: Wed, 14 Mar 2001 10:44:13 -0800 From: Sunitha Kumar Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-23.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: remove Content-Type: multipart/alternative; boundary="------------4E702D5146D3CD6950E3A9B3" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------4E702D5146D3CD6950E3A9B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------4E702D5146D3CD6950E3A9B3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 

 

--------------4E702D5146D3CD6950E3A9B3--




From rem-conf Wed Mar 14 10:57:36 2001 
From rem-conf-request@es.net Wed Mar 14 10:57:36 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dGPn-0003UM-00; Wed, 14 Mar 2001 10:54:31 -0800
Received: from smtprch1.nortelnetworks.com (smtprch1.nortel.com) [192.135.215.14] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dGPl-0003OK-00; Wed, 14 Mar 2001 10:54:29 -0800
Received: from zrchb213.us.nortel.com by smtprch1.nortel.com;
          Wed, 14 Mar 2001 12:35:14 -0600
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 14 Mar 2001 12:35:07 -0600
Message-ID: 
From: "John Lynch" 
To: "'rem-conf@es.net'" 
Subject: remove
Date: Wed, 14 Mar 2001 12:35:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0ACB5.7B9BF3D0"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0ACB5.7B9BF3D0
Content-Type: text/plain;
	charset="ISO-8859-1"

remove

------_=_NextPart_001_01C0ACB5.7B9BF3D0
Content-Type: text/html;
	charset="ISO-8859-1"






remove




remove





------_=_NextPart_001_01C0ACB5.7B9BF3D0--



From rem-conf Wed Mar 14 11:49:48 2001 
From rem-conf-request@es.net Wed Mar 14 11:49:47 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dHEh-0006Hk-00; Wed, 14 Mar 2001 11:47:07 -0800
Received: from paragon.tacom.army.mil [137.128.32.32] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dHEg-0006Gz-00; Wed, 14 Mar 2001 11:47:06 -0800
Received: from mailgw.tacom.army.mil (mailgw.tacom.army.mil [147.240.40.32])
	by paragon.tacom.army.mil (8.11.3/8.11.3/kbp) with ESMTP
	id  for ;
	Wed, 14 Mar 2001 14:45:56 -0500 (EST)
Received: from twm04.tacom.army.mil (twm04.tacom.army.mil [147.240.33.248])
	by mailgw.tacom.army.mil (8.11.3/8.11.3/kbp) with ESMTP
	id  for ;
	Wed, 14 Mar 2001 14:44:02 -0500 (EST)
Received: by twm04.tacom.army.mil with Internet Mail Service (5.5.2653.19)
	id ; Wed, 14 Mar 2001 14:43:08 -0500
Message-ID: 
From: "Hope, Kevin M." 
To: "'rem-conf@es.net'" 
Subject: remove
Date: Wed, 14 Mar 2001 14:41:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

remove



From rem-conf Wed Mar 14 12:05:37 2001 
From rem-conf-request@es.net Wed Mar 14 12:05:37 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dHTF-0007Ax-00; Wed, 14 Mar 2001 12:02:09 -0800
Received: from garcia.multicasttech.com (multicasttech.com) [63.105.122.8] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dHTD-0007Aa-00; Wed, 14 Mar 2001 12:02:07 -0800
Received: from [63.105.122.193] (HELO 21rst-century.com)
  by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
  with ESMTP id 833848; Wed, 14 Mar 2001 15:02:50 -0500
Message-ID: <3AAFCD65.4233D54B@21rst-century.com>
Date: Wed, 14 Mar 2001 14:58:29 -0500
From: Marshall Eubanks 
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Rob Lanphier 
CC: Bill Nowicki ,
 	'Hari Kalva' ,
 	"'rem-conf@es.net'" , Monty 
Subject: Re: File formats (RE: MP4 Player Available for Download)
References: <5.0.2.1.0.20010314093012.034b5c80@goobox.prognet.com>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Rob Lanphier wrote:

> At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
> >We just tried the obvious experiment.
> >
> >The ".mp4" files on the "Flavor" site do not play with the
> >Philips player, and the Philips ".mp4" files do not play with
> >the Flavor player. Sounds like a litle inter-operability
> >testing might have been in order before calling them the same
> >name!
> >
> >(and of course file format standards are outside the charter
> >of IETF, but are still useful)
>
> Not that I'm disagreeing with you here, but an honest question for
> you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG
> have taken it on, but they've also created a situation where I think
> genuine interoperability is out of the question for anyone who either
> doesn't have a patent licensing agreement from 30 different companies, or
> who chooses to ignore the issue.
>
> Is there a standards group out there who does file formats who would
> actually work toward an unencumbered format?
>
> Rob

Vorbis :

http://www.xiph.org/ogg/vorbis/index.html

--
                                 Regards
                                 Marshall Eubanks



T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : tme@on-the-i.com     tme@multicasttech.com

http://www.on-the-i.com http://www.buzzwaves.com





From rem-conf Wed Mar 14 12:50:47 2001 
From rem-conf-request@es.net Wed Mar 14 12:50:47 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dIA2-0001VU-00; Wed, 14 Mar 2001 12:46:22 -0800
Received: from purple.east.isi.edu [38.245.76.9] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dIA1-0001V2-00; Wed, 14 Mar 2001 12:46:21 -0800
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id PAA11820;
	Wed, 14 Mar 2001 15:46:04 -0500
Message-Id: <200103142046.PAA11820@purple.east.isi.edu>
To: "Hope, Kevin M." 
cc: "'rem-conf@es.net'" 
Subject: Re: remove 
In-Reply-To: Message from "Hope, Kevin M."  
   of "Wed, 14 Mar 2001 14:41:36 EST."  
Date: Wed, 14 Mar 2001 15:46:04 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Folks,

You should send these to rem-conf-request@es.net, sending to the list won't
help...                          ^^^^^^^^

Colin



--> "Hope, Kevin M." writes:
>remove
>



From rem-conf Wed Mar 14 14:49:45 2001 
From rem-conf-request@es.net Wed Mar 14 14:49:43 2001
Received: from list by mail2.es.net with local (Exim 1.92 #1)
	for rem-conf-dist@es.net
	id 14dJyY-0007Ov-00; Wed, 14 Mar 2001 14:42:38 -0800
Received: from [203.8.18.2] (helo=cl-ten-01.networkten.com.au)
	by mail2.es.net with smtp (Exim 1.92 #1)
	for rem-conf@es.net
	id 14dJyT-0007OR-00; Wed, 14 Mar 2001 14:42:33 -0800
Received: from pob23uifesi.cic.org.ar ([61.48.316.4]) by ris5s2.daidacent14sere
	(txmia4-162.gate.net [199.227.35.34])
	by cl-ten-01.networkten.com.au; Thu, 15 Mar 2001 05:44:20 +1100
To: 
From: des567@polbox.com
Subject: Fast Cash!...Quick Approvals for dept consolidation!                         3631
Date: Sat, 29 Jul 2000 03:21:18 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: des567@polbox.com
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list






   
   
   Loan Specialists




  












 We are Loan Specialists.....Ta=
p into our
huge network of Lenders!
For U.S.A.
Homeowners Only

Interest Rates have Dropped....Start Saving
Now!

We =
Will Shop The Best Loan For You!








We provide a 100% free =
service
 
which lets you shop for a loan conveniently and securely from the comfort
of your home. Tap into our huge network of lenders across the U.S. with
different appetites for different types of credit/equity profiles. 
Even if you're currently working with another lender or have been turned
down before, we can still help and structure a program that may just make =
some sense
to you. 

Our loan programs
can get you the cash you need for:

    

  • 
Debt Consolidation
    • 


  • 
2nd Mortgage
    • 


  • 
Refinance
    • 


  • 
Credit Repair
    • 


  • 
Home Improvement
    • 


  • 
New Car
    • 


  • 
Dream Vacation
    • 


  • 
College Tuition
    • 


  • 
To start a new business ..and
much, much more!
    • 




Funding borr=
owers
with less than perfect credit is our specialty!

W=
e can get you the loan you need. 

Regardless of whether you have good or bad
credit, we can help you.


Ready to get started? 

Simply fill out the our 60 second form, and we=
'll begin shopping for your loan.

  

 It's that easy! 
We Make the Lenders Compete for Y=
OUR Business!

  

Please
complete this form.

Our loan specialist will be contacting you at your convenience.

Thank You.
 



  

  

     
    
    
  
  
    

      
Contact
        Information: * Required Info

    

    

      Name:
      *
    

    

      Address:
      *
    

    

      City:
      *
    

    

      State
        (USA Only):
      *
    

    

      Zip/Postal
        Code:
      *<=
/td>
    

    

      Home
        Phone: 
      *
    

    

      Work
        Phone:
      *
    

    

      Email
        Address:
      *
    

    

      Best
        Time to Call:
      
    

  
  

  

    

    

      
        

          Do
            You Own Your Home?:
          Mobile
            Homes DO NOT Qualify
        

        

          Property
            Value:
          *
        

        

          Property
            Type:
          
        

        

          Purchase
            Price:
          *
        

        

          Year
            Acquired:
          *
        

        

          1st
            Mortgage Balance Owed:
          *
        

        

          1st
            Mortgage Interest Rate:
          *
        

        

          Is
            1st Adjustable or Fixed?:
          *
        

        

          2nd
            Mortgage Balance Owed:
          
        

        

          Amount
            You Wish To Borrow:
          *
        

        

          Employer:
          
        

        

          Monthly
            Gross Household Income:
          *
        

        

          
            

              Mon=
thly Debt:: 
            

          		
          
        

        

          Credit
            Rating:
          *
        

        

          Loan
            Interested In:
          *
        

      
    

    

  

  

  



 



Removal
Instructions

Click on the below link to be exclude from further communication.

Click=
 Here


















From rem-conf Wed Mar 14 14:56:19 2001 
From rem-conf-request@es.net Wed Mar 14 14:56:19 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dK9d-0005r1-00; Wed, 14 Mar 2001 14:54:05 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dK9b-0005qr-00; Wed, 14 Mar 2001 14:54:04 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA12973;
	Wed, 14 Mar 2001 17:57:19 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 14 Mar 2001 17:56:11 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Cc: Jonathan Rosenberg 
Subject: symmetric RTP as a solution for NAT traversal
Date: Wed, 14 Mar 2001 17:56:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Folks,

I would like to draw your attention to some work we have done on NAT
traversal for sip, documented in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

Earlier versions of this draft recommended running RTP over TCP to traverse
NATs, which is very unappealing. This -01 draft describes a way to run RTP
over UDP, and still traverse off the shelf, vanilla, regular, ALG-free NATs.
However, to do so requires a small change in the way RTP is done for
unicast, and a small update to some ongoing SDP work. Thats the reason for
my broad cross-post.

The problem with RTP usage for unicast (at least within SIP), is that there
are effectively two RTP sessions established; the caller specifies, in the
INVITE, the IP address and port pair where they would like to receive
packets, and the called party specifies, in the 200 OK, the IP address and
port where they'd like to receive packets. There are no restrictions on the
source port for sending to these addresses. Unfortunately, this is why NAT
traversal is hard. Most NATs which support UDP create NAT bindings, based on
the source address of packets, when a packet is sent outwards. However,
here, we must create the binding by inspecting the SDP. Thats why ALGs were
needed for UDP.

So, our solution is to fix that. To do so, we define symmetric RTP (aka
bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it uses a
single connection, rather than two. One participant in a call acts as the
active side, and another, the passive side. The active participant sends the
RTP packet, and the passive side receives it. Packets are sent back from the
passive user to the active one, using the source address learned from the
RTP packet just received. So, lets say Joe calls Bob. Joe acts as the active
side of the RTP connection. When the 200 OK arrives from Bob, it contains
Bob's address for RTP; say its IP address X and port Y (abbreviated {X,Y}).
So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets say
Joe is behind a NAT. Sending this RTP packet creates a binding in the NAT,
>from {U,V} to {A,B}, and rewrites the source IP address/port of the packet
to this pair. When Bob receives this, Bob can send media back to Joe, using
destination address {A,B} and source {X,Y}. These packets arrive at Joe's
NAT, and because a binding has been established, the destination is
rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has just
traversed a NAT without an ALG. The IP address Joe provided in his SDP was
never used, which was good, since it was wrong.

Note that who is active, and who is passive, as far as setting up the RTP
connections, is completely unrelated to who initiates the call. 

This little trick means that we can establish RTP-over-UDP calls with SIP
through vanilla NATs so long as one side has a public address. This covers a
huge amount of calling patterns we are seeing, right off the bat, including
PC to phone and phone to PC. In the case where both are behind NATs, the
draft describes usage of an RTP translator that can be used as an
intermediary. Other solutions may be possible depending on how the NAT
treats UDP packets. More to come.

I have left out some details about how we determine who is active, and who
is passive, and how this is signaled. Well, fortunately for us, there has
been some excellent work in mmusic on the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

which discusses exactly how to use connection oriented media within SDP. All
we need to do is define an additional keyword, BRTP, or something like that,
to describe this new type of connection oriented media, symmetric (aka
bidirectional) RTP.

The draft goes into details about all of this. It requires only small
changes to existing SIP/SDP/RTP devices to support, and can solve a problem
which I believe will continue to hamper ubiquitous deployment of SIP.

Comments? I'll be discussing this work in more detail on Friday during the
SIP session at IETF 50.

Thanks,
Jonathan R.



---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 



From rem-conf Wed Mar 14 17:35:59 2001 
From rem-conf-request@es.net Wed Mar 14 17:35:58 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dMdP-0003Jp-00; Wed, 14 Mar 2001 17:32:59 -0800
Received: from e1.ny.us.ibm.com [32.97.182.101] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dMdN-0003Ja-00; Wed, 14 Mar 2001 17:32:57 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA81676;
	Wed, 14 Mar 2001 20:31:37 -0500
Received: from d02ml251.somers.hqregion.ibm.com (d02ml251.sby.ibm.com [9.45.4.178])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id UAA29952;
	Wed, 14 Mar 2001 20:28:39 -0500
Importance: Normal
Subject: Re: SRTP and cryptographic context management
To: "David A. McGrew" 
Cc: Mark Baugher , "'rem-conf@es.net'" ,
        "Elisabetta Carrara (ERA)" ,
        "David Oran (E-mail)" ,
        "=?iso-8859-1?Q?MatsN=E4slund=28ERA=29_[mats=2En_aslund=40era-t=2Eericsson?=
 =?us-ascii?Q?=2E?= =?us-ascii?Q?se?= ] ( E-mail )" 
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: 
From: "Peter Schirling" 
Date: Thu, 15 Mar 2001 10:06:38 +0900
X-MIMETrack: Serialize by Router on D02ML251/02/M/IBM(Release 5.0.6a |January 17, 2001) at
 03/14/2001 08:32:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


David,

The rationale is simple...

1.  keep the key pirates from gaining a foothold
2.  much of what VoD is about is enticing couch potatoes to buy, so the=
y
might provide free to air for the 1st five minutes then free to prepaid=

subscribers of premium service, and then everyone pay for the rest of t=
he
movie. They may even open segments of the movie, or use keys to
allow/disallow recording.  The premium channel stations like ShowTime, =
HBO
etc will use this. As the business model for broadcast/multicast change=
s
the news services will use key change as well.

The description is in the MPEG-2 Systems Specification (ISO/IEC
13818-1:2000). The section on Transport Stream (TS) header. The
transport_scrambling_control bits (2 bit field) are part of the 4 byte =
TS
header. The carriage of keys is  described in the Program Specific clau=
se
of the spec. PID (Progam ID) "0001" is reserved for the carriage of
scrambling information. There is also a CA (Conditional Access) Descrip=
tor
which indicates the PID in which additional CA information in the strea=
m
can be found. We identify two types of entitlement messages. EMM -
Entitlement Management Message which are more global program access suc=
h as
groups of subscribers within a service level. These change less often t=
han
ECM (Entitlement Control Messages) which are fined grained down to the
elementary stream or even segments of streams and these are the ones th=
at
can change every few minutes or even seconds.

If you do not have a spec I can send a tutorial I use on MPEG-2
systems...or at least some slides out of it!

Pete Schirling

Digital Media Standards and Commercialisation
IBM Research Division
Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
Mobile text messaging 8022382036@msg.myvzw.com
Internet e-mail: schirlin@us.ibm.com


"David A. McGrew" @cisco.com on 03/14/2001 11:39:38 P=
M

Sent by:  mcgrew@cisco.com


To:   Peter Schirling/Burlington/IBM@IBMUS
cc:   Mark Baugher , "'rem-conf@es.net'"
      , "Elisabetta Carrara (ERA)"
      , "David      Oran (E-mail)"
      , "MatsN=E4slund(ERA)     [mats.n
      aslund@era-t.ericsson.se ] ( E-mail )"
      
Subject:  Re: SRTP and cryptographic context management



Peter,

thanks for your input, more inline:

Peter Schirling wrote:
>
> Mark, all,
>
> Mark's rationale and requirement are sound... an example may be that =
the
> first 5 minutes are free to air and the remainder are paid...
> Broadcasters/multicasters alike will always want to change key sets
> sometimes are as often as once every 5-10 seconds and in some case ev=
en
> more often.
>

what's the reason for the frequent changes?  Do you think that this cla=
ss
of
users will find it essential to enforce such fine-grained access contro=
l?

> The MPEG-2 mux has a 2 bit field to signal which key set to use. The =
key
> data is pre-loaded via a set of tables (themselves encrypted) such th=
at
> when the field in the stream switches value, the decryption engine
already
> has the new key to use...

Could you please provide me with a pointer to a description of this sys=
tem?

>
> This needs to be the same sort of simple key switch signalling
capability.

We certainly need to consider supporting five-second key lifetimes, if
that's
the model currently used by MPEG-2.  This will definitely be on the age=
nda
next
week!

thanks,

David
mcgrew@cisco.com

>
> Pete Schirling
>
> Digital Media Standards and Commercialisation
> IBM Research Division
> Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 736=
2
> Mobile text messaging 8022382036@msg.myvzw.com
> Internet e-mail: schirlin@us.ibm.com
>
> Mark Baugher  on 03/14/2001 08:32:08 AM
>
> To:   "David A. McGrew" 
> cc:   Mark Baugher , "'rem-conf@es.net'"
>       , Elisabetta Carrara (ERA)
>       , David Oran (E-mail)
>       , "Mats N=E4slund(ERA) [mats.n
>       aslund@era-t.ericsson.se] (E-mail)"

> Subject:  Re: SRTP and cryptographic context management
>
> Hi David,
>
> At 04:30 PM 3/13/2001 -0500, David A. McGrew wrote:
>
> >thanks for representing the multicast perspective here!  If I unders=
tand
> >correctly, you are thinking of using SRTP encryption as an access
control
> >method
> >in a multicast scenario.  That usage would certainly be in scope.
>
> I think there are reasons for changing the cryptographic context for
> unicast
> RTP sessions.  If TV Conditional Access vendors change the key for
> digital broadcast, I expect they may choose to do the same thing for
> on-demand streams.  Why they do it is another matter and the number o=
f
> reasons may be as numerous as the number of proprietary CA products
> on the market.  There are subscription schemes that I have heard of
> that control access by forcing the user to refresh a key prior to the=

> end of a pre-determined lifetime.  Seems odd to do that in the middle=
 of
> an RTP session, but I would not rule that out.  Finally, you may have=

> a short key and a long RTP session, which forces the need to refresh =
the
> key from time to time.  Do we really want to tear down the RTP sessio=
n
> to accomplish that?
>
> >In the current draft, there is a real need to have a unique SSRC-to-=
key
> >mapping,
> >since SRTP uses the synchronization information that's already in RT=
P
(the
> >SSRC
> >is used to identify a context, and the RTP sequence number is used a=
s
> >well).  I
> >suppose that it would be possible to change keys in a context as lon=
g as
> >the new
> >key were identified with a particular sequence number (so that all
> receivers
> >would know when to start using that key).  This approach might work,=

> though I
> >hadn't considered it before; we've made the simplifying assumption o=
f
> ssrc/key
> >uniqueness.
>
> If the context were associated with a particular source to an RTP
Session,
> then
> you would have the SSRC-to-key mapping, right?  But if you are changi=
ng
the
> keys
> then there would be two contexts mapping to the SSRC for a period of
time,
> until
> the key change is accomplished for all receivers.  Now could the RTP
> sequence
> number serve as the index into the security context?  I think this co=
uld
be
> a problem
From rem-conf Wed Mar 14 17:35:59 2001 
From rem-conf-request@es.net Wed Mar 14 17:35:58 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dMdN-0003Je-00; Wed, 14 Mar 2001 17:32:57 -0800
Received: from e1.ny.us.ibm.com [32.97.182.101] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dMdL-0003JT-00; Wed, 14 Mar 2001 17:32:55 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA19466;
	Wed, 14 Mar 2001 20:31:39 -0500
Received: from d02ml251.somers.hqregion.ibm.com (d02ml251.sby.ibm.com [9.45.4.178])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id UAA135320;
	Wed, 14 Mar 2001 20:28:40 -0500
Importance: Normal
Subject: Re: File formats (RE: MP4 Player Available for Download)
To: Rob Lanphier 
Cc: Bill Nowicki ,
        "'Hari Kalva'" ,
        "'rem-conf@es.net'" 
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: 
From: "Peter Schirling" 
Date: Thu, 15 Mar 2001 10:18:53 +0900
X-MIMETrack: Serialize by Router on D02ML251/02/M/IBM(Release 5.0.6a |January 17, 2001) at
 03/14/2001 08:32:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Rob,

The file format itself carries no IP ... it is simply a bytewise layout.
The content or rather the players and encoders for consumption and
generation of content is a different story...

There is absolutely no reason why the file exchange specified by WG 11
cannot be universally used. The reason the content does not play is that it
(the content portion of the file) uses some but not all the proper system
level and identification streams called out in the MPEG-4 specification...

Pete Schirling

Digital Media Standards and Commercialisation
IBM Research Division
Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
Mobile text messaging 8022382036@msg.myvzw.com
Internet e-mail: schirlin@us.ibm.com


Rob Lanphier  on 03/15/2001 02:35:09 AM

To:   Bill Nowicki , "'Hari Kalva'"
      
cc:   "'rem-conf@es.net'" 
Subject:  File formats (RE: MP4 Player Available for Download)



At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
>We just tried the obvious experiment.
>
>The ".mp4" files on the "Flavor" site do not play with the
>Philips player, and the Philips ".mp4" files do not play with
>the Flavor player. Sounds like a litle inter-operability
>testing might have been in order before calling them the same
>name!
>
>(and of course file format standards are outside the charter
>of IETF, but are still useful)

Not that I'm disagreeing with you here, but an honest question for
you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG
have taken it on, but they've also created a situation where I think
genuine interoperability is out of the question for anyone who either
doesn't have a patent licensing agreement from 30 different companies, or
who chooses to ignore the issue.

Is there a standards group out there who does file formats who would
actually work toward an unencumbered format?

Rob








> for RTP Translators.  I don't know if it would be good to overload th=
e
> sequence number
> in that way.
>
> >I recall that a similar issue has come up in SMUG before (Brian Weis=

> >pointed out
> >some of the problems with changing keys in an IPSEC SA without chang=
ing
> the
> >SPI), though I'm not sure what happend to that proposal.
>
> GDOI needs an index into the cryptographic context, which would be an=

> application-layer SA for SRTP.   GDOI allows the cryptographic contex=
t to
> be changed using a GROUPKEY-PUSH message that can be sent unicast
> or multicast to members.  But the SPI or index to the context must ch=
ange
> if the key changes in GDOI.
>
> >In large group security (a la SMUG), it may not be necessary to chan=
ge
the
> >group
> >key every time a group member is added.  For the purposes of access
> control
> >(e.g., pay tv), changing the keys is most likely not needed.  (If
someone
> >wants
> >to watch Lethal Weapon XIV five minutes after that movie has started=
,
who
> >cares
> >whether or not they can decrypt the first five minutes?)   OTOH, in =
a
high
> >security setting (e.g., a general addressing his entire army via
> multicast),
> >changing the group key when a member is added would be a good thing.=

> >
> >I think that SRTP as it stands supports digital rights management
> reasonably
> >well - it's secure for one sender, many receivers (though without
digital
> >signatures on packets), and possible to add members at any time.  Pl=
ease
> >let me
> >know if I've missed something, though.
>
> Do you agree that some provision must be made for changing the key, a=
nd
> thus the crypto context, during the life of an RTP session?
>
> Mark
>
> >thanks,
> >
> >David

=





From rem-conf Wed Mar 14 17:57:29 2001 
From rem-conf-request@es.net Wed Mar 14 17:57:28 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dMzn-00050s-00; Wed, 14 Mar 2001 17:56:07 -0800
Received: from mta5.rcsntx.swbell.net [151.164.30.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dMzm-00050d-00; Wed, 14 Mar 2001 17:56:06 -0800
Received: from mail.swbell.net ([65.64.212.26]) by mta5.rcsntx.swbell.net
 (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with SMTP id <0GA700952R21JE@mta5.rcsntx.swbell.net> for rem-conf@es.net; Wed,
 14 Mar 2001 18:37:14 -0600 (CST)
Date: Wed, 14 Mar 2001 18:44:35 +0000
From: Webmaster@whippinwillie.com
Subject: HAVE YOU SEEN MY WILLIE???
To: rem-conf@es.net
Message-id: <0GA700953R21JE@mta5.rcsntx.swbell.net>
MIME-version: 1.0
Content-type: text/plain;charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



http://www.whippinwillie.com



From rem-conf Thu Mar 15 02:26:58 2001 
From rem-conf-request@es.net Thu Mar 15 02:26:57 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dUtV-0001ty-00; Thu, 15 Mar 2001 02:22:09 -0800
Received: from gw-nl4.philips.com [212.153.190.6] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dUtT-0001tm-00; Thu, 15 Mar 2001 02:22:07 -0800
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id LAA22083
          for ; Thu, 15 Mar 2001 11:22:03 +0100 (MET)
          (envelope-from philippe.gentric@philips.com)
From: philippe.gentric@philips.com
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a)
	id xma022065; Thu, 15 Mar 01 11:22:04 +0100
Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA27666
	for ; Thu, 15 Mar 2001 11:22:00 +0100 (MET)
Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) 
	by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA05776
	for ; Thu, 15 Mar 2001 11:21:58 +0100 (MET)
Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi
          via EMEA1 id 0056900016627917; Thu, 15 Mar 2001 11:33:41 +0100
To: 
Subject: RE: File formats (RE: MP4 Player Available for Download)
Message-ID: <0056900016627917000002L072*@MHS>
Reply-To: <"CN=Philippe Gentric/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1"@unregistered.philips.com>
Date: Thu, 15 Mar 2001 11:33:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/15/01 11:21:01"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

> -----Original Message-----
> From: robla@real.com [mailto:robla@real.com]
> Sent: Wednesday, March 14, 2001 18:55
> To: hari@FLAVORSOFTWARE.com; BNowicki@Omneon.com
> Cc: rem-conf@es.net
> Subject: File formats (RE: MP4 Player Available for Download)
>=20
>=20
>=20
> At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
> >We just tried the obvious experiment.
> >
> >The ".mp4" files on the "Flavor" site do not play with the
> >Philips player, and the Philips ".mp4" files do not play with
> >the Flavor player. Sounds like a litle inter-operability
> >testing might have been in order before calling them the same
> >name!
> >
> >(and of course file format standards are outside the charter
> >of IETF, but are still useful)
>=20
> Not that I'm disagreeing with you here, but an honest question for
> you:  whose charter includes specifying file formats?  Clearly, ISO/M=
PEG
> have taken it on, but they've also created a situation where I think
> genuine interoperability is out of the question for anyone who either=

> doesn't have a patent licensing agreement from 30 different companies=
, or
> who chooses to ignore the issue.
>=20

Wow ?

Exactly like for MPEG-1 and MPEG-2 there is a patent pool system
to make MPEG-4 licensing really easy
( see http://www.mpegla.com and http://www.m4if.org).

Now I am always surprised to see how naive people
seem to be about patent issues.

(I am actually certain that many are not so naive ;-)

The truth is that research on these subjects
as been fueled by large corporations for more than
30 years. Hundreds of millions have been spent,
resulting in *thousands* of patents, and
rocketing up.

The technology coverage of this miriad of patents
is such and some of these patents are so "basic" i.e.=20
tackle so fundamental issues
(for example go to www.mpegla.com for the
short (but long !) list of "essential" patents
which affect DCT, VLC, quantization,
motion compensation, etc)
that there is *extrememely little chance*
that *any* technology/product related to
A/V is not covered by *some* patent.

In this context "unencumbered" is *meaningless*,
i.e. seeking that is a very difficult winding road
(around patents) and therefore actually
very probably a lost-in-advance battle.

Instead using well characterized
(standard) technologies such as MPEG-4
with open, cheap, clear, safe and simple licensing
is the way to go.

Amen,


Philippe Gentric
Software Architect
PHILIPS DIGITAL NETWORKS
Broadcast & Internet Delivery Solutions
Laboratoires d'Electronique Philips
B.P. 15 - 22, Av. Descartes
94453 Limeil-Brevannes Cedex France
Phone  :   33 (0)1 45 10 68 12
Fax    :   33 (0)1 45 10 69 60
philippe.gentric@philips.com
Check our web site at: www.mpeg-4player.com


=



From rem-conf Thu Mar 15 06:23:15 2001 
From rem-conf-request@es.net Thu Mar 15 06:23:14 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dYbB-0000m8-00; Thu, 15 Mar 2001 06:19:29 -0800
Received: from odin.unik.no [193.156.96.7] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dYb9-0000kZ-00; Thu, 15 Mar 2001 06:19:27 -0800
Received: from tomkri by odin.unik.no with local (Exim 3.16 #2)
	id 14dYLG-0005P0-00; Thu, 15 Mar 2001 15:03:02 +0100
To: ecoop-info@ecoop.org, tcgn@ieee.org, odp@dstc.edu.au, reflective-middleware@cs.uiuc.edu, cabernet-events@newcastle.ac.uk, confctrl@isi.edu, phdoos@ecoop.org, wg7@dstc.edu.au, rem-conf@es.net
Subject: CFP International Workshop on Multimedia Middleware (M3W'01)
From: Tom Kristensen 
Date: 15 Mar 2001 15:03:02 +0100
Message-ID: <7r4rwvuo2x.fsf@odin.unik.no>
Lines: 95
X-Mailer: Gnus v5.7/Emacs 20.4
Sender: Tom Kristensen 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



                        M3W'01
International Workshop on Multimedia Middleware

       October 5th, 2001, Ottawa, Canada
    in conjunction with ACM Multimedia 2001
          http://www.ifi.uio.no/~m3w

Middleware technologies like the Common Object Request
Broker (CORBA) implementations,  Microsoft's Distributed
Component Object Model (DCOM), and Java RMI have
proved their suitability for "standard" client-server applications.
Middleware abstracts from particular network services and
allows application developers to focus on the application.
However, it is well known in the research community, that today's
middleware solutions are not suited for distributed multimedia
systems, and do not provide the required levels of adaptation
and configurability that is needed to accommodate the diversity
of modern distributed multimedia applications. The goal of the
workshop is to bring together researchers from academia and
industry to identify why today's middleware technologies and
standards fail to appropriately support multimedia applications
and especially to discuss new requirements, approaches, and
solutions.

Areas of interest for this workshop include (but are not limited
to) the following topics:
- Experiences with middleware platforms in multimedia
   application domains
- The design and implementation of multimedia middleware platforms
- Performance analysis of multimedia middleware platforms
- Quality of Service and Realtime support in middleware platforms
- Stream support in middleware platforms
- Support for persistent multimedia objects
- Resolving heterogeneity in multimedia middleware platforms
- Services and APIs for multimedia application development (incl.
security and management)


Format of the workshop:
-----------------------
To  enable  a  highly interactive  workshop,  attendance  will be
limited to about 50 participants.   Participants will be invited based
on the originality,  technical  merit
and  topical  relevance  of  their submissions,  as  well  as  the
likelihood that the
ideas expressed in their submissions will lead to insightful technical
discussions at the
workshop.

Proceedings and submission guidelines:
-----------------------------------------
We seek short paper submissions describing original and unpublished
work. The
page limit for submissions is four pages. All accepted papers will be
published in
a proceeding printed by ACM.  We strongly encurage electronic
submissions via
the workshop's web page (http://www.ifi.uio.no/~m3w).


Important dates:
-----------------
Submission Deadline:  May 15th
Notification:   June 15th
Final version:   July 15th


Workshop Co-Chairs:
-------------------
T. Plagemann, U of Oslo
F. Eliassen, Simula RL


Publicity Chair:
----------------
T. Kristensen, U of Oslo


Program Committee:
--------------------
G. Blair, Lancaster U
V. Cahill, Trinity C. Dublin
A. Campbell, Columbia U
R. Campbell, U of Illinois at UC
V. Goebel, U of Oslo
D. Ionescu, U of Ottawa
D. Karr, BBN
D. Schmidt, DARPA
M. v. Sinderen, U of Enschede
B. Thuraisingham, MITRE
W. Yu, U of Tromsø

---------------------------------------------------------------------



From rem-conf Thu Mar 15 07:38:00 2001 
From rem-conf-request@es.net Thu Mar 15 07:38:00 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dZkS-0002uF-00; Thu, 15 Mar 2001 07:33:08 -0800
Received: from garcia.multicasttech.com (multicasttech.com) [63.105.122.8] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dZkQ-0002tv-00; Thu, 15 Mar 2001 07:33:07 -0800
Received: from [63.105.122.193] (HELO 21rst-century.com)
  by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
  with ESMTP id 834191; Thu, 15 Mar 2001 10:33:32 -0500
Message-ID: <3AB0DFCF.8EBF5C82@21rst-century.com>
Date: Thu, 15 Mar 2001 10:29:20 -0500
From: Marshall Eubanks 
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: philippe.gentric@philips.com
CC: rem-conf@es.net
Subject: Re: File formats (RE: MP4 Player Available for Download)
References: <0056900016627917000002L072*@MHS>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

philippe.gentric@philips.com wrote:

> > -----Original Message-----
> > From: robla@real.com [mailto:robla@real.com]
> > Sent: Wednesday, March 14, 2001 18:55
> > To: hari@FLAVORSOFTWARE.com; BNowicki@Omneon.com
> > Cc: rem-conf@es.net
> > Subject: File formats (RE: MP4 Player Available for Download)
> >
> >
> >
> > At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
> > >We just tried the obvious experiment.
> > >
> > >The ".mp4" files on the "Flavor" site do not play with the
> > >Philips player, and the Philips ".mp4" files do not play with
> > >the Flavor player. Sounds like a litle inter-operability
> > >testing might have been in order before calling them the same
> > >name!
> > >
> > >(and of course file format standards are outside the charter
> > >of IETF, but are still useful)
> >
> > Not that I'm disagreeing with you here, but an honest question for
> > you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG
> > have taken it on, but they've also created a situation where I think
> > genuine interoperability is out of the question for anyone who either
> > doesn't have a patent licensing agreement from 30 different companies, or
> > who chooses to ignore the issue.
> >
>
> Wow ?
>
> Exactly like for MPEG-1 and MPEG-2 there is a patent pool system
> to make MPEG-4 licensing really easy
> ( see http://www.mpegla.com and http://www.m4if.org).
>
> Now I am always surprised to see how naive people
> seem to be about patent issues.
>
> (I am actually certain that many are not so naive ;-)
>
> The truth is that research on these subjects
> as been fueled by large corporations for more than
> 30 years. Hundreds of millions have been spent,
> resulting in *thousands* of patents, and
> rocketing up.
>
> The technology coverage of this miriad of patents
> is such and some of these patents are so "basic" i.e.
> tackle so fundamental issues
> (for example go to www.mpegla.com for the
> short (but long !) list of "essential" patents
> which affect DCT, VLC, quantization,
> motion compensation, etc)
> that there is *extrememely little chance*
> that *any* technology/product related to
> A/V is not covered by *some* patent.
>
> In this context "unencumbered" is *meaningless*,
> i.e. seeking that is a very difficult winding road
> (around patents) and therefore actually
> very probably a lost-in-advance battle.
>
> Instead using well characterized
> (standard) technologies such as MPEG-4
> with open, cheap, clear, safe and simple licensing
> is the way to go.
>

Hello Philippe;

I hate to disagree with you here, but the current situation around MPEG 1/2 Layer 3
streaming licenses indicates that the MPEG process does not lead to
"cheap, clear, safe and simple licensing". I don't know what this license will be, what the
terms will be, whether it will be imposed at all or whether it will be changed at whim
in another year or two.

Can you _guarantee_ that MPEG-4 licensing will be better ? Can anyone ?

                                 Regards
                                 Marshall Eubanks




>
> Amen,
>
> Philippe Gentric
> Software Architect
> PHILIPS DIGITAL NETWORKS
> Broadcast & Internet Delivery Solutions
> Laboratoires d'Electronique Philips
> B.P. 15 - 22, Av. Descartes
> 94453 Limeil-Brevannes Cedex France
> Phone  :   33 (0)1 45 10 68 12
> Fax    :   33 (0)1 45 10 69 60
> philippe.gentric@philips.com
> Check our web site at: www.mpeg-4player.com



T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : tme@on-the-i.com     tme@multicasttech.com

http://www.on-the-i.com http://www.buzzwaves.com





From rem-conf Thu Mar 15 08:02:45 2001 
From rem-conf-request@es.net Thu Mar 15 08:02:45 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14daAA-0003nF-00; Thu, 15 Mar 2001 07:59:42 -0800
Received: from nmh.informatik.uni-bremen.de [134.102.224.3] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14daA7-0003n5-00; Thu, 15 Mar 2001 07:59:40 -0800
Received: from domain.informatik.uni-bremen.de (IDENT:root@domain.informatik.uni-bremen.de [134.102.218.58])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f2FFxW912448;
	Thu, 15 Mar 2001 16:59:32 +0100 (MET)
Received: (from dku@localhost)
	by domain.informatik.uni-bremen.de (8.9.3/8.8.7) id QAA00643;
	Thu, 15 Mar 2001 16:59:32 +0100
X-Authentication-Warning: domain.informatik.uni-bremen.de: dku set sender to dku@informatik.uni-bremen.de using -f
Sender: dku@Informatik.Uni-Bremen.DE
To: Jonathan Rosenberg 
Cc: "'sip@lists.bell-labs.com'" ,
   "'rem-conf@es.net'" ,
   "'confctrl@isi.edu'" 
Subject: Re: symmetric RTP as a solution for NAT traversal
References: 
From: Dirk Kutscher 
In-Reply-To: Jonathan Rosenberg's message of "Wed, 14 Mar 2001 17:56:10 -0500"
Date: 15 Mar 2001 16:59:32 +0100
Message-ID: 
Lines: 66
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

>>>>> "Jonathan" == Jonathan Rosenberg  writes:

    Jonathan> Folks, I would like to draw your attention to some work
    Jonathan> we have done on NAT traversal for sip, documented in:

    Jonathan> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt

    Jonathan> [...]

    Jonathan> I have left out some details about how we determine who
    Jonathan> is active, and who is passive, and how this is
    Jonathan> signaled. Well, fortunately for us, there has been some
    Jonathan> excellent work in mmusic on the following draft:

    Jonathan> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

    Jonathan> which discusses exactly how to use connection oriented
    Jonathan> media within SDP. All we need to do is define an
    Jonathan> additional keyword, BRTP, or something like that, to
    Jonathan> describe this new type of connection oriented media,
    Jonathan> symmetric (aka bidirectional) RTP.

    Jonathan> The draft goes into details about all of this. It
    Jonathan> requires only small changes to existing SIP/SDP/RTP
    Jonathan> devices to support, and can solve a problem which I
    Jonathan> believe will continue to hamper ubiquitous deployment of
    Jonathan> SIP.

    Jonathan> Comments? I'll be discussing this work in more detail on
    Jonathan> Friday during the SIP session at IETF 50.

Jonathan, Henning,

interesting idea! Some comments:

I think, both the ALG- and the "bidirectional RTP" approach have their
merits and drawbacks:

What is nice about the bidirectional RTP approach is that users are
not required to install additional SIP-ALG boxes in order to use their
SIP telephony equipment (assuming a few characteristics of the typical
installed NAT device).

What's not so nice is that both endpoints *and* provider-operated
proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
hostname in the Contact-header of REGISTER requests and make use of
a=direction (and BAVP) in the session description. Proxies will have
to support this stuff (plus the SDP-manipulation and
RTP-translator-control).

ALG-based solutions (given corresponding NAT-device and firewall
control) would at least allow users to deploy "plain", NAT-naive SIP
endsystems, and providers would not have to support the
SDP-manipulation and RTP translator functionality in their
proxies. Basically, it allows to keep the knowledge of NAT inside the
NATed network.

A note on the use of SDP: Since bidirectional RTP is not a different
transport (it's just a convention on the usage of source and
destination ports) and we are still using the RFC 1890 profile, maybe
it's more appropriate to use an a= line to signal the use of
bidirectional RTP?

-- 
	Dirk




From rem-conf Thu Mar 15 08:06:17 2001 
From rem-conf-request@es.net Thu Mar 15 08:06:17 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14daEY-00040v-00; Thu, 15 Mar 2001 08:04:14 -0800
Received: from ns.live.com [208.184.148.162] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14daEX-00040Z-00; Thu, 15 Mar 2001 08:04:13 -0800
Received: (from rsf@localhost)
	by ns.live.com (8.9.3/8.9.3) id IAA68648;
	Thu, 15 Mar 2001 08:04:13 -0800 (PST)
	(envelope-from rsf)
Message-Id: <4.3.1.1.20010315075259.00b91280@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 15 Mar 2001 08:04:09 -0800
To: rem-conf@es.net
From: Ross Finlayson 
Subject: MP3 streaming 'licenses' (was File formats)
In-Reply-To: <3AB0DFCF.8EBF5C82@21rst-century.com>
References: <0056900016627917000002L072*@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

At 07:29 AM 3/15/01, Marshall Eubanks wrote:
>I hate to disagree with you here, but the current situation around MPEG 
>1/2 Layer 3
>streaming licenses indicates that the MPEG process does not lead to
>"cheap, clear, safe and simple licensing". I don't know what this license 
>will be, what the
>terms will be, whether it will be imposed at all or whether it will be 
>changed at whim
>in another year or two.

IANAL, but I fail to see how Fraunhofer (or anyone else) could have any 
legal basis for charging a license for *streaming* MP3 (or MPEG audio of 
any form).

Certainly the encoding and decoding of MPEG audio is covered by patents, 
and is thus licenseable.  However, once you already have encoded MPEG audio 
data, to stream this data requires only unencumbered, open standard 
protocols (TCP, RFC 2250, or draft-ietf-avt-rtp-mp3-06.txt).

It's hard to see how any restriction on the streaming of pre-encoded audio 
could have any legal weight.  In fact, such a restriction might even be 
seen as a violation of free speech rights...

         Ross.





From rem-conf Thu Mar 15 08:20:42 2001 
From rem-conf-request@es.net Thu Mar 15 08:20:41 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14daS7-0005x0-00; Thu, 15 Mar 2001 08:18:15 -0800
Received: from garcia.multicasttech.com (multicasttech.com) [63.105.122.8] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14daS6-0005wp-00; Thu, 15 Mar 2001 08:18:14 -0800
Received: from [63.105.122.193] (HELO 21rst-century.com)
  by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
  with ESMTP id 834215; Thu, 15 Mar 2001 11:18:50 -0500
Message-ID: <3AB0EA69.DBA7109F@21rst-century.com>
Date: Thu, 15 Mar 2001 11:14:33 -0500
From: Marshall Eubanks 
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Ross Finlayson 
CC: rem-conf@es.net
Subject: Re: MP3 streaming 'licenses' (was File formats)
References: <0056900016627917000002L072*@MHS> <4.3.1.1.20010315075259.00b91280@localhost>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Ross Finlayson wrote:

> At 07:29 AM 3/15/01, Marshall Eubanks wrote:
> >I hate to disagree with you here, but the current situation around MPEG
> >1/2 Layer 3
> >streaming licenses indicates that the MPEG process does not lead to
> >"cheap, clear, safe and simple licensing". I don't know what this license
> >will be, what the
> >terms will be, whether it will be imposed at all or whether it will be
> >changed at whim
> >in another year or two.
>
> IANAL, but I fail to see how Fraunhofer (or anyone else) could have any
> legal basis for charging a license for *streaming* MP3 (or MPEG audio of
> any form).
>
> Certainly the encoding and decoding of MPEG audio is covered by patents,
> and is thus licenseable.  However, once you already have encoded MPEG audio
> data, to stream this data requires only unencumbered, open standard
> protocols (TCP, RFC 2250, or draft-ietf-avt-rtp-mp3-06.txt).
>
> It's hard to see how any restriction on the streaming of pre-encoded audio
> could have any legal weight.  In fact, such a restriction might even be
> seen as a violation of free speech rights...
>
>          Ross.

Ross;

   Neither of us is a lawyer (NOUIAL ?), but look at

http://mp3licensing.com/royalty/broadcast.html

IMHO, this kind of arbitrary changes in the license
in midstream invalidates the claim that MPEG licenses are
"cheap, clear, safe and simple."

I basically agree with you, but
I, for one, do not want to go to court to prove the validity of your assertions.

                                 Regards
                                 Marshall Eubanks



T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : tme@on-the-i.com     tme@multicasttech.com

http://www.on-the-i.com http://www.buzzwaves.com





From rem-conf Thu Mar 15 09:08:27 2001 
From rem-conf-request@es.net Thu Mar 15 09:08:26 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dbBI-0007bo-00; Thu, 15 Mar 2001 09:04:56 -0800
Received: from eden.dei.uc.pt [193.137.203.230] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dbB0-0007bP-00; Thu, 15 Mar 2001 09:04:52 -0800
Received: from pan (pan.dei.uc.pt [10.2.0.27])
	by eden.dei.uc.pt (8.11.2/8.11.2) with SMTP id f2FGSGt437382;
	Thu, 15 Mar 2001 16:28:25 GMT
Message-Id: <3.0.6.32.20010315163543.007bbe80@eden.dei.uc.pt>
X-Sender: boavida@eden.dei.uc.pt
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 15 Mar 2001 16:35:43 +0000
To: webmaster@ercim.org, office@ercim.org, muetze@wiwi.uni-marburg.de,
       sacj_production@cs.up.ac.za, sdelman@wkap.com, jorg@cs.virginia.edu,
       msj@microsoft.com, cecileh@total.emap.com, ole@cisco.com,
       helpdesk@cordis.lu, end2end-interest@ISI.EDU, tccc@ieee.org,
       int-serv@ISI.EDU, conf@colmar.colmar.uha.fr, rem-conf@es.net,
       qbone@internet2.edu, diffserv-interest@external.cisco.com
From: Fernando Boavida 
Subject: QofIS'2001 submission period now open
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


We apologize if you receive multiple copies.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

                          QofIS 2001
                 http://qofis2001.dei.uc.pt/

Second International Workshop on Quality of future Internet Services
  September 24-26, 2001, University of Coimbra, Coimbra, Portugal

                        2nd CALL FOR PAPERS

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Scope
-----

The design, implementation and provision of Quality of Service - from=20
networks to applications - are key issues of current and emerging=20
communication systems. QofIS'2001 workshop is the second international=20
event organised by COST263 Action "Quality of future Internet Services".=20
It will constitute a privileged forum for the presentation and discussion=20
of new approaches to QoS, bringing together researchers, developers=20
and practitioners from both industry and academia.=20

The emphasis of the workshop is on horizontal (end-to-end) as well as=20
vertical (top-down) provision of quality of services, spanning all=20
components of end systems and networks, with the aim of identifying=20
solutions enabling feasible and coherent QoS provision.=20

Along with invited papers and panels, QofIS'2001 will offer keynote=20
speeches and technical demonstrations.

Paper submission topics include, but are not restricted to

* Packet-level issues
    Per-hop behaviours (PHBs)=20
    Traffic policing and scheduling
* Flow-level issues
    QoS mapping, negotiation and adaptation
    Challenges of QoS routing: intra-domain, inter-domain and multicast
    User and network signalling for QoS
* Network-level issues
    Traffic engineering
    Wireless access and mobile communications issues
    Policy-based QoS control for the Internet
    Monitoring, measurement and management of quality of service
* Applications
    QoS in middleware platforms
    Quality of service for distributed applications
    Active services for Internet QoS
* Architectural issues
    End-to-end QoS support and services
    Cost assessment and pricing schemes for Internet QoS

Papers addressing new areas of research and novel ideas/proposals/techniques=
=20
still to be widely accepted by the community are welcome, especially if they=
=20
are supported by experimentation and prototyping. A session on=20
"Outrageous/innovative opinions" is envisaged.


Information for authors
-----------------------

Submissions, in the form of full papers, should describe original work=20
(not submitted or published elsewhere) and be 12 single-spaced pages or=20
less in length. Submissions should include: title, authors, affiliations,=20
100-word abstract and list of keywords. The author responsible for=20
correspondence should be identified, including the author's name, position,=
=20
mailing address, telephone and fax numbers, and e-mail address. The title=20
page should also indicate if the paper is to be considered for the best=20
PhD student paper award (see below). One of the authors of each accepted=20
paper must present the paper at QofIS'2001.

The conference proceedings will be published by Springer-Verlag, Heidelberg,=
=20
in the Lecture Notes in Computer Science Series and distributed at the=
 event.=20
Authors are requested to follow the LNCS's guidelines in preparing their=20
manuscript.


Best PhD student paper award
----------------------------

PhD student papers will be reviewed like all other papers and will be=20
presented in regular sessions. Papers that are candidate for the best PhD=20
student paper award should be clearly identified as such in a cover letter.=
=20
The PhD student should be the principal author and presenter of the=20
submitted paper. This is to be indicated in a cover letter, which should=20
be signed by the student's supervisor. A jury will select the best paper=20
based both on the quality of the written paper and its presentation. The=20
winner will be awarded a prize donated by one of the workshop sponsors.


Address for submissions
-----------------------

Authors are requested to submit their manuscripts electronically in PDF=20
or in Postscript formats through the workshop website
http://qofis2001.dei.uc.pt/=20


General information=20
-------------------

For more information visit http://qofis2001.dei.uc.pt/ or mail to=20
qofis2001@dei.uc.pt=20
(Fax.: +351 239 701266).

See also QofIS'2000 web pages at http://www.fokus.gmd.de/events/qofis2000/

Author guidelines: www.springer.de/comp/lncs/authors.html=20


-------------------
Important deadlines
-------------------

April 16th, 2001	Papers, demonstrations and panel proposals
June 8th, 2001		Author notification
July 9th, 2001		Camera-ready copies of papers and panelists' position=20
                        papers due


Steering Committee
------------------

Michael Smirnov, GMD FOKUS, Germany ( SC Chair)
Jon Crowcroft, UCL, UK
James Roberts, CNET, France
Fernando Boavida, University of Coimbra, Portugal


Program Committee
-----------------

Azcorra, Arturo - UC3M, Spain
Baker, Fred - Cisco Systems, USA
Berg, J. L. van den - KPN Research, The Netherlands
Blondia, Chris - UIA, Belgium
Boavida, Fernando - University of Coimbra, Portugal, (PC Chair)
Bonaventure, Olivier - FUNDP, Belgium
Carle, Georg  - GMD FOKUS, Germany
Casals, Olga - UPC, Spain
Crowcroft, Jon - UCL, UK
de Meer, Hermann - UCL, UK
de Sousa, Paulo - IST, EU
Domingo-Pascual, Jordi - UPC, Spain
Esaki, Hiroshi - Tokyo University, Japan
Hutchison, David - Lancaster University, UK
Jain, Raj - Nayna Networks and Ohio State University, USA
Jormakka, Jorma - HUT, Finland
Karlsson, Gunnar - KTH, Sweden
Kilkki, Kalevi - Nokia, USA
Kuehn, Paul J. - IND, Germany
Luoma, Marko - HUT, Finland
Madeira, Edmundo - UNICAMP, Brazil
Mei, R. D. van der - KPN Research, The Netherlands
Monteiro, Edmundo - University of Coimbra, Portugal
Pavlou, George - Uni Surrey, UK
Popa, Mihai - Procetel, Romania
Roberts, James - CNET, France
Scoglio, Caterina - FUB, Italy
Serpanos, Dimitrios N. - University of Patras, Greece
Smirnov, Michael - GMD FOKUS, Germany
Sol=E9-Pareta, Josep - UPC, Spain
Stavrakakis, Ioannis - UOA, Greece
Stuettgen, Heinrich - NEC, Germany
Ventre, Giorgio - UNINA, Italy
Virtamo, Jorma - HUT, Finland
Wolf, Lars - University of Karlsruhe, Germany
Wolisz, Adam - TU-Berlin, Germany
Wroclawski, John - MIT, USA
Zehl, Andr=E9 - T-Nova, Germany


---------------------------------------------------------------------------
Fernando Boavida (Associate Professor)                      =20
Dept. Engenharia Informatica                 Tel.: + 351 239 790000
Universidade de Coimbra                      Fax.: + 351 239 701266
POLO II . Pinhal de Marrocos                 e-mail: boavida@dei.uc.pt
P-3030 COIMBRA				     http://eden.dei.uc.pt/~boavida
---------------------------------------------------------------------------
                                QofIS'2001=20
   Second International Workshop on Quality of future Internet Services
                        http://qofis2001.dei.uc.pt
---------------------------------------------------------------------------




From rem-conf Thu Mar 15 11:37:03 2001 
From rem-conf-request@es.net Thu Mar 15 11:37:02 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ddOo-0003yM-00; Thu, 15 Mar 2001 11:27:02 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ddOl-0003yC-00; Thu, 15 Mar 2001 11:26:59 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA25841;
	Thu, 15 Mar 2001 14:30:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 15 Mar 2001 14:29:04 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Dirk Kutscher'" ,
        Jonathan Rosenberg
	 
Cc: "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Subject: RE: symmetric RTP as a solution for NAT traversal
Date: Thu, 15 Mar 2001 14:29:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 

> -----Original Message-----
> From: Dirk Kutscher [mailto:dku@informatik.uni-bremen.de]
> Sent: Thursday, March 15, 2001 11:00 AM
> To: Jonathan Rosenberg
> Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: Re: symmetric RTP as a solution for NAT traversal
> 
>    Jonathan> The draft goes into details about all of this. It
>    Jonathan> requires only small changes to existing SIP/SDP/RTP
>    Jonathan> devices to support, and can solve a problem which I
>    Jonathan> believe will continue to hamper ubiquitous deployment of
>    Jonathan> SIP.
>
>    Jonathan> Comments? I'll be discussing this work in more detail on
>    Jonathan> Friday during the SIP session at IETF 50.
>
>Jonathan, Henning,
>
>interesting idea! Some comments:
>
>I think, both the ALG- and the "bidirectional RTP" approach have their
>merits and drawbacks:
>
>What is nice about the bidirectional RTP approach is that users are
>not required to install additional SIP-ALG boxes in order to use their
>SIP telephony equipment (assuming a few characteristics of the typical
>installed NAT device).
>
>What's not so nice is that both endpoints *and* provider-operated
>proxies have to be NAT-aware: e.g., endpoints have to use the pseudo
>hostname in the Contact-header of REGISTER requests and make use of
>a=direction (and BAVP) in the session description. Proxies will have
>to support this stuff (plus the SDP-manipulation and
>RTP-translator-control).

Its a practical issue of what it takes to deploy a real system.

Fundamentally, the concept of ALG does not scale up. There are lots of new
Internet applications all of the time. The people who make NATs cannot keep
track of all of them, and grow the expertise to be able to support every
protocol (plus their extensions, revisions, interop testing, etc.) in a
timely fashion. The new breed of residential NAT is a $150 consumer device;
I just don't see how those boxes can support EVERY protocol, and they won't.
Those vendors will wait until there is a large demand for specific
application, and then introduce it. 

Consider SIP specifically. THe basic nat alg is not awfully hard, but upon
further study, you realize there are issues like no-SDP in the invites,
early media, preconditions, SDP in ACK, multiple m lines, re-invites with no
SDP, and so on. That list of issues which would affect an ALG will grow, I
fear. We are still debating issues like early media that could result in
additional extensions that better handle it. Is it reasonable to assume that
every vendor of every nat box is going to realistically track these things,
and support them in their releases as fast as the sip vendors will? I think
not. Not even close. Similar argument for H.323. 

So, if I want to deploy a new application, I can either (1) wait for all the
nats in the world to introduce ALGs for the protocol, and then wait for them
to be deployed, replacing any existing nats in peoples homes and
enterprises. Then I deploy my protocol. Besides the fact that we're talking
several years here, there is a chicken and egg problem - if the application
isn't widely deployed (and can't be, because of nat), why would people
bother to widely deploy ALGs for it? 

This is the core argument behind the midcom framework, which is to
*separate* the application layer processing to support nat, and the actual
nat packet processing itself. Its another form of decomposition, like our
MGC/MG/SG decomposition in MGCP/megaco. For the case here, there is no
control relationship possible between the application servers in the
network, and the nat. However, the principle is the same: the alg for a
protocol should live with the vendors that understand that protocol, and
live in the boxes that provide that protocol service. When I build a server
to provide a service, the onus is ultimately on ME to make sure that the
service works for my customers. That has nothing to do with nat, thats just
a truth of deploying a real service.


>
>
>
>ALG-based solutions (given corresponding NAT-device and firewall
>control) would at least allow users to deploy "plain", NAT-naive SIP
>endsystems, and providers would not have to support the
>SDP-manipulation and RTP translator functionality in their
>proxies. Basically, it allows to keep the knowledge of NAT inside the
>NATed network.

Well, as I argue above, thats not actually going to work in practice. Right
now, people are doing horrible things like tunneling RTP over HTTPS. Here is
an opportunity, through what amounts to really simple extensions in the
client, to allow this application to traverse NATs in a sensible way.

I'll also add that our enhancements have other benefits beyond nat. They
also deal with problems related to multi-homing and self discovery of IP
addresses, as we describe in the document. We have seen these problems in
real systems as well, and they are hampering deployment just as the nat
problem is. I suspect there are other benefits lurking as well. 

Another way to describe it is thusly: all that we are doing is back-filling
into SIP/SDP/RTP  the nat friendly protocol guidelines which have since been
published by IETF. 

>
>A note on the use of SDP: Since bidirectional RTP is not a different
>transport (it's just a convention on the usage of source and
>destination ports) and we are still using the RFC 1890 profile, maybe
>it's more appropriate to use an a= line to signal the use of
>bidirectional RTP?

I'm just going with the conventions which are already described in the
conmedia draft, since I think symmetric RTP is another connectin oriented
transport. However, I am not a stickler for the syntax. So long as we convey
the desired semantics, I'm fine.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com



From rem-conf Thu Mar 15 12:08:57 2001 
From rem-conf-request@es.net Thu Mar 15 12:08:56 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14de0d-0005p3-00; Thu, 15 Mar 2001 12:06:07 -0800
Received: from gumby.cs.berkeley.edu [128.32.32.38] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14de0b-0005ot-00; Thu, 15 Mar 2001 12:06:05 -0800
Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74])
	by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA08755;
	Thu, 15 Mar 2001 11:56:10 -0800
Message-ID: <3AB11F67.7F06EAC9@bmrc.berkeley.edu>
Date: Thu, 15 Mar 2001 12:00:39 -0800
From: katherine reyes 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: 3/21 Berkeley Multimedia, Interfaces and Graphics Seminar
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Berkeley Multimedia, Graphics and Interfaces Seminar

QoS Enabled Audio Teleportation

March 21, 2001,
1:10-2:30 p.m. PDT
Fujitsu Seminar Room (405 Soda Hall)

Chris Chafe
Center for Computer Research in Music and Acoustics
Stanford University

Our group working in cooperation with Internet2 demonstrated how the
benefits the quality of service (QoS) could be applied to the real-time
transmission of interactive CD-quality audio across the high-performance
network path between Stanford University and the SC2000 show floor in
Dallas last November. New, no compromise, audio applications were
developed using a simplified approach for high quality music and sound
streaming over IP networks.

Previously existing systems for streaming digital audio have involved a
number of trade-offs. Because of transmission bandwidth limitations and
best effort delivery, audio signal compression of one form or another is
typical. Buffering of data, which often delays a signal by seconds,
safeguards against delivery uncertainties.

The uncompressed live audio streams required for this demo were made
possible by employing network enhancements that support minimal delay
and low-jitter packet delivery over WAN. Applications include two-way
communication (full-bandwidth voice and music) and "surround sound"
multi-channel eavesdropping on Stanford spaces.

Along with our new professional audio applications we have developed
SoundWIRE, a utility which affords an intuitive way of evaluating
transaction delay and delay constancy. Its final form is an enhanced
"ping" that uses actual sound reflection. A musical tone, such as a
guitar pluck, can be created by repeatedly reflecting a digital acoustic
signal between two hosts. Using the network delay between these
reflections to substitute for a guitar string creates a tone whose
stability represents perfectly regular service and whose pitch
represents transmission latency. The ear's ability to discern minute
differences makes this an unforgiving test of network reliability. And
the Internet itself can be listened to as a vibrating acoustic medium,
as if it were a guitar string, with a new technique for generating sound
waves on the Internet from real-time echoes (SoundWIRE). This auditory
"ping" is used as a tool for evaluation of network constancy.

Network quality of service (QoS) for this demonstration consisted of
marking application traffic for Expedited Forwarding (EF), shaping and
policing it at the network edge, and sending it over the Stanford
University, CalREN2, and Abilene backbone network, where EF-marked
traffic is preferentially serviced. The QoS network design in this demo
reflects the architecture of the Internet2 QBone Premium Service. Heavy
congestion was created at one or more points near the edge and effective
protection of application traffic was demonstrated.

---------------

The seminar is broadcast live on the Internet Mbone and as a Real
Networks G2 broadcast.

You can connect to the live RealNetworks broadcast at:
http://bmrc.berkeley.edu/bibs/cs298-5

You can also directly put in this url into the Real Player:
rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm

To do so you will need to have the "Real Player G2" installed, which is
available
from:http://www.real.com/products/player/downloadrealplayer.html

To tune into the Internet MBone broadcast, look for the announcement in
your MBone session directory program ('sdr'), or you can visit:
http://imj.ucsb.edu/sdr-monitor/

You can get further information about this seminar, and access to
replays of previous seminars at
the MIG Seminar web page:

http://media2.bmrc.berkeley.edu/bibs/archive.cfm

Sponsored by the Berkeley Multimedia Research Center



From rem-conf Thu Mar 15 13:42:14 2001 
From rem-conf-request@es.net Thu Mar 15 13:42:13 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dfQW-0000vr-00; Thu, 15 Mar 2001 13:36:56 -0800
Received: from adsl-64-218-189-105.dsl.tulsok.swbell.net (emailserver1.machine.com) [64.218.189.105] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14dfQS-0000vO-00; Thu, 15 Mar 2001 13:36:52 -0800
From: 
Subject: Make Money In Just A Few Weeks
Date: Thu, 15 Mar 2001 12:01:01
Message-Id: <853.640236.563036@emailserver1.machine.com>
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hello Friends, I am an IT Manager making $50,000+ a year, 
but I want to show you what I do for fun, which will make me 
an ADDITIONAL $250,000 THIS YEAR ALONE....and it takes only 
a fraction of the time that you and I spend at our regular jobs. 
Basically, I send out as many of these emails as I can, then 
people send me cash in the mail for information that I just 
email back to them. Every day, I walk out to my mailbox 
knowing that there are at least a few hundred dollars
waiting for me. And the best part, IT IS COMPLETELY LEGAL. 
Just read the next few pages and see what you think. 
If you like what you read, great....If you don't, read it again 
because you must have missed something. 

					WildCard

DEAR FRIENDS AND FUTURE MILLIONAIRES: 
AS SEEN ON NATIONAL TV: 

"Making over half million dollars every 4 to 5 months from your 
home for an investment of only $25 US Dollars expense one time. 

THANKS TO THE COMPUTER AGE AND THE INTERNET! 
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! 

Before you say "Bull", please read the following. 
This is the letter you have been hearing about on the news lately. Due to the 
popularity of this letter on the Internet, a national weekly news program recently 
devoted an entire show to the investigation of this program described below, to see 
if it really can make people money. The show also investigated whether or not the 
program was legal. Their findings proved once and for all that there are "absolutely 
NO laws prohibiting the participation in the program and if people can follow the 
simple instructions, they are bound to make some mega bucks with only $25 out of 
pocket cost". 

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS 
PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN 
EVER. 

This is what one had to say: "Thanks to this profitable opportunity. I was approached 
many times before but each time I passed on it. I am so glad I finally joined just to 
see what one could expect in return for the minimal effort and money required. To my 
astonishment, I received a total $610,470.00 in 21 weeks, with money still coming 
in."
 
Pam Hedland, Fort Lee, New Jersey. 

PRINT THIS NOW FOR YOUR FUTURE REFERENCE 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
If you would like to make at least $500,000 every 4 to 5 months 
easily and comfortably, please read the following, 
THEN READ IT AGAIN AND AGAIN!! 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! 

INSTRUCTIONS:

===========Order all 5 reports shown on the list below===== 

For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING AND 
YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. 
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail 
problems. When you place your order, make Sure you order each of the 5 reports. You 
will need all 5 reports so that you Can save them on your computer and resell them. 

YOUR TOTAL COST... $ 5 X 5 = $ 25.00. Within a few days you will 
receive, via e-mail, each of the 5 reports from these 5 different individuals. Save 
them on your computer so they will be accessible for you to send to the 1,000's of 
people who will order them from you. Also make a floppy of these reports and keep it 
on your desk in case something happens to your computer. 

IMPORTANT: DO NOT alter the names of the people who are listed next to each report, 
or their sequence on the list, in any way other than what is instructed below in each 
step "1 through 6" or you will lose out on majority of your profits. 
Once you understand the way this works, you will also see how
it does not work if you change it. Remember, this method has been tested, and if you 
alter, it will NOT work!! People have tried to put their friends/relatives names on 
all five thinking they could get all the money. But it does not work this way. 
Believe us, we all have tried to be greedy and then nothing happened. So Do Not try 
to change anything other thanwhat is instructed, because if you do, it will not work 
for you. 
		Remember, honesty reaps the reward!!! 

1. After you have ordered all 5 reports, take this advertisement and REMOVE the name 
& address of the person in REPORT # 5. This person has made it through the cycle and 
is no doubt counting their fortune. 

2. Move the name & address in REPORT # 4 down to report # 5. 

3. Move the name & address in REPORT # 3 down to report # 4. 

4. Move the name & address in REPORT # 2 down to report # 3. 

5. Move the name & address in REPORT # 1 down to report # 2. 

6. Insert YOUR name & address in the REPORT # 1 Position. 

PLEASE MAKE SURE you copy every name & address ACCURATELY! 

***Take this entire letter, with the modified list of names, and save it on your 
computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if 
you lose any data. To assist you with marketing your business on the internet, the 5 
reports you purchase will provide you with invaluable marketing information which 
includes how to send bulk e-mails legally, where to find thousands of free classified 
ads and much more. 

There are 2 Primary methods to get this venture going: 

METHOD #1: BY SENDING BULK E-MAIL LEGALLY 
===========================================================
Let's say that you decide to start small, just to see how it goes, and we will assume 
you and those involved send out only 5,000 e-mails each.
Let's also assume that the mailing receive only a 0.2% response (the response could 
be much better but lets just say it is only 0.2%. Also, many people will send out 
hundreds of thousands of e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails. 
With a 0.2% response, that is only 10 orders for report # 1. 
Those 10 people responded by sending out 5,000 e-mails each for a total of 50,000. 
Out of those 50,000 e-mails, only 0.2% responded with orders. That's 100 people 
responding to and ordering Report # 2. Those 100 people mail out 5,000 e-mails each 
for a total of 500,000 e-mails.

The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 
5,000 e-mails each for a total of 5 million e-mails.
The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send 
out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% 
response to that is 100,000 orders for Report # 5. 

THAT'S 100,000 ORDERS TIMES $5 EACH = $ 500,000.00 (half million). 
Your total income in this example is: 1...$ 50 + 2...$ 500 + 3..$ 5,000 + 4... $ 
50,000 + 5... $ 500,000... GRAND TOTAL = $ 555,550.00 

			NUMBERS DO NOT LIE. 

GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE 
RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL 
MAKE A LOT OF MONEY! 

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT 
OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or 
half or even one 4th of those people mailed 100,000 e-mails each or more? There are 
over 150 million people on the Internet worldwide and counting. Believe me, many 
people will do just that, and more! 

METHOD # 2: BY PLACING FREE ADS ON THE INTERNET 
Advertising on the net is very, very inexpensive and there are hundreds of FREE 
places to advertise. Placing a lot of free ads on the internet will easily get a 
larger response. 

We strongly suggest you start with Method # 1 and add METHOD # 2 
as you go along. 

For every $5 you receive, all you must do is e-mail them the Report they ordered. 
That's it. Always provide same day service on all orders.
This will guarantee that the e-mail they send out, with your name and address on it, 
will be prompt because they can not advertise until they receive the report. 

AVAILABLE REPORTS ========================================= 

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. 

Notes: Always send $ 5 cash (US CURRENCY) for each report. 
Checks NOT accepted. 
Make sure the cash is concealed by wrapping it in atleast 2 sheets of paper. On one 
of those sheets of paper, write the NUMBER & NAME of the Report you are ordering., 
YOUR E-MAIL ADDERSS and your name and postal address. 

PLACE YOUR ORDER FOR THESE REPORTS NOW: 


REPORT # 1: "The Insider's Guide To Advertising For Free On The Net" 

Order Report # 1 from: 

Clay Montgomery
12725 E. 76th Circle N.
Owasso, OK 74055



Report #2: "The Insider's Guide To Sending Bulk E-Mail On The Net" 

Order Report #2 from: 

Rick Dennis 
P.O. Box 93649 
Anchorage, AK 99509-3649



Report # 3: "The Secret To Multilevel Marketing On The Net" 

Order Report # 3 from: 

Christian Ward 
PO Box 212537 
Augusta, GA 30917-2537



Report # 4: "How To Become A Millionaire Utilizing MLM & The Net" 

Order Report # 4 from: 

David Benear 
3415 Town & Country Dr., Apt 6B 
Little Rock, AR 72204



Report # 5: "How To Send 1 Million E-Mails For Free" 

Order Report # 5 from: 

Mike Nichols 
PO Box 270061 
Flower Mound, TX 75027 


$$$$$$$$$$$$$$$$$$ YOUR SUCCESS GUIDE $$$$$$$$$$$$$$$$$$$$$$$$ 

Follow these guidelines to guarantee your success: 

If you do not receive at least 10 orders for Report # 1 within 2 weeks, continue 
sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after 
that you should receive 100 orders or more for Report # 2. If you did not, continue 
advertising or sending e-mails until you do. Once you have received 100 or more 
orders for Report # 2, YOU CAN RELAX, Because the system is already working for you, 
and the cash will continue to roll in! 

THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you 
are placed in front of a different report. You can KEEP TRACK of your PROGRESS by 
watching which report people are ordering from you.
 
IF YOU WANT TO GENERATE MORE INCOME, SEND ANOTHER BATCH OF E-
MAILS AND START THE WHOLE PROCESS AGAIN. There is no limit to the income you can 
generate from this business!!! 


FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: 

You have just received information that can give you financial freedom for the rest 
of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money 
in the next few weeks and months than you haveever imagined. Follow the program 
EXACTLY AS INSTRUCTED. Do not change it in anyway. It works exceedingly well as it is 
now. Remember to e-mail a copy of this exciting report after you have put your name 
and address in Report # 1 and moved others to # 2...# 5 as instructed 
above. One of the people you send this to may send out 100,000 or more e-mails and 
your name will be on every one of them. Remember though, the more you send out the 
more potential customers you will reach. 
So my friend, I have given you the ideas, information, materials and opportunity to 
become financially independent. IT IS UP TO YOU NOW!

 ===================================================== 

This message is sent in compliance of the new e-mail bill: 
SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, 
http://www.senate.gov/~murkowski/commercialemail/ 

Further transmissions to you by the sender of this email 
may be stopped at no cost to you by sending a reply to this 
email address with the word "remove" in the subject line. 
 
 
 
 
 
 
 
 
 
 



From rem-conf Thu Mar 15 14:32:52 2001 
From rem-conf-request@es.net Thu Mar 15 14:32:51 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dgFc-0002qn-00; Thu, 15 Mar 2001 14:29:44 -0800
Received: from sj-msg-core-3.cisco.com [171.70.157.152] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dgFb-0002qT-00; Thu, 15 Mar 2001 14:29:43 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01937;
	Thu, 15 Mar 2001 14:27:18 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI20098;
	Thu, 15 Mar 2001 14:28:28 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA23341; Thu, 15 Mar 2001 14:28:28 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15025.16907.949542.516323@thomasm-u1.cisco.com>
Date: Thu, 15 Mar 2001 14:28:27 -0800 (PST)
To: Jonathan Rosenberg 
Cc: "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Subject: symmetric RTP as a solution for NAT traversal
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Jonathan, 

On the surface this doesn't sound unreasonable to
me, but my main question is whether, in the end
you end up needing ALG functionality to deal with
NAT's whether this incremental step is necessary.
That is, if you end up needing an ALG to deal with
the UAS-behind-the-NAT problem, have we bought 
anything?

On a different tangent, (never being one to shy
away from having multiple contradictory opinions
on the same subject), plain old firewalls (not
NAT'ing firewalls) are current still a problem
since they typically block the dynamic range for
RTP. Is it possible that this might be munged to
deal with that problem? Ie, allow RTP on a well
known port and demux using the SSCR? I seem to
recall that this has a fatal problem, but I can't
remember what it is. I really should go re-read my
Chapman/Zwicky first, but... If we could do this
your BRTP proposal would make RTP look like any
old UDP command/response protocol from the
firewall standpoiont which might interesting.

		Mike


Jonathan Rosenberg writes:
 > Folks,
 > 
 > I would like to draw your attention to some work we have done on NAT
 > traversal for sip, documented in:
 > 
 > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt
 > 
 > Earlier versions of this draft recommended running RTP over TCP to traverse
 > NATs, which is very unappealing. This -01 draft describes a way to run RTP
 > over UDP, and still traverse off the shelf, vanilla, regular, ALG-free NATs.
 > However, to do so requires a small change in the way RTP is done for
 > unicast, and a small update to some ongoing SDP work. Thats the reason for
 > my broad cross-post.
 > 
 > The problem with RTP usage for unicast (at least within SIP), is that there
 > are effectively two RTP sessions established; the caller specifies, in the
 > INVITE, the IP address and port pair where they would like to receive
 > packets, and the called party specifies, in the 200 OK, the IP address and
 > port where they'd like to receive packets. There are no restrictions on the
 > source port for sending to these addresses. Unfortunately, this is why NAT
 > traversal is hard. Most NATs which support UDP create NAT bindings, based on
 > the source address of packets, when a packet is sent outwards. However,
 > here, we must create the binding by inspecting the SDP. Thats why ALGs were
 > needed for UDP.
 > 
 > So, our solution is to fix that. To do so, we define symmetric RTP (aka
 > bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it uses a
 > single connection, rather than two. One participant in a call acts as the
 > active side, and another, the passive side. The active participant sends the
 > RTP packet, and the passive side receives it. Packets are sent back from the
 > passive user to the active one, using the source address learned from the
 > RTP packet just received. So, lets say Joe calls Bob. Joe acts as the active
 > side of the RTP connection. When the 200 OK arrives from Bob, it contains
 > Bob's address for RTP; say its IP address X and port Y (abbreviated {X,Y}).
 > So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets say
 > Joe is behind a NAT. Sending this RTP packet creates a binding in the NAT,
 > from {U,V} to {A,B}, and rewrites the source IP address/port of the packet
 > to this pair. When Bob receives this, Bob can send media back to Joe, using
 > destination address {A,B} and source {X,Y}. These packets arrive at Joe's
 > NAT, and because a binding has been established, the destination is
 > rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has just
 > traversed a NAT without an ALG. The IP address Joe provided in his SDP was
 > never used, which was good, since it was wrong.
 > 
 > Note that who is active, and who is passive, as far as setting up the RTP
 > connections, is completely unrelated to who initiates the call. 
 > 
 > This little trick means that we can establish RTP-over-UDP calls with SIP
 > through vanilla NATs so long as one side has a public address. This covers a
 > huge amount of calling patterns we are seeing, right off the bat, including
 > PC to phone and phone to PC. In the case where both are behind NATs, the
 > draft describes usage of an RTP translator that can be used as an
 > intermediary. Other solutions may be possible depending on how the NAT
 > treats UDP packets. More to come.
 > 
 > I have left out some details about how we determine who is active, and who
 > is passive, and how this is signaled. Well, fortunately for us, there has
 > been some excellent work in mmusic on the following draft:
 > 
 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt
 > 
 > which discusses exactly how to use connection oriented media within SDP. All
 > we need to do is define an additional keyword, BRTP, or something like that,
 > to describe this new type of connection oriented media, symmetric (aka
 > bidirectional) RTP.
 > 
 > The draft goes into details about all of this. It requires only small
 > changes to existing SIP/SDP/RTP devices to support, and can solve a problem
 > which I believe will continue to hamper ubiquitous deployment of SIP.
 > 
 > Comments? I'll be discussing this work in more detail on Friday during the
 > SIP session at IETF 50.
 > 
 > Thanks,
 > Jonathan R.
 > 
 > 
 > 
 > ---
 > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
 > Chief Scientist                             First Floor
 > dynamicsoft                                 East Hanover, NJ 07936
 > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
 > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
 > http://www.dynamicsoft.com
 >  



From rem-conf Thu Mar 15 19:32:44 2001 
From rem-conf-request@es.net Thu Mar 15 19:32:43 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dkp4-00030C-00; Thu, 15 Mar 2001 19:22:38 -0800
Received: from df-inet1.exchange.microsoft.com [131.107.8.8] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dkp3-0002y4-00; Thu, 15 Mar 2001 19:22:37 -0800
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Thu, 15 Mar 2001 19:22:24 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 19:22:28 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 15 Mar 2001 19:22:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Thu, 15 Mar 2001 19:22:27 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] symmetric RTP as a solution for NAT traversal
Thread-Index: AcCs20yGrWieM1iLS4eDnuGgd8+FogA6385Q
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ,
	,
	,
	
X-OriginalArrivalTime: 16 Mar 2001 03:22:27.0735 (UTC) FILETIME=[53CC8270:01C0ADC8]
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Jonathan,

Your solution is interesting, but it does not deal with the case of two
PCs, both behind a NAT. Another way to solve the problem is to let the
PC who is behind a NAT learn the external mapping of the RTP port, e.g.
that 10.0.0.9:3456 maps to 123.45.67.89:7891. There are quite a few ways
to do that, some of which could well end up being standardized. That
would certainly be a nice complement to the symmetric RTP trick.

However, there is a slight problem. We cannot assume that NATs are aware
of RTP's requirement for "port pairs", an even port for RTP, the next
port for RTCP. We may well learn that port 3456 maps to
123.45.67.89:7891, and port 3457 maps to 123.45.67.89:9872. Now, if we
intend to open the SDP spec and create attributes for the "symmetric
RTP", we should perhaps also create an attribute specifying the RTCP
port, when that port is not equal to RTP+1.

A mild objection to the symmetric RTP is the risk of session hijacking.
Arguably, that is a risk you can assume if the alternative is no session
at all, but you should still consider it...

-- Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, March 14, 2001 2:56 PM
> To: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Cc: Jonathan Rosenberg
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
>=20
> Folks,
>=20
> I would like to draw your attention to some work we have done on NAT
> traversal for sip, documented in:
>=20
>
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt
>=20
> Earlier versions of this draft recommended running RTP over TCP to
> traverse
> NATs, which is very unappealing. This -01 draft describes a way to run
RTP
> over UDP, and still traverse off the shelf, vanilla, regular, ALG-free
> NATs.
> However, to do so requires a small change in the way RTP is done for
> unicast, and a small update to some ongoing SDP work. Thats the reason
for
> my broad cross-post.
>=20
> The problem with RTP usage for unicast (at least within SIP), is that
> there
> are effectively two RTP sessions established; the caller specifies, in
the
> INVITE, the IP address and port pair where they would like to receive
> packets, and the called party specifies, in the 200 OK, the IP address
and
> port where they'd like to receive packets. There are no restrictions
on
> the
> source port for sending to these addresses. Unfortunately, this is why
NAT
> traversal is hard. Most NATs which support UDP create NAT bindings,
based
> on
> the source address of packets, when a packet is sent outwards.
However,
> here, we must create the binding by inspecting the SDP. Thats why ALGs
> were
> needed for UDP.
>=20
> So, our solution is to fix that. To do so, we define symmetric RTP
(aka
> bidirectional RTP in the draft). Symmetric RTP runs over UDP, but it
uses
> a
> single connection, rather than two. One participant in a call acts as
the
> active side, and another, the passive side. The active participant
sends
> the
> RTP packet, and the passive side receives it. Packets are sent back
from
> the
> passive user to the active one, using the source address learned from
the
> RTP packet just received. So, lets say Joe calls Bob. Joe acts as the
> active
> side of the RTP connection. When the 200 OK arrives from Bob, it
contains
> Bob's address for RTP; say its IP address X and port Y (abbreviated
> {X,Y}).
> So, Joe sends packets, using source address/port {U,V}, to {X,Y}. Lets
say
> Joe is behind a NAT. Sending this RTP packet creates a binding in the
NAT,
> from {U,V} to {A,B}, and rewrites the source IP address/port of the
packet
> to this pair. When Bob receives this, Bob can send media back to Joe,
> using
> destination address {A,B} and source {X,Y}. These packets arrive at
Joe's
> NAT, and because a binding has been established, the destination is
> rewritten to {U,V}, and then delivered to Joe. Voila. RTP over UDP has
> just
> traversed a NAT without an ALG. The IP address Joe provided in his SDP
was
> never used, which was good, since it was wrong.
>=20
> Note that who is active, and who is passive, as far as setting up the
RTP
> connections, is completely unrelated to who initiates the call.
>=20
> This little trick means that we can establish RTP-over-UDP calls with
SIP
> through vanilla NATs so long as one side has a public address. This
covers
> a
> huge amount of calling patterns we are seeing, right off the bat,
> including
> PC to phone and phone to PC. In the case where both are behind NATs,
the
> draft describes usage of an RTP translator that can be used as an
> intermediary. Other solutions may be possible depending on how the NAT
> treats UDP packets. More to come.
>=20
> I have left out some details about how we determine who is active, and
who
> is passive, and how this is signaled. Well, fortunately for us, there
has
> been some excellent work in mmusic on the following draft:
>=20
>
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt
>=20
> which discusses exactly how to use connection oriented media within
SDP.
> All
> we need to do is define an additional keyword, BRTP, or something like
> that,
> to describe this new type of connection oriented media, symmetric (aka
> bidirectional) RTP.
>=20
> The draft goes into details about all of this. It requires only small
> changes to existing SIP/SDP/RTP devices to support, and can solve a
> problem
> which I believe will continue to hamper ubiquitous deployment of SIP.
>=20
> Comments? I'll be discussing this work in more detail on Friday during
the
> SIP session at IETF 50.
>=20
> Thanks,
> Jonathan R.
>=20
>=20
>=20
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>=20
>=20
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.



From rem-conf Thu Mar 15 21:30:05 2001 
From rem-conf-request@es.net Thu Mar 15 21:30:04 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dmlo-0006Vi-00; Thu, 15 Mar 2001 21:27:24 -0800
Received: from sj-msg-core-3.cisco.com [171.70.157.152] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dmlm-0006U9-00; Thu, 15 Mar 2001 21:27:22 -0800
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id VAA25118;
	Thu, 15 Mar 2001 21:25:06 -0800 (PST)
Received: from rkumar-ntl.cisco.com ([144.254.252.22])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id AAI10389 (AUTH rkumar);
	Thu, 15 Mar 2001 21:26:07 -0800 (PST)
Message-Id: <4.3.2.7.2.20010315073940.00c7aec0@farley.cisco.com>
X-Sender: rkumar@mira-sjc5-8
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Mar 2001 21:31:54 -0800
To: rem-conf@es.net
From: Rajesh Kumar 
Subject: Re: Error in rfc2833?
Cc: mmostafa@cisco.com, fandreas@cisco.com, bfoster@cisco.com
In-Reply-To: <3AAF7CAB.8AF7A33F@cs.columbia.edu>
References: <200103140218.VAA07491@purple.east.isi.edu>
 <3AAEED5B.493DD8F2@agcs.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_25837922==_.ALT"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--=====================_25837922==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dear AVT team and chair,
Thanks for agreeing to fix the "MF S1... S3"  discrepancy that I pointed 
out on the AVT list. There is another CAS-related rfc2833 problem that was 
brought to my notice by our implementation groups. If the AVT group and 
chair think this too warrants a fix, then you might want to bundle the two 
fixes together! I request the AVT chair to help find a standard solution to 
the following problem:
Background: Carriage of CAS ABCD bits via rfc2833 telephone events applies 
in the case of VoIP trunking i.e. where both bearer and  CAS signaling are 
transported via RTP/IP. For this leg, there is no call agent to interpret 
the CAS and to relay it in some message format (e.g. ISUP). VoIP trunking 
applications are typically used in the access segment of application such 
as wireless where bandwith is a premium.

Problem: The problem has to do with trunk conditioning in the case of CAS 
trunking. Trunk conditioning is used to indicate a per-channel failure. In 
the case of T1 (North American applications), the problem is fairly 
straightforward. You send an idle CAS pattern for 2.5 seconds followed by a 
seize (non-loop-start), or you send an idle pattern for the duration of the 
failure (loop-start).

In the case of European (E1) applications, you indicate per DS0 failures by 
sending a 0xFF  on the bearer path. The receiver integrates it for a 
certain duration and determines that the channel has failed. This is the 
equivalent of North American per-DS0 trunk conditioning, and it prevents a 
failed channel from being seized at the far-end.

A problem arises when you use the 0xFF code in a channel carried via RTP. 
Unlike normal voice, you need to transmit a continuous stream of packets 
and this defeats the normal benefits of silence suppression. Thus, if an E1 
(2.048 Mb/s) line experiences a loss of frame on the TDM side, all its 
channels need to be routed via a VoIP network via a continuous RTP "0xFF" 
stream. A better approach would be to introduce a new standard 
telephone-event "Channel failure". Like other rfc2833 events, this would be 
stateless (i.e. you do not have separate messages for onset and remission). 
As long as you keep on receiving this "Channel failure" telephone  event, 
the channel is marked as failed. The duration field is adjusted so that you 
that there is the right balance between consuming bandwidth by sending this 
"channel-failure" telephone event too often, and not having sufficient 
granularity in demarcating failure intervals for the channel. Typically, 1 
second is good enough. Triple redundancy with the "channel failure" 
telephone events with identical timestamps spaced at 20 ms intervals is 
recommended.

Please not that this is COMPLETELY different from the AAL2-like "state 
signalling" telephone events which I had suggested to Henning et all 
earlier: this is a stateless telephone-event like the ringback tone. If you 
do not consider this appropriate for rfc2833, please advise an alternate 
implementation in RTP-based VoIP CAS trunking scenarios. We have looked at 
all options, and haven't found any.





Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------

--=====================_25837922==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dear AVT team and chair,

Thanks for agreeing to fix the "MF S1... S3"  discrepancy
that I pointed out on the AVT list. There is another CAS-related rfc2833
problem that was brought to my notice by our implementation groups. If
the AVT group and chair think this too warrants a fix, then you might
want to bundle the two fixes together! I request the AVT chair to help
find a standard solution to the following problem:





Background: Carriage of CAS ABCD bits via rfc2833 telephone events
applies in the case of VoIP trunking i.e. where both bearer and  CAS
signaling are transported via RTP/IP. For this leg, there is no call
agent to interpret the CAS and to relay it in some message format (e.g.
ISUP). VoIP trunking applications are typically used in the access
segment of application such as wireless where bandwith is a=20
premium.





Problem: The problem has to do with trunk conditioning in the case of
CAS trunking. Trunk conditioning is used to indicate a per-channel
failure. In the case of T1 (North American applications), the problem is
fairly straightforward. You send an idle CAS pattern for 2.5 seconds
followed by a seize (non-loop-start), or you send an idle pattern for the
duration of the failure (loop-start).





In the case of European (E1) applications, you indicate per DS0
failures by sending a 0xFF  on the bearer path. The receiver
integrates it for a certain duration and determines that the channel has
failed. This is the equivalent of North American per-DS0 trunk
conditioning, and it prevents a failed channel from being seized at the
far-end.





A problem arises when you use the 0xFF code in a channel carried via
RTP. Unlike normal voice, you need to transmit a continuous stream of
packets and this defeats the normal benefits of silence suppression.
Thus, if an E1 (2.048 Mb/s) line experiences a loss of frame on the TDM
side, all its channels need to be routed via a VoIP network via a
continuous RTP "0xFF" stream. A better approach would be to
introduce a new standard telephone-event "Channel failure".
Like other rfc2833 events, this would be stateless (i.e. you do not have
separate messages for onset and remission). As long as you keep on
receiving this "Channel failure" telephone  event, the
channel is marked as failed. The duration field is adjusted so that you
that there is the right balance between consuming bandwidth by sending
this "channel-failure" telephone event too often, and not
having sufficient granularity in demarcating failure intervals for the
channel. Typically, 1 second is good enough. Triple redundancy with the
"channel failure" telephone events with identical timestamps
spaced at 20 ms intervals is recommended.





Please not that this is COMPLETELY different from the AAL2-like
"state signalling" telephone events which I had suggested to
Henning et all earlier: this is a stateless telephone-event like the
ringback tone. If you do not consider this appropriate for rfc2833,
please advise an alternate implementation in RTP-based VoIP CAS trunking
scenarios. We have looked at all options, and haven't found any.









 


Thanks.



Rajesh

------------------------------------- 

Dr. Rajesh Kumar, Principal Engineer

Cisco Voice Technology Center 

Tel: 408-527-0811, Fax: 408-853-1101 

Epage:
mailto:rkumar@epage.cisco.com

-------------------------------------  



--=====================_25837922==_.ALT--




From rem-conf Thu Mar 15 23:22:26 2001 
From rem-conf-request@es.net Thu Mar 15 23:22:25 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14doVq-0001pg-00; Thu, 15 Mar 2001 23:19:02 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14doVo-0001pW-00; Thu, 15 Mar 2001 23:19:01 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07692;
	Fri, 16 Mar 2001 02:22:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 16 Mar 2001 02:21:04 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        Jonathan Rosenberg
	 
Cc: "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 02:20:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, March 15, 2001 5:28 PM
> To: Jonathan Rosenberg
> Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> Jonathan, 
> 
> On the surface this doesn't sound unreasonable to
> me, but my main question is whether, in the end
> you end up needing ALG functionality to deal with
> NAT's whether this incremental step is necessary.
> That is, if you end up needing an ALG to deal with
> the UAS-behind-the-NAT problem, have we bought 
> anything?

Well, you don't need an ALG to deal with UAS behind NAT.
THe document handles the case where one, the other, or
both users are behind NATs, without an ALG in all three cases.
The case where both are behind NAT is still a bit unappealing
(requiring an rtp forwarder), but there still may be ways
around that too, even.

Other peer-peer apps have dealt with nats in intelligent
ways, and I think its beneficial to learn from them.

> 
> On a different tangent, (never being one to shy
> away from having multiple contradictory opinions
> on the same subject), plain old firewalls (not
> NAT'ing firewalls) are current still a problem
> since they typically block the dynamic range for
> RTP. 

Yup.

> Is it possible that this might be munged to
> deal with that problem? 

In some respects, the problem gets easier with this change.
I think (and am not sure), that an implication of using this
symmetric RTP is that sip clients can now traverse socks v5.0
compliant firewalls. Its just a suspicion - I'm looking for
expert input to verify/reject that claim.



> Ie, allow RTP on a well
> known port and demux using the SSCR? I seem to
> recall that this has a fatal problem, but I can't
> remember what it is. I really should go re-read my
> Chapman/Zwicky first, but... If we could do this
> your BRTP proposal would make RTP look like any
> old UDP command/response protocol from the
> firewall standpoiont which might interesting.

It doesn't work when there are machines that have
multiple processes, each of which is terminating RTP.
Thats because you can no longer use the system provided
demux (ports), and now must resort to a new, intermediate
demux layer (using ssrc). Plus, it would require signaling
the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
in a separate thread on the sip list.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com




From rem-conf Thu Mar 15 23:24:37 2001 
From rem-conf-request@es.net Thu Mar 15 23:24:37 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14doaH-00025F-00; Thu, 15 Mar 2001 23:23:37 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14doaG-00024t-00; Thu, 15 Mar 2001 23:23:36 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07728;
	Fri, 16 Mar 2001 02:26:51 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 16 Mar 2001 02:25:40 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christian Huitema'" ,
        Jonathan Rosenberg , sip@lists.bell-labs.com,
        rem-conf@es.net, confctrl@isi.edu
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 02:25:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Thursday, March 15, 2001 10:22 PM
> To: Jonathan Rosenberg; sip@lists.bell-labs.com; rem-conf@es.net;
> confctrl@isi.edu
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan,
> 
> Your solution is interesting, but it does not deal with the 
> case of two
> PCs, both behind a NAT. 

It does. The document discusses the solution. It uses an external RTP
translator. Not optimal; I recognize that. Other solutions may be possible.

> Another way to solve the problem is to let the
> PC who is behind a NAT learn the external mapping of the RTP 
> port, e.g.
> that 10.0.0.9:3456 maps to 123.45.67.89:7891. There are quite 
> a few ways
> to do that, some of which could well end up being standardized. That
> would certainly be a nice complement to the symmetric RTP trick.

Absolutely. There are several tractable solutions if nats conform to the
UDP requirements which you have outlined, Christian, in:

http://search.ietf.org/internet-drafts/draft-huitema-natreq4udp-00.txt



> 
> However, there is a slight problem. We cannot assume that 
> NATs are aware
> of RTP's requirement for "port pairs", an even port for RTP, the next
> port for RTCP. We may well learn that port 3456 maps to
> 123.45.67.89:7891, and port 3457 maps to 123.45.67.89:9872. Now, if we
> intend to open the SDP spec and create attributes for the "symmetric
> RTP", we should perhaps also create an attribute specifying the RTCP
> port, when that port is not equal to RTP+1.

If we do some kind of solution where the external entity tells both UAs
their public addresses, then yes, this will be needed.

> 
> A mild objection to the symmetric RTP is the risk of session 
> hijacking.
> Arguably, that is a risk you can assume if the alternative is 
> no session
> at all, but you should still consider it...

How does symmetric RTP create a risk of hijacking?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com




From rem-conf Fri Mar 16 07:38:48 2001 
From rem-conf-request@es.net Fri Mar 16 07:38:48 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dwDW-0007OR-00; Fri, 16 Mar 2001 07:32:38 -0800
Received: from topaz.3com.com [192.156.136.158] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dwDU-0007Mf-00; Fri, 16 Mar 2001 07:32:36 -0800
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GFTld07351;
	Fri, 16 Mar 2001 07:29:49 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2GFVAE14780;
	Fri, 16 Mar 2001 07:31:10 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256A11.00553F7A ; Fri, 16 Mar 2001 07:31:08 -0800
X-Lotus-FromDomain: 3COM
From: James_Renkel@3com.com
To: casner@acm.org, rem-conf@es.net
cc: Simao Campos-Neto 
Message-ID: <88256A11.005535AC.00@hqoutbound.ops.3com.com>
Date: Fri, 16 Mar 2001 09:28:09 -0600
Subject: Interoperable implementations of G.723
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



To whom it may concern:

Please be advised that the CommWorks Corporation (formerly the 3Com Carrier
Networks Business, now a 3Com company) has implemented the ITU-T G.723 CODEC in
several products. One product (TCS VoIP release 2.3) is released to the field
and installed in a number of customer networks. Other near-term future products,
now in development and test, will also include this capability.

We have tested and continue to test these products and this specific capability
against products from a number of other vendors. I am not sure of the
appropriateness of identifying those vendors and products here, but may be able
to do so if necessary.

Based on the above, the CommWorks Corporation requests that the G.723 audio
payload format be retained in the IETF A/V Profile RFC, contrary to current
plans to delete it.

I will be in Minneapolis for IETF 50 next week and plan to attend the
Audio/Video Transport Working Group meetings. I would be most happy to discuss
this issue with anyone at that time, or by e-mail in advance.

Jim Renkel (e-mail: James_Renkel@3Com.com)
Director, Advanced Technology & System Engineering
The CommWorks Corporation, a 3Com company
formerly the 3Com Carrier Networks Business





From rem-conf Fri Mar 16 07:59:34 2001 
From rem-conf-request@es.net Fri Mar 16 07:59:33 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dwbZ-0000lq-00; Fri, 16 Mar 2001 07:57:29 -0800
Received: from df-inet1.exchange.microsoft.com [131.107.8.8] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dwbY-0000jd-00; Fri, 16 Mar 2001 07:57:28 -0800
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Fri, 16 Mar 2001 07:57:16 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 07:57:19 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 16 Mar 2001 07:57:19 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 07:57:18 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] symmetric RTP as a solution for NAT traversal
Thread-Index: AcCt6iS/i6ThWIBKS6Kr6RlNFeIwbwARvG0g
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ,
	,
	,
	
X-OriginalArrivalTime: 16 Mar 2001 15:57:19.0516 (UTC) FILETIME=[C7CDD5C0:01C0AE31]
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

> How does symmetric RTP create a risk of hijacking?

You discard the SDP information and instead reply to whatever address
the first RTP packet came from. If this first packet comes from a third
party, you end up with a session to the third party instead of a session
to the original target. As I said, this is a mild risk: the third party
has to be able to find out which port you listen to, and it has to have
good timing. Also, the third party has to find a way to shut down the
original target of the call.

-- Christian Huitema



From rem-conf Fri Mar 16 08:06:57 2001 
From rem-conf-request@es.net Fri Mar 16 08:06:57 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dwjo-0001Qg-00; Fri, 16 Mar 2001 08:06:00 -0800
Received: from sj-msg-core-1.cisco.com [171.71.163.11] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dwjn-0001Ib-00; Fri, 16 Mar 2001 08:05:59 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04980;
	Fri, 16 Mar 2001 08:04:52 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI32050;
	Fri, 16 Mar 2001 08:04:47 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03579; Fri, 16 Mar 2001 08:04:47 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.14750.967508.965470@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 08:04:46 -0800 (PST)
To: "Christian Huitema" 
Cc: "Jonathan Rosenberg" , ,
        , 
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



Christian Huitema writes:
 > > How does symmetric RTP create a risk of hijacking?
 > 
 > You discard the SDP information and instead reply to whatever address
 > the first RTP packet came from. If this first packet comes from a third
 > party, you end up with a session to the third party instead of a session
 > to the original target. As I said, this is a mild risk: the third party
 > has to be able to find out which port you listen to, and it has to have
 > good timing. Also, the third party has to find a way to shut down the
 > original target of the call.

   And this has a fairly straightforward solution in any
   case: use SRTP to place a keyed integrity check
   on the packet.

		Mike




From rem-conf Fri Mar 16 08:42:26 2001 
From rem-conf-request@es.net Fri Mar 16 08:42:26 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dxHF-0003Gh-00; Fri, 16 Mar 2001 08:40:33 -0800
Received: from sj-msg-core-2.cisco.com [171.69.43.88] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dxHE-0003Fp-00; Fri, 16 Mar 2001 08:40:32 -0800
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08293;
	Fri, 16 Mar 2001 08:39:44 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ACI32600;
	Fri, 16 Mar 2001 08:39:22 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03582; Fri, 16 Mar 2001 08:39:22 -0800 (PST)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15026.16826.454152.335949@thomasm-u1.cisco.com>
Date: Fri, 16 Mar 2001 08:39:22 -0800 (PST)
To: Jonathan Rosenberg 
Cc: "'Michael Thomas'" ,
        "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Jonathan Rosenberg writes:
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > Ie, allow RTP on a well
 > > known port and demux using the SSCR? I seem to
 > > recall that this has a fatal problem, but I can't
 > > remember what it is. I really should go re-read my
 > > Chapman/Zwicky first, but... If we could do this
 > > your BRTP proposal would make RTP look like any
 > > old UDP command/response protocol from the
 > > firewall standpoiont which might interesting.
 > 
 > It doesn't work when there are machines that have
 > multiple processes, each of which is terminating RTP.
 > Thats because you can no longer use the system provided
 > demux (ports), and now must resort to a new, intermediate
 > demux layer (using ssrc). Plus, it would require signaling
 > the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
 > in a separate thread on the sip list.

   On the first part, that's mainly an OS implementation
   issue; in fact, an OS could just ignore this problem
   and allow processes to camp on the well known port on 
   a first come first serve basis and it would probably
   work sort of OK until things got sorted out.

   The second part is more interesting. I think that
   we all agree that this would require some sort of 
   hint in SDP; I believe you suggested calling it
   BRTP ala the 1890 profile convention (*). If we
   assumed that that is what was placed into SDP,
   the normal thing a server does is reverses the
   source and destination port to reply, and the
   receiver could just camp on its source port to
   get the return flow, right? In fact, you might
   not even need to modify SDP at all if you got
   an IANA registered port and used that as the 
   key of whether to do BRTP or not. This may
   be risky though, but maybe not: an ignorant
   implementation would just issue a new SDP
   for the other direction which would fail, but
   that's the thing that would happen if it didn't 
   understand the semantics of the explicitly signaled BRTP
   in SDP.


[*] I'm a little worried about name space
    combinatorics here. how would you express
    BRTP+SRTP, for example, in SDP?

		   Mike




From rem-conf Fri Mar 16 09:58:42 2001 
From rem-conf-request@es.net Fri Mar 16 09:58:41 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dyS1-0005r4-00; Fri, 16 Mar 2001 09:55:45 -0800
Received: from (microappliances.com) [216.103.255.138] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14dyS0-0005qe-00; Fri, 16 Mar 2001 09:55:44 -0800
Received: (qmail 7646 invoked by uid 100); 16 Mar 2001 17:56:13 -0000
Date: 16 Mar 2001 17:56:13 -0000
Message-ID: <20010316175613.7645.qmail@microappliances.com>
From: shh@microappliances.com
To: Jonathan Rosenberg 
Reply-To: shh@microappliances.com
Cc: 'Michael Thomas' ,
  Jonathan Rosenberg ,
  "'sip@lists.bell-labs.com'" ,
  "'rem-conf@es.net'" ,
  "'confctrl@isi.edu'" 
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Sender: shh@microappliances.com
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


And of course there are SIP-ALGs that don't cost an arm and
a leg that solve all these problems (my biased opinion).

If SIP proxy vendors are interested in partnering to solve
this problem for their customers we would welcome that.

> >
> > On a different tangent, (never being one to shy
> > away from having multiple contradictory opinions
> > on the same subject), plain old firewalls (not
> > NAT'ing firewalls) are current still a problem
> > since they typically block the dynamic range for
> > RTP.
>

This problem is solved by a SIP ALG sitting in parallel with
a this kind of a firewall. AKA a side-car approach in which
timer based pin holes are created in the SIP-ALG.

Shiv
sip:shh@microappliances.com


Quoting Jonathan Rosenberg :

> 
>
>
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Thursday, March 15, 2001 5:28 PM
> > To: Jonathan Rosenberg
> > Cc: 'sip@lists.bell-labs.com'; 'rem-conf@es.net'; 'confctrl@isi.edu'
> > Subject: [SIP] symmetric RTP as a solution for NAT traversal
> >
> >
> >
> > Jonathan,
> >
> > On the surface this doesn't sound unreasonable to
> > me, but my main question is whether, in the end
> > you end up needing ALG functionality to deal with
> > NAT's whether this incremental step is necessary.
> > That is, if you end up needing an ALG to deal with
> > the UAS-behind-the-NAT problem, have we bought
> > anything?
>
> Well, you don't need an ALG to deal with UAS behind NAT.
> THe document handles the case where one, the other, or
> both users are behind NATs, without an ALG in all three cases.
> The case where both are behind NAT is still a bit unappealing> >
> > On a different tangent, (never being one to shy
> > away from having multiple contradictory opinions
> > on the same subject), plain old firewalls (not
> > NAT'ing firewalls) are current still a problem
> > since they typically block the dynamic range for
> > RTP.
>

> (requiring an rtp forwarder), but there still may be ways
> around that too, even.
>
> Other peer-peer apps have dealt with nats in intelligent
> ways, and I think its beneficial to learn from them.
>
> Yup.
>
> > Is it possible that this might be munged to
> > deal with that problem?
>
> In some respects, the problem gets easier with this change.
> I think (and am not sure), that an implication of using this
> symmetric RTP is that sip clients can now traverse socks v5.0
> compliant firewalls. Its just a suspicion - I'm looking for
> expert input to verify/reject that claim.
>
>
>
> > Ie, allow RTP on a well
> > known port and demux using the SSCR? I seem to
> > recall that this has a fatal problem, but I can't
> > remember what it is. I really should go re-read my
> > Chapman/Zwicky first, but... If we could do this
> > your BRTP proposal would make RTP look like any
> > old UDP command/response protocol from the
> > firewall standpoiont which might interesting.
>
> It doesn't work when there are machines that have
> multiple processes, each of which is terminating RTP.
> Thats because you can no longer use the system provided
> demux (ports), and now must resort to a new, intermediate
> demux layer (using ssrc). Plus, it would require signaling
> the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
> in a separate thread on the sip list.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 



From rem-conf Fri Mar 16 10:14:48 2001 
From rem-conf-request@es.net Fri Mar 16 10:14:47 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14dyj0-00076t-00; Fri, 16 Mar 2001 10:13:18 -0800
Received: from canospam.agcs.com [130.131.166.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14dyix-00076U-00; Fri, 16 Mar 2001 10:13:16 -0800
Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id LAA15902
	for ; Fri, 16 Mar 2001 11:13:10 -0700 (MST)
Posted-Date: Fri, 16 Mar 2001 11:13:10 -0700 (MST)
Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Fri Mar 16 11:13:17 2001 -0700
Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22704
	for ; Fri, 16 Mar 2001 11:12:56 -0700 (MST)
Received: from agcs.com ([130.131.26.189]) by pxmail2.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA382F;
          Fri, 16 Mar 2001 11:13:08 -0700
Message-ID: <3AB257B9.392435E@agcs.com>
Date: Fri, 16 Mar 2001 11:13:13 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rem-conf@es.net
CC: PacketCable PSTN Majordomo List 
Subject: RFC 2833 Duration Field
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

We are planning to use the RFC 2833 ABCD events but have noticed that
there might be a problem with the use of the duration field for this application.
Some ABCD event durations may have lengths much longer than what can
be represented in this field, which at 8000hz rate allows for approximately
eight seconds of duration.  A specific example of this is that one of these
ABCD patterns indicates that a line is on-hook.  This state can certainly
exceed eight seconds in an active call, the prime example being a 911 call
where the connection is not released automatically when the caller has gone
on-hook.

Has there been discussion of how to deal with durations larger than what
can be represented in the duration field?

One idea is to allow for the use of a duration of zero.  This would imply that
an event started at the time of the RTP timestamp, which would not give us
absolute preciseness of measurement.  However, some RTP events may not
need to have such accurate measurement in all applications.  The ABCD
events fit into this category.

Regards,
Rex Coldren




From rem-conf Fri Mar 16 11:46:39 2001 
From rem-conf-request@es.net Fri Mar 16 11:46:38 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e02o-0002Ij-00; Fri, 16 Mar 2001 11:37:50 -0800
Received: from mail.mediatrix.com [205.237.248.11] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e02m-0002IH-00; Fri, 16 Mar 2001 11:37:49 -0800
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 16 Mar 2001 14:35:06 -0500
Message-ID: 
From: Julien Myette 
To: rem-conf@es.net
Subject: RE: Interoperable implementations of G.723
Date: Fri, 16 Mar 2001 14:34:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Mediatrix Telecom supports the CommWorks Corporation request to retain the
G.723 payload. Our products are interoperable with Siemens, Microsoft
NetMeeting and others.

Julien Myette
Concepteur de logiciel / Software Designer

Mediatrix Telecom, Inc.   Tel.: (819) 829-8749 poste 362
4229 Garlock Street       Fax.: (819) 829-5100
Sherbrooke, Quebec        E-mail: mailto:jmyette@mediatrix.com
Canada J1L 2C8            Web: www.mediatrix.com


-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
Sent: Friday, March 16, 2001 10:28
To: casner@acm.org; rem-conf@es.net
Cc: Simao Campos-Neto
Subject: Interoperable implementations of G.723




To whom it may concern:

Please be advised that the CommWorks Corporation (formerly the 3Com Carrier
Networks Business, now a 3Com company) has implemented the ITU-T G.723 CODEC
in
several products. One product (TCS VoIP release 2.3) is released to the
field
and installed in a number of customer networks. Other near-term future
products,
now in development and test, will also include this capability.

We have tested and continue to test these products and this specific
capability
against products from a number of other vendors. I am not sure of the
appropriateness of identifying those vendors and products here, but may be
able
to do so if necessary.

Based on the above, the CommWorks Corporation requests that the G.723 audio
payload format be retained in the IETF A/V Profile RFC, contrary to current
plans to delete it.

I will be in Minneapolis for IETF 50 next week and plan to attend the
Audio/Video Transport Working Group meetings. I would be most happy to
discuss
this issue with anyone at that time, or by e-mail in advance.

Jim Renkel (e-mail: James_Renkel@3Com.com)
Director, Advanced Technology & System Engineering
The CommWorks Corporation, a 3Com company
formerly the 3Com Carrier Networks Business





From rem-conf Fri Mar 16 12:05:18 2001 
From rem-conf-request@es.net Fri Mar 16 12:05:18 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e0PB-0003uB-00; Fri, 16 Mar 2001 12:00:57 -0800
Received: from east.isi.edu [38.245.76.2] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e0P9-0003u1-00; Fri, 16 Mar 2001 12:00:55 -0800
Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA13237;
	Fri, 16 Mar 2001 15:00:41 -0500 (EST)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f2GK0lG07692;
	Fri, 16 Mar 2001 15:00:48 -0500
Message-Id: <200103162000.f2GK0lG07692@chiron.east.isi.edu>
To: rem-conf@es.net
Subject: G.723 implementations
cc: casner@acm.org
Date: Fri, 16 Mar 2001 15:00:47 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Folks,

Thanks for your help - we have noted that multiple interoperable 
implementations of G.723 exist, and this format will be re-instated 
in the next revision of the audio/video profile.

We are still missing implementations of the RTP payload formats
for GSM-HR, GSM-EFR, MP2T, MP1S, MP2P, BMPEG and BT656.

Colin



From rem-conf Fri Mar 16 12:23:41 2001 
From rem-conf-request@es.net Fri Mar 16 12:23:40 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e0gW-00054b-00; Fri, 16 Mar 2001 12:18:52 -0800
Received: from dominion.cisco.com [161.44.224.12] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e0gU-00053J-00; Fri, 16 Mar 2001 12:18:50 -0800
Received: from pots.cisco.com (mirapoint@pots.cisco.com [161.44.224.224])
	by dominion.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03342;
	Fri, 16 Mar 2001 15:17:53 -0500 (EST)
Received: from ORANLT ([171.69.210.11])
	by pots.cisco.com (Mirapoint)
	with ESMTP id AGK00373;
	Fri, 16 Mar 2001 15:17:46 -0500 (EST)
From: "David R. Oran" 
To: , 
Cc: "'PacketCable PSTN Majordomo List'" 
Subject: RE: RFC 2833 Duration Field
Date: Fri, 16 Mar 2001 15:19:28 -0500
Organization: Cisco Systems
Message-ID: <015601c0ae56$6769eeb0$0bd245ab@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2511
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3AB257B9.392435E@agcs.com>
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Couldn't you just send a continuation packet every few seconds?

> -----Original Message-----
> From: Rex Coldren [mailto:coldrenr@agcs.com] 
> Sent: Friday, March 16, 2001 1:13 PM
> To: rem-conf@es.net
> Cc: PacketCable PSTN Majordomo List
> Subject: RFC 2833 Duration Field
> 
> 
> We are planning to use the RFC 2833 ABCD events but have 
> noticed that there might be a problem with the use of the 
> duration field for this application. Some ABCD event 
> durations may have lengths much longer than what can be 
> represented in this field, which at 8000hz rate allows for 
> approximately eight seconds of duration.  A specific example 
> of this is that one of these ABCD patterns indicates that a 
> line is on-hook.  This state can certainly exceed eight 
> seconds in an active call, the prime example being a 911 call 
> where the connection is not released automatically when the 
> caller has gone on-hook.
> 
> Has there been discussion of how to deal with durations 
> larger than what can be represented in the duration field?
> 
> One idea is to allow for the use of a duration of zero.  This 
> would imply that an event started at the time of the RTP 
> timestamp, which would not give us absolute preciseness of 
> measurement.  However, some RTP events may not need to have 
> such accurate measurement in all applications.  The ABCD 
> events fit into this category.
> 
> Regards,
> Rex Coldren
> 
> 
> 




From rem-conf Fri Mar 16 12:46:01 2001 
From rem-conf-request@es.net Fri Mar 16 12:46:00 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e124-0006Dp-00; Fri, 16 Mar 2001 12:41:08 -0800
Received: from canospam.agcs.com [130.131.166.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e122-0006Df-00; Fri, 16 Mar 2001 12:41:06 -0800
Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id NAA26814
	for ; Fri, 16 Mar 2001 13:41:02 -0700 (MST)
Posted-Date: Fri, 16 Mar 2001 13:41:02 -0700 (MST)
Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Fri Mar 16 13:41:09 2001 -0700
Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id NAA02102
	for ; Fri, 16 Mar 2001 13:40:47 -0700 (MST)
Received: from agcs.com ([130.131.56.82]) by pxmail2.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA6472;
          Fri, 16 Mar 2001 13:40:59 -0700
Message-ID: <3AB27A5F.6B60D3EE@agcs.com>
Date: Fri, 16 Mar 2001 13:41:03 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David R. Oran" 
CC: rem-conf@es.net,
        "'PacketCable PSTN Majordomo List'" 
Subject: Re: RFC 2833 Duration Field
References: <015601c0ae56$6769eeb0$0bd245ab@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Please explain what a continuation packet is and how it will help
me get past the duration limit.

"David R. Oran" wrote:

> Couldn't you just send a continuation packet every few seconds?
>
> > -----Original Message-----
> > From: Rex Coldren [mailto:coldrenr@agcs.com]
> > Sent: Friday, March 16, 2001 1:13 PM
> > To: rem-conf@es.net
> > Cc: PacketCable PSTN Majordomo List
> > Subject: RFC 2833 Duration Field
> >
> >
> > We are planning to use the RFC 2833 ABCD events but have
> > noticed that there might be a problem with the use of the
> > duration field for this application. Some ABCD event
> > durations may have lengths much longer than what can be
> > represented in this field, which at 8000hz rate allows for
> > approximately eight seconds of duration.  A specific example
> > of this is that one of these ABCD patterns indicates that a
> > line is on-hook.  This state can certainly exceed eight
> > seconds in an active call, the prime example being a 911 call
> > where the connection is not released automatically when the
> > caller has gone on-hook.
> >
> > Has there been discussion of how to deal with durations
> > larger than what can be represented in the duration field?
> >
> > One idea is to allow for the use of a duration of zero.  This
> > would imply that an event started at the time of the RTP
> > timestamp, which would not give us absolute preciseness of
> > measurement.  However, some RTP events may not need to have
> > such accurate measurement in all applications.  The ABCD
> > events fit into this category.
> >
> > Regards,
> > Rex Coldren
> >
> >
> >




From rem-conf Fri Mar 16 13:12:53 2001 
From rem-conf-request@es.net Fri Mar 16 13:12:52 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e1Sw-0000Mn-00; Fri, 16 Mar 2001 13:08:54 -0800
Received: from (gbdmail.genband.com) [216.34.170.234] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14e1Sv-0000MR-00; Fri, 16 Mar 2001 13:08:53 -0800
Received: from 10.2.100.21 by gbdmail.genband.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 15:06:18 -0600 (Central Standard Time)
Received: by gbexc.genband.com with Internet Mail Service (5.5.2651.58)
	id <1S3ZJ5HB>; Fri, 16 Mar 2001 15:07:11 -0600
Message-ID: 
From: John Sirney 
To: "'coldrenr@agcs.com'" , "David R. Oran"
	 
Cc: rem-conf@es.net, 'PacketCable PSTN Majordomo List'
	 
Subject: RE: RFC 2833 Duration Field
Date: Fri, 16 Mar 2001 15:07:09 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Duration field of zero, will be equivalent to do Solution B
It would require multiple sends to insure no packet loss.


-----Original Message-----
From: Rex Coldren [mailto:coldrenr@agcs.com]
Sent: Friday, March 16, 2001 2:41 PM
To: David R. Oran
Cc: rem-conf@es.net; 'PacketCable PSTN Majordomo List'
Subject: Re: RFC 2833 Duration Field


Please explain what a continuation packet is and how it will help
me get past the duration limit.

"David R. Oran" wrote:

> Couldn't you just send a continuation packet every few seconds?
>
> > -----Original Message-----
> > From: Rex Coldren [mailto:coldrenr@agcs.com]
> > Sent: Friday, March 16, 2001 1:13 PM
> > To: rem-conf@es.net
> > Cc: PacketCable PSTN Majordomo List
> > Subject: RFC 2833 Duration Field
> >
> >
> > We are planning to use the RFC 2833 ABCD events but have
> > noticed that there might be a problem with the use of the
> > duration field for this application. Some ABCD event
> > durations may have lengths much longer than what can be
> > represented in this field, which at 8000hz rate allows for
> > approximately eight seconds of duration.  A specific example
> > of this is that one of these ABCD patterns indicates that a
> > line is on-hook.  This state can certainly exceed eight
> > seconds in an active call, the prime example being a 911 call
> > where the connection is not released automatically when the
> > caller has gone on-hook.
> >
> > Has there been discussion of how to deal with durations
> > larger than what can be represented in the duration field?
> >
> > One idea is to allow for the use of a duration of zero.  This
> > would imply that an event started at the time of the RTP
> > timestamp, which would not give us absolute preciseness of
> > measurement.  However, some RTP events may not need to have
> > such accurate measurement in all applications.  The ABCD
> > events fit into this category.
> >
> > Regards,
> > Rex Coldren
> >
> >
> >



From rem-conf Fri Mar 16 13:25:45 2001 
From rem-conf-request@es.net Fri Mar 16 13:25:45 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e1e7-0001Mz-00; Fri, 16 Mar 2001 13:20:27 -0800
Received: from mx4.tellabs.com [204.68.180.54] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e1e5-0001Jy-00; Fri, 16 Mar 2001 13:20:26 -0800
Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100])
	by mx4.tellabs.com (Mirapoint)
	with ESMTP id AAH29007;
	Fri, 16 Mar 2001 14:02:32 -0600 (CST)
From: 
Received: from localhost (root@localhost)
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA13462;
	Fri, 16 Mar 2001 14:01:28 -0600 (CST)
X-OpenMail-Hops: 1
Date: Fri, 16 Mar 2001 14:01:27 -0600
Message-Id: 
Subject: RE: RE: Interoperable implementations of G.723
MIME-Version: 1.0
TO: jmyette@mediatrix.com, rem-conf@es.net
Content-Type: multipart/alternative; boundary=openmail-part-1d919213-00000002
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


--openmail-part-1d919213-00000002
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
	;Creation-Date="Fri, 16 Mar 2001 14:01:27 -0600"
Content-Transfer-Encoding: 8bit

I'd like to voice my support for this request: we are also implementing
G.723.

Regards,

Dennis Montgomery


-----Original Message-----
From: jmyette@mediatrix.com [mailto:jmyette@mediatrix.com]
Sent: Friday, March 16, 2001 2:35 PM
To: rem-conf@es.net
Subject: RE: Interoperable implementations of G.723


Mediatrix Telecom supports the CommWorks Corporation request to retain
the
G.723 payload. Our products are interoperable with Siemens, Microsoft
NetMeeting and others.

Julien Myette
Concepteur de logiciel / Software Designer

Mediatrix Telecom, Inc.   Tel.: (819) 829-8749 poste 362
4229 Garlock Street       Fax.: (819) 829-5100
Sherbrooke, Quebec        E-mail: mailto:jmyette@mediatrix.com
Canada J1L 2C8            Web: www.mediatrix.com


-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
Sent: Friday, March 16, 2001 10:28
To: casner@acm.org; rem-conf@es.net
Cc: Simao Campos-Neto
Subject: Interoperable implementations of G.723




To whom it may concern:

Please be advised that the CommWorks Corporation (formerly the 3Com
Carrier
Networks Business, now a 3Com company) has implemented the ITU-T G.723
CODEC
in
several products. One product (TCS VoIP release 2.3) is released to the
field
and installed in a number of customer networks. Other near-term future
products,
now in development and test, will also include this capability.

We have tested and continue to test these products and this specific
capability
against products from a number of other vendors. I am not sure of the
appropriateness of identifying those vendors and products here, but may
be
able
to do so if necessary.

Based on the above, the CommWorks Corporation requests that the G.723
audio
payload format be retained in the IETF A/V Profile RFC, contrary to
current
plans to delete it.

I will be in Minneapolis for IETF 50 next week and plan to attend the
Audio/Video Transport Working Group meetings. I would be most happy to
discuss
this issue with anyone at that time, or by e-mail in advance.

Jim Renkel (e-mail: James_Renkel@3Com.com)
Director, Advanced Technology & System Engineering
The CommWorks Corporation, a 3Com company
formerly the 3Com Carrier Networks Business





--openmail-part-1d919213-00000002
Content-Type: application/rtf
Content-Disposition: attachment; filename="BDY.RTF"
	;Creation-Date="Fri, 16 Mar 2001 14:01:27 -0600"
Content-Transfer-Encoding: base64

e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYw
XGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmls
XGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5l
dzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1
NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwXGNmMCBJJ2QgbGlrZSB0
byB2b2ljZSBteSBzdXBwb3J0IGZvciB0aGlzIHJlcXVlc3Q6IHdlIGFyZSBhbHNvIGltcGxl
bWVudGluZyBHLjcyMy5ccGFyDQpccGFyDQpSZWdhcmRzLFxwYXINClxwYXINCkRlbm5pcyBN
b250Z29tZXJ5XHBhcg0KXHBhcg0KXHBhcg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS1c
cGFyDQpGcm9tOiBqbXlldHRlQG1lZGlhdHJpeC5jb20gW21haWx0bzpqbXlldHRlQG1lZGlh
dHJpeC5jb21dXHBhcg0KU2VudDogRnJpZGF5LCBNYXJjaCAxNiwgMjAwMSAyOjM1IFBNXHBh
cg0KVG86IHJlbS1jb25mQGVzLm5ldFxwYXINClN1YmplY3Q6IFJFOiBJbnRlcm9wZXJhYmxl
IGltcGxlbWVudGF0aW9ucyBvZiBHLjcyM1xwYXINClxwYXINClxwYXINCk1lZGlhdHJpeCBU
ZWxlY29tIHN1cHBvcnRzIHRoZSBDb21tV29ya3MgQ29ycG9yYXRpb24gcmVxdWVzdCB0byBy
ZXRhaW4gdGhlXHBhcg0KRy43MjMgcGF5bG9hZC4gT3VyIHByb2R1Y3RzIGFyZSBpbnRlcm9w
ZXJhYmxlIHdpdGggU2llbWVucywgTWljcm9zb2Z0XHBhcg0KTmV0TWVldGluZyBhbmQgb3Ro
ZXJzLlxwYXINClxwYXINCkp1bGllbiBNeWV0dGVccGFyDQpDb25jZXB0ZXVyIGRlIGxvZ2lj
aWVsIC8gU29mdHdhcmUgRGVzaWduZXJccGFyDQpccGFyDQpNZWRpYXRyaXggVGVsZWNvbSwg
SW5jLiAgIFRlbC46ICg4MTkpIDgyOS04NzQ5IHBvc3RlIDM2MlxwYXINCjQyMjkgR2FybG9j
ayBTdHJlZXQgICAgICAgRmF4LjogKDgxOSkgODI5LTUxMDBccGFyDQpTaGVyYnJvb2tlLCBR
dWViZWMgICAgICAgIEUtbWFpbDogbWFpbHRvOmpteWV0dGVAbWVkaWF0cml4LmNvbVxwYXIN
CkNhbmFkYSBKMUwgMkM4ICAgICAgICAgICAgV2ViOiB3d3cubWVkaWF0cml4LmNvbVxwYXIN
ClxwYXINClxwYXINCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tXHBhcg0KRnJvbTogSmFt
ZXNfUmVua2VsQDNjb20uY29tIFttYWlsdG86SmFtZXNfUmVua2VsQDNjb20uY29tXVxwYXIN
ClNlbnQ6IEZyaWRheSwgTWFyY2ggMTYsIDIwMDEgMTA6MjhccGFyDQpUbzogY2FzbmVyQGFj
bS5vcmc7IHJlbS1jb25mQGVzLm5ldFxwYXINCkNjOiBTaW1hbyBDYW1wb3MtTmV0b1xwYXIN
ClN1YmplY3Q6IEludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zIG9mIEcuNzIzXHBhcg0K
XHBhcg0KXHBhcg0KXHBhcg0KXHBhcg0KVG8gd2hvbSBpdCBtYXkgY29uY2VybjpccGFyDQpc
cGFyDQpQbGVhc2UgYmUgYWR2aXNlZCB0aGF0IHRoZSBDb21tV29ya3MgQ29ycG9yYXRpb24g
KGZvcm1lcmx5IHRoZSAzQ29tIENhcnJpZXJccGFyDQpOZXR3b3JrcyBCdXNpbmVzcywgbm93
IGEgM0NvbSBjb21wYW55KSBoYXMgaW1wbGVtZW50ZWQgdGhlIElUVS1UIEcuNzIzIENPREVD
XHBhcg0KaW5ccGFyDQpzZXZlcmFsIHByb2R1Y3RzLiBPbmUgcHJvZHVjdCAoVENTIFZvSVAg
cmVsZWFzZSAyLjMpIGlzIHJlbGVhc2VkIHRvIHRoZVxwYXINCmZpZWxkXHBhcg0KYW5kIGlu
c3RhbGxlZCBpbiBhIG51bWJlciBvZiBjdXN0b21lciBuZXR3b3Jrcy4gT3RoZXIgbmVhci10
ZXJtIGZ1dHVyZVxwYXINCnByb2R1Y3RzLFxwYXINCm5vdyBpbiBkZXZlbG9wbWVudCBhbmQg
dGVzdCwgd2lsbCBhbHNvIGluY2x1ZGUgdGhpcyBjYXBhYmlsaXR5LlxwYXINClxwYXINCldl
IGhhdmUgdGVzdGVkIGFuZCBjb250aW51ZSB0byB0ZXN0IHRoZXNlIHByb2R1Y3RzIGFuZCB0
aGlzIHNwZWNpZmljXHBhcg0KY2FwYWJpbGl0eVxwYXINCmFnYWluc3QgcHJvZHVjdHMgZnJv
bSBhIG51bWJlciBvZiBvdGhlciB2ZW5kb3JzLiBJIGFtIG5vdCBzdXJlIG9mIHRoZVxwYXIN
CmFwcHJvcHJpYXRlbmVzcyBvZiBpZGVudGlmeWluZyB0aG9zZSB2ZW5kb3JzIGFuZCBwcm9k
dWN0cyBoZXJlLCBidXQgbWF5IGJlXHBhcg0KYWJsZVxwYXINCnRvIGRvIHNvIGlmIG5lY2Vz
c2FyeS5ccGFyDQpccGFyDQpCYXNlZCBvbiB0aGUgYWJvdmUsIHRoZSBDb21tV29ya3MgQ29y
cG9yYXRpb24gcmVxdWVzdHMgdGhhdCB0aGUgRy43MjMgYXVkaW9ccGFyDQpwYXlsb2FkIGZv
cm1hdCBiZSByZXRhaW5lZCBpbiB0aGUgSUVURiBBL1YgUHJvZmlsZSBSRkMsIGNvbnRyYXJ5
IHRvIGN1cnJlbnRccGFyDQpwbGFucyB0byBkZWxldGUgaXQuXHBhcg0KXHBhcg0KSSB3aWxs
IGJlIGluIE1pbm5lYXBvbGlzIGZvciBJRVRGIDUwIG5leHQgd2VlayBhbmQgcGxhbiB0byBh
dHRlbmQgdGhlXHBhcg0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcgR3JvdXAgbWVl
dGluZ3MuIEkgd291bGQgYmUgbW9zdCBoYXBweSB0b1xwYXINCmRpc2N1c3NccGFyDQp0aGlz
IGlzc3VlIHdpdGggYW55b25lIGF0IHRoYXQgdGltZSwgb3IgYnkgZS1tYWlsIGluIGFkdmFu
Y2UuXHBhcg0KXHBhcg0KSmltIFJlbmtlbCAoZS1tYWlsOiBKYW1lc19SZW5rZWxAM0NvbS5j
b20pXHBhcg0KRGlyZWN0b3IsIEFkdmFuY2VkIFRlY2hub2xvZ3kgJiBTeXN0ZW0gRW5naW5l
ZXJpbmdccGFyDQpUaGUgQ29tbVdvcmtzIENvcnBvcmF0aW9uLCBhIDNDb20gY29tcGFueVxw
YXINCmZvcm1lcmx5IHRoZSAzQ29tIENhcnJpZXIgTmV0d29ya3MgQnVzaW5lc3NccGFyDQpc
cGFyDQpccGFyDQpccGFyDQp9

--openmail-part-1d919213-00000002--




From rem-conf Fri Mar 16 13:26:07 2001 
From rem-conf-request@es.net Fri Mar 16 13:26:07 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e1iM-0001Rb-00; Fri, 16 Mar 2001 13:24:50 -0800
Received: from canospam.agcs.com [130.131.166.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e1iK-0001RR-00; Fri, 16 Mar 2001 13:24:48 -0800
Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id OAA00216
	for ; Fri, 16 Mar 2001 14:24:47 -0700 (MST)
Posted-Date: Fri, 16 Mar 2001 14:24:47 -0700 (MST)
Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Fri Mar 16 14:24:54 2001 -0700
Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id OAA05143
	for ; Fri, 16 Mar 2001 14:24:32 -0700 (MST)
Received: from agcs.com ([130.131.56.82]) by pxmail2.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA71B6;
          Fri, 16 Mar 2001 14:24:44 -0700
Message-ID: <3AB2849F.80F7633C@agcs.com>
Date: Fri, 16 Mar 2001 14:24:47 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Sirney 
CC: "David R. Oran" ,
        "'PacketCable PSTN Majordomo List'" ,
        rem-conf@es.net
Subject: Re: RFC 2833 Duration Field
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

John,
   We should probably keep this part of the discussion to the
PacketCable reflector list since not many folks on the IETF
group from which I am trying to solicit input have an idea what
"Solution B" is.

   The purpose of this mailing is to solve the duration problem,
regardless of which approach we ultimately choose (Solution A
or B).  Keep in mind also that the PacketCable list discussion
should be kept to PacketCable NDA and IPR vendors.

Rex

John Sirney wrote:

> Duration field of zero, will be equivalent to do Solution B
> It would require multiple sends to insure no packet loss.
>
> -----Original Message-----
> From: Rex Coldren [mailto:coldrenr@agcs.com]
> Sent: Friday, March 16, 2001 2:41 PM
> To: David R. Oran
> Cc: rem-conf@es.net; 'PacketCable PSTN Majordomo List'
> Subject: Re: RFC 2833 Duration Field
>
> Please explain what a continuation packet is and how it will help
> me get past the duration limit.
>
> "David R. Oran" wrote:
>
> > Couldn't you just send a continuation packet every few seconds?
> >
> > > -----Original Message-----
> > > From: Rex Coldren [mailto:coldrenr@agcs.com]
> > > Sent: Friday, March 16, 2001 1:13 PM
> > > To: rem-conf@es.net
> > > Cc: PacketCable PSTN Majordomo List
> > > Subject: RFC 2833 Duration Field
> > >
> > >
> > > We are planning to use the RFC 2833 ABCD events but have
> > > noticed that there might be a problem with the use of the
> > > duration field for this application. Some ABCD event
> > > durations may have lengths much longer than what can be
> > > represented in this field, which at 8000hz rate allows for
> > > approximately eight seconds of duration.  A specific example
> > > of this is that one of these ABCD patterns indicates that a
> > > line is on-hook.  This state can certainly exceed eight
> > > seconds in an active call, the prime example being a 911 call
> > > where the connection is not released automatically when the
> > > caller has gone on-hook.
> > >
> > > Has there been discussion of how to deal with durations
> > > larger than what can be represented in the duration field?
> > >
> > > One idea is to allow for the use of a duration of zero.  This
> > > would imply that an event started at the time of the RTP
> > > timestamp, which would not give us absolute preciseness of
> > > measurement.  However, some RTP events may not need to have
> > > such accurate measurement in all applications.  The ABCD
> > > events fit into this category.
> > >
> > > Regards,
> > > Rex Coldren
> > >
> > >
> > >




From rem-conf Fri Mar 16 14:45:49 2001 
From rem-conf-request@es.net Fri Mar 16 14:45:48 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e2rx-0005BH-00; Fri, 16 Mar 2001 14:38:49 -0800
Received: from sj-msg-core-4.cisco.com [171.71.163.10] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e2rw-0005Ap-00; Fri, 16 Mar 2001 14:38:48 -0800
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA10865;
	Fri, 16 Mar 2001 14:37:41 -0800 (PST)
Received: from rkumar-ntl.cisco.com (dhcp-171-71-9-134.cisco.com [171.71.9.134])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id AAI16933 (AUTH rkumar);
	Fri, 16 Mar 2001 14:37:36 -0800 (PST)
Message-Id: <4.3.2.7.2.20010316144314.00db44a0@mira-sjc5-8>
X-Sender: rkumar@mira-sjc5-8
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 16 Mar 2001 14:43:25 -0800
To: rem-conf@es.net
From: Rajesh Kumar 
Subject: Note to AVT chair
Cc: mmostafa@cisco.com, fandreas@cisco.com, bfoster@cisco.com
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_16324954==_.ALT"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--=====================_16324954==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Dear AVT team and chair,
Thanks for agreeing to fix the "MF S1... S3"  discrepancy that I pointed 
out on the AVT list. There is another CAS-related rfc2833 problem that was 
brought to my notice by our implementation groups. If the AVT group and 
chair think this too warrants a fix, then you might want to bundle the two 
fixes together! I request the AVT chair to help find a standard solution to 
the following problem:
Background: Carriage of CAS ABCD bits via rfc2833 telephone events applies 
in the case of VoIP trunking i.e. where both bearer and  CAS signaling are 
transported via RTP/IP. For this leg, there is no call agent to interpret 
the CAS and to relay it in some message format (e.g. ISUP). VoIP trunking 
applications are typically used in the access segment of application such 
as wireless where bandwith is a premium.

Problem: The problem has to do with trunk conditioning in the case of CAS 
trunking. Trunk conditioning is used to indicate a per-channel failure. In 
the case of T1 (North American applications), the problem is fairly 
straightforward. You send an idle CAS pattern for 2.5 seconds followed by a 
seize (non-loop-start), or you send an idle pattern for the duration of the 
failure (loop-start).

In the case of European (E1) applications, you indicate per DS0 failures by 
sending a 0xFF  on the bearer path. The receiver integrates it for a 
certain duration and determines that the channel has failed. This is the 
equivalent of North American per-DS0 trunk conditioning, and it prevents a 
failed channel from being seized at the far-end.

A problem arises when you use the 0xFF code in a channel carried via RTP. 
Unlike normal voice, you need to transmit a continuous stream of packets 
and this defeats the normal benefits of silence suppression. Thus, if an E1 
(2.048 Mb/s) line experiences a loss of frame on the TDM side, all its 
channels need to be routed via a VoIP network via a continuous RTP "0xFF" 
stream. A better approach would be to introduce a new standard 
telephone-event "Channel failure". Like other rfc2833 events, this would be 
stateless (i.e. you do not have separate messages for onset and remission). 
As long as you keep on receiving this "Channel failure" telephone  event, 
the channel is marked as failed. The duration field is adjusted so that you 
that there is the right balance between consuming bandwidth by sending this 
"channel-failure" telephone event too often, and not having sufficient 
granularity in demarcating failure intervals for the channel. Typically, 1 
second is good enough. Triple redundancy with the "channel failure" 
telephone events with identical timestamps spaced at 20 ms intervals is 
recommended.
Please not that this is COMPLETELY different from the AAL2-like "state 
signalling" telephone events which I had suggested to Henning et all 
earlier: this is a stateless telephone-event like the ringback tone. If you 
do not consider this appropriate for rfc2833, please advise an alternate 
implementation in RTP-based VoIP CAS trunking scenarios. We have looked at 
all options, and haven't found any.





Thanks.

Rajesh
-------------------------------------
Dr. Rajesh Kumar, Principal Engineer
Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
-------------------------------------

Thanks.

Rajesh
------------------------------------------------
Rajesh Kumar, Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------------------


--=====================_16324954==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dear AVT team and chair,

Thanks for agreeing to fix the "MF S1... S3"  discrepancy
that I pointed out on the AVT list. There is another CAS-related rfc2833
problem that was brought to my notice by our implementation groups. If
the AVT group and chair think this too warrants a fix, then you might
want to bundle the two fixes together! I request the AVT chair to help
find a standard solution to the following problem:



Background: Carriage of CAS ABCD bits via rfc2833 telephone events
applies in the case of VoIP trunking i.e. where both bearer and  CAS
signaling are transported via RTP/IP. For this leg, there is no call
agent to interpret the CAS and to relay it in some message format (e.g.
ISUP). VoIP trunking applications are typically used in the access
segment of application such as wireless where bandwith is a=20
premium.





Problem: The problem has to do with trunk conditioning in the case of
CAS trunking. Trunk conditioning is used to indicate a per-channel
failure. In the case of T1 (North American applications), the problem is
fairly straightforward. You send an idle CAS pattern for 2.5 seconds
followed by a seize (non-loop-start), or you send an idle pattern for the
duration of the failure (loop-start).





In the case of European (E1) applications, you indicate per DS0
failures by sending a 0xFF  on the bearer path. The receiver
integrates it for a certain duration and determines that the channel has
failed. This is the equivalent of North American per-DS0 trunk
conditioning, and it prevents a failed channel from being seized at the
far-end.





A problem arises when you use the 0xFF code in a channel carried via
RTP. Unlike normal voice, you need to transmit a continuous stream of
packets and this defeats the normal benefits of silence suppression.
Thus, if an E1 (2.048 Mb/s) line experiences a loss of frame on the TDM
side, all its channels need to be routed via a VoIP network via a
continuous RTP "0xFF" stream. A better approach would be to
introduce a new standard telephone-event "Channel failure".
Like other rfc2833 events, this would be stateless (i.e. you do not have
separate messages for onset and remission). As long as you keep on
receiving this "Channel failure" telephone  event, the
channel is marked as failed. The duration field is adjusted so that you
that there is the right balance between consuming bandwidth by sending
this "channel-failure" telephone event too often, and not
having sufficient granularity in demarcating failure intervals for the
channel. Typically, 1 second is good enough. Triple redundancy with the
"channel failure" telephone events with identical timestamps
spaced at 20 ms intervals is recommended.

Please not that this is COMPLETELY different from the AAL2-like
"state signalling" telephone events which I had suggested to
Henning et all earlier: this is a stateless telephone-event like the
ringback tone. If you do not consider this appropriate for rfc2833,
please advise an alternate implementation in RTP-based VoIP CAS trunking
scenarios. We have looked at all options, and haven't found any.









 

Thanks.



Rajesh

------------------------------------- 

Dr. Rajesh Kumar, Principal Engineer

Cisco Voice Technology Center 

Tel: 408-527-0811, Fax: 408-853-1101 

Epage:
mailto:rkumar@epage.cisco.com

------------------------------------- 




Thanks.



Rajesh

------------------------------------------------

Rajesh Kumar, Cisco Voice Technology Center 

Tel: 408-527-0811, Fax: 408-853-1101 

Epage:
mailto:rkumar@epage.cisco.com

------------------------------------------------ 





--=====================_16324954==_.ALT--




From rem-conf Fri Mar 16 15:38:07 2001 
From rem-conf-request@es.net Fri Mar 16 15:38:07 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e3jZ-0007VQ-00; Fri, 16 Mar 2001 15:34:13 -0800
Received: from canospam.agcs.com [130.131.166.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e3jX-0007VG-00; Fri, 16 Mar 2001 15:34:11 -0800
Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id QAA09494
	for ; Fri, 16 Mar 2001 16:34:11 -0700 (MST)
Posted-Date: Fri, 16 Mar 2001 16:34:11 -0700 (MST)
Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Fri Mar 16 16:34:12 2001 -0700
Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id QAA12985
	for ; Fri, 16 Mar 2001 16:33:56 -0700 (MST)
Received: from agcs.com ([130.131.56.82]) by pxmail2.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA213C;
          Fri, 16 Mar 2001 16:34:09 -0700
Message-ID: <3AB2A2F3.F793F563@agcs.com>
Date: Fri, 16 Mar 2001 16:34:11 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rem-conf@es.net, john.sirney@genband.com
Subject: [Fwd: Re: RFC 2833 Duration Field] bis
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

I must apologize here to John for inadvertently setting him up for 
this with a cross-posting.  I should have primed the PacketCable
reflector prior to sending this cross-posting.  Sorry, John.

Rex

-------- Original Message --------
Subject: Re: RFC 2833 Duration Field
Date: Fri, 16 Mar 2001 14:24:47 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
To: John Sirney 
CC: "David R. Oran" ,"'PacketCable PSTN Majordomo List'"
,rem-conf@es.net
References: 

John,
   We should probably keep this part of the discussion to the
PacketCable reflector list since not many folks on the IETF
group from which I am trying to solicit input have an idea what
"Solution B" is.

   The purpose of this mailing is to solve the duration problem,
regardless of which approach we ultimately choose (Solution A
or B).  Keep in mind also that the PacketCable list discussion
should be kept to PacketCable NDA and IPR vendors.

Rex

John Sirney wrote:

> Duration field of zero, will be equivalent to do Solution B
> It would require multiple sends to insure no packet loss.
>
> -----Original Message-----
> From: Rex Coldren [mailto:coldrenr@agcs.com]
> Sent: Friday, March 16, 2001 2:41 PM
> To: David R. Oran
> Cc: rem-conf@es.net; 'PacketCable PSTN Majordomo List'
> Subject: Re: RFC 2833 Duration Field
>
> Please explain what a continuation packet is and how it will help
> me get past the duration limit.
>
> "David R. Oran" wrote:
>
> > Couldn't you just send a continuation packet every few seconds?
> >
> > > -----Original Message-----
> > > From: Rex Coldren [mailto:coldrenr@agcs.com]
> > > Sent: Friday, March 16, 2001 1:13 PM
> > > To: rem-conf@es.net
> > > Cc: PacketCable PSTN Majordomo List
> > > Subject: RFC 2833 Duration Field
> > >
> > >
> > > We are planning to use the RFC 2833 ABCD events but have
> > > noticed that there might be a problem with the use of the
> > > duration field for this application. Some ABCD event
> > > durations may have lengths much longer than what can be
> > > represented in this field, which at 8000hz rate allows for
> > > approximately eight seconds of duration.  A specific example
> > > of this is that one of these ABCD patterns indicates that a
> > > line is on-hook.  This state can certainly exceed eight
> > > seconds in an active call, the prime example being a 911 call
> > > where the connection is not released automatically when the
> > > caller has gone on-hook.
> > >
> > > Has there been discussion of how to deal with durations
> > > larger than what can be represented in the duration field?
> > >
> > > One idea is to allow for the use of a duration of zero.  This
> > > would imply that an event started at the time of the RTP
> > > timestamp, which would not give us absolute preciseness of
> > > measurement.  However, some RTP events may not need to have
> > > such accurate measurement in all applications.  The ABCD
> > > events fit into this category.
> > >
> > > Regards,
> > > Rex Coldren
> > >
> > >
> > >



From rem-conf Fri Mar 16 20:45:15 2001 
From rem-conf-request@es.net Fri Mar 16 20:45:14 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e8Tk-0000t5-00; Fri, 16 Mar 2001 20:38:12 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e8Ti-0000sv-00; Fri, 16 Mar 2001 20:38:10 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19544;
	Fri, 16 Mar 2001 23:41:18 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 16 Mar 2001 23:40:05 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'shh@microappliances.com'" ,
        Jonathan Rosenberg 
Cc: "'Michael Thomas'" ,
        "'sip@lists.bell-labs.com'"
	 ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'" 
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 23:40:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 

> -----Original Message-----
> From: shh@microappliances.com [mailto:shh@microappliances.com]
> Sent: Friday, March 16, 2001 12:56 PM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; Jonathan Rosenberg; 'sip@lists.bell-labs.com';
> 'rem-conf@es.net'; 'confctrl@isi.edu'
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> 
> And of course there are SIP-ALGs that don't cost an arm and
> a leg that solve all these problems (my biased opinion).
> 
> If SIP proxy vendors are interested in partnering to solve
> this problem for their customers we would welcome that.
> 
> > >
> > > On a different tangent, (never being one to shy
> > > away from having multiple contradictory opinions
> > > on the same subject), plain old firewalls (not
> > > NAT'ing firewalls) are current still a problem
> > > since they typically block the dynamic range for
> > > RTP.
> >
> 
> This problem is solved by a SIP ALG sitting in parallel with
> a this kind of a firewall. AKA a side-car approach in which
> timer based pin holes are created in the SIP-ALG.

I guess I'm just not making myself clear here.

This "side-car" approach, ala midcom, is just fine for service provider
networks, where the provider is rolling out a firewall/NAT and is well aware
of this application, and the need to support it. Same story for an
enterprise rolling out sip internally. Indeed, my company sells just such a
solution. That is NOT the problem space I am talking about.

I am talking here about NATs which sit between subscribers and their
providers, where there is NOT A RELATIONSHIP between the NAT and the proxies
run by sip provider. In this scenario, there is no way to connect the NAT to
an ALG in the network.

Let me give an example. I have a nat box at home. Its made by Linksys. You
can buy them in CompUSA for $150. It is meant to be an easy to use, cheap,
consumer device. It does not have SIP ALG support embedded in it. Nor does
it have controls that allow an external proxy ALG sitting in the network to
control it. Nor am I alone in having such NATs. OK, now I want to get SIP
service. Apparently, Shiv is proposing that I wait for Linksys to embed an
ALG in their $150 box, if that should ever happen, or wait for midcom
support in that box, once the standards are complete. He also proposes that
my SIP service provider wait to turn on service, until their potential
customers get such new boxes. Sounds like a great way to go out of business.
The alternative is that the provider modifies the components they have
control over - the client device and the server, so they work through
Linksys and *any* other NAT their customers might have. Unlike Linksys, who
would need to worry about every protocol that might ever get used (whcih
they simply won't), the sip service provider needs to only worry about one
protocol - sip. The sip provider is the one making money on the service, so
it is them who is motivated to solve this problem.

Another example. Many cable modem providers have NATs that hide their entire
network. Every subscriber that gets cable modem service from one of these
providers is behind a nat, and doesn't even know it. The subscriber wants
sip services from some other provider. There is no way, ever, that the cable
modem provider is going to allow random SIP providers to control their
firewalls. Nor is the cable modem provider motivated to upgrade their nat to
support sip alg. The cable provider won't make any money from it. Their
subscribers aren't using sip services (they can't). Why bother?

This is not a theoretical problem for which we posit the theoretically ideal
solution. I already know the ideal solution, which is to throw all the nats
out and deploy IPV6. Now waiting for that is a really good way to go out of
business.

Solutions like what I am proposing have already been done in countless other
applications, where there were no standards. Even within VoIP, proprietary
VoIP protocols are using solutions like what I describe in order to traverse
NATs (yahoo, MSN, AOL voice). Those guys care about deployment, and so do I.
But, I also care about standards. So, instead of having everyone hack things
up horribly in a proprietary way, I'm proposing a small modification to the
way this stuff is handled, which can help all of us deploy SIP now through
existing NATs. Shiv can wait for everyone to upgrade their NATs (several
years, probably). I'd rather not.

-Jonathan R.




---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com




From rem-conf Fri Mar 16 20:49:06 2001 
From rem-conf-request@es.net Fri Mar 16 20:49:05 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14e8a5-000100-00; Fri, 16 Mar 2001 20:44:45 -0800
Received: from redball.dynamicsoft.com [216.173.40.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14e8a3-0000zQ-00; Fri, 16 Mar 2001 20:44:43 -0800
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19580;
	Fri, 16 Mar 2001 23:47:58 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 16 Mar 2001 23:46:45 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        Jonathan Rosenberg
	 
Cc: "'sip@lists.bell-labs.com'" ,
        "'rem-conf@es.net'" ,
        "'confctrl@isi.edu'"
	 
Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
Date: Fri, 16 Mar 2001 23:46:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, March 16, 2001 11:39 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; 'sip@lists.bell-labs.com'; 'rem-conf@es.net';
> 'confctrl@isi.edu'
> Subject: RE: [SIP] symmetric RTP as a solution for NAT traversal
> 
> 
> Jonathan Rosenberg writes:
>  > > From: Michael Thomas [mailto:mat@cisco.com]
>  > > Ie, allow RTP on a well
>  > > known port and demux using the SSCR? I seem to
>  > > recall that this has a fatal problem, but I can't
>  > > remember what it is. I really should go re-read my
>  > > Chapman/Zwicky first, but... If we could do this
>  > > your BRTP proposal would make RTP look like any
>  > > old UDP command/response protocol from the
>  > > firewall standpoiont which might interesting.
>  > 
>  > It doesn't work when there are machines that have
>  > multiple processes, each of which is terminating RTP.
>  > Thats because you can no longer use the system provided
>  > demux (ports), and now must resort to a new, intermediate
>  > demux layer (using ssrc). Plus, it would require signaling
>  > the SSRC within SDP/SIP. Much akin to the SCTP stream discussion
>  > in a separate thread on the sip list.
> 
>    On the first part, that's mainly an OS implementation
>    issue; in fact, an OS could just ignore this problem
>    and allow processes to camp on the well known port on 
>    a first come first serve basis and it would probably
>    work sort of OK until things got sorted out.

I don't follow you. If its FCFS, all the other apps won't get any 
of their packets. 


> 
>    The second part is more interesting. I think that
>    we all agree that this would require some sort of 
>    hint in SDP; I believe you suggested calling it
>    BRTP ala the 1890 profile convention (*). If we
>    assumed that that is what was placed into SDP,
>    the normal thing a server does is reverses the
>    source and destination port to reply, and the
>    receiver could just camp on its source port to
>    get the return flow, right? 

Yes.


In fact, you might
>    not even need to modify SDP at all if you got
>    an IANA registered port and used that as the 
>    key of whether to do BRTP or not. 

I generally prefer to be explicit about it. Either way its an extension
to the client in semantics. May as well reflect that in syntax.

Christian writes:
> > How does symmetric RTP create a risk of hijacking?
> 
> You discard the SDP information and instead reply to whatever address
> the first RTP packet came from. If this first packet comes 
> from a third
> party, you end up with a session to the third party instead 
> of a session
> to the original target. As I said, this is a mild risk: the 
> third party
> has to be able to find out which port you listen to, and it 
> has to have
> good timing. Also, the third party has to find a way to shut down the
> original target of the call.

The same thing can pretty much happen in current SIP/SDP/RTP. I snoop some
SIP/SDP on the wire, and learn the IP address port the caller is listening
on. I then send them packets. The called party will also send packets to the
caller. The caller can't tell who is the real called party, and who is the
attacker. So, it either plays both (which is what would happen using RTP
semantics - mix all SSRC you receive on a session), drops the call, or picks
one (the wrong one half the time). Seems just as bad. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com



From rem-conf Sat Mar 17 10:42:55 2001 
From rem-conf-request@es.net Sat Mar 17 10:42:54 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14eLXo-0002uD-00; Sat, 17 Mar 2001 10:35:16 -0800
Received: from (mobydick.paltalk.com) [216.74.151.143] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14eLXm-0002tZ-00; Sat, 17 Mar 2001 10:35:14 -0800
Received: from mobydick - 216.74.151.143 by mobydick.paltalk.com  with Microsoft SMTPSVC(5.5.1774.114.11);
	 Sat, 17 Mar 2001 13:25:29 -0500
X-Mailer: JgMail Version 1.2.3
Date: Sat, 17 Mar 2001 13:25:29 EST
To:  
From: nubeus@nubeus.com
Subject: Talk Free Online and Win a Trip to Cancun!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <089a72925181131MOBYDICK@mobydick.paltalk.com>
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Dear rem-conf@es.net,

obi nubeus (nubeus@nubeus.com) invites you to join the PalTalk community, and win a trip to Cancun!

PalTalk enables LONG DISTANCE CALLS to anyone in the world, amazing Voice Chat Rooms, Live Video Calls and lots more - all 100% free.

Join today, and enter our special CANCUN VACATION GIVEAWAY!

For a quick and easy start, click here: 

	http://www.paltalk.com/download/0.x/pal_install.exe


PalTalk.com
The #1 Voice Quality on the Net

Click here to delist: 
http://service.paltalk.com:8080/srv/ps.d2.jrun?e=7210161Irem-conf@es.net



From rem-conf Sat Mar 17 16:19:18 2001 
From rem-conf-request@es.net Sat Mar 17 16:19:17 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14eQjW-0004ID-00; Sat, 17 Mar 2001 16:07:42 -0800
Received: from cs.columbia.edu [128.59.16.20] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14eQjQ-0004Hx-00; Sat, 17 Mar 2001 16:07:36 -0800
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA03028;
	Sat, 17 Mar 2001 19:07:32 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA28450;
	Sat, 17 Mar 2001 19:07:26 -0500 (EST)
Message-ID: <3AB4276C.B531689A@cs.columbia.edu>
Date: Sat, 17 Mar 2001 19:11:40 -0800
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rajesh Kumar 
CC: rem-conf@es.net, mmostafa@cisco.com, fandreas@cisco.com, bfoster@cisco.com
Subject: Re: Note to AVT chair
References: <4.3.2.7.2.20010316144314.00db44a0@mira-sjc5-8>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

I would suggest you write up a paragraph or two describing the
application. Assuming there is no opposition, I can then include this in
the next version leading to RFC2833bis.

Rajesh Kumar wrote:
> 
> Dear AVT team and chair,
> Thanks for agreeing to fix the "MF S1... S3"  discrepancy that I
> pointed out on the AVT list. There is another CAS-related rfc2833
> problem that was brought to my notice by our implementation groups. If
> the AVT group and chair think this too warrants a fix, then you might
> want to bundle the two fixes together! I request the AVT chair to help
> find a standard solution to the following problem:
> 
>      Background: Carriage of CAS ABCD bits via rfc2833 telephone
>      events applies in the case of VoIP trunking i.e. where both
>      bearer and  CAS signaling are transported via RTP/IP. For this
>      leg, there is no call agent to interpret the CAS and to relay it
>      in some message format (e.g. ISUP). VoIP trunking applications
>      are typically used in the access segment of application such as
>      wireless where bandwith is a premium.
> 
>      Problem: The problem has to do with trunk conditioning in the
>      case of CAS trunking. Trunk conditioning is used to indicate a
>      per-channel failure. In the case of T1 (North American
>      applications), the problem is fairly straightforward. You send an
>      idle CAS pattern for 2.5 seconds followed by a seize
>      (non-loop-start), or you send an idle pattern for the duration of
>      the failure (loop-start).
> 
>      In the case of European (E1) applications, you indicate per DS0
>      failures by sending a 0xFF  on the bearer path. The receiver
>      integrates it for a certain duration and determines that the
>      channel has failed. This is the equivalent of North American
>      per-DS0 trunk conditioning, and it prevents a failed channel from
>      being seized at the far-end.
> 
>      A problem arises when you use the 0xFF code in a channel carried
>      via RTP. Unlike normal voice, you need to transmit a continuous
>      stream of packets and this defeats the normal benefits of silence
>      suppression. Thus, if an E1 (2.048 Mb/s) line experiences a loss
>      of frame on the TDM side, all its channels need to be routed via
>      a VoIP network via a continuous RTP "0xFF" stream. A better
>      approach would be to introduce a new standard telephone-event
>      "Channel failure". Like other rfc2833 events, this would be
>      stateless (i.e. you do not have separate messages for onset and
>      remission). As long as you keep on receiving this "Channel
>      failure" telephone  event, the channel is marked as failed. The
>      duration field is adjusted so that you that there is the right
>      balance between consuming bandwidth by sending this
>      "channel-failure" telephone event too often, and not having
>      sufficient granularity in demarcating failure intervals for the
>      channel. Typically, 1 second is good enough. Triple redundancy
>      with the "channel failure" telephone events with identical
>      timestamps spaced at 20 ms intervals is recommended.
> 
> Please not that this is COMPLETELY different from the AAL2-like "state
> signalling" telephone events which I had suggested to Henning et all
> earlier: this is a stateless telephone-event like the ringback tone.
> If you do not consider this appropriate for rfc2833, please advise an
> alternate implementation in RTP-based VoIP CAS trunking scenarios. We
> have looked at all options, and haven't found any.
> 
> 
> Thanks.
> 
> Rajesh
> -------------------------------------
> Dr. Rajesh Kumar, Principal Engineer
> Cisco Voice Technology Center
> Tel: 408-527-0811, Fax: 408-853-1101
> Epage: mailto:rkumar@epage.cisco.com
> -------------------------------------
> 
> Thanks.
> 
> Rajesh
> ------------------------------------------------
> Rajesh Kumar, Cisco Voice Technology Center
> Tel: 408-527-0811, Fax: 408-853-1101
> Epage: mailto:rkumar@epage.cisco.com
> ------------------------------------------------



From rem-conf Sat Mar 17 21:46:32 2001 
From rem-conf-request@es.net Sat Mar 17 21:46:32 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14eVu0-00067Q-00; Sat, 17 Mar 2001 21:38:52 -0800
Received: from hse-ottawa-ppp157677.sympatico.ca (serv.mail.com) [64.229.131.94] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14eVtr-00065T-00; Sat, 17 Mar 2001 21:38:43 -0800
From: 
Subject: It's Your Turn !
Date: Sun, 18 Mar 2001 02:55:53
Message-Id: <495.424008.588248@serv.mail.com>
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

AS SEEN ON NATIONAL TV: 
Making over half million dollars every 4 to 5 months right from 
your home !! 
THANK'S TO THE COMPUTER AGE AND THE INTERNET ! 
================================================== 
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! 
Before you say ''Bull'', please read the following. This is the 
letter you have been hearing about on the news lately. Due to the 
popularity of this letter on the Internet, a national weekly news 
program recently devoted an entire show to the investigation of 
this program described below, to see if it really can make people 
money. The show also investigated whether or not the program was 
legal. Their findings proved once and for all that there are 
''absolutely NO Laws prohibiting the participation in the program 
and if people can -follow the simple instructions, they are bound 
to make some mega bucks with only $25 out of pocket cost''. DUE 
TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS 
ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. 
This is what one had to say: ''Thanks to this profitable 
opportunity. I was approached many times before but each time I 
passed on it. I am so gladI finally joined just to see what one 
could expect in return for the minimal effort and money required. 
To my astonishment, I received total $610,470.00 in 21 weeks, 
with money still coming in." Pam Hedland, Fort Lee, New Jersey. 
=================================================== 
Here is another testimonial: "This program has been around for a 
long time but I never believed in it. But one day when I received 
this again in the mail I decided to gamble my $25 on it. I 
followed the simple instructions and walaa ..... 3 weeks later 
the money started to come in. First month I only made $240.00 but 
the next 2 months after that I made a total of $290,000.00. So 
far, in the past 8 months by re-entering the program, I have made 
over $710,000.00 and I am playing it again. The key to success in 
this program is to follow the simple steps and NOT change 
anything.'' More testimonials later but first, 
===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
If you would like to make at least $500,000 every 4 to 5 months 
easily and comfortably, please read the following...THEN READ IT 
AGAIN and AGAIN!!! 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: 
=====Order all 5 reports shown on the list below ===== 
For each report, send $5 CASH (US FUNDS ONLY), THE NAME & NUMBER 
OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose 
name appears ON THAT LIST next to the report. MAKE SURE YOUR 
RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any 
mail problems. 
=== When you place your order, make sure you order each of the 5 
reports. You will need all 5 reports so that you can save them on 
your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. 
Within a few days you will receive, vie e-mail, each of the 5 
reports from these 5 different individuals. Save them on your 
computer so they will be accessible for you to send to the 
1,000's of people who will order them from you. Also make a 
floppy of these reports and keep it on your desk in 
case something happen to your computer. 
IMPORTANT - DO NOT alter the names of the people who are listed 
next to each report, or their sequence on the list, in any way 
other than what is instructed below in step '' 1 through 6 '' or 
you will loose out on majority of your profits. Once you 
understand the way this works, you will also see 
how it does not work if you change it. Remember, this method has 
been tested, and if you alter, it will NOT work !!! People have 
tried to put their friends/relatives names on all five thinking 
they could get all the money. But it does not work this way. 
Believe us, we all have tried to be greedy and then 
nothing happened. So Do Not try to change anything other than 
what is instructed. Because if you do, it will not work for you. 
Remember, honesty reaps the reward!!! 
1.... After you have ordered all 5 reports, take this 
advertisement and REMOVE the name & address of the person in 
REPORT # 5. This person has made it through the cycle and is no 
doubt counting their fortune. 
2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 
3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 
4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 
5.... Move the name & address in REPORT # 1 down TO REPORT # 2 
6.... Insert YOUR name & address in the REPORT # 1 Position. 
PLEASE MAKE SURE you copy every name & address ACCURATELY! 
========================================================== 
**** Take this entire letter, with the modified list of names, 
and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. 
Save this on a disk as well just in case if you loose any data. 
To assist you with marketing your business on the internet, the 5 
reports you purchase will provide you with invaluable marketing 
information which includes how to send bulk e-mails legally, 
where to find thousands of free classified ads and much more. 
There are 2 Primary methods to get this venture going: 
METHOD # 1: BY SENDING BULK E-MAIL LEGALLY 
========================================================== 
Let's say that you decide to start small, just to see how it 
goes, and we will assume You and those involved send out only 
5,000 e-mails each. Let's also assume that the mailing receive 
only a 0.2% response (the response could be much better but lets 
just say it is only 0.2%. Also many people will send out hundreds 
of thousands e-mails instead of only 5,000 each). 
Continuing with this example, you send out only 5,000 e-mails. 
With a 0.2% response, that is only 10 orders for report # 1. 
Those 10 people responded by sending out 5,000 e-mail each for a 
total of 50,000. Out of those 50,000 e-mails only 0.2% responded 
with orders. That's=100 people responded and ordered Report # 2. 
Those 100 people mail out 5,000 e-mails each for a total of 
500,000 e-mails. The 0.2% response to that is 1000 orders for 
Report # 3. Those 1000 people send out 5,000 e-mails each for a 
total of 5 million e-mails sent out. The 0.2% response to that is 
10,000 orders for Report # 4. Those 10,000 people send out 5,000 
e-mails each for a total of 50,000,000 (50 million) e-mails. The 
0.2% response to that is 100,000 orders for Report # 5 THAT'S 
100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). 
Your total income in this example is: 1..... $50 + 2..... $500 + 
3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand 
Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND 
FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU 
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! 
========================================================= 
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE 
ORDERING OUT OF 5,000 YOU MAILED TO. 
Dare to think for a moment what would happen if everyone or half 
or even one 4th of those people mailed 100,000e-mails each or 
more? There are over 150 million people on the Internet worldwide 
and counting. Believe me, many people will do just that, and 
more! 
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET 
======================================================= 
Advertising on the net is very very inexpensive and there are 
hundreds of FREE places to advertise. Placing a lot of free ads 
on the Internet will easily get a larger response. We strongly 
suggest you start with Method # 1 and dd METHOD # 2 as you go 
along. For every $5 you receive, all you must do is e-mail them 
the Report they ordered. That's it. Always provide same day 
service on all orders. This will guarantee that the e-mail they 
send out, with your name and address on it, will be prompt 
because they can not advertise until they receivethe report. 
=========== AVAILABLE REPORTS ==================== 
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: 
Always send $5 cash (U.S. CURRENCY ONLY!!) for each Report. 
Checks NOT 
accepted. Make sure the cash is concealed by wrapping it in at 
least 2 sheets of paper. On one of those sheets of paper, Write 
the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL 
ADDRESS and your name and postal address. 
PLACE YOUR ORDER FOR THESE REPORTS NOW : 
==================================================== 
REPORT # 1: "The Insider's Guide to Advertising for Free on the 
Net" Order Report #1 from: 

B. McDonald
Suite 409
1500 Bank St
Ottawa, ON
K1H 1B8
Canada
___________________________________________________________ 
REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the 
Net" Order Report # 2 from: 

T. Richardson
P.O. Box 753
Richland, MO. 65556
USA 
____________________________________________________________ 
REPORT # 3: "Secret to Multilevel Marketing on the Net" 
Order Report # 3 from : 

C.J. Kalata 
P.O. Box 130157 
Roseville, MN 55113
USA 
____________________________________________________________ 
REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" 
Order Report # 4 from:

R. B. 
Box. 21115, 
Grande Prairie 
Alberta, T8V-6W7 
Canada 
____________________________________________________________ 
REPORT #5: "How to Send Out 0ne Million e-mails for Free" 
Order Report # 5 from: 

B. Taylor 
P.O.Box 26001 
Fredericton, N.B. 
E3A 5V8 
Canada
_____________________________________________________________ 
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ 
Follow these guidelines to guarantee your success: 
=== If you do not receive at least 10 orders for Report #1 within 
2 weeks, continue sending e-mails until you do. 
=== After you have received 10 orders, 2 to 3 weeks after that 
you should receive 100 orders or more for REPORT # 2. If you did 
not, continue advertising or sending e-mails until you do. 
=== Once you have received 100 or more orders for Report # 2, YOU 
CAN RELAX, because the system is already working for you, and the 
cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: 
Every time your name is moved down on the list, you are placed in 
front of a Different report. 
You can KEEP TRACK of your PROGRESS by watching which report 
people are ordering from you. IF YOU WANT TO GENERATE MORE 
INCOME SEND ANOTHER BATCH OF E-MAILS AND START 
THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this 
business !!! 
====================================================== 
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS 
PROGRAM: You have just received information that can give you 
financial freedom for the rest of your life, with NO RISK and 
JUST A LITTLE BIT OF EFFORT. You can make more money in the next 
few weeks and months than you have ever imagined. Follow the 
program EXACTLY AS INSTRUCTED. Do Not change it in any way. It 
works exceedingly well as it is now. 
Remember to e-mail a copy of this exciting report after you have 
put your name and address in Report #1 and moved others to #2 
..........# 5 
as instructed above. One of the people you send this to may send 
out 100,000 or more e-mails and your name will be on every one of 
them. Remember though, the more you send out the more potential 
customers you will reach. 
So my friend, I have given you the ideas, information, materials 
and opportunity to become financially independent. IT IS UP TO 
YOU NOW ! 
============ MORE TESTIMONIALS ================ 
"My name is Mitchell. My wife, Jody and I live in Chicago. I am 
an accountant with a major U.S. Corporation and I make pretty 
good money. When I received this program I grumbled to 
Jodyaboutreceiving ''junk mail''. I made fun of the whole 
thing,spoutingmy knowledge of the population and percentages 
involved. I ''knew'' it wouldn't work. Jody totally ignored 
my supposed intelligence and few days later she jumped in with 
both feet. I made merciless fun of her, and was ready to lay the 
old ''I told you so'' on her when the thing didn't work. Well, 
the laugh was on me! Within 3 weeks she had received 50 
responses. Within the next 45 days she had received total $ 
147,200.00 ........... all cash! I was shocked. I have joined 
Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois 
====================================================== 
''Not being the gambling type, it took me several weeks to make 
up my mind to participate in this plan. But conservative that I 
am, I decided that the initial investment was so little that 
there was just no way that I wouldn't get enough orders to at 
least get my money back''. '' I was surprised when I found my 
medium size post office box crammed with orders. I made 
$319,210.00in the first 12 weeks. The nice thing about this deal 
is that it does not matter where people live. There simply isn't 
a better investment with a faster return and so big." 
Dan Sondstrom, Alberta, Canada 
======================================================= 
''I had received this program before. I deleted it, but later I 
wondered if I should have given it a try. Of course, I had no 
idea who to contact to get another copy, so I had to wait until I 
was e-mailed again by someone else.........11 months passed then 
it luckily came again...... I did not delete this one! I made 
more than $490,000 on my first try and all the money came within 
22 weeks." Susan De Suza, New York, N.Y. 
======================================================= 
''It really is a great opportunity to make relatively easy money 
with little cost to you. I followed the simple instructions 
carefully and within 10 days the money started to come in. My 
first month I made $20,560.00 and by the end of third month my 
total cash count was $362,840.00. Life is beautiful, Thanx to 
internet.". Fred Dellaca, Westport, New Zealand 
======================================================= 
ORDER YOUR REPORTS TODAY AND GET STARTED ON 
'YOUR' ROAD TO FINANCIAL FREEDOM ! 
======================================================= 
If you have any questions of the legality of this program, 
contact the Office of Associate Director for Marketing Practices, 
Federal Trade Commission, Bureau of Consumer Protection, 
Washington, D.C. 
 
 
 
 
 
 
 
 
 
 



From rem-conf Sun Mar 18 12:00:04 2001 
From rem-conf-request@es.net Sun Mar 18 12:00:03 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ejDy-0006Rl-00; Sun, 18 Mar 2001 11:52:22 -0800
Received: from netsys.kaist.ac.kr [143.248.148.90] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ejDw-0006Rb-00; Sun, 18 Mar 2001 11:52:20 -0800
Received: from by.genie.uottawa.ca (by.genie.uottawa.ca [137.122.20.226])
	by netsys.kaist.ac.kr (8.11.0/8.11.0) with ESMTP id f2J8lTh21015;
	Sun, 18 Mar 2001 23:47:29 -0900
Received: from mobstar ([137.122.107.157])
	by by.genie.uottawa.ca (8.9.1/8.9.1) with SMTP id JAA18617;
	Sun, 18 Mar 2001 09:28:09 -0500 (EST)
Reply-To: 
From: "Ahmed Karmouch" 
To: "karmouch" 
Subject: IEEE/ACM Workshop on Mobile Software Agents-  MATA 2001- Deadline-April 1.
Date: Sun, 18 Mar 2001 00:21:11 -0500
Message-ID: <001f01c0ad2a$7563cb80$9d6b7a89@uottawa.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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 V5.00.2919.6600
X-UIDL: ae345eaa9c07da9d4d3b9ea7fdaf9c90
Importance: Normal
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by netsys.kaist.ac.kr id f2J8lTh21015
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


[My apologies if you receive this more than once]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
			MATA'2001

  Third International Workshop on Mobile Agents for
	Telecommunication Applications
	August 14-16, 2001, Montr=E9al, CANADA
	  Co-sponsored by IEEE and ACM
	http://www.congresbcu.com/mata01/


CALL FOR PAPERS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Technical papers (4500 words maximum) describing previously unpublished,
completed research or work in progress, not currently under review by
another journal or conference, are solicited on the following topics:
Mobile Agent Architecture and Models
Agent Identification, Tracking and Persistence
Agent-based Mobility Management in Mobile Networks
Web Agent Systems
Agent Integration with CORBA and TINA
Active Networks and Mobile Agents
Feature Interaction and Agents
Mobile Agents Communication Language
Security in Mobile Agent Systems
Interactive Multimedia Presentation Agents
Agent-based Electronic Commerce
Agent-based Access to Legacy Services
Managing QoS with agents
Information Discovery and Gathering using agents
Data Mining Agents
Network Management Agents
Policy-based Management using Mobile Agents
Education and Applications of Mobile Agents
Prototypes and Experience with Mobile Agents
Seamless Messaging and Mobile Agents

Accepted papers will be published in the conference proceedings. Papers o=
f
particular merit will be proposed for publication in IEEE Network  Magazi=
ne.
All paper submissions should have a cover page containing the title, name=
s,
email address and complete postal addresses (including telephone and fax
numbers) for all authors. Please indicate the main author for the purpose=
 of
correspondence. The cover page should also provide an abstract (150 words
maximum), and a list of keywords. Please include a statement stating that
"when accepted, one of the authors will attend the Workshop to present th=
e
paper".
Submissions should be sent by email to the program chair:

Roch Glitho
Ericcson Research Canada
8400, boul. D=E9carie
Ville Mont-Royal, Qu=E9bec, Canada, H4P 2N2
email: roch.glitho@lmc.ericsson.se
Tel.: (514) 345-7000 ext. 2266

IMPORTANT DATES FOR PAPER SUBMISSION
Full paper submission due	April 1, 2001
Notification of acceptance	May 15, 2001
Final paper due	June 15, 2001
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D








From rem-conf Sun Mar 18 20:32:43 2001 
From rem-conf-request@es.net Sun Mar 18 20:32:42 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14erAd-0004OQ-00; Sun, 18 Mar 2001 20:21:27 -0800
Received: from saturn5.acs.oakland.edu [141.210.6.22] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14erAY-0004Nm-00; Sun, 18 Mar 2001 20:21:22 -0800
Received: (from srodawa@localhost)
	by saturn5.acs.oakland.edu (8.8.8/8.8.8) id XAA26881;
	Sun, 18 Mar 2001 23:21:19 -0500 (EST)
From: Ron Srodawa 
Message-Id: <200103190421.XAA26881@saturn5.acs.oakland.edu>
Subject: Call for Papers IEEE Electro/Information Technology Conf.
To: IETF-Announce@ietf.org, ietf@ietf.org, rem-conf-request@es.net,
        rem-conf@es.net
Date: Sun, 18 Mar 2001 23:21:19 -0500 (EST)
Cc: srodawa@saturn5.acs.oakland.edu (Ron Srodawa)
X-Mailer: ELM [version 2.5 PL2]
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

CFP Second IEEE Electro/Information Technology Conference

The second IEEE Electro/Information Technology conference will be held
at Oakland University, Rochester, MI 48309, USA on June 7-9, 2001. We
are organizing a session on High Speed (gigabit) Network Technology.
Both hardware and software oriented papers will be considered.

The schedule is:

Submit full paper or extended abstract of 2 pages by April 10, 2001
Both hard copies and electronic form (MS Word or PDF attachment) via email.

Notification of acceptance will be given by April 20, 2001.

Full paper in Camera-Ready format (submitted as MS Word or PDF attachment)
is due by May 1, 2001.

Address correspondence and submissions for this session to:

Prof. Ronald Srodawa
Department of Computer Science and Engineering
Oakland University
Rochester, MI 48309, USA

Phone: (248) 370 2247  Fax: (248) 370 4625

Email: srodawa@oakland.edu

The conference web site is: http://www.ewh.ieee.org/reg/4/eit2001.htm






From rem-conf Mon Mar 19 05:41:37 2001 
From rem-conf-request@es.net Mon Mar 19 05:41:36 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ezpQ-0004hK-00; Mon, 19 Mar 2001 05:36:08 -0800
Received: from mgw-x3.nokia.com [131.228.20.26] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ezpL-0004hA-00; Mon, 19 Mar 2001 05:36:06 -0800
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2JDa7H16061
	for ; Mon, 19 Mar 2001 15:36:07 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Mon, 19 Mar 2001 15:36:00 +0200
Received: from loki.research.nokia.com (mgw.research.nokia.com [172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
	id GS5KQL62; Mon, 19 Mar 2001 15:36:00 +0200
Received: from agni.research.nokia.com (IDENT:root@nokesa19341.europe.nokia.com [172.21.193.41])
	by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA10744;
	Mon, 19 Mar 2001 15:35:56 +0200 (EET)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.0/8.11.0) id f2IKgE603451;
	Sun, 18 Mar 2001 22:42:14 +0200
X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f
Sender: pekka.pessi@nokia.com
To: "Colin Perkins" 
Cc: rem-conf@es.net, casner@acm.org
Subject: GSM-HR/GSM-FR [Was Re: G.723 implementations]
References: <200103162000.f2GK0lG07692@chiron.east.isi.edu>
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi 
In-Reply-To: "Colin Perkins"'s message of "Fri, 16 Mar 2001 15:00:47 -0500"
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)
Date: 18 Mar 2001 22:42:14 +0200
Message-ID: 
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

In message <200103162000.f2GK0lG07692@chiron.east.isi.edu> "Colin Perkins"  writes:
>We are still missing implementations of the RTP payload formats
>for GSM-HR, GSM-EFR, MP2T, MP1S, MP2P, BMPEG and BT656.

        I'm author of the GSM-HR and GSM-EFR payload formats.  Nokia ended
        in using the AMR payload for these codecs, so GSM-HR and GSM-EFR are
        propably not implemented anywhere.

        Best regards,
                                        Pekka Pessi





From rem-conf Mon Mar 19 07:24:55 2001 
From rem-conf-request@es.net Mon Mar 19 07:24:54 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14f1T2-0006UX-00; Mon, 19 Mar 2001 07:21:08 -0800
Received: from as24-s16-199-145-142.cw-visp.com (production) [195.44.145.142] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14f1Sy-0006UL-00; Mon, 19 Mar 2001 07:21:07 -0800
From:     BlueFive 
To:        
Message-Id: <419.436969.64991852bluefive@ic24.net>
Subject:     Free Money Making Web Sites
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Mar 2001 07:21:07 -0800
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

    Hi there, I hope you take a few moments to read this 
    short letter and you find it of interest. Please email if you
    would  like more information. You could be on the road to 
    that  financial security you have always wanted.
           Thanks for your time
            Peter

             FREE SEX  SITE FRANCHISES
   Get a'XXX' Adult web site from us and we'll make
   sure you make money.  You don't pay for your site
   until YOU start earning over £10,,000 a month from
   it. If you don't we'll give it to you for FREE.

   All our sites are fully featured and contain the
   best legal content available.  None of them charge
   surfers for access but you still get paid major
   commission per visitor.

   For full details e-mail me:
   Bluefive@ic.net

   Limited Offer
   ----------------------------------------------
   For further details reply with 'MORE DETAILS'
   in the subject line.  "If you want to be
   removed from my email database please reply
   with 'REMOVE' in the subject line.
   ----------------------------------------------





From rem-conf Mon Mar 19 11:35:01 2001 
From rem-conf-request@es.net Mon Mar 19 11:35:00 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14f5Lz-0001YI-00; Mon, 19 Mar 2001 11:30:07 -0800
Received: from prognet.com [205.219.198.1] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14f5Lw-0001Y8-00; Mon, 19 Mar 2001 11:30:04 -0800
Received: from jeffa-laptop.real.com (cronkite.prognet.com [208.147.89.1])
	by prognet.com (8.9.2/8.9.0) with ESMTP id LAA03616;
	Mon, 19 Mar 2001 11:29:55 -0800 (PST)
Message-Id: <4.3.2.7.2.20010319112219.02c882c0@localhost>
X-Sender: jeffa@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Mar 2001 11:29:45 -0800
To: , jmyette@mediatrix.com, rem-conf@es.net
From: Jeff Ayars 
Subject: RE: RE: Interoperable implementations of G.723
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Are we talking ADPCM 5, 4, and 2 bits per sample G.723 here or ACELP G.723.1?

JEff

At 02:01 PM 3/16/2001 -0600, Dennis.Montgomery@tellabs.com wrote:
>I'd like to voice my support for this request: we are also implementing
>G.723.
>
>Regards,
>
>Dennis Montgomery
>
>
>-----Original Message-----
>From: jmyette@mediatrix.com [mailto:jmyette@mediatrix.com]
>Sent: Friday, March 16, 2001 2:35 PM
>To: rem-conf@es.net
>Subject: RE: Interoperable implementations of G.723
>
>
>Mediatrix Telecom supports the CommWorks Corporation request to retain
>the
>G.723 payload. Our products are interoperable with Siemens, Microsoft
>NetMeeting and others.
>
>Julien Myette
>Concepteur de logiciel / Software Designer
>
>Mediatrix Telecom, Inc.   Tel.: (819) 829-8749 poste 362
>4229 Garlock Street       Fax.: (819) 829-5100
>Sherbrooke, Quebec        E-mail: mailto:jmyette@mediatrix.com
>Canada J1L 2C8            Web: www.mediatrix.com
>
>
>-----Original Message-----
>From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
>Sent: Friday, March 16, 2001 10:28
>To: casner@acm.org; rem-conf@es.net
>Cc: Simao Campos-Neto
>Subject: Interoperable implementations of G.723
>
>
>
>
>To whom it may concern:
>
>Please be advised that the CommWorks Corporation (formerly the 3Com
>Carrier
>Networks Business, now a 3Com company) has implemented the ITU-T G.723
>CODEC
>in
>several products. One product (TCS VoIP release 2.3) is released to the
>field
>and installed in a number of customer networks. Other near-term future
>products,
>now in development and test, will also include this capability.
>
>We have tested and continue to test these products and this specific
>capability
>against products from a number of other vendors. I am not sure of the
>appropriateness of identifying those vendors and products here, but may
>be
>able
>to do so if necessary.
>
>Based on the above, the CommWorks Corporation requests that the G.723
>audio
>payload format be retained in the IETF A/V Profile RFC, contrary to
>current
>plans to delete it.
>
>I will be in Minneapolis for IETF 50 next week and plan to attend the
>Audio/Video Transport Working Group meetings. I would be most happy to
>discuss
>this issue with anyone at that time, or by e-mail in advance.
>
>Jim Renkel (e-mail: James_Renkel@3Com.com)
>Director, Advanced Technology & System Engineering
>The CommWorks Corporation, a 3Com company
>formerly the 3Com Carrier Networks Business
>
>
>
>





From rem-conf Mon Mar 19 12:02:17 2001 
From rem-conf-request@es.net Mon Mar 19 12:02:16 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14f5m4-0002Qc-00; Mon, 19 Mar 2001 11:57:04 -0800
Received: from igate.nuera.com (exchange1.nuera.com) [204.216.240.98] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14f5m3-0002Q2-00; Mon, 19 Mar 2001 11:57:03 -0800
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 19 Mar 2001 11:55:45 -0800
Message-ID: 
From: "Fox, Mike" 
To: "David R. Oran" , coldrenr@agcs.com, rem-conf@es.net
Subject: RE: RFC 2833 Duration Field
Date: Mon, 19 Mar 2001 11:55:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0B0AE.95AC29A0"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B0AE.95AC29A0
Content-Type: text/plain;
	charset="iso-8859-1"

Another consideration is to signal the transition event, rather than the
steady state condition.

Best regards,
Mike

------_=_NextPart_001_01C0B0AE.95AC29A0
Content-Type: text/html;
	charset="iso-8859-1"






RE: RFC 2833 Duration Field




Another consideration is to signal the transition event, rather than the steady state condition.




Best regards,

Mike





------_=_NextPart_001_01C0B0AE.95AC29A0--



From rem-conf Mon Mar 19 12:26:08 2001 
From rem-conf-request@es.net Mon Mar 19 12:26:07 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14f6Ar-0003HJ-00; Mon, 19 Mar 2001 12:22:41 -0800
Received: from (mailman.packetdesign.com) [65.192.41.10] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14f6Ap-0003FD-00; Mon, 19 Mar 2001 12:22:39 -0800
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2JKJwe18602;
	Mon, 19 Mar 2001 12:19:58 -0800 (PST)
	(envelope-from casner@acm.org)
Date: Mon, 19 Mar 2001 12:23:02 -0800 (PST)
From: Stephen Casner 
Sender: 
To: Jeff Ayars 
cc: 
Subject: RE: RE: Interoperable implementations of G.723
In-Reply-To: <4.3.2.7.2.20010319112219.02c882c0@localhost>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

These messages are about the payload format ACELP G.723.1, denoted
"G723" in the RTP profile and MIME subtype definition.  The profile
also contains payload format "G726" for G.726 (nee G.723) ADPCM at 5,
4, 3, and 2 bits per sample.

As some earlier messages have confirmed, the G.723.1 payload format
will be restored in the profile now that we have received the
necessary responses that we were seeking.
							-- Steve

On Mon, 19 Mar 2001, Jeff Ayars wrote:

> Are we talking ADPCM 5, 4, and 2 bits per sample G.723 here or ACELP G.723.1?
>
> JEff
>
> At 02:01 PM 3/16/2001 -0600, Dennis.Montgomery@tellabs.com wrote:
> >I'd like to voice my support for this request: we are also implementing
> >G.723.
> >
> >Regards,
> >
> >Dennis Montgomery
> >
> >
> >-----Original Message-----
> >From: jmyette@mediatrix.com [mailto:jmyette@mediatrix.com]
> >Sent: Friday, March 16, 2001 2:35 PM
> >To: rem-conf@es.net
> >Subject: RE: Interoperable implementations of G.723
> >
> >
> >Mediatrix Telecom supports the CommWorks Corporation request to retain
> >the
> >G.723 payload. Our products are interoperable with Siemens, Microsoft
> >NetMeeting and others.
> >
> >Julien Myette
> >Concepteur de logiciel / Software Designer
> >
> >Mediatrix Telecom, Inc.   Tel.: (819) 829-8749 poste 362
> >4229 Garlock Street       Fax.: (819) 829-5100
> >Sherbrooke, Quebec        E-mail: mailto:jmyette@mediatrix.com
> >Canada J1L 2C8            Web: www.mediatrix.com
> >
> >
> >-----Original Message-----
> >From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
> >Sent: Friday, March 16, 2001 10:28
> >To: casner@acm.org; rem-conf@es.net
> >Cc: Simao Campos-Neto
> >Subject: Interoperable implementations of G.723
> >
> >
> >
> >
> >To whom it may concern:
> >
> >Please be advised that the CommWorks Corporation (formerly the 3Com
> >Carrier
> >Networks Business, now a 3Com company) has implemented the ITU-T G.723
> >CODEC
> >in
> >several products. One product (TCS VoIP release 2.3) is released to the
> >field
> >and installed in a number of customer networks. Other near-term future
> >products,
> >now in development and test, will also include this capability.
> >
> >We have tested and continue to test these products and this specific
> >capability
> >against products from a number of other vendors. I am not sure of the
> >appropriateness of identifying those vendors and products here, but may
> >be
> >able
> >to do so if necessary.
> >
> >Based on the above, the CommWorks Corporation requests that the G.723
> >audio
> >payload format be retained in the IETF A/V Profile RFC, contrary to
> >current
> >plans to delete it.
> >
> >I will be in Minneapolis for IETF 50 next week and plan to attend the
> >Audio/Video Transport Working Group meetings. I would be most happy to
> >discuss
> >this issue with anyone at that time, or by e-mail in advance.
> >
> >Jim Renkel (e-mail: James_Renkel@3Com.com)
> >Director, Advanced Technology & System Engineering
> >The CommWorks Corporation, a 3Com company
> >formerly the 3Com Carrier Networks Business
> >
> >
> >
> >
>
>
>

							-- Steve




From rem-conf Tue Mar 20 00:05:59 2001 
From rem-conf-request@es.net Tue Mar 20 00:05:59 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fGwB-0002C2-00; Mon, 19 Mar 2001 23:52:15 -0800
Received: from ns.kyoshin-print.co.jp [210.226.85.210] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fGw4-00029t-00; Mon, 19 Mar 2001 23:52:08 -0800
Received: from usa.net (slip-32-102-226-154.fl.us.prserv.net [32.102.226.154]) by ns.kyoshin-print.co.jp (8.9.1/3.5Wbeta) with SMTP id QAA20251; Tue, 20 Mar 2001 16:54:49 +0900 (JST)
From: wei.li@usa.net
Message-ID: <000028223eb3$0000766b$00000eb0@usa.net>
To: 
Subject: Rated Strong Buy.                         3760
Date: Tue, 20 Mar 2001 02:45:44 -1700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

 For The Serious Investor 


News Flash: Important Press Release 


THIS IS A STOCK TO PURCHASE! 


 


March 20, 2001  


Symbol LIQD (OTCBB) 


Shares Outstanding 9,000,000 


Float 2,100,000 


Recent Price $0.32 


52 Week High $2.50 


The Market:We belive that the nasdaq has done a full turn since dec 1998 h=
as totally bottomed and ready to catapualtand . Historically speaking the =
small-cap stocks have made a faster and quicker recovery and we belive we =
have a great opportunity at hand right now.





THE OPPORTUNITY:The stock that we are currently recommending is (OTCBB: LI=
QD) Liquidics, Inc. With two divisions creating products in the high-growt=
h semiconductor market, Liquidics, Inc. is on the verge of becoming a fron=
t-runner in microchip design and manufacturing.





Liquidics, Inc.industrial divisions is currently marketing magnetic fluids=
, created in the sixties under the sponsorship of NASA, to semiconductor m=
anufacturing industry.





Their consumer product division is producing a new generation of improved =
performance shock absorbers for offroad vehicles using techology developed=
 by the company's R&D team. 








FOR MORE INFORMATION 


CLICK HERE http://seasease=
a.51.net/investments





 


 





To be removed CLICK HERE mailto:clee=
24@disinfo.net












From rem-conf Tue Mar 20 07:37:07 2001 
From rem-conf-request@es.net Tue Mar 20 07:37:07 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fO7c-0007FP-00; Tue, 20 Mar 2001 07:32:32 -0800
Received: from beamer.mchh.siemens.de [194.138.158.163] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fO7a-0007FF-00; Tue, 20 Mar 2001 07:32:30 -0800
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA12742;
	Tue, 20 Mar 2001 16:32:21 +0100 (MET)
From: Tobias.Faerber@mch.siemens.de
Received: from mchh9eea.mchh.siemens.de (mchh9eea.mchh.siemens.de [139.21.204.218])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with SMTP id QAA11863;
	Tue, 20 Mar 2001 16:32:21 +0100 (MET)
Received: by mchh9eea.mchh.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Tue, 20 Mar 2001 16:31:18 +0100
Message-ID: <07B0CDE3B76AD31190F700508B5D5D1D68A816@mchg9eba.mchh.siemens.de>
To: schirlin@us.ibm.com, hari@FLAVORSOFTWARE.com, rem-conf@es.net
Subject: AW: File formats (RE: MP4 Player Available for Download)
Date: Tue, 20 Mar 2001 16:32:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

I absolutely agree. This player maybe only supports mp4 file format !. Our
files don't work with it (flavoursoft) either, but MPEG leaves open whitch
file format to use or even defining one dedicated file format like it was
with mp3. maybe this player doesn't work with LATM, ADTS,ADIF based mp4
streams, the producer of "flavour" should give a statement about that !!!

regards,
Tobias 


> Rob,
> 
> The file format itself carries no IP ... it is simply a bytewise layout.
> The content or rather the players and encoders for consumption and
> generation of content is a different story...
> 
> There is absolutely no reason why the file exchange specified by WG 11
> cannot be universally used. The reason the content does not play is that
> it
> (the content portion of the file) uses some but not all the proper system
> level and identification streams called out in the MPEG-4 specification...
> 
> Pete Schirling
> 
> Digital Media Standards and Commercialisation
> IBM Research Division
> Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
> Mobile text messaging 8022382036@msg.myvzw.com
> Internet e-mail: schirlin@us.ibm.com
> 
> 
> Rob Lanphier  on 03/15/2001 02:35:09 AM
> 
> To:   Bill Nowicki , "'Hari Kalva'"
>       
> cc:   "'rem-conf@es.net'" 
> Subject:  File formats (RE: MP4 Player Available for Download)
> 
> 
> 
> At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
> >We just tried the obvious experiment.
> >
> >The ".mp4" files on the "Flavor" site do not play with the
> >Philips player, and the Philips ".mp4" files do not play with
> >the Flavor player. Sounds like a litle inter-operability
> >testing might have been in order before calling them the same
> >name!
> >
> >(and of course file format standards are outside the charter
> >of IETF, but are still useful)
> 
> Not that I'm disagreeing with you here, but an honest question for
> you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG
> have taken it on, but they've also created a situation where I think
> genuine interoperability is out of the question for anyone who either
> doesn't have a patent licensing agreement from 30 different companies, or
> who chooses to ignore the issue.
> 
> Is there a standards group out there who does file formats who would
> actually work toward an unencumbered format?
> 
> Rob
> 
> 
> 
> 
> 



From rem-conf Tue Mar 20 13:13:55 2001 
From rem-conf-request@es.net Tue Mar 20 13:13:54 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fTL2-0003T9-00; Tue, 20 Mar 2001 13:06:44 -0800
Received: from gumby.cs.berkeley.edu [128.32.32.38] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fTL1-0003Sz-00; Tue, 20 Mar 2001 13:06:43 -0800
Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74])
	by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA28250;
	Tue, 20 Mar 2001 12:31:02 -0800
Message-ID: <3AB7BF16.E0DCD44F@bmrc.berkeley.edu>
Date: Tue, 20 Mar 2001 12:35:35 -0800
From: katherine reyes 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: 3/21 Berkeley Multimedia, Interfaces and Graphics Seminar
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Berkeley Multimedia, Graphics and Interfaces Seminar

QoS Enabled Audio Teleportation

March 21, 2001,
1:10-2:30 p.m. PDT
Fujitsu Seminar Room (405 Soda Hall)

Chris Chafe
Center for Computer Research in Music and Acoustics
Stanford University

Our group working in cooperation with Internet2 demonstrated how the
benefits the quality of service (QoS) could be applied to the real-time
transmission of interactive CD-quality audio across the high-performance

network path between Stanford University and the SC2000 show floor in
Dallas last November. New, no compromise, audio applications were
developed using a simplified approach for high quality music and sound
streaming over IP networks.

Previously existing systems for streaming digital audio have involved a
number of trade-offs. Because of transmission bandwidth limitations and
best effort delivery, audio signal compression of one form or another is

typical. Buffering of data, which often delays a signal by seconds,
safeguards against delivery uncertainties.

The uncompressed live audio streams required for this demo were made
possible by employing network enhancements that support minimal delay
and low-jitter packet delivery over WAN. Applications include two-way
communication (full-bandwidth voice and music) and "surround sound"
multi-channel eavesdropping on Stanford spaces.

Along with our new professional audio applications we have developed
SoundWIRE, a utility which affords an intuitive way of evaluating
transaction delay and delay constancy. Its final form is an enhanced
"ping" that uses actual sound reflection. A musical tone, such as a
guitar pluck, can be created by repeatedly reflecting a digital acoustic

signal between two hosts. Using the network delay between these
reflections to substitute for a guitar string creates a tone whose
stability represents perfectly regular service and whose pitch
represents transmission latency. The ear's ability to discern minute
differences makes this an unforgiving test of network reliability. And
the Internet itself can be listened to as a vibrating acoustic medium,
as if it were a guitar string, with a new technique for generating sound

waves on the Internet from real-time echoes (SoundWIRE). This auditory
"ping" is used as a tool for evaluation of network constancy.

Network quality of service (QoS) for this demonstration consisted of
marking application traffic for Expedited Forwarding (EF), shaping and
policing it at the network edge, and sending it over the Stanford
University, CalREN2, and Abilene backbone network, where EF-marked
traffic is preferentially serviced. The QoS network design in this demo
reflects the architecture of the Internet2 QBone Premium Service. Heavy
congestion was created at one or more points near the edge and effective

protection of application traffic was demonstrated.

---------------

The seminar is broadcast live on the Internet Mbone and as a Real
Networks G2 broadcast.

You can connect to the live RealNetworks broadcast at:
http://bmrc.berkeley.edu/bibs/cs298-5

You can also directly put in this url into the Real Player:
rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm

To do so you will need to have the "Real Player G2" installed, which is
available
from:http://www.real.com/products/player/downloadrealplayer.html

To tune into the Internet MBone broadcast, look for the announcement in
your MBone session directory program ('sdr'), or you can visit:
http://imj.ucsb.edu/sdr-monitor/

You can get further information about this seminar, and access to
replays of previous seminars at
the MIG Seminar web page:

http://media2.bmrc.berkeley.edu/bibs/archive.cfm

Sponsored by the Berkeley Multimedia Research Center




From rem-conf Tue Mar 20 16:58:39 2001 
From rem-conf-request@es.net Tue Mar 20 16:58:38 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fWso-0006XI-00; Tue, 20 Mar 2001 16:53:50 -0800
Received: from host62-7-98-137.btinternet.com (mail.btinternet.com) [62.7.98.137] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14fWsi-0006WD-00; Tue, 20 Mar 2001 16:53:45 -0800
From: tony@aknap.fsnet.co.uk
Reply-To: tony@knap.fsnet.co.uk
Message-Id: <8gqj4t5b6o7hk5.4jch0r2p8v7fekq@mail.btinternet.com>
Date: Wed, 21 Mar 2001 00:47:43 +0000
Subject: Pentium 200 with  20 Gb  Hard Drive,   only  £495
Content-Type: text/plain;
	 charset=us-ascii
Content-Transfer-Encoding: 8BIT
To: $user@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Pentium 200 with  20 Gb  Hard Drive,   only  £495

											
Hi

Now, for only £495 you can have the COMPUTING POWER required for some great games, the latest Scanners, CD Writers and still run a business, type letters,  enjoy the Internet, Improve your Network,  keep a database or familiarise the family with computers.......

We are disposing of  'end of lease' Branded computers (with MASSIVE  20 Gb Hard Drive) at unbelievable prices. One can be yours for only £495 complete with Monitor, Keyboard, Mouse, Windows 95, Word Processing, Database, and Spreadsheet. For a small extra you can 'Surf' the Internet or send E-mails at a blazing 56K. There is no VAT to be added.


I trust the following will answer your questions in time for you to quickly reserve a 'end of lease' Dell computer whilst we still have some left.....

* Branded  Pentium 200 Computer (massive 20 Gb Hard Drive, 32 RAM, Min)
* Colour Monitor (14" Super VGA)
* Keyboard and Mouse (new)
* Windows 95 (loaded and running with online instructions and help)
* Microsoft Works (Word Processor, Spreadsheet, Database all loaded and Running)

 									       Only 495 Pounds


You can choose any of these optional extras......

* Freeserve  Internet Software and new super fast 56K 
modem installed and ready to send e-mails and surf the Internet		Add  £68.00
* CD ROM								Add  £58.00
* Colour Printer (new, including cartridge and cables)			Add  £79.00
* Door to door delivery (FREE if you fax your order and pay by cheque)	Add  £27.50

Your computer will arrive in just 14 to 21 days and will include all cables, guidance notes and a 30 day return to base guarantee which ensures the above capability. You will also receive two independent help lines. You can simply plug in your computer and start using it. 

To reserve your own Computer you MUST act quickly and call us now on 0207 644 3404 to reserve one. If you FAX  your reservation and pay by cheque (payable to ViSa) you will qualify for FREE delivery normally £27.50. Alternatively, we accept most major credit cards, and if you choose, we won't debit your card until after your computer arrives. Please FAX your order/reservation now to 01737  823726 or  01293 619035.

Regards

Tony           
Liquidated Computers


P.S.   	Remember, fax your order/reservation and receive FREE door to door delivery worth £27.50
	Fax   (01737)  823726  or  (01293) 619035




E.mail SAVES TREES ! Unit 4, 140 Station Rd, Redhill, Surrey. RH1 1ET
We don't sell Laptop Computers .Terms and Conditions apply.Your e.mail can be supressed with REMOVE in the subject line.  





From rem-conf Tue Mar 20 22:42:36 2001 
From rem-conf-request@es.net Tue Mar 20 22:42:35 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fcFp-0002l1-00; Tue, 20 Mar 2001 22:37:57 -0800
Received: from e1.ny.us.ibm.com [32.97.182.101] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fcFn-0002kr-00; Tue, 20 Mar 2001 22:37:55 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA106116;
	Wed, 21 Mar 2001 01:36:34 -0500
Received: from d02ml251.somers.hqregion.ibm.com (d02ml251.sby.ibm.com [9.45.4.178])
	by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id BAA30030;
	Wed, 21 Mar 2001 01:33:32 -0500
Importance: Normal
Subject: Re: AW: File formats (RE: MP4 Player Available for Download)
To: Tobias.Faerber@mch.siemens.de
Cc: hari@FLAVORSOFTWARE.com, rem-conf@es.net
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: 
From: "Peter Schirling" 
Date: Tue, 20 Mar 2001 22:30:21 -0800
X-MIMETrack: Serialize by Router on D02ML251/02/M/IBM(Release 5.0.6a |January 17, 2001) at
 03/21/2001 01:37:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Tobias,

Let me clarify something....

The .mp3 collection of bytes is merely an elementary stream with its
headers packaged in IP datagrams. MPEG did not specify anything beyond the
elementary stream headers at the time of MPEG-1 Layer III audio
standardization for the carriage of audio alone. We did create Systems
Multiplex (Program Stream in MPEG-2) for the carriage of video and audio.

In the case of MP4 the committee explicity developed a file format intended
for the exchange of MPEG-4  content. The reason we created a  file exchange
format rather than yet another Program Stream or Transport Stream as we did
in MPEG-2 was because we already had a multiplex for the carriage of
streams in MPEG-2 and in the case of the the carriage of streams over IP
based networks it is not in MPEG scope of work to do that. ISMA and IETF
have taken on the task of defining a multplexing standard for the carriage
of MPEG-2 over IP based networks... MP4 is not a multiplex specification.

I agree that anyone who creates an MPEG-4 multiplex should clearly state
its relationship, if any, to existing specifications.

Pete Schirling

Digital Media Standards and Commercialisation
IBM Research Division
Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
Mobile text messaging 8022382036@msg.myvzw.com
Internet e-mail: schirlin@us.ibm.com


Tobias.Faerber@mch.siemens.de on 03/20/2001 07:32:18 AM

To:   Peter Schirling/Burlington/IBM@IBMUS, hari@FLAVORSOFTWARE.com,
      rem-conf@es.net
cc:
Subject:  AW: File formats (RE: MP4 Player Available for Download)



I absolutely agree. This player maybe only supports mp4 file format !. Our
files don't work with it (flavoursoft) either, but MPEG leaves open whitch
file format to use or even defining one dedicated file format like it was
with mp3. maybe this player doesn't work with LATM, ADTS,ADIF based mp4
streams, the producer of "flavour" should give a statement about that !!!

regards,
Tobias


> Rob,
>
> The file format itself carries no IP ... it is simply a bytewise layout.
> The content or rather the players and encoders for consumption and
> generation of content is a different story...
>
> There is absolutely no reason why the file exchange specified by WG 11
> cannot be universally used. The reason the content does not play is that
> it
> (the content portion of the file) uses some but not all the proper system
> level and identification streams called out in the MPEG-4
specification...
>
> Pete Schirling
>
> Digital Media Standards and Commercialisation
> IBM Research Division
> Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
> Mobile text messaging 8022382036@msg.myvzw.com
> Internet e-mail: schirlin@us.ibm.com
>
>
> Rob Lanphier  on 03/15/2001 02:35:09 AM
>
> To:   Bill Nowicki , "'Hari Kalva'"
>       
> cc:   "'rem-conf@es.net'" 
> Subject:  File formats (RE: MP4 Player Available for Download)
>
>
>
> At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
> >We just tried the obvious experiment.
> >
> >The ".mp4" files on the "Flavor" site do not play with the
> >Philips player, and the Philips ".mp4" files do not play with
> >the Flavor player. Sounds like a litle inter-operability
> >testing might have been in order before calling them the same
> >name!
> >
> >(and of course file format standards are outside the charter
> >of IETF, but are still useful)
>
> Not that I'm disagreeing with you here, but an honest question for
> you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG
> have taken it on, but they've also created a situation where I think
> genuine interoperability is out of the question for anyone who either
> doesn't have a patent licensing agreement from 30 different companies, or
> who chooses to ignore the issue.
>
> Is there a standards group out there who does file formats who would
> actually work toward an unencumbered format?
>
> Rob
>
>
>
>
>






From rem-conf Wed Mar 21 00:09:59 2001 
From rem-conf-request@es.net Wed Mar 21 00:09:57 2001
Received: from list by mail2.es.net with local (Exim 1.92 #1)
	for rem-conf-dist@es.net
	id 14fdZ2-0007E7-00; Wed, 21 Mar 2001 00:01:52 -0800
Received: from nwd2gtw1.analog.com ([137.71.23.34] helo=nwd2mime2.analog.com)
	by mail2.es.net with esmtp (Exim 1.92 #1)
	for rem-conf@es.net
	id 14fdZ0-0007Dr-00; Wed, 21 Mar 2001 00:01:50 -0800
Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com
 (Content Technologies SMTPRS 4.1.5) with SMTP id  for ;
 Wed, 21 Mar 2001 02:56:53 -0500
Received: from IPDC_TEST7 ([137.71.79.115] (may be forged))
	by delhi.spd.analog.com (8.8.6/8.8.6) with SMTP id NAA14165
	for ; Wed, 21 Mar 2001 13:26:07 +0530 (IST)
Received: by IPDC_TEST7 with Microsoft Mail
	id <01C0B20C.03481060@IPDC_TEST7>; Wed, 21 Mar 2001 13:37:03 -0800
Message-ID: <01C0B20C.03481060@IPDC_TEST7>
From: K Roopa 
To: "'rem-conf@es.net'" 
Subject: Doubts on ABCD bits (with reference to RFC 2833)
Date: Wed, 21 Mar 2001 13:37:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi,


  I had some doubts regarding the ABCD signaling bits.
           1.   Is the mapping of  ABCD bits done as below:

                           A B C  D                       encoded decimal
                           0  0  0  0                           144
                           0  0  0  1                           145
                           .
                           .
                           1  1  1  1                           159
 Is  the A  bit considered as the MS Bit ?

      2. Does ABCD bit state change can occur simultaneously alond with DTMF events. If yes
           Can we send DTMF event and ABCD event at the same instant?

     



From rem-conf Wed Mar 21 00:09:59 2001 
From rem-conf-request@es.net Wed Mar 21 00:09:57 2001
Received: from list by mail2.es.net with local (Exim 1.92 #1)
	for rem-conf-dist@es.net
	id 14fdZA-0007EC-00; Wed, 21 Mar 2001 00:02:00 -0800
Received: from nwd2gtw1.analog.com ([137.71.23.34] helo=nwd2mime2.analog.com)
	by mail2.es.net with esmtp (Exim 1.92 #1)
	for rem-conf@es.net
	id 14fdZ0-0007Dr-01; Wed, 21 Mar 2001 00:01:51 -0800
Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com
 (Content Technologies SMTPRS 4.1.5) with SMTP id  for ;
 Wed, 21 Mar 2001 03:00:34 -0500
Received: from IPDC_TEST7 ([137.71.79.115] (may be forged))
	by delhi.spd.analog.com (8.8.6/8.8.6) with SMTP id NAA14201
	for ; Wed, 21 Mar 2001 13:29:51 +0530 (IST)
Received: by IPDC_TEST7 with Microsoft Mail
	id <01C0B20C.8944E800@IPDC_TEST7>; Wed, 21 Mar 2001 13:40:47 -0800
Message-ID: <01C0B20C.8944E800@IPDC_TEST7>
From: K Roopa 
To: "'rem-conf@es.net'" 
Subject: Doubts on ABCD bits (with reference to RFC 2833)
Date: Wed, 21 Mar 2001 13:40:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi,


  I had some doubts regarding the ABCD signaling bits.
           1.   Is the mapping of  ABCD bits done as below:

                           A B C  D                       encoded decimal
                           0  0  0  0                           144
                           0  0  0  1                           145
                           .
                           .
                           1  1  1  1                           159
 Is  the A  bit considered as the MS Bit ?

      2. Does ABCD bit state change can occur simultaneously alond with DTMF events. If yes
           Can we send DTMF event and ABCD event at the same instant?



regards,
Roopa
Analog Devices Pvt Ltd.  
roopa.k@spd.analog.com
     




From rem-conf Wed Mar 21 01:28:59 2001 
From rem-conf-request@es.net Wed Mar 21 01:28:58 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ferR-00069j-00; Wed, 21 Mar 2001 01:24:57 -0800
Received: from (smail-6.hanmail.net) [211.62.252.66] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ferP-00069Y-00; Wed, 21 Mar 2001 01:24:55 -0800
Received: from www15.hanmail.net ([211.32.117.35])
        by smail-6.hanmail.net (8.10.0/8.9.1) with ESMTP id f2L9KTc09745;
        Wed, 21 Mar 2001 18:20:29 +0900
Received: (from hanadmin@localhost)
        by www15.hanmail.net (8.10.0/8.9.1) id f2L9JOW14930;
        Wed, 21 Mar 2001 18:19:24 +0900 (KST)
X-Originating-IP: [129.254.142.162]
From: "ÀÌÅÂÁø" 
Reply-To: "ÀÌÅÂÁø" 
Organization: 
To: rem-conf@es.net
Subject: About MBZ...
X-Mailer: Daum Web Mailer 1.0
Date: Wed, 21 Mar 2001 18:19:24 KST
Message-Id: <20010321181924.HM.E0000000001MU7V@www15.hanmail.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by smail-6.hanmail.net id f2L9KTc09745
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

SGkNCk1hbnkgUkZDIGhhcyBNQlogZmllbGQgZm9yIGZ1dHVyZSB1c2UuDQpTbywgbm93IEkg
Y2FuJ3QgdXNlIHRoYXQgZmllbGQgZm9yIG15IGFwcGxpY2F0aW9uID8NCkkgd2FudCB1c2Ug
dGhhdCBmaWVsZCBmb3Igc2VuZGluZyBzb21lIGluZm9ybWF0aW9uIHRvIGNsaWVudC4uDQoN
CklmIGFueW9uZSBrbm93IHRoZSBhbnN3ZXIsIHBsZWFzZSB0ZWxsIG1lLg0KDQp0aGFua3Mu
DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
DQq/7LiuIMDOxc2z3SwgRGF1bQ0KxvK7/SC+srTCILmrt+EgRS1tYWlsIMHWvNIgx9G43sDP
s90NCsH2sbjDzCDH0bHbILDLu/a8rbrxvbogRGF1bSBGSVJFQkFMTA0KaHR0cDovL3d3dy5k
YXVtLm5ldA0K



From rem-conf Wed Mar 21 01:43:51 2001 
From rem-conf-request@es.net Wed Mar 21 01:43:48 2001
Received: from list by mail2.es.net with local (Exim 1.92 #1)
	for rem-conf-dist@es.net
	id 14ff62-0000cA-00; Wed, 21 Mar 2001 01:40:02 -0800
Received: from nwd2gtw1.analog.com ([137.71.23.34] helo=nwd2mime2.analog.com)
	by mail2.es.net with esmtp (Exim 1.92 #1)
	for rem-conf@es.net
	id 14ff60-0000by-00; Wed, 21 Mar 2001 01:40:00 -0800
Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com
 (Content Technologies SMTPRS 4.1.5) with SMTP id  for ;
 Wed, 21 Mar 2001 04:35:03 -0500
Received: from IPDC_TEST7 ([137.71.79.115] (may be forged))
	by delhi.spd.analog.com (8.8.6/8.8.6) with SMTP id PAA15892
	for ; Wed, 21 Mar 2001 15:04:17 +0530 (IST)
Received: by IPDC_TEST7 with Microsoft Mail
	id <01C0B219.BA329EA0@IPDC_TEST7>; Wed, 21 Mar 2001 15:15:13 -0800
Message-ID: <01C0B219.BA329EA0@IPDC_TEST7>
From: K Roopa 
To: "'rem-conf@es.net'" 
Subject: Doubts on ABCD bits (with reference to RFC 2833)
Date: Wed, 21 Mar 2001 15:15:12 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

                    
Hi,


  I had some doubts regarding the ABCD signaling bits.
           1.   Is the mapping of  ABCD bits done as below:

                           A B C  D                       encoded decimal
                           0  0  0  0                           144
                           0  0  0  1                           145
                           .
                           .
                           1  1  1  1                           159
 Is  the A  bit considered as the MS Bit ?

      2. Does ABCD bit state change can occur simultaneously alond with DTMF events. If yes
           Can we send DTMF event and ABCD event at the same instant?

       3. ABCD bits carry the information like on hook,off hook detection .RTP session starts after               
          the call establishment , then how do we relay these information before the call establishment
         as we will have no idea of udp port number and IP address.
         Where can we get more information about these ABCD bits ?

Looking forward for  the reply.


regards
Roopa.

(roopa.k@spd.analog.com)
      




regards,
Roopa
Analog Devices Pvt Ltd.  
roopa.k@spd.analog.com
     





From rem-conf Wed Mar 21 04:57:56 2001 
From rem-conf-request@es.net Wed Mar 21 04:57:56 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fi8F-0002Vm-00; Wed, 21 Mar 2001 04:54:31 -0800
Received: from (exchange.Ic4ic.com) [194.90.135.194] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14fi8C-0002Vc-00; Wed, 21 Mar 2001 04:54:29 -0800
content-class: urn:content-classes:message
Subject: cTCRTP
Date: Wed, 21 Mar 2001 14:53:37 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D36E9@exchange.Ic4ic.com>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
X-MS-TNEF-Correlator: 
Thread-Topic: cTCRTP
Thread-Index: AcCyBasd3CEJ6HErQwCt4oetnhIVng==
From: "Daniel Feldman" 
To: 
Cc: "Eyal Gutman" ,
	"Alex Trigub" ,
	"Doron Greenbaum" ,
	"Giora Ariel" ,
	"Dov Alon" 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

	Does anyone know which document describes cTCRTP (supposedly a
more bandwidth efficient way to send TCRTP over a PPP link by
compressing the L2TP IP header with cUDP)?
	Thanks in advance,

~~~~~~~~~~~~~~~~~~~~~~~~
Daniel Feldman
System Engineer, IC4IC ltd.
office: +972-4-9594644 ext. 121
mobile: +972-53-980442
fax: +972-4-9594944
~~~~~~~~~~~~~~~~~~~~~~~~




From rem-conf Wed Mar 21 05:13:24 2001 
From rem-conf-request@es.net Wed Mar 21 05:13:23 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fiP6-0003UL-00; Wed, 21 Mar 2001 05:11:56 -0800
Received: from cml5.csie.ntu.edu.tw [140.112.29.135] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fiP4-0003UB-00; Wed, 21 Mar 2001 05:11:54 -0800
Received: (from ccfang@localhost)
	by cml5.csie.ntu.edu.tw (8.9.3+Sun/8.9.3) id VAA16416
	for rem-conf@es.net; Wed, 21 Mar 2001 21:10:28 +0800 (CST)
From: Fang Jiunn-Joan 
Message-Id: <200103211310.VAA16416@cml5.csie.ntu.edu.tw>
Subject: Is RFC2833 is mandatory for H.323?
To: rem-conf@es.net
Date: Wed, 21 Mar 101 21:10:27 +0800 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi all
	Can anyone tell me wether is RFC 2833 mandatory for H.323?
	H.323 can send DTMF tone out-of-band by H.245 message.
	And the capability exchange has no information about RFC 2833.
	If we implement H.323, do we need to implement RFC2833?

Best Regards
ccfang



From rem-conf Wed Mar 21 07:17:26 2001 
From rem-conf-request@es.net Wed Mar 21 07:17:25 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fkJr-00062g-00; Wed, 21 Mar 2001 07:14:39 -0800
Received: from canospam.agcs.com [130.131.166.29] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fkJp-00062W-00; Wed, 21 Mar 2001 07:14:37 -0800
Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113])
	by canospam.agcs.com (8.9.3/8.9.1) with SMTP id IAA24452
	for ; Wed, 21 Mar 2001 08:14:36 -0700 (MST)
Posted-Date: Wed, 21 Mar 2001 08:14:36 -0700 (MST)
Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Mar 21 08:14:36 2001 -0700
Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5])
	by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id IAA09862
	for ; Wed, 21 Mar 2001 08:14:19 -0700 (MST)
Received: from agcs.com ([130.131.56.195]) by pxmail2.agcs.com
          (Netscape Messaging Server 3.61)  with ESMTP id AAA70DC;
          Wed, 21 Mar 2001 08:14:33 -0700
Message-ID: <3AB8C53D.368A8392@agcs.com>
Date: Wed, 21 Mar 2001 08:14:05 -0700
From: "Rex Coldren" 
Reply-To: coldrenr@agcs.com
Organization: AG Communication Systems
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: K Roopa 
CC: "'rem-conf@es.net'" 
Subject: Re: Doubts on ABCD bits (with reference to RFC 2833)
References: <01C0B219.BA329EA0@IPDC_TEST7>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

K Roopa wrote:

>
> Hi,
>
>   I had some doubts regarding the ABCD signaling bits.
>            1.   Is the mapping of  ABCD bits done as below:
>
>                            A B C  D                       encoded decimal
>                            0  0  0  0                           144
>                            0  0  0  1                           145
>                            .
>                            .
>                            1  1  1  1                           159
>  Is  the A  bit considered as the MS Bit ?

Yes.  The bit pattern's binary represents a number that is normalized into the
range 144-159.  So what you have is correct.

>       2. Does ABCD bit state change can occur simultaneously alond with DTMF events. If yes
>            Can we send DTMF event and ABCD event at the same instant?

ABCD state changes are independent of whether DTMF is being sent so there is no reason
(other than bandwidth limitations) why you cannot send them both at the same time.

>        3. ABCD bits carry the information like on hook,off hook detection .RTP session starts after
>           the call establishment , then how do we relay these information before the call establishment
>          as we will have no idea of udp port number and IP address.
>          Where can we get more information about these ABCD bits ?

This is a good point.  Some call signaling protocol (e.g.-NCS, H.323, etc.) would be required to
establish the IP address and UDP port to use as well as what part of RFC 2833 is to be used.
This same call signaling protocol would be used to determine if a call context is necessary (e.g.-
when a user line goes off-hook to originate).

> Looking forward for  the reply.
>
> regards
> Roopa.
>
> (roopa.k@spd.analog.com)
>
>
> regards,
> Roopa
> Analog Devices Pvt Ltd.
> roopa.k@spd.analog.com
>




From rem-conf Wed Mar 21 09:33:57 2001 
From rem-conf-request@es.net Wed Mar 21 09:33:57 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fmQy-0000fq-00; Wed, 21 Mar 2001 09:30:08 -0800
Received: from (radvpost.us.radvision.com) [38.150.216.6] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fmQx-0000fO-00; Wed, 21 Mar 2001 09:30:07 -0800
Received: by RADVPOST with Internet Mail Service (5.5.2650.21)
	id ; Wed, 21 Mar 2001 12:28:55 -0500
Message-ID: <0D5BBF5D638DD4119E3400508BD9494544247E@RADVPOST>
From: Orit Levin 
To: "SIP reflector (E-mail)" , 
	confctrl@isi.edu, rem-conf@es.net
Subject: FW: I-D ACTION:draft-levin-sip-for-video-00.txt
Date: Wed, 21 Mar 2001 12:28:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hello all!
You can find the attached draft in the IETF Draft directories.
I am looking for the comments from all the interested parties on the
emergency for each one of the listed (and additional) requirements before
preparing proposal(s) for their resolution.

There are some formatting deficiencies in the submitted ASCII version. I
will be happy to send the Word version, for those who are interested.

Best Regards,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, February 27, 2001 6:53 AM
Subject: I-D ACTION:draft-levin-sip-for-video-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: SIP Requirements for support of Multimedia and
Video
	Author(s)	: O. Levin
	Filename	: draft-levin-sip-for-video-00.txt
	Pages		: 14
	Date		: 26-Feb-01
	
This document outlines requirements for a call control
protocol for real-time multimedia support over IP. As a
part of its broader scope, the document examines
important aspects of interactive video communications
that need to be addressed by a call control protocol for
real-time multimedia support and discusses techniques
currently used to deal with them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-sip-for-video-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-levin-sip-for-video-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-levin-sip-for-video-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



From rem-conf Wed Mar 21 10:56:02 2001 
From rem-conf-request@es.net Wed Mar 21 10:56:01 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fnkF-0002fG-00; Wed, 21 Mar 2001 10:54:07 -0800
Received: from (server.commin.co.kr) [211.41.165.225] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fnkD-0002eg-00; Wed, 21 Mar 2001 10:54:05 -0800
Received: from 777.net.cn (ap-baylan-164.pworld.net.ph [202.93.70.164]) by server.commin.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id GQ6DK02X; Thu, 22 Mar 2001 03:50:51 +0900
Message-ID: <00007ed858a7$00004284$000050cd@go.ru>
To: <151@163.net>
From: huiik@go.ru
Subject: Perform Weddings!            ~
Date: Wed, 21 Mar 2001 09:55:24 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Minister Charles Simpson has the power to make you a LEGALLY ORDAINED MINISTER within 48 hours!!!!                  6                                   

BE ORDAINED NOW!

As a minister, you will be authorized to perform the rites and ceremonies of the church!!

WEDDINGS
MARRY your BROTHER, SISTER, or your BEST FRIEND!!
Don't settle for being the BEST MAN OR BRIDES' MAID
Most states require that you register your certificate (THAT WE SEND YOU) with the state prior to conducting the ceremony.

FUNERALS
A very hard time for you and your family
Don't settle for a minister you don't know!!
Most states require that you register your certificate (THAT WE SEND YOU) with the state prior to conducting the ceremony.

BAPTISMS
You can say "WELCOME TO THE WORLD!!!! I AM YOUR MINISTER AND YOUR UNCLE!!"
What a special way to welcome a child of God.

FORGIVENESS OF SINS
The Catholic Church has practiced the forgiveness of sins for centuries
**Forgiveness of Sins is granted to all who ask in sincerity and willingness to change for the better!!

VISIT CORRECTIONAL FACILITIES
Since you will be a Certified Minister, you can visit others in need!!
Preach the Word of God to those who have strayed from the flock

WANT TO START YOUR OWN CHURCH??
After your LEGAL ORDINATION, you may start your own congregation!!


At this point you must be wondering how much the Certificate costs.  Right?  Well, let's talk about how much the program is worth.  Considering the value of becoming a CERTIFIED MINISTER I'd say the program is easily worth $100.  Wouldn't you agree?  However, it won't cost that much.  Not even close!  My goal is to make this life changing program affordable so average folks can benefit from the power of it.
            
Since I know how much you want to help others, you're going to receive your Minister Certification for under $100.00... Not even $50.00...  You are going to receive the entire life-changing course for only $29.95.  

For only $29.95 you will receive:
1. 8-inch by 10-inch certificate IN COLOR, WITH GOLD SEAL.
(CERTIFICATE IS PROFESSIONALLY PRINTED BY AN INK PRESS)
2. Proof of Minister Certification in YOUR NAME!!
3. SHIPPING IS FREE!!!


***********************************************************************

LIMITED TIME OFFER: ORDER TODAY!
SEND Only $29.95 US
(CREDIT CARD, CASH, CHECK, OR MONEY ORDER)
SHIPPING IS FREE!!!

To place your order merely fill out the following form and fax to 1-775-535-7852.  If this line is busy, please try faxing to 1-801-383-9138.

or mail to:

Internet Information Services
PO Box 21442
Billings, MT 59104


(ALL ORDERS FILLED WITHIN 24 HOURS OF RECEIVING THEM)
*Please allow 8 days to receive your certificate by mail.
If you do not receive your order within 10 days, please send us a fax letting us know of the late arrival.  We will then contact you to figure out why you have not received your order.

*************************

Credit Card Order Form
(Please print very clearly in dark ink)

Name on Credit Card: 

Address:

City/State/ZIP:

Your email address: 

Your card will be charged $29.95 for your Ministers' Certificate.

Type of Card, circle one (Visa, MasterCard, American Express)

Credit Card Number: 

Date Credit Card Expires: 

Please tell us your phone Number: 

Please tell us your fax Number: 


To order by Check or Money Order:

MAKE YOUR CHECK PAYABLE TO: 
Internet Information Services

(Please Print Clearly Your Name and Address)
                                                                                   
Name:

Address:

City/State/ZIP:

E-mail Address:

Please tell us your phone Number: 

Please tell us your fax Number: 

(ALL ORDERS FILLED WITHIN 24 HOURS OF RECEIVING THEM)
*Please allow 8 days to receive your certificate by mail.
If you do not receive your order within 10 days, please send us a fax letting us know of the late arrival.  We will then contact you to figure out why you have not received your order.

 

Thank you for your business, 


Internet Information Services
PO Box 21442
Billings, MT 59104

Fax to 1-775-535-7852.  If this line is busy, please try faxing to 1-801-383-9138.


Copyright (c) 1997-2000
All Rights Reserved













++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This ad is produced and sent out by:
Universal Advertising Systems
To be removed from our mailing list please email us at 
vanessagreen@freeze.com with remove in the subject line or
call us toll free at 1-888-605-2485 and give us your email address or write us at:
Central DB Removal, PO Box 1200, Oranjestad, Aruba
++++++++++++++++++++++++++++++++++++++++++++++++++++++++





From rem-conf Wed Mar 21 14:34:50 2001 
From rem-conf-request@es.net Wed Mar 21 14:34:49 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fr6Q-0006l9-00; Wed, 21 Mar 2001 14:29:14 -0800
Received: from c1184632-a.boise1.id.home.com (hotmail.com) [24.16.148.212] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14fr6M-0006jc-00; Wed, 21 Mar 2001 14:29:11 -0800
From:  
To: rem-conf@es.net
Subject: BE A MILLIONAIRE
Date: Wed, 21 Mar 2001 15:27:43
Message-Id: <118.683256.701423@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Dear Friends & Future Millionaires: 

AS SEEN ON NATIONAL TV: 
Making over half million dollars every 4 to 5 months from your home for 
an investment of only $25 U.S. Dollars expense one time 
THANK'S TO THE COMPUTER AGE AND THE INTERNET! 
================================================== 
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! 
Before you say  ''Bull'', please read the following. This is the letter you 
have been hearing about on the news lately. Due to the popularity of 
this letter on the Internet, a national weekly news program recently devoted 
an entire show to the investigation of this program described below, to see 
if it really can make people money. The show also investigated whether or 
not the program was legal. 
Their findings proved once and for all that there are ''absolutely NO Laws 
prohibiting the participation in the program and if people can -follow the 
simple instructions, they are bound to make some mega bucks with only 
$25 out of pocket cost''. DUE TO THE RECENT INCREASE OF 
POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, 
IT IS CURRENTLY WORKING BETTER THAN EVER. 
This is what one had to say: ''Thanks to this profitable opportunity. I 
was approached many times before but each time I passed on it. I am 
so glad I finally joined just to see what one could expect in return for the 
minimal effort and money required. To my astonishment, I received total $ 
610,470.00 in 21 weeks, with money still coming in." 
Pam Hedland, Fort Lee, New Jersey. 
=================================================== 
Here is another testimonial: "This program has been around for a long 
time but I never believed in it. But one day when I received this again 
in the mail I decided to gamble my $25 on it. I followed the simple 
instructions and walaa ..... 3 weeks later the money started to come in. 
First month I only made $240.00 but the next 2 months after that I made 
a total of $290,000.00. So far, in the past 8 months by re-entering the 
program, I have made over $710,000.00 and I am playing it again. The 
key to success in this program is to follow the simple steps and NOT change 
anything.'' More testimonials later but first, 
===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
If you would like to make at least $500,000 every 4 to 5 months easily and 
comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: 
=====Order all 5 reports shown on the list below ===== 
For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose 
name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN 
ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail 
problems. 
=== When you place your order, make sure you order each of the 5 reports. 
You will need all 5 reports so that you can save them on your computer 
and resell them. YOUR TOTAL COST $5 X 5=$25.00. 
Within a few days you will receive, vie e-mail, each of the 5 reports from 
these 5 different individuals. Save them on your computer so they will be 
accessible for you to send to the 1,000's of people who will order them 
>from you. Also make a floppy of these reports and keep it on your desk in 
case something happen to your computer. 
IMPORTANT - DO NOT alter the names of the people who are listed next 
to each report, or their sequence on the list, in any way other than what is 
instructed below in step '' 1 through 6 '' or you will loose out on majority 
of your profits. Once you understand the way this works, you will also see 
how it does not work if you change it. Remember, this method has been 
tested, and if you alter, it will NOT work !!! People have tried to put their 
friends/relatives names on all five thinking they could get all the money. But 
it does not work this way. Believe us, we all have tried to be greedy and then 
nothing happened. So Do Not try to change anything other than what is 
instructed. Because if you do, it will not work for you. 
Remember, honesty reaps the reward!!! 
1.... After you have ordered all 5 reports, take this advertisement and 
REMOVE the name & address of the person in REPORT # 5. This person 
has made it through the cycle and is no doubt counting their fortune. 
2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 
3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 
4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 
5.... Move the name & address in REPORT # 1 down TO REPORT # 2 
6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE 
SURE you copy every name & address ACCURATELY! 
========================================================== 
**** Take this entire letter, with the modified list of names, and save it on your 
computer. DO NOT MAKE ANY OTHER CHANGES. 
Save this on a disk as well just in case if you loose any data. To assist you with 
marketing your business on the internet, the 5 reports you purchase will provide 
you with invaluable marketing information which includes how to send bulk 
e-mails legally, where to find thousands of free classified ads and much more. 
There are 2 Primary methods to get this venture going: 
METHOD # 1: BY SENDING BULK E-MAIL LEGALLY 
========================================================== 
Let's say that you decide to start small, just to see how it goes, and we will 
assume You and those involved send out only 5,000 e-mails each. Let's 
also assume that the mailing receive only a 0.2% response (the response 
could be much better but lets just say it is only 0.2%. Also many people 
will send out hundreds of thousands e-mails instead of only 5,000 each). 
Continuing with this example, you send out only 5,000 e-mails. With a 0.2% 
response, that is only 10 orders for report # 1. Those 10 people responded 
by sending out 5,000 e-mail each for a total of  50,000. Out of those 50,000 
e-mails only 0.2% responded with orders. That's=100 people responded and 
ordered Report # 2. 
Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. 
The 0.2% response to that is 1000 orders for Report # 3. 
Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails 
sent out. The 0.2% response to that is 10,000 orders for Report # 4. 
Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 
(50 million) e-mails. The 0.2% response to that is 100,000 orders for Report 
# 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). 
Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 
.... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 
NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT 
THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU 
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! 
========================================================= 
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE 
ORDERING OUT OF 5,000 YOU MAILED TO. 
Dare to think for a moment what would happen if everyone or half or even 
one 4th of those people mailed 100,000e-mails each or more? There are 
over 150 million people on the Internet worldwide and counting. Believe me, 
many people will do just that, and more! 
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET 
======================================================= 
Advertising on the net is very very inexpensive and there are hundreds 
of FREE places to advertise. Placing a lot of free ads on the Internet will 
easily get a larger response. We strongly suggest you start with Method # 1 
and METHOD # 2 as you go along. For every $5 you receive, all you 
must do is e-mail them the Report they ordered. That's it. Always provide 
same day service on all orders. 
This will guarantee that the e-mail they send out, with your name and 
address on it, will be prompt because they can not advertise until they 
receive the report. 
=========== AVAILABLE REPORTS ==================== 
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: 
Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT 
accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets 
of paper. On one of those sheets of paper, Write the NUMBER & the NAME 
of the Report you are ordering, YOUR E-MAIL ADDRESS and your name 
and postal address. 
PLACE YOUR ORDER FOR THESE REPORTS NOW : 
==================================================== 
REPORT
# 1: The Insider's Guide to Advertising for Free on the Net
Order Report #1 from:

VGO
P.O. Box 6058
Boise, Idaho 83707
USA 
________________________________________________________

REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net
Order Report # 2 from:

JBG
P.O. Box 6018
Boise, Idaho 83707
USA
_________________________________________________________________
REPORT # 3: Secret to Multilevel marketing on the net
Order Report # 3 from :

LSM
8030 La Mesa Blvd. #221
La Mesa,CA.91941
USA

____________________________________________________________ 
REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" 
Order Report # 4 from:

SJS
3628 Monroe Ave.#7
San Diego,CA.92116
USA
 ____________________________________________________________ 
REPORT #5: "How to Send Out 0ne Million e-mails for Free" 
Order Report # 5 from: 

C.J. Kalata
P.O. Box 130157
Roseville, MN 55113-0002
USA

____________________________________________________________ 
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ 
Follow these guidelines to guarantee your success: 
=== If you do not receive at least 10 orders for Report #1 within 2 
weeks, continue sending e-mails until you do. 
=== After you have received 10 orders, 2 to 3 weeks after that you 
should receive 100 orders or more for REPORT # 2. If you did not, 
continue advertising or sending e-mails until you do. 
=== Once you have received 100 or more orders for Report # 2, YOU 
CAN RELAX, because the system is already working for you, and the 
cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: 
Every time your name is moved down on the list, you are placed in front 
of a Different report. 
You can KEEP TRACK of your PROGRESS by watching which report 
people are ordering from you. IF YOU WANT TO GENERATE MORE 
INCOME SEND ANOTHER BATCH OF E-MAILS AND START 
THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this business !!! 
====================================================== 
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS 
PROGRAM: You have just received information that can give you 
financial freedom for the rest of your life, with NO RISK and JUST 
A LITTLE BIT OF EFFORT. You can make more money in the next 
few weeks and months than you have ever imagined. Follow the program 
EXACTLY AS INSTRUCTED. Do Not change it in any way. It works 
exceedingly well as it is now. 
Remember to e-mail a copy of this exciting report after you have put 
your name and address in Report #1 and moved others to #2 ...........# 5 
as instructed above. One of the people you send this to may send out 
100,000 or more e-mails and your name will be on every one of them. 
Remember though, the more you send out the more potential customers 
you will reach. 
So my friend, I have given you the ideas, information, materials and 
opportunity to become financially independent. IT IS UP TO YOU NOW! 
============ MORE TESTIMONIALS ================ 
"My name is Mitchell. My wife, Jody and I live in Chicago. I am an 
accountant with a major U.S. Corporation and I make pretty good money. 
When I received this program I grumbled to Jody about receiving ''junk 
mail''. I made fun of the whole thing, spouting my knowledge of the population 
and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored 
my supposed intelligence and few days later she jumped in with both feet. I 
made merciless fun of her, and was ready to lay the old ''I told you so'' on 
her when the thing didn't work. Well, the laugh was on me! Within 3 weeks 
she had received 50 responses. Within the next 45 days she had received 
total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody 
in her ''hobby''. 
Mitchell Wolf M.D., Chicago, Illinois 
====================================================== 
''Not being the gambling type, it took me several weeks to make up my 
mind to participate in this plan. But conservative that I am, I decided that 
the initial investment was so little that there was just no way that I 
wouldn't get enough orders to at least get my money back''. '' I was 
surprised when I found my medium size post office box crammed with 
orders. I made $319,210.00in the first 12 weeks. The nice thing about 
this deal is that it does not matter where people live. There simply isn't a 
better investment with a faster return and so big." 
Dan Sondstrom, Alberta, Canada 
======================================================= 
''I had received this program before. I deleted it, but later I wondered 
if I should have given it a try. Of course, I had no idea who to contact to 
get another copy, so I had to wait until I was e-mailed again by someone 
else.........11 months passed then it luckily came again...... I did not 
delete this one! I made more than $490,000 on my first try and all the 
money came within 22 weeks." 
Susan De Suza, New York, N.Y. 
======================================================= 
''It really is a great opportunity to make relatively easy money with 
little cost to you. I followed the simple instructions carefully and 
within 10 days the money started to come in. My first month I made 
$20,560.00 and by the end of third month my total cash count was 
$362,840.00 Life is beautiful, Thanx to internet.". 
Fred Dellaca, Westport, New Zealand 
======================================================= 
ORDER YOUR REPORTS TODAY AND GET STARTED ON 
'YOUR' ROAD TO FINANCIAL FREEDOM! 
======================================================= 
If you have any questions of the legality of this program, contact the 
Office of Associate Director for Marketing Practices, Federal Trade 
Commission, Bureau of Consumer Protection, Washington, D.C. 




From rem-conf Wed Mar 21 15:45:25 2001 
From rem-conf-request@es.net Wed Mar 21 15:45:24 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fsEj-0000eD-00; Wed, 21 Mar 2001 15:41:53 -0800
Received: from sj-msg-core-3.cisco.com [171.70.157.152] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fsEi-0000dF-00; Wed, 21 Mar 2001 15:41:52 -0800
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id PAA01919;
	Wed, 21 Mar 2001 15:39:28 -0800 (PST)
Received: from rkumar-ntl.cisco.com (dhcp-171-71-9-134.cisco.com [171.71.9.134])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id AAI54194 (AUTH rkumar);
	Wed, 21 Mar 2001 15:40:31 -0800 (PST)
Message-Id: <4.3.2.7.2.20010321154211.00d71550@mira-sjc5-8>
X-Sender: rkumar@mira-sjc5-8
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Mar 2001 15:46:19 -0800
To: Henning Schulzrinne 
From: Rajesh Kumar 
Subject: Text for inclusion in rfc2833bis
Cc: rem-conf@es.net, mmostafa@cisco.com, fandreas@cisco.com, bfoster@cisco.com
In-Reply-To: <3AB4276C.B531689A@cs.columbia.edu>
References: <4.3.2.7.2.20010316144314.00db44a0@mira-sjc5-8>
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_7153946==_"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--=====================_7153946==_
Content-Type: multipart/alternative;
	boundary="=====================_7153946==_.ALT"

--=====================_7153946==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


Dr. Schulzrinne:

Here is the text I promised for rfc2833bis to support a 'trunk unavailable' 
event. I think it is pretty solid, however, the AVT team is requested to 
review, criticize and ask for explanations as needed.

With best regards,

Rajesh





--=====================_7153946==_.ALT
Content-Type: text/html; charset="us-ascii"




Dr. Schulzrinne: 



Here is the text I promised for rfc2833bis to support a 'trunk
unavailable' event. I think it is pretty solid, however, the AVT team is
requested to review, criticize and ask for explanations as needed.



With best regards,



Rajesh

 

 

 

 



--=====================_7153946==_.ALT--

--=====================_7153946==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="new.event.rfc2833.txt"






  
Dr. Schulzrinne: Here is the text I promised for rfc2833bis to support a 'trunk unavailable' event.-rajesh



       Event                           encoding (decimal)
       __________________________________________________
        
       Trunk unavailable                   ???

                     Table 6: Trunk events

       Trunk unavailable: The trunk is unavailable for service. The duration
           field is set to a value, typically 1 second, that allows adequate
           granularity in demarcating downtime. When there is a change to 
           an unavailable state, this event is sent with the same 
           timestamp 3 times at an interval of 20 ms. A 5 ms interval can 
           also be used. If the trunk persists in the unavailable state at 
           the end of the indicated duration, then it is retransmitted, 
           preferably with the same redundancy scheme.

           Unavailability of the trunk might result from a failure or an
           administrative action. This event is used in a stateless manner
           to synchronize trunk unavailability between equipment connected 
           through provisioned RTP trunks. It avoids the unnecessary 
           consumption of bandwidth in sending a continuous stream of
           RTP packets with a fixed payload for the duration of the
           downtime, as would be required in certain E1-based applications.
           In T1-based applications, trunk conditioning via the ABCD 
           transitional events can be used instead.

 
 
 

--=====================_7153946==_
Content-Type: multipart/alternative;
	boundary="=====================_7153966==_.ALT"

--=====================_7153966==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Thanks.

Rajesh
------------------------------------------------
Rajesh Kumar, Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------------------


--=====================_7153966==_.ALT
Content-Type: text/html; charset="us-ascii"


Thanks.



Rajesh

------------------------------------------------

Rajesh Kumar, Cisco Voice Technology Center 

Tel: 408-527-0811, Fax: 408-853-1101 

Epage:
mailto:rkumar@epage.cisco.com

------------------------------------------------ 





--=====================_7153966==_.ALT--

--=====================_7153946==_--




From rem-conf Wed Mar 21 17:58:37 2001 
From rem-conf-request@es.net Wed Mar 21 17:58:36 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fuIs-0003ID-00; Wed, 21 Mar 2001 17:54:18 -0800
Received: from sj-msg-core-2.cisco.com [171.69.43.88] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fuIr-0003Gi-00; Wed, 21 Mar 2001 17:54:17 -0800
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA06462;
	Wed, 21 Mar 2001 17:53:37 -0800 (PST)
Received: from rkumar-ntl.cisco.com (dhcp-171-71-9-134.cisco.com [171.71.9.134])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id AAI56008 (AUTH rkumar);
	Wed, 21 Mar 2001 17:53:15 -0800 (PST)
Message-Id: <4.3.2.7.2.20010321175848.00d673e0@mira-sjc5-8>
X-Sender: rkumar@mira-sjc5-8
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Mar 2001 17:59:03 -0800
To: Henning Schulzrinne 
From: Rajesh Kumar 
Subject: Text for inclusion in rfc2833bis
Cc: rem-conf@es.net, mmostafa@cisco.com, fandreas@cisco.com, bfoster@cisco.com,
        rkumar@cisco.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_15118218==_"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--=====================_15118218==_
Content-Type: multipart/alternative;
	boundary="=====================_15118218==_.ALT"

--=====================_15118218==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


Dr. Schulzrinne:

Here is the text I promised for rfc2833bis to support a 'trunk unavailable' 
event. I think it is pretty solid, however, the AVT team is requested to 
review, criticize and ask for explanations as needed.

With best regards,

Rajesh





--=====================_15118218==_.ALT
Content-Type: text/html; charset="us-ascii"




Dr. Schulzrinne: 



Here is the text I promised for rfc2833bis to support a 'trunk
unavailable' event. I think it is pretty solid, however, the AVT team is
requested to review, criticize and ask for explanations as needed.



With best regards,



Rajesh

 

 

 

 



--=====================_15118218==_.ALT--

--=====================_15118218==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="new.event.rfc2833.txt"






  
Dr. Schulzrinne: Here is the text I promised for rfc2833bis to support a 'trunk unavailable' event.-rajesh



       Event                           encoding (decimal)
       __________________________________________________
        
       Trunk unavailable                   ???

                     Table 6: Trunk events

       Trunk unavailable: The trunk is unavailable for service. The duration
           field is set to a value, typically 1 second, that allows adequate
           granularity in demarcating downtime. When there is a change to 
           an unavailable state, this event is sent with the same 
           timestamp 3 times at an interval of 20 ms. A 5 ms interval can 
           also be used. If the trunk persists in the unavailable state at 
           the end of the indicated duration, then it is retransmitted, 
           preferably with the same redundancy scheme.

           Unavailability of the trunk might result from a failure or an
           administrative action. This event is used in a stateless manner
           to synchronize trunk unavailability between equipment connected 
           through provisioned RTP trunks. It avoids the unnecessary 
           consumption of bandwidth in sending a continuous stream of
           RTP packets with a fixed payload for the duration of the
           downtime, as would be required in certain E1-based applications.
           In T1-based applications, trunk conditioning via the ABCD 
           transitional events can be used instead.

 
 
 

--=====================_15118218==_
Content-Type: multipart/alternative;
	boundary="=====================_15118238==_.ALT"

--=====================_15118238==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Thanks.

Rajesh
------------------------------------------------
Rajesh Kumar, Cisco Voice Technology Center
Tel: 408-527-0811, Fax: 408-853-1101
Epage: mailto:rkumar@epage.cisco.com
------------------------------------------------


--=====================_15118238==_.ALT
Content-Type: text/html; charset="us-ascii"


Thanks.



Rajesh

------------------------------------------------

Rajesh Kumar, Cisco Voice Technology Center 

Tel: 408-527-0811, Fax: 408-853-1101 

Epage:
mailto:rkumar@epage.cisco.com

------------------------------------------------ 





--=====================_15118238==_.ALT--

--=====================_15118218==_--




From rem-conf Wed Mar 21 22:39:14 2001 
From rem-conf-request@es.net Wed Mar 21 22:39:13 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14fyg7-0007mk-00; Wed, 21 Mar 2001 22:34:35 -0800
Received: from sj-msg-core-1.cisco.com [171.71.163.11] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14fyg6-0007mH-00; Wed, 21 Mar 2001 22:34:34 -0800
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA24824;
	Wed, 21 Mar 2001 22:33:29 -0800 (PST)
Received: from tmima-w2k.cisco.com (sjc-vpn-171.cisco.com [10.21.64.171])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id ALH02493;
	Wed, 21 Mar 2001 22:33:27 -0800 (PST)
Message-Id: <4.3.2.7.2.20010321235847.02909de0@mira-sjcm-2.cisco.com>
X-Sender: tmima@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Mar 2001 00:32:10 -0600
To: "Daniel Feldman" , 
From: Tmima Koren 
Subject: Re: cTCRTP
Cc: "Eyal Gutman" , "Alex Trigub" ,
        "Doron Greenbaum" , "Giora Ariel" ,
        "Dov Alon" 
In-Reply-To: <88BC9E379956AE4DB689CC5FF6F5A43D36E9@exchange.Ic4ic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


There is no separate document that describes cTCRTP. It's just cUDP applied to a TCRTP stream (which is a stream of IP packets) when traversing a PPP link.
Tmima

At 02:53 PM 3/21/2001 +0200, Daniel Feldman wrote:
>        Does anyone know which document describes cTCRTP (supposedly a
>more bandwidth efficient way to send TCRTP over a PPP link by
>compressing the L2TP IP header with cUDP)?
>        Thanks in advance,
>
>~~~~~~~~~~~~~~~~~~~~~~~~
>Daniel Feldman
>System Engineer, IC4IC ltd.
>office: +972-4-9594644 ext. 121
>mobile: +972-53-980442
>fax: +972-4-9594944
>~~~~~~~~~~~~~~~~~~~~~~~~




From rem-conf Thu Mar 22 02:59:04 2001 
From rem-conf-request@es.net Thu Mar 22 02:59:04 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14g2bX-0003v3-00; Thu, 22 Mar 2001 02:46:07 -0800
Received: from (CIC-EMS-1.bestinfo.gov.cn) [210.76.97.252] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14g2bQ-0003ut-00; Thu, 22 Mar 2001 02:46:02 -0800
Received: from notes-server5.bestinfo.net.cn ([210.76.97.245])
	by CIC-EMS-1.bestinfo.gov.cn (8.9.1a/8.9.1) with ESMTP id SAA18831;
	Thu, 22 Mar 2001 18:44:35 +0800 (CST)
From: derecho@smtp.esarom.com
Received: from kwn.com ([38.33.134.98])
          by notes-server5.bestinfo.net.cn (Lotus Domino Build 166.1)
          with SMTP id 2001032218354056:8715 ;
          Thu, 22 Mar 2001 18:35:40 +0800 
To: 
Subject: Free gift just for clicking on our site!
Date: Thu, 22 Mar 2001 05:32:45 -0500
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MIMETrack: Itemize by SMTP Server on notes-server5/Bestinfo(R5.0 (Intl)|30 March 1999) at
 2001-03-22 06:35:41 PM,
	Serialize by Router on notes-server5/Bestinfo(R5.0 (Intl)|30 March 1999) at
 2001-03-22 06:46:27 PM,
	Serialize complete at 2001-03-22 06:46:27 PM
Message-ID: 
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="Windows-1252"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This family in the midwest USA is living a very comfortable life.
We do NOT do mlm, network marketing, or chain letters!!
We run a legitimate business and we want to show you how 
you can do the same with just a little effort and a lot of good will!!
Laziness does not help!!

We love staying at home and raising our 2 children!
Please, just read what we have to offer and we will give you a FREE gift!

FREE DOWNLOADABLE BOOK FOR EVERY VISITOR!
===========================================================
Send an email to:  keystone@uol.com.ar
with "home" in the * SUBJECT* field.
===========================================================

The first 75 people will also get a FREE REPORT
===========================================================
See Below for INSTANT ACCESS!
==>> Send e-mail to: mailto:  keystone@uol.com.ar?subject=home
===========================================================


This message is sent in compliance of the new email bill section 301. Per Section 301,
Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email
may be stopped at no cost to you by contacting us:  doitnow@uol.com.ar
Please type "Remove" in the subject line.Your request to be remove will be processed
within 24 hours. Please DO NOT Reply to this message if you wish to be removed









From rem-conf Thu Mar 22 12:03:29 2001 
From rem-conf-request@es.net Thu Mar 22 12:03:28 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gBDc-0004gf-00; Thu, 22 Mar 2001 11:58:00 -0800
Received: from gumby.cs.berkeley.edu [128.32.32.38] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gBDb-0004gV-00; Thu, 22 Mar 2001 11:57:59 -0800
Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74])
	by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA07233;
	Thu, 22 Mar 2001 11:51:23 -0800
Message-ID: <3ABA58CE.79ACBBAA@bmrc.berkeley.edu>
Date: Thu, 22 Mar 2001 11:55:58 -0800
From: katherine reyes 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: 4/4 Berkeley Multimedia, Graphics and Interfaces Seminar
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Berkeley Multimedia, Graphics and Interfaces Seminar

The Future of the GUI

April 04, 2001,
1:10-2:30 p.m. PST
Fujitsu Seminar Room (405 Soda Hall)

John Ousterhout
Interwoven, Inc.

Graphical user interfaces as we knew them in them in the early 1990s are
on the road to extinction, replaced by Web-based GUIs. In this talk I
will discuss issues in using the Web for "real" GUIs (as opposed to
documents and forms) and compare Web-based GUIs to traditional GUIs. I
will also speculate about how the facilities for Web-based GUIs might
evolve the years to come.

---------------

The seminar is broadcast live on the Internet Mbone and as a Real
Networks G2 broadcast.

You can connect to the live RealNetworks broadcast at:
http://bmrc.berkeley.edu/bibs/cs298-5

You can also directly put in this url into the Real Player:
rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm

To do so you will need to have the "Real Player G2" installed, which is
available
from:http://www.real.com/products/player/downloadrealplayer.html

To tune into the Internet MBone broadcast, look for the announcement in
your MBone session directory program ('sdr'), or you can visit:
http://imj.ucsb.edu/sdr-monitor/

You can get further information about this seminar, and access to
replays of previous seminars at
the MIG Seminar web page:

http://media2.bmrc.berkeley.edu/bibs/archive.cfm

Sponsored by the Berkeley Multimedia Research Center



From rem-conf Thu Mar 22 12:59:41 2001 
From rem-conf-request@es.net Thu Mar 22 12:59:41 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gC8q-0006FW-00; Thu, 22 Mar 2001 12:57:08 -0800
Received: from (tsmtp2.mail.isp) [195.235.113.141] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gC8o-0006Ef-00; Thu, 22 Mar 2001 12:57:06 -0800
Received: from pop3.teleline.es ([212.170.176.213]) by
          tsmtp2.mail.isp (Netscape Messaging Server 4.15) with SMTP id
          GAMA3K03.Y35 for ; Thu, 22 Mar 2001 21:54:56 +0100 
To: rem-conf@es.net
From: "pacsam@terra.es" 
Date: Thu, 22 Mar 2001 21:58:20
Subject: noticia de interes
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



 
Saludos, enorabuena ha sido seleccionado para una oportunidad única.

   En primer lugar felicitarle por su pagina y proponerle un negocio que 
le aportará increibles beneficios
 ¿Que te parecería si hicieras entre u$s 3.000.00 - u$s 5.000.00 al mes? 
No se requiere pagar dinero por adelantado. Nosotros proporcionamos el 
sistema, es agradable y fácil, y solo lleva unas pocas horas al día. Tú 
pones tu propio plan de trabajo. Totalmente legal y tu puedes ayudar a 
personas a enriquecer sus vidas. Si tu tienes una computadora y acceso 
a Internet entonces estás list(o)(a) para empezar. Contactar a pacsam@terra.es 
escribe en la subject line = solicito información.


Saludos,
Antonio S. Romero

 Sistemas Informaticos
E-mail : pacsam@terra.es

Respetamos su privacidad.  Si le ha molestado este mensaje le pido las 
más humildes disculpas. No pretendo molestar mientras realizo mi trabajo. 
Este no es un Spm.  Bajo el Decreto S.1618, Título III aprobado por el 
105 congreso base de las normativas internacionales,  este mensaje no puede 
ser considerado "Correo No Solicitado", mientras incluya una forma de ser 
removido.
Para eliminar futuros envios, comedidamente le solicito que coloque la 
palabra REMOVE en Asunto y pulse reenviar este e-mail. Gracias por su atención.



--------------------

E-Mail sent using the Free Trial Version of WorldMerge, the fastest
and easiest way to send personalized e-mail messages. More
information at http://www.coloradosoft.com/worldmrg

201266




From rem-conf Thu Mar 22 14:24:29 2001 
From rem-conf-request@es.net Thu Mar 22 14:24:28 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gDTB-0000Wm-00; Thu, 22 Mar 2001 14:22:13 -0800
Received: from pcp000707pcs.wireless.meeting.ietf.org (purple.east.isi.edu) [135.222.64.207] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gDTA-0000Wc-00; Thu, 22 Mar 2001 14:22:12 -0800
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id RAA01337
	for ; Thu, 22 Mar 2001 17:21:36 -0500
Message-Id: <200103222221.RAA01337@purple.east.isi.edu>
To: rem-conf@es.net
Subject: AVT presentation slides
Date: Thu, 22 Mar 2001 17:21:36 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Would those who presented in AVT please send a copy of your slides to 
the chairs. We'll collect them for inclusion in the minutes, and will 
make them available on a web-page.

Thanks!
Colin



From rem-conf Thu Mar 22 17:38:23 2001 
From rem-conf-request@es.net Thu Mar 22 17:38:23 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gGRU-00055D-00; Thu, 22 Mar 2001 17:32:40 -0800
Received: from pcp000707pcs.wireless.meeting.ietf.org (purple.east.isi.edu) [135.222.64.207] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gGRT-000551-00; Thu, 22 Mar 2001 17:32:39 -0800
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA02763;
	Thu, 22 Mar 2001 20:21:44 -0500
Message-Id: <200103230121.UAA02763@purple.east.isi.edu>
To: " " 
cc: rem-conf@es.net
Subject: Re: About MBZ... 
In-Reply-To: Message from " "  
   of "Wed, 21 Mar 2001 18:19:24 +0700." <20010321181924.HM.E0000000001MU7V@www15.hanmail.net> 
Date: Thu, 22 Mar 2001 20:21:43 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

The MBZ fields are reserved for future use. You cannot use them for your
application, unless you first produce an updated standard specifying the
desired use (i.e. an RFC describing your modifications to the protocol).

Colin



--> " " writes:
>Hi
>Many RFC has MBZ field for future use.
>So, now I can't use that field for my application ?
>I want use that field for sending some information to client..
>
>If anyone know the answer, please tell me.
>
>thanks.
>
>==================================================
>¿ì¸® ÀÎÅͳÝ, Daum
>Æò»ý ¾²´Â ¹«·á E-mail ÁÖ¼Ò ÇѸÞÀϳÝ
>Áö±¸ÃÌ ÇÑ±Û °Ë»ö¼­ºñ½º Daum FIREBALL
>http://www.daum.net



From rem-conf Thu Mar 22 21:11:08 2001 
From rem-conf-request@es.net Thu Mar 22 21:11:07 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gJjo-00015U-00; Thu, 22 Mar 2001 21:03:48 -0800
Received: from tomts8.bellnexxia.net (tomts8-srv.bellnexxia.net) [209.226.175.52] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gJjl-00013M-00; Thu, 22 Mar 2001 21:03:45 -0800
Received: from smtp1.sympatico.ca ([65.92.103.191])
          by tomts8-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20010323050236.XGBP22656.tomts8-srv.bellnexxia.net@smtp1.sympatico.ca>;
          Fri, 23 Mar 2001 00:02:36 -0500
From: jimmy_olsenca@yahoo.ca
Subject: Your money @ the Federal Reserve Board.
Reply-To: jimmy_olsenca@yahoo.ca
Date: 23 Mar 2001 00:15:50 -0500
Mime-Version: 1.0
Content-Type: multipart/alternative;boundary="75ImAu-FoiMD1"
Message-Id: <20010323050236.XGBP22656.tomts8-srv.bellnexxia.net@smtp1.sympatico.ca>
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--75ImAu-FoiMD1
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

                                   Remove instruction at the bottom

QUICK CASH SECRET BANKING SYSTEM, THE SECRETS OF THE RICH & FAMOUS 
REVEALED AT LAST!!! Make money with the abundance of the bank's money  
  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$
Quick Cash Secret Banking System is the fastest and the easiest money 
making system today in the world, used by all multi-millionaires to pile 
up cash, without any huffing and puffing! 
==================================================
It is 100% legal, easy, fast and fun! There is no scam or shady 
transaction! It WORKS in any country in the world that has bank(s) and 
provides the facility to open checking account(s). 
<<><><><><><><><><><><<><><><><>
I guarantee that from this moment on your life will never be the same 
again. You will be amazed at how much money you will be capable of having 
in just a few days, right from your Federal Reserve Board.
Please, leave the skepticism in the past. If you are skeptical, this will 
not work or anything else in life for that matter, because you will not 
believe.   If you were promised $5,000,000 to jump out of an airplane 
without a parachute, would you do it? If you answered "No" you answered 
Wrong! Like the majority of the people, you made a decision before you had 
all the facts. Had you investigated further, you would have found out that 
the plane was on the ground. Do not let the greatest opportunity of your 
life pass you by because you were so eager to jump into conclusions that 
you did not get all the facts. Please, read on and try to get the concept 
of what I can give you here and now, before you form any opinions.

Ok, I think that you are ready to begin now.  I want you to follow exactly 
the instructions that you are about to read. Let me be your guide 
throughout the entire booklet.  It is financial health you are looking for 
and I sure know how you can get it. So, follow my instructions. 
 
MAKE MONEY WITH THE BANK'S MONEY

During a 6-month period you will be able to deposit 50,000 dollars in your 
personal bank accounts, without doing anything at all!  Let me elaborate 
just a little.  "You do not do anything physical to bring in this kind of 
money!"  The bank does all the work for you at your convenience, and as 
long as you keep your account "open" they almost have no choice!  I will 
show you how to make a minimum of $5,000 a month by just opening a bank 
account.  But that is just the tip of the iceberg!  By opening a bank 
account, I will teach you how to have that kind of money deposited into 
your bank account Automatically, though a built-in automatic process that 
I will personally show you.  That is the beauty of the $ecret Banking 
$ystem!  Imagine making $5,000 a month for each bank account you "open".  
And aside from opening the account, it does not cost you anything!  Just 
one bank account can make you financially independent for life! 

Now Think Big.  Think of the same idea on a slight larger scale, like two 
or three bank accounts working at the same time each producing a 
guaranteed monthly income of $5,000 each.  As of today, I have 13 active 
account @$5,000 = $65,000 per month, every month, 12 months a year.  I 
assure you, there is no print error.  I said 65 thousand dollars per 
month! 

In summary this is how the formula works:  YOU walk into a bank, open a 
bank account, follow the instructions like a recipe in a cookbook, and 30 
days later you will make $5,000.  And one of the most amazing realities of 
the $ecret Banking $ystem is that you can begin with literally $0, zero 
money.  In the $ecret Banking $ystem manual, in an easy to duplicate as a 
set of "blueprints", you will find out for yourself where all the money 
comes from and how it is added up for you.

I realize what I am originating to you may sound impossible, but I promise 
you, it is possible, doable and simple.  There is not shortage of money, 
the Federal Reserve Board creates money daily but most of it must pass 
through and circulate in the banks over and over again.  That is how banks 
run.  That is where this Ingenious $ecret Banking $ystem comes in.  All 
you need is the $ecret Banking $ystem manual to start making big money.  
IF YOU ORDER TODAY WE SHALL ADD AT NO EXTRA COST TO YOU, THE FAMOUS "101 
High Profit Businesses You Can Start Online For Little Or No Money", PLUS 
1,000 How-To Books, Manuals and Programs.
a.) E-BOOK SUCCESS ON THE NET
b.) E-BOOK 101 HIGH PROFIT BUSINESS
c.) TEN STEPS TO SUCCESS
d.) THE $ECRET BANKING $YSTEM
e.) 1000 HOW-TO BOOKS
That you obtain your very own copy of the $ecret Banking $ystem and the 
above mentioned, take the first step and invest only $49US for something 
that is worth its weight in gold.  Copy and mail-send a money order and 
Postal Money Order must be INTERNATIONAL.  You can also send a cheque (we 
accept cash) to: 

All Moreir 
970 Queen St. E. #98165
Toronto, Ontario, Canada
M4M 1J0
___________
ORDER FORM

Name	________________________________________________
Address	______________________________________________
City	_____________________	State_________	Zip_____-________
Fax	(_____) _____-______
E-mail address	_________________________________________
Send me the $ecret Banking $ystem right now, please.  Here is the $49US. 
Postal Money Order must be INTERNATIONAL
Write legible please
________ Check here if you would like to receive this information by e-
mail as an attachment and save the $5.00 shipping and handling fee, which 
is the fastest service; if not please add $5US for S&H. 
IF YOU ORDER TODAY
WE SHALL ADD AT NO EXTRA COST TO YOU, THE FAMOUS "101 High Profit 
Businesses You Can Start Online For Little Or No Money", PLUS MORE THAN 
ONE MILLION OPT-IN ADDRESSES- FREE!!
Postal Money Orders MUST be international- - if not, this will not be 
negotiable outside the USA and will be returned.
If you realize that you are on this list in error or have changed your 
mind or if you do not want this type of information, please reply to this 
e-mail with "REMOVE" in the subject field and you will be removed 
immediately! I apologize for any mistake, intrusion or inconvenience, if 
any.  Under Bill 1618 Title 111 passed by the 105th U.S. Congress, this 
message can not be considered SPAM as long as we include a way for it to 
be removed from future mailings
 Foundations of Wealth
If you wish to learn more……please read on
A few years ago I believed that I really had to work hard to make money. I 
thought that the more I worked, the more money I was going to make. But 
after a while I realized that I was not getting anywhere. I was working 
like a slave and I was not seeing any satisfactory results. I wondered why 
I wasn't because I sure was applying the time and the effort. 
I realized that I needed to make a change. For months I tried to find that 
special answer that I needed. I tried different things, but none of them 
worked. I was lost. Finally, I was ready to give up my dreams and continue 
living that ordinary life that I was used to living. You know, that wake 
up, go to work, come home, have dinner, and go to bed sort of life. That 
kind of life that I am very sure you are used to living. But no! I had to 
give it one more chance. I could not quit that easily. So, an idea came to 
my mind and I decided: "If I want to be become extremely wealthy, why 
don't I study people who already are extremely wealthy and interpret what 
they are doing?" So that is what I did. After a few months, I realized 
that the majority of the extremely wealthy people did not work that hard. 
Also, the majority of them not only had enough money to buy another planet, 
but they also had the time and the freedom to enjoy it. That is what I 
consider true wealth, and that is exactly what $ecret Banking $ystem is 
all about. The ability to have free time and be able to do what you choose, 
when you choose it. I think that is where the majority of the people get 
confused on the definition of wealth. Wealth is not just money. Wealth is 
also the ability to spend it the way you choose to do, when you want to do 
so.
Having accomplished my goals, my purpose now is to help those that are in 
the situation I was in; my purpose is to turn you into a "true" wealthy 
person; I want you to have great amounts of money, and great amounts of 
free time to enjoy it. Now, the first step to accomplish this is the one 
that a lot of people do not pay that much attention to, yet it is one of 
the most important aspects of true wealth. I am talking about the mental 
aspect of true wealth. Hang on!  I know you are tired of listening the 
same psychology song over and over. Do not worry!  The mental aspect of 
true wealth is actually very simple and easy to apply. It is actually like 
a list of steps that you have to "get into your mind" before we really get 
into the "secrets" of making money with the bank's money that I have been 
talking about so much. Once you know all these steps and are ready to 
apply them, then you will really be ready to start the journey.
Please! Do not jump this section thinking that you do not need any mental 
preparation. It is very important! Remember, follow my instructions and 
you could be sitting on gold in just days.
Do you remember the three "keys" to success that I explained on the web 
site? If you forgot, the three "keys" to success are:
1.	Timing: Being at the right place at the right time. 
2.	Having Vision: Seeing potential in what is being presented. Having the 
ability to see success. 
3.	Taking Action: Going one step further than the rest. Doing instead of 
saying.
These three "keys" are essential to recognize success, and to make it a 
part of your life. Now, once you have made the decision to "Take Action," 
your next task is to follow what I call "The Ten Steps To Success." As I 
said before, they are very simple, but extremely important if your purpose 
is to achieve true wealth. I would happily give them to you as part of the 
Training I provide when you obtain the $ecret Banking $ystem.  Get your 
copy today!

 

--75ImAu-FoiMD1
Content-Type: text/html











 












Remove instruction
at the bottom



QUICK CASH SECRET BANKING SYSTEM, THE SECRETS OF THE
RICH & FAMOUS REVEALED AT LAST!!! Make
money with the abundance of the bank’s money  



  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$



Quick Cash Secret Banking System is the fastest
and the easiest money making system today in the world, used by all
multi-millionaires to pile up cash, without any huffing and puffing! 



==================================================



It is 100% legal, easy, fast
and fun! There is no scam or shady transaction! It
WORKS in any country in the world that has bank(s) and provides the facility to
open checking account(s). 



<<><><><><><><><><><><<><><><><>



I guarantee that from this moment on your life will never be the same again.
You will be amazed at how much money you will be capable of having in just a
few days, right from your Federal Reserve Board.



Please, leave the skepticism in the past. If you are skeptical, this will
not work or anything else in life for that matter, because you will not
believe.   If you were promised
$5,000,000 to jump out of an airplane without a parachute, would you do it? If
you answered "No" you answered Wrong! Like the majority
of the people, you made a decision before you had all the facts. Had you investigated
further, you would have found out that the plane was on the ground. Do not let
the greatest opportunity of your life pass you by because you were so eager to
jump into conclusions that you did not get all the facts. Please, read on and
try to get the concept of what I can give you here and now, before you form any
opinions.



Ok, I think that you are ready to begin now.  I want you to follow exactly the instructions that you are about
to read. Let me be your guide throughout the entire booklet.  It is financial health you are looking for
and I sure know how you can get it. So, follow my instructions.  



MAKE MONEY WITH THE
BANK’S MONEY



During a 6-month period you will be able to deposit 50,000 dollars in your
personal bank accounts, without doing anything at all!  Let me elaborate just a little.  “You do not do anything physical to bring
in this kind of money!”  The bank
does all the work for you at your convenience, and as long as you keep your
account “open” they almost have no choice!  I will show you how to make a minimum of $5,000 a month by
just opening a bank account.  But
that is just the tip of the iceberg!  By
opening a bank account, I will teach you how to have that kind of money
deposited into your bank account Automatically, though a built-in
automatic process that I will personally show you.  That is the beauty of the $ecret Banking $ystem!  Imagine making $5,000 a month for each bank
account you “open”.  And aside from
opening the account, it does not cost you anything!  Just one bank account can make you financially independent for
life! 



Now Think Big.  Think of the same idea
on a slight larger scale, like two or three bank accounts working at the same
time each producing a guaranteed monthly income of $5,000 each.  As of today, I have 13 active account
@$5,000 = $65,000 per month, every month, 12 months a year.  I assure you, there is no print error.  I said 65 thousand dollars per month! 



In summary this is how the formula works: 
YOU walk into a bank, open a bank account, follow the instructions like
a recipe in a cookbook, and 30 days later you will make $5,000.  And one of the most amazing realities of the
$ecret Banking $ystem is that you can begin with literally $0, zero money.  In the $ecret Banking $ystem manual, in an
easy to duplicate as a set of “blueprints”, you will find out for yourself
where all the money comes from and how it is added up for you.



I realize
what I am originating to you may sound impossible, but I promise you, it is
possible, doable and simple.  There is
not shortage of money, the Federal Reserve Board creates money daily but most
of it must pass through and circulate in the banks over and over again.  That is how banks run.  That is where this Ingenious $ecret Banking
$ystem comes in.  All you need is the $ecret
Banking $ystem manual to start making big money.  Send
a $49US Payment on International Money Order, Cash or Personal Cheque (checks
must clear at the bank B4 materials are send.) 



IF YOU ORDER TODAY WE SHALL ADD AT NO EXTRA COST TO YOU, THE
FAMOUS e-Books:



1)    
E-BOOK
SUCCESS ON THE NET



2)    
E-BOOK 101
HIGH PROFIT BUSINESS



3)    
TEN STEPS
TO SUCCESS



4)    
1000
HOW-TO BOOKS



5)    
THE $ECRET
BANKING $YSTEM 



All Moreir 



970 Queen
St. E. #98165



Toronto, Ontario, Canada



M4M 1J0



___________



ORDER FORM



 



Name          ________________________________________________



Address       ______________________________________________



City   _____________________        State_________   Zip_____-________



Fax    (_____) _____-______



E-mail address      _________________________________________



Send me the $ecret Banking $ystem right now,
please.  Here is the $49US. Postal Money Order must be INTERNATIONAL



Write legible please



________ Check here if you
would like to receive this information by e-mail as an attachment and save the $5.00 shipping and handling fee, which is the fastest service;
if not please add $5US for S&H. 



 



IF YOU ORDER TODAY WE SHALL ADD AT NO EXTRA COST TO YOU, THE
FAMOUS e-Books:



1.)    E-BOOK SUCCESS ON THE NET



2.)    E-BOOK 101 HIGH PROFIT
BUSINESS



3.)    TEN STEPS TO SUCCESS



4.)   1000 HOW-TO BOOKS



5.)   THE $ECRET BANKING $YSTEM



If you realize that you are on this list
in error or have changed your mind or if you do not want this type of
information, please reply to this e-mail with "REMOVE" in the subject
field and you will be removed immediately! I apologize for any mistake, intrusion
or inconvenience, if any.  Under Bill
1618 Title 111 passed by the 105th U.S. Congress, this message can not be
considered SPAM as long as we include a way for it to be removed from future
mailings



 Foundations of Wealth



If you wish to learn more……please read on



A few years ago I believed that I really had to work hard to make money. I
thought that the more I worked, the more money I was going to make. But after a
while I realized that I was not getting anywhere. I was working like a slave
and I was not seeing any satisfactory results. I wondered why I wasn't because
I sure was applying the time and the effort. 



I realized that I needed to make a change. For months I tried to find that
special answer that I needed. I tried different things, but none of them worked.
I was lost. Finally, I was ready to give up my dreams and continue living that
ordinary life that I was used to living. You know, that wake up, go to work,
come home, have dinner, and go to bed sort of life. That kind of life that I am
very sure you are used to living. But no! I had to give it one more chance. I
could not quit that easily. So, an idea came to my mind and I decided: "If
I want to be become extremely wealthy, why don't I study people who already are
extremely wealthy and interpret what they are doing?" So that is what I
did. After a few months, I realized that the majority of the extremely wealthy
people did not work that hard. Also, the majority of them not only had enough
money to buy another planet, but they also had the time and the freedom to
enjoy it. That is what I consider true wealth, and that is exactly what $ecret
Banking $ystem is all about. The ability to have free time and be able to do
what you choose, when you choose it. I think that is where the majority of the
people get confused on the definition of wealth. Wealth is not just money.
Wealth is also the ability to spend it the way you choose to do, when you want
to do so.



Having accomplished my goals, my purpose now is to help those that are in
the situation I was in; my purpose is to turn you into a "true"
wealthy person; I want you to have great amounts of money, and great amounts of
free time to enjoy it. Now, the first step to accomplish this is the one that a
lot of people do not pay that much attention to, yet it is one of the most
important aspects of true wealth. I am talking about the mental aspect of true
wealth. Hang on!  I know you are tired
of listening the same psychology song over and over. Do not worry!  The mental aspect of true wealth is actually
very simple and easy to apply. It is actually like a list of steps that you
have to "get into your mind" before we really get into the
"secrets" of making money with the bank’s money that I have been
talking about so much. Once you know all these steps and are ready to apply
them, then you will really be ready to start the journey.



Please! Do not jump this section thinking that you do not need any mental
preparation. It is very important! Remember, follow my instructions and you
could be sitting on gold in just days.



Do you remember the three "keys" to success that I explained on
the web site? If you forgot, the three "keys" to success are:



    
 
  1. Timing: Being at the right place at
     the right time. 
    2. 
 
  2. Having Vision: Seeing potential in
     what is being presented. Having the ability to see success. 
    3. 
 
  3. Taking Action: Going one step
     further than the rest. Doing instead of saying.
    4. 




These
three "keys" are essential to recognize success, and to make it a
part of your life. Now, once you have made the decision to "Take
Action," your next task is to follow what I call "The Ten Steps To
Success." As I said before, they are very simple, but extremely important
if your purpose is to achieve true wealth. I would happily give them to you as
part of the Training I provide when you obtain the $ecret Banking $ystem.  Get your copy today!



If you realize that you are on this list in error or have
changed your mind or if you do not want this type of information, please reply
to this e-mail with "REMOVE" in the subject field and you will be
removed immediately! I apologize for any mistake, intrusion or inconvenience,
if any.  Under Bill 1618 Title 111
passed by the 105th U.S. Congress, this message can not be considered SPAM as
long as we include a way for it to be removed from future mailings



 



 



 



 



 



 



 










--75ImAu-FoiMD1--




From rem-conf Thu Mar 22 22:48:25 2001 
From rem-conf-request@es.net Thu Mar 22 22:48:25 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gLID-0003Tz-00; Thu, 22 Mar 2001 22:43:25 -0800
Received: from netsys.kaist.ac.kr [143.248.148.90] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gLI6-0003Tp-00; Thu, 22 Mar 2001 22:43:18 -0800
Received: from public (netsys13.kaist.ac.kr [143.248.148.93])
	by netsys.kaist.ac.kr (8.11.0/8.11.0) with SMTP id f2NNY6v17247;
	Fri, 23 Mar 2001 14:34:06 -0900
Message-ID: <000901c0b35a$e7700280$5d94f88f@public>
From: "PV2001" 
To: , ,
   , ,
   , 
Subject: PV2001 Call for Participation & Advance Program
Date: Fri, 23 Mar 2001 14:34:17 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0005_01C0B3A6.573C3340"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C0B3A6.573C3340
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C0B3A6.573C3340"


------=_NextPart_001_0006_01C0B3A6.573C3340
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: base64

Q0FMTCBGT1IgUEFSVElDSVBBVElPTg0KDQpQbGVhc2UgbWFyayB5b3VyIGNhbGVuZGFyIHRvIGF0
dGVuZCB0aGUgUFYtMjAwMQ0KZm9yIGEgcmV3YXJkaW5nIGV4cGVyaWVuY2UgDQppbiB0aGUgZmll
bGQgb2YgIkFkdmFuY2VkIFBhY2tldCBWaWRlb5QNClRoZSAxMXRoIEludGVybmF0aW9uYWwgUGFj
a2V0IFZpZGVvIFdvcmtzaG9wIChQVi0yMDAxKSB3aWxsIGJlIGhlbGQgb24gMzAgQXByaWwgLSAx
IE1heSAyMDAxIGluIEt5b25nanUsIEtvcmVhIChsb2NhdGVkIGluIDM1MC1raWxvbWV0ZXIgc291
dGhlYXN0IG9mIFNlb3VsKSwgd2hpY2ggd2FzIHRoZSBjYXBpdGFsIGNpdHkgb2YgYW5jaWVudCBL
b3JlYSAoQS5EIDY3Ni1BLkQgOTM1KS4gVGhlIHdvcmtzaG9wIGlzIGRldm90ZWQgdG8gcHJlc2Vu
dGluZyB0ZWNobm9sb2dpY2FsIGFkdmFuY2VtZW50cyBhbmQgaW5ub3ZhdGlvbnMgaW4gdmlkZW8g
dHJhbnNtaXNzaW9uIG92ZXIgcGFja2V0IG5ldHdvcmtzLCBpbiBwYXJ0aWN1bGFyLCB0aGUgSW50
ZXJuZXQuIFBhY2tldCBWaWRlbyBXb3Jrc2hvcHMgaGF2ZSBiZWVuIHVuaXF1ZSBpbiBwcm92aWRp
bmcgYSBjb21tb24gZ3JvdW5kIGZvciBwZW9wbGUgZnJvbSB2aWRlbyBjb2RpbmcgYW5kIG5ldHdv
cmtpbmcgZmllbGRzLiBQcmVzZW50YXRpb25zIG9uIHRoZW9yeSBhbmQgcHJhY3RpY2UsIHN0YW5k
YXJkcyBhY3Rpdml0aWVzLCBhbmQgYnVzaW5lc3MgYW5kIGNvbnN1bWVyIGFwcGxpY2F0aW9ucyBh
cmUgZW5jb3VyYWdlZC4gSW4gMjAwMSwgdGhlIHdvcmtzaG9wIGlzIHNjaGVkdWxlZCB0byB0YWtl
IHBsYWNlIGluIHRoZSB3ZWVrIGZvbGxvd2luZyBQaWN0dXJlIENvZGluZyBTeW1wb3NpdW0gKFBD
Uy0yMDAxKSB3aGljaCB3aWxsIGJlIGhlbGQgaW4gU2VvdWwgb24gMjUtMjcgQXByaWwgMjAwMS4g
V2UgY29yZGlhbGx5IGludml0ZSB5b3UgdG8gdGFrZSBwYXJ0IGluIHRoaXMgd29ya3Nob3AuIEZ1
cnRoZXIgZGV0YWlscyBhbmQgdXBkYXRlZCBpbmZvcm1hdGlvbiBmb3IgUFYtMjAwMSBjYW4gYmUg
Zm91bmQgYXQgaHR0cDovL3B2MjAwMS5rYWlzdC5hYy5rci4NCg0KV2l0aCBicm9hZCBhbmQgYWN0
aXZlIHBhcnRpY2lwYXRpb25zIGZyb20gYWxsIG92ZXIgdGhlIHdvcmxkLCB3ZSBhcmUgY29udmlu
Y2VkIHRoYXQgdGhlIFBWLTIwMDEgd2lsbCBiZSB2ZXJ5IHN1Y2Nlc3NmdWwuIA0KUHJvZ3JhbSBP
dmVydmlldzoNCg0KVGhlIHNlc3Npb24gcHJvZ3JhbSB3aWxsIGhhdmUgOCBzZXNzaW9ucyB3aXRo
IDU2IHBhcGVycyBmcm9tIDE2IGNvdW50cmllcy4gVGhpcyB3aWxsIGJlIGZ1cnRoZXIgaGlnaGxp
Z2h0ZWQgYnkgdHdvIGludml0ZWQgdGFsa3MgYW5kIG9uZSBwYW5lbCBkaXNjdXNzaW9uLiBUaGUg
MjMgcGFwZXJzIHdpbGwgYmUgcHJlc2VudGVkIGJ5IG9yYWwgcHJlc2VudGF0aW9uIGFuZCB0aGUg
b3RoZXIgcGFwZXJzIHdpbGwgYmUgcHJlc2VudGVkIGJ5IHBvc3RlciBwcmVzZW50YXRpb24uDQoN
ClRvcGljIEFyZWFzOiAgDQoNCiAgICAgIC0gVmlkZW8gc3RyZWFtaW5nIG92ZXIgSW50ZXJuZXQg
IA0KICAgICAgLSBOZXR3b3JrIGFkYXB0aXZlIHZpZGVvIGNvZGluZyBhbmQgdHJhbnNwb3J0ICAN
CiAgICAgIC0gRXJyb3IvbG9zcyByZXNpbGllbnQgdmlkZW8gY29kaW5nIGFuZCB0cmFuc3BvcnQg
IA0KICAgICAgLSBMYXllcmVkIGNvZGluZyBmb3IgZXJyb3IgcmVzaWxpZW5jZSBhbmQgaGV0ZXJv
Z2VuZW91cyBuZXR3b3JrcyAgDQogICAgICAtIFJhdGUgY29udHJvbCBmb3IgVkJSIHZpZGVvICAN
CiAgICAgIC0gU3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nIGZvciBncmVhdGVyIG5ldHdvcmsgYW5k
IHRlcm1pbmFsIHV0aWxpemF0aW9uICANCiAgICAgIC0gQ29uZ2VzdGlvbiBjb250cm9sIGFuZCBi
YW5kd2lkdGggYWxsb2NhdGlvbiAgDQogICAgICAtIEVmZmljaWVudCB0cmFuc2NvZGluZyBmb3Ig
aGV0ZXJvZ2VuZW91cyBuZXR3b3JrcyAgDQogICAgICAtIEVycm9yIGNvbmNlYWxtZW50IGFuZCBw
b3N0IHByb2Nlc3NpbmcgIA0KICAgICAgLSBUcmFmZmljIHNoYXBpbmcgZm9yIGVmZmljaWVudCBu
ZXR3b3JrIGFuZCB0ZXJtaW5hbCB1dGlsaXphdGlvbiAgDQogICAgICAtIFBlcmZvcm1hbmNlIG1v
ZGVsaW5nIGFuZCBldmFsdWF0aW9uIGZvciBwYWNrZXQgdmlkZW8gbmV0d29yayAgDQogICAgICAt
IEludGVyc3RyZWFtIHN5bmNocm9uaXphdGlvbiBmb3IgbXVsdGlwbGUgdmlkZW8gcHJlc2VudGF0
aW9ucyAgDQogICAgICAtIFBhY2tldGl6ZWQgdmlkZW8gZm9yIHdpcmVsZXNzL21vYmlsZSBzeXN0
ZW1zICANCiAgICAgIC0gUGFja2V0aXplZCB2aWRlbyBmb3IgaG9tZSBMQU4ncyAgDQogICAgICAt
IE11bHRpY2FzdGluZywgTUJPTkUgYXBwbGljYXRpb25zICANCiAgICAgIC0gSW50ZXJuYXRpb25h
bCBzdGFuZGFyZHM6IE1QRUctNCwgTVBFRy03LCBILjI2TCwgSC4zMjMsIFJUUCwgUlRTUCwgU0lQ
LCBTRFAgIA0KICAgICAgLSBUZXJtaW5hbCBhbmQgc2VydmVyIGFyY2hpdGVjdHVyZSBmb3IgSW50
ZXJuZXQgVFYgIA0KICAgICAgLSBJbXBsZW1lbnRhdGlvbnMgYW5kIGNvbW1lcmNpYWwgYXBwbGlj
YXRpb25zICANCg0KSW52aXRlZCBTcGVha2VyczoNCg0KDQogICAgICAtIERyLiBZYS1RaW4gWmhh
bmcsIE1pY3Jvc29mdCBSZXNlYXJjaCBpbiBCZWlqaW5nLCBDaGluYQ0KICAgICAgICAiQ29udmVy
Z2VuY2Ugb2YgTXVsdGltZWRpYSwgV2lyZWxlc3MgYW5kIEludGVybmV0lA0KICAgICANCiAgICAg
IC0gRHIuIENpdmFubGFyIE0uIFJlaGEsIEFUJlQgTGFicyBSZXNlYXJjaCwgVS5TLkEuDQogICAg
ICAgICJJbnRlcm5ldCBWaWRlbyAtIFByb3RvY29scyAmIEFwcGxpY2F0aW9uc5QNCiAgICAgDQoN
ClJlZ2lzdHJhdGlvbiBJbmZvcm1hdGlvbjoNCg0KICAgICAgQ2F0ZWdvcnkNCiAgICAgQnkgTWFy
Y2ggMzEsIDIwMDENCiAgICAgQWZ0ZXIgTWFyY2ggMzEsIDIwMDENCiAgICAgDQogICAgICBSZWd1
bGFyIFJlZ2lzdHJhdGlvbg0KICAgICBQbGFuIDENCiAgICAgVVMkMzAwDQogICAgIFVTJDM1MA0K
ICAgICANCiAgICAgIFBsYW4gMg0KICAgICBVUyQyMjUNCiAgICAgVVMkMjc1DQogICAgIA0KICAg
ICAgQmFucXVldCBmb3IgQWNjb21wYW55aW5nIFBlcnNvbg0KICAgICBVUyQ2MC9lYWNoDQogICAg
IA0KICAgICAgQWRkaXRpb25hbCBDRC1ST00gUHJvY2VlZGluZ3MNCiAgICAgVVMkNTAvZWFjaA0K
ICAgICANCiAgICAgIFNwZWNpYWwgQnVzIFRyYW5zcG9ydGF0aW9uIChmcm9tIFNlb3VsIHRvIEt5
b25nanUpICBVUyQ4MC9lYWNoDQogICAgIA0KICAgICAgUFYgYW5kIFBDUy0yMDAxIFJlZ2lzdHJh
dGlvbiAgQnkgTWFyY2ggMzEsIDIwMDENCiAgICAgQWZ0ZXIgTWFyY2ggMzEsIDIwMDENCiAgICAg
DQogICAgICBSZWd1bGFyIFJlZ2lzdHJhdGlvbg0KICAgICBQbGFuIDM6IFBDUyBSZWd1bGFyK1BW
IFBsYW4gMSAgVVMkNjUwDQogICAgIFVTJDc1MA0KICAgICANCiAgICAgIFN0dWRlbnQgUmVnaXN0
cmF0aW9uDQogICAgIFBsYW4gNDogUENTIFBsYW4gQStQViBQbGFuIDIgIFVTJDQ1MA0KICAgICBV
UyQ1NTANCiAgICAgDQogICAgICBQbGFuIDU6IFBDUyBQbGFuIEIrUFYgUGxhbiAyICBVUyQzOTAN
CiAgICAgVVMkNDkwDQogICAgIA0KDQpJbXBvcnRhbnQgRGF0ZTogICAgICBNYXJjaCAzMSwgMjAw
MSAgICAgICAgQWR2YW5jZSBSZWdpc3RyYXRpb24gJiBIb3RlbCBSZXNlcnZhdGlvbg0KDQpQQ1Mt
MjAwMSBTZWNyZXRhcmlhdDogDQpGdXJ0aGVyIGlucXVpcmllcyBjYW4gYmUgbWFkZSBhdDoNClRl
bDogKzgyLTQyLTQ3Mi03NDYwICAgICAgICAgICAgRmF4OiArODItNDItNDcyLTc0NTkgICAgICAg
ICAgICAgIEVtYWlsOiBwdkBwdjIwMDEua2Fpc3QuYWMua3INCg0K

------=_NextPart_001_0006_01C0B3A6.573C3340
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp
bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hU
TUwgNS4wMC4zMDE4LjkwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB
RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1
NDg7IHNpemU9Mj4NCjxIMiBhbGlnbj1jZW50ZXIgDQpzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsg
TUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtQUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBweCI+
PFNQQU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsIEJsYWNrJzsgRk9O
VC1TSVpFOiAxNnB0Ij48Rk9OVCBjb2xvcj1ncmVlbiANCmZhY2U9VmVyZGFuYT5DQUxMIEZPUiBQ
QVJUSUNJUEFUSU9OPC9TUEFOPjxCIA0Kc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBub3Jt
YWwiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCBCbGFjayci
PjxCUj48L0ZPTlQ+PC9TUEFOPjwvQj48L0gyPg0KPEg2IGFsaWduPWNlbnRlciANCnN0eWxlPSJU
RVhULUFMSUdOOiBjZW50ZXI7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tbGluZS1oZWlnaHQt
cnVsZTogZXhhY3RseSI+PFNQQU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZP
TlQtU0laRTogMTNwdCI+PEZPTlQgY29sb3I9IzY2NjZmZiANCmZhY2U9QXJpYWw+PEI+UGxlYXNl
IG1hcmsgeW91ciBjYWxlbmRhciB0byBhdHRlbmQgdGhlIDwvRk9OVD48Rk9OVCBjb2xvcj0jY2Mw
MDAwIA0KZmFjZT1BcmlhbD5QVi0yMDAxPC9GT05UPjxGT05UIGNvbG9yPSM2NjY2ZmYgZmFjZT1B
cmlhbD48QlI+Zm9yIGEgcmV3YXJkaW5nIA0KZXhwZXJpZW5jZSA8QlI+aW4gdGhlIGZpZWxkIG9m
ICJBZHZhbmNlZCBQYWNrZXQgVmlkZW+UPC9CPjwvU1BBTj48L0ZPTlQ+PC9INj4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTEFZT1VULUdSSUQtTU9ERTogY2hhciI+PFNQQU4gbGFuZz1FTi1V
UyANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48
Rk9OVCBmYWNlPUFyaWFsPlRoZSANCjExPFNVUD50aDwvU1VQPiBJbnRlcm5hdGlvbmFsIFBhY2tl
dCBWaWRlbyBXb3Jrc2hvcCAoUFYtMjAwMSkgd2lsbCBiZSBoZWxkIG9uIDMwIA0KQXByaWwgLSAx
IE1heSAyMDAxIGluIEt5b25nanUsIEtvcmVhIChsb2NhdGVkIGluIDM1MC1raWxvbWV0ZXIgc291
dGhlYXN0IG9mIA0KU2VvdWwpLCB3aGljaCB3YXMgdGhlIGNhcGl0YWwgY2l0eSBvZiBhbmNpZW50
IEtvcmVhIChBLkQgNjc2LUEuRCA5MzUpLiBUaGUgDQp3b3Jrc2hvcCBpcyBkZXZvdGVkIHRvIHBy
ZXNlbnRpbmcgdGVjaG5vbG9naWNhbCBhZHZhbmNlbWVudHMgYW5kIGlubm92YXRpb25zIGluIA0K
dmlkZW8gdHJhbnNtaXNzaW9uIG92ZXIgcGFja2V0IG5ldHdvcmtzLCBpbiBwYXJ0aWN1bGFyLCB0
aGUgSW50ZXJuZXQuIFBhY2tldCANClZpZGVvIFdvcmtzaG9wcyBoYXZlIGJlZW4gdW5pcXVlIGlu
IHByb3ZpZGluZyBhIGNvbW1vbiBncm91bmQgZm9yIHBlb3BsZSBmcm9tIA0KdmlkZW8gY29kaW5n
IGFuZCBuZXR3b3JraW5nIGZpZWxkcy4gUHJlc2VudGF0aW9ucyBvbiB0aGVvcnkgYW5kIHByYWN0
aWNlLCANCnN0YW5kYXJkcyBhY3Rpdml0aWVzLCBhbmQgYnVzaW5lc3MgYW5kIGNvbnN1bWVyIGFw
cGxpY2F0aW9ucyBhcmUgZW5jb3VyYWdlZC4gSW4gDQoyMDAxLCB0aGUgd29ya3Nob3AgaXMgc2No
ZWR1bGVkIHRvIHRha2UgcGxhY2UgaW4gdGhlIHdlZWsgZm9sbG93aW5nIFBpY3R1cmUgDQpDb2Rp
bmcgU3ltcG9zaXVtIChQQ1MtMjAwMSkgd2hpY2ggd2lsbCBiZSBoZWxkIGluIFNlb3VsIG9uIDI1
LTI3IEFwcmlsIDIwMDEuIFdlIA0KY29yZGlhbGx5IGludml0ZSB5b3UgdG8gdGFrZSBwYXJ0IGlu
IHRoaXMgd29ya3Nob3AuIEZ1cnRoZXIgZGV0YWlscyBhbmQgdXBkYXRlZCANCmluZm9ybWF0aW9u
IGZvciBQVi0yMDAxIGNhbiBiZSBmb3VuZCBhdCA8QSANCmhyZWY9Imh0dHA6Ly9wdjIwMDEua2Fp
c3QuYWMua3IvIj5odHRwOi8vcHYyMDAxLmthaXN0LmFjLmtyPC9BPi48L1NQQU4+PC9GT05UPjwv
UD48U1BBTiANCmxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFy
ZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJu
aW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn
ZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQpmYWNlPUFyaWFsPldpdGgg
YnJvYWQgYW5kIGFjdGl2ZSBwYXJ0aWNpcGF0aW9ucyBmcm9tIGFsbCBvdmVyIHRoZSB3b3JsZCwg
d2UgYXJlIA0KY29udmluY2VkIHRoYXQgdGhlIFBWLTIwMDEgd2lsbCBiZSB2ZXJ5IHN1Y2Nlc3Nm
dWwuPC9GT05UPjwvU1BBTj4gDQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOLUxF
RlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6
IGtlZXAtYWxsOyBtc28tbGluZS1oZWlnaHQtcnVsZTogZXhhY3RseSI+PEI+PEIgDQpzdHlsZT0i
bXNvLWJpZGktZm9udC13ZWlnaHQ6IG5vcm1hbCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJC
QUNLR1JPVU5ELUNPTE9SOiByZ2IoMjE3LDIxNywyMTcpOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1z
aGFkaW5nOiB3aGl0ZTsgbXNvLXBhdHRlcm46IGdyYXktMTUgYXV0byI+PEZPTlQgDQpmYWNlPUFy
aWFsPlByb2dyYW0gT3ZlcnZpZXc6PC9CPjwvRk9OVD48L1NQQU4+PC9CPjwvUD4NCjxQIGNsYXNz
PU1zb0hlYWRlciANCnN0eWxlPSJMQVlPVVQtR1JJRC1NT0RFOiBib3RoOyBNQVJHSU4tTEVGVDog
MHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1JTkRFTlQ6IDBweDsgV09SRC1CUkVBSzoga2Vl
cC1hbGw7IG1zby1saW5lLWhlaWdodC1ydWxlOiBleGFjdGx5OyB0YWItc3RvcHM6IDQwLjBwdCI+
PFNQQU4gDQpsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFu
JzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2Vybmlu
ZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1BcmlhbD5UaGUgc2Vz
c2lvbiBwcm9ncmFtIHdpbGwgaGF2ZSA4IHNlc3Npb25zIHdpdGggNTYgcGFwZXJzIGZyb20gMTYg
DQpjb3VudHJpZXMuIFRoaXMgd2lsbCBiZSBmdXJ0aGVyIGhpZ2hsaWdodGVkIGJ5IHR3byBpbnZp
dGVkIHRhbGtzIGFuZCBvbmUgcGFuZWwgDQpkaXNjdXNzaW9uLiBUaGUgMjMgcGFwZXJzIHdpbGwg
YmUgcHJlc2VudGVkIGJ5IG9yYWwgcHJlc2VudGF0aW9uIGFuZCB0aGUgb3RoZXIgDQpwYXBlcnMg
d2lsbCBiZSBwcmVzZW50ZWQgYnkgcG9zdGVyIHByZXNlbnRhdGlvbjwvRk9OVD48L1NQQU4+PFNQ
QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZP
TlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2VybmluZzogMS4w
cHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBt
c28tYmlkaS1sYW5ndWFnZTogQVItU0EiPi48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs
IA0Kc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUlOREVO
VDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgbXNvLWxpbmUtaGVpZ2h0LXJ1bGU6IGV4YWN0
bHkiPjxCPjxCIA0Kc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBub3JtYWwiPjxTUEFOIGxh
bmc9RU4tVVMgDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogcmdiKDIxNywyMTcsMjE3KTsgRk9O
VC1TSVpFOiAxMHB0OyBtc28tc2hhZGluZzogd2hpdGU7IG1zby1wYXR0ZXJuOiBncmF5LTE1IGF1
dG8iPjxGT05UIA0KZmFjZT1BcmlhbD5Ub3BpYyBBcmVhczo8L0I+PC9TUEFOPjxTUEFOIGxhbmc9
RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBw
dCI+IA0KJm5ic3A7PC9CPjwvRk9OVD48L1NQQU4+PC9QPg0KPFRBQkxFIGJvcmRlcj0wPg0KICA8
VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxTUEFOIGxhbmc9RU4tVVMgDQogICAg
ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7
IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0
ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2kt
bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1
YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPi0gVmlkZW8gc3RyZWFtaW5nIG92
ZXIgSW50ZXJuZXQ8L0ZPTlQ+PC9TUEFOPiA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lk
dGg9NTE0PjxTUEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l
cyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0
OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28t
Zm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz
dC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBm
YWNlPUFyaWFsPi0gTmV0d29yayBhZGFwdGl2ZSB2aWRlbyBjb2RpbmcgYW5kIHRyYW5zcG9ydDwv
Rk9OVD48L1NQQU4+IA0KICA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxT
UEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFy
ZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJu
aW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn
ZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFs
Pi0gRXJyb3IvbG9zcyByZXNpbGllbnQgdmlkZW8gY29kaW5nIGFuZCB0cmFuc3BvcnQ8L0ZPTlQ+
PC9TUEFOPiANCiAgICA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxTUEFO
IGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n
OyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFz
dC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5n
OiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog
S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPi0g
TGF5ZXJlZCBjb2RpbmcgZm9yIGVycm9yIHJlc2lsaWVuY2UgYW5kIGhldGVyb2dlbmVvdXMgDQog
ICAgICBuZXR3b3JrczwvRk9OVD48L1NQQU4+IDwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3
aWR0aD01MTQ+PFNQQU4gbGFuZz1FTi1VUyANCiAgICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp
bWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w
cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1z
by1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl
YXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAg
IGZhY2U9QXJpYWw+LSBSYXRlIGNvbnRyb2wgZm9yIFZCUiB2aWRlbzwvRk9OVD48L1NQQU4+IDwv
VEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+PFNQQU4gbGFuZz1FTi1VUyANCiAg
ICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBw
dDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm
IzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFu
Z3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+LSBTdGF0aXN0aWNhbCBtdWx0
aXBsZXhpbmcgZm9yIGdyZWF0ZXIgbmV0d29yayBhbmQgdGVybWluYWwgDQogICAgICB1dGlsaXph
dGlvbiA8L0ZPTlQ+PC9TUEFOPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+
PFNQQU4gbGFuZz1FTi1VUyANCiAgICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS
b21hbic7IEZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtl
cm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1
YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJp
YWw+LSBDb25nZXN0aW9uIGNvbnRyb2wgYW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9uPC9GT05UPjwv
U1BBTj4gDQogIDwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+PFNQQU4gbGFu
Zz1FTi1VUyANCiAgICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZP
TlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtlcm5pbmc6IDEu
MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg
bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+LSBFZmZp
Y2llbnQgdHJhbnNjb2RpbmcgZm9yIGhldGVyb2dlbmVvdXMgDQogICAgICBuZXR3b3JrczwvRk9O
VD48L1NQQU4+IDwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+PFNQQU4gbGFu
Zz1FTi1VUyANCiAgICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZP
TlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtlcm5pbmc6IDEu
MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg
bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+LSBFcnJv
ciBjb25jZWFsbWVudCBhbmQgcG9zdCBwcm9jZXNzaW5nPC9GT05UPjwvU1BBTj4gPC9URD48L1RS
Pg0KICA8VFI+DQogICAgPFREIHdpZHRoPTUxND48U1BBTiBsYW5nPUVOLVVTIA0KICAgICAgc3R5
bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7
JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1
YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTog
QVItU0EiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbD4tIFRyYWZmaWMgc2hhcGluZyBmb3IgZWZm
aWNpZW50IG5ldHdvcmsgYW5kIHRlcm1pbmFsIA0KICAgICAgdXRpbGl6YXRpb248L0ZPTlQ+PC9T
UEFOPiA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxTUEFOIGxhbmc9RU4t
VVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJ
WkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZh
bWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsg
bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1i
aWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPi0gUGVyZm9ybWFu
Y2UgbW9kZWxpbmcgYW5kIGV2YWx1YXRpb24gZm9yIHBhY2tldCB2aWRlbyANCiAgICAgIG5ldHdv
cms8L0ZPTlQ+PC9TUEFOPiA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxT
UEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFy
ZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJu
aW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn
ZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFs
Pi0gSW50ZXJzdHJlYW0gc3luY2hyb25pemF0aW9uIGZvciBtdWx0aXBsZSB2aWRlbyANCiAgICAg
IHByZXNlbnRhdGlvbnM8L0ZPTlQ+PC9TUEFOPiA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQg
d2lkdGg9NTE0PjxTUEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU
aW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAu
MHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBt
c28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFy
ZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAg
ICBmYWNlPUFyaWFsPi0gUGFja2V0aXplZCB2aWRlbyBmb3Igd2lyZWxlc3MvbW9iaWxlIHN5c3Rl
bXM8L0ZPTlQ+PC9TUEFOPiANCiAgPC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIHdpZHRoPTUx
ND48U1BBTiBsYW5nPUVOLVVTIA0KICAgICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3
IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQt
a2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KICAgICAgZmFjZT1B
cmlhbD4tIFBhY2tldGl6ZWQgdmlkZW8gZm9yIGhvbWUgTEFOJ3M8L0ZPTlQ+PC9TUEFOPiA8L1RE
PjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NTE0PjxTUEFOIGxhbmc9RU4tVVMgDQogICAg
ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7
IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0
ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2kt
bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1
YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPi0gTXVsdGljYXN0aW5nLCBNQk9O
RSBhcHBsaWNhdGlvbnM8L0ZPTlQ+PC9TUEFOPiA8L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQg
d2lkdGg9NTE0PjxTUEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU
aW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAu
MHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBt
c28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFy
ZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAg
ICBmYWNlPUFyaWFsPi0gSW50ZXJuYXRpb25hbCBzdGFuZGFyZHM6IE1QRUctNCwgTVBFRy03LCBI
LjI2TCwgSC4zMjMsIFJUUCwgDQogICAgICBSVFNQLCBTSVAsIFNEUDwvRk9OVD48L1NQQU4+IDwv
VEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+PFNQQU4gbGFuZz1FTi1VUyANCiAg
ICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBw
dDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm
IzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFu
Z3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+LSBUZXJtaW5hbCBhbmQgc2Vy
dmVyIGFyY2hpdGVjdHVyZSBmb3IgSW50ZXJuZXQgDQogICAgICBUVjwvRk9OVD48L1NQQU4+IDwv
VEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+PFNQQU4gbGFuZz1FTi1VUyANCiAg
ICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTBw
dDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm
IzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5z
aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFu
Z3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+LSBJbXBsZW1lbnRhdGlvbnMg
YW5kIGNvbW1lcmNpYWwgYXBwbGljYXRpb25zIA0KICA8L0ZPTlQ+PC9TUEFOPjwvVEQ+PC9UUj48
L1RCT0RZPjwvVEFCTEU+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOLUxFRlQ6
IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtl
ZXAtYWxsOyBtc28tbGluZS1oZWlnaHQtcnVsZTogZXhhY3RseSI+PEI+PEIgDQpzdHlsZT0ibXNv
LWJpZGktZm9udC13ZWlnaHQ6IG5vcm1hbCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJCQUNL
R1JPVU5ELUNPTE9SOiByZ2IoMjE3LDIxNywyMTcpOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1zaGFk
aW5nOiB3aGl0ZTsgbXNvLXBhdHRlcm46IGdyYXktMTUgYXV0byI+PEZPTlQgDQpmYWNlPUFyaWFs
Pkludml0ZWQgU3BlYWtlcnM6PEJSPjwvQj48L0ZPTlQ+PC9TUEFOPjwvQj48L1A+DQo8VEFCTEUg
Ym9yZGVyPTA+DQogIDxUQk9EWT4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD01MTQ+DQogICAgICA8
UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lO
LVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHgiPjxTUEFOIA0KICAgICAgbGFuZz1FTi1VUyBz
dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEIgDQog
ICAgICBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6IG5vcm1hbCI+PEZPTlQgZmFjZT1Bcmlh
bD4tIERyLiBZYS1RaW4gDQogICAgICBaaGFuZzwvQj4sIE1pY3Jvc29mdCBSZXNlYXJjaCBpbiBC
ZWlqaW5nLCBDaGluYTwvU1BBTj48Qj48U1BBTiBsYW5nPUVOLVVTIA0KICAgICAgc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0IiAmIzk1Nju4v28/
IA0KICAgICAgbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWls
eTogDQogICAgICBmb250LXNpemU6MTBwdDs+PEJSPiZuYnNwOyZuYnNwOzwvQj4iPC9TUEFOPjxT
UEFOIGxhbmc9RU4tVVMgDQogICAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFy
ZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJu
aW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn
ZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFs
PkNvbnZlcmdlbmNlIG9mIE11bHRpbWVkaWEsIFdpcmVsZXNzIGFuZCANCiAgICAgIEludGVybmV0
lDwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lk
dGg9NTE0Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1M
RUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUlOREVOVDogMHB4Ij48U1BBTiANCiAg
ICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXpl
OiAxMC4wcHQiPjxCIA0KICAgICAgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBub3JtYWwi
PjxGT05UIGZhY2U9QXJpYWw+LSBEci4gQ2l2YW5sYXIgTS4gDQogICAgICBSZWhhPC9CPiwgQVQm
YW1wO1QgTGFicyBSZXNlYXJjaCwgVS5TLkEuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgDQogICAg
ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEJS
PiZuYnNwOyZuYnNwOzwvU1BBTj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt
U0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPiJJbnRlcm5ldCANCiAgICAg
IFZpZGVvIC0gUHJvdG9jb2xzICZhbXA7IA0KQXBwbGljYXRpb25zlDwvRk9OVD48L1NQQU4+PC9Q
PjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0i
TUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdP
UkQtQlJFQUs6IGtlZXAtYWxsOyBtc28tbGluZS1oZWlnaHQtcnVsZTogZXhhY3RseSI+PEI+PEIg
DQpzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6IG5vcm1hbCI+PFNQQU4gbGFuZz1FTi1VUyAN
CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjE3LDIxNywyMTcpOyBGT05ULVNJWkU6IDEw
cHQ7IG1zby1zaGFkaW5nOiB3aGl0ZTsgbXNvLXBhdHRlcm46IGdyYXktMTUgYXV0byI+PEZPTlQg
DQpmYWNlPUFyaWFsPlJlZ2lzdHJhdGlvbiBJbmZvcm1hdGlvbjo8L0I+PC9GT05UPjwvU1BBTj48
L0I+PC9QPg0KPFRBQkxFIGJvcmRlcj0wIGJvcmRlckNvbG9yPXdoaXRlIGNlbGxQYWRkaW5nPTAg
Y2VsbFNwYWNpbmc9MiANCnN0eWxlPSJCT1JERVItQk9UVE9NLVNUWUxFOiBub25lOyBCT1JERVIt
Q09MTEFQU0U6IGNvbGxhcHNlOyBCT1JERVItTEVGVC1TVFlMRTogbm9uZTsgQk9SREVSLVJJR0hU
LVNUWUxFOiBub25lOyBCT1JERVItVE9QLVNUWUxFOiBub25lOyBNQVJHSU4tTEVGVDogMHB4OyBN
QVJHSU4tUklHSFQ6IDBweDsgVEVYVC1JTkRFTlQ6IDBweDsgbXNvLXRhYmxlLWxheW91dC1hbHQ6
IGZpeGVkOyBtc28tYm9yZGVyLWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0OyBtc28tcGFkZGlu
Zy1hbHQ6IDBjbSA0Ljk1cHQgMGNtIDQuOTVwdCIgDQp3aWR0aD01MjM+DQogIDxUQk9EWT4NCiAg
PFRSIHN0eWxlPSJIRUlHSFQ6IDE0LjJwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5Ij4NCiAg
ICA8VEQgY29sU3Bhbj0yIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDEu
NXB0IGRvdWJsZTsgQk9SREVSLUxFRlQ6IHdpbmRvd3RleHQgMS41cHQgc29saWQ7IEJPUkRFUi1S
SUdIVDogd2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogd2luZG93dGV4dCAxLjVw
dCBzb2xpZDsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVG
VDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRI
OiAyNjBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5IiANCiAgICB3aWR0aD0yNjk+DQogICAg
ICA8UCBhbGlnbj1jZW50ZXIgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1M
RUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5E
RU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMg
c3R5bGU9IkZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQg
DQogICAgICBmYWNlPUFyaWFsPkNhdGVnb3J5PC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8
VEQgDQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMS41cHQgZG91YmxlOyBC
T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAwLjVwdCBz
b2xpZDsgQk9SREVSLVRPUDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgSEVJR0hUOiAxNC4ycHQ7
IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hU
OiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRIOiAxMzVwdDsgbXNvLWhlaWdodC1ydWxl
OiBleGFjdGx5OyBtc28tYm9yZGVyLWxlZnQtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQiIA0K
ICAgIHdpZHRoPTk2Pg0KICAgICAgPFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb05vcm1hbCANCiAg
ICAgIHN0eWxlPSJNQVJHSU4tTEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1BTElH
TjogY2VudGVyOyBURVhULUlOREVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4g
DQogICAgICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1z
aXplOiAxMC4wcHQiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbD5CeSBNYXJjaCAzMSwgMjAwMTwv
U1BBTj48L0ZPTlQ+PC9QPjwvVEQ+DQogICAgPFREIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9N
OiB3aW5kb3d0ZXh0IDEuNXB0IGRvdWJsZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBCT1JE
RVItUklHSFQ6IHdpbmRvd3RleHQgMS41cHQgc29saWQ7IEJPUkRFUi1UT1A6IHdpbmRvd3RleHQg
MS41cHQgc29saWQ7IEhFSUdIVDogMTQuMnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5H
LUxFRlQ6IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBX
SURUSDogMTM1cHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFs
dDogc29saWQgd2luZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD0xMDU+DQogICAgICA8UCBhbGln
bj1jZW50ZXIgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7
IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5ERU5UOiAwcHg7
IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZP
TlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBm
YWNlPUFyaWFsPkFmdGVyIE1hcmNoIDMxLCAyMDAxPC9TUEFOPjwvRk9OVD48L1A+PC9URD48L1RS
Pg0KICA8VFIgc3R5bGU9IkhFSUdIVDogMTQuMnB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHki
Pg0KICAgIDxURCByb3dTcGFuPTIgDQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3Rl
eHQgMC41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JE
RVItUklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25l
OyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1
cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBjbTsgV0lEVEg6IDEwMHB0
OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1ib3JkZXItdG9wLWFsdDogZG91YmxlIHdp
bmRvd3RleHQgMS41cHQiIA0KICAgIHdpZHRoPTYzPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs
IA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhU
LUlOREVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVO
LVVTIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxG
T05UIA0KICAgICAgZmFjZT1BcmlhbD5SZWd1bGFyIFJlZ2lzdHJhdGlvbjwvU1BBTj48L0ZPTlQ+
PC9QPjwvVEQ+DQogICAgPFREIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0
IDAuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2lu
ZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IEhFSUdIVDogMTQu
MnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDQuOTVwdDsgUEFERElORy1S
SUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDogMTYwcHQ7IG1zby1oZWlnaHQt
cnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0
OyBtc28tYm9yZGVyLXRvcC1hbHQ6IGRvdWJsZSB3aW5kb3d0ZXh0IDEuNXB0IiANCiAgICB3aWR0
aD0xOTA+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxF
RlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6
IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogOXB0
OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlBs
YW4gMTwvU1BBTj48L0ZPTlQ+PC9QPjwvVEQ+DQogICAgPFREIA0KICAgIHN0eWxlPSJCT1JERVIt
Qk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7
IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVt
IG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6
IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDog
MTM1cHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29s
aWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9yZGVyLXRvcC1hbHQ6IGRvdWJsZSB3aW5kb3d0ZXh0
IDEuNXB0IiANCiAgICB3aWR0aD05Nj4NCiAgICAgIDxQIGFsaWduPWNlbnRlciBjbGFzcz1Nc29O
b3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7
IFRFWFQtQUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBweDsgV09SRC1CUkVBSzoga2VlcC1h
bGwiPjxTUEFOIA0KICAgICAgbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IG1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+VVMkMzAwPC9T
UEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQgDQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006
IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgQk9SREVS
LVJJR0hUOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsg
SEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNC45NXB0
OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRIOiAxMzVwdDsg
bXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28tYm9yZGVyLWxlZnQtYWx0OiBzb2xpZCB3aW5k
b3d0ZXh0IC41cHQ7IG1zby1ib3JkZXItdG9wLWFsdDogZG91YmxlIHdpbmRvd3RleHQgMS41cHQi
IA0KICAgIHdpZHRoPTEwNT4NCiAgICAgIDxQIGFsaWduPWNlbnRlciBjbGFzcz1Nc29Ob3JtYWwg
DQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQt
QUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBweDsgV09SRC1CUkVBSzoga2VlcC1hbGwiPjxT
UEFOIA0KICAgICAgbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZv
bnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+VVMkMzUwPC9TUEFOPjwv
Rk9OVD48L1A+PC9URD48L1RSPg0KICA8VFIgc3R5bGU9IkhFSUdIVDogMTQuMnB0OyBtc28taGVp
Z2h0LXJ1bGU6IGV4YWN0bHkiPg0KICAgIDxURCANCiAgICBzdHlsZT0iQk9SREVSLUJPVFRPTTog
d2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBCT1JERVIt
UklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBI
RUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7
IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBjbTsgV0lEVEg6IDE2MHB0OyBt
c28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1ib3JkZXItbGVmdC1hbHQ6IHNvbGlkIHdpbmRv
d3RleHQgLjVwdDsgbXNvLWJvcmRlci10b3AtYWx0OiBkb3VibGUgd2luZG93dGV4dCAxLjVwdCIg
DQogICAgd2lkdGg9MTkwPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9
Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUlOREVOVDogMHB4OyBX
T1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVTIHN0eWxlPSJGT05U
LVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIA0KICAgICAgZmFj
ZT1BcmlhbD5QbGFuIDI8L1NQQU4+PC9GT05UPjwvUD48L1REPg0KICAgIDxURCANCiAgICBzdHls
ZT0iQk9SREVSLUJPVFRPTTogd2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLUxFRlQ6IG1l
ZGl1bSBub25lOyBCT1JERVItUklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1U
T1A6IG1lZGl1bSBub25lOyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFE
RElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBj
bTsgV0lEVEg6IDEzNXB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1ib3JkZXItbGVm
dC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdDsgbXNvLWJvcmRlci10b3AtYWx0OiBkb3VibGUg
d2luZG93dGV4dCAxLjVwdCIgDQogICAgd2lkdGg9OTY+DQogICAgICA8UCBhbGlnbj1jZW50ZXIg
Y2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1S
SUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJF
QUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTog
OXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFs
PlVTJDIyNTwvU1BBTj48L0ZPTlQ+PC9QPjwvVEQ+DQogICAgPFREIA0KICAgIHN0eWxlPSJCT1JE
RVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5v
bmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVk
aXVtIG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxF
RlQ6IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURU
SDogMTM1cHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDog
c29saWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9yZGVyLXRvcC1hbHQ6IGRvdWJsZSB3aW5kb3d0
ZXh0IDEuNXB0IiANCiAgICB3aWR0aD0xMDU+DQogICAgICA8UCBhbGlnbj1jZW50ZXIgY2xhc3M9
TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1SSUdIVDog
MHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtl
ZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBt
c28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlVTJDI3
NTwvU1BBTj48L0ZPTlQ+PC9QPjwvVEQ+PC9UUj4NCiAgPFRSIHN0eWxlPSJIRUlHSFQ6IDE0LjJw
dDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5Ij4NCiAgICA8VEQgY29sU3Bhbj0yIA0KICAgIHN0
eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItTEVGVDog
d2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNv
bGlkOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9U
VE9NOiAwY207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBB
RERJTkctVE9QOiAwY207IFdJRFRIOiAyNjBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBt
c28tYm9yZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9MjY5
Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAw
cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUlOREVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVw
LWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNv
LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbD5CYW5xdWV0
IGZvciBBY2NvbXBhbnlpbmcgUGVyc29uPC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQg
Y29sU3Bhbj0yIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNv
bGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAx
LjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURE
SU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45
NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDogMjcwcHQ7IG1zby1oZWlnaHQtcnVsZTogZXhh
Y3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9y
ZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9MjE3Pg0KICAg
ICAgPFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb05vcm1hbCANCiAgICAgIHN0eWxlPSJNQVJHSU4t
TEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1BTElHTjogY2VudGVyOyBURVhULUlO
REVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVT
IHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05U
IA0KICAgICAgZmFjZT1BcmlhbD5VUyQ2MC9lYWNoPC9TUEFOPjwvRk9OVD48L1A+PC9URD48L1RS
Pg0KICA8VFIgc3R5bGU9IkhFSUdIVDogMTQuMnB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHki
Pg0KICAgIDxURCBjb2xTcGFuPTIgDQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3Rl
eHQgMS41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JE
RVItUklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25l
OyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1
cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBjbTsgV0lEVEg6IDI2MHB0
OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1ib3JkZXItdG9wLWFsdDogc29saWQgd2lu
ZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD0yNjk+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWwg
DQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQt
SU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4t
VVMgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZP
TlQgDQogICAgICBmYWNlPUFyaWFsPkFkZGl0aW9uYWwgQ0QtUk9NIFByb2NlZWRpbmdzPC9TUEFO
PjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQgY29sU3Bhbj0yIA0KICAgIHN0eWxlPSJCT1JERVIt
Qk9UVE9NOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7
IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVt
IG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6
IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDog
MjcwcHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29s
aWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9yZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQg
LjVwdCIgDQogICAgd2lkdGg9MjE3Pg0KICAgICAgPFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb05v
cm1hbCANCiAgICAgIHN0eWxlPSJNQVJHSU4tTEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsg
VEVYVC1BTElHTjogY2VudGVyOyBURVhULUlOREVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFs
bCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJp
ZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbD5VUyQ1MC9lYWNo
PC9TUEFOPjwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFIgc3R5bGU9IkhFSUdIVDogMTQuMnB0
OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHkiPg0KICAgIDxURCBjb2xTcGFuPTIgDQogICAgc3R5
bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMS41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiB3
aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29s
aWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RU
T006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFE
RElORy1UT1A6IDBjbTsgV0lEVEg6IDI2MHB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1z
by1ib3JkZXItdG9wLWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD0yNjk+
PFNQQU4gbGFuZz1FTi1VUyANCiAgICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS
b21hbic7IEZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZh
cmVhc3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2Vy
bmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KICAgICAgZmFjZT1Bcmlh
bD5TcGVjaWFsIEJ1cyBUcmFuc3BvcnRhdGlvbiAoZnJvbSBTZW91bCB0byANCiAgICAgIEt5b25n
anUpPC9GT05UPjwvU1BBTj4gPC9URD4NCiAgICA8VEQgY29sU3Bhbj0yIA0KICAgIHN0eWxlPSJC
T1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVt
IG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVRPUDog
bWVkaXVtIG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5H
LUxFRlQ6IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBX
SURUSDogMjcwcHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFs
dDogc29saWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9yZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRv
d3RleHQgLjVwdCIgDQogICAgd2lkdGg9MjE3Pg0KICAgICAgPFAgYWxpZ249Y2VudGVyIGNsYXNz
PU1zb05vcm1hbCANCiAgICAgIHN0eWxlPSJNQVJHSU4tTEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6
IDBweDsgVEVYVC1BTElHTjogY2VudGVyOyBURVhULUlOREVOVDogMHB4OyBXT1JELUJSRUFLOiBr
ZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsg
bXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIA0KICAgICAgZmFjZT1BcmlhbD5VUyQ4
MC9lYWNoPC9TUEFOPjwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFIgc3R5bGU9IkhFSUdIVDog
MTQuMnB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHkiPg0KICAgIDxURCBjb2xTcGFuPTIgDQog
ICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMS41cHQgZG91YmxlOyBCT1JERVIt
TEVGVDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAu
NXB0IHNvbGlkOyBCT1JERVItVE9QOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBIRUlHSFQ6IDE0
LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkct
UklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBjbTsgV0lEVEg6IDI2MHB0OyBtc28taGVpZ2h0
LXJ1bGU6IGV4YWN0bHkiIA0KICAgIHdpZHRoPTI2OT48U1BBTiBsYW5nPUVOLVVTIA0KICAgICAg
c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiA5cHQ7IG1z
by1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0
ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFu
Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdl
OiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlBWIGFuZCBQQ1MtMjAwMSBSZWdpc3Ry
YXRpb248L0ZPTlQ+PC9TUEFOPiA8L1REPg0KICAgIDxURCANCiAgICBzdHlsZT0iQk9SREVSLUJP
VFRPTTogd2luZG93dGV4dCAxLjVwdCBkb3VibGU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg
Qk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItVE9QOiB3aW5kb3d0
ZXh0IDEuNXB0IHNvbGlkOyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006IDBjbTsgUEFE
RElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElORy1UT1A6IDBj
bTsgV0lEVEg6IDEzNXB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1ib3JkZXItbGVm
dC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9OTY+DQogICAgICA8UCBh
bGlnbj1jZW50ZXIgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAw
cHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5ERU5UOiAw
cHg7IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9
IkZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAg
ICBmYWNlPUFyaWFsPkJ5IE1hcmNoIDMxLCAyMDAxPC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAg
ICA8VEQgDQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMS41cHQgZG91Ymxl
OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAxLjVw
dCBzb2xpZDsgQk9SREVSLVRPUDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgSEVJR0hUOiAxNC4y
cHQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJ
R0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRIOiAxMzVwdDsgbXNvLWhlaWdodC1y
dWxlOiBleGFjdGx5OyBtc28tYm9yZGVyLWxlZnQtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQi
IA0KICAgIHdpZHRoPTEwNT4NCiAgICAgIDxQIGFsaWduPWNlbnRlciBjbGFzcz1Nc29Ob3JtYWwg
DQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQt
QUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBweDsgV09SRC1CUkVBSzoga2VlcC1hbGwiPjxT
UEFOIA0KICAgICAgbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZv
bnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCiAgICAgIGZhY2U9QXJpYWw+QWZ0ZXIgTWFyY2ggMzEs
IDIwMDE8L1NQQU4+PC9GT05UPjwvUD48L1REPjwvVFI+DQogIDxUUiBzdHlsZT0iSEVJR0hUOiAx
NC4ycHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3RseSI+DQogICAgPFREIA0KICAgIHN0eWxlPSJC
T1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItTEVGVDogd2luZG93
dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBC
T1JERVItVE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAw
Y207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkct
VE9QOiAwY207IFdJRFRIOiAxMDBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28tYm9y
ZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9NjM+DQogICAg
ICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsgTUFS
R0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48
U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1m
b250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlJlZ3VsYXIgUmVnaXN0
cmF0aW9uPC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQgDQogICAgc3R5bGU9IkJPUkRF
Ui1CT1RUT006IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9u
ZTsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVItVE9QOiBtZWRp
dW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVG
VDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRI
OiAxNjBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28tYm9yZGVyLWxlZnQtYWx0OiBz
b2xpZCB3aW5kb3d0ZXh0IC41cHQ7IG1zby1ib3JkZXItdG9wLWFsdDogc29saWQgd2luZG93dGV4
dCAuNXB0IiANCiAgICB3aWR0aD0xOTA+PFNQQU4gbGFuZz1FTi1VUyANCiAgICAgIHN0eWxlPSJG
T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogOXB0OyBtc28tZmFyZWFz
dC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5n
OiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog
S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlBs
YW4gMzogUENTIFJlZ3VsYXIrUFYgUGxhbiAxPC9GT05UPjwvU1BBTj4gPC9URD4NCiAgICA8VEQg
DQogICAgc3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRF
Ui1MRUZUOiBtZWRpdW0gbm9uZTsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlk
OyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9N
OiAwY207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJ
TkctVE9QOiAwY207IFdJRFRIOiAxMzVwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28t
Ym9yZGVyLWxlZnQtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7IG1zby1ib3JkZXItdG9wLWFs
dDogc29saWQgd2luZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD05Nj4NCiAgICAgIDxQIGFsaWdu
PWNlbnRlciBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBweDsg
TUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtQUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBweDsg
V09SRC1CUkVBSzoga2VlcC1hbGwiPjxTUEFOIA0KICAgICAgbGFuZz1FTi1VUyBzdHlsZT0iRk9O
VC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCiAgICAgIGZh
Y2U9QXJpYWw+VVMkNjUwPC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQgDQogICAgc3R5
bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1MRUZUOiBt
ZWRpdW0gbm9uZTsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDEuNXB0IHNvbGlkOyBCT1JERVIt
VE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBB
RERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9QOiAw
Y207IFdJRFRIOiAxMzVwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28tYm9yZGVyLWxl
ZnQtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7IG1zby1ib3JkZXItdG9wLWFsdDogc29saWQg
d2luZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD0xMDU+DQogICAgICA8UCBhbGlnbj1jZW50ZXIg
Y2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1S
SUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJF
QUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTog
OXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFs
PlVTJDc1MDwvU1BBTj48L0ZPTlQ+PC9QPjwvVEQ+PC9UUj4NCiAgPFRSIHN0eWxlPSJIRUlHSFQ6
IDE0LjJwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5Ij4NCiAgICA8VEQgcm93U3Bhbj0yIA0K
ICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JERVIt
TEVGVDogd2luZG93dGV4dCAxLjVwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAu
NXB0IHNvbGlkOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJ
TkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1
cHQ7IFBBRERJTkctVE9QOiAwY207IFdJRFRIOiAxMDBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFj
dGx5OyBtc28tYm9yZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lk
dGg9NjM+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxF
RlQ6IDBweDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6
IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogOXB0
OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlN0
dWRlbnQgUmVnaXN0cmF0aW9uPC9TUEFOPjwvRk9OVD48L1A+PC9URD4NCiAgICA8VEQgDQogICAg
c3R5bGU9IkJPUkRFUi1CT1RUT006IHdpbmRvd3RleHQgMC41cHQgc29saWQ7IEJPUkRFUi1MRUZU
OiBtZWRpdW0gbm9uZTsgQk9SREVSLVJJR0hUOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlkOyBCT1JE
RVItVE9QOiBtZWRpdW0gbm9uZTsgSEVJR0hUOiAxNC4ycHQ7IFBBRERJTkctQk9UVE9NOiAwY207
IFBBRERJTkctTEVGVDogNC45NXB0OyBQQURESU5HLVJJR0hUOiA0Ljk1cHQ7IFBBRERJTkctVE9Q
OiAwY207IFdJRFRIOiAxNjBwdDsgbXNvLWhlaWdodC1ydWxlOiBleGFjdGx5OyBtc28tYm9yZGVy
LWxlZnQtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQ7IG1zby1ib3JkZXItdG9wLWFsdDogc29s
aWQgd2luZG93dGV4dCAuNXB0IiANCiAgICB3aWR0aD0xOTA+PFNQQU4gbGFuZz1FTi1VUyANCiAg
ICAgIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogOXB0
OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28t
Zm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz
dC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQogICAgICBm
YWNlPUFyaWFsPlBsYW4gNDogUENTIFBsYW4gQStQViBQbGFuIDI8L0ZPTlQ+PC9TUEFOPiA8L1RE
Pg0KICAgIDxURCANCiAgICBzdHlsZT0iQk9SREVSLUJPVFRPTTogd2luZG93dGV4dCAwLjVwdCBz
b2xpZDsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IHdpbmRvd3RleHQg
MC41cHQgc29saWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBIRUlHSFQ6IDE0LjJwdDsgUEFE
RElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQu
OTVwdDsgUEFERElORy1UT1A6IDBjbTsgV0lEVEg6IDEzNXB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4
YWN0bHk7IG1zby1ib3JkZXItbGVmdC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdDsgbXNvLWJv
cmRlci10b3AtYWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQiIA0KICAgIHdpZHRoPTk2Pg0KICAg
ICAgPFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb05vcm1hbCANCiAgICAgIHN0eWxlPSJNQVJHSU4t
TEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1BTElHTjogY2VudGVyOyBURVhULUlO
REVOVDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVT
IHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05U
IA0KICAgICAgZmFjZT1BcmlhbD5VUyQ0NTA8L1NQQU4+PC9GT05UPjwvUD48L1REPg0KICAgIDxU
RCANCiAgICBzdHlsZT0iQk9SREVSLUJPVFRPTTogd2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9S
REVSLUxFRlQ6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IHdpbmRvd3RleHQgMS41cHQgc29s
aWQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RU
T006IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFE
RElORy1UT1A6IDBjbTsgV0lEVEg6IDEzNXB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1z
by1ib3JkZXItbGVmdC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdDsgbXNvLWJvcmRlci10b3At
YWx0OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQiIA0KICAgIHdpZHRoPTEwNT4NCiAgICAgIDxQIGFs
aWduPWNlbnRlciBjbGFzcz1Nc29Ob3JtYWwgDQogICAgICBzdHlsZT0iTUFSR0lOLUxFRlQ6IDBw
eDsgTUFSR0lOLVJJR0hUOiAwcHg7IFRFWFQtQUxJR046IGNlbnRlcjsgVEVYVC1JTkRFTlQ6IDBw
eDsgV09SRC1CUkVBSzoga2VlcC1hbGwiPjxTUEFOIA0KICAgICAgbGFuZz1FTi1VUyBzdHlsZT0i
Rk9OVC1TSVpFOiA5cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Rk9OVCANCiAgICAg
IGZhY2U9QXJpYWw+VVMkNTUwPC9TUEFOPjwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFIgc3R5
bGU9IkhFSUdIVDogMTQuMnB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHkiPg0KICAgIDxURCAN
CiAgICBzdHlsZT0iQk9SREVSLUJPVFRPTTogd2luZG93dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVS
LUxFRlQ6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IHdpbmRvd3RleHQgMC41cHQgc29saWQ7
IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBIRUlHSFQ6IDE0LjJwdDsgUEFERElORy1CT1RUT006
IDBjbTsgUEFERElORy1MRUZUOiA0Ljk1cHQ7IFBBRERJTkctUklHSFQ6IDQuOTVwdDsgUEFERElO
Ry1UT1A6IDBjbTsgV0lEVEg6IDE2MHB0OyBtc28taGVpZ2h0LXJ1bGU6IGV4YWN0bHk7IG1zby1i
b3JkZXItbGVmdC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdDsgbXNvLWJvcmRlci10b3AtYWx0
OiBzb2xpZCB3aW5kb3d0ZXh0IC41cHQiIA0KICAgIHdpZHRoPTE5MD48U1BBTiBsYW5nPUVOLVVT
IA0KICAgICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpF
OiA5cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzQ4MTQ4OyYjNTM0NjE7JiM1MjQwNDs7
IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m
YXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48Rk9OVCANCiAg
ICAgIGZhY2U9QXJpYWw+UGxhbiA1OiBQQ1MgUGxhbiBCK1BWIFBsYW4gMjwvRk9OVD48L1NQQU4+
IDwvVEQ+DQogICAgPFREIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAu
NXB0IHNvbGlkOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93
dGV4dCAwLjVwdCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IEhFSUdIVDogMTQuMnB0
OyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDQuOTVwdDsgUEFERElORy1SSUdI
VDogNC45NXB0OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDogMTM1cHQ7IG1zby1oZWlnaHQtcnVs
ZTogZXhhY3RseTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0OyBt
c28tYm9yZGVyLXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9OTY+
DQogICAgICA8UCBhbGlnbj1jZW50ZXIgY2xhc3M9TXNvTm9ybWFsIA0KICAgICAgc3R5bGU9Ik1B
UkdJTi1MRUZUOiAwcHg7IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUFMSUdOOiBjZW50ZXI7IFRF
WFQtSU5ERU5UOiAwcHg7IFdPUkQtQlJFQUs6IGtlZXAtYWxsIj48U1BBTiANCiAgICAgIGxhbmc9
RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+
PEZPTlQgDQogICAgICBmYWNlPUFyaWFsPlVTJDM5MDwvU1BBTj48L0ZPTlQ+PC9QPjwvVEQ+DQog
ICAgPFREIA0KICAgIHN0eWxlPSJCT1JERVItQk9UVE9NOiB3aW5kb3d0ZXh0IDAuNXB0IHNvbGlk
OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogd2luZG93dGV4dCAxLjVw
dCBzb2xpZDsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IEhFSUdIVDogMTQuMnB0OyBQQURESU5H
LUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDQuOTVwdDsgUEFERElORy1SSUdIVDogNC45NXB0
OyBQQURESU5HLVRPUDogMGNtOyBXSURUSDogMTM1cHQ7IG1zby1oZWlnaHQtcnVsZTogZXhhY3Rs
eTsgbXNvLWJvcmRlci1sZWZ0LWFsdDogc29saWQgd2luZG93dGV4dCAuNXB0OyBtc28tYm9yZGVy
LXRvcC1hbHQ6IHNvbGlkIHdpbmRvd3RleHQgLjVwdCIgDQogICAgd2lkdGg9MTA1Pg0KICAgICAg
PFAgYWxpZ249Y2VudGVyIGNsYXNzPU1zb05vcm1hbCANCiAgICAgIHN0eWxlPSJNQVJHSU4tTEVG
VDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1BTElHTjogY2VudGVyOyBURVhULUlOREVO
VDogMHB4OyBXT1JELUJSRUFLOiBrZWVwLWFsbCI+PFNQQU4gDQogICAgICBsYW5nPUVOLVVTIHN0
eWxlPSJGT05ULVNJWkU6IDlwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxGT05UIA0K
ICAgICAgZmFjZT1BcmlhbD5VUyQ0OTA8L1NQQU4+PC9GT05UPjwvUD48L1REPjwvVFI+PC9UQk9E
WT48L1RBQkxFPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTi1MRUZUOiAwcHg7
IE1BUkdJTi1SSUdIVDogMHB4OyBURVhULUlOREVOVDogMHB4Ij48Qj48QiANCnN0eWxlPSJtc28t
YmlkaS1mb250LXdlaWdodDogbm9ybWFsIj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkJBQ0tH
Uk9VTkQtQ09MT1I6IHJnYigyMTcsMjE3LDIxNyk7IEZPTlQtU0laRTogMTBwdDsgbXNvLXNoYWRp
bmc6IHdoaXRlOyBtc28tcGF0dGVybjogZ3JheS0xNSBhdXRvIj48Rk9OVCANCmZhY2U9QXJpYWw+
SW1wb3J0YW50IERhdGU6PC9CPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQiPiANCjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTog
MTBwdDsgbXNvLXRhYi1jb3VudDogMSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48
QiANCnN0eWxlPSJtc28tYmlkaS1mb250LXdlaWdodDogbm9ybWFsIj48U1BBTiBsYW5nPUVOLVVT
IA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0
OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYj
NDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNp
LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5n
dWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1BcmlhbD5NYXJjaCAzMSwgMjAwMTwvU1BBTj48L0I+
PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IG1zby10YWItY291bnQ6
IDEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvQj4mbmJzcDsmbmJzcDs8
L1NQQU4+PFNQQU4gDQpsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3
IFJvbWFuJzsgRk9OVC1TSVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQt
a2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1BcmlhbD5B
ZHZhbmNlIFJlZ2lzdHJhdGlvbiAmYW1wOyBIb3RlbCANClJlc2VydmF0aW9uPC9GT05UPjwvRk9O
VD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU4t
TEVGVDogMHB4OyBNQVJHSU4tUklHSFQ6IDBweDsgVEVYVC1JTkRFTlQ6IDBweCI+PEZPTlQgDQpm
YWNlPUFyaWFsPjxGT05UIGZhY2U9QXJpYWw+PEI+PEIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2Vp
Z2h0OiBub3JtYWwiPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9S
OiByZ2IoMjE3LDIxNywyMTcpOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1zaGFkaW5nOiB3aGl0ZTsg
bXNvLXBhdHRlcm46IGdyYXktMTUgYXV0byI+PEZPTlQgDQpmYWNlPUFyaWFsPlBDUy0yMDAxIFNl
Y3JldGFyaWF0OjwvQj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IG1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8QlI+PC9CPjwvU1BBTj48U1BBTiBsYW5n
PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4w
cHQiPkZ1cnRoZXIgaW5xdWlyaWVzIGNhbiBiZSANCm1hZGUgYXQ6PEJSPjwvU1BBTj48U1BBTiBs
YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1T
SVpFOiAxMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsgbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6ICYjNDgxNDg7JiM1MzQ2MTsmIzUyNDA0OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7
IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28t
YmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1BcmlhbD5UZWw6ICs4Mi00Mi00NzIt
NzQ2MDwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNv
LXRhYi1jb3VudDogMSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls
ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwcHQ7IG1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiM0ODE0ODsm
IzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3Vh
Z2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBB
Ui1TQSI+PEZPTlQgDQpmYWNlPUFyaWFsPkZheDogKzgyLTQyLTQ3Mi03NDU5PC9TUEFOPjxTUEFO
IGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBtc28tdGFiLWNvdW50OiAxIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PFNQQU4gDQpsYW5nPUVOLVVTIA0K
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgbXNvLXRhYi1jb3VudDogMSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjxTUEFOIGxhbmc9RU4t
VVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEw
cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog
JiM0ODE0ODsmIzUzNDYxOyYjNTI0MDQ7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFu
c2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxh
bmd1YWdlOiBBUi1TQSI+PEZPTlQgDQpmYWNlPUFyaWFsPkVtYWlsOiANCnB2QHB2MjAwMS5rYWlz
dC5hYy5rcjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48
L1A+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_001_0006_01C0B3A6.573C3340--

------=_NextPart_000_0005_01C0B3A6.573C3340
Content-Type: text/html;
	name="advance_program.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="advance_program.htm"




Paper Review






    

                    =

Advance Program


=A2=BAMONDAY, APRIL 30, 2001



INVITED TALK (1) =
(08:40~09:40)



Room: Grand =
Ballroom (A)



Convergence of Multimedia, Wireless and =
Internet



Ya-Qin Zhang (Microsoft Research in =
Beijing, China)



SESSION MP1: Streaming, Network =
Adaptation
and Performance (10:20~11:20)



Room: =
Pine


            
Chair: =
T.B.D.

            

                

                    
1

                    		
                    
An
Empirical Analysis of Video Streaming over an Internet Routing =
Environment


                    		
                

                

                    
 

                    		
                    
S.R.Sudharsanan, V.Ganapathy,
and V.Ramachandran (Multimedia Univ., Cyberjaya, =
Malaysia)


                    		
                

                

                    
2

                    		
                    
Adaptive
Multimedia Streaming over IP


                    		
                

                

                    
 

                    		
                    
Matthew Walker, Richard
Jacobs, and Mike Nilsson (Ipswich, U.K.)


                    		
                

                

                    
3

                    		
                    
Hierarchical
Modeling of Variable Bit Rate Video Sources


                    		
                

                

                    
 

                    		
                    
Deepak S. Turaga and Tsuhan
Chen (Carnegie Mellon Univ., U.S.A.)


                    		
                

                

                    
4

                    		
                    
Admission Control Algorithm Based =
on
Metadata of Quantization Parameter and Output-Bit-Rate Profile for =
Guaranteeing


                    		
                

                

                    
 

                    		
                    
 Hwangjun
Song (Hongik Univ., Korea) and Hae-Kwang Kim (Sejong Univ., =
Korea)


                    		
                

                

                                
5

                    		
                                
A New Rate Control Algorithm for =
Real
Time Video Communication Using Spatial Prediction =
Error


                    		
                

                

                                
 

                    		
                                
Jun Geun
Jeon and Myoung Ho Lee (ETRI, Korea)


                    		
                

                

                                
6

                    		
                                
Study of
Packet Dropping Policies on Layered Video


                    		
                

                

                                
 

                    		
                                
Frederic Raspall (Univ. of
Politecnica de Cataluuya, Spain), Christoph Kuhmuench (Univ. of =
Mannheim,
Germany), Albert Banchs, Federico Pelizza (NEC Europe Ltd., Germany), =
and
Sebastia Sallent (Univ. of Politecnica de Cataluuya, =
Spain)


                    		
                

                

                    
7

                    		
                    
Cooperative
Caching Framework of VOD Using P2P Technology


                    		
                

                

                    
 

                    		
                    
Jungohn Yim (LG Electronics
Inc., Korea), Gil Yong Kim (Pusan Nat=A1=AFl Univ., Korea), and =
Young-Sung Son
(ETRI, Korea)


                    		
                

                

                    
8

                    		
                    
 A Study on the Scalable Coding
Algorithm by Separating and Composing of MPEG-2 =
Bitstreams


                    		
                

                

                    
 

                    		
                    
Isao Nagayoshi, Tsuyoshi
Hanamura, Hiroyuki Kasai, and Hideyoshi Tominaga (Waseda Univ., =
Japan)


                    		
                

                

                    
9

                    		
                    
A Media
Gateway for Flexible MPEG-2 Video Delivery over IP Network and its =
Applications


                    		
                

                

                    
 

                    		
                    
Yuzo Senda (NEC =
Corp., Japan)


                    		
                

                

                    
10

                    		
                    
Video
Compression Based on Selectively Refining Regions in Difference =
Frame


                    		
                

                

                    
 

                    		
                    
 Jay Yun and
Toby Berger (Cornell Univ., U.S.A.)


                    		
                

                

                                
11

                    		
                                
Markovian
Arrival Process (MAP) Modeling for Superposed Packet =
Streams


                    		
                

                

                                
 

                    		
                                
Sang H.
Kang, Yong Han Kim (Univ. of Seoul, Korea), and Dan K. Sung (KAIST, =
Korea)


                    		
                

            


SESSION MO1: Video Streaming =
Over Internet



Room: Grand =
Ballroom (A)



Chair:
T.B.D.


            

                

                    
11:20~11:40


                    		
                    
Packet
Classification Schemes for Streaming MPEG Video over Delay and Loss
Differentiated Networks


                    		
                

                

                    
 

                    		
                    
Wai-tian Tan and Avideh Zakhor (Univ.
of California, U.S.A.)


                    		
                

                

                    
11:40~12:00


                    		
                    
Hierarchical
Video Multicast And Packet Filtering


                    		
                

                

                    
 


                    		
                    
David Pate and Jean-Jacques Pansiot =
(LSIIT, France)


                    		
                

                

                    
12:00~12:20


                    		
                    
Aggregated
QoS Mapping Framework for Relative Service Differentiation-Aware Video =
Streaming


                    		
                

                

                    
 

                    		
                    
Jitae Shin, Jin-Gyeong Kim, JongWon =
Kim, D. C.
Lee, and C.-C. Jay Kuo (Univ. of Southern California, =
U.S.A.


                    		
                

                

                    
12:20~12:40


                    		
                    
 Media
Oriented Video Streaming Flow Control in Linux Cluster =
Server


                    		
                

                

                    
 

                    		
                    
Jungohn Yim (LG Electronics
Inc., Korea), Gil Yong Kim (Pusan Nat=A1=AFl Univ., Korea), and =
Young-Sung Son
(ETRI, Korea)


                    		
                

                

                    
12:40~13:00 


                    		
                    
Simple
Packet Loss Recovery Method for Video Streaming


                    		
                

                

                    
 

                    		
                    
   Miska M. =
Hannuksela (Nokia Mobile Phones, Finland)


                    		
                

            


SESSION MO2: Streaming Congestion =
Control



Room: Grand =
Ballroom (A)



Chair:
T.B.D.


            

                

                    
14:00~14:20


                    		
                    
 =
On the
Interactions between Layered Quality Adaptation and Congestion Control =
for
Streaming Video


                    		
                

                

                    
 

                    		
                    
 Nick Feamster, Deepak Bansal, =
and Hari
Balakrishnan (MIT, U.S.A.)


                    		
                

                

                    
14:20~14:40


                    		
                    
 =
Robust
Scalable Video Streaming over Internet with Network-Adaptive Congestion =
Control
and Unequal Loss Protection


                    		
                

                

                    


                    		
                    
   Qian Zhang, Guijin Wang , Wenwu Zhu,
and Ya-Qin Zhang (Microsoft Research, China)


                    		
                

                

                    
14:40~15:00  


                    		
                    
Long Window
Rate Control for Video Streaming


                    		
                

                

                    
 

                    		
                    
Viktor Varsa and Marta Karczewicz =
(Nokia Research Center,
U.S.A.)


                    		
                

                

                    
15:00~15:20


                    		
                    
Adaptive
Streaming of Stored Video in a TCP-Friendly Context : Multiple Versions =
or
Multiple Layers ?


                    		
                

                

                    
 

                    		
                    
 Philippe de Cuetos, Despina Saparilla,
and Keith W. Ross (Inst. Eurecom, France)


                    		
                

            


SESSION MP2: Multicasting, =
Standards and
Implementation (16:00~17:00)



Room: =
Pine



Chair: T.B.D.


            

                

                    
1

                    		
                    
Sender-Initiated
Configuration of an ACK-Tree for Reliable Multicast =
Transport


                    		
                

                

                    
 

                    		
                    
Eunsook Kim (Sookmyung
Women's Univ., Korea), Seokjoo Koh, Juyoung Park, Singak Kang (ETRI, =
Korea), and
Jongwon Choe (Sookmyung Women's Univ., Korea)


                    		
                

                

                    
2

                    		
                    
A
Constrained Routing Algorithm for Dynamic =
Multicasting


                    		
                

                

                    
 

                    		
                    
Hong-Soon Nam (ETRI, Korea),
Dae-Young Kim (Chungnam Nat'l Univ., Korea), and Kyu-Ook Lee (ETRI, =
Korea)


                    		
                

                

                    
3

                    		
                    
 A
Proposal of Video Contents E-Commerce System Using Scalability =
Architecture


                    		
                

                

                    
 

                    		
                    
Mei Kodama (Hiroshima Univ.,
Japan), Tomoji Ikeda (Satake Corp., Japan), Hidekazu Takahashi, and =
Masashi
Murasaki (Hiroshima Univ., Japan)


                    		
                

                

                    
4

                    		
                    
  Water
Ring Scan Order for MPEG-4 Fine Granular Scalable =
Coding


                    		
                

                

                    
 

                    		
                    
Gwang Hoon Park, Seung Tae
Kim, Yoon Jin Lee (Yonsei Univ., Wonju, Korea), Young Kwon Lim (MP4 =
Cast,
Korea), Hyun Cheol Kim, and Myoung Ho Lee (ETRI, =
Korea)


                    		
                

                

                                
5

                    		
                                
Value
Added Object Video Authoring Tools


                    		
                

                

                                
 

                    		
                                
  Pierre
Pleven (Symah Vision, France)


                    		
                

                

                                
6

                    		
                                
  Web Based
Multicast Audio and Video Application over QoS Enabled =
Networks


                    		
                

                

                                
 

                    		
                                
 Myung-Ki
Shin and Yong-Jin Kim (ETRI, Korea)


                    		
                

                

                    
7

                    		
                    
Streaming
MPEG-4 over IP and Broadcast Networks: DMIF Based =
Architectures


                    		
                

                

                    
 

                    		
                    
Y. Pourmohammadi, K. Asrar
Haghighi, A. Mohamed, and H. M. Alnuweiri (Univ. of British Columbia, =
Canada)


                    		
                

                

                    
8

                    		
                    
Online Video Content Analysis for
Collaborative Information Sharing and Dissemination in Semantic =
Multicast


                    		
                

                

                    
 

                    		
                    
Wensheng Zhou, Son Dao (HRL
Labs., U.S.A.), and C.-C. Jay Kuo (Univ. of Southern California, =
U.S.A.)


                    		
                

                

                    
9

                    		
                    
Design of
Appropriate Multiplexer and Its Corresponding Demutiplexer for =
Multi-View Video
                                 &n=
bsp;        Communication System


                    		
                

                

                    
 

                    		
                    
 Je-Woo Kim,
Jong-Ho Paik, Byeong-Ho Choi, and Hyeok-Koo Jung (KETI, =
Korea)


                    		
                

                

                    
10

                    		
                    
 Design and
Implementation of an Open Broadband Multimedia =
System


                    		
                

                

                    
 

                    		
                    
Florin Lohan, Irek Defee
(Tampere Univ. of Technology, Finland), and Harri Hakulinen (Nokia Home
Communications, Finland)


                    		
                

                

                                
11

                    		
                                
A Study on
the Interworking Platform Supporting Adaptive Stream =
QoS


                    		
                

                

                                
 

                    		
                                
Byunghun
Song, Kwangsue Chung, and Hyukjoon Lee (Kwangwoon Univ., =
Korea)


                    		
                

            


SESSION MO3: Multicasting, =
Standards and
Network Control



Room: Grand =
Ballroom (A)



Chair:
T.B.D.


            

                

                    
17:00~17:20


                    		
                    
Classification
of Receivers in Large Multicast Groups Using =
Distributed


                    		
                

                

                    

                    		
                    
Kave Salamatian and Thierry Turletti
(Univ. of Paris VI, France)


                    		
                

                

                    
17:20~17:40


                    		
                    
MPEG-7
Transcoding Hints for Reduced Complexity and Improved =
Quality


                    		
                

                

                    


                    		
                    
Peter M. Kuhn, Teruhiko Suzuki (Sony
Corp., Japan), and Anthony Vetro (MERL, U.S.A.)


                    		
                

                

                    
17:40~18:00


                    		
                    
Adding
Delivery Support to MPEG-Pro, an Authoring System for =
MPEG-4


                    		
                

                

                    

                    		
                    
Frederic Bouilhaguet, Cyril =
Concolato, Souhila Boughoufalah, and
Jean-Claude Dufourd (ENST, France)


                    		
                

                

                    
18:00~18:20


                    		
                    
An
Efficient Scene-Based Renegotiation Scheduling and Admission Control for =
RCBR
Transmission of Real-Time Video Traffic


                    		
                

                

                    

                    		
                    
Jae Cheol Kwon, Myeong-jin Lee, and
Jae-kyoon Kim (KAIST, Korea)


                    		
                

            


 



=A2=BATUESDAY, MAY 1, 2001



INVITED TALK (2) =
(08:40~09:40)



Room: Grand =
Ballroom (A)



Internet Video - Protocols & =
Applications



Civanlar M. Reha (AT&T Labs Research, =
U.S.A.)



SESSION TP1: Error Resilient and =
Layered
Coding (10:20~11:20)



Room: =
Pine



Chair: T.B.D.


            

                

                    
1

                    		
                    
An
Implementation of Coding Scheme for Packet Loss =
Protection


                    		
                

                

                    

                    		
                    
Youshi Xu and Tingting Zhang
(Mid-Sweden Univ., Sweden)


                    		
                

                

                    
2

                    		
                    
  Constraint-Reduced
Regularization for Reducing Blocking Artifacts in Compressed =
Video


                    		
                

                

                    

                    		
                    
In-Kyung Hwang, Shi-Chang
Joung, Sung-Jin Kim, and Joon-Ki Paik (Chung-Ang Univ., =
Korea)


                    		
                

                

                    
3

                    		
                    
Context-Based Block Motion =
Estimation
(CB-BME): A Low-Complexity Approach to Motion Analysis in Video =
Coders


                    		
                

                

                    

                    		
                    
   F.G.B. De
Natale and F. Granelli (Univ. of Trento, Italy)


                    		
                

                

                    
4

                    		
                    
Scalable Delivery of Digital Video
Over Non-Prioritized ATM Networks: A Joint Source-Channel =
Approach


                    		
                

                

                    

                    		
                    
R. Kurceren and J.
Modestino (Rensselaer Polytechnic Inst., U.S.A.)


                    		
                

                

                                
5

                    		
                                
   Layered
Wavelet Coding for Video


                    		
                

                

                                

                    		
                                
Claudia Schremmer, Christoph
Kuhmuench, and Wolfgang Effelsberg (Univ. of Mannheim, =
Germany)


                    		
                

                

                                
6

                    		
                                
   Design of
Joint Source-Channel Decoder for H.263+ by MAP =
Estimation


                    		
                

                

                                

                    		
                                
     =
Ho-hyon
Song, Yong-gu Kim, and Yoon-sik Choe (Yonsei Univ., =
Korea)


                    		
                

                

                    
7

                    		
                    
   Motion Vector Recovery Based on
Homogeneous Motion Area for H.263 Video =
Communications


                    		
                

                

                    

                    		
                    
JungHyun Kim and GueeSang Lee
(Chonnam Nat'l Univ., Korea)


                    		
                

                

                    
8

                    		
                    
  Redundancy
Allocation Strategy for Multiple Description Transform Video =
Coding


                    		
                

                

                    

                    		
                    
Sang-Uk Ryu
and Yo-Sung Ho (K-JIST, Korea)


                    		
                

                

                    
9

                    		
                    
  Video
Coding Using Color Set Partitioning in Hierarchical Trees =
Scheme


                    		
                

                

                    

                    		
                    
Lee Wei
Siong and Ashraf A. Kassim (Nat'l Univ. of Singapore, =
Singapore)


                    		
                

                

                    
10

                    		
                    
A Novel
Approach for the Concealment of JPEG2000 Transmission =
Errors


                    		
                

                

                    

                    		
                    
Luigi
Atzori, Stefano Corona, Daniele D. Giusto, and Alessio Raccis (Univ. of
Cagliari, Italy)


                    		
                

                

                                
11

                    		
                                
An
Efficient Data Partitioning and Coding for Error-Resilient DCT-Based =
Images


                    		
                

                

                                

                    		
                                
Kyu-chan
Roh, Kwang-deok Seo, and Jae-kyoon Kim (KAIST, Korea)


                    		
                

            


SESSION TO1: Wireless/Mobile =
Packet Video



Room: Grand =
Ballroom (A)



Chair:
T.B.D.


            

                

                    
11:20~11:40


                    		
                    
Multiple
Selective Retransmissions in RTP


                    		
                

                

                    

                    		
                    
Carsten Burmeister, Rolf Hakenberg, =
Jose Rey (Panasonic, Germany),
Akihiro Miyazaki, and Koichi Hata (Matsushita Electric Industrial Co. =
Ltd.,
Japan)


                    		
                

                

                    
11:40~12:00


                    		
                    
A Joint
Source Coding and Power Control Approach for Maximizing the Capacity of =
CDMA
Wireless Networks Supporting Heterogeneous Video =
Traffic


                    		
                

                

                    


                    		
                    
Yee Sin Chan and J. W. Modestino
(Rensselaer Polytechnic Inst., U.S.A.)


                    		
                

                

                    
12:00~12:20


                    		
                    
Design of
an Adaptive Interface between Video Compression and Transmission =
Protocols for
Mobile Communication


                    		
                

                

                    

                    		
                    
Arjen van der Schaaf, Koen
Langendoen, and R. L. Lagendijk (Delft Univ. of Technology, The =
Netherlands)


                    		
                

                

                    
12:20~12:40


                    		
                    
IVideo - A
Video Proxy for the Mobile Internet


                    		
                

                

                    

                    		
                    
Sam John, Rittwik Jana, Vinay
Vaishampayan, and Amy Reibman (AT&T Research Lab., =
U.S.A.)


                    		
                

                

                    
12:40~13:00 


                    		
                    
Wireless Video Transport Using =
Conditional
Retransmission and Low-Delay Interleaving


                    		
                

                

                    

                    		
                    
Supavadee Aramvith (Univ. of
Washington, U.S.A.), Chia-Wen Lin (Nat'l Chung Cheng Univ., Taiwan), and
Ming-Ting Sun (Univ. of Washington, U.S.A.)


                    		
                

            


SESSION TO2: Network Adaptive =
Video Coding
and Transport



Room: Grand =
Ballroom (A)



Chair:
T.B.D.


            

                

                    
                        
14:00~14:20 

                    		
                    
                        
 A Joint
Source-Channel Coding Approach for Packet Video Transport over Wireless =
IP
Networks

                    		
                

                

                    

                    		
                    
Y. Pei and J. W. Modestino =
(Rensselaer
Polytechnic Inst., U.S.A.)


                    		
                

                

                    
14:20~14:40


                    		
                    
Scalable
Video Coding and its Delivery System over the =
Internet


                    		
                

                

                    


                    		
                    
Atsushi Sagata, Yoshiyuki
Yashima, Kazuto Kamikura, and Naoki Kobayashi (NTT, =
Japan)


                    		
                

                

                    
14:40~15:00


                    		
                    
Rate
Control Methods for Real-Time VBR Video Coding and =
Transmission


                    		
                

                

                    

                    		
                    
Junfeng Bai, Chang Feng (Univ.
of Missouri-Columbia, U.S.A.), Qingmin Liao, Xinggang Lin (Tsinghua =
Univ.,
China), and Xinhua Zhuang (Univ. of Missouri-Columbia, =
U.S.A.)


                    		
                

                

                    
15:00~15:20


                    		
                    
Progressiv
Texture Video Streaming for Lossy Packet Networks


                    		
                

                

                    

                    		
                    
 Thomas Stockhammer and =
Christian
Buchner (Munich Univ. of Technology, Germany)


                    		
                

                

                    
15:20~15:40


                    		
                    
Adaptive
QoS Management for MPEG-4 Streaming Service over =
Internet


                    		
                

                

                    

                    		
                    
Ji Hoon Choi, Sang Jo =
Lee, Hyun Chul Kim, and Myung Ho Lee
(Kyunghee Univ., Korea)


                    		
                

            


PANEL DISCUSSION =
(16:00~17:00)



Room: Grand =
Ballroom (A)



The detailed
information will be informed soon.


        		
    




 





------=_NextPart_000_0005_01C0B3A6.573C3340--




From rem-conf Fri Mar 23 09:34:52 2001 
From rem-conf-request@es.net Fri Mar 23 09:34:51 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gVPm-0005t4-00; Fri, 23 Mar 2001 09:31:54 -0800
Received: from dns.packetdesign.com (mailman.packetdesign.com) [65.192.41.10] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gVPj-0005qA-00; Fri, 23 Mar 2001 09:31:51 -0800
Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f2NHSe288121;
	Fri, 23 Mar 2001 09:28:40 -0800 (PST)
	(envelope-from casner@acm.org)
Date: Fri, 23 Mar 2001 09:32:30 -0800 (PST)
From: Stephen Casner 
Sender: 
To: Allison Mankin , Scott Bradner 
cc: 
Subject: AVT meeting summary
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Audio/Video Transport Working Group summary

As of this meeting, we completed WG last call to submit the RTP spec
and A/V profile for advancement to Draft Standard. Apart from a few
exceptions, for each function we have either received a statement of
interoperability between two independent implementations or we have
removed the function.  For the few exceptions, we have commitments
>from specific individuals to complete the testing by April 15.  The
deletions were two minor functions and several payload formats in the
A/V profile.  Two of those payload formats will be restored since
interop statements were subsequently received; the revised draft is to
be posted in the week after the meeting, and then a request for
advancement will be submitted to the Area Directors.

The two proposals for secure RTP presented at the last meeting were
successfully merged.  After discussion of a few issues in this
meeting, a revised draft is expected to be ready for last call by the
next meeting.

A new proposal for changes to RTCP to support source-specific
multicast sessions was proposed.  This uses source forwarding of
unicast RTCP from receivers.  As was discussed previously at the Oslo
meeting, there are denial-of-service risks in this that need to be
addressed.  This enhancement has wide potential use and merits further
work.

The two drafts specifing timing rules and packet formats for a new
profile for low-delay RTCP backchannel information were revised for
this meeting, but have not yet been merged as was planned at the last
meeting.  This is to be done in mid-April.  A retransmission payload
format using that profile has also been revised.

Several payload formats already in progress were revised for this
meeting.  The payload format for generic FEC with ULP is ready for
working group last call.  The payload formats for AMR and AMR-WB have
been combined and extended to have both bit-efficient and byte-aligned
formats.  The authors were requested to explore removing the in-band
signaling of these alternatives to use just out-of-band signaling
instead.  This should to proceed toward RFC publication soon.
In the meeting we resolved a few minor issues with the payload format
for EVRC speech, but did not resolve a more contentious issue of a
format tradeoff between bit efficiency and byte alignment.  If this is
not resolved in further discussion, support for both alternatives may
be proposed.

The MPEG-4 Committee has forwarded a liaison statement saying payload
format for MPEG-4 SL streams is complete.  Whilst major progress has
been made, it is clear that there are a relatively small number of
technical issues to resolve, and a fairly large number of editorial
clarifications.  We expect this to be completed by the time of the
London meeting.

New payload formats at this meeting: the Ogg Vorbis audio codec and
MPEG-4 FlexMux streams.  Vorbis is expected to be straightforward
(only major issue is compression codebooks, which may require out of
band transport).  The FlexMux draft is in a very early stage of
development, and needs major editorial work.  We expect there are a
number of issues to be resolved before it is complete.

					     -- Steve & Colin




From rem-conf Fri Mar 23 09:34:53 2001 
From rem-conf-request@es.net Fri Mar 23 09:34:53 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gVK1-0005nn-00; Fri, 23 Mar 2001 09:25:57 -0800
Received: from pcp000707pcs.wireless.meeting.ietf.org (purple.east.isi.edu) [135.222.64.207] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gVJz-0005nd-00; Fri, 23 Mar 2001 09:25:56 -0800
Received: from purple.east.isi.edu (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id MAA04181
	for ; Fri, 23 Mar 2001 12:25:21 -0500
Message-Id: <200103231725.MAA04181@purple.east.isi.edu>
To: rem-conf@es.net
Subject: Other work/charter update
Date: Fri, 23 Mar 2001 12:25:21 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Folks,

There have been a number of areas where progress has occured since the last
meeting, but which were not discussed in the AVT meeting yesterday. These
include: RFC 2833 errata, payload formats for meta-information, and the new
draft on precision audio/video. In addition, we need to re-charter the AVT
working group.

Regarding RFC 2833 errata, we note the following:
	- The MF S1...S3 codes have two code points, but need three. We
	  agreed, on the mailing list, to deprecate codes 142 and 143, 
	  and assign new numbers.
	- We may need to add a channel failure event to signal E1 loss of 
	  frame
	- What is the procedure for events longer than those which can be
	  represented in the duration field? Are continuation packets
	  acceptable?
Henning Schulzrinne will produce an updated draft addressing these issues.

At the San Diego meeting, two payloads for meta-information were presented.
The authors have been working on this since then, and believe it makes
sense to focus on a common (payload independent) set of mechanisms for
indicating and communicating metadata associated with RTP streams. For
example:
	- announcing sessions with associated metadata (SDP)
	- requesting streams with associated metadata (RTSP)
	- specifying the communication of metadata (in-band vs.
	  out-of-band, separate metadata stream vs. mixed media/meta-data
	  stream)
Subsequent to that, they will consider the matter of payload format(s)
themselves. We expect to see an update in future.

Chuck Harrison submitted a new draft on precision audio/video
(draft-harrison-avt-precision-av-00.txt). The abstract reads:
	This memo discusses methods for transporting audio-visual content
	over the Internet while meeting professional-quality temporal
	performance. This memo gives information about the timing
	requirements and synchronization practices in professional
	audio-visual production and exhibition. It is intended to initiate
	a discussion which may result in new or modified IETF standards
	which address the needs of this field.
We encourage you to read and comment on the issues raised by this draft,
since it is desirable that RTP can be used for studio quality audio/video.

We note that we have completed the vast majority of our milestones, and
that it is time to recharter (the current charter, goals and milestones 
are available from http://www.ietf.org/html.charters/avt-charter.html)

What are the next steps for the AVT working group? In the short term, we
need to finish the MPEG-4 and multiplexing (TCRTP) work which is on our
current charter, then write the existing work into the charter along with
milestones for completion (i.e. SRTP, unicast RTCP, RTCP feedback, RTCP-based 
retransmission, ULP/UXP, AMR, EVRC, Vorbis). Longer term, once RTP is a
draft standard, we need to advance the proposed standard payload formats -
which ones? - and guide development of new payload formats.

We propose the following new charter:

	The Audio/Video Transport Working Group was formed to specify a
	protocol for real-time transmission of audio and video over UDP and
	IP multicast.  This is the Real-time Transport Protocol, RTP,
	together with its associated profile for audio/video conferences
	and payload format documents. 

	The current goals of the working group are to complete the revision
	of RTP and the audio/video profile for draft standard, to review
	the existing payload formats to determine which of those are
	suitable for advancement to draft standard, to develop new RTP
	profiles relating to security, unicast feedback, and unicast RTCP,
	and to guide development of new payload formats. 

Regarding milestones, we propose to issue WG last call on:
	- RTP Testing Strategies (draft-ietf-avt-rtptest-04.txt)
	- Comfort Noise payload (draft-ietf-avt-rtp-cn-01.txt)
in the next few days. We will also submit a revision to the MIME
registration draft and request IESG last call on:
	- MIME registrations (draft-ietf-avt-rtp-mime-05.txt)
	- SDP RTCP BW modifiers (draft-ietf-avt-rtcp-bw-03.txt)
We propose to send the RTP specification and audio/video profile to the
area director for review in the next few days, for eventual publication
as a proposed standard.

Proposed milestones, for completion in Apr/May:
- AMR payload format to proposed standard
- CRTP to draft standard
- CRTP enhancements to proposed standard and TCRTP to BCP
- Combine RTCP feedback drafts to form a new profile
- Resolve ULP/UXP choice (send both to proposed, or chose one?)

Proposed milestones, for completion by the London meeting:
- RTP payload format for MPEG-4 multiple SL
- RTP payload format for EVRC
- RTP payload format for Vorbis
- RTCP feedback profile to proposed/experimental (depending on congestion
  control results)
- RTP payload format for Selective retransmission 
- Complete Unicast RTCP profile, start performance simulations
- Secure RTP profile to proposed standard
- ULP/UXP to proposed standard

Proposed milestones, for completion by the Salt Lake City meeting:
- Unicast RTCP profile to proposed
- RTP payload format for MPEG-4 FlexMux to proposed standard

We also need to advance the current proposed standard payload formats, and
other documents, to draft standard. At present, those eligible include:
	- H.261 		- Redundant audio
	- CellB 		- Generic FEC
	- H.263, H.263+ 	- Text conversation
	- MPEG 			- DTMF
	- Bundled MPEG 		- Real time pointers
	- BT.656 		- MIB
	- JPEG
Volunteers are solicited to work on revising these ready for draft standard.
Opinions on which are suitable for draft standard, which should remain at 
proposed, which should be declared historic are solicited.

Comments and suggestions are welcome.

Colin and Steve



From rem-conf Fri Mar 23 12:27:35 2001 
From rem-conf-request@es.net Fri Mar 23 12:27:34 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gY3C-0002XZ-00; Fri, 23 Mar 2001 12:20:46 -0800
Received: from host62-6-97-165.dialup.lineone.co.uk (Animator) [62.6.97.165] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14gY38-0002W6-00; Fri, 23 Mar 2001 12:20:44 -0800
From:     phantom 
To:        
Message-Id: <419.436973.86479861davelarge@timewarranties.fsnet.co.uk>
Subject: CAR FINANCE!!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Fri, 23 Mar 2001 12:20:44 -0800
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Need a car? Guarenteed acceptance on any make or model
We provide non status finance for the self employed, employed or the unemployed, 
regardless of previous credit history.
To qualify please fax 2 x bank statements, 2 x utillity bills and a copy of your driving 
licence or passport to 0113 279 8415 or give us a call on 0113 279 8413 to discuss 
your requirements.
Cars available from 40.00 inclusive of vat.

If you have received this e-mail in error please accept our most sincere apollogies.




From rem-conf Sat Mar 24 14:41:02 2001 
From rem-conf-request@es.net Sat Mar 24 14:41:01 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14gwKg-0004IR-00; Sat, 24 Mar 2001 14:16:26 -0800
Received: from 060upc075.chartermi.net (mail.chartermi.net) [24.213.60.75] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14gwKe-0004Hw-00; Sat, 24 Mar 2001 14:16:24 -0800
Received: from pop.chartermi.net ([24.213.46.11]) by mail.chartermi.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-71004U47242L33562S0V35)
          with SMTP id net for ;
          Sat, 24 Mar 2001 17:16:12 -0500
Date: Sat, 24 Mar 01 17:15:37 EST
From: barriesager@hotmail.com
To: rem-conf@es.net
Subject: MONEY TALKS - Please Read...This Really Works!
Message-ID: <>
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear rem-conf@es.net,

All I ask is that you take 5 minutes to read this and see what you think.  This works!

Try this... follow the directions exactly and it REALLY works!

PLEASE READ THESE FEW PAGES (IT WILL ONLY TAKE A FEW MINUTES OF YOUR TIME), AND SEE FOR YOURSELF.

*******PLEASE READ ONCE, AND THEN READ AGAIN*******

IT HAS WORKED SO WELL, THIS IS MY THIRD TIME AROUND.  I QUIT MY BORING JOB AND WORK AT THIS ABOUT ONE TO TWO HOURS A DAY PROCESSING ORDERS AND DRIVING TO THE BANK.

SO GO FOR IT!  YOU WILL BE GLAD YOU DID.  EARN $100,000 OR MORE PER YEAR JUST BY SENDING E-MAIL.

I felt compelled to share this with anyone interested in spending more time with their families, instead of at work.  It's an interesting story so read it all and see what I mean.

===========================================
"Parents of 15-year old kid find $71,000 cash hidden in his closet."
===========================================

********** Does this headline look familiar? **********

Of course it does.  You most likely have seen this story recently featured on a major nightly news program (USA).

This 15-year old's mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her son's closet.  Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash.  Five dollar bill, twenties, fifties, and hundred - all neatly rubber-banded and labeled.

"My first thought was that he robbed a bank," says the 41-year old mother.  "There was over $71,000 in that bag - that's more than my husband earns in a year."

The woman immediately called her husband at the car dealership where he worked and told him what she had discovered.  He came home right away and they drove together to the boy's school and picked him up.  Little did they suspect that where this money came from was more shocking than actually finding it in the closet.

As it turns out, the boy had been sending out via e-mail on the Internet a type of 'chain letter' to e-mail addresses that he got of the Internet.  Everyday after school for the past 2 months he had been doing this on his computer in his bedroom.

"I just got the e-mail one day and I figured what the heck.  I sent $5 to five people for the reports, put my name on it like the instructions said, and I started sending it out" says the clever 15-year old.  The reports I received for my $25 were fantastic.

The e-mail letter listed 5 addresses and contained instructions to send on $5 bill to each of the 5 individuals.  These individuals would in turn send me the 5 reports.  Put your name and mailing information in the number one position, move the person from 1 to the 2 position, the person from 2 to 3, 3 to 4, 4 to 5.  The letter goes on to state that you would receive several thousand dollars in $5 bills within 2 weeks if you sent out the letter with your name in the number 1 position.

"I get junk e-mail all the time and didn't think it was going to work" said the 15-year old boy.  Within the first few days of sending out the e-mail, the post office box that his parents had gotten him for his Video Game Magazine subscriptions began to fill up with not magazines, but envelopes containing $5 bills.

"About a week later I rode my bike down to the post office and my box had 1 magazine and about 300 envelopes stuffed in it.  There was also a yellow slip that stated that I had to go to the post office counter - I thought I was in trouble, but instead they had a whole box of mail for me….all envelopes with $5 bills.

Over the next few weeks, the boy continued sending out the e-mail.  "The money just kept coming in and I kept sorting it and stashing it in my closet."  He had been riding his bike to several area banks and exchanging the $5 bills for twenties, fifties, and hundreds.  "I didn't want the banks to get suspicious so I would go to different banks with like five-thousand at a time in my backpack.  I would usually say that my dad sent me in to exchange the money and was waiting outside.

Surprisingly, the boy didn't have any reason to be afraid.  The reporting news team examined and investigated the so-called 'chain letter' the boy was sending out and found that it wasn't a 'chain letter.'  In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Volume 16, Sections 255 and 436, which state a product or service must be exchanged.  Every $5 bill that he received, he immediately sent out the report requested.  This report made the letter legal because he was exchanging a service (sending the requested report) for a $5 fee.

The reports that you will receive and eventually send out are the power behind the program.  They include insider tips and techniques for cost effective promotion.  These reports are very comprehensive and will allow you to build and promote any business product or service on the Internet.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Here are instructions on how YOU can make thousands in cash.
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

******* Print this now for future reference *******

Read it often to fully understand how simple and easy works!

If you would like to make at least $50,000 in less than 90 days…

If not, please forward this to someone who would like to make this kind of money.  It really works (like designed), but only for those who follow this letter.  Please read this program, then read it again!
-------------------------------------------------------------------------------
There are two primary methods of building your downline:

METHOD #1:  SENDING BULK E-MAIL

Let's say that you decide to start small just to see how it goes.  We will assume that you and those involved send out only 5,000 e-mails each.  Let's also assume that the mailing receive only a 0.2% response.  (The response could be much better and people will send out more than 5,000 e-mails, but we are just assuming).

So, you send out 5,000 e-mails.  With a 0.2% response, that is only 10 orders for report #1.  Those 10 orders responded by sending out 5,000 e-mails each for a total of 50,000.  Out of those 50,000 e-mails again only 0.2% responded with orders.  Now that is 100 orders for report #2.

Those 100 orders send out 5,000 e-mails each for a total of 500,000 and with the 0.2% response, that is 1000 orders for report #3.  Those 1000 people send out 5,000 e-mails, with the 0.2% response, that is 10,000 orders for report #4.

Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 e-mails.  The 0.2% response gives you 100,000 orders for report #5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000 (half million).

Your total income in this example is:

$50 + $500 + $5,000 + $50,000 + $500,000 = $555,550

NUMBERS DO NOT LIE.  GET A PENCIL AND PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES.  NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE FAR MORE MONEY THAN YOU INVEST!  REMEMBER, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU E-MAILED.

Just think of what would happen if everyone, or even 1/3 of those people mailed 10,000 e-mails each or more?  There are over 150 million people on the Internet worldwide and counting.  Believe me, many people will do just that, and more!

METHOD #2:  PLACING FREE ADS ON THE INTERNET

Advertising on the Internet is very, very inexpensive and there are hundreds of FREE places to advertise.  Place a lot of free ads on the Internet will easily get a larger response.  However, we strongly suggest that you start with Method #1 and add Method #2 as you go along.  It is very easy to do!

For every $5 you receive, all you must do is e-mail them the report that they ordered.  That's it!

Always provide same day service on all orders.  This will guarantee that the e-mail they send out, with your name and address on it will be prompt because they cannot advertise until they have received the report from you.

Report #2 will show you the best methods for bulk e-mailing, and tell you where to obtain e-mail lists.

 …………………….INSTRUCTIONS …………………….

This method of raising capital REALLY WORKS 100% EVERY TIME.
I am sure that you could earn up to $500,000 or more in 90 days.

Before you say "Bull," please read this program carefully.

This is not a 'chain letter' but a perfectly legal money-making opportunity.  Basically, this is what you do:

As with all multi-level businesses, we build our business by recruiting new partners.  Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling.  You do it in your own home!

This is the greatest multi-level mail order marketing anywhere.  This is what you MUST do:

1.	Order all 5 reports from the 5 people listed
(you can't sell them if you don't order them)

·	For each report, send $5 cash, the NAME and NUMBER OF THE REPORT YOUR ARE ORDERING, YOUR E-MAIL ADDRESS, YOUR NAME AND RETURN ADDRESS (in case of a problem) and to the person whose name appears on the list next to the report.

MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS!

·	When you place your order, make sure you order each of the five reports.  You will need all 5 reports so that you can save them on your computer and resell them.

·	Within a few days you will receive, via e-mail, each of the five reports.  Save them on your computer so they will be accessible for you to send to the 1,000 or so people who will order them from you.

2.	IMPORTANT -- Do not alter the names of the people who are listed next to each report or their sequence on the list in any way other than what have been instructed in this document or you will lose out on the majority of the profits.

Once you understand the way this works, you'll see how it doesn't work if you don't follow the instructions exactly.  Remember, this method has been tested, and if you alter it, it WILL NOT WORK.

a.	After you've ordered the 5 reports, take the person in the #5 position and remove their name.  They have completed the cycle and are more than likely on their way to the bank..AGAIN!

b.	Move the name and address of #4 to the #5 position.

c.	Move the name and address of #3 to the #4 position.

d.	Move the name and address of #2 to the #3 position.

e.	Move the name and address of #1 to the #2 position.

f.	Insert YOUR name and address in the #1 position.

Please make sure you copy every name and address ACCURATELY!

3.	Take this entire letter, including the MODIFIED list of names, and save it on your computer.  Make NO changes to the instructions portion of this letter.

4.	Your cost to participate in this is practically nothing. (Surely you have $25 + 5 stamps).  You obviously already have an Internet connection and the e-mail is FREE!

To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with the invaluable marketing information which includes how to send bulk e-mail and where to find thousands of free classified ads and much, much more.

In addition, you will be provided with information on the Internet Marketing Clubs such as Internet Marketing Resources (IMR).  This is on of the premiere marketing clubs.  This club provides a forum where internet marketers from all over the world can exchange ideas and secrets on Internet marketing.

This club specializes in providing free Internet marketing tools and service for the Do-Yourself-Internet-Marketer.  They will provide you with free e-mail software and up to 1,000,000 fresh e-mail addresses each week.  They will also provide you with how to obtain free websites, how to obtain top rankings in search engines for your website, how to send bulk e-mail into AOL and CompuServe, how to market products on newsgroups, free classified ads, electronic malls, banner ads, and much more.

AVAILABLE REPORTS

**** Order each REPORT BY NUMBER ****

Notes:

n	Always send $5 cash (US currency) for each report.  Checks are not accepted because of clearance time.

n	Always send your order via first-class mail.

n	Make sure your cash is concealed by wrapping it in at least 2 sheets of paper, and include:

a.	The number of the report you are ordering.
b.	Your e-mail address, and
c.	Your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW:
________________________________________________________
REPORT #1:  The Insiders Guide to Advertising For Free on the Net

Order report #1 from:

Barrie A. Sager
915 N. Third St.
Ishpeming, MI  49849

________________________________________________________
REPORT #2:  The Insiders Guide to sending Bulk E-mail on the Net

Order report #2 from:

B. Watson
P.O. Box 8162
Augusta, GA  30905
USA

________________________________________________________REPORT #3:  The Secret to Multi-Level Marketing on the Net

Order report #3 from:

Aaron Croft
1037 Charlela Ln. #206
Elk Grove Village, IL  60007

________________________________________________________
REPORT #4:  How to become a Millionaire using MLM and the Net

Order report #4 from:

Cris Ardeleanu
5571 Dove Trace
Norcross, GA  30093

________________________________________________________
REPORT #5:  How to send 1 million e-mails for free

Order report #5 from:

Sandy Siliadi
5638 Friar Tuck Ct.
Lilburn, GA  30047

________________________________________________________

About 50,000 new people get online every month.

*** JUST GIVE THIS A TRY AND YOU WON"T BE SORRY ***

***  TIPS FOR SUCCESS  ***

1.	Treat this as your business.  Be prompt, professional, and follow the directions accurately.

2.	Send for the first 5 reports immediately so you will have them when your orders start coming in.  This is important because you MUST send out the requested product/report for every $5 you receive.

3.	Always provide same day service on the orders you receive.

4.	Be patient and persistent with this program.  If you follow the instructions exactly, your results will be successful.

5.	Above all, have faith in yourself and know you will SUCCEED!

THANK YOU FOR YOUR TIME AND CONSIDERATION.

Please note:  If you need help with starting a business, registering a business name, learning how income tax is handled, etc. then contact your local office of the Small Business Administration at the following number:  1-800-827-5722 for free help and answers to any questions.  Also the Internal Revenue Service offers free help via the telephone and free seminars about business tax requirements.

Your earnings are highly dependent on your activities and advertising.  The information contained in this letter or the reports constitutes no guarantees stated or implied.  In the event that this letter constitutes a guarantee of any kind, that guarantee is now void.

The earnings amounts listed on this site and in the report are estimates only.  If you don't try it, you will never know!

It works - It's legal - It's Easy - So WHY NOT?

GOOD LUCK AND HAVE FUN!








From rem-conf Sat Mar 24 20:44:13 2001 
From rem-conf-request@es.net Sat Mar 24 20:44:11 2001
Received: from list by mail2.es.net with local (Exim 1.92 #1)
	for rem-conf-dist@es.net
	id 14h2Gq-0003vB-00; Sat, 24 Mar 2001 20:36:52 -0800
Received: from hse-ottawa-ppp160981.sympatico.ca ([64.229.144.96] helo=mail.serv.com)
	by mail2.es.net with smtp (Exim 1.92 #1)
	id 14h2Gk-0003uB-00; Sat, 24 Mar 2001 20:36:47 -0800
From: 
Subject: That Little Extra 
Date: Sat, 24 Mar 2001 20:00:48
Message-Id: <790.899828.489603@mail.serv.com>
Bcc:
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

AS SEEN ON NATIONAL TV: 
Making over half million dollars every 4 to 5 months right from 
your home !! 
THANK'S TO THE COMPUTER AGE AND THE INTERNET ! 
================================================== 
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! 
Before you say ''Bull'', please read the following. This is the 
letter you have been hearing about on the news lately. Due to the 
popularity of this letter on the Internet, a national weekly news 
program recently devoted an entire show to the investigation of 
this program described below, to see if it really can make people 
money. The show also investigated whether or not the program was 
legal. Their findings proved once and for all that there are 
''absolutely NO Laws prohibiting the participation in the program 
and if people can -follow the simple instructions, they are bound 
to make some mega bucks with only $25 out of pocket cost''. DUE 
TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS 
ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. 
This is what one had to say: ''Thanks to this profitable 
opportunity. I was approached many times before but each time I 
passed on it. I am so gladI finally joined just to see what one 
could expect in return for the minimal effort and money required. 
To my astonishment, I received total $610,470.00 in 21 weeks, 
with money still coming in." Pam Hedland, Fort Lee, New Jersey. 
=================================================== 
Here is another testimonial: "This program has been around for a 
long time but I never believed in it. But one day when I received 
this again in the mail I decided to gamble my $25 on it. I 
followed the simple instructions and walaa ..... 3 weeks later 
the money started to come in. First month I only made $240.00 but 
the next 2 months after that I made a total of $290,000.00. So 
far, in the past 8 months by re-entering the program, I have made 
over $710,000.00 and I am playing it again. The key to success in 
this program is to follow the simple steps and NOT change 
anything.'' More testimonials later but first, 
===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
If you would like to make at least $500,000 every 4 to 5 months 
easily and comfortably, please read the following...THEN READ IT 
AGAIN and AGAIN!!! 
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: 
=====Order all 5 reports shown on the list below ===== 
For each report, send $5 CASH (US FUNDS ONLY), THE NAME & NUMBER 
OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose 
name appears ON THAT LIST next to the report. MAKE SURE YOUR 
RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any 
mail problems. 
=== When you place your order, make sure you order each of the 5 
reports. You will need all 5 reports so that you can save them on 
your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. 
Within a few days you will receive, vie e-mail, each of the 5 
reports from these 5 different individuals. Save them on your 
computer so they will be accessible for you to send to the 
1,000's of people who will order them from you. Also make a 
floppy of these reports and keep it on your desk in 
case something happen to your computer. 
IMPORTANT - DO NOT alter the names of the people who are listed 
next to each report, or their sequence on the list, in any way 
other than what is instructed below in step '' 1 through 6 '' or 
you will loose out on majority of your profits. Once you 
understand the way this works, you will also see 
how it does not work if you change it. Remember, this method has 
been tested, and if you alter, it will NOT work !!! People have 
tried to put their friends/relatives names on all five thinking 
they could get all the money. But it does not work this way. 
Believe us, we all have tried to be greedy and then 
nothing happened. So Do Not try to change anything other than 
what is instructed. Because if you do, it will not work for you. 
Remember, honesty reaps the reward!!! 
1.... After you have ordered all 5 reports, take this 
advertisement and REMOVE the name & address of the person in 
REPORT # 5. This person has made it through the cycle and is no 
doubt counting their fortune. 
2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 
3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 
4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 
5.... Move the name & address in REPORT # 1 down TO REPORT # 2 
6.... Insert YOUR name & address in the REPORT # 1 Position. 
PLEASE MAKE SURE you copy every name & address ACCURATELY! 
========================================================== 
**** Take this entire letter, with the modified list of names, 
and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. 
Save this on a disk as well just in case if you loose any data. 
To assist you with marketing your business on the internet, the 5 
reports you purchase will provide you with invaluable marketing 
information which includes how to send bulk e-mails legally, 
where to find thousands of free classified ads and much more. 
There are 2 Primary methods to get this venture going: 
METHOD # 1: BY SENDING BULK E-MAIL LEGALLY 
========================================================== 
Let's say that you decide to start small, just to see how it 
goes, and we will assume You and those involved send out only 
5,000 e-mails each. Let's also assume that the mailing receive 
only a 0.2% response (the response could be much better but lets 
just say it is only 0.2%. Also many people will send out hundreds 
of thousands e-mails instead of only 5,000 each). 
Continuing with this example, you send out only 5,000 e-mails. 
With a 0.2% response, that is only 10 orders for report # 1. 
Those 10 people responded by sending out 5,000 e-mail each for a 
total of 50,000. Out of those 50,000 e-mails only 0.2% responded 
with orders. That's=100 people responded and ordered Report # 2. 
Those 100 people mail out 5,000 e-mails each for a total of 
500,000 e-mails. The 0.2% response to that is 1000 orders for 
Report # 3. Those 1000 people send out 5,000 e-mails each for a 
total of 5 million e-mails sent out. The 0.2% response to that is 
10,000 orders for Report # 4. Those 10,000 people send out 5,000 
e-mails each for a total of 50,000,000 (50 million) e-mails. The 
0.2% response to that is 100,000 orders for Report # 5 THAT'S 
100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). 
Your total income in this example is: 1..... $50 + 2..... $500 + 
3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand 
Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND 
FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU 
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! 
========================================================= 
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE 
ORDERING OUT OF 5,000 YOU MAILED TO. 
Dare to think for a moment what would happen if everyone or half 
or even one 4th of those people mailed 100,000e-mails each or 
more? There are over 150 million people on the Internet worldwide 
and counting. Believe me, many people will do just that, and 
more! 
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET 
======================================================= 
Advertising on the net is very very inexpensive and there are 
hundreds of FREE places to advertise. Placing a lot of free ads 
on the Internet will easily get a larger response. We strongly 
suggest you start with Method # 1 and dd METHOD # 2 as you go 
along. For every $5 you receive, all you must do is e-mail them 
the Report they ordered. That's it. Always provide same day 
service on all orders. This will guarantee that the e-mail they 
send out, with your name and address on it, will be prompt 
because they can not advertise until they receivethe report. 
=========== AVAILABLE REPORTS ==================== 
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: 
Always send $5 cash (U.S. CURRENCY ONLY!!) for each Report. 
Checks NOT 
accepted. Make sure the cash is concealed by wrapping it in at 
least 2 sheets of paper. On one of those sheets of paper, Write 
the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL 
ADDRESS and your name and postal address. 
PLACE YOUR ORDER FOR THESE REPORTS NOW : 
==================================================== 
REPORT # 1: "The Insider's Guide to Advertising for Free on the 
Net" Order Report #1 from: 

B. McDonald
Suite 409
1500 Bank St
Ottawa, ON
K1H 1B8
Canada
___________________________________________________________ 
REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the 
Net" Order Report # 2 from: 

T. Richardson
P.O. Box 753
Richland, MO. 65556
USA 
____________________________________________________________ 
REPORT # 3: "Secret to Multilevel Marketing on the Net" 
Order Report # 3 from : 

C.J. Kalata 
P.O. Box 130157 
Roseville, MN 55113
USA 
____________________________________________________________ 
REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" 
Order Report # 4 from:

R. B. 
Box. 21115, 
Grande Prairie 
Alberta, T8V-6W7 
Canada 
____________________________________________________________ 
REPORT #5: "How to Send Out 0ne Million e-mails for Free" 
Order Report # 5 from: 

B. Taylor 
P.O.Box 26001 
Fredericton, N.B. 
E3A 5V8 
Canada
_____________________________________________________________ 
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ 
Follow these guidelines to guarantee your success: 
=== If you do not receive at least 10 orders for Report #1 within 
2 weeks, continue sending e-mails until you do. 
=== After you have received 10 orders, 2 to 3 weeks after that 
you should receive 100 orders or more for REPORT # 2. If you did 
not, continue advertising or sending e-mails until you do. 
=== Once you have received 100 or more orders for Report # 2, YOU 
CAN RELAX, because the system is already working for you, and the 
cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: 
Every time your name is moved down on the list, you are placed in 
front of a Different report. 
You can KEEP TRACK of your PROGRESS by watching which report 
people are ordering from you. IF YOU WANT TO GENERATE MORE 
INCOME SEND ANOTHER BATCH OF E-MAILS AND START 
THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this 
business !!! 
====================================================== 
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS 
PROGRAM: You have just received information that can give you 
financial freedom for the rest of your life, with NO RISK and 
JUST A LITTLE BIT OF EFFORT. You can make more money in the next 
few weeks and months than you have ever imagined. Follow the 
program EXACTLY AS INSTRUCTED. Do Not change it in any way. It 
works exceedingly well as it is now. 
Remember to e-mail a copy of this exciting report after you have 
put your name and address in Report #1 and moved others to #2 
..........# 5 
as instructed above. One of the people you send this to may send 
out 100,000 or more e-mails and your name will be on every one of 
them. Remember though, the more you send out the more potential 
customers you will reach. 
So my friend, I have given you the ideas, information, materials 
and opportunity to become financially independent. IT IS UP TO 
YOU NOW ! 
============ MORE TESTIMONIALS ================ 
"My name is Mitchell. My wife, Jody and I live in Chicago. I am 
an accountant with a major U.S. Corporation and I make pretty 
good money. When I received this program I grumbled to 
Jodyaboutreceiving ''junk mail''. I made fun of the whole 
thing,spoutingmy knowledge of the population and percentages 
involved. I ''knew'' it wouldn't work. Jody totally ignored 
my supposed intelligence and few days later she jumped in with 
both feet. I made merciless fun of her, and was ready to lay the 
old ''I told you so'' on her when the thing didn't work. Well, 
the laugh was on me! Within 3 weeks she had received 50 
responses. Within the next 45 days she had received total $ 
147,200.00 ........... all cash! I was shocked. I have joined 
Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois 
====================================================== 
''Not being the gambling type, it took me several weeks to make 
up my mind to participate in this plan. But conservative that I 
am, I decided that the initial investment was so little that 
there was just no way that I wouldn't get enough orders to at 
least get my money back''. '' I was surprised when I found my 
medium size post office box crammed with orders. I made 
$319,210.00in the first 12 weeks. The nice thing about this deal 
is that it does not matter where people live. There simply isn't 
a better investment with a faster return and so big." 
Dan Sondstrom, Alberta, Canada 
======================================================= 
''I had received this program before. I deleted it, but later I 
wondered if I should have given it a try. Of course, I had no 
idea who to contact to get another copy, so I had to wait until I 
was e-mailed again by someone else.........11 months passed then 
it luckily came again...... I did not delete this one! I made 
more than $490,000 on my first try and all the money came within 
22 weeks." Susan De Suza, New York, N.Y. 
======================================================= 
''It really is a great opportunity to make relatively easy money 
with little cost to you. I followed the simple instructions 
carefully and within 10 days the money started to come in. My 
first month I made $20,560.00 and by the end of third month my 
total cash count was $362,840.00. Life is beautiful, Thanx to 
internet.". Fred Dellaca, Westport, New Zealand 
======================================================= 
ORDER YOUR REPORTS TODAY AND GET STARTED ON 
'YOUR' ROAD TO FINANCIAL FREEDOM ! 
======================================================= 
If you have any questions of the legality of this program, 
contact the Office of Associate Director for Marketing Practices, 
Federal Trade Commission, Bureau of Consumer Protection, 
Washington, D.C. 
 
 
 
 
 
 
 
 
 



From rem-conf Sat Mar 24 23:57:36 2001 
From rem-conf-request@es.net Sat Mar 24 23:57:35 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14h5Lv-0006kg-00; Sat, 24 Mar 2001 23:54:19 -0800
Received: from sm8.texas.rr.com [24.93.35.220] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14h5Ls-0006kF-00; Sat, 24 Mar 2001 23:54:17 -0800
Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200])
	by sm8.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P7pcTY024255
	for ; Sun, 25 Mar 2001 01:52:24 -0600
Message-Id: <200103250752.f2P7pcTY024255@sm8.texas.rr.com>
X-Sender: hermag@excite.com
From: "hermag@excite.com" 
To: rem-conf@es.net
Date: Sun, 25 Mar 2001 01:49:06 -0600
Subject: Would you like to recieve information on how to register your pet online for free?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__17901866_6546.45"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a Multipart MIME message.

------=_NextPart_000_001__17901866_6546.45
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__17901866_6546.45
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4
dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93
IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg
eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro
ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi
amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw
PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg
dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl
bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0
IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i
b2R5Pg0KPC9odG1sPg0K

------=_NextPart_000_001__17901866_6546.45--




From rem-conf Sun Mar 25 00:40:14 2001 
From rem-conf-request@es.net Sun Mar 25 00:40:14 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14h62p-0000Sb-00; Sun, 25 Mar 2001 00:38:39 -0800
Received: from (colart.co.kr) [203.233.105.82] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14h62m-0000RQ-00; Sun, 25 Mar 2001 00:38:36 -0800
Received: from mail.iupi.pt (unverified [203.177.38.150]) by www.woosea.com
 (EMWAC SMTPRS 0.83) with SMTP id ;
 Sun, 25 Mar 2001 17:39:53 +0900
Message-ID: <000021ca1d54$0000304f$00002028@id.ru>
To: 
From: ttzyh@id.ru
Subject: Opportunity in the investigative profession          {
Date: Sat, 24 Mar 2001 23:59:42 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list






 Thank you for your interest!

  
                         

 14



 

Judgment Courses offers an extensive Audio training

course in 
 "How to Collect Money Judgments"
  .



If you are like many people, you are not even sure what a

Money Judgment is and 
 why processing Money Judgments

can earn you very substantial income
  .



If you ever sue a company or a person and you win then you

will have a Money Judgment against them.



You are happy you won but you will soon find out the

shocking fact: "Its now up to you to collect on the

Judgment". The court does not require the loser to pay you.

The court will not even help you. You must trace the loser

down, find their assets, their employment, bank accounts,

real estate, stocks and bonds, etc.



Very few people know how to find these assets or what to do

when they are found. The result is that millions of

Judgments are just sitting in files and being forgotten.



"In 79% of the cases the winner of a Judgment never sees a

dime."



The non-payment of judicial debt has grown to epidemic

proportions. Right now in the United States there is

between 
 200 and 300 billion dollars of uncollected Money<=
BR>
Judgment debt
  . For every Judgment that is paid, 5 more

Judgments take its place.



We identified this massive market 8 years ago and have

actively pursued Judicial Judgments since. We invented this

business. We have perfected it into a well proven and solid

profession in which only a select few will be trained in the

techniques necessary to succeed.



With our first hand experience we have built a course which

teaches you how to start your business in this new unknown

and exciting field of processing Money Judgments.



By following the steps laid out in our course and with

reasonable effort you can become very successful in the

processing of Money Judgments.



The income potential is substantial in this profession. 
 We

have associates who have taken our course and are now

working full time making $96,000.00 to over $200,000.00 per

year. Part time associates are earning between $24,000.00

and $100,000.00 per year 
 . Some choose to operate out of

their home and work by themselves. Others build a sizable

organization of 15 to 25 people in attractive business

offices.



Today our company and our associates have over 126

million dollars in Money Judgments that we are currently

processing. Of this 126 million, 25 million is in the form

of joint ventures between our firm and our associates.

Joint ventures are where we make our money. We only break

even when our course is purchased. We make a 12% margin on

the reports we supply to our associates. Our reporting

capability is so extensive that government agencies, police

officers, attorneys, credit agencies etc., all come to us

for reports.





Many of our associates already have real estate liens in

force of between 5 million to over 15 million dollars.

Legally this means that when the properties are sold or

refinanced our associate must be paid off. The norm is 10%

interest compounded annually on unpaid Money Judgments.

Annual interest on 5 million at 10% translates to

$500,000.00 annually in interest income, not counting the

payment of the principal.



Our associates earn half of this amount or $250,000.00 per

year. This is just for interest, not counting principle

and not counting the compounding of the interest which can

add substantial additional income. Typically companies are

sold for 10 times earnings. Just based on simple interest

an associate with 5 million in real estate liens could sell

their business for approximately 2.5 million dollars.




 92% of all of our associates work out of their ho=
me; 43%

are women and 36% are part time
  .



One of the benefits of working in this field is that you are

not under any kind of time frame. If you decide to take off

for a month on vacation then go. The Judgments you are

working on will be there when you return. The Judgments

are still in force, they do not disappear.



The way we train you is non-confrontational. You use your

computer and telephone to do most of the processing. You

never confront the debtor. The debtor doesn't know who you

are. You are not a collection agency.



Simply stated the steps to successful Money Processing

are as follows:



Mail our recommended letter to companies and individuals

with Money Judgments. (We train you how to find out who

to write to)



8% to 11% of the firms and people you write will call you

and ask for your help. They call you, you don't call them

unless you want to.



You send them an agreement (supplied in the course) to

sign which splits every dollar you collect 50% to you and

50% to them. This applies no matter if the judgment is for

$2,000.00 or $2,000,000.00.



You then go on-line to our computers to find the debtor

and their assets. We offer over 120 powerful reports to

assist you. They range from credit reports from all three

credit bureaus, to bank account locates, employment

locates, skip traces and locating stocks and bonds, etc.

The prices of our reports are very low. Typically 1/2 to

1/3 of what other firms charge. For example we charge

$6.00 for an individuals credit report when some other

companies charge $25.00.



Once you find the debtor and their assets you file

garnishments and liens on the assets you have located.

(Standard fill in the blanks forms are included in the

course)



When you receive the assets you keep 50% and send 50% to

the original Judgment holder.



Once the Judgment is fully paid you mail a Satisfaction of

Judgment to the court. (Included in the course)



Quote's from several of our students:



Thomas in area code 516 writes us: "I just wanted to drop

you a short note thanking you for your excellent course. 
 My

first week, part time, will net me 3,700.00 dollars
  . Your

professionalism in both the manual and the video opened

doors for me in the future. There's no stopping me now.

Recently Thomas states he has over $8,500,000 worth of

judgments he is working on.



After only having this course for four months, Larry S. in

area code 314 stated to us: " 
 I am now making $2,000.00 per

week 
 and expect this to grow to twice this amount with=
in the

next year. I am having a ball. I have over $250,000 in

judgments I am collecting on now."



After having our course for 7 months Larry S. in 314 stated

" 
 I am now making $12,000.00
  per month and have approximately

$500,000.00 in judgments I am collecting on. Looks like I

will have to hire someone to help out"



Marshal in area code 407 states to us "I feel bad, you only

charged me $259.00 for this course and it is a goldmine. I

have added 3 full time people to help me after only having

your course for 5 months"



>From the above information and actual results you can see

why we can state the following:



With our course you can own your own successful business.

A business which earns you substantial income now and one

which could be sold in 3-5 years, paying you enough to

retire on and travel the world. A business which is

extremely interesting to be in. A Business in which every

day is new and exciting.



None of your days will be hum-drum. Your brain is

Challenged. A business, which protects you from Corporate

Downsizing. A business which you can start part time from

your home and later, if you so desire, you can work in full

time. A business, which is your ticket to freedom from

others telling you what to do. A business, which lets you

control your own destiny. Our training has made this happen

for many others already. Make it happen for you!



If the above sounds interesting to you then its time for you

to talk to a real live human being, no cost or obligation

on your part.




 Please call us at 1-4 0 6--6 5 2--0 1 9 4 
 .



We have 
 Customer Support staff available to you from 8:00=
am to

9:00pm (Mountain Time) 7 days a week
  . If you call this number

you can talk to one of our experienced Customer Support personnel.

They can answer any questions you may have - with no obligation.

Sometimes we run special pricing on our courses and combinations

of courses. When you call our Customer Support line they can let

you know of any specials we may be running. If you like what you

read and hear about our courses, then the Customer Support person

can work with you to place your order. We are very low key. We

merely give you the facts and you can then decide if you want to

work with us or not.



Thank you for your time and interest.


































 +++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++

This ad is produced and sent out by:

Universal Advertising Systems

To be removed from our mailing list please email us at 

tammismith@freeze.com with remove in the subject line or

call us toll free at 1-888-605-2485 and give us your email address or writ=
e us at:

Central DB Removal, PO Box 1200, Oranjestad, Aruba

++++++++++++++++++++++++++++++++++++++++++++++++++++++++




 









From rem-conf Sun Mar 25 01:56:57 2001 
From rem-conf-request@es.net Sun Mar 25 01:56:56 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14h7Dw-0002LE-00; Sun, 25 Mar 2001 01:54:12 -0800
Received: from c371273-a.frndl1.wa.home.com (John Mack) [24.176.72.159] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14h7Dc-0002Ky-00; Sun, 25 Mar 2001 01:53:58 -0800
From: "Dakota Rae" 
To: 
Subject: "VIAGRAS COUNTERPART"
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sun, 25 Mar 2001 01:52:22
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

www.darnnearanything.com

WOMEN DON'T WANT TO TALK ABOUT IT...

THEY JUST WANT TO DO SOMETHING ABOUT IT

AND FINALLY SOMEONE DID!

          The Men Have "Viagra"
                     and now
          The Women Have "VIACREME"
 
Viacrème For Women is a patented formula which has been clinically 
evaluated by female nurses and doctors.  Women who have used 
ViaCreme have reported greater sexual sensitivity and arousal.  
ViaCreme is proven effective even for women who suffer from 
extreme sexual dysfunction associated with surgery or menopause, and 
has been proven to enhance female and male orgasms.

Viacrème For Women is convenient to use and, unlike viagra, 
ViaCreme does not require a perscription. 
 
    
      "VIACREME DOES NOT REQUIRE A PRESCRIPTION"

For more info on this product or to order click on or paste:
www.darnnearanything.com

By not responding to this offer you will automatically be removed 
>from our list.

         "SOME VIACREME USER'S TESTIMONIALS"

Alicia - 51 years old
The more I use Viacrème the more I find myself thinking about sex! 

June - 43 years old 
I had lost interest in intimate relations with my husband until Viacrème. 
I thought something was wrong with me. Now we are intimate like when 
we were first married. I can't wait until our vacation. I will pack the 
Viacrème first!

Stella - 58 years old
My husband is so loving now that I have found sex fun again. 
He is like the "young buck" I married years ago.

Lynn
I had a full hysterectomy at an early age and due to that a lot of 
physical changes that I wasn't mentally ready to deal with. 
Viacreme has put that smile back on my husbands face. 
When somebody asks 'does it work?', my husband will 
smile and say, "Oh yeah does it ever!"

Liz - 42 years old
My husband has found new life with Viagra. 
With Viacrème for me, our life is now perfect! 

June - 37 years old  
I have not had feeling like this for fifteen years. I love it! 
My husband is the happiest I have seen him in years.

Aurora - a young 50 years old - NY  
Already having gone through menopause, I think most women 
can appreciate that 'syndrome'. I can tell you this product has 
truly improved the quality of my life. ViaCreme has helped my 
husband and I extend the beautiful intimacy that we have always 
known as best friends, put the bounce back in our step and just 
the way we look at each other. I really am thrilled with the product.


www.darnnearanything.com



From rem-conf Sun Mar 25 04:08:35 2001 
From rem-conf-request@es.net Sun Mar 25 04:08:34 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14h9Dp-0005HL-00; Sun, 25 Mar 2001 04:02:13 -0800
Received: from sparc20.guomai.sh.cn (sparc20.guomai.sh.cn.) [202.96.206.74] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14h9Df-0005Gt-00; Sun, 25 Mar 2001 04:02:03 -0800
Received: from 63.49.48.88 (pool-63.49.48.88.tmpa.grid.net [63.49.48.88])
	by sparc20.guomai.sh.cn. (8.9.0/8.9.0) with SMTP id UAA04342;
	Sun, 25 Mar 2001 20:02:15 +0800 (CST)
From: wolkie@yahoo.de
Message-Id: <200103251202.UAA04342@sparc20.guomai.sh.cn.>
Subject: ACT NOW! BECOME A MILLIONAIRE ON THE INTERNET
Date: Fri, 23 Mar 01 22:39:26 Eastern Standard Time
Reply-To: wolkie@yahoo.de
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Priority: 1
X-MSMailPriority: High
Importance: High
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_018C_01BD9940.715D52A0"
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_018C_01BD9940.715D52A0
Content-Type: text/html;





 THANKS TO THE COMPUTER AGE AND THE INTERNET!



===============================================



BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!



Before you say "Nonsense", please read the following. This

is the letter you have been hearing about on the news

lately. Due to the popularity of this letter on the

Internet, a national weekly news program recently devoted an

entire show to the investigation of this program described

below , to see if it really can make people money.



The show also investigated whether or not the program was

legal. Their findings proved once and for all that there are

''absolutely NO. Laws prohibiting the participation in the

program and if people can follow the simple instructions,

they are bound to make some mega bucks with only $25 out of

pocket cost''.



This e-mail holds the keys to the secrets of opening the

doors of E-COMMERCE, the information highway, the wave of

the future, THE INTERNET!



One Time-Initial Investment:  $20.00



Before you delete this e-mail, please read it through to see

if this would be something that would interest you.  --  IT

IS NOT SPAM!!



If you could find an easier way to make a higher income,

would you pursue it?



If you had more money to pay your bills, would you spend

more time with your family and less time at work?



If you could find a business that would generate money while

you were doing what you wanted, would you invest in it?  THE

INVESTMENT IN THIS PROGRAM IS $20.



Here is a money  making program you can start immediately

without any debt.  The only expense so far is the $20 to

order the reports and your time to read and reread the

program.



THIS IS A LEGITIMATE, LEGAL, MONEY MAKING PROGRAM!!!  Read

on...



Basically, this is what you do:  As with all multi-level

businesses, you build your business by recruiting new

partners and selling your product.  You offer a product for

EVERY DOLLAR sent to you.  You will NEVER defraud anyone

because you deliver what you promise.



Before you delete this e-mail, print it off and read it

thoroughly.  Be sure that you don't miss any of the points

outlined.  Then put it down, think about it, and read it

again.  I am sending you a whole lot of information in which

you might not fully digest the first time you read through

all this info.



If you don't believe this program will work for you, send it

to 10-20 of your closest friends (in which you trust

deeply), and ask them what they think.  This program really

works!  DON'T MISS THIS OPPORTUNITY!  Of course, your

friends will also want to participate!



Due to the popularity of this program on the Internet, a

major Nightly News Program recently dedicated an entire show

to the investigation of the program to see if it really made

money.  The show also investigated whether or not the

program was legal.  Their findings proved that there are

absolutely no laws prohibiting the participation in the

program. This has helped to show people like you that this

is a simple, harmless and fun way to make extra money at

home.



Even so, if you are still worried or skeptical about the

legal aspects of the program, check it out with the U.S.

Postal Service (1-800-725-2161) and they will confirm that

this is a legal program. After determining that it is legal,

ask yourself, "WHY NOT!?!?"



The results of this MLM program have been truly remarkable.

So many people are participating that everyone involved are

doing much better than ever before.  Since everyone makes

more, as more people try it out, it has been very exciting.



You may have heard this story before, but recently Donald

Trump appeared on the David Letterman Show.  Dave asked him

what he would do if he lost everything and had to start over

>from scratch.  Without hesitating, Trump said he would find

a good network marketing program and get to work.  The

audience started to hoot and boo him.  He looked out at the

audience and dead-panned his response, "That's why I am

sitting up here and you all are sitting out there!"



Multi-Level Marketing has gained respectability.  It is

being taught in the Harvard Business School, and both

Stanford Research and the Wall Street Journal have stated

that between 50% and 65% of all goods and services will be

sold through multi-level methods by 2005.



You will only understand the program if you get involved.

The entire plan is outlined below.  Print this now for

future reference.  Better yet, download it to your computer

and save it for future modification and use.



Unsure how you would find a reliable, yet affordable, bulk

e-mail company...when you order Report #1, information is

included on 3 very reliable companies that have committed to

making this program work.



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$



This program has the potential to make $50,000 in less than

90 days! It really works, but you must follow the

instructions to the letter.



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$



THIS IS A LEGITIMATE, LEGAL, MONEY MAKING PROGRAM!!!  It

does not require you to come into contact with people or

make or take any telephone calls.  All that is required is a

computer and an Internet connection.  You obviously already

have that or you would not have received this e-mail.  Just

follow the instructions and this simplified e-mail marketing

program will work 100% for you EVERY TIME!



E-mail is the sales tool of the future.  Take advantage of

this virtually free method of advertising NOW!  The longer

you wait, the more people will be doing business on the

Internet.  Be one of the first in the relatively new

frontier.



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$



A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:



By the time you have read the program outlined below, you

should have concluded that such a program, one that is a

legal multi-level marketing program, could not have been

created by an amateur entrepreneur.  Let me tell you a

little about myself.  I had a profitable business for 10

years.  Then in 1979 my business began falling off.  I was

doing the same things that were previously successful for

me, but it wasn't working.



Finally, I figured it out.  It wasn't me, it was the

economy.  Inflation and recession had replaced the stable

economy that had been with us since 1945.  I don't have to

tell you what happened to the unemployment rate, because

many of you know first-hand.  There were more failures and

bankruptcies than every before.  The middle class was

vanishing.  Those who knew what they were doing invested

wisely and moved up.  Those who did not, including those who

never had anything to save or invest, were moving down into

the ranks of the poor.  As the old saying goes, THE RICH GET

RICHER AND THE POOR GET POORER.



The traditional methods of business will never allow you to

move up or make more money, inflation will see to that.  You

have just received a program that will help you start the

business you have always wanted to start.  This is the

reason I wrote and developed the four reports offered in

this program.



THERE IS NO RISK AND LITTLE EFFORT ON YOUR PART.  You will

make more money in the next few months than you ever

imagined.  You will become debt free and be able to invest

wisely.



I should point out that I will not see a penny of this money

as I have retired from the program after sending thousands

and thousands e-mails. I am ready to relax and enjoy my

retirement!  I created this program so that I could make

enough money to enjoy life.  It really worked for me!



Follow the program EXACTLY AS INSTRUCTED.  Do not change it

in any way. It works exceedingly well as it is now.

Remember to e-mail a copy of this exciting report to

everyone you can think of.  One of the people you send this

to may send out 50,000 e-mails and your name will be on

everyone of them!



Remember though, the MORE YOU SEND OUT, the more potential

customers you will reach.  So, I have given you the ideas,

information, materials, and opportunity to become

financially independent.



I don't want to try to tell the future, but with interest

rates climbing and spending the way it is today, I am afraid

the federal government will force us into another recession.

You need to look out for your future.



IT IS UP TO YOU!!  NOW DO IT!!!  -  Jody Jacobs, Richmond,

VA



************************************************************



Before you delete this from your Inbox, save it to your

computer, print it out, read it and then read it again.

Take the time to REALLY THINK ABOUT IT.  Get a pencil and

figure out what could happen when you participate.  Figure

out the worst possible response and no matter how you

calculate it, you will still make a lot of money with this

program. You will definitely get back the $20 you have

invested.  Any doubts you have will vanish when your first

orders come in.



$$$$$  IT REALLY WORKS!!!  GIVE IT A TRY!!! $$$$$



This is not a chain letter, but a perfectly legal, money

making MLM business.  As with all multi-level businesses,

Amway being a good example, you build your business by

recruiting new partners and selling your products.



Every state in the United States allows you to recruit new

multi-level business partners, and this program sells and

delivers a product for every dollar received.



This is a multi-billion dollar industry and of the 500,000

millionaires in the U.S. today, 20% (100,000) made their

fortune in the last several years in MLM programs.

Moreover, statistics show 45 people become millionaires

everyday through Multi-Level Marketing Programs.



With network marketing, you have two sources of income.

Direct commissions from sales you make yourself and

commissions from sales made by people you introduce to the

business.



Residual income in the secret of the wealthy.  It means

investing time or money once and getting paid again and

again and again.  In network marketing, it also means

getting paid for the work of others.



The orders for the reports come by the U.S. Postal Service

and you fill the orders by e-mail, so you are not involved

in personal selling.  You do it privately in your own home,

store, or office.  This is the EASIEST marketing plan you

will find anywhere.  It is simply order-filling by e-mail!

The products are informational and instructional materials,

keys to the secrets of opening the doors of  E-COMMERCE, the

information highway, the wave of the future, THE INTERNET!



************************************************************



THE SUMMARY OF THE PLAN IS THIS:



1. You order the 4 reports listed below ($5 each) through

the U.S. Postal Service.  They come to you by e-mail.



2. Save a copy of this entire e-mail and then place your

name under Report #1 and move the other names down, removing

the name under Report #4, as that person has completed the

cycle.



3. When Report #1 comes to you via your e-mail, contact one

of the bulk e-mail companies listed and have them send your

e-mail as soon as possible.  As soon as you can get started

sending e-mails, you are on your way.  Begin sending out

your e-mail with your name under Report #1.



4. Orders for the reports will come to you by the U.S.

Postal Service with $5 cash for each report. You will simply

then e-mail the reports as they are ordered, along with the

"Welcome" e-mail text you receive when you get the reports.



Is this not as simple as it gets?  There are already over 50

million e-mail addresses available, with millions more

joining the Internet each year.  Don't worry about running

out or over-saturation of the market. People are used to

seeing and hearing the same advertisements every day on TV

and radio.  How many times have you received the same pizza

flyers and then one day you decide you are hungry for the

pizza and decide to try it.  This program works the same

way!



************************************************************



YOU CAN START THE PROCESS TODAY, JUST FOLLOW THESE FOUR EASY

STEPS:



STEP #1 - ORDER THE REPORTS



Order the four reports shown on the address list below (you

can't sell them, if you don't order them).  Address four

separate envelopes and send $5.00 cash for each report ($20

total), enclose a sheet of paper that includes the NAME OF

THE REPORT YOU ARE ORDERING, YOUR E-mail ADDRESS, AND YOUR

NAME & RETURN ADDRESS (in case there is a problem) to the

four persons whose names appear on the list next to the four

reports.



Make sure your RETURN ADDRESS is on the outside of each of

the four envelopes you send the cash in, in case of any U.S.

Postal Service problems.  Within a few days, you will

receive by e-mail, each of the four reports.  Detach the

reports onto your computer so you can send them to the

thousands of people who will order from you.  It's always

good to back a backup disk with all the e-mail text and the

reports, just in case!  This will save you lots of heartache

later!



STEP #2 - ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look

below for the listing of the four reports, along with the

addresses of the folks you will order from.



b. After you have ordered all four reports, delete the name

and address under REPORT #4.  This person has made it

through the cycle.



c. Move the name and address under REPORT #3 down to REPORT

#4.



d. Move the name and address under REPORT #2 down to REPORT

#3.



e. Move the name and address under REPORT #1 down to REPORT

#2.



f. Insert your name and address under the REPORT #1

position.  Please make sure you COPY ALL INFORMATION, every

name and address, ACCURATELY! THIS IS VERY IMPORTANT!



STEP #3 - COPY THIS ENTIRE E-MAIL AND SAVE IT TO YOUR

COMPUTER



After you have modified this e-mail text by removing the

name under REPORT #4, moving all names down, and adding YOUR

NAME under REPORT #1, copy the entire e-mail and save it to

your computer.  Make NO CHANGES to these instructions.  You

now have an e-mail to send to your prospects. It's always

better to copy and paste your text, rather than just

forwarding the e-mail-it makes for a much cleaner and easier

to read e-mail each time it is sent!



STEP #4 - BEGIN YOUR E-MAIL MARKETING PROGRAM



When you receive REPORT #1, it will teach you how to

download bulk e-mail software and e-mail addresses so you

can send your e-mail to thousands of people while you sleep!

Remember, 50,000+ new people are joining the Internet every

month!  Your cost to participate in this program is the

initial $20 for the reports and the initial bulk mailing

cost.  You obviously already have a computer and an Internet

connection and this e-mail is FREE!



************************************************************



There are two primary methods of building your company:



METHOD #1  -  SENDING BULK E-MAILS



Let's say you decide to start small, just to see how it

goes, and we'll assume you and all those involved only send

2000 e-mails each.  Let's also assume that the mailing

receives only a 0.5% response.  (The response could

definitely be much better than this small percentage. Also,

many people will e-mail out thousands and thousands of e-

mails, rather than the 2000 we are estimating here.)  But,

continuing with this example, 2000 e-mails at 0.5% response,

this is 10 orders for REPORT #1.  Those 10 people respond by

sending out 2000 e-mails, for a total of 20,000.



Out of those 0.5%, 100 people respond and order REPORT #2.

Those 100 people e-mail 2000 programs each for a total of

200,000.



The 0.5% response to that is 1000 orders for REPORT #3.

Those 1000 send out 2000 programs each for a 2,000,000

total!



The 0.5% response to that is 10,000 orders for REPORT #4.

That's 10,000 $5 bills for you.  CASH!!!



Your total income for this example is $50 + $500 + $5000 +

$50,000, for a total of $55,550!



Remember, this is assuming 1,900 out of the 2,000 people you

e-mail to will DO ABSOLUTELY NOTHING and trash this e-mail!

What would happen if half of the people you e-mail sent out

10,000 programs, instead of 2000!  Many people will do just

that, and more!



METHOD #2 - PLACING FREE ADS ON THE INTERNET



Advertising on the Internet is very, very inexpensive, and

there are hundreds of FREE places to advertise.  Start small

and decide for yourself how well it works.



Assume your goal is to get only 10 people to participate on

your first attempt.  Also assume that everyone else in your

program gets only 10 downline members.  Look how this small

number accumulates to achieve the STAGGERING results below:



1st level - your first 10 send you

$5........................................$50



2nd level - 10 members from those 10 ($5 x 100)

.........................................$500



3rd level - 10 members from those 100 ($5 x

1000).....................................$5,000



4th level - 10 members from those 1000 ($5 x 10,000)

.........................................$50,000



$$$$  THIS TOTALS.........................$55,550



Have any idea what 10,000 $5 bills look like piled up on

your kitchen table?  IT'S AWESOME!!!!!!



************************************************************



Amazing, isn't it!!  Remember, this assumes that the people

who participate only recruit 10 people each.  Think for a

moment what would happen if they got 20 people to

participate!  Most people get hundreds of participants and

many will continue to work this program, sending out

programs WITH YOUR NAME ON THEM for years!  Think about it!

Many, many people with Internet connections are going to

receive this e-mail--don't you want your name to be on

it!!!!



DON'T MISS OUT!!!



JUST TRY IT ONCE!!!



SEE WHAT HAPPENS!!!



YOU WILL BE AMAZED!!!



************************************************************



 ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS!  This will

guarantee that the e-mails your prospects send out will have

YOUR NAME AND ADDRESS on them and they will be prompt

because they can't advertise until they receive your report!



************************************************************



GET STARTED TODAY, WITH THESE EASY DIRECTIONS:



1. Place your four orders for the four reports.  Send $5.00

cash (checks or money orders will not be accepted--U.S.

Currency only) for each report.



2. Make sure the cash is concealed by double-wrapping it in

two sheets of paper.  On one of the sheets write (do this

for each of the four reports):



- the name and number of the report you are ordering



- your e-mail address for the report to be sent to



- your name and postal address



3. Send the cash and the two sheets of paper in a plain

white envelope addressed to each of the four persons listed

on your initial e-mail.  Be sure and put your return address

on the envelope, in case there is a problem with the U.S.

Postal Service.



REPORT #1 - The Insider's Guide to Advertising for Free on

the Internet



Order Report #1 from:



L. Armendariz



4224 E. Seneca St.



Tucson, AZ  85712



REPORT #2 - The Insider's Guide to Sending Bulk E-mail on

the Internet



Order Report #2 from:



Aaron Family



3150 E. Ft. Lowell Rd.



Tucson, AZ  85716



REPORT #3 - The Secrets to Multi-level Marketing on the

Internet



Order Report #3 from:



Stacey Parker



P.O. Box 8061



Medford, Oregon  97501-0061



REPORT #4 - How to Become a Millionaire Utilizing the Power

of Multi-level Marketing and the Internet



Order Report #4 from:



Heartfelt Gifts



PMB 119 2305-C Ashland St.



Ashland, OR  97520



************************************************************



Remember, AFTER YOU HAVE ORDERED ALL FOUR REPORTS from the

folks listed above, and BEFORE YOU SEND THIS E-MAIL ON TO

YOUR PROSPECTS, delete the name and address under REPORT #4.

This person has made it through the cycle.



Move the name and address under REPORT #3 down to REPORT #4.



Move the name and address under REPORT #2 down to REPORT #3.



Move the name and address under REPORT #1 down to REPORT #2.



Insert your name and address under the REPORT #1 position.

Please make sure you COPY ALL INFORMATION, every name and

address, ACCURATELY!



For this program to work, you must follow the instructions

exactly! Especially the rule of not trying to place your

name in a different position.  The program won't work

correctly and you will lose out on a lot of money and

potential income.



And also for this program to work for you, you must meet

your goal of 20+ orders for Report #1 and 100+ orders for

Report #2.  After you have met that goal, you are on your

way to making over $50,000.



$$$$$$$$$$$$$$$$$$$$  TIPS FOR SUCCESS  $$$$$$$$$$$$$$$$$$$$



TREAT THIS AS YOUR BUSINESS!  Be prompt, professional, and

follow the directions accurately.  Send for the four reports

IMMEDIATELY so you will have them when the orders start

coming in because when you receive a $5 order, you MUST send

out the requested product/report.  It is required for this

to be a legal business and folks need to receive the product

they are promised and have paid for.  They will need the

report to sell to the prospects that they contact.



ALWAYS PROVIDE SAME DAY SERVICE on the orders that you

receive.  Be patient and persistent with this program.  If

you follow the instructions exactly, results will follow.



$$$$$$$$$$$$  YOUR SUCCESS GUIDELINES $$$$$$$$$$$$



Follow these guidelines to guarantee your success:



1. If you don't receive 20 orders for REPORT #1 within two

weeks, continue advertising or sending e-mails until you do.

Then a couple of weeks later you should receive at least 100

orders for REPORT #2.  If you don't, continue advertising or

sending e-mails until you do.  Once you have received 100 or

more orders for REPORT #3, YOU CAN RELAX, because the system

is already working for you and the cash will continue to

come in.



2. THIS IS IMPORTANT TO REMEMBER:  Every time your name is

moved down on the list, you are placed in front of a

DIFFERENT report.  You can keep track of your progress by

watching which report your prospects are ordering from you.



3. To generate more income, simply send another batch of e-

mails or continue placing ads and start the whole process

again!  There is no limit to the income you will generate

>from this business!



************************************************************



Before you make your decision as to whether or not you

participate in this program, answer one question:



ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?



If the answer is NO, then please look at the following facts

about this super-simple MLM program:



- No face to face selling, no meetings, no inventory!  No

telephone calls, no big cost to start! Nothing to learn, no

skills needed (surely you know how to send an e-mail!).



- No equipment to buy!  You obviously already have a

computer and Internet connection, so you already have

everything you will need to begin filling orders. - You are

selling a product which does NOT COST ANYTHING TO PRODUCE OR

SHIP!  (E-mail copies of the reports are FREE to you to send

out.)



- All of your customers pay you in CASH!  There are no more

"bad checks" to worry about and try to collect.  There are

no more MC/Visa monthly service charges to cut into your

profit. This program will change your LIFE FOREVER!  Look at

the potential for you to be able to quit your job and live a

life of luxury you could only dream about!  Imagine getting

out of debt and buying the car and home of your dreams and

being able to work a super-high-paying, leisurely-easy

business from your home computer!



$$$$$$$$$$$$$  MAKE YOUR DREAMS COME TRUE



$$$$$$$$$$$$$ ACT NOW!



Take your first step toward achieving financial

independence.  Order the reports and follow the program

outlined above.  SUCCESS will be your reward.



************************************************************



WHAT OTHERS SAY WHO HAVE USED THIS PROGRAM:



My name is Mitchell.  My wife, Cathy, and I, live in

Chicago, IL.  I am a cost accountant with a major U.S.

Corporation and I make pretty good money.  When I received

the program, I grumbled to Cathy about receiving "junk

mail--SPAM!"  I made fun of the whole thing, spouting my

knowledge of the population and percentages involved.  I

"knew" it wouldn't work. Cathy totally ignored my supposed

intelligence and jumped in with both feet.  I made merciless

fun of her, and was ready to lay the old, "I told you so",

on her when the thing didn't work...well, the laugh was on

me!  Within two months she had received over $147,200 in $5

bills!  I was shocked!  I was sure that I had it all figured

out and that it would not work.  I AM A BELIEVER NOW!  I

have joined Cathy in her "hobby."  I did have seven more

years until retirement, but I think of the "rat race" and

it's not for me.  We owe it all to this MLM.  --  Mitchell

Wolf, Chicago, IL



************************************************************



The main reason for this letter is to convince you that this

system is honest, lawful, extremely profitable, and is a way

to get a large amount of money in a short time.  I was

approached several times before I checked this out.  I

joined just to see what one could expect in return for the

minimal effort and money required.  To my astonishment, I

received $36,470 in the first 14 weeks, with money still

coming in.  - Charles Morris, Esq.



************************************************************



Not being the gambling type, it took me several weeks to

make up my mind to participate in this plan.  But

conservative that I am, I decided that the initial

investment was so little that there was just no way that I

wouldn't get enough orders to at least get by $20 back.

Boy, was I surprised when I found my medium-size post office

box crammed with orders!   For a while, it got so overloaded

that I had to start picking up my mail at the window.  I'll

make more money this year than any 10 years of my life

before.  The nice thing about this Internet deal is that it

doesn't matter where people live.  There simply isn't a

better investment with a faster return.  --  Paige Willis,

Des Moines, IA



************************************************************



I had received this MLM program before.  I deleted it, but

later I wondered if I should not have given it a try.  Of

course, I had no idea who to contact to get another copy, so

I had to wait and hope that I was e-mailed this program

again--11 months passed before I received it again.  I did

not delete it this time.  I have made more than $41,000 on

the first try!  -  Violet Wilson, Johnston, PA



************************************************************



 This is my third time to participate in this plan.  We have

both quit our jobs and will soon buy a home on the Atlantic

Ocean and live off the interest on our money.  But, the only

way on earth that this plan will work for you is if you do

it.  For your sake, and for your family's sake, don't pass

up this golden opportunity. Good luck and happy spending!!

- Kerry Ford, Centerport NY



************************************************************



Now, the business end of this program:  (Please note, this

is VERY IMPORTANT in getting your business started.) - If

you need help with starting your business, registering your

business name, learning how to handle the income tax, etc.,

contact your local office of the Small Business

Administration or call their toll free number

(1-800-827-5722) for free help and answers to your

questions.



- Also, the Internal Revenue Service offers free help via

the Internet and has free seminars about business tax

requirements.



- Your earnings are highly dependent on your activities and

advertising.  The information contained in this e-mail and

in the reports constitute no guarantee stated or implied.

In the event that it is determined that this site or report

constitutes a guarantee of any kind, that guarantee is null

and void.  The earning amounts listed in this e-mail and in

the reports are ESTIMATES only.  If you have any questions

of the legality of this program, contact the Office of

Associate Director for Marketing Practices, Federal Trade

Commission, Bureau of Consumer Protection, in Washington,

DC.



- Under Bill S. 1618 TITLE III, passed by the 105th U.S.

Congress, this e-mail cannot be considered SPAM as long as

the sender includes contact information and a method of

removal.  This is a one time e-mail transmission.  No

request for removal is necessary.



THERE IS NO NEED TO RESPOND TO THIS E-MAIL IF YOU DO NOT

WISH TO RECEIVE FURTHER CORRESPONDENCE.  THIS IS A ONE-TIME

E-MAIL.


























From rem-conf Sun Mar 25 05:37:48 2001 
From rem-conf-request@es.net Sun Mar 25 05:37:47 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hAgF-0007hK-00; Sun, 25 Mar 2001 05:35:39 -0800
Received: from bendeguz.elender.hu (mail.elender.hu) [212.108.200.75] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hAgC-0007hA-00; Sun, 25 Mar 2001 05:35:36 -0800
Received: from mail.elender.hu (m33-as104.elender.hu [212.108.205.160])
	by mail.elender.hu  with SMTP id PAA00275
	for ; Sun, 25 Mar 2001 15:35:29 +0200 (MET DST)
From: medicine3@nexus.hu
Received: from 88388@nexus.medicine.hu by internationalstudies.in.college.in (8.8.5/8.6.5) with SMTP id GAA05721 for ; Sun, 25 Mar 2001 14:34:07 -0600 (EST)
Date: Sun, 25 Mar 01 14:34:07 EST
To: rem-conf@es.net
Subject: W.H.O universities..accredited, affordable & financial aid approved!
Message-ID: <525527728827tgs87288s00200sms99020>
Reply-To: whouniversities@1000.hu
X-PMFLAGS: 19i9i19mcmm94399 kdrioeks
X-UIDL: medical associations.medical.orwii
Comments: Authenticated sender is 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear rem-conf@es.net,

TO BE REMOVED FROM FUTURE MAILINGS, SIMPLY REPLY TO THIS MESSAGE 
AND PUT "REMOVE" IN THE SUBJECT.
*********************************************************************
Direct Admission into W.H.O. Medical Schools, Dental Schools and Pharmacy 
Schools.
IMEI, an international medical education organization, promotes medical
Education and coorporation between the American medical community and its
European and worldwide Counterparts through cultural exchange program.
ENGLISH-LANGUAGE DOCTOR OF MEDICINE (M.D.) PROGRAMS
IN EUROPE.
Direct admission into World Health Organization (W.H.O.) listed
and fully Accredited Medical Schools which participate in
the U.S. Office of Education Guaranteed Student Loan Program for
Health Professions Students.
============================================================
The Curriculum of the English-Language Medical School Program in
Europe parallels that of American Medical Schools.
4-year and 7- year English-Language Programs for high school seniors, 
premedical students with 2 years of college/university work, college graduates 
and post graduates.
=============================================================
For more information on qualification, please write to:
                     medicine@1997.hu
Or call us at (use 001 if you are calling outside USA) (303) 593-6473




From rem-conf Sun Mar 25 08:22:18 2001 
From rem-conf-request@es.net Sun Mar 25 08:22:17 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hDED-0003s7-00; Sun, 25 Mar 2001 08:18:53 -0800
Received: from ipohisdn.ozemail.com.au (mail.ipoh.com.au) [203.108.186.161] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hDE8-0003q8-00; Sun, 25 Mar 2001 08:18:49 -0800
Received: from centrum.cz (203.177.38.71 [203.177.38.71]) by mail.ipoh.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id H30M95SS; Mon, 26 Mar 2001 02:14:17 +1000
Message-ID: <000057a12634$00006960$00006482@kali.com.cn>
To: 
From: pohaw@kali.com.cn
Subject: Opportunity in the investigative profession          {
Date: Sun, 25 Mar 2001 07:03:29 -0800
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list






 Thank you for your interest!

  
                         

 14



 

Judgment Courses offers an extensive Audio training

course in 
 "How to Collect Money Judgments"
  .



If you are like many people, you are not even sure what a

Money Judgment is and 
 why processing Money Judgments

can earn you very substantial income
  .



If you ever sue a company or a person and you win then you

will have a Money Judgment against them.



You are happy you won but you will soon find out the

shocking fact: "Its now up to you to collect on the

Judgment". The court does not require the loser to pay you.

The court will not even help you. You must trace the loser

down, find their assets, their employment, bank accounts,

real estate, stocks and bonds, etc.



Very few people know how to find these assets or what to do

when they are found. The result is that millions of

Judgments are just sitting in files and being forgotten.



"In 79% of the cases the winner of a Judgment never sees a

dime."



The non-payment of judicial debt has grown to epidemic

proportions. Right now in the United States there is

between 
 200 and 300 billion dollars of uncollected Money<=
BR>
Judgment debt
  . For every Judgment that is paid, 5 more

Judgments take its place.



We identified this massive market 8 years ago and have

actively pursued Judicial Judgments since. We invented this

business. We have perfected it into a well proven and solid

profession in which only a select few will be trained in the

techniques necessary to succeed.



With our first hand experience we have built a course which

teaches you how to start your business in this new unknown

and exciting field of processing Money Judgments.



By following the steps laid out in our course and with

reasonable effort you can become very successful in the

processing of Money Judgments.



The income potential is substantial in this profession. 
 We

have associates who have taken our course and are now

working full time making $96,000.00 to over $200,000.00 per

year. Part time associates are earning between $24,000.00

and $100,000.00 per year 
 . Some choose to operate out of

their home and work by themselves. Others build a sizable

organization of 15 to 25 people in attractive business

offices.



Today our company and our associates have over 126

million dollars in Money Judgments that we are currently

processing. Of this 126 million, 25 million is in the form

of joint ventures between our firm and our associates.

Joint ventures are where we make our money. We only break

even when our course is purchased. We make a 12% margin on

the reports we supply to our associates. Our reporting

capability is so extensive that government agencies, police

officers, attorneys, credit agencies etc., all come to us

for reports.





Many of our associates already have real estate liens in

force of between 5 million to over 15 million dollars.

Legally this means that when the properties are sold or

refinanced our associate must be paid off. The norm is 10%

interest compounded annually on unpaid Money Judgments.

Annual interest on 5 million at 10% translates to

$500,000.00 annually in interest income, not counting the

payment of the principal.



Our associates earn half of this amount or $250,000.00 per

year. This is just for interest, not counting principle

and not counting the compounding of the interest which can

add substantial additional income. Typically companies are

sold for 10 times earnings. Just based on simple interest

an associate with 5 million in real estate liens could sell

their business for approximately 2.5 million dollars.




 92% of all of our associates work out of their ho=
me; 43%

are women and 36% are part time
  .



One of the benefits of working in this field is that you are

not under any kind of time frame. If you decide to take off

for a month on vacation then go. The Judgments you are

working on will be there when you return. The Judgments

are still in force, they do not disappear.



The way we train you is non-confrontational. You use your

computer and telephone to do most of the processing. You

never confront the debtor. The debtor doesn't know who you

are. You are not a collection agency.



Simply stated the steps to successful Money Processing

are as follows:



Mail our recommended letter to companies and individuals

with Money Judgments. (We train you how to find out who

to write to)



8% to 11% of the firms and people you write will call you

and ask for your help. They call you, you don't call them

unless you want to.



You send them an agreement (supplied in the course) to

sign which splits every dollar you collect 50% to you and

50% to them. This applies no matter if the judgment is for

$2,000.00 or $2,000,000.00.



You then go on-line to our computers to find the debtor

and their assets. We offer over 120 powerful reports to

assist you. They range from credit reports from all three

credit bureaus, to bank account locates, employment

locates, skip traces and locating stocks and bonds, etc.

The prices of our reports are very low. Typically 1/2 to

1/3 of what other firms charge. For example we charge

$6.00 for an individuals credit report when some other

companies charge $25.00.



Once you find the debtor and their assets you file

garnishments and liens on the assets you have located.

(Standard fill in the blanks forms are included in the

course)



When you receive the assets you keep 50% and send 50% to

the original Judgment holder.



Once the Judgment is fully paid you mail a Satisfaction of

Judgment to the court. (Included in the course)



Quote's from several of our students:



Thomas in area code 516 writes us: "I just wanted to drop

you a short note thanking you for your excellent course. 
 My

first week, part time, will net me 3,700.00 dollars
  . Your

professionalism in both the manual and the video opened

doors for me in the future. There's no stopping me now.

Recently Thomas states he has over $8,500,000 worth of

judgments he is working on.



After only having this course for four months, Larry S. in

area code 314 stated to us: " 
 I am now making $2,000.00 per

week 
 and expect this to grow to twice this amount with=
in the

next year. I am having a ball. I have over $250,000 in

judgments I am collecting on now."



After having our course for 7 months Larry S. in 314 stated

" 
 I am now making $12,000.00
  per month and have approximately

$500,000.00 in judgments I am collecting on. Looks like I

will have to hire someone to help out"



Marshal in area code 407 states to us "I feel bad, you only

charged me $259.00 for this course and it is a goldmine. I

have added 3 full time people to help me after only having

your course for 5 months"



>From the above information and actual results you can see

why we can state the following:



With our course you can own your own successful business.

A business which earns you substantial income now and one

which could be sold in 3-5 years, paying you enough to

retire on and travel the world. A business which is

extremely interesting to be in. A Business in which every

day is new and exciting.



None of your days will be hum-drum. Your brain is

Challenged. A business, which protects you from Corporate

Downsizing. A business which you can start part time from

your home and later, if you so desire, you can work in full

time. A business, which is your ticket to freedom from

others telling you what to do. A business, which lets you

control your own destiny. Our training has made this happen

for many others already. Make it happen for you!



If the above sounds interesting to you then its time for you

to talk to a real live human being, no cost or obligation

on your part.




 Please call us at 1-4 0 6--6 5 2--0 1 9 4 
 .



We have 
 Customer Support staff available to you from 8:00=
am to

9:00pm (Mountain Time) 7 days a week
  . If you call this number

you can talk to one of our experienced Customer Support personnel.

They can answer any questions you may have - with no obligation.

Sometimes we run special pricing on our courses and combinations

of courses. When you call our Customer Support line they can let

you know of any specials we may be running. If you like what you

read and hear about our courses, then the Customer Support person

can work with you to place your order. We are very low key. We

merely give you the facts and you can then decide if you want to

work with us or not.



Thank you for your time and interest.


































 +++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++

This ad is produced and sent out by:

Universal Advertising Systems

To be removed from our mailing list please email us at 

tammismith@freeze.com with remove in the subject line or

call us toll free at 1-888-605-2485 and give us your email address or writ=
e us at:

Central DB Removal, PO Box 1200, Oranjestad, Aruba

++++++++++++++++++++++++++++++++++++++++++++++++++++++++




 









From rem-conf Sun Mar 25 15:27:39 2001 
From rem-conf-request@es.net Sun Mar 25 15:27:38 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hJnq-00044b-00; Sun, 25 Mar 2001 15:20:06 -0800
Received: from vic20.linix.co.uk [195.219.30.14] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hJnm-000441-00; Sun, 25 Mar 2001 15:20:02 -0800
Received: from dul-061.linix.co.uk ([195.219.7.61] helo=mail.welshnet.co.uk)
	by vic20.linix.co.uk with smtp (Exim 3.22 #11)
	id 14hJm2-0003eb-00; Mon, 26 Mar 2001 00:18:17 +0100
Received: from inmail.pongstrip.com [alt1.pongstrip.com (208.9.77.65)] by pongstrip.com (8.8.5/8.6.5) with SMTP id GAA03421 for <>; Mon, 26 Mar 2001 00:13:25 -0600 (EST)
Date: Mon, 26 Mar 01 00:13:25 EST
From: 26508776@24787.com
To: Friend@public.com
Subject: TURN $25 Into $1000s - SIMPLE STEP- BY-STEP GUIDE
Message-ID: 
Reply-To: order@pongstrip.com
X-PMFLAGS: 128.0
X-UIDL: 35243542536788876534288776655423
Comments: Authenticated sender is 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

AS SEEN ON NATIONAL TV:

"Making over half a million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!

Before you say "bull", please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money.

The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in".
Pam Hedland, Fort Lee, New Jersey.

Here is another testimonial:

"this program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa   3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything."

More testimonials later but first,

PRINT THIS NOW FOR YOUR FUTURE REFERENCE

If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following.. THEN READ IT AGAIN and AGAIN!!!

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

Order all 5 reports shown on the list below.

For each report send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report.

MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems.

When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them.  YOUR TOTAL COST $5 X 5 = $25.00.

Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals.  Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you.  Also make a floppy of these reports and keep it on your desk.

****IMPORTANT - DO NOT alter the names of the people who are listed next to each report or their sequence on the list in any way other than what is instructed below in step 1 through 6  or you will lose out on the majority of your profits. Once you understand the way this works you will also see how it does not work if you change it.

Remember, this method has been tested, and if you alter it, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way.  Believe us, we all have tried to be greedy and then nothing happened.   So Do Not try to change anything other than what is instructed.  Because if you do, it will NOT work for you.  Remember, honesty reaps the rewards!!!

1.	After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune.

2.	Move the name & address in REPORT #4 down TO REPORT #5.

3.	Move the name & address in REPORT # 3 down TO REPORT #4.

4.	Move the name & address in REPORT #2 down TO REPORT #3.

5.	Move the name & address in REPORT # 1 down TO REPORT #2

6.	Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY!

Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES.  Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1: BY SENDING BULK E-MAIL LEGALLY                                          
                                          
Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e-mails each. Let's also assume that the mailings receive only a 0.2% response (the response could be much better but let's just say it is only 0.2%.  Also many people will send out hundreds of thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.  With a 0,2% response, that is only 10 orders for report # 1.  Those 10 people responded by sending out 5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5000 e-mails each for a total of 5 million e-mails sent out.

The 0.20% response to that is 10,000 orders for Report #4.  Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report #5.

THATS 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
	1	 $50	+
	2	 $500	+
	3	 $5,000	+
	4	 $50,000	+
	5	 $500,000		Grand Total = $555,550.00 

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY!

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. 

Dare to think for a-moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the internet worldwide and counting.

Believe me, many people will do just that and more!

METHOD #2 BY PLACING FREE ADS ON THE INTERNET
                                                 
Advertising on the net is very, very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # I and add METHOD #2 as you go along.

For every $5 you receive, all you must do is e-mail them the Report they ordered.  That's it.  Always provide same day service on all orders. This will, guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report.

AVAILABLE REPORTS

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes:	Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets pf paper write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address.
* stamp to Europe cost 33c only one needed *

PLACE YOUR ORDER FOR THESE REPORTS NOW-
                                        
REPORT # 1: "The Insiders Guide to Advertising for Free on the Net"

Order Report# 1 from:
Howard Sunderland
5 Gresford Close
Prescot
Merseyside
L35 3TS
United Kingdom

REPORT #2 "The Insider's Guide to Sending Bulk e-mail on the Net'

Order Report #2 from:
John Harper
Unit3
8 Clare-Mace Crescent
BERKELEY VALE 2261
NSW, Australia


REPORT #3; "The Secret to Multi-Level marketing on the net"

Order Report # 3 from:
Daryn Dunn
6214 E 126th St.
Apt 302
Grandview, MO 64030
U.S.A


REPORT #4: "How to become a millionaire utilizing MLM & the Net"

Order Report#4 from:
R. Bock
P.O. Box 491.
Paulden. AZ 86334
U.S.A.


REPORT #5: "HOW TO SEND 1 MLLLION E-MAILS FOR FREE" 

Order Report #5 from:
J Hegarty
Templeisque
Whites Cross
Co Cork
Ireland

YOUR SUCCESS GUIDELINES

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do.

After you have received 10 orders: 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2.  If you did not, continue advertising or sending e-mails until you do.

Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you and the cash will continue to roll in THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list you are placed in front of a different report.  You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you.  IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

"You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT You can make more money in the next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved the others to #2 - # 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach.

So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW!

MORE TESTIMONIALS

My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money.  When I received this program I grumbled to Jody about receiving "junk mail". I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work. Well, the laugh was on met within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of$ 147,200.00 all cash! I was shocked. I have joined Jody in her "hobby"
Mitchell Wolf M.D. Chicago, Illinois

Not being the gambling type1 it took me several weeks to make up my mind to participate in this plan.  But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back.

I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big.
Dan Sondstrom, Alberta,
Canada

"I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else    11 months passed then it luckily came again   I did not delete this one! I made more than $490,000 on my first try and air the money came within 22 weeks".
Susan De Suza, New York, N.Y

"It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca1 Westport, New Zealand 

Your local bank or post office can help you exchange local currency in to US retain the system in US Dollars so we are all on the same playing field.

Good Luck, it really works.

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.

ONE TIME MAILING, NO NEED TO REMOVE

This message is sent in compliance of the proposed bill SECTION 301. per Section 3011 Paragraph (a~2)(C) of 8.1618. Further transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to: personal@wealth-direct.com with the word "Remove (1)" in the subject tine. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability.

T H E	E N D





From rem-conf Sun Mar 25 16:52:22 2001 
From rem-conf-request@es.net Sun Mar 25 16:52:22 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hLBZ-0006e1-00; Sun, 25 Mar 2001 16:48:41 -0800
Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hLBY-0006dr-00; Sun, 25 Mar 2001 16:48:40 -0800
Received: from kkb3 (kkb3-099.kk.etx.ericsson.se [130.100.99.23])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2Q0mXC24790;
	Mon, 26 Mar 2001 02:48:33 +0200 (MEST)
Received: from ericsson.com.au by kkb3 (SMI-8.6/LME-2.2.6)
	id CAA24017; Mon, 26 Mar 2001 02:48:24 +0200
Message-ID: <3ABE91D8.7B162967@ericsson.com.au>
Date: Mon, 26 Mar 2001 10:48:24 +1000
From: Ian Rytina 
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tmima Koren 
CC: Daniel Feldman , rem-conf@es.net,
   Eyal Gutman , Alex Trigub ,
   Doron Greenbaum , Giora Ariel ,
   Dov Alon 
Subject: Re: cTCRTP
References: <4.3.2.7.2.20010321235847.02909de0@mira-sjcm-2.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Hi Tmima,

The TCRTP draft refers to the L2TPHC draft. What is the status of
that document at the moment ?

/Ian.


Tmima Koren wrote:

> There is no separate document that describes cTCRTP. It's just cUDP applied to a TCRTP stream (which is a stream of IP packets) when traversing a PPP link.
> Tmima
>
> At 02:53 PM 3/21/2001 +0200, Daniel Feldman wrote:
> >        Does anyone know which document describes cTCRTP (supposedly a
> >more bandwidth efficient way to send TCRTP over a PPP link by
> >compressing the L2TP IP header with cUDP)?
> >        Thanks in advance,
> >
> >~~~~~~~~~~~~~~~~~~~~~~~~
> >Daniel Feldman
> >System Engineer, IC4IC ltd.
> >office: +972-4-9594644 ext. 121
> >mobile: +972-53-980442
> >fax: +972-4-9594944
> >~~~~~~~~~~~~~~~~~~~~~~~~




From rem-conf Sun Mar 25 17:35:20 2001 
From rem-conf-request@es.net Sun Mar 25 17:35:20 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hLsd-0000VC-00; Sun, 25 Mar 2001 17:33:11 -0800
Received: from sj-msg-core-1.cisco.com [171.71.163.11] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hLsb-0000Ur-00; Sun, 25 Mar 2001 17:33:09 -0800
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA22533;
	Sun, 25 Mar 2001 17:32:09 -0800 (PST)
Received: from tmima-w2k.cisco.com (tmima-dsl4.cisco.com [144.254.211.45])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAL01394;
	Sun, 25 Mar 2001 17:32:03 -0800 (PST)
Message-Id: <4.3.2.7.2.20010325171300.04460c98@mira-sjcm-2.cisco.com>
X-Sender: tmima@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 25 Mar 2001 17:30:29 -0800
To: Ian Rytina 
From: Tmima Koren 
Subject: Re: cTCRTP
Cc: Daniel Feldman , rem-conf@es.net,
        Eyal Gutman , Alex Trigub ,
        Doron Greenbaum , Giora Ariel ,
        Dov Alon , brucet@cisco.com
In-Reply-To: <3ABE91D8.7B162967@ericsson.com.au>
References: <4.3.2.7.2.20010321235847.02909de0@mira-sjcm-2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

l2tpext Draft Status was sent to the l2tpext mailing list by the l2tpext WG chair
Here is the status of l2tphc:

draft-ietf-l2tpext-l2tphc-03.txt
In WG Last Call. Awaiting a reply from IANA, and then ready to move
forward to IESG for PS.

Tmima

At 10:48 AM 3/26/2001 +1000, Ian Rytina wrote:

>Hi Tmima,
>
>The TCRTP draft refers to the L2TPHC draft. What is the status of
>that document at the moment ?
>
>/Ian.
>
>
>Tmima Koren wrote:
>
>> There is no separate document that describes cTCRTP. It's just cUDP applied to a TCRTP stream (which is a stream of IP packets) when traversing a PPP link.
>> Tmima
>>
>> At 02:53 PM 3/21/2001 +0200, Daniel Feldman wrote:
>> >        Does anyone know which document describes cTCRTP (supposedly a
>> >more bandwidth efficient way to send TCRTP over a PPP link by
>> >compressing the L2TP IP header with cUDP)?
>> >        Thanks in advance,
>> >
>> >~~~~~~~~~~~~~~~~~~~~~~~~
>> >Daniel Feldman
>> >System Engineer, IC4IC ltd.
>> >office: +972-4-9594644 ext. 121
>> >mobile: +972-53-980442
>> >fax: +972-4-9594944
>> >~~~~~~~~~~~~~~~~~~~~~~~~




From rem-conf Sun Mar 25 22:04:18 2001 
From rem-conf-request@es.net Sun Mar 25 22:04:16 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hQ02-00069E-00; Sun, 25 Mar 2001 21:57:06 -0800
Received: from (ms.samsung.com) [211.45.29.136] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hQ00-00068e-00; Sun, 25 Mar 2001 21:57:04 -0800
Received: from bright ([203.241.48.20]) by ms.samsung.com
          (Netscape Messaging Server 4.15) with SMTP id GASJ1C00.HRJ for
          ; Mon, 26 Mar 2001 14:53:36 +0900 
From: chjkim@samsung.com
To: "Rtp" 
Subject: On mixer
Date: Mon, 26 Mar 2001 14:57:37 +0900
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C0B605.19196400"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C0B605.19196400
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGVsbG8sIA0KDQpJIGhhdmUgdHdvIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gbWl4ZXIgaW4gUlRQLiBQ
bGVhc2UgbGV0IG1lIGtub3cgdGhlbS4NCg0KMS4gV2hlbiBjb21iaW5pbmcgbXVsdGlwbGUgcGFj
a2V0IGluIG1peGVyIG9mIFJUUCwgaXMgaXQgcmlnaHQgdGhhdCB0aGUgZGVsYXkgaXMgaW5jcmVh
c2VkIGJlY2F1c2UgZWFjaCBwYWNrZXQgaXMgZ2VuZXJhdGVkIGluIGRpZmZlcmVudCB0aW1lLiBJ
IHRoaW5rIHRoYXQgZm9yIGV4YW1wbGUsIHRoZSBmaXJzdCBwYWNrZXQgb2YgY29tYmluZWQgcGFj
a2V0cyBoYXMgdG8gd2FpdCBmb3IgbGFzdCBwYWNrZXQgdG8gam9pbiwgYW5kIGZvciB0aGUgY29t
cGxldGlvbiBvZiBjb21iaW5hdGlvbiBvZiBtdXRpcGxlIHBhY2tldHMgYW5kIHRoaXMgaW5jcmVh
c2VzIHRoZSBkZWxheSB0aW1lLg0KDQoyLiBJbiBjb21iaW5lZCBSVFAgcGFja2V0LCBob3cgY2Fu
IGVhY2ggYm91bmRhcnkgb2YgY29udHJpYnV0aW5nIHNvdXJjZXMgYmUgaWRlbnRpZmllZD8gSXMg
dGhlcmUgYW55IGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gaXQgaW4gUlRQIGhlYWRlcj8NCg0KVGhh
bmtzIGluIGFkdmFuY2UuLi4NCg0KQ2hlb2wtSnUNCg==

------=_NextPart_000_0013_01C0B605.19196400
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWT4NCjxESVY+
PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTA0NzEwMzgwNS0yNjAzMjAwMT5IZWxsbywgPC9TUEFO
PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTA0NzEwMzgwNS0y
NjAzMjAwMT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQ
QU4gY2xhc3M9MDQ3MTAzODA1LTI2MDMyMDAxPkkgaGF2ZSB0d28gcXVlc3Rpb24gcmVsYXRlZCB0
byANCm1peGVyIGluIFJUUC4gUGxlYXNlIGxldCBtZSBrbm93IHRoZW0uPC9TUEFOPjwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTA0NzEwMzgwNS0yNjAzMjAwMT48
L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9
MDQ3MTAzODA1LTI2MDMyMDAxPjEuIFdoZW4gY29tYmluaW5nIG11bHRpcGxlIA0KcGFja2V0IGlu
IG1peGVyIG9mIFJUUCwgaXMgaXQgcmlnaHQgdGhhdCB0aGUgZGVsYXkgaXMgaW5jcmVhc2VkIA0K
YmVjYXVzZSZuYnNwO2VhY2ggcGFja2V0IGlzIGdlbmVyYXRlZCBpbiBkaWZmZXJlbnQgdGltZS4g
SSB0aGluayB0aGF0Jm5ic3A7Zm9yIA0KZXhhbXBsZSwgdGhlIGZpcnN0IHBhY2tldCBvZiBjb21i
aW5lZCBwYWNrZXRzIGhhcyB0byB3YWl0IGZvciBsYXN0IHBhY2tldCB0byANCmpvaW4sIGFuZCBm
b3IgdGg8L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wNDcxMDM4MDUtMjYw
MzIwMDE+ZSANCmNvbXBsZXRpb24gb2YgY29tYmluYXRpb24gb2YgbXV0aXBsZSBwYWNrZXRzIGFu
ZCB0aGlzIGluY3JlYXNlcyB0aGUgZGVsYXkgDQp0aW1lLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0wNDcxMDM4MDUtMjYwMzIwMDE+PC9TUEFOPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTA0NzEwMzgw
NS0yNjAzMjAwMT4yLiBJbiBjb21iaW5lZCBSVFAgcGFja2V0LCBob3cgDQpjYW4gZWFjaCBib3Vu
ZGFyeSBvZiBjb250cmlidXRpbmcgc291cmNlcyBiZSBpZGVudGlmaWVkPyBJcyB0aGVyZSBhbnkg
DQppbmZvcm1hdGlvbiByZWxhdGVkIHRvIGl0IGluIFJUUCBoZWFkZXI/PC9TUEFOPjwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTA0NzEwMzgwNS0yNjAzMjAwMT48
L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9
MDQ3MTAzODA1LTI2MDMyMDAxPlRoYW5rcyBpbiANCmFkdmFuY2UuLi48L1NQQU4+PC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MDQ3MTAzODA1LTI2MDMyMDAxPjwv
U1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNz
PTA0NzEwMzgwNS0yNjAzMjAwMT5DaGVvbC1KdTwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv
SFRNTD4NCg==

------=_NextPart_000_0013_01C0B605.19196400--




From rem-conf Sun Mar 25 22:05:06 2001 
From rem-conf-request@es.net Sun Mar 25 22:05:05 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hQ45-0006GB-00; Sun, 25 Mar 2001 22:01:18 -0800
Received: from (ms.samsung.com) [211.45.29.136] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hQ44-0006Ew-00; Sun, 25 Mar 2001 22:01:16 -0800
Received: from bright ([203.241.48.20]) by ms.samsung.com
          (Netscape Messaging Server 4.15) with SMTP id GASJ8C00.JUR for
          ; Mon, 26 Mar 2001 14:57:48 +0900 
From: chjkim@samsung.com
To: "Rtp" 
Subject: On mixer...(text)
Date: Mon, 26 Mar 2001 15:01:49 +0900
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

KFNvcnJ5LCB0aGlzIGlzIHRleHQgZm9ybWF0KQ0KDQpIZWxsbywgDQoNCkkgaGF2ZSB0d28gcXVl
c3Rpb24gcmVsYXRlZCB0byBtaXhlciBpbiBSVFAuIFBsZWFzZSBsZXQgbWUga25vdyB0aGVtLg0K
DQoxLiBXaGVuIGNvbWJpbmluZyBtdWx0aXBsZSBwYWNrZXRzIGluIG1peGVyIG9mIFJUUCwgaXMg
aXQgcmlnaHQgdGhhdCB0aGUgZGVsYXlzIGFyZSBpbmNyZWFzZWQgYmVjYXVzZSBlYWNoIHBhY2tl
dCBpcyBnZW5lcmF0ZWQgaW4gZGlmZmVyZW50IHRpbWUuIEkgdGhpbmsgZm9yIGV4YW1wbGUsIHRo
ZSBmaXJzdCBwYWNrZXQgb2YgY29tYmluZWQgcGFja2V0cyBoYXMgdG8gd2FpdCBmb3IgbGFzdCBw
YWNrZXQgdG8gam9pbiwgYW5kIGZvciB0aGUgY29tcGxldGlvbiBvZiBjb21iaW5hdGlvbiBvZiBt
dXRpcGxlIHBhY2tldHMgYW5kIHRoaXMgaW5jcmVhc2VzIHRoZSBkZWxheSB0aW1lLg0KDQoyLiBJ
biBjb21iaW5lZCBSVFAgcGFja2V0LCBob3cgY2FuIGVhY2ggYm91bmRhcnkgb2YgY29udHJpYnV0
aW5nIHNvdXJjZXMgYmUgaWRlbnRpZmllZD8gSXMgdGhlcmUgYW55IGluZm9ybWF0aW9uKHN1Y2gg
YXMgbGVuZ3Rocy4uLikgcmVsYXRlZCB0byBpdCBpbiBSVFAgaGVhZGVyPw0KDQpUaGFua3MgaW4g
YWR2YW5jZS4uLg0KDQpDaGVvbC1KdQ==




From rem-conf Sun Mar 25 23:34:18 2001 
From rem-conf-request@es.net Sun Mar 25 23:34:17 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hRTo-0001pW-00; Sun, 25 Mar 2001 23:31:56 -0800
Received: from (ms.samsung.com) [211.45.29.136] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hRTm-0001p2-00; Sun, 25 Mar 2001 23:31:54 -0800
Received: from bright ([203.241.48.20]) by ms.samsung.com
          (Netscape Messaging Server 4.15) with SMTP id GASNFE00.K17 for
          ; Mon, 26 Mar 2001 16:28:26 +0900 
From: chjkim@samsung.com
To: "Rtp" 
Subject: fig2 in rfc1889
Date: Mon, 26 Mar 2001 16:32:27 +0900
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

SGksIA0KDQpDb3VsZCBhbnlib2R5IGV4cGxhaW4gdGhlIGZpZ3VyZSAyKEV4YW1wbGUgZm9yIHJv
dW5kLXRyaXAgdGltZSBjb21wdXRhdGlvbikgaW4gcmZjMTg4OT8NCkkgY2FuJ3QgdW5kZXJzdGFu
dCB0aGUgaGV4YWRlY2ltYWxzIGluIGl0Lg0KDQpBbmQgcGxlYXNlIHNob3cgbWUgdGhlIGV4YW1w
bGVzIGZvciBOVFAgdGltZXN0YW1wPw0KDQpUaGFua3MuDQoNCkNoZW9sLUp1




From rem-conf Mon Mar 26 06:30:16 2001 
From rem-conf-request@es.net Mon Mar 26 06:30:16 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hXvL-0003Tr-00; Mon, 26 Mar 2001 06:24:47 -0800
Received: from (mail) [211.75.85.1] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14hXvF-0003Rd-00; Mon, 26 Mar 2001 06:24:41 -0800
Received: from freemail.fx.ro by mail (SMI-8.6/SMI-SVR4)
	id WAA15855; Mon, 26 Mar 2001 22:23:43 +0800
From: vctfhskikz@freemail.fx.ro
Message-ID: <000062793866$00000440$00006dd6@freemail.fx.ro>
To: 
Subject: Lose Enough Money In The Stock Market Yet?                         28118
Date: Mon, 26 Mar 2001 05:33:46 -2000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

There are other ways to make money!

This product produces 50% of all the money made on the Internet!
Now for the first time, it is brought to you retail! People like you are making $600-$4,000
per week in CASH with this product! 
No selling! Not MLM! All CASH!!

Call Toll Free 1-888-804-6837 to find more!!!

Only a few people per area will be selected to provide this revolutionary product!
So act fast and be the first one in your area, and make the most money!!! Isn't it time you earn
what you are worth? Aren't you tired of making someone else rich? Well, here is your chance to 
make YOU RICH!!!
No selling! Not MLM! All CASH!!

Call now Toll Free 1-888-804-6837 24 HRS!!!

Fortunes have been made with this product, and fortunes will be made again with this new retail 
version! Remember, get in at the beginning, the first ones in get the best locations!

Call Toll Free 1-888-804-6837 if all reps are busy, leave your name and number and your call will
be returned in a few minutes!!!




remove linda74889896@ilse.nl



From rem-conf Mon Mar 26 12:45:18 2001 
From rem-conf-request@es.net Mon Mar 26 12:45:18 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hdmP-0004GX-00; Mon, 26 Mar 2001 12:39:57 -0800
Received: from east.isi.edu [38.245.76.2] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hdmN-0004GL-00; Mon, 26 Mar 2001 12:39:55 -0800
Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA07044;
	Mon, 26 Mar 2001 15:39:45 -0500 (EST)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f2QKdqp02556;
	Mon, 26 Mar 2001 15:39:53 -0500
Message-Id: <200103262039.f2QKdqp02556@chiron.east.isi.edu>
To: chjkim@samsung.com
cc: Rtp 
Subject: Re: On mixer...(text) 
In-Reply-To: Your message of "Mon, 26 Mar 2001 15:01:49 +0900."
              
Date: Mon, 26 Mar 2001 15:39:52 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

--> chjkim@samsung.com writes:
>(Sorry, this is text format)
>
>Hello, 
>
>I have two question related to mixer in RTP. Please let me know them.
>
>1. When combining multiple packets in mixer of RTP, is it right that the
>delays are increased because each packet is generated in different time. I
>think for example, the first packet of combined packets has to wait for
>last packet to join, and for the completion of combination of mutiple
>packets and this increases the delay time.

A mixer certainly adds delay to a media stream, yes. 

>2. In combined RTP packet, how can each boundary of contributing sources
>be identified? Is there any information(such as lengths...) related to it
>in RTP header?

I'm not sure I understand the question: a mixer combines RTP payloads to
create a single new payload, and hence there is no boundary between the
data from the different contributing sources.

Be careful not to confuse an RTP mixer with a multiplex, which would
concatenate multiple payloads within a packet.

Colin



From rem-conf Mon Mar 26 13:23:45 2001 
From rem-conf-request@es.net Mon Mar 26 13:23:44 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14heR2-00061N-00; Mon, 26 Mar 2001 13:21:56 -0800
Received: from (mailserver.) [64.122.30.120] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14heR0-00061D-00; Mon, 26 Mar 2001 13:21:54 -0800
Received: from [10.0.0.165] [64.122.30.80] by mailserver.
  (SMTPD32-4.06) id A2D41B4901BC; Mon, 26 Mar 2001 14:21:24 MST
From: email@oneoffmedia.com
To: rem-conf@es.net
MIME-Version: 1.0
Subject: Save up to 55% on CD Duplication!!  (ADVERTISEMENT)
Date: Mon Mar 26 14:15:50 MST 2001
X-Priority: Normal
Organization: OneOff Media, Inc.
Content-Type: multipart/alternative; boundary="--------------ED486016616714576223803"
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

----------------ED486016616714576223803
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

OneOff Media's CD Duplication Sale!!

All our mailings are sent complying to the proposed HR 3113 Unsolicited
Commercial Electronic Mail Act of 2000.  Please see the bottom of this
message for further information and removal instructions.

CD-R Duplication        Save up to 55%!

Any Quantity up to 500
Quality Silver/Silver OneOff house brand CD-R's!
Includes black Rimage print!

Was $1.99 to $4.49  NOW $1.95 a disc!!!

For quantities greater than 500, or other packaging options, please
call for a custom price quote.

To place an order call 1-800-340-1633 and ask for TC, Mark, or Brent. 
Sale ends April 15, 2001.  For more information about OneOff Media and
our other products, you may also visit our website at
"http://www.oneoffmedia.com".  You may also e-mail us at
"info@oneoffmedia.com" for more information about our products and
services.

OneOff Media, Inc.
2470 S. Redwood Road
Salt Lake City, Utah 84119
Main: 801-303-6280
Fax: 801-303-6285
Toll Free: 800-340-1633

If you would like to be removed from our mailing list please send an
email to "remove@oneoffmedia.com" with the word "remove" in the subject
line and body of the email.  For additional information regarding  the
proposed HR 3113 Unsolicited Commercial Electronic Mail Act of 2000
please see: "http://thomas.loc.gov"


----------------ED486016616714576223803
Content-Type: text/html
Content-Transfer-Encoding: 7bit
Content-Disposition: inline






	untitled









  
  

    
OneOff Media
    
    
      
2470 S Redwood Road
Salt Lake City, Utah 84119
Main: 
      801-303-6280
Fax: 801-303-6285
Toll Free: 800-340-1633

  

    
	All our mailings are sent complying to the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000.  Please see the bottom of this message for further information and removal instructions.
	media, cd, dvd, video, audio, floppy

  

    
      
CD Duplication Sale 
      !!

      

     

 

 

 

 CD-R Duplication                          Save up to 55%


Any Quantity up to 500.

Quality Silver/Silver OneOff house brand CD-R's!

Includes black Rimage print and bulk packaging.



Was $1.99 to $4.49           Now $1.95 a disc!!!
 
For quantities greater than 500, or other packaging options, please call for a custom quote.

 		
 

 
 
 		
    
	

	  
      
	  

     To place an order call 1-800-340-1633 and ask for TC, 
      Mark, or Brent.  
      Sale ends April 15, 2001.  For more information about OneOff Media and our other products, 
      you may also visit our website at 'http://www.oneoffmedia.com'. 
 
	  

      If you would like to be removed from our mailing list please send an email 
      to ' remove@oneoffmedia.com' with the word "remove" in the subject line and body of the email.  For additional information regarding the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000 please see: thomas.loc.gov
	                     


	  		
	

	













----------------ED486016616714576223803--




From rem-conf Mon Mar 26 20:40:21 2001 
From rem-conf-request@es.net Mon Mar 26 20:40:20 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hl3r-0007Jg-00; Mon, 26 Mar 2001 20:26:27 -0800
Received: from (wonbul.wonbuddhism.ac.kr) [210.97.60.2] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14hl3m-0007JH-00; Mon, 26 Mar 2001 20:26:23 -0800
Received: from unknown by wonbul.wonbuddhism.ac.kr (SMI-8.6/SMI-SVR4)
	id NAA21854; Tue, 27 Mar 2001 13:24:30 +0900
From: 
Subject: Best Toner Cartridge Prices
Date: Mon, 26 Mar 2001 23:30:02
Message-Id: <356.775354.3148@unknown>
Reply-To: dprint2000@aol.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Apparently-To: 
Apparently-To: 
To: rem-conf@es.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


D&J PRINTING CORPORATION
   2564 COCHISE DR
  ACWORTH, GA 30102
    (770) 974-8228 

 --LASER, FAX AND COPIER PRINTER TONER CARTRIDGES--

*WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS*

    ***FREE SHIPPING WITH ANY ORDER OF $200 OR MORE!!!***


CHECK OUT OUR NEW CARTRIDGE PRICES:


APPLE
  
  LASER WRITER PRO 600 OR 16/600		$65                        
  LASER WRITER SELECT 300, 310, 360 		$65          
  LASER WRITER 300, 320, 4/600 			$49                       
  LASER WRITER LS, NT, 2NTX, 2F, 2G AND 2SC	$54    
  LASER WRITER 12/640				$75

                           
HEWLETT PACKARD


  LASERJET SERIES 2, 3 AND 3D (95A) 		$49            
  LASERJET SERIES 2P AND 3P (75A)		$60	  	
  LASERJET SERIES 3SI AND 4SI (91A)		$80             
  LASERJET SERIES 4L AND 4P			$45			                    
  LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A)	$60      
  LASERJET SERIES 4000 HIGH YIELD (27X)		$95        
  LASERJET SERIES 4V				$95                          
  LASERJET SERIES 5SI, 8000			$110                     
  LASERJET SERIES 5L AND 6L			$39                   
  LASERJET SERIES 5P, 5MP, 6P, 6MP		$55              
  LASERJET SERIES 5000 (29X)			$110                  
  LASERJET SERIES 1100 (92A)			$42                   
  LASERJET SERIES 2100 (96A)			$75                   
  LASERJET SERIES 8100 (82X)			$135                   
  

HEWLETT PACKARD LASERFAX

  LASERFAX 500, 700, FX1 			$57                       
  LASERFAX 5000, 7000, FX2  			$57                    
  LASERFAX FX3					$67                                 
  LASERFAX FX4 					$77                                 


LEXMARK

  OPTRA 4019, 4029 HIGH YIELD			$130                   
  OPTRA R, 4039, 4049 HIGH YIELD		$135		               
  OPTRA S, 4059 HIGH YIELD			$135                                                             
  OPTRA N					$110                                       


EPSON LASER TONER

  EPL-7000, 8000 				$100                               
  EPL-1000, 1500				$100


EPSON INK JET                     

  STYLUS COLOR 740/760/860/SCAN 2000 (BLK)         $20

  STYLUS COLOR 440/640/740/760/860 SCAN 2000 (CLR) $20


CANON

  LBP-430 					$49                                      
  LBP-460, 465 					$59                                
  LBP-8 II					$54				
  LBP-LX					$54					
  LBP-MX					$95					
  LBP-AX					$49					
  LBP-EX					$59					
  LBP-SX					$49					
  LBP-BX					$95					
  LBP-PX					$49					
  LBP-WX					$95					
  LBP-VX					$59					
  CANON FAX L700 THRU L790 (FX1)		$59		
  CANON FAX L5000 THRU L7000 (FX2)		$59		


CANON COPIERS

  PC 3, 6RE, 7, 11 (A30)			$69			
  PC 320 THRU 780 (E40)				$90				

NEC

  SERIES 2 LASER MODEL 90, 95			$105			
  SUPERSCRIPT 860                               $115

PLEASE NOTE:

   ***FREE SHIPPING WITH ANY ORDER OF $200 OR MORE!!!***

 * WE SHIP UPS GROUND.  ADD $6.50 FOR SHIPPING AND HANDLING
 * WE ACCEPT ALL MAJOR CREDIT CARDS OR "COD" ORDERS.
 * COD CHECK ORDERS ADD $3.50 TO YOUR SHIPPING COST.
 * OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS.  
 * OUR STANDARD MERCHANDISE REPLACEMENT POLICY IS NET 90 DAYS.
 * WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS.
 * WE DO NOT CARRY: BROTHER, MINOLTA, KYOSERA, PANASONIC, XEROX, 
                    FUJITSU, OKIDATA OR SHARP PRODUCTS. 
 * WE ALSO DO NOT CARRY:  DESKJET OR BUBBLEJET SUPPLIES.
 * WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS.


           -PLACE YOUR ORDER AS FOLLOWS-

1) BY PHONE (770) 974-8228
2) BY MAIL:  D AND J PRINTING CORPORATION
             2564 COCHISE DR
             ACWORTH, GA 30102
3) BY INTERNET: DPRINT2000@AOL.COM

 INCLUDE THE FOLLOWING INFORMATION WHEN YOU PLACE YOUR ORDER:

1) YOUR PHONE NUMBER
2) COMPANY NAME
3) SHIPPING ADDRESS
4) CONTACT NAME
5) ITEMS NEEDED WITH QUANTITIES
6) METHOD OF PAYMENT (COD OR CREDIT CARD)
7) CREDIT CARD NUMBER WITH EXPIRATION DATE

** IF YOU ARE ORDERING BY PURCHASE ORDER, PLEASE INCLUDE A 
   SEPARATE BILLING ADDRESS AND SHIPPING ADDRESS WHEN NEEDED.
  
** TO BE REMOVED FROM THIS LIST, SEND YOUR REQUEST TO                              DPRINT2000@AOL.COM
               



From rem-conf Mon Mar 26 21:56:47 2001 
From rem-conf-request@es.net Mon Mar 26 21:56:46 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hmPh-0002CL-00; Mon, 26 Mar 2001 21:53:05 -0800
Received: from mail.itin.fr [212.234.52.21] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hmPf-00029j-00; Mon, 26 Mar 2001 21:53:03 -0800
Received: from plastic1 ([65.88.230.10]) by mail.itin.fr
          (Netscape Messaging Server 3.5)  with ESMTP id 612;
          Tue, 27 Mar 2001 07:49:59 +0200
From: "Kalvin Morris" 
Subject: Your Operation
To: #field0#@mail.itin.fr
Date: Mon, 26 Mar 2001 21:02:16 -0700
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE Vdiffondi.1712.3
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Message-ID: <20010327054739384.AAA263.612@plastic1>
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







FREE Computer With Merchant Account Setup





COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNET - 
HOME
BASED -  MAIL ORDER -  PHONE ORDER
Do you accept credit cards? Your competition does!
 
Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to third parties!
Home Businesses OK!  Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!



  
    
      
        Everyone Approved!
         Good Credit or Bad!  To apply today, please fill out
        the express form below=2E It
contains all the information we need to get your account approved=2E For
area's
that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application
documents necessary to establish your Merchant Account=2E Once returned we
can
have your account approved within 24 hours=2E 
        
      
    
  


  
    
      Service
      Industry
        Standard
      
        US
      
    
    
      Site
        Inspection
      $50 - $75
      FREE
    
    
      Shipping
      $50 - $75
      FREE
    
    
      Warranty
      $10 Per Month
      FREE
    
    
      Sales
        Receipts
      $10 - $50 
      FREE
    
    
      Fraud
        Screening
      
    
      $=2E50 - $1=2E00
      Per Transaction
    

FREE
    
    
      Amex Set
        Up
      $50 - $75
      FREE
    
    
      24 Hour Help
        Line
      $10 Month
      FREE
    
    
      Security
        Bond
      $5000- $10,000
        Or More
      NONE
    
  


  
    
      
        This is a No
        Obligation Qualification Form and is your first step to
        accepting credit cards=2E By filling out this form you will 
"not
        enter" in to any obligations or
        contracts with us=2E We will use it to determine the best program
        to offer you based on the information you provide=2E You will be
contacted by one of our representatives within 1-2 business days to go
over the rest of your account set up=2E
        Note: 
        All Information Provided To Us Will Remain 100%
        Confidential
        !! 
    
  


  
    
      
        Apply
        Free With No Risk!
      
    
  

  


  
    
      
        Please fill out the
        express application form completely=2EIncomplete information may
prevent us from properly
        processing your application=2E
      
    
  



  
    
      Your Full Email Address:
        be sure to use your full address (i=2Ee=2E
        user@domain=2Ecom)
      
    
    
      Your Name:
      
    
    
      Business Name:
      
    
    
      Business Phone Number:
      
    
    
      Home Phone Number:
      
    
    
      Type of Business:
      
        
          
            
              
              Retail Business
            
            
              
              Mail Order Business
            
            
              
              Internet Based Business
            
          
        
      
    
    
      Personal Credit Rating:
      
        
          
            
              
              Excellent
            
            
              
              Good
            
            
              
              Fair
            
            
              
              Poor
            
          
        
      
    
    
      How Soon Would You Like a Merchant
        Account?
      
        
      
    
    
      
        
          
          
            
              
                
            
          
          
        
      
    
  


  
  
    
      Your information is confidential, it will not be sold or used for
any other purpose, and you are under no obligation=2E
        Your information will be used solely for the purpose of evaluating
your business or website for a merchant account so that you may begin
accepting credit card payments=2E
      
    
  
  





List
 Removal/OPT-OUT Option
 Click
 Here








------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







FREE Computer With Merchant Account Setup







COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE=
T -  HOME
BASED -  MAIL ORDER -  PHONE ORDER


Do you accept credit cards? Your competition does!


 


Everyone Approved - Credit Problems OK!

Approval in less than 24 hours!

Increase your sales by 300%

Start Accepting Credit Cards on your website!

Free Information, No Risk, 100% confidential=2E

Your name and information will not be sold to third parties!

Home Businesses OK!  Phone/Mail Order OK!

No Application Fee, No Setup Fee!

Close More Impulse Sales!







  

    

      
        
Everyone Approved!

        
 Good Credit or Bad!  To=
 apply today, please fill out
        the express form below=2E It
contains all the information we need to get your account approved=2E For a=
rea's
that do not apply to you please put "n/a" in the box=2E



Upon receipt, we'll fax you with all of the all Bank Card Application
documents necessary to establish your Merchant Account=2E Once returned we=
 can
have your account approved within 24 hours=2E
 
        

      		
    

  







  
    

      Service
      Industry
        Standard
      
        
US

      		
    

    

      Site
        Inspection
      $50 - $75
      FREE
    

    

      Shipping
      $50 - $75
      FREE
    

    

      Warranty
      $10 Per Month=

      FREE
    

    

      Sales
        Receipts
      $10 - $50&nbs=
p;
      FREE
    

    

      Fraud
        Screening
      
    
      
$=2E50 - $1=2E00

      Per Transaction

    		
FREE
    

    

      Amex Set
        Up
      $50 - $75
      FREE
    

    

      24 Hour Help
        Line
      $10 Month
      FREE
    

    

      Security
        Bond
      $5000- $10,00=
0

        Or More		
      NONE
    

  




  

    

      
        
This is a No
        Obligation Qualification Form and is your first step to
        accepting credit cards=2E By filling out this form you will=
 "not
        enter" in to any obligations o=
r
        contracts with us=2E We will use it to determine the best p=
rogram
        to offer you based on the information you provide=2E You will be c=
ontacted by one of our representatives within 1-2 business days to go over =
the rest of your account set up=2E
        
<=
font color=3D"#cc0000">Note: 
        All Information Provided To Us Will Remain=
 100%
        Confidential
        !! 

    

  





  
    

      
        
Apply
        Free With No Risk!

      		
    

  


  




  

    

      
        
Pleas=
e fill out the
        express application form completely=2E
Incomplete information m=
ay prevent us from properly
        processing your application=2E

      		
    

  







  

    

      Your Full Emai=
l Address:

        be sure to use your full address (i=
=2Ee=2E
        user@domain=2Ecom)		
      
    

    

      Your Name:
      
    

    

      Business Name:=

      
    

    

      Business Phone=
 Number:
      
    

    

      Home Phone Num=
ber:
      
    

    

      Type of Busine=
ss:
      
        

          

            

              
              Retail Business
            

            

              
              Mail Order Business
            

            

              
              Internet Based Busines=
s
            

          

        

      		
    

    

      Personal Credi=
t Rating:
      
        

          

            

              
              Excellent
            

            

              
              Good
            

            

              
              Fair
            

            

              
              Poor
            

          

        

      		
    

    

      How Soon Would=
 You Like a Merchant
        Account?
      
        

      		
    

    

      
        

          

          

            

              
                

            

          

          

        

      		
    

  






  

  

    

      Your info=
rmation is confidential, it will not be sold or used for any other purpose,=
 and you are under no obligation=2E
        Your information will be used solely for the purpose of evaluating=
 your business or website for a merchant account so that you may begin acce=
pting credit card payments=2E
      
    

  

  









List
 Removal/OPT-OUT Option
 
Click
 Here







------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--






From rem-conf Tue Mar 27 05:48:58 2001 
From rem-conf-request@es.net Tue Mar 27 05:48:57 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14htkn-0004Fm-00; Tue, 27 Mar 2001 05:43:21 -0800
Received: from host217-32-147-114.hg.mdip.bt.net (server) [217.32.147.114] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14htkj-0004Fc-00; Tue, 27 Mar 2001 05:43:19 -0800
From:     "eBusinessAge.com" 
To:        
Message-Id: <419.436977.65539201info@eBusinessAge.com>
Subject: London Ticket Brokers Event Update 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Tue, 27 Mar 2001 05:43:19 -0800
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

LONDON TICKET BROKERS
Telephone 020 7833 9591

www.LTB-online.com

For All Your Ticket Requirements
Football / Concerts / Shows Etc

mailto:enquiries@LTB-online.com

Football Tickets:

Sat 31 Mar 	Arsenal v Tottenham

Sat 31 Mar 	Liverpool v Man Utd

Sat 31 Mar	Chelsea v Middlesborough

Tue 3 Apr	Man Utd v Bayem Munich

Wed 4 Apr 	Arsenal v Valencia 

Wed 4 Apr	Leeds v Deportivo

Tue 10 Apr 	Man Utd v Charlton

Fri 13 Apr 	Liverpool v Leeds

Sat 14 Apr	Arsenal v Middlesborough

Sat 14 Apr	Chelsea v Southampton

Tue 17 Apr	Tottenham v Chelsea

Thu 19 Apr	Liverpool v Barcelona

Sat 21 Apr	Arsenal v Everton 

Sat 21 Apr	Chelsea v Charlton 

Sat 21 Apr	Liverpool v Tottenham 

Sat 21 Apr	Man Utd v Man City 

Sat 28 Apr 	Tottenham v Aston Villa 

Sat 5 May	Arsenals v Leeds 

Sat 5 May	Chelsea v Everton 

Sat 5 May	Liverpool v Newcastle 

Concert Tickets:

U2 
Manchester 11th  - 12th August
Birmingham 14th August
Earls Court  18th - 19th - 21st - 22nd August
Slane Castle 25th August 

Robbie Williams 
All Dates 

Roxy Music 
Wembley 22nd- 23rd June 2001

Guns 'N Roses 
Docklands 9th June 2001

Limp Bizkit
Wembley 6th June 2001

Cliff Richards 
Sunday 13th May
Tuesday 15th May
Wednesday 16th May
Sunday 20th May
Tuesday 22nd May 
Wednesday 23rd May
Sunday 27th May

WWF Wrestling 
5th May Earls Court     

Other Events
 
The Champions League Final
The Ryder Cup 2001
The Wimbledon Championships
Royal Ascot
The French Open
International Cricket
The Lion King
Mamma Mia
The British Open
The British Grand Prix 2001
 
London Ticket Brokers is able to supply
just your ticket or full corporate hospitality 
packages for all sporting events.
   
Telephone 020 7833 9591
  

Further transmissions to you by the sender of this email may be 
stopped if required at any time by just clicking on the link below and  
sending the eMail. 

To be Removed from this Mailing list click below. 
mailto:remove@eBusinessAge.com?subject=remove


                                              
                              
 
 
 
        
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 




 





 










From rem-conf Tue Mar 27 09:21:26 2001 
From rem-conf-request@es.net Tue Mar 27 09:21:25 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14hx4s-0001PA-00; Tue, 27 Mar 2001 09:16:18 -0800
Received: from east.isi.edu [38.245.76.2] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14hx4q-0001P0-00; Tue, 27 Mar 2001 09:16:16 -0800
Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id MAA19474
	for ; Tue, 27 Mar 2001 12:16:07 -0500 (EST)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f2RHGFN05556
	for ; Tue, 27 Mar 2001 12:16:15 -0500
Message-Id: <200103271716.f2RHGFN05556@chiron.east.isi.edu>
To: rem-conf@es.net
Subject: Presentation slides from Minneapolis
Date: Tue, 27 Mar 2001 12:16:15 -0500
From: Colin Perkins 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Please can anyone who presented at the AVT meeting in Minneapolis send me a
copy of your presentation slides? Those which have been received so far are
available from http://www.east.isi.edu/DIV7/IETF/AVT/ and will be included
in the minutes.

Thanks,
Colin



From rem-conf Tue Mar 27 12:29:41 2001 
From rem-conf-request@es.net Tue Mar 27 12:29:40 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14i00W-00060p-00; Tue, 27 Mar 2001 12:24:00 -0800
Received: from www3.threelight.co.jp (ipshome) [202.241.227.195] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14i00U-00060R-00; Tue, 27 Mar 2001 12:23:58 -0800
Received: from computer3 (rsvp-207-173-123-101.ac17.rcrd.eli.net [207.173.123.101]) by ipshome (8.6.12/8.6.9) with SMTP id FAA29970; Wed, 28 Mar 2001 05:32:19 +0900
Date: Wed, 28 Mar 2001 05:32:19 +0900
From: moneysource@delphi.net
Message-Id: <200103272032.FAA29970@ipshome>
To: moneysource@delphi.net
Subject: GUARANTEED way to QUICKLY have EXCELLENT CREDIT!!
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
content-length: 5728
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list






$$  GUARANTEED WAY TO QUICKLY HAVE EXCELLENT CREDIT!!   $$


Dear Friend,

Give yourself the ADVANTAGE of enjoying life more with EXCELLENT
CREDIT!! Over the past 8 years I have perfected a system called
the Proven Credit Advantage Program. It's a guaranteed way for
legally getting an excellent credit rating almost instantly. 
Here's how:

If you have bad credit you will simply go through my easy 5 step
program to quickly get a new, legal, unblemished credit file and 
establish Excellent Credit. If you don't have bad credit, but
want to make your existing credit EXCELLENT, we will go straight
to STEP 5.

Step 1 - 
Because no two people in the United States have the same Social
Security Number, Banks and Creditors access your credit file 
almost entirely by your SS#. You will not want to change your
Social Security Number because it is extremely difficult to do 
so and you need it for your Employment, Taxes and Social 
Security Benefits. The FEDERAL PRIVACY ACT OF 1974 clearly
states that only the Government and your employer can force you 
to use your SS#. Because of this law you are allowed to legally
use another 9 digit number to use in place of your Social
Security # on credit applications. 

The first day you become our client, you will receive your own
number through the Employer Identification Number Program. You
will need us for this because 95% of all Employer Identification
Numbers, although 9 digits, do not look anything like Social
Security Numbers and cannot be used on credit applications.
We will legally get you an Employer Identification Number that 
fits in the same range of Social Numbers in use today. Because 
the Federal Laws do not require you to give your SS# to anyone
besides your Employer and the Government, you can now legally 
use this number in place of your SS# on credit applications. 
Remember, your new number will only be used for new credit. 

Step 2 - 
No two people with the same name have the same mailing address,
so you will need to obtain a new mailing address for use on your
new credit file. A friend, relative or mailbox address in your
area will be perfect.

Step 3 - 
No two people with the same name have the same telephone numbers, 
so you will also need a new telephone number for use on your
new credit file. A friend, relative, voice mail or pager will 
again work perfectly.

Step 4 - 
With your new Social Security number, new address and new
telephone number we will open your new credit file. It will now 
be totally impossible for any creditor to know anything about
your past credit history.

Step 5-
To guarantee that you will quickly have EXCELLENT CREDIT, we
will assist you in instantly adding UNLIMITED positive
information to your credit file. This is an unknown way of 
adding real accounts to your new credit file to give you an 
Excellent Credit Rating in less than 15 days. As you know, the 
more positive information on your credit file, the more money 
banks will lend you. Countless clients of ours have credit lines
over $100,000 because of our Proven Credit Advantage Program!

When we are finished you will receive a copy of your credit
file proving that you now have excellent credit! This will take
less than 15 days. You will now be able to easily qualify for
ANY credit you apply for! To be on the road to EXCELLENT CREDIT
simply send us your name, complete mailing address including 
zip code and telephone number (optional), along with a check
or money order payable to American Financial Services Inc. 
for $29.95. 

Send to: 
American Financial Services Inc.
Attn.: Mike Robbins
311 N. Robertson Blvd. 
Suite 625
Beverly Hills, CA 90210

All necessary paperwork along with a telephone number to contact
us for assistance will be sent to you priority mailed to you 
within 3 business days.

   $$$$ RISK FREE DOUBLE YOUR MONEY BACK GUARANTEE!!  $$$$

My Proven Credit Advantage Program unconditionally guarantees 
you will qualify for personal loans, business loans, credit 
cards, auto loans, home loans and any other credit you apply for!

If you are not able to qualify for credit after using my program, 
simply return your Proven Credit Advantage Program along with
your denial letter and your $29.95 investment will be refunded
DOUBLE! That's a $59.90 refund if this doesn't work like I said!

I make this guarantee to you because the Proven Credit Advantage
Program has already helped over 15,000 people just like you.
I KNOW it works - all you need to do is sign up TODAY! I truly 
look forward to making you another SATISFIED CLIENT!!
.................................................................
Yes! I deserve excellent credit. Please enroll me in the Proven
Credit Advantage Program. Enclosed is my check/money order for 
$29.95. The following information is for our records only and 
does not need to be your new credit file information.

First Name______________________________

Last Name________________________________

Address__________________________________

City_____________________________________

State_______________Zip__________________

Telephone(optional)______________________

e-mail___________________________________

If you would prefer to download your Proven Credit Advantage
Program, simply check below and we will e-mail you a download 
upon receipt of your order. Otherwise we will Priority Mail your 
program to the above address.


___ Please e-mail me my PROVEN CREDIT ADVANTAGE PROGRAM to the 
    above e-mail address.

___ Please send me my PROVEN CREDIT ADVANTAGE PROGRAM via 
    United States Priority Mail to the above address.


Send $29.95 to: 
American Financial Services Inc.
Attn: Mike Robbins
311 N. Robertson Blvd. 
Suite 625
Beverly Hills, CA 90210









From rem-conf Tue Mar 27 13:39:05 2001 
From rem-conf-request@es.net Tue Mar 27 13:39:04 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14i150-0000NR-00; Tue, 27 Mar 2001 13:32:42 -0800
Received: from totem.ci.uv.es (idolo.uv.es) [147.156.200.2] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14i14y-0000NH-00; Tue, 27 Mar 2001 13:32:41 -0800
Received: from idolo.ci.uv.es (idolo.ci.uv.es [147.156.1.38])
	by idolo.uv.es (8.9.3/8.9.3) with SMTP id XAA03662
	for rem-conf@es.net; Tue, 27 Mar 2001 23:32:37 +0200 (METDST)
From: Francisco Garcia Cortes 
To: rem-conf@es.net
Subject: Netmeeting in the LAN
Date: Tue Mar 27 23:32:38 2001
X-Mailer: postman 1.4
Message-ID: <5633255162frangar3@alumni.uv.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Hi everybody!

I would like to know how can use Netmeeting in a LAN without using a ILS(It=
ernet Lcator Server), i mean, i want to know if there is any way to establi=
sh a videoconferencing between two computers of my LAN and how can i do (co=
nfigure the Netmeeting) this?

Thank you very much for your answers.


=0A



From rem-conf Tue Mar 27 14:51:58 2001 
From rem-conf-request@es.net Tue Mar 27 14:51:58 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14i2GD-0002p0-00; Tue, 27 Mar 2001 14:48:21 -0800
Received: from (ms.yantaiport.com) [202.110.205.178] 
	by mail1.es.net with smtp (Exim 1.81 #2)
	id 14i2GC-0002oW-00; Tue, 27 Mar 2001 14:48:20 -0800
Received: from Received: from [192.168.1.2] ([24.7.157.115]) by mail.rdc1.tx.home.com  ([38.37.111.61]) by ms.yantaiport.com (Lotus SMTP MTA v4.6.2  (693.3 8-11-1998)) with SMTP id 48256A1C.007D2925; Wed, 28 Mar 2001 06:47:12 +0800
Message-ID: <00000b8c0d1c$000038c5$000077ff@Received: (qmail 554 invoked from network); 25 Mar 2001 23:56:02 -0000 >
To: 
From: fedup98@oceanfree.net
Subject: Rates DROPPED! Low Interest Loans From Competing Funding Institutions! 
Date: Tue, 27 Mar 2001 18:13:53 -0500
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: fedup98@oceanfree.net
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list






   
   
   
   Interest Rates have Dropped











Int=
erest Rates have Dropped....Start Saving
Now!

We
Shop The Best Loan For You!




The Money Lending Network is a 100% free service which lets you shop for a=
 mortgage conveniently and securely from the comfort of your home. Us=
ing our vast network of lenders across the U.S., we will search our d=
atabase of loan programs for the best loans that fit your needs.  Eve=
n if you're currently working with another lender or have been turned=
 down before, we can still
help.



Our loan programs can get you the cash you need for:



Debt Consolidation *
2nd Mortgage *
Refinance *
Credit Repair
Home Improvement *
New Car *
Dream Vacation *
College Tuition
To start a new business ..and much, much more!



Funding borrowers with less than perfect credit is our specialty! We =
can get you the loan you
need.



Regardless of whether you have good or bad credit, we can help you.
Ready to get started?



Simply fill out the our 60 second form, and we'll begin shopping for your =
loan.

It'=
s that easy!

=
We Make the Lenders Compete for YOUR Business!



Click Here For A
Free Mortgage Quote

=
Removal
Instructions

Click on the below link to be exclude from further communication.

Click Here=












 










From rem-conf Tue Mar 27 15:01:19 2001 
From rem-conf-request@es.net Tue Mar 27 15:01:19 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14i2QX-0003Ki-00; Tue, 27 Mar 2001 14:59:01 -0800
Received: from ddsmttayz007.sam.pentagon.mil [140.185.20.186] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14i2QW-0003Gv-00; Tue, 27 Mar 2001 14:59:00 -0800
Received: by ddsmttayz007 with Internet Mail Service (5.5.2650.21)
	id ; Tue, 27 Mar 2001 17:51:46 -0500
Message-ID: <8B0A34361237D4118C4E009027E59FA301B34C29@osdn5.osd.mil>
From: "Sato, Galen, CTR, OSD-C3I" 
To: "'Conference@Secure-Biz.net'" 
Subject: Announcement: Secure E-Business Executive Summit
Date: Tue, 27 Mar 2001 17:51:26 -0500
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


This announcement is being forwarded at the request of Dr. Margaret Myers,
DoD Deputy Chief Information Officer (Acting):  

The Department of Defense Deputy Chief Information Officer is co-hosting the
Spring Secure E-Business Executive Summit addressing the latest strategies,
architectures and technologies for e-government.  The conference is May 7-9
at the Crystal City Hilton, in Arlington, Virginia.  The Secure E-Business
Executive Summit is a best practices seminar for government information
technology (IT) leaders, standards communities, integrators, and industry
practitioners.  

     	The Secure E-Business Executive Summit is a collaboration among the
Federal CIO Council, the National Imagery & Mapping Agency, the National
Information Assurance Partnership, National Institute of Science and
Technology, National Security Agency, the U.S. Department of the Treasury,
the Department of Veterans Affairs, the Canadian Department of National
Defense, the Object Management Group, the U.S. General Services
Administration, the Computer & Communications Industry Association, the
Center for Internet Security and the Council for Excellence in Government. 
   	
Your attendance and support of the Secure E-Business Executive Summit is
requested.   Please join us so we may all better learn how to transform our
business processes into secure E-business solutions. For more information
about the conference please visit the Secure E-Biz web site located at
www.c3i.osd.mil/ebiz/

Dr. Margaret Myers
DoD Deputy Chief Information Officer (Acting)








From rem-conf Tue Mar 27 17:35:35 2001 
From rem-conf-request@es.net Tue Mar 27 17:35:34 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14i4nY-0007MK-00; Tue, 27 Mar 2001 17:30:56 -0800
Received: from ns1.packetvideo.com [63.214.191.69] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14i4nX-0007L3-00; Tue, 27 Mar 2001 17:30:55 -0800
Received: from misty.packetvideo.com ([63.214.191.76])
	by ns1.packetvideo.com (8.9.3/8.9.3) with ESMTP id RAA51522
	for ; Tue, 27 Mar 2001 17:29:49 -0800 (PST)
	(envelope-from sherwood@PacketVideo.com)
Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 27 Mar 2001 17:23:11 -0800
Message-ID: <72660A24B978D411BB8A00B0D03DFE01178F17@misty.packetvideo.com>
From: Greg Sherwood 
To: "'rem-conf@es.net'" 
Cc: Thomas Zeng ,
        David Kosiba
	 
Subject: negotiating client capabilities within RTSP
Date: Tue, 27 Mar 2001 17:23:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list



I have some questions regarding the implementation of simple capability 
negotiation within RTSP.  Many of the proposed payload formats have optional
parameters communicated through MIME attributes.  What is the preferred
method
of communicating the client capabilities?  

In a streaming application, there is no problem with the server listing
several
options in the DESCRIBE response using SDP and the syntax defined in the SDP
simcap
draft.  The client can then select the desired set of parameters through the
SETUP 
request (i.e., only does a SETUP on the stream with the desired parameters).
However, 
this method is only reasonable if the number of options is small.  In other
cases, the 
client needs to inform the server of its capabilities so they can find a
mutually agreeable
set of parameters.  The client typically has the most severe resource
limitations (especially 
for wireless handsets), so it's probably the case that the server can
accommodate whatever the 
client can handle if it is informed about the constraints.  

It seems like the "Require" field might be a method for the client to inform
the server about 
capabilities.  What is the preferred syntax if we use the Require field?  Do
we just use SDP lines?
Can we include multiple Require fields in a single request?  I get the
impression that a single 
Require per request is preferred to simplify a possible negative
acknowledgement from the server.
However, the delay may become excessive if many requests have to be made to
get through the capability
negotiation.  Also if the client sends a range of acceptable values for a
given parameter, how does the 
server indicate the selected value? Is it possible to send an entity body in
the SETUP request which 
contains the clients capabilities encoded in SDP? 

Sorry for all the questions, but there are many ways to make it work and I
want to follow the intentions
of RTSP document. Any advice would be appreciated.

- Greg Sherwood



From rem-conf Tue Mar 27 23:28:34 2001 
From rem-conf-request@es.net Tue Mar 27 23:28:34 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iAG0-0007aK-00; Tue, 27 Mar 2001 23:20:40 -0800
Received: from (prserv.net) [32.97.166.34] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iAFy-0007aA-00; Tue, 27 Mar 2001 23:20:38 -0800
Received: from rptw2kavaro (slip32-106-67-179.mlv.fr.prserv.net[32.106.67.179])
          by prserv.net (out4) with SMTP
          id <2001032807203520400e0gr2e>; Wed, 28 Mar 2001 07:20:36 +0000
Reply-To: 
From: "Olivier Avaro" 
To: "'Hari Kalva'" ,
	
Cc: "gen-sys@advent. ee. columbia. edu \(E-mail\)" 
Subject: RE: MP4 Player Available for Download
Date: Tue, 27 Mar 2001 09:12:59 +0200
Message-ID: <000201c0b757$9046f120$b3436a20@rptw2kavaro>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi all,

For clarification on some questions raised by the original mail from Hari.

1- mp4 is the file format of MPEG-4. If you comply to the mp4 spec., you can
parse any mp4 stream. The ability to play the stream is another dimension
covered by the signaling of the audio, video, graphics and scene description
profiles contained in the file.

2- Because it would be nice when opening an mp4 file to know what bundles of
codecs you need, the mp4 file format contains specific tags to signal this.
As decided in the last MPEG meeting, these tags will be in part managed by a
registration authority outside MPEG. Industry fora, like ISMA, 3GPP, ... can
therefore defined the specific flavor of the MP4 file and signal it in a
clean way.

3- It's great to see the MPEG-4 wave happening now, with new MPEG-4 products
released regularly (and not only audio and video !).Still, I am also
concerned about the confusion created when people do not announce to what
part of MPEG-4 they comply. It would be interesting to have this information
>from the technology provider, otherwise the products are pretty useless, and
even more, they do not serve neither themselves nor the standard.

4- I join Philippe regarding patents issues. I am also surprised by the kind
of naive questions raised and therefore am inclined to doubt their true
naivity. Quoting Leonardo : "Of course getting things for free is nice, but
wise buyers know that a "free" price tag on something that is known to be
valuable means that the cost of that particular "free" item is just folded
into another cost item. The particular cost item that remunerates those who
have developed Intellectual Property applies to the MPEG standard solution
as much as to a proprietary solution. The fact that there is no explicit
price tag for the Intellectual Property of proprietary solutions does not
mean there there is no cost associated with it, it just means that it is
hidden. And this is not necessarily a good feature for a wise buyer.". I
would add to this that before considering developing another solution,
possibly free of IP, maybe wise buyers should consider the cost of doing so,
including the extra cost of navigating between the existing patents.

Kind regards,

Olivier

> > >> Flavor Software is proud to release the first commercial
> > MPEG-4 player
> > >> and authoring software. The Mild Flavor(tm) player and
> > sample MP4 files
> > >> featuring New York City indi bands "The Pasties", "Brave
> > New Girl", and
> > >> "The Rosenbergs" are available for download from the
> > Flavor Software web
> > >> site.
> > >>
> > >> Go to http://www.flavorsoftware.com and click on downloads.
> > >>
> > >> Spread the joy... tell your friends to go to the Flavor
> > web site and get
> > >> into MP4! Even better... create your own MP4 files and
> > send them to your
> > >> friends!  -- The Flavor Team




From rem-conf Wed Mar 28 08:15:34 2001 
From rem-conf-request@es.net Wed Mar 28 08:15:34 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iIW1-00045E-00; Wed, 28 Mar 2001 08:09:45 -0800
Received: from opt5.adgrafix.com (humanahom.com) [216.248.193.11] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iIVz-00044x-00; Wed, 28 Mar 2001 08:09:43 -0800
Received: from localhost [193.252.29.90] by humanahom.com [216.248.193.11]
	with SMTP (MDaemon.v3.5.4.T)
	for ; Wed, 28 Mar 2001 23:01:16 -0500
X-Sender: cp@humanahom.com
From: cp@humanahom.com 
To: rem-conf@es.net
Date: Wed, 28 Mar 2001 16:54:00 +0000
Subject: Your culture
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-MDRemoteIP: 193.252.29.90
X-Return-Path: cp@humanahom.com
X-MDaemon-Deliver-To: rem-conf@es.net
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

We need to devide culture... yours too...
Please accept it, connecting you to www.humanahom.com

If you need further informations about us or our project, please connect you 
to our site or simply reply to this mail.

If culture doesn't interess you, choose "optout" option, by replying to this 
mail, with "optout" in its subject.

Best regards,
Christophe Parmentier





From rem-conf Wed Mar 28 18:18:26 2001 
From rem-conf-request@es.net Wed Mar 28 18:18:26 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iRtW-0001ud-00; Wed, 28 Mar 2001 18:10:38 -0800
Received: from prognet.com [205.219.198.1] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iRtV-0001uT-00; Wed, 28 Mar 2001 18:10:37 -0800
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id SAA23707;
	Wed, 28 Mar 2001 18:10:30 -0800 (PST)
Message-Id: <5.0.2.1.0.20010328175627.03b30a70@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 28 Mar 2001 18:02:35 -0800
To: Greg Sherwood ,
        "'rem-conf@es.net'" 
From: Rob Lanphier 
Subject: Re: negotiating client capabilities within RTSP
Cc: Thomas Zeng , David Kosiba ,
        confctrl@ISI.EDU
In-Reply-To: <72660A24B978D411BB8A00B0D03DFE01178F17@misty.packetvideo.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi Greg,

I've cc'd the MMUSIC list, since that's the more appropriate forum.

The type of negotiation that you are suggesting is something that would 
need to be handled by extension to RTSP.  There's currently no way, other 
than the "Require" header, for the client to announce its capability set to 
the server, and there isn't yet a standardized set of Require extensions.

Mind you, you probably don't want to use the Require header anyway.  That 
would force an extra round trip from the server if the feature isn't 
supported, and you don't get the benefit of learning what the server *does* 
have to offer, since it's required to return a "feature not supported" 
response.  It's harmless to let the server return a DESCRIBE response, and 
then decide whether or not to proceed to SETUP the streams or not.

The best thing you could do is add a header which lists the media types in 
the DESCRIBE request:

DESCRIBE rtsp://example.org/foo.rm RTSP/1.0
Accept-RTP-Payload:  audio/AMR/8000, audio/AMR-WB/16000
...

....which would then possibly restrict the server to the listed codecs.  If 
the server ignored this header, the client could still determine whether or 
not its capable of playing back the media based on what is returned in the 
SDP in the DESCRIBE response.

You may want to model this after the "Accept" header usage described in RFC 
2295 (http://www.ietf.org/rfc/rfc2295.txt), but that may be more complex 
than you want.

This hasn't been a problem in our system, since the client usually has 
*far* more capabilities than the server has options for returning the content.

Hope this helps.

Rob

At 05:23 PM 3/27/01 -0800, Greg Sherwood wrote:


>I have some questions regarding the implementation of simple capability
>negotiation within RTSP.  Many of the proposed payload formats have optional
>parameters communicated through MIME attributes.  What is the preferred
>method
>of communicating the client capabilities?
>
>In a streaming application, there is no problem with the server listing
>several
>options in the DESCRIBE response using SDP and the syntax defined in the SDP
>simcap
>draft.  The client can then select the desired set of parameters through the
>SETUP
>request (i.e., only does a SETUP on the stream with the desired parameters).
>However,
>this method is only reasonable if the number of options is small.  In other
>cases, the
>client needs to inform the server of its capabilities so they can find a
>mutually agreeable
>set of parameters.  The client typically has the most severe resource
>limitations (especially
>for wireless handsets), so it's probably the case that the server can
>accommodate whatever the
>client can handle if it is informed about the constraints.
>
>It seems like the "Require" field might be a method for the client to inform
>the server about
>capabilities.  What is the preferred syntax if we use the Require field?  Do
>we just use SDP lines?
>Can we include multiple Require fields in a single request?  I get the
>impression that a single
>Require per request is preferred to simplify a possible negative
>acknowledgement from the server.
>However, the delay may become excessive if many requests have to be made to
>get through the capability
>negotiation.  Also if the client sends a range of acceptable values for a
>given parameter, how does the
>server indicate the selected value? Is it possible to send an entity body in
>the SETUP request which
>contains the clients capabilities encoded in SDP?
>
>Sorry for all the questions, but there are many ways to make it work and I
>want to follow the intentions
>of RTSP document. Any advice would be appreciated.
>
>- Greg Sherwood




From rem-conf Wed Mar 28 22:42:00 2001 
From rem-conf-request@es.net Wed Mar 28 22:42:00 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iW2K-0000lO-00; Wed, 28 Mar 2001 22:36:00 -0800
Received: from usc.edu [128.125.253.136] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iW2J-0000lE-00; Wed, 28 Mar 2001 22:35:59 -0800
Received: from aludra.usc.edu (younggoo@aludra.usc.edu [128.125.253.184])
	by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id WAA25144 for ; Wed, 28 Mar 2001 22:35:58 -0800 (PST)
Received: from localhost (younggoo@localhost)
	by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id WAA01638 for ; Wed, 28 Mar 2001 22:35:57 -0800 (PST)
Date: Wed, 28 Mar 2001 22:35:57 -0800 (PST)
From: younggoo 
To: rem-conf@es.net
Subject: RTP-RTCP port.
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear ..

May I ask that what is the philosophy of using different
port for RTP and RTCP ?

If anyone knows answer, please let me know.
Thanks in advance.




From rem-conf Thu Mar 29 03:12:47 2001 
From rem-conf-request@es.net Thu Mar 29 03:12:47 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iaAi-0007H4-00; Thu, 29 Mar 2001 03:00:56 -0800
Received: from gwsmtp.thomson-csf.com [195.101.39.226] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iaAa-0007F1-00; Thu, 29 Mar 2001 03:00:50 -0800
Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.1.053)
        id 3AC245D90000BBFF for rem-conf@es.net; Thu, 29 Mar 2001 13:03:07 +0200
Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.1.053)
        id 3ABED8900005B328 for rem-conf@es.net; Thu, 29 Mar 2001 12:59:30 +0200
Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Thu, 29 Mar 2001 12:59:29 +0200 (Paris, Madrid (heure d'été))
Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 5.1.053)
        id 3AB5BDDB0000B324 for rem-conf@es.net; Thu, 29 Mar 2001 11:59:45 +0200
Received: from thomcast.thomson-csf.com ([178.3.1.89])
          by minos.snmrennes.thomcast.thomson-csf.com
          (Netscape Messaging Server 3.62)  with ESMTP id 365;
          Thu, 29 Mar 2001 12:50:58 +0200
Message-ID: <3AC32385.CDFC0A0E@thomcast.thomson-csf.com>
Date: Thu, 29 Mar 2001 12:59:01 +0100
From: "Marc Le Naour" 
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: younggoo 
CC: rem-conf@es.net
Subject: Re: RTP-RTCP port.
References: 
Content-Type: multipart/mixed;
 boundary="------------391B24316D0E6F1DD309BDAE"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This is a multi-part message in MIME format.
--------------391B24316D0E6F1DD309BDAE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit

Dear younggoo,

I think using different port for RTP and RTCP is useful in order to
separate "control layer" and "transport layer", particularly in order to
manage QoS without any polluting of the transport ....( just filtering
and VCR orders)

younggoo wrote:

> Dear ..
>
> May I ask that what is the philosophy of using different
> port for RTP and RTCP ?
>
> If anyone knows answer, please let me know.
> Thanks in advance.

--------------391B24316D0E6F1DD309BDAE
Content-Type: text/x-vcard; charset=us-ascii;
 name="marc.lenaour.vcf"
Content-Description: Card for Marc Le Naour
Content-Disposition: attachment;
 filename="marc.lenaour.vcf"
Content-Transfer-Encoding: 7Bit

begin:vcard 
n:Le Naour;Marc
tel;cell:06.63.59.32.38
tel;work:02.99.22.76.32
x-mozilla-html:TRUE
org:SII/THALES Broadcast Multimedia;Stream Server Department
version:2.1
email;internet:Marc.Lenaour@Thomcast.thomson-csf.com
title:Software & Telecom Engineer
adr;quoted-printable:;;40, rue de Bray=0D=0ACesson-Sevigne=0D=0A35510 Rennes;Cesson-Sévigné;;;France
fn:Marc Le Naour
end:vcard

--------------391B24316D0E6F1DD309BDAE--




From rem-conf Thu Mar 29 03:14:15 2001 
From rem-conf-request@es.net Thu Mar 29 03:14:15 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iaMR-0007YI-00; Thu, 29 Mar 2001 03:13:03 -0800
Received: from obelix.teleste.fi [212.213.16.9] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iaMQ-0007Xl-00; Thu, 29 Mar 2001 03:13:02 -0800
Received: by obelix.teleste.fi with Internet Mail Service (5.5.2650.21)
	id ; Thu, 29 Mar 2001 14:08:30 +0300
Message-ID: <514B833CB5E4D1118E320008C724B24B176D6A@obelix.teleste.fi>
From: "Jakobsson, Anders" 
To: "'rem-conf@es.net'" 
Subject: MPTS over RTP
Date: Thu, 29 Mar 2001 14:08:21 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

What payload type should be used with MPEG-2 Multi program transport
streams? Is it the same that is used for transport streams in general, or
what about the payload for bundled type MPEG?
I'll be grateful for all help, since I'm only a novice in these matters.




From rem-conf Thu Mar 29 06:06:43 2001 
From rem-conf-request@es.net Thu Mar 29 06:06:42 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14id13-0004wa-00; Thu, 29 Mar 2001 06:03:09 -0800
Received: from letters.cs.ucsb.edu [128.111.41.13] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14id12-0004wQ-00; Thu, 29 Mar 2001 06:03:08 -0800
Received: from muddy.cs.ucsb.edu (muddy [128.111.49.130])
	by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA00684;
	Thu, 29 Mar 2001 06:02:48 -0800 (PST)
Received: by muddy.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
	id GAA07375 for ; Thu, 29 Mar 2001 06:02:49 -0800 (PST)
Date: Thu, 29 Mar 2001 06:02:49 -0800 (PST)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200103291402.GAA07375@muddy.cs.ucsb.edu>
To: katia@cse.ucsc.edu
Subject: Global Internet 2001 Deadline Extension
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Due to the numerous requests, etc. etc.  we are extending the
deadline for Global Internet 2001 to April 8, 2001 at 11:59pm.

Another note.  The submissions length is five pages.  Papers
that are significantly over will NOT be reviewed.

---------------
                       Sixth Global Internet Symposium
                             in conjunction with

                                Globecom 2001
                           San Antonio, Texas, USA
                            November 25-29, 2001

                        http://www.cs.ucsb.edu/gi2001/
  ------------------------------------------------------------------------

                              Call For Papers

The sixth Global Internet Symposium will be held simultaneously and
co-located with Globecom 2001. Therefore, all of the relevant dates,
location, travel information are derived from the Globecom 2001
(http://www.globecom2001.com/) conference site.

Symposium Topics

Global Internet 2000 solicits technical papers on Internet-related topics.
The Program Committee encourages papers submitted on experimental systems
and emerging technologies. Also encouraged are original submissions
describing promising work in progress, original speculations about the
future of the Internet, and progressive position papers. Topics of interest
include, but are not limited to:

   * Novel applications and new paradigms (telephony, streaming media, etc.)
   * Distributed Internet applications (file sharing, games, conferencing, etc.)
   * Service provisioning, monitoring, and management
   * Privacy and/or security issues
   * Charging and billing issues
   * Handling Internet dynamics/heterogeneity (by applications and/or network)
   * Routing (unicast, multicast, anycast, etc.)
   * Traffic measurement, analysis, modeling, and visualization
   * Flow management (fairness/sharing, differentiated services, etc.)
   * The Internet and mobility/mobile devices
   * Wireless device access and Internet gateways

Important Dates

            Manuscript Submission:       April 8, 2001 at 11:59pm PDT
            Acceptance Notification:     July 31, 2001
            Final Manuscript:            September 31, 2000

Submission Instructions

   Please see the Global Internet Symposium WWW site at:

      http://www.cs.ucsb.edu/gi2001/

Technical Program Chairs

     Kevin Almeroth, UC-Santa Barbara (almeroth@cs.ucsb.edu)
     Katia Obraczka, UC-Santa Cruz (katia@cse.ucsc.edu)

Program Committee

     See the WWW page.

Sponsorship

The Global Internet Symposium is sponsored by the IEEE Communications
Society InternetTC.



From rem-conf Thu Mar 29 07:28:26 2001 
From rem-conf-request@es.net Thu Mar 29 07:28:26 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ieHt-0007Ny-00; Thu, 29 Mar 2001 07:24:37 -0800
Received: from mail-blue.research.att.com [135.207.30.102] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ieHs-0007No-00; Thu, 29 Mar 2001 07:24:36 -0800
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id B7FD34CE35; Thu, 29 Mar 2001 10:24:34 -0500 (EST)
Received: from vtpc3 ([135.207.132.105])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA07930;
	Thu, 29 Mar 2001 10:24:12 -0500 (EST)
Message-ID: <007c01c0b864$92ad1170$6984cf87@vtpc3>
Reply-To: "M. Reha Civanlar" 
From: "M. Reha Civanlar" 
To: "Jakobsson, Anders" ,
	
References: <514B833CB5E4D1118E320008C724B24B176D6A@obelix.teleste.fi>
Subject: Re: MPTS over RTP
Date: Thu, 29 Mar 2001 10:26:05 -0500
Organization: AT&T Labs - Research
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

You are supposed to use the transport payload format as defined in RFC 2250.
BMPEG is for elementary A/V streams.

M. Reha Civanlar

----- Original Message -----
From: "Jakobsson, Anders" 
To: 
Sent: Thursday, March 29, 2001 6:08 AM
Subject: MPTS over RTP


> What payload type should be used with MPEG-2 Multi program transport
> streams? Is it the same that is used for transport streams in general, or
> what about the payload for bundled type MPEG?
> I'll be grateful for all help, since I'm only a novice in these matters.
>
>
>




From rem-conf Thu Mar 29 08:33:53 2001 
From rem-conf-request@es.net Thu Mar 29 08:33:53 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ifJT-0001mP-00; Thu, 29 Mar 2001 08:30:19 -0800
Received: from smtprch1.nortelnetworks.com (smtprch1.nortel.com) [192.135.215.14] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ifJS-0001le-00; Thu, 29 Mar 2001 08:30:18 -0800
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 29 Mar 2001 10:19:02 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 29 Mar 2001 10:18:50 -0600
Message-ID: 
From: "Peter Barany" 
To: "'rem-conf@es.net'" 
Subject: Comment on 
Date: Thu, 29 Mar 2001 10:18:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0B86B.EE752540"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B86B.EE752540
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

A comment/request for clarification concerning the "RTP Payload Format for
AMR-WB" (. In Section 3 Payload Format,
Table 1, the "AMR-WB speech codec rates" (i.e., modes) cannot be derived
>from the "total speech bits". For example, for Index 0, 78 bits/20 msec does
not equal 6.6 kbps, etc. The SID appears to be correct though. After looking
at 3G TS 26.190 (the 3GPP AMR-WB specification), it appears that the column
marked "total speech bits" in the IETF draft is actually the "Class B +
Class C bits". If the column marked "Class A bits" in the IETF draft is
added to the column marked "total speech bits", you then get the real value
for the "total speech bits".

If someone else has already commented on this, please ignore. Thanks.

NOTE: The AMR-NB IETF draft does not suffer from this (see Section 3 Payload
Format, Table 1 in ).

Regards,

Peter Barany
Advisor
IP Multimedia Standards and Research
Nortel Networks
+1 972-685-2471 (Office)
+1 972-684-3775 (Fax)
e-mail: pbarany@nortelnetworks.com

------_=_NextPart_001_01C0B86B.EE752540
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Comment on <draft-lakaniemi-avt-amrwb-00.txt>




Hi,




A comment/request for clarification =
concerning the "RTP Payload Format for AMR-WB" =
(<draft-lakaniemi-avt-amrwb-00.txt>. In Section 3 Payload Format, =
Table 1, the "AMR-WB speech codec rates" (i.e., modes) cannot =
be derived from the "total speech bits". For example, for =
Index 0, 78 bits/20 msec does not equal 6.6 kbps, etc. The SID appears =
to be correct though. After looking at 3G TS 26.190 (the 3GPP AMR-WB =
specification), it appears that the column marked "total speech =
bits" in the IETF draft is actually the "Class B + Class C =
bits". If the column marked "Class A bits" in the IETF =
draft is added to the column marked "total speech bits", you =
then get the real value for the "total speech =
bits".



If someone else has already commented =
on this, please ignore. Thanks.




NOTE: The AMR-NB IETF draft does not =
suffer from this (see Section 3 Payload Format, Table 1 in =
<draft-ietf-avt-rtp-amr-05.txt>).



Regards,




Peter Barany

Advisor

IP Multimedia Standards and =
Research

Nortel Networks

+1 972-685-2471 (Office)

+1 972-684-3775 (Fax)

e-mail: =
pbarany@nortelnetworks.com





------_=_NextPart_001_01C0B86B.EE752540--



From rem-conf Thu Mar 29 08:47:43 2001 
From rem-conf-request@es.net Thu Mar 29 08:47:43 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14ifXu-0002p1-00; Thu, 29 Mar 2001 08:45:14 -0800
Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14ifXt-0002or-00; Thu, 29 Mar 2001 08:45:13 -0800
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2TGj6I09483;
	Thu, 29 Mar 2001 18:45:06 +0200 (MEST)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id SAA11897; Thu, 29 Mar 2001 18:45:05 +0200
Message-ID: <3AC36692.C6F01F5C@era-t.ericsson.se>
Date: Thu, 29 Mar 2001 18:45:06 +0200
From: Magnus Westerlund 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Barany 
CC: "'rem-conf@es.net'" 
Subject: Re: Comment on 
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi,

Thanks, we are aware of that this table is in error. This will be
corrected in the new draft for both narrowband and wideband.

Regards

Magnus W.

Peter Barany wrote:

>
>
> Hi,
>
> A comment/request for clarification concerning the "RTP Payload Format
> for AMR-WB" (. In Section 3 Payload
> Format, Table 1, the "AMR-WB speech codec rates" (i.e., modes) cannot
> be derived from the "total speech bits". For example, for Index 0, 78
> bits/20 msec does not equal 6.6 kbps, etc. The SID appears to be
> correct though. After looking at 3G TS 26.190 (the 3GPP AMR-WB
> specification), it appears that the column marked "total speech bits"
> in the IETF draft is actually the "Class B + Class C bits". If the
> column marked "Class A bits" in the IETF draft is added to the column
> marked "total speech bits", you then get the real value for the "total
> speech bits".
>
> If someone else has already commented on this, please ignore. Thanks.
>
> NOTE: The AMR-NB IETF draft does not suffer from this (see Section 3
> Payload Format, Table 1 in ).
>
> Regards,
>
> Peter Barany
> Advisor
> IP Multimedia Standards and Research
> Nortel Networks
> +1 972-685-2471 (Office)
> +1 972-684-3775 (Fax)
> e-mail: pbarany@nortelnetworks.com

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se






From rem-conf Fri Mar 30 05:38:21 2001 
From rem-conf-request@es.net Fri Mar 30 05:38:20 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14iyyb-0007Lc-00; Fri, 30 Mar 2001 05:30:05 -0800
Received: from nscolmar.uha.fr [194.167.108.34] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14iyyZ-0007Jw-00; Fri, 30 Mar 2001 05:30:03 -0800
Received: from [194.167.108.50] (admpcsrv1.uha.fr [194.167.108.50])
          by nscolmar.uha.fr (8.11.0/jtpda-5.3.3) with SMTP id f2U9IlX31176
          ; Fri, 30 Mar 2001 11:18:48 +0200
Received: from admpcsrv1.uha.fr by [194.167.108.50]
          via smtpd (for nscolmar.uha.fr [194.167.108.34]) with SMTP; 30 Mar 2001 09:29:36 UT
Received: from gtrpc31 ([192.168.12.82])
          by admpcsrv1.uha.fr (Lotus Domino Release 5.0.3 (Intl))
          with SMTP id 2001033011123783:6625 ;
          Fri, 30 Mar 2001 11:12:37 +0200 
Message-Id: <3.0.1.32.20010330112529.00905a60@uha.fr>
X-Sender: conf@uha.fr (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Fri, 30 Mar 2001 11:25:29 +0200
To: conf@uha.fr
From: conf@uha.fr
Subject: Call for participation for ICN01 and Call for Papers for
  ECUMN'02
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21
 March 2000) at 30/03/2001 11:12:37,
	Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March
 2000) at 30/03/2001 11:27:05,
	Serialize complete at 30/03/2001 11:27:05
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear All,

Please feel free to circulate to interested colleagues:

1. The preliminary program of ICN01 (International Conference on
Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be
held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001.
If you would like to Chair a session during ICN01, please contact
lorenz@ieee.org

2. The call for papers of ECUMN'02 (see
http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April
10, 2002. The deadline for this CfP is September 1, 2001.

Accept our sincere apologies if you receive multiple copies.





From rem-conf Fri Mar 30 05:49:15 2001 
From rem-conf-request@es.net Fri Mar 30 05:49:14 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14izFw-0000UR-00; Fri, 30 Mar 2001 05:48:00 -0800
Received: from netsys.kaist.ac.kr [143.248.148.90] (root)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14izFt-0000Tg-00; Fri, 30 Mar 2001 05:47:58 -0800
Received: from nscolmar.uha.fr (nscolmar.uha.fr [194.167.108.34])
	by netsys.kaist.ac.kr (8.11.0/8.11.0) with ESMTP id f2V7i2v29326
	for ; Fri, 30 Mar 2001 22:44:03 -0900
Received: from [194.167.108.50] (admpcsrv1.uha.fr [194.167.108.50])
          by nscolmar.uha.fr (8.11.0/jtpda-5.3.3) with SMTP id f2U9I2X31042
          ; Fri, 30 Mar 2001 11:18:02 +0200
Received: from admpcsrv1.uha.fr by [194.167.108.50]
          via smtpd (for nscolmar.uha.fr [194.167.108.34]) with SMTP; 30 Mar 2001 09:28:51 UT
Received: from gtrpc31 ([192.168.12.82])
          by admpcsrv1.uha.fr (Lotus Domino Release 5.0.3 (Intl))
          with SMTP id 2001033011115670:6622 ;
          Fri, 30 Mar 2001 11:11:56 +0200 
Message-Id: <3.0.1.32.20010330112447.0090c890@uha.fr>
X-Sender: conf@uha.fr (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Fri, 30 Mar 2001 11:24:47 +0200
To: conf@uha.fr
From: conf@uha.fr
Subject: Call for participation for ICN01 and Call for Papers for
  ECUMN'02
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21
 March 2000) at 30/03/2001 11:11:56,
	Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March
 2000) at 30/03/2001 11:24:06,
	Serialize complete at 30/03/2001 11:24:06
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear All,

Please feel free to circulate to interested colleagues:

1. The preliminary program of ICN01 (International Conference on
Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be
held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001.
If you would like to Chair a session during ICN01, please contact
lorenz@ieee.org

2. The call for papers of ECUMN'02 (see
http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April
10, 2002. The deadline for this CfP is September 1, 2001.

Accept our sincere apologies if you receive multiple copies.





From rem-conf Fri Mar 30 06:09:44 2001 
From rem-conf-request@es.net Fri Mar 30 06:09:43 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14izZc-0001nD-00; Fri, 30 Mar 2001 06:08:20 -0800
Received: from lumumba.luc.ac.be [193.190.9.252] (mail)
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14izZZ-0001mc-00; Fri, 30 Mar 2001 06:08:17 -0800
Received: from jori (helo=localhost)
	by lumumba.luc.ac.be with local-esmtp (Exim 3.12 #1 (Debian))
	id 14izZX-0003yl-00
	for ; Fri, 30 Mar 2001 16:08:15 +0200
Date: Fri, 30 Mar 2001 16:08:15 +0200 (CEST)
From: Jori Liesenborgs 
X-Sender: jori@lumumba.luc.ac.be
To: rem-conf@es.net
Subject: jvoiplib and jrtplib
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Jori 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Hello everybody!

It's been a while since I released JVOIPLIB and JRTPLIB, and I'm quite
curious about which projects these libraries are being used in. For this
purpose, I've added some CGI's to the homepages which allow you to add a
description of your project to a list. 

So if you're using either JVOIPLIB or JRTPLIB, I would really appreciate
it if you would fill in a small description. This gives me an idea about
how useful the libraries are...

The homepages for the libraries are:
 * for JVOIPLIB:
   http://lumumba.luc.ac.be/jori/jvoiplib/jvoiplib.html
 
 * for JRTPLIB:
   http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html

Bye,
Jori




From rem-conf Fri Mar 30 06:53:21 2001 
From rem-conf-request@es.net Fri Mar 30 06:53:20 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14j0Cv-0003Yp-00; Fri, 30 Mar 2001 06:48:57 -0800
Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14j0Ct-0003Yf-00; Fri, 30 Mar 2001 06:48:55 -0800
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f2UEmqI00710
	for ; Fri, 30 Mar 2001 16:48:53 +0200 (MEST)
Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 id <0GB000M01MHGR9@mbb1.ericsson.se> for rem-conf@es.net; Fri,
 30 Mar 2001 16:48:52 +0200 (MET DST)
Received: from ericsson.com (rcur34ip175.ericsson.se [147.214.34.175])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GB000NNZMHFD4@mbb1.ericsson.se> for rem-conf@es.net; Fri,
 30 Mar 2001 16:48:51 +0200 (MET DST)
Date: Fri, 30 Mar 2001 16:48:48 +0200
From: Johan =?iso-8859-1?Q?Sj=F6berg?= 
Subject: draft-ietf-avt-rtp-amr-06.txt submitted
To: rem-conf@es.net
Message-id: <3AC49CD0.E1DACB01@ericsson.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=iso-8859-1
X-Accept-Language: sv,en-US,en
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id f2UEmqI00710
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi,

I have just submitted the draft-ietf-avt-rtp-amr-06.txt version of the
"RTP payload format and file storage format for AMR and AMR-WB audio".

Biggest changes from the 05 version are:

1. Some inband signaling is now made out of band
2. One common payload description for AMR and AMR-WB
3. Interleaving is introduced for AMR

You can download the draft from:
http://standards.ericsson.net/rtp-pf/draft-ietf-avt-rtp-amr-06.txt

Best regards,

Johan=20

--=20
Johan Sj=F6berg
Audio Technology, Ericsson Research
-----------------------------------------------------------------
Ericsson Radio Systems AB  | Phone:  +46 8 50878230
Torshamnsgatan 23          | Fax:    +46 8 7575550
S-164 80 Stockholm, SWEDEN | mailto:johan.sjoberg@ericsson.com



From rem-conf Fri Mar 30 12:29:02 2001 
From rem-conf-request@es.net Fri Mar 30 12:29:01 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14j5S5-0004NE-00; Fri, 30 Mar 2001 12:24:57 -0800
Received: from prognet.com [205.219.198.1] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14j5S4-0004N4-00; Fri, 30 Mar 2001 12:24:56 -0800
Received: from robla350.real.com ([172.23.100.116])
	by prognet.com (8.9.2/8.9.0) with ESMTP id MAA05202;
	Fri, 30 Mar 2001 12:24:41 -0800 (PST)
Message-Id: <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 30 Mar 2001 12:25:33 -0800
To: ,
        "'Hari Kalva'" , 
From: Rob Lanphier 
Subject: RE: MP4 Player Available for Download
Cc: "gen-sys@advent. ee. columbia. edu \(E-mail\)" ,
        discuss@apps.ietf.org
In-Reply-To: <000201c0b757$9046f120$b3436a20@rptw2kavaro>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

I've hesitated from joining this conversation because it was pointed out 
that it's "off-topic".  Since everyone has been dying to get the last word 
in on this thread, and since I do think this is an important discussion to 
have, I'm requesting that we move it to the Apps area discussion list 
rather than end the thread altogether (hence the addition of 
"discuss@apps.ietf.org" to the cc line...please send followups to this 
alias instead of rem-conf).

For those in the apps area, a brief introduction.  Someone posted a note to 
rem-conf (the IETF AVT working group mail alias) on the topic of two 
players that support the ".mp4" file extension which don't 
interoperate.  The discussion turned toward the issue of whether or not 
genuine interoperability is possible, due to patent licensing restrictions, 
to which several people made statements to the effect of "oh, that's just a 
red herring".

Well, I disagree.  MPEG-4 licensing is still very murky.  Here's the 
statement in the M4IF FAQ (see http://www.m4if.org):

     Based on the information that M4IF has received, the situation
     is as follows:

     MPEG-4 Systems: A call for essential patents was issued at the
     beginning of September. Licensing is expected to start in
     Spring 2001, and should encompass all of MPEG-4 version 1 and
     version 2 technology

     MPEG-4 Visual: portfolios are under development for the Simple
     and Core Visual Profiles. Patents are currently being evaluated,
     and a meeting will be called in October. It is expected that
     licensing will begin in the beginning of 2001.

     MPEG-4 Audio: A Call for essential patents is expected by the
     end of October. Licensing should start in 2001.  Details are
     still being worked out.

In other words, there's still a bunch of people talking in smoke filled 
rooms about what the licensing terms are.  Fine....just don't push this as 
a standard that's ready for prime time.

Having seen the hue and cry in IETF plenary meetings when *one* company 
holds an essential patent, I shudder to think how a discussion of MPEG-4 
licensing would play out if done in the IETF, where my understanding is 
that there are dozens of rights holders involved in the essential 
technology.  Perhaps that's why it's never been brought up.....   :)

So, I'm at a loss.  The MPEG4 group hasn't been very vigilant in ensuring 
that the technology that they are standardizing is practical to implement, 
>from a technology perspective or from a business perspective. On the 
technology front, the specification is a sprawling set of documents from 
which only a small portion is useful for the nuts-and-bolts of 
interoperability, and even then it's not complete and is still a 
work-in-progress. On the business side, there are dozens of companies 
claiming to own intellectual property associated with essential technology 
in the specification, and the group responsible for working out a licensing 
pool (the MPEG-4 Industry Forum, M4IF) is long overdue in its attempts to 
work out the first of many pieces necessary for a complete end-to-end
system.

Would it be useful for the IETF to engage in standardization of audio/video 
file formats?  If not the IETF, then who?

Rob

At 09:12 AM 3/27/01 +0200, Olivier Avaro wrote:
>Hi all,
>
>For clarification on some questions raised by the original mail from Hari.
>
>1- mp4 is the file format of MPEG-4. If you comply to the mp4 spec., you can
>parse any mp4 stream. The ability to play the stream is another dimension
>covered by the signaling of the audio, video, graphics and scene description
>profiles contained in the file.
>
>2- Because it would be nice when opening an mp4 file to know what bundles of
>codecs you need, the mp4 file format contains specific tags to signal this.
>As decided in the last MPEG meeting, these tags will be in part managed by a
>registration authority outside MPEG. Industry fora, like ISMA, 3GPP, ... can
>therefore defined the specific flavor of the MP4 file and signal it in a
>clean way.
>
>3- It's great to see the MPEG-4 wave happening now, with new MPEG-4 products
>released regularly (and not only audio and video !).Still, I am also
>concerned about the confusion created when people do not announce to what
>part of MPEG-4 they comply. It would be interesting to have this information
>from the technology provider, otherwise the products are pretty useless, and
>even more, they do not serve neither themselves nor the standard.
>
>4- I join Philippe regarding patents issues. I am also surprised by the kind
>of naive questions raised and therefore am inclined to doubt their true
>naivity. Quoting Leonardo : "Of course getting things for free is nice, but
>wise buyers know that a "free" price tag on something that is known to be
>valuable means that the cost of that particular "free" item is just folded
>into another cost item. The particular cost item that remunerates those who
>have developed Intellectual Property applies to the MPEG standard solution
>as much as to a proprietary solution. The fact that there is no explicit
>price tag for the Intellectual Property of proprietary solutions does not
>mean there there is no cost associated with it, it just means that it is
>hidden. And this is not necessarily a good feature for a wise buyer.". I
>would add to this that before considering developing another solution,
>possibly free of IP, maybe wise buyers should consider the cost of doing so,
>including the extra cost of navigating between the existing patents.
>
>Kind regards,
>
>Olivier
>
> > > >> Flavor Software is proud to release the first commercial
> > > MPEG-4 player
> > > >> and authoring software. The Mild Flavor(tm) player and
> > > sample MP4 files
> > > >> featuring New York City indi bands "The Pasties", "Brave
> > > New Girl", and
> > > >> "The Rosenbergs" are available for download from the
> > > Flavor Software web
> > > >> site.
> > > >>
> > > >> Go to http://www.flavorsoftware.com and click on downloads.
> > > >>
> > > >> Spread the joy... tell your friends to go to the Flavor
> > > web site and get
> > > >> into MP4! Even better... create your own MP4 files and
> > > send them to your
> > > >> friends!  -- The Flavor Team




From rem-conf Fri Mar 30 13:41:24 2001 
From rem-conf-request@es.net Fri Mar 30 13:41:24 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14j6bO-0006ej-00; Fri, 30 Mar 2001 13:38:38 -0800
Received: from ss3000e.cselt.it [163.162.41.5] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14j6bM-0006dt-00; Fri, 30 Mar 2001 13:38:36 -0800
Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12])
 by ss3000e.cselt.it (PMDF V5.2-31 #43137)
 with ESMTP id <0GB10068J5CZFF@ss3000e.cselt.it> for rem-conf@es.net; Fri,
 30 Mar 2001 23:36:36 +0200 (MET DST)
Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21)
	id ; Fri, 30 Mar 2001 23:37:29 +0200
Content-return: allowed
Date: Fri, 30 Mar 2001 23:37:14 +0200
From: Chiariglione Leonardo 
Subject: RE: MP4 Player Available for Download
To: 'Rob Lanphier' , olivier.avaro@francetelecom.com,
 'Hari Kalva' , rem-conf@es.net
Cc: "gen-sys@advent. ee. columbia. edu (E-mail)"
 , discuss@apps.ietf.org
Message-id: 
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Dear Colleagues
I do not know for the IETF email address that appears in Cc:, but as =
far as
MPEG is concerned discussions about patents are not allowed by the =
ISO/IEC
directives.
I can understand that it may suit some parties to state that "MPEG-4
licensing is still very murky" and I will make no efforts to convince =
such
parties that its is not, for the very simple reason that I do not know
whether this is true or not and I do not want to know.
I will simply point out these two very simple and incontrovertible =
facts:
1. the number of MP3 processors (encoders, decoders etc.) can be =
counted by
the tens of millions (at least 60 million Napster users :-)
2. the number of MPEG-2 processors is well above 100 million (50 =
million
digital television set top boxes, 30 million hardware-based DVDs, 10 =
million
Playstation 2, an unknown number of software DVD decoders, an unknown =
number
of DviX converters :-).
I hear reports that implementation of these two standards requires the =
use
of patented technologies (I have been told about 100 patents for =
MPEG-2).
It may suit some parties to run down MPEG-4, but the power of standard
technologies demonstrated by the two cases above stays unchallenged. =
Patent
issues may be complex, but so are business decisions for which patents =
are
just one element. That is why I am sure that, as for the past, wise =
people
will make wise decisions.
In any case, please do not make further discussions about patents on =
MPEG
reflectors.
Kind regards
Leonardo Chiariglione
Convenor, ISO/IEC JTC1/SC29/WG11 (MPEG)

-----Original Message-----
From: Rob Lanphier [mailto:robla@real.com]
Sent: 2001 marzo venerd=EC 22:26
To: olivier.avaro@francetelecom.com; 'Hari Kalva'; rem-conf@es.net
Cc: gen-sys@advent. ee. columbia. edu (E-mail); discuss@apps.ietf.org
Subject: RE: MP4 Player Available for Download


I've hesitated from joining this conversation because it was pointed =
out=20
that it's "off-topic".  Since everyone has been dying to get the last =
word=20
in on this thread, and since I do think this is an important discussion =
to=20
have, I'm requesting that we move it to the Apps area discussion list=20
rather than end the thread altogether (hence the addition of=20
"discuss@apps.ietf.org" to the cc line...please send followups to this=20
alias instead of rem-conf).

For those in the apps area, a brief introduction.  Someone posted a =
note to=20
rem-conf (the IETF AVT working group mail alias) on the topic of two=20
players that support the ".mp4" file extension which don't=20
interoperate.  The discussion turned toward the issue of whether or not =

genuine interoperability is possible, due to patent licensing =
restrictions,=20
to which several people made statements to the effect of "oh, that's =
just a=20
red herring".

Well, I disagree.  MPEG-4 licensing is still very murky.  Here's the=20
statement in the M4IF FAQ (see http://www.m4if.org):

     Based on the information that M4IF has received, the situation
     is as follows:

     MPEG-4 Systems: A call for essential patents was issued at the
     beginning of September. Licensing is expected to start in
     Spring 2001, and should encompass all of MPEG-4 version 1 and
     version 2 technology

     MPEG-4 Visual: portfolios are under development for the Simple
     and Core Visual Profiles. Patents are currently being evaluated,
     and a meeting will be called in October. It is expected that
     licensing will begin in the beginning of 2001.

     MPEG-4 Audio: A Call for essential patents is expected by the
     end of October. Licensing should start in 2001.  Details are
     still being worked out.

In other words, there's still a bunch of people talking in smoke filled =

rooms about what the licensing terms are.  Fine....just don't push this =
as=20
a standard that's ready for prime time.

Having seen the hue and cry in IETF plenary meetings when *one* company =

holds an essential patent, I shudder to think how a discussion of =
MPEG-4=20
licensing would play out if done in the IETF, where my understanding is =

that there are dozens of rights holders involved in the essential=20
technology.  Perhaps that's why it's never been brought up.....   :)

So, I'm at a loss.  The MPEG4 group hasn't been very vigilant in =
ensuring=20
that the technology that they are standardizing is practical to =
implement,=20
>from a technology perspective or from a business perspective. On the=20
technology front, the specification is a sprawling set of documents =
from=20
which only a small portion is useful for the nuts-and-bolts of=20
interoperability, and even then it's not complete and is still a=20
work-in-progress. On the business side, there are dozens of companies=20
claiming to own intellectual property associated with essential =
technology=20
in the specification, and the group responsible for working out a =
licensing=20
pool (the MPEG-4 Industry Forum, M4IF) is long overdue in its attempts =
to=20
work out the first of many pieces necessary for a complete end-to-end
system.

Would it be useful for the IETF to engage in standardization of =
audio/video=20
file formats?  If not the IETF, then who?

Rob

At 09:12 AM 3/27/01 +0200, Olivier Avaro wrote:
>Hi all,
>
>For clarification on some questions raised by the original mail from =
Hari.
>
>1- mp4 is the file format of MPEG-4. If you comply to the mp4 spec., =
you
can
>parse any mp4 stream. The ability to play the stream is another =
dimension
>covered by the signaling of the audio, video, graphics and scene
description
>profiles contained in the file.
>
>2- Because it would be nice when opening an mp4 file to know what =
bundles
of
>codecs you need, the mp4 file format contains specific tags to signal =
this.
>As decided in the last MPEG meeting, these tags will be in part =
managed by
a
>registration authority outside MPEG. Industry fora, like ISMA, 3GPP, =
...
can
>therefore defined the specific flavor of the MP4 file and signal it in =
a
>clean way.
>
>3- It's great to see the MPEG-4 wave happening now, with new MPEG-4
products
>released regularly (and not only audio and video !).Still, I am also
>concerned about the confusion created when people do not announce to =
what
>part of MPEG-4 they comply. It would be interesting to have this
information
>from the technology provider, otherwise the products are pretty =
useless,
and
>even more, they do not serve neither themselves nor the standard.
>
>4- I join Philippe regarding patents issues. I am also surprised by =
the
kind
>of naive questions raised and therefore am inclined to doubt their =
true
>naivity. Quoting Leonardo : "Of course getting things for free is =
nice, but
>wise buyers know that a "free" price tag on something that is known to =
be
>valuable means that the cost of that particular "free" item is just =
folded
>into another cost item. The particular cost item that remunerates =
those who
>have developed Intellectual Property applies to the MPEG standard =
solution
>as much as to a proprietary solution. The fact that there is no =
explicit
>price tag for the Intellectual Property of proprietary solutions does =
not
>mean there there is no cost associated with it, it just means that it =
is
>hidden. And this is not necessarily a good feature for a wise buyer.". =
I
>would add to this that before considering developing another solution,
>possibly free of IP, maybe wise buyers should consider the cost of =
doing
so,
>including the extra cost of navigating between the existing patents.
>
>Kind regards,
>
>Olivier
>
> > > >> Flavor Software is proud to release the first commercial
> > > MPEG-4 player
> > > >> and authoring software. The Mild Flavor(tm) player and
> > > sample MP4 files
> > > >> featuring New York City indi bands "The Pasties", "Brave
> > > New Girl", and
> > > >> "The Rosenbergs" are available for download from the
> > > Flavor Software web
> > > >> site.
> > > >>
> > > >> Go to http://www.flavorsoftware.com and click on downloads.
> > > >>
> > > >> Spread the joy... tell your friends to go to the Flavor
> > > web site and get
> > > >> into MP4! Even better... create your own MP4 files and
> > > send them to your
> > > >> friends!  -- The Flavor Team



From rem-conf Fri Mar 30 18:39:38 2001 
From rem-conf-request@es.net Fri Mar 30 18:39:37 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14jBDD-00060H-00; Fri, 30 Mar 2001 18:33:59 -0800
Received: from mail-out2.apple.com [17.254.0.51] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14jBDC-000607-00; Fri, 30 Mar 2001 18:33:58 -0800
Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id SAA18371
	for ; Fri, 30 Mar 2001 18:33:55 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Fri, 30 Mar 2001 18:33:33 -0800
Received: from [17.219.158.123] (singeridsl2.apple.com [17.219.158.123])
	by scv3.apple.com (8.9.3/8.9.3) with ESMTP id SAA15381;
	Fri, 30 Mar 2001 18:33:32 -0800 (PST)
Mime-Version: 1.0
X-Sender: singer@mail.apple.com (Unverified)
Message-Id: 
In-Reply-To: <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com>
References: 
 
 <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com>
Date: Fri, 30 Mar 2001 18:28:32 -0800
To: Rob Lanphier 
From: Dave Singer 
Subject: RE: MP4 Player Available for Download
Cc: olivier.avaro@francetelecom.com, "'Hari Kalva'" ,
        rem-conf@es.net, discuss@apps.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list


Rob

you may be right about the licensing of MPEG-4 in general;  but I 
believe I have told this group already the best of my knowledge on 
the licensing of the file format, so I am a little disappointed that 
you should end up on that particular subject.



At 12:25 PM -0800 3/30/01, Rob Lanphier wrote:
>I've hesitated from joining this conversation because it was pointed 
>out that it's "off-topic".  Since everyone has been dying to get the 
>last word in on this thread, and since I do think this is an 
>important discussion to have, I'm requesting that we move it to the 
>Apps area discussion list rather than end the thread altogether 
>(hence the addition of "discuss@apps.ietf.org" to the cc 
>line...please send followups to this alias instead of rem-conf).
>
>For those in the apps area, a brief introduction.  Someone posted a 
>note to rem-conf (the IETF AVT working group mail alias) on the 
>topic of two players that support the ".mp4" file extension which 
>don't interoperate.  The discussion turned toward the issue of 
>whether or not genuine interoperability is possible, due to patent 
>licensing restrictions, to which several people made statements to 
>the effect of "oh, that's just a red herring".
>
>Well, I disagree.  MPEG-4 licensing is still very murky.  Here's the 
>statement in the M4IF FAQ (see http://www.m4if.org):
>
>     Based on the information that M4IF has received, the situation
>     is as follows:
>
>     MPEG-4 Systems: A call for essential patents was issued at the
>     beginning of September. Licensing is expected to start in
>     Spring 2001, and should encompass all of MPEG-4 version 1 and
>     version 2 technology
>
>     MPEG-4 Visual: portfolios are under development for the Simple
>     and Core Visual Profiles. Patents are currently being evaluated,
>     and a meeting will be called in October. It is expected that
>     licensing will begin in the beginning of 2001.
>
>     MPEG-4 Audio: A Call for essential patents is expected by the
>     end of October. Licensing should start in 2001.  Details are
>     still being worked out.
>
>In other words, there's still a bunch of people talking in smoke 
>filled rooms about what the licensing terms are.  Fine....just don't 
>push this as a standard that's ready for prime time.
>
>Having seen the hue and cry in IETF plenary meetings when *one* 
>company holds an essential patent, I shudder to think how a 
>discussion of MPEG-4 licensing would play out if done in the IETF, 
>where my understanding is that there are dozens of rights holders 
>involved in the essential technology.  Perhaps that's why it's never 
>been brought up.....   :)
>
>So, I'm at a loss.  The MPEG4 group hasn't been very vigilant in 
>ensuring that the technology that they are standardizing is 
>practical to implement, from a technology perspective or from a 
>business perspective. On the technology front, the specification is 
>a sprawling set of documents from which only a small portion is 
>useful for the nuts-and-bolts of interoperability, and even then 
>it's not complete and is still a work-in-progress. On the business 
>side, there are dozens of companies claiming to own intellectual 
>property associated with essential technology in the specification, 
>and the group responsible for working out a licensing pool (the 
>MPEG-4 Industry Forum, M4IF) is long overdue in its attempts to work 
>out the first of many pieces necessary for a complete end-to-end
>system.
>
>Would it be useful for the IETF to engage in standardization of 
>audio/video file formats?  If not the IETF, then who?
>
>Rob
>
>At 09:12 AM 3/27/01 +0200, Olivier Avaro wrote:
>>Hi all,
>>
>>For clarification on some questions raised by the original mail from Hari.
>>
>>1- mp4 is the file format of MPEG-4. If you comply to the mp4 spec., you can
>>parse any mp4 stream. The ability to play the stream is another dimension
>>covered by the signaling of the audio, video, graphics and scene description
>>profiles contained in the file.
>>
>>2- Because it would be nice when opening an mp4 file to know what bundles of
>>codecs you need, the mp4 file format contains specific tags to signal this.
>>As decided in the last MPEG meeting, these tags will be in part managed by a
>>registration authority outside MPEG. Industry fora, like ISMA, 3GPP, ... can
>>therefore defined the specific flavor of the MP4 file and signal it in a
>>clean way.
>>
>>3- It's great to see the MPEG-4 wave happening now, with new MPEG-4 products
>>released regularly (and not only audio and video !).Still, I am also
>>concerned about the confusion created when people do not announce to what
>>part of MPEG-4 they comply. It would be interesting to have this information
>>from the technology provider, otherwise the products are pretty useless, and
>>even more, they do not serve neither themselves nor the standard.
>>
>>4- I join Philippe regarding patents issues. I am also surprised by the kind
>>of naive questions raised and therefore am inclined to doubt their true
>>naivity. Quoting Leonardo : "Of course getting things for free is nice, but
>>wise buyers know that a "free" price tag on something that is known to be
>>valuable means that the cost of that particular "free" item is just folded
>>into another cost item. The particular cost item that remunerates those who
>>have developed Intellectual Property applies to the MPEG standard solution
>>as much as to a proprietary solution. The fact that there is no explicit
>>price tag for the Intellectual Property of proprietary solutions does not
>>mean there there is no cost associated with it, it just means that it is
>>hidden. And this is not necessarily a good feature for a wise buyer.". I
>>would add to this that before considering developing another solution,
>>possibly free of IP, maybe wise buyers should consider the cost of doing so,
>>including the extra cost of navigating between the existing patents.
>>
>>Kind regards,
>>
>>Olivier
>>
>>>  > >> Flavor Software is proud to release the first commercial
>>>  > MPEG-4 player
>>>  > >> and authoring software. The Mild Flavor(tm) player and
>>>  > sample MP4 files
>>>  > >> featuring New York City indi bands "The Pasties", "Brave
>>>  > New Girl", and
>>>  > >> "The Rosenbergs" are available for download from the
>>>  > Flavor Software web
>>>  > >> site.
>>>  > >>
>>>  > >> Go to http://www.flavorsoftware.com and click on downloads.
>>>  > >>
>>>  > >> Spread the joy... tell your friends to go to the Flavor
>>>  > web site and get
>>>  > >> into MP4! Even better... create your own MP4 files and
>>>  > send them to your
>>>  > >> friends!  -- The Flavor Team

-- 
David Singer
Apple Computer/QuickTime



From rem-conf Sat Mar 31 09:34:37 2001 
From rem-conf-request@es.net Sat Mar 31 09:34:36 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14jP6J-0004lt-00; Sat, 31 Mar 2001 09:23:47 -0800
Received: from mta8.srv.hcvlny.cv.net (mta8) [167.206.5.23] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14jP6F-0004lR-00; Sat, 31 Mar 2001 09:23:43 -0800
Received: from mail.optonline.com
 (ool-18bd8973.dyn.optonline.net [24.189.137.115]) by mta8.srv.hcvlny.cv.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
 with SMTP id <0GB200ISENOIUK@mta8.srv.hcvlny.cv.net> for rem-conf@es.net; Sat,
 31 Mar 2001 12:12:35 -0500 (EST)
Date: Sat, 31 Mar 2001 12:10:29 -0500 (EST)
From: financefree2001@yahoo.com
Subject: WORK AT HOME - MAKE MONEY!
To: Friend@public.com
Content-transfer-encoding: 7BIT
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hello-
I am an e-bay seller making $75,000+ per year, but I want to show 
you what I took a skeptical chance on, which I have come to realize has 
made our family at least an ADDITIONAL $252,000 THIS YEAR to date! This is a 
project and business that takes dedication, however it has ultilized only a 
fraction of the time that my regular selling does, without the costly fees that 
Ebay charges. There are countless different concepts of multi-level marketing, 
but sound marketing strategies are the key to secure financial success. 
In the summer of 1999 Donald  Trump (A Multi-Millionaire touted by Forbes 
Magazine as one of the wealthiest men in the country) made an appearance 
on the David Letterman show. Dave asked him what he would do if  he lost 
everything and had to start over from scratch. Without hesitating, Trump said 
he would find a good network marketing company and get to work.  The 
audience started to hoot and boo him. He looked out at the audience and  
dead-panned his response "That's why I'm sitting up here and you are all 
sitting out there!"

In this program I send out emails just like this one, as many as I can, and 
people send me cash in the mail for marketing information that I email back 
to them upon receipt of funds. Being a service, it is all completely legal, 
and I get to make that walk to the mailbox every day knowing that it is full 
of $5 bills for me!!

Do the math... If you send out 100,000 emails (which you can do for free, 
the reports will show you how) and only 1 in 1000 people participates, you 
just made $500...and that was only on the first level!!! At the fifth level, you 
have a realistic chance to be at over $500,000! And that is ONLY ONE person 
participating out of 1000 at each level!
 
 
Report #2 will even show you where you can get One MILLION e-mail
addresses and all of the software you will need to send emails to them, 
and HOW!!


Realize FAST how much money there is to be made, and how EASY it 
is to do over and over... Then act. Make this the one email like this you 
decide to act on.

Do you HONESTLY think you wont see your meager, one-time $25 
returned to you a hundredfold AT LEAST?? PLUS, look at the value of the 
informational reports you are getting for your money, and understand that you 
will be able to sell them over and over forever, even AFTER you have used 
them for your own monetary gain!!!

And then you can run the whole program over and over for free!! If you have 
been looking for a little fun in your life, wait till you try THIS fun...the kind that 
puts cash in your mailbox!!

Good Luck!!!

Matt Farruggio

              
==================================================


DEAR FRIENDS AND FUTURE MILLIONAIRES:



AS SEEN ON NATIONAL TV :  (Reportedly on 48 Hours, in a 1999 
feature report.)


''Making over half million dollars every 4 to 5 months from your 
home for an investment of only $25 U.S. Dollars expense one time''


THANKS TO THE COMPUTER AGE AND THE INTERNET !

                 
==================================================



BECOMING A MILLIONAIRE WITHIN A YEAR!!!


Before you say ''Bull'', please read the following. This is the 
letter you have been hearing about on the news lately. Due to the 
popularity of this letter on the Internet, a national weekly news program, 
reportedly "48 hours", recently devoted an entire show to the investigation 
of this program described below, to see if it really can make people money.  
The show also investigated whether or not the program was legal.

Their findings proved once and for all that there are ''absolutely NO Laws 
prohibiting the participation in the program and if people can -follow the 
simple instructions, they are bound to make some mega bucks with only $25 
out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY 
& RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING 
BETTER THAN EVER. 


Here is what Pam Hedland, from Fort Lee, New Jersey had to say: 
'' Thanks to this profitable opportunity. I was approached many times 
before but each time I passed on it. I am so glad I finally  joined just to 
see what one could expect in return for the minimal effort and money 
required. To my astonishment, I received total $ 610,470.00 in 21 weeks, 
with money still coming in''. 

Pam Hedland, Fort Lee, New Jersey.


===============================================================


Here is another testimonial: 

'' This program has been around for a long time but I never believed 
in it. But one day when I received this again in the mail I decided to 
gamble my $25 on it. I followed the simple instructions and voila' ... 
3 weeks later the money started to come in. First month I only made 
$240.00  but the next 2 months after that I made a total of$290,000.00. 
So far, in the past 8 months by re-entering the program, I have made over 
$710,000.00 and I am playing it again. The key to success in this program 
is to follow the simple steps and NOT change anything.'' 

More testimonials later but first.


=======PRINT THIS NOW FOR YOUR FUTURE REFERENCE ==========



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$


If you would like to make at least $500,000 every 4 to 5 months easily 
and comfortably, please read the following. THEN READ IT AGAIN 
and AGAIN !!!


$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$


 FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS:



======== Order all 5 reports shown on the list below.===========


For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name 
appears 
ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON 
YOUR 
ENVELOPE TOP LEFT CORNER in case of any mail problems.


=== When you place your order, make sure you order each of the 5 
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5=$25.00.


 === Within a few days you will receive, vie e-mail, each of the 
5 reports from these 5 different individuals. Save them on your 
computer so they will be accessible for you to send to the 1,000's 
of people who will order them from you. Also make a floppy of these 
reports and keep it on your desk in case something happens to your computer.



=== IMPORTANT __ DO NOT alter the names of the people who are 
listed next to each report, or their sequence on the list, in any way 
other than what is instructed below in step '' 1 through 6 '' or you will lose out 
on majority of your profits.


Once you understand the way this works, you will also see how it 
does not work if you change it. Remember, this method has been tested, 
and if you alter, it will NOT work !!! People have tried to put their 
friends/relatives names on all five thinking they could get all the money. 
But it does not work this way. Believe us, we all have tried to be greedy and 
then nothing happened. So Do Not try to change anything other than what  
is instructed. Because if you do, it will not work for you. Remember, honesty 
reaps the reward!!!


1.. After you have ordered all 5 reports, take this advertisement 
From rem-conf Sat Mar 31 09:34:37 2001 
From rem-conf-request@es.net Sat Mar 31 09:34:36 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14jP8c-0004of-00; Sat, 31 Mar 2001 09:26:10 -0800
Received: from mta4.srv.hcvlny.cv.net (mta4) [167.206.5.10] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14jP8a-0004oD-00; Sat, 31 Mar 2001 09:26:08 -0800
Received: from mail.optonline.com
 (ool-18bd8973.dyn.optonline.net [24.189.137.115]) by mta4.srv.hcvlny.cv.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
 with SMTP id <0GB200M5WNP1WH@mta4.srv.hcvlny.cv.net> for rem-conf@es.net; Sat,
 31 Mar 2001 12:13:07 -0500 (EST)
Date: Sat, 31 Mar 2001 12:10:29 -0500 (EST)
From: financefree2001@yahoo.com
Subject: WORK AT HOME - MAKE MONEY!
To: Friend@public.com
Content-transfer-encoding: 7BIT
Message-Id: 
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hello-
I am an e-bay seller making $75,000+ per year, but I want to show 
you what I took a skeptical chance on, which I have come to realize has 
made our family at least an ADDITIONAL $252,000 THIS YEAR to date! This is a 
project and business that takes dedication, however it has ultilized only a 
fraction of the time that my regular selling does, without the costly fees that 
Ebay charges. There are countless different concepts of multi-level marketing, 
but sound marketing strategies are the key to secure financial success. 
In the summer of 1999 Donald  Trump (A Multi-Millionaire touted by Forbes 
Magazine as one of the wealthiest men in the country) made an appearance 
on the David Letterman show. Dave asked him what he would do if  he lost 
everything and had to start over from scratch. Without hesitating, Trump said 
he would find a good network marketing company and get to work.  The 
audience started to hoot and boo him. He looked out at the audience and  
dead-panned his response "That's why I'm sitting up here and you are all 
sitting out there!"

In this program I send out emails just like this one, as many as I can, and 
people send me cash in the mail for marketing information that I email back 
to them upon receipt of funds. Being a service, it is all completely legal, 
and I get to make that walk to the mailbox every day knowing that it is full 
of $5 bills for me!!

Do the math... If you send out 100,000 emails (which you can do for free, 
the reports will show you how) and only 1 in 1000 people participates, you 
just made $500...and that was only on the first level!!! At the fifth level, you 
have a realistic chance to be at over $500,000! And that is ONLY ONE person 
participating out of 1000 at each level!
 
 
Report #2 will even show you where you can get One MILLION e-mail
addresses and all of the software you will need to send emails to them, 
and HOW!!


Realize FAST how much money there is to be made, and how EASY it 
is to do over and over... Then act. Make this the one email like this you 
decide to act on.

Do you HONESTLY think you wont see your meager, one-time $25 
returned to you a hundredfold AT LEAST?? PLUS, look at the value of the 
informational reports you are getting for your money, and understand that you 
will be able to sell them over and over forever, even AFTER you have used 
them for your own monetary gain!!!

And then you can run the whole program over and over for free!! If you have 
been looking for a little fun in your life, wait till you try THIS fun...the kind that 
puts cash in your mailbox!!

Good Luck!!!

Matt Farruggio

              
==================================================


DEAR FRIENDS AND FUTURE MILLIONAIRES:



AS SEEN ON NATIONAL TV :  (Reportedly on 48 Hours, in a 1999 
feature report.)


''Making over half million dollars every 4 to 5 months from your 
home for an investment of only $25 U.S. Dollars expense one time''


THANKS TO THE COMPUTER AGE AND THE INTERNET !

                 
==================================================



BECOMING A MILLIONAIRE WITHIN A YEAR!!!


Before you say ''Bull'', please read the following. This is the 
letter you have been hearing about on the news lately. Due to the 
popularity of this letter on the Internet, a national weekly news program, 
reportedly "48 hours", recently devoted an entire show to the investigation 
of this program described below, to see if it really can make people money.  
The show also investigated whether or not the program was legal.

Their findings proved once and for all that there are ''absolutely NO Laws 
prohibiting the participation in the program and if people can -follow the 
simple instructions, they are bound to make some mega bucks with only $25 
out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY 
& RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING 
BETTER THAN EVER. 


Here is what Pam Hedland, from Fort Lee, New Jersey had to say: 
'' Thanks to this profitable opportunity. I was approached many times 
before but each time I passed on it. I am so glad I finally  joined just to 
see what one could expect in return for the minimal effort and money 
required. To my astonishment, I received total $ 610,470.00 in 21 weeks, 
with money still coming in''. 

Pam Hedland, Fort Lee, New Jersey.


===============================================================


Here is another testimonial: 

'' This program has been around for a long time but I never believed 
in it. But one day when I received this again in the mail I decided to 
gamble my $25 on it. I followed the simple instructions and voila' ... 
3 weeks later the money started to come in. First month I only made 
$240.00  but the next 2 months after that I made a total of$290,000.00. 
So far, in the past 8 months by re-entering the program, I have made over 
$710,000.00 and I am playing it again. The key to success in this program 
is to follow the simple steps and NOT change anything.'' 

More testimonials later but first.


=======PRINT THIS NOW FOR YOUR FUTURE REFERENCE ==========



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$


If you would like to make at least $500,000 every 4 to 5 months easily 
and comfortably, please read the following. THEN READ IT AGAIN 
and AGAIN !!!


$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$


 FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL 
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS:



======== Order all 5 reports shown on the list below.===========


For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT 
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name 
appears 
ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON 
YOUR 
ENVELOPE TOP LEFT CORNER in case of any mail problems.


=== When you place your order, make sure you order each of the 5 
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5=$25.00.


 === Within a few days you will receive, vie e-mail, each of the 
5 reports from these 5 different individuals. Save them on your 
computer so they will be accessible for you to send to the 1,000's 
of people who will order them from you. Also make a floppy of these 
reports and keep it on your desk in case something happens to your computer.



=== IMPORTANT __ DO NOT alter the names of the people who are 
listed next to each report, or their sequence on the list, in any way 
other than what is instructed below in step '' 1 through 6 '' or you will lose out 
on majority of your profits.


Once you understand the way this works, you will also see how it 
does not work if you change it. Remember, this method has been tested, 
and if you alter, it will NOT work !!! People have tried to put their 
friends/relatives names on all five thinking they could get all the money. 
But it does not work this way. Believe us, we all have tried to be greedy and 
then nothing happened. So Do Not try to change anything other than what  
is instructed. Because if you do, it will not work for you. Remember, honesty 
reaps the reward!!!


1.. After you have ordered all 5 reports, take this advertisement 
and REMOVE the name & address of the person in REPORT # 5. This person 
has made it through the cycle and is no doubt counting their fortune.

2.. Move the name & address in REPORT # 4 down TO REPORT # 5.


3.. Move the name & address in REPORT # 3 down TO REPORT # 4.


4.. Move the name & address in REPORT # 2 down TO REPORT # 3.


5.. Move the name & address in REPORT # 1 down TO REPORT # 2


6.. Insert YOUR name & address in the REPORT # 1 Position. PLEASE 
MAKE SURE you copy every name & address ACCURATELY!

 
===============================================================


*** Take this entire letter, with the modified list of names, and 
save it on your computer. DO NOT MAKE ANY OTHER CHANGES.


Save this on a disk as well just in case if you lose any data. To 
assist you with marketing your business on the internet, the 5 reports 
you purchase will provide you with invaluable marketing information which 
includes how to send bulk e-mails legally, where to find thousands of 
free classified ads and much more. There are 2 Primary methods to get this 
venture going:


METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
            
===============================================================
Let's say that you decide to start small, just to see how it goes, and we 
will assume You and those involved send out only 5,000 e-mails 
each. Let's also assume that the mailing receive only a 0.2% response 
(the response could be much better but lets just say it is only 0.2%. Also 
many people will send out hundreds of thousands e-mails instead of only 5,000 
each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1. 
Those 10 people responded by sending out 5,000 e-mail each for a total 
of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. 
That's=100 people responded and ordered Report # 2.

Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. 
The 0.2% response to that is 1000 orders for Report # 3.

Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails 
sent out. The 0.2% response to that is 10,000 orders for Report # 4.

Those 10,000 people send out 5,000 e-mails each for a total of 
50,000,000 (50  million) e-mails.  The 0.2% response to that is 100,000 
orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 
(half million).

Your total income in this example is: 1... $50 + 2... $500 + 3...
$5,000 + 4... $50,000 + 5... $500,000 .... Grand Total= $555,550.00



NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST 
POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL 
STILL MAKE A LOT OF MONEY !
           
===============================================================


REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT 
OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if 
everyone or half or even one 4th of those people mailed 100,000 e-mails 
each or more? There are over 150 million people on the Internet worldwide and 
counting. Believe me, many people will do just that, and more!



METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
=============================================================


Advertising on the net is very very inexpensive and there are hundreds 
of FREE places to advertise. Placing a lot of free ads on the Internet will 
easily get a larger response. We strongly suggest you start with Method # 1 
and add METHOD # 2 as you go along. For every $5 you receive, all 
you must do is e-mail them the Report they ordered. That's it. Always 
provide same day service on all orders.

This will guarantee that the e-mail they send out, with your name 
and address on it, will be prompt because they can not advertise 
until they receive the report.



 ===================== AVAILABLE REPORTS====================


ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send 
$5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure 
the cash is concealed by wrapping it in at least 2 sheets of paper. On one of 
those sheets of paper, Write the NUMBER & the NAME of the Report you 
are ordering, YOUR E-MAIL ADDRESS and your name and postal address.


PLACE YOUR ORDER FOR THESE REPORTS NOW :



===============================================================
______________________________________________________________



REPORT # 1 : ''The Insider's Guide to Advertising for Free on the Net''


Order Report # 1, and add a notice that says " Please send me the 
50,000 e-mail addresses as per your special offer " from:



Robert Giampia
Box # 404
648 Central Park Ave.
Scarsdale, NY. 10583
 ______________________________________________________________



REPORT # 2 : ''The Insider's Guide to Sending Bulk e-mail on the 
Net''



Order Report # 2 from :



Brad Swanson
4920 204th St W
Farmington, MN 55024
 ________________________________________________________________



REPORT # 3 : ''The Secret to Multilevel marketing on the net''



Order Report # 3 from:



Matt Farruggio
6890 East Sunrise Dr
Suite #120
PMB 351
Tucson, AZ  85750
 ________________________________________________________________



REPORT # 4 : ''How to become a millionaire utilizing MLM & the 
Net''



Order Report # 4 from:



Mike Nichols
PO Box 270061
Flower Mound, TX  75027
 ________________________________________________________________



REPORT # 5 : ''HOW TO SEND 1 MILLION E-MAILS FOR FREE''



Order Report # 5 from:



Jack Zampell
4511 Rockford Ln
Chattanooga, TN  37411


______________________________________________________________



     $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$



Follow these guidelines to guarantee your success:



=== If you do not receive at least 10 orders for Report #1 within 
2 weeks, continue sending e-mails until you do.


=== After you have received 10 orders, 2 to 3 weeks after that 
you should receive 100 orders or more for REPORT # 2. If you did not, 
continue advertising or sending e-mails until you do.



=== Once you have received 100 or more orders for Report # 2, YOU 
CAN RELAX, because the system is already working for you, and the cash 
will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your 
name is moved down on the list, you are placed in front of a different report.


 You can KEEP TRACK of your PROGRESS by watching which report people 
are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND 
ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this business !!!


         
===============================================================


FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:


You have just received information that can give you financial freedom for the 
rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can
make more money in the next few weeks and months than you have ever imagined. 
Follow the program EXACTLY AS INSTRUCTED. Do Not change it in anyway. 
It works exceedingly well as it is now. Remember to e-mail a copy of this exciting 
report after you have put your name and address in Report #1 and moved others 
to #2 ......# 5 as instructed above. One of the people you send this to may send 
out 100,000 or more e-mails and your name will be on every one of them. Remember 
though, the more you send out the more potential customers you will reach. So 
my friend, I have given you the ideas, information, materials and opportunity to become 
financially independent. IT IS UP TO YOU NOW!


   =================== MORE TESTIMONIALS======================


'' My name is Mitchell. My wife, Jody and I live in Chicago. I am 
an accountant  with a major U.S. Corporation and I make pretty good 
money. When I received this  program I grumbled to Jody about receiving 
''junk mail''. I made fun of the whole  thing, spouting my knowledge of 
the population and percentages involved. I ''knew''  it wouldn't work. Jody 
totally ignored my supposed intelligence and few days later she jumped in with 
both feet.  I made  merciless fun of her, and was ready to lay the old ''I 
told yoand REMOVE the name & address of the person in REPORT # 5. This person 
has made it through the cycle and is no doubt counting their fortune.

2.. Move the name & address in REPORT # 4 down TO REPORT # 5.


3.. Move the name & address in REPORT # 3 down TO REPORT # 4.


4.. Move the name & address in REPORT # 2 down TO REPORT # 3.


5.. Move the name & address in REPORT # 1 down TO REPORT # 2


6.. Insert YOUR name & address in the REPORT # 1 Position. PLEASE 
MAKE SURE you copy every name & address ACCURATELY!

 
===============================================================


*** Take this entire letter, with the modified list of names, and 
save it on your computer. DO NOT MAKE ANY OTHER CHANGES.


Save this on a disk as well just in case if you lose any data. To 
assist you with marketing your business on the internet, the 5 reports 
you purchase will provide you with invaluable marketing information which 
includes how to send bulk e-mails legally, where to find thousands of 
free classified ads and much more. There are 2 Primary methods to get this 
venture going:


METHOD # 1: BY SENDING BULK E-MAIL LEGALLY
            
===============================================================
Let's say that you decide to start small, just to see how it goes, and we 
will assume You and those involved send out only 5,000 e-mails 
each. Let's also assume that the mailing receive only a 0.2% response 
(the response could be much better but lets just say it is only 0.2%. Also 
many people will send out hundreds of thousands e-mails instead of only 5,000 
each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1. 
Those 10 people responded by sending out 5,000 e-mail each for a total 
of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. 
That's=100 people responded and ordered Report # 2.

Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. 
The 0.2% response to that is 1000 orders for Report # 3.

Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails 
sent out. The 0.2% response to that is 10,000 orders for Report # 4.

Those 10,000 people send out 5,000 e-mails each for a total of 
50,000,000 (50  million) e-mails.  The 0.2% response to that is 100,000 
orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 
(half million).

Your total income in this example is: 1... $50 + 2... $500 + 3...
$5,000 + 4... $50,000 + 5... $500,000 .... Grand Total= $555,550.00



NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST 
POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL 
STILL MAKE A LOT OF MONEY !
           
===============================================================


REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT 
OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if 
everyone or half or even one 4th of those people mailed 100,000 e-mails 
each or more? There are over 150 million people on the Internet worldwide and 
counting. Believe me, many people will do just that, and more!



METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
=============================================================


Advertising on the net is very very inexpensive and there are hundreds 
of FREE places to advertise. Placing a lot of free ads on the Internet will 
easily get a larger response. We strongly suggest you start with Method # 1 
and add METHOD # 2 as you go along. For every $5 you receive, all 
you must do is e-mail them the Report they ordered. That's it. Always 
provide same day service on all orders.

This will guarantee that the e-mail they send out, with your name 
and address on it, will be prompt because they can not advertise 
until they receive the report.



 ===================== AVAILABLE REPORTS====================


ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send 
$5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure 
the cash is concealed by wrapping it in at least 2 sheets of paper. On one of 
those sheets of paper, Write the NUMBER & the NAME of the Report you 
are ordering, YOUR E-MAIL ADDRESS and your name and postal address.


PLACE YOUR ORDER FOR THESE REPORTS NOW :



===============================================================
______________________________________________________________



REPORT # 1 : ''The Insider's Guide to Advertising for Free on the Net''


Order Report # 1, and add a notice that says " Please send me the 
50,000 e-mail addresses as per your special offer " from:



Robert Giampia
Box # 404
648 Central Park Ave.
Scarsdale, NY. 10583
 ______________________________________________________________



REPORT # 2 : ''The Insider's Guide to Sending Bulk e-mail on the 
Net''



Order Report # 2 from :



Brad Swanson
4920 204th St W
Farmington, MN 55024
 ________________________________________________________________



REPORT # 3 : ''The Secret to Multilevel marketing on the net''



Order Report # 3 from:



Matt Farruggio
6890 East Sunrise Dr
Suite #120
PMB 351
Tucson, AZ  85750
 ________________________________________________________________



REPORT # 4 : ''How to become a millionaire utilizing MLM & the 
Net''



Order Report # 4 from:



Mike Nichols
PO Box 270061
Flower Mound, TX  75027
 ________________________________________________________________



REPORT # 5 : ''HOW TO SEND 1 MILLION E-MAILS FOR FREE''



Order Report # 5 from:



Jack Zampell
4511 Rockford Ln
Chattanooga, TN  37411


______________________________________________________________



     $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$



Follow these guidelines to guarantee your success:



=== If you do not receive at least 10 orders for Report #1 within 
2 weeks, continue sending e-mails until you do.


=== After you have received 10 orders, 2 to 3 weeks after that 
you should receive 100 orders or more for REPORT # 2. If you did not, 
continue advertising or sending e-mails until you do.



=== Once you have received 100 or more orders for Report # 2, YOU 
CAN RELAX, because the system is already working for you, and the cash 
will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your 
name is moved down on the list, you are placed in front of a different report.


 You can KEEP TRACK of your PROGRESS by watching which report people 
are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND 
ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. 
There is NO LIMIT to the income you can generate from this business !!!


         
===============================================================


FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM:


You have just received information that can give you financial freedom for the 
rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can
make more money in the next few weeks and months than you have ever imagined. 
Follow the program EXACTLY AS INSTRUCTED. Do Not change it in anyway. 
It works exceedingly well as it is now. Remember to e-mail a copy of this exciting 
report after you have put your name and address in Report #1 and moved others 
to #2 ......# 5 as instructed above. One of the people you send this to may send 
out 100,000 or more e-mails and your name will be on every one of them. Remember 
though, the more you send out the more potential customers you will reach. So 
my friend, I have given you the ideas, information, materials and opportunity to become 
financially independent. IT IS UP TO YOU NOW!


   =================== MORE TESTIMONIALS======================


'' My name is Mitchell. My wife, Jody and I live in Chicago. I am 
an accountant  with a major U.S. Corporation and I make pretty good 
money. When I received this  program I grumbled to Jody about receiving 
''junk mail''. I made fun of the whole  thing, spouting my knowledge of 
the population and percentages involved. I ''knew''  it wouldn't work. Jody 
totally ignored my supposed intelligence and few days later she jumped in with 
both feet.  I made  merciless fun of her, and was ready to lay the old ''I 
told you so'' on her when  the thing didn't work. Well, the laugh was on me! 
Within 3 weeks she had received 50 responses. Within the next 45 days 
she hadreceived total $ 147,200.00 ...... all cash! I was shocked. I 
have joined Jody in her ''hobby''.

Mitchell Wolf, Chicago, Illinois


=============================================================


'' Not being the gambling type, it took me several weeks to make 
up my mind to participate in this plan. But conservative that I am, I 
decided that the initial investment was so little that there was just 
no way that I wouldn't get enough orders to at least get my money back''. 
'' I was surprised when I found my medium size post office box crammed with 
orders. I made $319,210.00 in the first 12 weeks.  The nice thing about this 
deal is that it does not matter where people live.  There simply isn't a better 
investment with a faster return and so big''.


Dan Sondstrom, Alberta, Canada


===============================================================


'' I had received this program before. I deleted it, but later I wondered if I should 
have given it a try. Of course, I had no idea who to contact to get another copy,
so I had to wait until I was e-mailed again by someone else.....11 months passed 
then it luckily came again... I did not delete this one! I made more than $490,000 
on my first try and all the money came within 22 weeks''.

Susan De Suza, New York, N.Y.


===============================================================


'' It really is a great opportunity to make relatively easy money 
with little cost to you. I followed the simple instructions carefully 
and within 10 days the money started to come in. My first month I made 
$20,560.00 and by the end of third month my total cash count was $ 362,840.00. 
Life isbeautiful, thanks to the internet''.


Fred Dellaca, Westport, New Zealand


==============================================================


ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO 
FINANCIAL FREEDOM !


        
==============================================================


If you have any questions of the legality of this program, contact the Office of 
Associate Director for Marketing Practices, Federal Trade Commission, Bureau 
of Consumer Protection, Washington, D.C.


==========================THE END======================


This message is sent in compliance of the new e-mail bill: 
SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,


http://www.senate.gov/~murkowski/commercialemail/S771index.html


This is a one time only unsolicited commercial email. Further 
transmissions to you by the sender of this email may be stopped at no 
cost to you by sending a reply to this email address with the word "remove" 
in the subject line.





u so'' on her when  the thing didn't work. Well, the laugh was on me! 
Within 3 weeks she had received 50 responses. Within the next 45 days 
she hadreceived total $ 147,200.00 ...... all cash! I was shocked. I 
have joined Jody in her ''hobby''.

Mitchell Wolf, Chicago, Illinois


=============================================================


'' Not being the gambling type, it took me several weeks to make 
up my mind to participate in this plan. But conservative that I am, I 
decided that the initial investment was so little that there was just 
no way that I wouldn't get enough orders to at least get my money back''. 
'' I was surprised when I found my medium size post office box crammed with 
orders. I made $319,210.00 in the first 12 weeks.  The nice thing about this 
deal is that it does not matter where people live.  There simply isn't a better 
investment with a faster return and so big''.


Dan Sondstrom, Alberta, Canada


===============================================================


'' I had received this program before. I deleted it, but later I wondered if I should 
have given it a try. Of course, I had no idea who to contact to get another copy,
so I had to wait until I was e-mailed again by someone else.....11 months passed 
then it luckily came again... I did not delete this one! I made more than $490,000 
on my first try and all the money came within 22 weeks''.

Susan De Suza, New York, N.Y.


===============================================================


'' It really is a great opportunity to make relatively easy money 
with little cost to you. I followed the simple instructions carefully 
and within 10 days the money started to come in. My first month I made 
$20,560.00 and by the end of third month my total cash count was $ 362,840.00. 
Life isbeautiful, thanks to the internet''.


Fred Dellaca, Westport, New Zealand


==============================================================


ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO 
FINANCIAL FREEDOM !


        
==============================================================


If you have any questions of the legality of this program, contact the Office of 
Associate Director for Marketing Practices, Federal Trade Commission, Bureau 
of Consumer Protection, Washington, D.C.


==========================THE END======================


This message is sent in compliance of the new e-mail bill: 
SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,


http://www.senate.gov/~murkowski/commercialemail/S771index.html


This is a one time only unsolicited commercial email. Further 
transmissions to you by the sender of this email may be stopped at no 
cost to you by sending a reply to this email address with the word "remove" 
in the subject line.





From rem-conf Sat Mar 31 11:37:27 2001 
From rem-conf-request@es.net Sat Mar 31 11:37:26 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14jR8X-00072F-00; Sat, 31 Mar 2001 11:34:13 -0800
Received: from mx.serv.net [205.153.153.234] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14jR8W-000725-00; Sat, 31 Mar 2001 11:34:12 -0800
Received: from iname.com (dialup325.serv.net [207.207.70.218])
	by mx.serv.net (8.9.1/8.9.1) with ESMTP id LAA21727;
	Sat, 31 Mar 2001 11:34:06 -0800 (PST)
Message-ID: <3AC6309E.A27F5EBC@iname.com>
Date: Sat, 31 Mar 2001 11:31:42 -0800
From: Chuck Harrison 
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rem-conf@es.net
CC: Russ Housley 
Subject: Secure RTP; crypto context
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Greetings!

Please apply newbie disclaimer, I have not been working in this area
very long.

While
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt
describes particular default methods, I think there is an implicit
longing for a way to generalize the protocol. Could we piggyback on RFC
2630, Cryptographic Message Syntax, and its AES update?
http://www.ietf.org/rfc/rfc2630.txt
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-01.txt

I am visualizing a "detached content" mode, wherein the encrypted
content (a big chunk of it...as much as you encrypt under a single key
context) is separated from the "header" info. The content is packetized,
and transmitted over an RTP stream pretty much as in the srtp-00 draft.

It seems that the "classic" RTP approach would then be to send the rest
of the CMS message (i.e. the "crypto header") out-of-band. However, I
think the "new paradigm" is to consider it to be an additional media
stream. Over in MPEG they call it an IPMP stream. In this paradigm, the
crypto header info is part of the multimedia session. Because transport
is likely to be unreliable, and participants may "hop on", it will
probably be retransmitted periodically. If key change is required, this
is handled by sending a new crypto header on the IPMP stream, and
starting a corresponding new piece of "detached content" on the media
stream.

As noted by others, key change must be synchronized between the IPMP
stream and media stream. This could be done using the extended packet
sequence number defined in srtp-00. It could also be done by timestamp.
(Some of you know that I think general multistream timestamp-based sync
should be added to RTP. But don't hold your breath. ) As a
pragmatist, I think the "odd/even" approach deployed in ATSC (and DVB?)
is simple, robust, and worth standardizing. See the ATSC guide
http://www.fcc.gov/Bureaus/Engineering_Technology/Documents/atsc/a54/
section 8.5.3, esp. figure 8.15.

....
And another detail from srtp-00. It states,
   When RTP authentication is not present, robust synchronization is not
   possible. In this case, transmission errors or an active attacker may
   force the receiver to erroneously update his rollover counter and
   thus to become completely out of synch. It is not possible to protect
   against active attackers in such case [...]

I would think that, if the rollover counter is only updated when the
packet is successfully decrypted, then active attacks would be
suppressed without authentication overhead. Determining "successful
decryption" may be trivial with some highly structured payload formats
and impossible with others. Thus this technique is a definite MAY.

....
And *another* piece of spew...
It seems there is considerable concern about D.O.S. attacks. Should we
think about a way to filter spurious packets within the network, before
they reach the target device? Maybe the filter function could be
provided by an "RTP translator" entity? I am thinking particularly you
would want to remove the garbage before it hits a wireless link.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  co-chair, SMPTE DC28.4 Study Group on Conditional Access
    for Digital Cinema
  +1 360 863 8340 (voice) GMT-0800



From rem-conf Sat Mar 31 12:51:04 2001 
From rem-conf-request@es.net Sat Mar 31 12:51:03 2001
Received: from list by mail1.es.net with local (Exim 1.81 #2)
	id 14jSH4-0000QY-00; Sat, 31 Mar 2001 12:47:06 -0800
Received: from prognet.com [205.219.198.1] 
	by mail1.es.net with esmtp (Exim 1.81 #2)
	id 14jSH3-0000QO-00; Sat, 31 Mar 2001 12:47:05 -0800
Received: from beans.real.com (c1041793-a.sttls1.wa.home.com [24.16.227.26])
	by prognet.com (8.9.2/8.9.0) with ESMTP id MAA21587;
	Sat, 31 Mar 2001 12:46:55 -0800 (PST)
Message-Id: <5.0.0.25.0.20010331120339.079a0650@goobox.prognet.com>
X-Sender: robla@goobox.prognet.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sat, 31 Mar 2001 12:35:53 -0800
To: Dave Singer 
From: Rob Lanphier 
Subject: RE: MP4 Player Available for Download
Cc: olivier.avaro@francetelecom.com, "'Hari Kalva'" ,
        rem-conf@es.net, discuss@apps.ietf.org
In-Reply-To: 
References: <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com>
 
 <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailing-List:  
X-Loop: rem-conf@es.net
Precedence: list

Hi Dave,

Replies inline....

At 06:28 PM 3/30/01 -0800, Dave Singer wrote:
>you may be right about the licensing of MPEG-4 in general;  but I believe 
>I have told this group already the best of my knowledge on the licensing 
>of the file format, so I am a little disappointed that you should end up 
>on that particular subject.

My parting shot wasn't intended for strictly the file format as you 
probably think of it, but in terms of a general interoperable blob of a/v 
data that includes audio, video, and the structure of the file format.  If 
.foo is an interoperable multimedia file format, and there are two .foo 
players, they should have all of the necessary components to interoperate.

For those of you not familiar with the distinction, in the multimedia world 
there's a pretty distinct separation between the codec used (such as H.261 
video, or G.711 audio), and the container its put in (such as Quicktime's 
.mov format, Microsoft's .asf, .avi, and .wav formats, RealNetworks .rm 
format, or the .mp4 format in the MPEG-4 v2 spec).  A minor additional 
complexity is that the codecs have to be inserted into the container file 
using the same conventions (same codec identifier, interoperable codec 
parameters, etc).  What Dave is referring to is the container itself.

Now Dave, since you are practically begging me to respond to your earlier 
mail....  :)

For the benefit of those not on the full thread, I've included the full 
email from Dave at the bottom of this message.  Here's the snippit I want 
to respond to, though:

At 10:00 AM 3/14/01 -0800, Dave Singer wrote:
>I hate to carry on an off-topic thread, but the MPEG-4 file format is not 
>heavily encumbered.  To my knowledge, we (Apple) are the only IPR owners 
>in the file format per se, and the license needed would be the same as for 
>the QT file format (i.e. it's the same IPR), for which we have plenty of 
>examples of licensees (including Real Networks).

Are you really willing to stand up and disclose the terms of the 
Apple/RealNetworks agreement?  I think it's entirely inappropriate to cite 
the Apple/RealNetworks agreement as an example of an MPEG-4 file format 
licensing success story, and entirely inappropriate to discuss the terms of 
any deal that go beyond the joint press release:

http://www.realnetworks.com/company/pressroom/pr/2000/apple.html

Besides that, I don't think it's at all reasonable that if RealNetworks and 
some other company/project want to interoperate, that that other 
company/project should have to go to Apple to get permission.  Do you?

Rob


>X-Sender: singer@mail.apple.com (Unverified)
>Date: Wed, 14 Mar 2001 10:00:03 -0800
>To: Rob Lanphier 
>From: Dave Singer 
>Subject: Re: File formats (RE: MP4 Player Available for Download)
>Cc: "'rem-conf@es.net'" 
>
>At 9:35 AM -0800 3/14/01, Rob Lanphier wrote:
>>At 11:54 AM 3/13/01 -0800, Bill Nowicki wrote:
>>>We just tried the obvious experiment.
>>>
>>>The ".mp4" files on the "Flavor" site do not play with the
>>>Philips player, and the Philips ".mp4" files do not play with
>>>the Flavor player. Sounds like a litle inter-operability
>>>testing might have been in order before calling them the same
>>>name!
>>>
>>>(and of course file format standards are outside the charter
>>>of IETF, but are still useful)
>>
>>Not that I'm disagreeing with you here, but an honest question for 
>>you:  whose charter includes specifying file formats?  Clearly, ISO/MPEG 
>>have taken it on, but they've also created a situation where I think 
>>genuine interoperability is out of the question for anyone who either 
>>doesn't have a patent licensing agreement from 30 different companies, or 
>>who chooses to ignore the issue.
>>
>>Is there a standards group out there who does file formats who would 
>>actually work toward an unencumbered format?
>>
>>Rob
>
>I hate to carry on an off-topic thread, but the MPEG-4 file format is not 
>heavily encumbered.  To my knowledge, we (Apple) are the only IPR owners 
>in the file format per se, and the license needed would be the same as for 
>the QT file format (i.e. it's the same IPR), for which we have plenty of 
>examples of licensees (including Real Networks).
>
>ISMA will be testing interop very carefully, as Philippe says.  And there 
>have been interop tests done under the conformance group at MPEG-4.
>
>Now, the encumbrance of MPEG-4 in general is a different matter, as anyone 
>who follows m4if will attest....
>--
>David Singer
>Apple Computer/QuickTime