From rem-conf-request@es.net Fri Oct 1 02:55:51 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10059 for ; Fri, 1 Oct 1999 02:55:51 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11WwDJ-0004uR-00; Thu, 30 Sep 1999 23:30:41 -0700 Received: from mailweb.pue.udlap.mx [140.148.155.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 11WwDH-0004t7-00; Thu, 30 Sep 1999 23:30:39 -0700 Received: (from ad102336@localhost) by mailweb.pue.udlap.mx (8.9.0/8.9.0) id BAA18192; Fri, 1 Oct 1999 01:23:17 -0600 (CST) Date: Fri, 1 Oct 1999 01:23:17 -0600 (CST) From: VELA GONZALEZ WENDY K X-Sender: ad102336@mailweb To: trouble@es.net, info@es.net, rem-conf@es.net, request-videophone@es.net Subject: Could you do me a favor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi! I dont speak english very well, so I would like that you help me to anwser a few questions, I am taking a curse o Marketing by internet and I have to make a homework, I have to aswer these questions about (Audio and video in Internet) 1.-History 2.-Definition 3.-How does them work and 4.-The problem of (ANCHO DE BANDA...spanish) I will be very happy if you could answering my questions...Thak you From rem-conf-request@es.net Fri Oct 1 03:00:06 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10083 for ; Fri, 1 Oct 1999 03:00:06 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11WwNP-0005CQ-00; Thu, 30 Sep 1999 23:41:07 -0700 Received: from mailweb.pue.udlap.mx [140.148.155.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 11WwNN-0005Br-00; Thu, 30 Sep 1999 23:41:05 -0700 Received: (from ad102336@localhost) by mailweb.pue.udlap.mx (8.9.0/8.9.0) id BAA18607; Fri, 1 Oct 1999 01:33:58 -0600 (CST) Date: Fri, 1 Oct 1999 01:33:58 -0600 (CST) From: VELA GONZALEZ WENDY K To: VELA GONZALEZ WENDY K cc: trouble@es.net, info@es.net, rem-conf@es.net, videophone@es.net Subject: Re: Could you do me a favor In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 1 Oct 1999, VELA GONZALEZ WENDY K wrote: > > > Hi! I dont speak english very well, so I would like that you > help me to anwser a few questions, I am taking a curse o Marketing > by internet and I have to make a homework, I have to aswer these > questions about (Audio and video in Internet) > 1.-History > 2.-Definition > 3.-How does them work and > 4.-The problem of (ANCHO DE BANDA...spanish) > > > I will be very happy if you could answering my questions...Thak you > > From rem-conf-request@es.net Fri Oct 1 03:05:25 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10213 for ; Fri, 1 Oct 1999 03:05:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11WwQb-0005iR-00; Thu, 30 Sep 1999 23:44:25 -0700 Received: from mailweb.pue.udlap.mx [140.148.155.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 11WwQZ-0005i0-00; Thu, 30 Sep 1999 23:44:23 -0700 Received: (from ad102336@localhost) by mailweb.pue.udlap.mx (8.9.0/8.9.0) id BAA18777; Fri, 1 Oct 1999 01:37:16 -0600 (CST) Date: Fri, 1 Oct 1999 01:37:15 -0600 (CST) From: VELA GONZALEZ WENDY K To: trouble@es.net, info@es.net, rem-conf@es.net, videophone@es.net Subject: Re: Could you do me a favor In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 1 Oct 1999, VELA GONZALEZ WENDY K wrote: > > > On Fri, 1 Oct 1999, VELA GONZALEZ WENDY K wrote: > > > > > > > Hi! I dont speak english very well, so I would like that you > > help me to anwser a few questions, I am taking a curse o Marketing > > by internet and I have to make a homework, I have to aswer these > > questions about (Audio and video in Internet) > > 1.-History > > 2.-Definition > > 3.-How does them work and > > 4.-The problem of (ANCHO DE BANDA...spanish) > > > > > > I will be very happy if you could answering my questions...Thak you > > > > > From rem-conf-request@es.net Fri Oct 1 12:52:24 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18720 for ; Fri, 1 Oct 1999 12:52:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11X5LW-0004Uw-00; Fri, 1 Oct 1999 09:15:46 -0700 Received: from mail.telefonica.es [194.179.42.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 11X5LV-0004Ts-00; Fri, 1 Oct 1999 09:15:45 -0700 Received: from t143754 ([192.168.143.137]) by mail.telefonica.es (Netscape Messaging Server 3.6) with SMTP id AAA9AE for ; Fri, 1 Oct 1999 18:13:45 +0200 Message-ID: <014a01bf0c28$528d99a0$8a10740a@telefonica> From: "Vicente Cid" To: References: <558.113143.511285@ns.bigbear.net> Subject: remove vicente.cid@telefonica.es Date: Fri, 1 Oct 1999 18:16:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit remove vicente.cid@telefonica.es _________________________________________________________________ Vicente Cid Cid Telefónica de España Gerente de Canales de Distribución Comercial Territorio II (Galicia y Asturias) C/Zamora 51 Bajo 36203 VIGO Tel 986812730 Fax 986422607 vicente.cid@telefonica.es ----- Mensaje original ----- De: Para: Enviado: sábado, 02 de octubre de 1999 3:59 Asunto: Homeworkers Needed! > Dear Future Associate, > > You Can Work At Home & Set Your Own Hours. Start earning Big > Money in a short time > > NO Newspaper Advertising! > > Your job will be to stuff and mail envelopes for our company. You > will receive $.25 for each and every envelope you stuff and mail > out. > > Just follow our simple instructions and you will be making money > as easy as > 1. 2. 3 > > For example stuff and mail 200 envelopes and you will receive > $50.00. Stuff and mail 1000 and you will receive $250.00. Stuff > and mail 2000 and you will receive $500.00 and more > > Never before has there been an easier way to make money from > home! > > Our Company's Home Mailing Program is designed for people with > little or no experience and provides simple, step by step > instructions. > > There is no prior experience or special skills necessary on your > part, Just stuffing envelopes. > > We need the help of honest and reliable home workers like you. > Because we are overloaded with work and have more than our staff > can handle. We have now expanded our mailing program and are > expecting to reach millions more with our offers throughout the > US and Canada. > > Our system of stuffing and mailing envelopes is very simple and > easy to do! > You will not be required to buy envelopes or postage stamps. > > We will gladly furnish all circulars at no cost to you. We assure > you that as a participant in our program you will never have to > mail anything objective or offensive. > > There are no quotas to meet, and there no contracts to sign. You > can work as much, or as little as you want. Payment for each > envelope you send out is Guaranteed! > > Here is what you will receive when you get your first Package. > Inside you will find 100 envelopes, 100 labels and 100 sales > letters ready to stuff and mail > > As soon as you are done with stuffing and mailing these first > letters, your payment will arrive shortly, thereafter. All you > have to do is to order more free supplies and stuff and mail more > envelopes to make more money. > > Our sales literature which you will be stuffing and mailing will > contain > information outlining our highly informative manuals that we are > advertising nationwide. As a free gift you will receive a > special manual valued at $24.95, absolutely free, just for > joining our Home Mailers Program. > > Plus you will get your own special code number, so that we will > know how much you are to get paid. And to make re-ordering of > more envelopes, that our company supplies very simple for you. > > We are giving you this free bonus because we want you to be > confident in our company and to ensure that we will be doing > business with you for a long time. > > Benefits Of This Job: > > 1. You do not have to quit your present job, to earn more money > at home > 2. You can make between $2,500 to $4,500 a month depending on the > amount of time you are willing to spend stuffing and mailing > envelopes > 3. This is a great opportunity for the students, mothers, > disabled persons or those who are home bodies. > > To secure your position and to show us that you are serious about > earning extra income at home we require a one-time registration > fee of $35.00. > This fee covers the cost of your initial start up package, which > includes 100 envelopes, 100 labels and 100 sales letters and a > manual, your registration fee will be refunded back to you > shortly thereafter. > > Money Back Guarantee! > > We guarantee that as soon as you stuff and mail your first 300 > envelopes You will be paid $75.00 and your registration fee will > be refunded. > > Many of you wonder why it is necessary to pay a deposit to get a > job. It is because we are looking for people that seriously want > to work from home. > > * If 3.000 people told us they wanted to start working from home > and we sent out 3.000 packages free to every one. And then half > of the people decided not to work, this would be a potential loss > of more than $60,000 in supply's and shipping that we have sent > out to people that don't want to work > > We have instituted this policy to make sure that you really want > to work and at least finish your first package. > > To Get Started Today Please Enclose Your Registration Fee of $35 > Check,Cash Or Money Order and fill out the application below and > mail to: > > MOHW Co > PMB > 11054 Ventura Blvd #126 > Studio City, CA 91604 > > Name_____________________________________________________ > > Address___________________________________________________ > > City____________________________________ State______________ > > Zip Code________________ > > Telephone Number(s)_________________________________________ > > E-mail Address______________________________________________ > > > > For all orders, please allow seven (7) days for delivery and up > to 10 days. Cash and Money Orders will result in faster shipping of your > package. > > > > > > > > > > > > > > > From rem-conf-request@es.net Fri Oct 1 13:55:28 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19866 for ; Fri, 1 Oct 1999 13:55:27 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11X6Pq-0005vW-00; Fri, 1 Oct 1999 10:24:18 -0700 Received: from mail.telefonica.es [194.179.42.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 11X6Po-0005v6-00; Fri, 1 Oct 1999 10:24:16 -0700 Received: from t143754 ([192.168.143.137]) by mail.telefonica.es (Netscape Messaging Server 3.6) with SMTP id AAA4536; Fri, 1 Oct 1999 19:22:31 +0200 Message-ID: <017401bf0c31$e9e9aec0$8a10740a@telefonica> From: "Vicente Cid" To: , References: <199910010151.DAA06569@micro.iternet.it> Subject: remove vicente.cid@telefonica.es Date: Fri, 1 Oct 1999 19:25:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit remove vicente.cid@telefonica.es _________________________________________________________________ Vicente Cid Cid Telefónica de España Gerente de Canales de Distribución Comercial Territorio II (Galicia y Asturias) C/Zamora 51 Bajo 36203 VIGO Tel 986812730 Fax 986422607 vicente.cid@telefonica.es ----- Mensaje original ----- De: Para: Enviado: lunes, 15 de marzo de 1999 1:01 Asunto: Free Vacation when you Request the Info > GET YOUR FREE VACATION VOUCHER WHEN > VISITING OUR WEB SITE! > > ONLY 14 ASSOCIATES NEEDED! > We will train hard working and ethical candidates. > > HUGE COMPENSATION PLAN AVAILABLE! > This is your chance to get in on the ground floor of the > Multi-Billion-Dollar Home Based Business Revolution. > > Receive a COMPLIMENTARY Weekend Get Away when > visiting our site. > > > http://3626046468/ut/travelfree/index2.html > > Click Here > FOR FREE INFORMATION > > From rem-conf-request@es.net Fri Oct 1 23:24:01 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28409 for ; Fri, 1 Oct 1999 23:24:01 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11XFNm-0003ak-00; Fri, 1 Oct 1999 19:58:46 -0700 Received: from ne.mediaone.net (chmls05.mediaone.net) [24.128.1.70] by mail1.es.net with esmtp (Exim 1.81 #2) id 11XFNl-0003aa-00; Fri, 1 Oct 1999 19:58:45 -0700 Received: from maldrich (maldrich.ne.mediaone.net [24.128.111.72]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id WAA28577 for ; Fri, 1 Oct 1999 22:58:42 -0400 (EDT) Message-Id: <4.2.0.58.19991001225923.00a0dee0@pop.ne.mediaone.net> X-Sender: maldrich@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 01 Oct 1999 23:01:04 -0400 To: rem-conf@es.net From: Michael Aldrich Subject: Send more info In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_47387804==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_47387804==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:13 PM 9/17/99 -0700, you wrote: >Take a look at this...... > >Greetings.... > >THE NEWS THAT HAS BEEN RUMORED FOR WEEKS > >IS HERE > >NEWS THAT WILL TAKE THE WORLD BY STORM! > >REGISTER NOW TO SECURE BEST POSITION DURING PRE-LAUNCH > >Just imagine. Thousands upon Thousands of Premium Products > >and Services all categorized for your easy use > >THE LARGEST DIRECTORY OF FREE OFFERS IN THE WORLD! > >To Start With . Take the tour and you can have your very > >own > >Digital Satellite System Certificate, valued at > >$149 FREE > >We know that no one has to be a computer genius or know everything about > >the Internet to profit from it .Combine FREE with the dynamics of > >cyber space and you have the World's easiest and most lucrative business > >Work will simply be Sharing FREE goods and services with others > >Take this for starters .. All subscribers will have FREE > >INTERNET > >and E-MAIL ACCESS That is just the beginning! > >But .An immediate saving on your current overheads. > >YOU WILL ALSO HAVE .. FREE > >* Software allowing long distance calls at zero dollars per minute. > >* $100 airline check > >* Encarta Encyclopedia 99 > >* Personal Computer > >* Las Vegas vacation > >* Thousands upon Thousands of Free Products and Services > >Just click your reply button now and type the words "send more info " in >your subject box and I will send you the website where you can get the >rest of the information and join straightaway. > >=========================================================================== > >><<<<<<<<<<<<<<<<<<<<<<<< ><<<<<<<<<<<<<<<<<<<<<<<<< ><<<<<<<< > >>PLEASE NOTE: You have received this email because your email address is > >>part of our "in house" list. You or someone you know has sent your > >>email address to us in the past. Our team promotes professional and > >>responsible use of direct email marketing. If this message is in > >>error we apologize. 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. > >><<<<<<<<<<<<<<<<<<<<<<<< ><<<<<<<<<<<<<<<<<<<<<<<<< ><<<<<<<< > >======================================= ******************************************************************************* Michael Aldrich White Pine Software Sr. Support Technician 542 Amherst St. Phone: (603) 886-9050 Nashua NH. 03063 Fax: (603) 886-9051 http://www.wpine.com Please visit our website for all the latest upgrade's and enhancement's to White Pine Software's Awesome Product's. **************************************************************************** *** --=====================_47387804==_.ALT Content-Type: text/html; charset="us-ascii"

At 08:13 PM 9/17/99 -0700, you wrote:

Take a look at this......

Greetings....

THE NEWS THAT HAS BEEN RUMORED FOR WEEKS

IS HERE

NEWS THAT WILL TAKE THE WORLD BY STORM!

REGISTER NOW TO SECURE BEST POSITION DURING PRE-LAUNCH

Just imagine. Thousands upon Thousands of Premium Products

and Services all categorized for your easy use

THE LARGEST DIRECTORY OF FREE OFFERS IN THE WORLD!

To Start With . Take the tour and you can have your very

own

Digital Satellite System Certificate, valued at

$149 FREE

We know that no one has to be a computer genius or know everything about

the Internet to profit from it .Combine FREE with the dynamics of

cyber space and you have the World's easiest and most lucrative business

Work will simply be Sharing FREE goods and services with others

Take this for starters .. All subscribers will have FREE

INTERNET

and E-MAIL ACCESS That is just the beginning!

But .An immediate saving on your current overheads.

YOU WILL ALSO HAVE .. FREE

* Software allowing long distance calls at zero dollars per minute.

* $100 airline check

* Encarta Encyclopedia 99

* Personal Computer

* Las Vegas vacation

* Thousands upon Thousands of Free Products and Services

Just click your reply button now and type the words "send more info " in your subject box and I will send you the website where you can get the rest of the information and join straightaway.

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

&gt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt

&gtPLEASE NOTE: You have received this email because your email address is

&gtpart of our "in house" list. You or someone you know has sent your

&gtemail address to us in the past. Our team promotes professional and

&gtresponsible use of direct email marketing. If this message is in

&gterror we apologize. Further transmissions to you by the sender of this

&gtemail may be stopped at no cost to you by sending a reply to this

&gtemail address with the word "remove" in the subject line.

&gt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt&lt

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

*******************************************************************************
Michael Aldrich                                      White Pine Software
Sr. Support Technician                              542 Amherst St.
Phone: (603) 886-9050                              Nashua NH. 03063
Fax: (603) 886-9051                                  http://www.wpine.com

Please visit our website for all the latest upgrade's and
enhancement's to White Pine Software's Awesome Product's.
******************************************************************************* --=====================_47387804==_.ALT-- From rem-conf-request@es.net Sat Oct 2 19:35:51 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15689 for ; Sat, 2 Oct 1999 19:35:50 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11XYEO-0004wy-00; Sat, 2 Oct 1999 16:06:20 -0700 Received: from alba.startmultimedia.com [194.177.64.144] by mail1.es.net with esmtp (Exim 1.81 #2) id 11XYEK-0004w6-00; Sat, 2 Oct 1999 16:06:16 -0700 Received: from ip139.pasadena3.ca.pub-ip.psi.net (ip139.pasadena3.ca.pub-ip.psi.net [38.12.85.139]) by alba.startmultimedia.com (8.9.3/8.9.3) with SMTP id XAA07976; Sun, 3 Oct 1999 23:55:48 +0200 X-Authentication-Warning: alba.startmultimedia.com: ip139.pasadena3.ca.pub-ip.psi.net [38.12.85.139] didn't use HELO protocol To: rem-conf@es.net Content-Type: text/plain; charset="iso-8859-1" Message-ID: From: gdsfrhb@dhneeuvqqg.alba.startmultimedia.com Subject: FREE Pager-Great Gift Idea -lknddxwk Date: Sat, 02 Oct 1999 16:03:25 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE PAGER Get a top of the Line Brand New pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check Put Free pagers on your kids Give one to your wife Paging America is going to give you a top of the line full featured pager in your choice of color for FREE. This top viewable display pager is one of the smallest and lightest pagers on the market today and holds up to 32 numeric messages, has 9 music alerts or silent vibration mode, flex technology which provides three times the battery life, message time and day stamping and smart alarm so you can set a daily or weekly reminder. This pager comes in black, teal (green) and blue. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. Airtime for this pager is only $9.95 per month billed monthly or only $8.95 per month if we bill your credit card or checking account each month. Just call the toll free number and we'll ship your Free pager to you immediately in your choice of color already programmed with a local telephone number for your town. For immediate delivery call Paging America 24 hours a day at 800-443-3122 This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph(a)(2)(c) of S.1618 To be removed from our list you call us toll free at 888-248-2594 From rem-conf-request@es.net Sun Oct 3 00:44:14 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19244 for ; Sun, 3 Oct 1999 00:44:14 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11XdLx-0007ZR-00; Sat, 2 Oct 1999 21:34:29 -0700 Received: from comp43.snu.ac.kr [147.46.113.23] by mail1.es.net with esmtp (Exim 1.81 #2) id 11XdLv-0007ZH-00; Sat, 2 Oct 1999 21:34:27 -0700 Received: from yeonche ([147.46.210.171]) by comp43.snu.ac.kr (8.8.8+Sun/8.8.8) with SMTP id NAA05496 for ; Sun, 3 Oct 1999 13:34:25 +0900 (KST) Message-ID: <03c701bf0d59$c6d8a340$abd22e93@snu.ac.kr> From: "Oh yeonhee" To: Subject: remove Date: Sun, 3 Oct 1999 13:43:02 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C4_01BF0DA5.364ACD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_03C4_01BF0DA5.364ACD20 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 cmVtb3ZlDQo= ------=_NextPart_000_03C4_01BF0DA5.364ACD20 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIwMTQuMjEwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+cmVtb3ZlPC9G T05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_03C4_01BF0DA5.364ACD20-- From rem-conf-request@es.net Sun Oct 3 02:10:58 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28548 for ; Sun, 3 Oct 1999 02:10:58 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Xeji-000109-00; Sat, 2 Oct 1999 23:03:06 -0700 Received: from usc.edu [128.125.253.136] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11Xejg-0000zz-00; Sat, 2 Oct 1999 23:03:04 -0700 Received: from aludra.usc.edu (fanliu@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA02886 for ; Sat, 2 Oct 1999 23:03:04 -0700 (PDT) Received: from localhost (fanliu@localhost) by aludra.usc.edu (8.9.3/8.9.3/usc) with ESMTP id XAA16777 for ; Sat, 2 Oct 1999 23:03:03 -0700 (PDT) Date: Sat, 2 Oct 1999 23:03:03 -0700 (PDT) From: fanliu To: rem-conf@es.net Subject: re Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Best Regards, Cissy ----- "Live is about turning the things you want to do, to the things that you've done." ------ *********************************************************************** * Cissy Fang Liu EEB418 * * Ph.D Student Tel: (213)740-4657(O) * * Signal and Image Processing Institute * * Department of Electrical Engineering Email: fanliu@usc.edu * * University of Southern California http://biron.usc.edu/~fliu * *********************************************************************** From rem-conf-request@es.net Sun Oct 3 02:11:01 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28584 for ; Sun, 3 Oct 1999 02:11:00 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Xek1-00010M-00; Sat, 2 Oct 1999 23:03:25 -0700 Received: from usc.edu [128.125.253.136] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11Xek0-00010C-00; Sat, 2 Oct 1999 23:03:24 -0700 Received: from aludra.usc.edu (fanliu@aludra.usc.edu [128.125.19.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA03110 for ; Sat, 2 Oct 1999 23:03:24 -0700 (PDT) Received: from localhost (fanliu@localhost) by aludra.usc.edu (8.9.3/8.9.3/usc) with ESMTP id XAA16876 for ; Sat, 2 Oct 1999 23:03:23 -0700 (PDT) Date: Sat, 2 Oct 1999 23:03:23 -0700 (PDT) From: fanliu To: rem-conf@es.net Subject: remove Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf-request@es.net Sun Oct 3 12:34:59 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08772 for ; Sun, 3 Oct 1999 12:34:59 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11XoFG-0006OD-00; Sun, 3 Oct 1999 09:12:18 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11XoFD-0006O3-00; Sun, 3 Oct 1999 09:12:16 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 3 Oct 1999 17:12:13 +0100 To: rem-conf@es.net Subject: WG last call: MIB and tones drafts Date: Sun, 03 Oct 1999 17:12:11 +0100 Message-ID: <4175.938967131@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group, This is to announce a two week working group last call on the following drafts: Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-01.txt Pages : 25 Date : 27-Sep-99 Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-06.txt Pages : 37 Date : 28-Sep-99 The DTMF draft addresses the concerns raised during the Oslo meeting, and the MIB addresses comments raised during the previous working group last call held earlier this year. Please send comments to the rem-conf@es.net list before 18th October. If there are no serious objections, we intend to request the IESG to consider these for publication as proposed standards at that time. Colin From rem-conf-request@es.net Sun Oct 3 15:30:52 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09755 for ; Sun, 3 Oct 1999 15:30:51 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Xr9F-0000fD-00; Sun, 3 Oct 1999 12:18:17 -0700 Received: from schumaker.hkj.gov.jo [212.34.0.228] by mail1.es.net with esmtp (Exim 1.81 #2) id 11Xr9C-0000f1-00; Sun, 3 Oct 1999 12:18:15 -0700 Received: from computer by schumaker.hkj.gov.jo (UUNET UK simple 1.31 (pcalmp)) id WAA01395; Sun, 3 Oct 1999 22:05:52 -0200 (GMT) From: Date: Sun, 3 Oct 1999 22:05:52 -0200 (GMT) Message-Id: <199910040005.WAA01395@schumaker.hkj.gov.jo> To: Subject: Search Engine Registration adv MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I saw your listing on the internet. I work for a company that submits websites to search engines. We can submit your website to over 350 of the worlds best search engines and directories for a one time charge of only $39.95. If you would like to put your website in the fast lane and receive more traffic call me on our toll-free number listed below. All work is verified! Sincerely, Mike Davidson (888) 892-7537 From rem-conf-request@es.net Sun Oct 3 21:35:12 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11285 for ; Sun, 3 Oct 1999 21:35:12 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11XwgK-0003i9-00; Sun, 3 Oct 1999 18:12:48 -0700 Received: from bootstrap.agcs.com [130.131.48.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 11XwgJ-0003hz-00; Sun, 3 Oct 1999 18:12:47 -0700 Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.1/8.9.1) with ESMTP id SAA17351 for ; Sun, 3 Oct 1999 18:10:56 -0700 (MST) Posted-Date: Sun, 3 Oct 1999 18:10:56 -0700 (MST) Received: from agcs.com ([130.131.108.108]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA3120 for ; Sun, 3 Oct 1999 18:12:45 -0700 Message-ID: <37F7FF41.9D0BFE10@agcs.com> Date: Sun, 03 Oct 1999 18:13:37 -0700 From: "Axel Christiansen" Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Remove Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Remove From rem-conf-request@es.net Tue Oct 5 02:23:40 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25059 for ; Tue, 5 Oct 1999 02:23:40 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11YNUG-0004Cf-00; Mon, 4 Oct 1999 22:50:08 -0700 Received: from gabriel.ul.ie [136.201.1.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 11YNU9-00049x-00; Mon, 4 Oct 1999 22:50:01 -0700 Received: from smtp.boom.com (98CC3E1D.ipt.aol.com [152.204.62.29]) by gabriel.ul.ie with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id TQ6P6YL3; Tue, 5 Oct 1999 06:51:32 +0100 Date: Tue, 5 Oct 1999 01:46:36 From: Subject: Promote Travel Industry From Home. Message-Id: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GET YOUR FREE VACATION VOUCHER WHEN VISITING OUR WEB SITE! ONLY 14 ASSOCIATES NEEDED! We will train hard working and ethical candidates. HUGE COMPENSATION PLAN AVAILABLE! This is your chance to get in on the ground floor of the Multi-Billion-Dollar Home Based Business Revolution. Receive a COMPLIMENTARY Weekend GetAway when visiting our site. http://3465215558/mdw/index.html Click Here FOR FREE INFORMATION ------------------------------------------------- This mailing list is opt-in only. We are linked to many web sites that offer free subscriptions to our mailing list. To be removed place your email address with remove in name under the free package information form at the website above. From rem-conf-request@es.net Tue Oct 5 08:15:08 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27637 for ; Tue, 5 Oct 1999 08:15:08 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11YOub-00062f-00; Tue, 5 Oct 1999 00:21:25 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11YOua-00062V-00; Tue, 5 Oct 1999 00:21:24 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 5 Oct 1999 08:21:15 +0100 to: rem-conf@es.net Subject: UCL MBone Announcement: Seminar on IP Evolution by Steve Deering Date: Tue, 05 Oct 1999 08:21:13 +0100 Message-ID: <420.939108073@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list we'll be mbone-ing a seminar this friday at 1pm BST (see sdr for the Hourglass session), and http://www.cs.ucl.ac.uk/dept-seminar-abstracts/dept-seminar-991008.html for abstract its only on a best effort basis, so if things go horribly wrong, we are not going to chase any routing/congestion problems, but hopefully you may be able to see some of it.... thanks jon From rem-conf-request@es.net Tue Oct 5 13:06:02 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08092 for ; Tue, 5 Oct 1999 13:06:01 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11YXTS-0004RO-00; Tue, 5 Oct 1999 09:29:58 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11YXTR-0004R8-00; Tue, 5 Oct 1999 09:29:57 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id A46D54CE03 for ; Tue, 5 Oct 1999 12:29:52 -0400 (EDT) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id MAA25502 for ; Tue, 5 Oct 1999 12:29:50 -0400 (EDT) Message-ID: <018501bf0f4e$6500f310$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: Subject: ID on pointer payload format Date: Tue, 5 Oct 1999 12:26:36 -0400 Organization: AT&T Labs - Research MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit I have just posted an updated ID describing the RTP payload format for transmitting real-time pointers. If you want to take a look at it before it becomes available on the regular web site, it is available at: http://www.research.att.com/~mrc/draft-ietf-avt-pointer-01.t xt or http://www.research.att.com/~mrc/draft-ietf-avt-pointer-01.p s This update incorporates the modifications/additions as decided in the Oslo meeting. As always, comments are welcome. Best regards. ------------------------------------------------------------ ----------- M. Reha Civanlar Division Manager, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf-request@es.net Tue Oct 5 14:12:26 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09472 for ; Tue, 5 Oct 1999 14:12:25 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11YYo7-00062F-00; Tue, 5 Oct 1999 10:55:23 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11YYo6-000625-00; Tue, 5 Oct 1999 10:55:22 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA08468; Tue, 5 Oct 1999 10:44:49 -0700 (PDT) Message-Id: <3.0.3.32.19991005104507.00b46b10@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 05 Oct 1999 10:45:07 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/6 Resource Management in Operating Systems --Timothy Roscoe, Applied Technology Lab Sprint Communications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Resource Management in Operating Systems Wednesday October 6, 1999 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Timothy Roscoe Applied Technology Lab Sprint Communications This is a talk about how multimedia research and operating systems interact, in a few cases. Traditionally, multimedia applications research in academia and quite a few corporate labs has been based on dedicated hardware of one sort or another, either built specially for the application or else a general-purpose computer given over entirely to one processing job. The problem is usually not that the hardware lacks the resources, but that the system is incapable of sharing the resources in the appropriate way, including dynamically reallocating resources and policing resource usage. A few operating systems have appeared recently which directly address these problems, and in doing so require multimedia application designers to reorient their thinking away from virtual, abstracted resources to physical, controlled resources. This doesn't necessarily make writing programs harder, and can actually result in much simpler and more robust multimedia applications. I'll talk about this different way of thinking about systems, especially in relation to the Nemesis operating system. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf-request@es.net Tue Oct 5 19:10:00 1999 Received: from mail2.es.net (mail2.es.net [198.128.3.182]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13836 for ; Tue, 5 Oct 1999 19:09:59 -0400 (EDT) Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 11Yd9w-0003wX-00; Tue, 5 Oct 1999 15:34:12 -0700 Received: from stroudsburg135-pri.voicenet.com ([207.103.36.163] helo=mailer100.gte.net) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 11Yd9X-0003w3-00; Tue, 5 Oct 1999 15:33:50 -0700 From: To: Date: Tue, 5 Oct 1999 15:19:57 Message-Id: <773.856522.812828@mailer100.gte.net> Subject: Quick Cash From Home $$$ 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 Content-Transfer-Encoding: 7bit >Subject: Quick Cash From Home $$$ >Date: Mon, 4 Oct 1999 16:32:10 > > >>>>>>>>>HERE IS THE INFO YOU REQUESTED, THIS IS NOT SPAM, YOU ARE >RECEIVING THIS E-MAIL BECAUSE YOU OR SOMEONE ELSE REQUESTED THIS >INFORMATION. IF YOU WISH TO BE PERMANENTLY REMOVED FROM OUR >MAILING LIST. PLEASE SEND AN E-MAIL WITH THE WORD "REMOVE" IN THE >SUBJECT LINE TO: >easenterprises@hotmail.com. OUR COMPANY DOES NOT SUPPORT THE >SENDING OF UNSOLICITED E-MAILS. > >>>>>>>>>******************************************************* > >>>>>>>>>>>>>> > >>>>>>>>> WORK AT HOME USING YOUR COMPUTER!!! > > >>>>>>>>>******************************************************* > >>>>>>>>> >Dear Friend, > >>>>>>>>> >You can earn $46,000 or more in next the 90 days sending e-mail, >seem impossible? Read on for details (no, there is no 'catch')... > >>>>>>>>> > >>>>>>>>>"AS SEEN ON NATIONAL T.V." > >>>>>>>>> > >>>>>>>>>Thank you for your time and Interest. > >>>>>>>>>This is the letter you've been reading about in the news >lately. > >>>>>>>>> >Due to the popularity of this letter on the internet, >a major nightly news program recently devoted an entire show to >the investigation of the 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. >This has helped to show people that this is a simple, >harmless and fun way to make some extra money at home. >The results of this show has been truly remarkable. >So many people are participating that those involved are doing, >much better than ever before. Since everyone makes more as >more people try it out, its been very exciting to be a part of >lately. > >>>>>>>>>You will understand once you experience it. > >>>>>>>>> > >>>>>>>>>"HERE IT IS BELOW" > >>>>>>>>> > >>>>>>>>>================================================ > >>>>>>>>>================================================ > >>>>>>>>> > >>>>>>>>> *** Print This Now For Future Reference *** > >>>>>>>>> > >>>>>>>>>The following income opportunity is one you may be >interested in taking a look at. It can be started with VERY >LITTLE investment and the income return is TREMENDOUS!!! > >>>>>>>>> > >>>>>>>>>$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > >>>>>>>>> > >>>>>>>>>If you would like to make at least $46,000 in less than >90 days! > >>>>>>>>>Please read the enclosed program...THEN READ IT AGAIN!!! > >>>>>>>>> > >>>>>>>>>$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > >>>>>>>>> >THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does >not require you to come into contact with people, do any hard >work, and best of all, you never have to leave >the house except to get the mail. If you believe that someday >you'll get that big break that you've been waiting for, THIS IS >IT! Simply follow the instructions, and your dreams will come >true. > >>>>>>>>>This multi-level e-mail order marketing program works > >perfectly...100% EVERY TIME. E-mail is the sales tool of the >future. Take advantage of this non-commercialized method of >advertising NOW!!! The longer you wait, the more people will be >doing business using e-mail. Get your piece of this action!!! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>MULTI-LEVEL MARKETING (MLM) has finally 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 >the mid to late 1990's. This is a Multi-Billion Dollar industry >and of the 3,500,000 millionaires in the WORLD, 20% ( 700,000 ) >made their fortune in the last several >years in MLM. Moreover, statistics show that over 100 people >become millionaires everyday through >Multi-Level Marketing. >You may have heard this story before, but over the summer Donald >Trump (A MULTI-BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE >WORLD) >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!" > >>>>>>>>> > >>>>>>>>>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 is 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. This program is currently being utilized in more than 50 >different countries across the world. > >The enclosed information is something I almost let slip through my >fingers. Fortunately, sometime later I re-read everything and gave >some thought and studyto it. > >>>>>>>>> > >>>>>>>>>My name is Johnathon Rourke. Two years ago, the >corporation I >worked at for the past twelve years down-sized and my position was >eliminated. After unproductive job interviews, I decided to open >my own business. >Over the >past year, I incurred >many unforeseen financial problems. I owed my family, friends and >creditors over $35,000. The >economy was taking a toll on my business and I just couldn't seem >to make ends meet. I had to refinance and borrow against my home >to support my family and struggling business. AT THAT MOMENT >something significant happened in my life and I am writing to >share the experience in hopes that this will change your life >FOREVER FINANCIALLY!!! > >>>>>>>>> > >>>>>>>>>In mid December, I received this program via e-mail. Six >month's prior to receiving this program I had been sending away >for information on various business opportunities. All of the >programs I received, in my opinion, were not cost effective. They >were either too difficult for me to comprehend or the initial >investment was too much for me to risk to see if they would work >or not. One claimed that I would make a million dollars in one >year...it didn't tell me I'd have to write a book to make it! > >>>>>>>>> >But like I was saying, in December of 1997 I received this >program.I didn't send for it, or ask for >it, they just got my name off a mailing list. THANK GOODNESS FOR >THAT!!! After reading it >several times, to make sure I was reading it correctly, I couldn't >believe my eyes. Here was a MONEY MAKING PHENOMENON. I could >invest as much as I wanted to start, without putting me further >into debt. After I got a pencil and paper and figured it out, I >would at least get my money back. But like most of you I was >still a little skeptical and a little worried about the legal >aspects of it all. So I checked it out >with the U.S. Post Office (1-800-725-2161 24-hrs) and they >confirmed that it is indeed legal! After determining the program >was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." > >>>>>>>>> >Initially I sent out 100,000 e-mails. It cost me about $15 for my >time on-line. The great thing about e-mail is that I don't need >any money for printing to send out the program, and because all of >my orders are fulfilled via e-mail,the only expense is my time. I >am telling you like it is, I hope it doesn't turn you off, but I >promised myself that I would not "rip-off" anyone, no matter how >much money it cost me. > >>>>>>>>> > >>>>>>>>>In less than one week, I was starting to receive orders >for REPORT #1. By January 13, I had received 26 orders for REPORT >#1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 >WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU >DO!" My first step in making $46,000 in 90 days was done. By >January 30, I had received 196 orders for REPORT #2. Your goal is >to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 >WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU >DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, > >>>>>>>>> > >>>>>>>>>YOU WILL MAKE YOUR $46,000 GOAL." Well, I had 196 orders >for > >>>>>>>>>REPORT #2, 96 more than I needed. So I sat back and >relaxed. > >>>>>>>>>By March 1, of my e-mailing of 100,000, I received >$58,000 with more coming in every day. > >>>>>>>>> > >>>>>>>>>I paid off ALL my debts and bought a much needed new car. > >>>>>>>>>Please take time to read the attached program, IT WILL >CHANGE YOUR LIFE FOREVER!!! > >>>>>>>>>Remember, it won't work if you don't try it. This >program does work, but you must follow it >EXACTLY! Especially the rules of not trying to place your name in >a different place. It won't >work, you'll lose out on a lot of money! In order for this >program to work, you must meet your goal of 20+ orders for REPORT >#1, and 100+ orders for REPORT #2 and you will make $46,000 or >more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! >If you choose not to participate in this program, I am sorry. >Itreally is >a great opportunity with little cost or risk to you. If you >choose to participate, follow the program and you will be on your >way to financial security.If you are a fellow business owner and >are if financial trouble like I was,or you want to start your own >business, consider this a sign. I DID! > >>>>>>>>> > >>>>>>>>> Sincerely, > >>>>>>>>> > >>>>>>>>> Johnathon Rourke > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>P.S. Do you have any idea what 11,700 $5 bills ($58,000) >look like piled up on a kitchen table!!IT'S AWESOME! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>A PERSONAL NOTE FROM THE ORIGINATOR OF THIS > >>>>>>>>>PROGRAM: > >>>>>>>>> >By the time you have read the enclosed program and reports, you >should have concluded that such a program, and one that is legal, >could not have been created by an amateur. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>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 from first hand >experience. There were more failures and bankruptcies than ever >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 saying goes, "THE >RICH GET RICHER AND THE POOR GET POORER." The traditional methods >of making money will never allow you to "move up" or "get rich", >inflation will see to that. > >>>>>>>>> > >>>>>>>>>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 months than you have ever imagined. > >>>>>>>>> > >>>>>>>>>I should also point out that I will not see a penny of >this money, nor anyone else who has provided a testimonial for >this program. I have already made over 4 MILLION DOLLARS! I have >retired from the program after sending out over 1,600,000 >programs. Now I have several offices that make this and several >other programs here and overseas. > >>>>>>>>> > >>>>>>>>>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 100,000 or more...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! > >>>>>>>>> > >>>>>>>>>"THINK ABOUT IT" Before you delete this program from your >mailbox, as I almost did, take a little time to read it and 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! You will >definitely get back what you invested. Any doubts you have will >vanish when your first orders come in. IT WORKS! > >>>>>>>>> Jody Jacobs, >Richmond, VA > >>>>>>>>> > >>>>>>>>>HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS >OF DOLLAR$ > >>>>>>>>> > >>>>>>>>>INSTRUCTIONS: > >>>>>>>>>This method of raising capital REALLY WORKS 100% EVERY >TIME. I am sure that you could use up to $46,000 or more in the >next 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 and selling our products. Because of the global nature >of the internet, >you will be able to recruit new multi-level business partners from >all over the world, 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 privately in your own >home, store or office. This is the GREATEST Multi-Level Mail >Order > >>>>>>>>>Marketing anywhere: > >>>>>>>>> > >>>>>>>>>This is what you MUST do: > >>>>>>>>> > >>>>>>>>>1. Order all 5 reports shown on the list below (you can't > sell them if you don't order them). > >>>>>>>>> > >>>>>>>>>* For each report, send $5.00 CASH, the NAME & NUMBER > >>>>>>>>>OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and > >>>>>>>>>YOUR NAME & RETURN ADDRESS (in case of a problem) 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 five 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's of 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 is instructed below in steps "a" >through "g" or you will lose out on the majority of your profits. > Once you understand the way this works, you'll also see how it >doesn't work if you change it. Remember, this method has been >tested, and if you alter it, it will not work. > >>>>>>>>> > >>>>>>>>>a. Look below for the listing of available reports. > >>>>>>>>> > >>>>>>>>>b. After you've ordered the five reports, take this > >>>>>>>>> advertisement and remove the name and address >under > >>>>>>>>> REPORT #5. This person has made it through the >cycle and is no doubt counting their $46,000! Also, change the >name of the company, the address, and the remove e-mail address on >the top of this document to your own. > >>>>>>>>> > >>>>>>>> c. Move the name and address under REPORT #4 down to > >>>>>>>>> REPORT #5. > >>>>>>>>> > >>>>>>>>>d. Move the name and address under REPORT #3 down to > >>>>>>>>> REPORT #4. > >>>>>>>>> > >>>>>>>>>e. Move the name and address under REPORT #2 down to > >>>>>>>>> REPORT #3. > >>>>>>>>> > >>>>>>>>>f. Move the name and address under REPORT #1 down to > >>>>>>>>> REPORT #2. > >>>>>>>>> > >>>>>>>>>g. Insert your name/address in the REPORT #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 to your computer. Make NO changes to the >instruction portion of this letter. > >>>>>>>>> > >>>>>>>>>Your cost to participate in this is practically nothing >(surely you can afford $25). You obviously already have an >Internet connection and e-mail is FREE! > >>>>>>>>> > >>>>>>>>>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, where to find thousands of free classified ads and much, >much more. > >>>>>>>>> > >>>>>>>>>In addition you will be provided with information on >Internet Marketing Clubs such as INTERNET MARKETING >RESOURCES(IMR): This is one the premiere internet marketing clubs >on the INTERNET. This club provides a forum where interne >marketers from all over the world can exchange ideas and secrets >on Internet Marketing. In addition, members of this club are >provided free internet marketing tools and services for the >Do-Yourself-Internet-Marketer. They will provide you with free >bulk e-mail software and up to 1,000,000 fresh e-mail addresses >each week. This club will provide you with hundreds of free >resources which include: >How to obtain free web sites, how to obtain top rankings in >search engines for your web-site, how to send bulk e-mail into >AOL and Compuserve, how to market your products on >newsgroups, free classified ads, electronic malls, bulletin >boards, banner ads and much more. > >>>>>>>>> > >>>>>>>>>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, >and we'll assume you and all those involved send out only 2,000 >programs each. Let's also assume that the mailing receives a 0.3% >response. Using a good list the response could be much better. >Also, many people will send out hundreds of thousands of programs >instead of 2,000. But continuing with this example, you send out >only 2,000 programs. With a 0.3% response, that is only 6 orders >for REPORT #1. Those 6 people respond by sending out 2,000 >programs each for a total of 12,000. Out of those 0.3%, 36 people >respond and order >REPORT #2. Those 36 mail out 2,000 programs each for a total of >72,000. The 0.3% response to that is 216 orders for REPORT #3. >Those 216 send out 2,000 programs each for a 432,000 total. The >0.3% response to that is 1,296 orders for REPORT #4. Those 1,296 >send out 2,000 programs each for a 2,592,000 total. The 0.3% >response to that is 7,776 orders for REPORT #5. That's 7,776 $5 >bills for you. CASH!!! Your total income in this example is $30 + >$180 + $1,080 + $6,480 + $38,880 for a total of $46,650!!! > >>>>>>>>> > >>>>>>>>>REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 >PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS >PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF >EVERYONE, >OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. >Believe me, many people will do just that, and more! By the way, >your cost to participate in this is practically nothing. You >obviously already have an internet connection and e-mail is FREE!! >REPORT #2 and #5 will show you the best methods for bulk >e-mailing, tell you where to obtain free bulk e-mail software and >where to obtain e-mail lists and show you how to send out >1,000,000 e-mails for free. > >>>>>>>>> > >>>>>>>>>METHOD #2 - PLACING FREE ADS ON THE INTERNET > >>>>>>>>> > >>>>>>>>>1. Advertising on the 'Net is very, very inexpensive, >and there are HUNDREDS of FREE places to advertise. Let's say you >decide to start small just to see how well it >works. Assume your goal is to get ONLY 6 people to participate >on your first level. (Placing a lot of FREE ads on the internet >will EASILY get a larger response.) Also assume that everyone else >in YOUR ORGANIZATION gets ONLY 6 downline members. >Follow this example to achieve the STAGGERING results below. > >>>>>>>>> > >>>>>>>>>1st level--your 6 members with $5 ($5 x >6).............$30 > >>>>>>>>>2nd level--6 members from those 6 ($5 x >36).............$180 > >>>>>>>>> > >>>>>>>>>3rd level--6 members from those 36 ($5 x 216)....... >$1,080 > >>>>>>>>>4th level--6 members from those 216 ($5 x 1,296).. >$6,480 > >>>>>>>>>5th level-6 members from those 1,296 ($5 x 7,776)... >$38,880 > >----------- > >>>>>>>>> THIS TOTALS >----------------------$46,650 > >>>>>>>>> >Remember friends, this assumes that the people who participate >only recruit 6 people each. Think for a moment what would >happen if they got 20 people to participate! Many people will get >100's of participants! THINK ABOUT IT! >For every $5.00 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't advertise until they >receive the report! > >>>>>>>>> > >>>>>>>>>------------------------------------------ > >>>>>>>>>AVAILABLE REPORTS > >>>>>>>>>------------------------------------------ > >>>>>>>>> > >>>>>>>>>*** Order Each REPORT by NUMBER and NAME *** > >>>>>>>>> > >>>>>>>>>Notes: > >>>>>>>>> >- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT > CHEQUES NOT ACCEPTED >- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL- Make sure the >cash is concealed by wrapping it in at least two sheets of paper - > On one of those sheets of paper, include: (a) the number & name >of the report you are ordering, (b) your e-mail address, and (c) >your name & postal address. > >>>>>>>>> > >>>>>>>>>PLACE YOUR ORDER FOR THESE REPORTS NOW: > >>>>>>>>>______________________________________________________ > >>>>>>>>> > >>>>>>>>> >REPORT #1 "The Insider's Guide to Advertising for Free on the >Internet" > >>>>>>>>> > ORDER REPORT #1 FROM: > >>>>>>>>> > >>>>>>>>>EAS Enterprises > >>>>>>>>>196 Lehigh Circle > >>>>>>>>>Tobyhanna, PA. 18466 > >>>>>>>>>______________________________________________________ > >>>>>>>>> >REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the > >>>>>>>>>Internet" > >>>>>>>>> > >>>>>>>>>ORDER REPORT #2 FROM: > >>>>>>>>> > >>>>>>>>>American United Systems > >>>>>>>>>3915 Mission Avenue Suite 7414 > >>>>>>>>>Oceanside, CA. 92054-7801 > >>>>>>>>>______________________________________________________ > >>>>>>>>> >REPORT #3 "The Secrets to Multilevel Marketing on the Internet" > >>>>>>>>> > >>>>>>>>>ORDER REPORT #3 FROM: > >>>>>>>>> > >>>>>>>>>MLH Enterprises > >>>>>>>>>1450 N. Santa Fe Suite C-525 > >>>>>>>>>Vista, Ca. 92083 > >>>>>>>>>______________________________________________________ > >>>>>>>>> >REPORT #4 "How to become a Millionaire utilizing the Power > >>>>>>>>>of Multilevel Marketing and the Internet" > >>>>>>>>> > >>>>>>>>>ORDER REPORT #4 FROM: > >>>>>>>>> > >>>>>>>>>ROJ Inc. > >>>>>>>>>PO BOX 5052 > >>>>>>>>>Oceanside, Ca. 92051-5052 > >>>>>>>>> > >>>>>>>>>______________________________________________________ > >>>>>>>>> >REPORT #5 "How to SEND 1,000,000 e-mails for FREE" > >>>>>>>>> > >>>>>>>>>ORDER REPORT #5 FROM: > >>>>>>>>> > >>>>>>>>>Marketing Unlimited > >>>>>>>>>PO Box 2312 > >>>>>>>>>Carlsbad, Ca. 92008 > >>>>>>>>>______________________________________________________ > >>>>>>>>> > >>>>>>>>>______________________________________________________ > >>>>>>>>> >There currently more than 175,000,000 people online worldwide! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>******* TIPS FOR SUCCESS ******* > >>>>>>>>> > >>>>>>>>>* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, > >>>>>>>>> and follow the directions accurately. > >>>>>>>>> > >>>>>>>>>* Send for the five 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. > >>>>>>>>> > >>>>>>>>>* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU >RECEIVE. > > >>>>>>>>>* Be patient and persistent with this program. If you >follow the instructions exactly, your results WILL BE SUCCESSFUL! > >>>>>>>>> >* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! > > >>>>>>>>> > >>>>>>>>>******* YOUR SUCCESS GUIDELINES ******* > >>>>>>>>> > >>>>>>>>>Follow these guidelines to guarantee your success: > >>>>>>>>>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 #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 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. Please >answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the >answer is yes, please look at the following facts about this >program: > >>>>>>>>> > >>>>>>>>> 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT > >>>>>>>>> COST ANYTHING TO PRODUCE! > >>>>>>>>> > >>>>>>>>> 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT > >>>>>>>>> COST ANYTHING TO SHIP! > >>>>>>>>> > >>>>>>>>> 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT > >>>>>>>>> COST YOU ANYTHING TO ADVERTISE! > >>>>>>>>> > >>>>>>>>> 4. YOU ARE UTILIZING THE POWER OF THE INTERNET > >>>>>>>>> AND THE POWER OF MULTI-LEVEL MARKETING TO > >>>>>>>>> DISTRIBUTE YOUR PRODUCT ALL OVER THE > >>>>>>>>> WORLD! > >>>>>>>>> > >>>>>>>>> 5. YOUR ONLY EXPENSES OTHER THAN YOUR > >>>>>>>>> INITIAL $25 INVESTMENT IS YOUR TIME! > >>>>>>>>> > >>>>>>>>> 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE > >>>>>>>>> FROM THIS PROGRAM IS PURE PROFIT! > >>>>>>>>> > >>>>>>>>> 7. THIS PROGRAM WILL CHANGE YOUR > >>>>>>>>> LIFE FOREVER. > >>>>>>>>> > >>>>>>>>>******* T E S T I M O N I A L S ******* > >>>>>>>>> > >>>>>>>>>This program does work, but you must follow it EXACTLY! >Especially the rule of not trying to place your name in a >different position, it won't work and you'll lose a lot of >potential income. I'm living proof that it works. It really is >a great opportunity to make relatively easy money, with little >cost to you. If you do choose to participate, follow the >program exactly, and you'll be on your way to financial >security. > >>>>>>>>> Fred Dellaca, Westport, New Zealand > >>>>>>>>> > My name is Mitchell. My wife, Jody, 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 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 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 weeks she had received over 50 responses. Within >45 days she had received over $147,200 in $5 bills! I was >shocked! I was sure that I had it all figured and that it >wouldn't work. I AM a believer now. I have joined Jody 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 >MLM. > >>>>>>>>> Mitchell Wolf MD., 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.00 in the >first 14 weeks, with money still coming in. > >>>>>>>>> > >>>>>>>>> Sincerely yours, > >>>>>>>>> Pam Hedland Halmstad, Sweden > >>>>>>>>> > 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 surprised when I found my >medium-size post office box crammed with orders! For awhile, 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 deal is that it doesn't >matter where people live. There simply isn't a better investment >with a faster return. > >>>>>>>>> Dan Sondstrom, Alberta, Canada > >>>>>>>>> > >>>>>>>>> I had received this program before. I deleted it, >but later I wondered if I shouldn't 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 another program, ...11 months passed >then it came...I didn't delete this one!...I made more than >$41,000 on the first try!! > >>>>>>>>> Mohamed, Cairo, Egypt > >>>>>>>>> > >>>>>>>>> This is my third time to participate in this plan. >We have quit our jobs, and will soon buy a home on the beach and >live off the interest on our money. 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! > >>>>>>>>> Sam Lee Suva, Fiji Islands > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>ORDER YOUR REPORTS TODAY AND > >>>>>>>>>GET STARTED ON YOUR ROAD TO > >>>>>>>>>FINANCIAL FREEDOM! > >>>>>>>>> > >>>>>>>>>NOW IS THE TIME FOR YOUR TURN > >>>>>>>>> > >>>>>>>>>DECISIVE ACTION YIELDS > >>>>>>>>>POWERFUL RESULTS > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>PLEASE NOTE: If you need help with starting a business, >registering a business name, learning how income tax is handled, >etc., contact your local office of the Small Business >Administration (a Federal agency) 1-(800)827-5722 for free help >and answers to questions. Also, the Internal Revenue Service >offers free help via telephone and free seminars about business >tax requirements. Your earnings and results are highly dependant >on your activities and advertising. This letter constitutes no >guarantees stated nor implied. In the event that it is determined >that this letter constitutes a guarantee of any kind, that >guarantee is now void. Any testimonials or amounts of earnings >listed in this letter may be factual or fictitious. If you have >any question of the legality of this letter contact the Office of >Associate Director for Marketing Practices Federal Trade >Commission Bureau of Consumer Protection in WashingtonDC. From rem-conf-request@es.net Tue Oct 5 20:29:17 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14322 for ; Tue, 5 Oct 1999 20:29:16 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Yekh-00037c-00; Tue, 5 Oct 1999 17:16:15 -0700 Received: from mail.nps.navy.mil [131.120.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 11Yekf-00037S-00; Tue, 5 Oct 1999 17:16:13 -0700 Received: from nps.navy.mil (accelerate.stl.nps.navy.mil [131.120.179.139]) by mail.nps.navy.mil (8.9.3/8.9.3) with ESMTP id RAA01862; Tue, 5 Oct 1999 17:15:28 -0700 (PDT) Message-ID: <37FA94C8.B8EC040C@nps.navy.mil> Date: Tue, 05 Oct 1999 17:16:08 -0700 From: Don Brutzman Organization: Naval Postgraduate School X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: AVT working group , JMF Java media framework list , vrtp working group , movesrg , Softarch NTII mail list , DIS-Java-VRML Working Group Subject: rtpMonitor thesis and software available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit IMPLEMENTING A MONITOR APPLICATION FOR THE REAL-TIME TRANSPORT PROTOCOL (RTP) USING THE JAVA MEDIA FRAMEWORK (JMF) Francisco Carlos Afonso Lieutenant Commander, Brazilian Navy Naval Postgraduate School, Monterey California USA September 1999 Abstract. The Real-time Transport Protocol (RTP) supports the transmission of time-based media, such as audio and video, over wide-area networks (WANs), by adding synchronization and quality-of- service (QoS) feedback capabilities to the existing transport protocol. RTP has been widely used in the Multicast Backbone (MBone), a virtual network that has become a shared worldwide medium for Internet multicast communications. This work presents the design patterns, architecture and implementation of an RTP monitor application using the Java Media Framework (JMF), a new Java Application Programming Interface (API) for multimedia support. An RTP monitor is an application that receives packets from all participants in a multicast session in order to estimate the quality of service for distribution monitoring, fault diagnosis and both short and long-term statistics. This new RTP monitor is available as a component of the Virtual Reality Transfer Protocol (vrtp), a protocol being developed to support large-scale virtual environments (LSVEs) over the Internet. Initial test results are satisfactory for audio and video streams, as well as prototype RTP-compliant Distributed Interactive Simulation (DIS) protocol streams. Future work includes automated monitoring across WANs and standardizing structured data formats to comply with Management Information Base (MIB) requirements using Extensible Markup Language (XML) target set definitions. The thesis and software are available at http://www.web3D.org/WorkingGroups/vrtp/rtpMonitor/rtpMonitor.html Sample screen snapshots are available at http://www.web3D.org/WorkingGroups/vrtp/rtpMonitor/manual.html Comments, bricks and bouquets are welcome. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 831.656.2149 Monterey California 93943-5000 USA fax 831.656.3679 Virtual worlds/underwater robots/Internet http://web.nps.navy.mil/~brutzman From rem-conf-request@es.net Wed Oct 6 02:24:36 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29365 for ; Wed, 6 Oct 1999 02:24:35 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Yjth-0006OG-00; Tue, 5 Oct 1999 22:45:53 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11Yjtf-0006O6-00; Tue, 5 Oct 1999 22:45:52 -0700 Received: from uggla (ap03-034.mp.pi.se [195.7.87.34]) by mail.pi.se (8.8.8/8.8.8) with SMTP id HAA04503; Wed, 6 Oct 1999 07:45:44 +0200 (MET DST) Reply-To: From: "Gunnar Hellstrom" To: Cc: "IETF-avt list" Subject: New version of text conversation RTP draft Date: Wed, 6 Oct 1999 07:41:55 +0200 Message-ID: <000401bf0fbd$7fd0f720$0c01a8c0@uggla> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01BF0FCE.4359C720" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF0FCE.4359C720 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id HAA04503 Content-Transfer-Encoding: quoted-printable This is a submission of a new version of the RTP-Text internet draft: draft-ietf-avt-rtp-text-01.txt This version contains minor editorial adjustments and added clarification= s in the recommended procedures part, and an updated address of the author. Regards ______________________________________ Gunnar Hellstr=F6m Ericsson Mobile Communication AB Sweden Tel +46 708 204 288 Fax +46 8 556 002 06 Video +46 8 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom@omnitor.se ------=_NextPart_000_0005_01BF0FCE.4359C720 Content-Type: text/plain; name="draft-ietf-avt-rtp-text-01.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtp-text-01.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force AVT WG Internet Draft Gunnar = Hellstr=F6m draft-ietf-avt-rtp-text-01.txt Ericsson October 6, 1999 Expires: April 6, 2000 RTP Payload for Text Conversation STATUS OF THIS MEMO This document is an Internet-Draft and it 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/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html Distribution of this document is unlimited. ABSTRACT This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1].=20 Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. Hellstrom [Page 1] =0C Internet Draft 1 Introduction This memo defines a payload type for carrying text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. Text in text conversation sessions is sent as soon as it is available, or = with a small delay of up to 0.5 seconds for buffering. The text is supposed to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per second or less. Therefore, the expected number of characters to transmit is low. Only one or a few new characters are expected to be transmitted with each packet. T.140 specifies that text and other T.140 elements SHALL be transmitted in ISO 10 646-1 code with UTF-8 transformation. That makes it easy to implement internationally useful applications, and to handle the text in modern information technology environments. The most common T140 PDU is a character of ISO 10646 text, UTF-8 coded, submitted from T.140 without any extra framing.=20 =20 T.140 requires the transport channel to provide characters without duplication and in original order.=20 Text conversation users expect that text will be delivered with no or a low level of lost information. If lost information can be replaced with a special marker, the willingness to accept loss is expected to be higher. =20 Therefore a mechanism based on RTP is specified here. It gives text arrival in correct order, without duplications, with an optional possibility to repeat data for redundancy to lower the risk of loss, and a mechanism that reveals loss and therefore can insert a marker for lost text in the received stream. Since packet overhead is usually much larger than the T.140 contents, the increase in channel load by the redundancy scheme is minimal.=20 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4] 2. Usage of RTP When an unreliable transport of T.140 text session data in a packet network is selected, RTP with payload as described in this specification should be used. T.140 data is submitted for = transmission in a number of complete protocol data units (T140 PDU). A T140block contains one or more T140 PDU:s.=20 =20 Hellstr=F6m [Page = 2] =0C Internet Draft =20 A text conversation RTP packet contains an RTP header, a Payload Header, OPTIONAL redundant data fields, and the new (primary) T.140 data field. 2.1 RTP packet header =20 Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for T.140 text streams: Payload Type (PT): Payload type allocation is dynamic. If redundancy is used, the Payload Type SHALL indicate redundancy ("RED") according to RFC 2198 [3]. If no redundancy is used, the Payload Type SHALL specify the primary T.140 data "T140" payload format.=20 Sequence number: The Sequence Number SHALL be increased with one for each new transmitted packet. It is used for detection of packet loss and packets out of order, and can be used in the process of retrieval of redundant text, reordering of text and marking missing text. Timestamp: The RTP Timestamp encodes the approximate sampling instance of the primary text in the packet. A clock frequency of 1000 Hz SHALL be used. No sequential packets SHOULD use the same timestamp.=20 2.2 Additional headers When redundant data is used, additional headers specify the redundant = text fields. They are specified according to RFC 2198 and use dynamic = payload type "T140". 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra = framing. When using the format with redundant data, the transmitter MAY select a number of T.140 block generations to retransmit in each packet. A higher number introduces better protection against loss of text. It is RECOMMENDED to use no more than 6 generations. The=20 redundant data is placed in age order with most recent redundant text last in the redundance area. =20 3. Recommended procedures This section contains RECOMMENDED procedures for usage of the payload format. Based on the information in the received packets, the receiver can: - reorder received text out of order. - mark where text is missing because of packet loss. - compensate for lost packets by using redundant data. Hellstr=F6m [Page = 3] =0C Internet Draft =09 3.1 Recommended basic procedure =20 On reception, the RTP sequence number is compared with the sequence number of the last correctly received packet. If they are = consecutive, only the most recent t140block is retrieved from the received packet. = 3.2 Recommended procedure for compensation for lost packets. For reduction of data loss in case of packet loss, redundant data MAY be included in the packets. If network conditions are not known, it is RECOMMENDED to use two generations of T.140 blocks in the packets. If there is a gap in the RTP sequence numbers, and redundancy coded T.140blocks are available in the packet, older t140blocks are retrieved from the packet up to the point where the sequence number is consecutive to the last correctly received packet or no more t140block are available in the received packet.=20 Both for the case when redundancy is used and not used, missing data SHALL be marked. If there is still a gap in the sequence, one T.140 missing data marker ( Unicode character 2607 "Lightning") SHALL be inserted, UTF-8 coded, replacing each missing t140block.=20 3.3 Recommended procedure for compensation for packets out of order. For protection against packets arriving out of order, the following procedure MAY be implemented in the receiver. If analysis of a received packet reveals gaps in the sequence, the received packet can be kept in a buffer before being used as valid T.140 data. If a packet arrives with a t140block belonging to the gap, the gap is filled with the contents of this block. If all gaps are filled or the packet is kept in the buffer for 0.5 seconds, valid T140blocks in the buffered packet are retrieved and used as valid T.140 data. For each t140block still missing, a T.140 missing data marker (Unicode character 2607 "Lightning") is inserted.=20 3.4 Transmission during "silent periods" when redundancy is used. When using the redundancy transmission scheme, and there is nothing more to transmit from T.140, the latest t140block has a risk of getting old before it is transmitted as redundant data. The result is less useful protection against packet loss at the end of a text input sequence. For cases where this should be avoided, the ISO 10 646 synchronization character FEFF MAY be transmitted (UTF-8 coded) after some time of inactivity.=20 Hellstr=F6m [Page = 4] =0C Internet Draft 4. Examples This is an example of a T140 RTP packet without redundancy. 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=3D2|P|X| CC=3D0 |M| T140 dyn PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (1000Hz) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + T140 encoded data (PT=3Ddynamic) + | | + +---------------+ | | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 This is an example of an RTP packet with two t140 blocks using redundancy coding. 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=3D2|P|X| CC=3D0 |M| "RED" PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding "P" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| T140 dyn. PT| timestamp offset of "R" | "R" block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| T140 dyn. PT| | +-+-+-+-+-+-+-+-+ + | | + "R" T140 encoded redundant data (PT=3Ddynamic T140) + | | + +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | "P" T140 encoded primary data (PT=3Ddynamic T140) | + + + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure: Examples of RTP text packets. Hellstr=F6m [Page = 5] =0C Internet Draft 5. Security Considerations. Since the intention of the described payload format is to carry text in a text conversation, security measures in the form of encryption is of importance. The amount of data in a text conversation session is low and therefore any encryption method MAY be selected and applied to T.140 session contents or to the whole RTP packets.=20 When redundant data is included, the same security considerations as for RFC 2198 apply. 6 MIME Media Type Registrations This document defines a new RTP payload name and associated MIME type, T140 (text/t140). The registration form for this MIME type has been submitted to IANA. =20 6.1 Registration of MIME media type text/t140 MIME media type name: text MIME subtype name: t140 Required parameters: None Optional parameters: None Encoding considerations: T140 text can be transmitted=20 with RTP as specified in "draft-ietf-avt-rtp-text-01". Security considerations: None Interoperability considerations: None Published specification: ITU-T T.140 Recommendation. draft-ietf-avt-rtp-text-01. =20 Applications which use this media type: Text communication terminals and text conferencing tools. Additional information: None Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Intended usage: COMMON Author/Change controller: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Hellstr=F6m [Page = 6] =0C Internet Draft Expires: April 6, 2000 7. Author's Address Gunnar Hellstrom Ericsson Mobile Communication AB Home Communications SE-164 80 Stockholm =20 Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 8 References [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1999. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,=20 "Real Time Transport Protocol", RFC 1889. [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, "RTP payload for redundant audio data," RFC 2198, Internet Engineering Task Force, Sept. 1997. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 9 Revision history. Oct 6 1999. draft-01. Explanations in recommended procedures = improved. Hellstr=F6m [Page = 7] =0C ------=_NextPart_000_0005_01BF0FCE.4359C720-- From rem-conf-request@es.net Wed Oct 6 03:16:26 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29707 for ; Wed, 6 Oct 1999 03:16:25 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Yl2m-0007bU-00; Tue, 5 Oct 1999 23:59:20 -0700 Received: from giasbm01.vsnl.net.in [202.54.1.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 11Yl2k-0007bK-00; Tue, 5 Oct 1999 23:59:19 -0700 Received: from hyd.chiplogic.com ([203.197.21.84]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id MAA07508 for ; Wed, 6 Oct 1999 12:29:11 +0530 (IST) Received: from localhost (rafiq@localhost) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id MAA21306 for ; Wed, 6 Oct 1999 12:25:51 +0530 X-Authentication-Warning: hyd.chiplogic.com: rafiq owned process doing -bs Date: Wed, 6 Oct 1999 12:25:50 +0530 (IST) From: Rafiq Shaikh To: rem-conf@es.net Subject: Test tools for RTP/RTCP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, Are there any s/w test tools available to test the functionality of the RTP/RTCP s/w? any pointers will be very helpful. Thanks in advance. -Rafiq. From rem-conf-request@es.net Wed Oct 6 07:11:09 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01586 for ; Wed, 6 Oct 1999 07:11:08 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11Yolu-00027j-00; Wed, 6 Oct 1999 03:58:10 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11Yols-00027O-00; Wed, 6 Oct 1999 03:58:08 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01163; Wed, 6 Oct 1999 06:57:07 -0400 (EDT) Message-Id: <199910061057.GAA01163@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-pointer-00.txt,.ps Date: Wed, 06 Oct 1999 06:57:06 -0400 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 Real-Time Pointers Author(s) : M. Civanlar, G. Cash Filename : draft-ietf-avt-pointer-00.txt,.ps Pages : 5 Date : 05-Oct-99 This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalitiesp needed to implement a general mouse event transmission mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-pointer-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-pointer-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-pointer-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991005123244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-pointer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-pointer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991005123244.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 7 17:45:15 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25933 for ; Thu, 7 Oct 1999 17:45:15 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ZKfV-0001ni-00; Thu, 7 Oct 1999 14:01:41 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ZKfU-0001nJ-00; Thu, 7 Oct 1999 14:01:40 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JGUT6UUZZABV9EOW@GI.COM> for rem-conf@es.net; Thu, 7 Oct 1999 14:00:53 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 07 Oct 1999 14:05:13 -0400 Content-return: allowed Date: Thu, 07 Oct 1999 17:00:59 -0400 From: "Lalwaney, Poornima (SD-EX)" Subject: Call for Papers - Networld+Interop2000 To: "'end2end-interest@isi.edu'" , "'impp@iastate.edu'" , "'ipcdn@terayon.com'" , "'ipng@sunroof.eng.sun.com'" , "'aaa-wg@merit.edu'" , "'mobile-ip@standards.nortelnetworks.com'" , "'rem-conf@es.net'" , "'tcpsat@grc.nasa.gov'" , "'pilc@grc.nasa.gov'" , "'confctrl@isi.edu'" , "'megaco@standards.nortelnetworks.com'" , "'diffserv@ietf.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE2021D5ECC@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BF10EE.803C8918" 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_01BF10EE.803C8918 Content-Type: text/plain Apologize for the wide cross-posting ---------------------------------------------------------------------------- ------------------- CALL FOR PAPERS Engineers Conference on Broadband Internet Access Technologies, Systems and Services May 10-11, 2000 - Las Vegas Conventions Center as part of the Networld+Interop'2000 Program For the detailed call for papers and the program see: http://www.comsoc.org/confs/engconf/2000/EngConf.htm Paper Submission Deadline - December 1, 1999 ---------------------------------------------------------------------------- --------------------------- ------_=_NextPart_001_01BF10EE.803C8918 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Call for Papers - Networld+Interop2000

Apologize for the wide = cross-posting
---------------------------------------------------------= --------------------------------------
CALL FOR PAPERS
Engineers Conference on Broadband = Internet Access Technologies, Systems and Services
May 10-11, 2000 - Las Vegas = Conventions Center as  part of  the Networld+Interop'2000 = Program
For the detailed call for papers and = the program see:
http://www.comsoc.org/confs/engconf/2000/EngConf.htm


Paper Submission Deadline - December = 1, 1999
---------------------------------------------------------= ----------------------------------------------




------_=_NextPart_001_01BF10EE.803C8918-- From rem-conf-request@es.net Fri Oct 8 05:15:21 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13706 for ; Fri, 8 Oct 1999 05:15:20 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ZVho-0006zC-00; Fri, 8 Oct 1999 01:48:48 -0700 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ZVhm-0006z2-00; Fri, 8 Oct 1999 01:48:46 -0700 Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id KAA06588; Fri, 8 Oct 1999 10:48:32 +0200 (MET DST) Received: by lms001.lu.erisoft.se id KAA19408; Fri, 8 Oct 1999 10:48:31 +0200 (MET DST) Message-ID: <030501bf1169$8336ace0$7fb08496@e00008639f5da.epl.ericsson.se> From: "Lars-Erik Jonsson" To: "Ali Irfan-FIA225" , , Cc: "Natarajan Nat-ANN004" Subject: Re: Header Stripping Date: Fri, 8 Oct 1999 10:45:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hello ! [To: PILC and AVT, AVT included since original message appered at the PILC-list] Ali, the answers to your questions should be ABSOLUTELY NOT and PROBABLY NOT. Header stripping is in general something really ugly and such ideas should not be accepted. However, there is a reason for why ideas like that come up. The reason is that in cellular environments, the header compression scheme for real-time (e.g. CRTP) of today are not working very well due to the problematic characteristics of the links. This was studied in the internet draft "draft-degermark-crtp-cellular". New header compression solutions are needed that are efficient and robust enough against packet losses and thereby making things like header stripping uninteresting. A new concept for header compression, ROCCO, has been proposed and the work can be studied at: www.ludd.luth.se/users/larsman/rocco It is important to speed up the progress of the header compression development and standardization before ideas like those about header stripping has come to far. Support for and participation in the ROCCO development is needed /Lars-Erik Jonsson >Question: >1. Should a recommendation for header stripping/regeneration be allowed >in any IP network? >2. Also, should this issue be dealt with in the performance >implications draft? > >Background: > >I was just reading a Cellular network proposal (the name of group or doc. is >not important) for an IP network. For air-link optimization, >header-compression is recommend. Fine. In addition an option for >header-striping and regeneration down-stream is also allowed. A statement >in the doc. states, > > "Reducing of the header size is done by removing redundancy in the >originally coded header information AND/OR REMOVING HEADER FIELD INFORMATION >AND THERBY LOSING FUNCTIONALITY" > >This disturbed me. I want to make a contribution to the group to delete such >text, but would first like to get some feedback from this mailing list. > >Note: the doc. does state that these options are to be investigated and a >final recommendation made. So header-stripping option is not set in stone, >yet. > >Irfan Ali >Motorola From rem-conf-request@es.net Fri Oct 8 15:33:25 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29419 for ; Fri, 8 Oct 1999 15:33:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ZfKb-0003vV-00; Fri, 8 Oct 1999 12:05:29 -0700 Received: from mail2.uunet.ca [142.77.1.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11ZfKa-0003vL-00; Fri, 8 Oct 1999 12:05:28 -0700 Received: from dukat.psti.com ([207.176.196.175]) by mail2.uunet.ca with ESMTP id <55935-18477>; Fri, 8 Oct 1999 15:04:53 -0400 Received: from jerome.psti.com ([207.176.196.146]) by dukat.psti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id SK0RYJMV; Fri, 8 Oct 1999 15:04:52 -0400 Received: (qmail 2622 invoked by uid 1000); 8 Oct 1999 19:07:30 -0000 Message-ID: <19991008150730.A2598@jerome.psti.com> Date: Fri, 8 Oct 1999 15:07:30 -0400 From: jerome@psti.com To: rem-conf@es.net Subject: RTP testing Reply-To: jerome@psti.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, i'm implementing RTP and just read draft-ietf-avt-rtptest-01.txt about "RTP testing strategie". I would like to know if there is a available software able to perform these tests automatically. thanks From rem-conf-request@es.net Sat Oct 9 06:38:48 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18787 for ; Sat, 9 Oct 1999 06:38:47 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ZtL7-00035f-00; Sat, 9 Oct 1999 03:02:57 -0700 Received: from www.hwi.com (hwi.hwi.com) [206.168.68.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ZtL5-00035E-00; Sat, 9 Oct 1999 03:02:55 -0700 Received: from m44Asu4b2 (1Cust76.tnt17.sfo3.da.uu.net [63.23.49.76]) by hwi.hwi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 43PK90R0; Sat, 9 Oct 1999 03:55:29 -0600 DATE: 09 Oct 99 3:08:20 AM FROM: jobaldi@ibm.net Reply-to: jobaldi@ibm.net TO: jobaldi@ibm.net SUBJECT: 57 Million Email Addresses - ONLY $149.00 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 57 MILLION EMAIL ADDRESSES FOR ONLY $149 You want to make some money? I can put you in touch with over 50 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $500,000.00 That's right, I have 57 Million Fresh email addresses that I will sell for only $149. These are all fresh addresses that include almost every person on the Internet today, with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1/10% response. That's $2,850,000 in your pocket !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! I will even tell you how to mail them with easy to follow step-by-step instructions I include with every order. I will send you a copy of every law concerning email. It is easy to obey the law and make a fortune. These 57 Million email addresses are yours to keep, so you can use them over and over and they come on 1 CD. This offer is not for everyone. If you can not see the just how excellent the risk / reward ratio in this offer is then there is nothing I can do for you. To make money you must stop dreaming and TAKE ACTION. **************************************** THE BRONZE MARKETING SETUP 57,000,000 email addresses on CD These name are all in text files ready to mail!!! $149.00 **************************************** THE SILVER MARKETING SETUP 57,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. $ 189.00 **************************************** THE GOLD MARKETING SETUP VIRTUALLY EVERYTHING!! 57,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. AND Over 500 different Business Reports now being sold on the Internet for up to $100 each. You get full rights to resell these reports. With this package you get the email addresses, the software to mail them AND ready to sell information products. AND ...... .. a collection of the 100 best money making adds currently floating around on the Internet. $ 249 ************************************************************* SEVERAL WAYS TO ORDER !!! IF YOU ORDER BY PHONE OR FAX WE WILL SHIP YOUR CD CONTAINING THE 57 MILLION + NAMES WITHIN 12 HOURS OF YOUR ORDER!!! 1) WE ACCEPT: AMERICAN EXPRESS OR VISA <> MasterCard TYPE OF CARD AMX / VISA / MC??_______________ EXPIRATION DATE ___________________________ NAME ON CREDIT CARD________________________ CREDIT CARD #________________________________ BILLING ADDRESS ____________________________ CITY_________________________________________ STATE________________ZIP_____________________ PHONE INCLUDE AREA CODE___________________ EMAIL ADDRESS______________________________ WE WILL BILL selected amount to your account plus the following shipping costs SHIPPING COST OF 3.85 FIRST CLASS MAIL SHIPPING COST OF 15.00 24 HOUR EXPRESS MAIL / FEDERAL EXPRESS SALES TAX added where required FAX your order and a copy of your SIGNED check payable to Cyberdata for the appropriate amount to; 530-895-8470 2) Fax the same above requested credit card information to 530-895-8470. 3) Call phone # 530-872-6591. This is a 24 hour phone number to place a CREDIT CARD order. This is an ORDER LINE only. ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER Copyright 1999 All rights reserved From rem-conf-request@es.net Sun Oct 10 13:16:16 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08278 for ; Sun, 10 Oct 1999 13:16:16 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11a9sl-00015I-00; Sat, 9 Oct 1999 20:42:47 -0700 Received: from barbeque.maps.cs.cmu.edu [128.2.181.185] by mail1.es.net with smtp (Exim 1.81 #2) id 11a9sj-00014q-00; Sat, 9 Oct 1999 20:42:45 -0700 Received: from [208.168.196.106] by barbeque.maps.cs.cmu.edu id aa22753; 9 Oct 99 23:40 EDT To: kdtf@es.net MMDF-Warning: Parse error in original version of preceding line at barbeque.maps.cs.cmu.edu X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Date: Sat, 09 Oct 1999 23:37:25 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Via: *0/00** MessageID: Sensitivity: Public X-References: 0D7CDA71D, 072283F9B X-Other-References: 0D875AE0B References: 0C59C8304 Subject: $E-commerce will increase 40 times by 2003! From: sammy12@pickit2.com MMDF-Warning: Parse error in original version of preceding line at barbeque.maps.cs.cmu.edu X-Mailer: Microsoft Outlook Express 4.72.3110.5 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit EARN LIMITLESS RESIDUAL INCOME FROM INTERNET COMMERCE!! CALL 888-277-7691 TODAY! We are seeking qualified representatives for our new Internet-based technology company, which is financed by a well-known, 15-year-old public corporation. This parent corporation generates about $1.5 billion-per-year in gross revenue, and its top representatives earn from $1,000,000 to almost $3,000,000 per year! Conservative estimates predict that in 5 - 10 years our technology company will generate between $10 and $20 billion per year, with our TOP REPRESENTATIVES earning ALMOST UNIMAGINABLY HIGH INCOMES of at least TEN TIMES GREATER than those of the parent company!! Many INTERNET FORTUNES will be created over the next 5 years.. ONE OF THEM MIGHT AS WELL BE YOURS!!! Almost everyone who is aware of the rapid growth of the Internet has at some time envisioned themselves: - Making huge profits from an Internet-based business, - Working entirely from home, - Spending quality time with their families, and - Forever leaving behind the boss, the office, and the daily commute. - If you have too, then please read on! CONSIDER THE FOLLOWING: - Today, only 18% of North Americans have Internet access in their homes. - However, Internet use is doubling every 100 days! In it's first major study of the economic effect of the Internet, the U.S. Commerce Department said that Internet traffic is doubling every 100 days and Electronic Commerce should reach $300 Billion by 2002! - There are 85,000 new Internet customers logging on daily! - Many different sources have predicted that Internet Commerce will increase at least twenty-fold in the next 5 years, and that within 10 years, standard retailing of products will largely be replaced by online selling! - Experts are predicting that computer sales will drop drastically over the next few years because most homes will be logging onto the net using simpler, less expensive Internet Access Devices. - Some companies are already generating massive revenue by directing their customers to welcome or portal pages that display ads and banners tempting them to shop online. For example, during 1998, America Online generated 3.2 billion dollars of revenue through its entry page. ADDITIONALLY: Market research has shown the more services (such as Internet, long distance, cellular phone, and paging services) one company can provide to the same customer, the longer they are likely to retain that customer. - If they provide one service, they have less than a 50% chance of keeping that customer for one year. - However, if they provide two services, they have a 75% chance of keeping that customer for 5 years. - Finally, of a company can provide three or more services to one customer, they have a 90% chance of keeping that customer for AT LEAST 10 YEARS! THEREFORE: The race is on! Today all major telecommunications companies are competing to: - Secure their share of the Internet marketplace by acquiring new Internet users and capturing their online dollars, - Keep those customers for the next several years by offering them multiple services in addition to Internet access, and - Ultimately generate huge profits when E-Commerce explodes and their customer base spends 40 dollars for every 1 they are spending today! NOW, IMAGINE IF YOU COULD: - Sell Internet service. - Sell your customers an Internet Access Device to connect to that service. - Profit every month from every Internet account. - Direct every customer, every time they log on, to your own Online Supermall wehre they could purchase every imaginable product or service. - Profit from every online purchase made by every customer. - Earn enormous residual profits from all business generated by a potentially huge network of others who you recruit to dupicate your efforts, and thus - Capture your share of the E-Commerce now and make a fortune as it grows. "A wonderful idea for large company" you say, "but a fairy tale for me.." NOT ANY MORE! Our company is already "leveling the playing field" and can provide all the resources and tools you need to help you start our Internet Business and position yourself today to make a fortune from the Internet explosion! We are a rapidly-Growing technology company that is owned and financed by a 15-year-old international billion-dollar company that is publicly traded on the NYSE. We offer a uniquely stable ground floor opportunity, because our company is backed by an established business with a Dunn & Bradstreet credit rating of 5A1, the highest rating available to any business!! We are currently seeking qualified individuals to independently market our rapidly-growing nationwide Internet and telecommunications services and our state-of-the-art Internet Access Device throughout the entire United States and, in the near future, Canadian and Japanese markets! WE ARE SEEKING INDIVIDUALS WHO ARE: - Excited by the possibility of creating their own Internet fortune. - Understand why they must begin establishing their Internet presence today in order to do so. - Are willing to take immediate action and use our extensive resources and support to rapidly build their own business. - Are able to invest between $500 and $1000 to start their business. - Are serious about starting now! PLEASE NOTE: Our company is structured using a network marketing model similar to that of our 15-year-old parent company. This allows any individual to start his or her own business without a huge initial investment and makes our extensive resources and technology available to all who wish to use them. However, we only want serious, motivated individuals to consider joining our company and do not want our network marketing structure and relatively low start-up cost to attract the casually interested. HOWEVER: If you ARE serious, this is TRULY THE CHANCE OF A LIFETIME (and perhaps your only real chance) to "MAKE IT BIG" on the Internet! We can provide you with the following products and technology to successfully compete in the Internet marketplace: NATIONWIDE INTERNET ACCESS We offer our customers state-of-the-art Internet access through a high-speed backbone. We have over 2500 dial-in numbers that make us locally available anywhere in the country. THE WORLD'S BEST-SELLING INTERNET SCREEN PHONE We have exclusive rights to market the first and most popular Internet Access Device in the world! With this compact unit the average user can be online, surfing the web, and sending and retrieving email within 10 minutes of taking it out of the box!! This device is available now and is selling rapidly. AN EXTENSIVE E-COMMERCE WEBSITE We are rapidly developing a comprehensive online store where our customers will be able to purchase virtually any product or service they need! We already have hundreds of thousands of products and services as well as direct links to several affiliate sites, and we are adding new items every day! All transactions are carried out on our secure servers and all products are shipped promptly. A PORTAL PAGE LEADING TO OUR E-COMMERCE WEBSITE We have designed an entry page to the web so that every time any of your customers or representatives logs on to the Internet to check their email or to access a website, they view this page which displays banners and ads directing them to our E-Commerce Store! And, you profit every time one of your customers or representatives makes an online purchase! MULTIPLE TELECOMMUNICATIONS SERVICES We can keep our customers by offering them multiple, state-of-the-art telecommunications services, including long distance telephone service, cellular service, digital and alpha-numeric pager accounts, web hosting, an online university, and more! Furthermore, as more and more services deregulate, such as local telephone service and utilities, we will be competing for all of them! A COMPREHENSIVE TRAINING WEBSITE The two top representatives in our organization have designed a detailed training site which clearly and objectively describes how to build a successful business. This website contains essential information on prospecting, recruiting, training new members, and acquiring new customers. Most importantly, as your business grows, it will dramatically decrease the time you spend training your representatives and free valuable time for you to continue building your organization. SO, AS A REPRESENTATIVE, YOU CAN PROVIDE INDIVIDUALS WITH: 1) An Internet account. 2) A convenient device with which to access the web. 3) An E-Commerce site at which to shop. 4) Direction to that E-Commerce site every time they log on. 5) Multiple other telecommunications services. ALL THE NECESSARY TOOLS YOU NEED TO: - CAPTURE A SIGNIFICANT PERCENTAGE OF NEW INTERNET USERS, - PROFIT FROM ALL E-COMMERCE THEY GENERATE, and - RAPIDLY EXPAND YOUR BUSINESS TO KEEP UP WITH INTERNET GROWTH. CLEARLY, IF YOU STARTED NOW AND OVER THE NEXT FEW YEARS CAPTURED EVEN A TINY AMOUNT OF THE E-COMMERCE PROFITS ON THE INTERNET, YOU WOULD CREATE A RESIDUAL INCOME OF TRULY STAGGERING PROPORTIONS!! REMEMBER!! - Our parent company has, over the last 15 years, created annual incomes of $152,098.00 to $649,550.15 for over 1,000 individuals. - Its representatives have a millionaires' circle and a 10-million- dollar circle. - It did, as a whole, over $1.5 billion in sales last year. - The revenue ultimately generated by our new company, which will ride the ensuing tidal wave of Internet Commerce, WILL LIKELY SURPASS THAT OF THE PARENT COMPANY BY AT LEAST 10 TIMES!! DON'T MISS YOUR CHANCE TO PARTICIPATE IN THE FORTUNES THAT ARE GOING TO BE CREATED! LET US HELP YOU START BUILDING.. CALL TOLL FREE 1-888-277-7691 TODAY!! From rem-conf-request@es.net Sun Oct 10 23:00:46 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12881 for ; Sun, 10 Oct 1999 23:00:45 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11aV7a-00037G-00; Sun, 10 Oct 1999 19:23:30 -0700 Received: from 98aa23b2.ipt.aol.com (localhost) [152.170.35.178] by mail1.es.net with smtp (Exim 1.81 #2) id 11aV7X-000376-00; Sun, 10 Oct 1999 19:23:28 -0700 From: Subject: Become a reviewer for iNet Reviews and receive books, software, products you can keep for free! Date: Sun, 10 Oct 1999 18:51:05 Message-Id: <293.455460.306362@localhost> To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list iNet News October 1999 (for reviewers and prospects only) INet Reviews needs book, software & product reviewers. You may request any virtually title or consumer product. Titles are shipped directly to you with the freight paid from the publisher or manufacturer. You write a brief review and post it to our web site. For your review starter information kit reply to this email or send an email message with the words STARTER 1010g53 in the message subject line to juliacantor@bigfoot.com The starter kit contains complete information plus a 70 page list of review products others have received. This message is directed for iNet reviewers and referrals only. If you received this message by mistake, reply with the single word REMOVE to have your name removed from our email message database. If you have problem responding to this email, send a Self addressed Stamped envelope to iNet Reviews, 4015 Holcomb bridge Road, Ste 350-905, norcross, GA 30092. From rem-conf-request@es.net Mon Oct 11 00:08:21 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13626 for ; Mon, 11 Oct 1999 00:08:20 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11aWWJ-0004TV-00; Sun, 10 Oct 1999 20:53:07 -0700 Received: from proxy4.ba.best.com [206.184.139.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11aWWI-0004TL-00; Sun, 10 Oct 1999 20:53:06 -0700 Received: from kaipara (kaipara.live.com [206.86.37.12]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id UAA16278 for ; Sun, 10 Oct 1999 20:52:08 -0700 (PDT) Message-Id: <3.0.6.32.19991011205228.0093b580@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 11 Oct 1999 20:52:28 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: Updated info on tools for receiving MP3/RTP sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI, here is some updated information on available tools for receiving and playing multicast MP3 sessions (several of which have been announced on the MBone recently). There have recently been some new tools for receiving these sessions, as well as improvements to some existing tools. 1/ "Freeamp" - for Windows and Linux/x86 (& probably other platforms in the future) - can receive and play MP3/RTP multicast sessions, by giving it a 'pseudo-URL' argument: rtp://: (Thanks to Robert Kaye for implementing RTP reception in Freeamp.) This implementation currently does not generate RTCP reports. 2/ A new input plugin for AOL/Nullsoft's "Winamp" audio player (for Windows) allows Winamp users to receive & play MP3/RTP sessions directly. For details, see . 3/ For other MP3 player tools, the "playRTPMPEG" helper application can be used. This tool receives multicast MP3/RTP data, and feeds the MP3 data to an existing audio player (either via stdout, or via a built-in HTTP server). In particular, RealNetworks' "RealPlayer G2" can now be used - in combination with "playRTPMPEG" - to play multicast MP3 streams. For details, see Both "playRTPMPEG" and the new Winamp input plugin can now support the experimental "X-MP3" alternative RTP payload format for MP3 data, as well as the conventional MPEG audio format ("MPA") described in RFC2250. (The "liveCaster" server tool can also (optionally) transmit MP3 data using this new payload format.) The new payload format is more tolerant of network packet loss. For more information, see . (I will also be updating and resubmitting the associated Internet-Draft prior to the Washington DC IETF meeting.) Ross. From rem-conf-request@es.net Mon Oct 11 10:07:31 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03958 for ; Mon, 11 Oct 1999 10:07:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11afeG-0001t9-00; Mon, 11 Oct 1999 06:37:56 -0700 Received: from heliostat.uchicago.edu [128.135.99.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 11afeE-0001si-00; Mon, 11 Oct 1999 06:37:54 -0700 Received: from uchicago.edu (coelostat.uchicago.edu [128.135.99.69]) by heliostat.uchicago.edu (8.9.1b+Sun/8.9.1) with ESMTP id IAA05887; Mon, 11 Oct 1999 08:37:52 -0500 (CDT) Message-ID: <3801E864.C4CCAFAB@uchicago.edu> Date: Mon, 11 Oct 1999 08:38:44 -0500 From: Ken Hopper Reply-To: k-hopper@uchicago.edu Organization: The University of Chicago X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: abbyjenkins@bigfoot.com CC: rem-conf@es.net Subject: REMOVE References: <293.455460.306362@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit REMOVE From rem-conf-request@es.net Tue Oct 12 03:02:56 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06151 for ; Tue, 12 Oct 1999 03:02:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11avOn-0003TH-00; Mon, 11 Oct 1999 23:27:01 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11avOl-0003T7-00; Mon, 11 Oct 1999 23:26:59 -0700 Received: from my (ap01-023.mp.pi.se [195.7.86.23]) by mail.pi.se (8.8.8/8.8.8) with SMTP id IAA10872; Tue, 12 Oct 1999 08:26:39 +0200 (MET DST) From: "Gunnar Hellstrom" To: "Larry Masinter" , "Harald Tveit Alvestrand" , , "IETF-avt list" Cc: "Thomas Johansson" Subject: SV: Registration of MIME media type text/t140 Date: Tue, 12 Oct 1999 08:25:16 +0200 Message-ID: <000101bf147a$8c48a540$0b01a8c0@my> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <000601bf137a$855d8620$c3d2000d@copper.parc.xerox.com> X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id IAA10872 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA06151 Larry Masinter asks if the Text Conversation topic should be handled by the IMPP group. Yes, why not. Now, the transport is handled in the avt group because it makes use of RTP. Then the t140 medium is to be registered as a MIME text type. The purpose is real time character by character ( or close ) transmission of text in a call. In many cases it is combined with voice or video. IMPP goals is short messages first entered as a whole and then transmitted. That is different, but it would of course be of interest to study interworking. Regards Gunnar Hellström > -----Ursprungligt meddelande----- > Från: Larry Masinter [mailto:masinter@parc.xerox.com] > Skickat: den 11 oktober 1999 01:53 > Till: gunnar.hellstrom@omnitor.se; Harald Tveit Alvestrand; > ietf-types@iana.org > Ämne: RE: Registration of MIME media type text/t140 > > > > > Response to Harald's questions: > > > > The MIME Media type text/t140 is intended for the standards track. > > It will be used firstly in the megaco/H.248 protocol to indicate use of > > either RTP/t140 with the RTP payload format specified in the > internet-draft > > provided as the transport and medium for text conversation, or > TCP with the > > t140 stream without extra framing. > > > > For that purpose it also needs IANA registration. > > > > T.140 is intended for real time, character by character text > chatting. Time > > stamping info is not important. In transmission, it is UTF-8 > coded. The use > > as a text chat medium restricts use of positioning and > formatting control > > characters to a minimal set. > > > > To me it seems like it is suitable to register it as text. > > > > There is no explicit way to indicate language. > > It may be hard in an real time text chat to promise to keep to > one language, > > but there are many other planned environments where T.140 fits, > so it might > > be useful to give a language indication. > > > > Can you advice me how that is normally done? > > > > The IMPP working group is developing standards for real-time > text chatting. If there's going to be an IETF standard for > it, shouldn't it be considered by the IMPP group? > > ---------------------------------------------- Gunnar Hellström LM Ericsson Sweden E-mail gunnar.hellstrom@omnitor.se Tel +46 8 556 002 03 Mob. +46 708 204 288 Video and V.18 text tel +46 8 556 002 05 Fax +46 8 556 002 06 ------------------------------------------ From rem-conf-request@es.net Tue Oct 12 07:12:24 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08860 for ; Tue, 12 Oct 1999 07:12:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11azbb-0006Wq-00; Tue, 12 Oct 1999 03:56:31 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11azbZ-0006WW-00; Tue, 12 Oct 1999 03:56:29 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08068; Tue, 12 Oct 1999 06:55:27 -0400 (EDT) Message-Id: <199910121055.GAA08068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-text-01.txt Date: Tue, 12 Oct 1999 06:55:26 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-01.txt Pages : 7 Date : 11-Oct-99 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-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-text-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-text-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: <19991011110538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991011110538.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Oct 12 09:56:05 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15187 for ; Tue, 12 Oct 1999 09:56:03 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11b28Y-0000uJ-00; Tue, 12 Oct 1999 06:38:42 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11b28W-0000u9-00; Tue, 12 Oct 1999 06:38:41 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Oct 1999 14:38:24 +0100 To: rem-conf@es.net Subject: Re: WG last call: MIB and tones drafts In-reply-to: Your message of "Sun, 03 Oct 1999 17:12:11 BST." <4175.938967131@cs.ucl.ac.uk> Date: Tue, 12 Oct 1999 14:38:23 +0100 Message-ID: <3466.939735503@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A reminder that this working group last call is in progress. If you have any final comments on these drafts, please send them by Monday. Thanks, Colin --> Colin Perkins writes: >To the AVT working group, > >This is to announce a two week working group last call on the following >drafts: > >Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals >Author(s) : H. Schulzrinne, S. Petrack >Filename : draft-ietf-avt-tones-01.txt >Pages : 25 >Date : 27-Sep-99 > >Title : Real-Time Transport Protocol Management Information Base >Author(s) : M. Baugher, I. Suconick, B. Strahm >Filename : draft-ietf-avt-rtp-mib-06.txt >Pages : 37 >Date : 28-Sep-99 > >The DTMF draft addresses the concerns raised during the Oslo meeting, and >the MIB addresses comments raised during the previous working group last >call held earlier this year. > >Please send comments to the rem-conf@es.net list before 18th October. If >there are no serious objections, we intend to request the IESG to consider >these for publication as proposed standards at that time. > >Colin > From rem-conf-request@es.net Tue Oct 12 17:23:37 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26991 for ; Tue, 12 Oct 1999 17:23:37 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11b8wX-0005x0-00; Tue, 12 Oct 1999 13:54:45 -0700 Received: from andrew.triumf.ca [142.90.106.59] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11b8wW-0005wq-00; Tue, 12 Oct 1999 13:54:44 -0700 Received: from localhost (andrew@localhost [127.0.0.1]) by andrew.triumf.ca (8.8.7/8.8.7) with ESMTP id NAA27598 for ; Tue, 12 Oct 1999 13:54:39 -0700 Date: Tue, 12 Oct 1999 13:54:39 -0700 (PDT) From: Andrew Daviel Reply-To: Andrew Daviel To: RemConf List Subject: pruning required in mrouted ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are basically a leaf node on the Mbone. We had been running mrouted 3.8 on an SGI but it has been a bit unreliable, and I am considering using our FORE PowerHub 7100 directly. The PowerHub is an older model; according to mrinfo it is running "version 2.0". Thus, I believe it is not running prune and is not trace-capable. A software upgrade may be impossible without replacing some hardware. Is pruning absolutely required everwhere, or just at routing nodes? I haven't been following the list for a while; I remember some push to make sure no-one ran mrouted3.7. Would it cause trouble if we enable multicast on this router ? Andrew Daviel TRIUMF From rem-conf-request@es.net Wed Oct 13 09:25:34 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23081 for ; Wed, 13 Oct 1999 09:25:34 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11bNtl-0006oh-00; Wed, 13 Oct 1999 05:52:53 -0700 Received: from dialup-135-164.goldnet.net.il (m4.mail.net) [192.115.10.164] by mail1.es.net with smtp (Exim 1.81 #2) id 11bNtf-0006nw-00; Wed, 13 Oct 1999 05:52:50 -0700 Received: (qmail 11059 invoked by uid 507); 13 Oct 1999 10:10:44 -0000 Date: 13 Oct 1999 10:10:44 -0000 Message-ID: <19991013101044.11058.qmail@m4.mail.net> Cc: recipient list not shown: ; From: Manager Subject: good morning To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-713-866-8869 Call 24 hours a day, 7 days a week, including Sundays and holidays. . From rem-conf-request@es.net Wed Oct 13 13:39:18 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00936 for ; Wed, 13 Oct 1999 13:39:17 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11bS1w-0002GI-00; Wed, 13 Oct 1999 10:17:36 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 11bS1v-0002G8-00; Wed, 13 Oct 1999 10:17:35 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id KAA29256; Wed, 13 Oct 1999 10:17:34 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id KAA21862 for ; Wed, 13 Oct 1999 10:17:32 -0700 (PDT) Date: Wed, 13 Oct 1999 10:17:32 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199910131717.KAA21862@jackson.cs.ucsb.edu> To: brutzman@nps.navy.mil, rem-conf@es.net Subject: Re: rtpMonitor thesis and software available X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>The thesis and software are available at >>http://www.web3D.org/WorkingGroups/vrtp/rtpMonitor/rtpMonitor.html >>Sample screen snapshots are available at >>http://www.web3D.org/WorkingGroups/vrtp/rtpMonitor/manual.html Not that this tool is available (and I actually got it to work on Windoze) can anyone advise on how to make .vic.tcl and .vat.tcl work in Windoze? Or, does it simply not work? I'd like to add the rtpmon button to my windows apps. -Kevin From rem-conf-request@es.net Wed Oct 13 13:48:21 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01097 for ; Wed, 13 Oct 1999 13:48:19 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11bSEX-0002pG-00; Wed, 13 Oct 1999 10:30:37 -0700 Received: from lois.dgim.crc.ca [142.92.39.60] by mail1.es.net with smtp (Exim 1.81 #2) id 11bSEW-0002he-00; Wed, 13 Oct 1999 10:30:36 -0700 Received: (qmail 15201 invoked from network); 13 Oct 1999 17:29:23 -0000 Received: from meson.dgrc.crc.ca (HELO crc.ca) (142.92.34.4) by lois.dgim.crc.ca with SMTP; 13 Oct 1999 17:29:23 -0000 Sender: luigi@es.net Message-ID: <3804D02C.CB4FFC9A@crc.ca> Date: Wed, 13 Oct 1999 13:32:12 -0500 From: John Stewart Organization: CRC Canada X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin C. Almeroth" CC: brutzman@nps.navy.mil, rem-conf@es.net Subject: Re: rtpMonitor thesis and software available References: <199910131717.KAA21862@jackson.cs.ucsb.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hi Kevin; I seem to remember seeing that the call to source the .vic.tcl was commented out in some versions of the source. (I was looking for it on an older of vic for Linux) Do you have the newest vic source from UCL? Maybe if you don't get any informed answers you can have a peek at the source code to see what happened to the source line. Just a thought... John Stewart john.stewart@crc.ca > Not that this tool is available (and I actually got it to work on > Windoze) can anyone advise on how to make .vic.tcl and .vat.tcl > work in Windoze? Or, does it simply not work? > > I'd like to add the rtpmon button to my windows apps. From rem-conf-request@es.net Thu Oct 14 10:35:17 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02728 for ; Thu, 14 Oct 1999 10:35:16 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11blNd-0007MJ-00; Thu, 14 Oct 1999 06:57:17 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 11blNb-0007M9-00; Thu, 14 Oct 1999 06:57:15 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id GAA19927 for ; Thu, 14 Oct 1999 06:57:14 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id GAA24266 for rem-conf@es.net; Thu, 14 Oct 1999 06:57:13 -0700 (PDT) Date: Thu, 14 Oct 1999 06:57:13 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199910141357.GAA24266@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Re: rtpMonitor thesis and software available X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>Not that this tool is available (and I actually got it to work on >>Windoze) can anyone advise on how to make .vic.tcl and .vat.tcl >>work in Windoze? Or, does it simply not work? Thanks to Marcia Perry at LBL I'm part of the way there. I can get the button to show up (.vic.tcl and .vat.tcl need to be in c:\ not mbone home). But now I can't get the exec to exec ANYTHING... I've even tried simple bat files stored all over the place, commands like "dir" and "set". I'm still hunting though. -Kevin From rem-conf-request@es.net Thu Oct 14 12:05:59 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05619 for ; Thu, 14 Oct 1999 12:05:57 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11bn8Y-0001Kn-00; Thu, 14 Oct 1999 08:49:50 -0700 Received: from pop3.tu-dresden.de [141.30.2.83] by mail1.es.net with smtp (Exim 1.81 #2) id 11bn8X-0001Kd-00; Thu, 14 Oct 1999 08:49:49 -0700 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Thu, 14 Oct 1999 17:47:18 +0200 Received: from rncmm2.urz.tu-dresden.de by rmail with SMTP (IC-PP); Thu, 14 Oct 1999 17:48:05 +0200 Received: from localhost (fleck@localhost) by rncmm2.urz.tu-dresden.de (8.8.8+Sun/8.8.8) with SMTP id RAA02756; Thu, 14 Oct 1999 17:48:58 +0200 (MET DST) X-Authentication-Warning: rncmm2.urz.tu-dresden.de: fleck owned process doing -bs Date: Thu, 14 Oct 1999 17:48:57 +0200 (MET DST) From: Christoph Fleck X-Sender: fleck@rncmm2.urz.tu-dresden.de Reply-To: bzvd@tu-dresden.de To: "Kevin C. Almeroth" cc: rem-conf@es.net Subject: Re: rtpMonitor thesis and software available In-Reply-To: <199910141357.GAA24266@jackson.cs.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 14 Oct 1999, Kevin C. Almeroth wrote: > >>Not that this tool is available (and I actually got it to work on > >>Windoze) can anyone advise on how to make .vic.tcl and .vat.tcl > >>work in Windoze? Or, does it simply not work? > > Thanks to Marcia Perry at LBL I'm part of the way there. > I can get the button to show up (.vic.tcl and .vat.tcl need > to be in c:\ not mbone home). > > But now I can't get the exec to exec ANYTHING... I've even > tried simple bat files stored all over the place, commands > like "dir" and "set". I'm still hunting though. The sdr (maybe depends on the tcl/tk for Windows) would exec only *.exe files. Try to use "exec start command /c xxx.bat &" on win9x or "exec cmd /C start xxx.bat &" on NT. You can find a example tcl file (start ReLaTe from sdr): ftp://ftp-mm.urz.tu-dresden.de/pub/mbone/relate/mmrz/sdr-relate.tcl Rgds, Christoph Fleck ,----------------------------------------------------------------. | Beratungszentrum fuer Videokonferenzdienste (BZVD), TU Dresden | | Christoph Fleck Tel.: +49 (0)351/463-5653 | | E-Mail: bzvd@tu-dresden.de http://bzvd.urz.tu-dresden.de | `----------------------------------------------------------------' From rem-conf-request@es.net Thu Oct 14 12:58:25 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07254 for ; Thu, 14 Oct 1999 12:58:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11bo0p-0002fG-00; Thu, 14 Oct 1999 09:45:55 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11bo0n-0002f4-00; Thu, 14 Oct 1999 09:45:53 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id JAA19474; Thu, 14 Oct 1999 09:29:40 -0700 (PDT) Message-Id: <3.0.3.32.19991014093000.00b7f710@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 14 Oct 1999 09:30:00 -0700 To: Florissa Colina From: Florissa Colina Subject: 10/20 New Approaches to Image Retrieval and Video Shot Boundary Detection -- Yihong Gong, NEC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar New Approaches to Image Retrieval and Video Shot Boundary Detection Wednesday October 20, 1999, 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Yihong Gong NEC The explosive growth of digital images in computer systems and networks has dramatically increased the need for multimedia database systems that effectively index, store, and retrieve image and video data based on their contents. Techniques for content-based image retrieval enable users to retrieve images based on their visual similarities, while techniques for video shot boundary detection aim to segment a continuous video sequence into visually consistant units, so that the sequence can be efficiently indexed and retrieved. In this talk, I will present two novel approaches for image retrieval and video shot boundary detection. First, I will present an image retrieval system that strives to achieve advanced content-based image retrieval using seamless combination of two complementary approaches: on one hand, we propose a new color clustering method to better capture color properties of the original images; on the other hand, expecting that image regions acquired from the original images inevitably contain many errors, we make use of the available erroneous, ill-segmented image regions to accomplish the object region-based image retrieval. We also propose an effective image indexing scheme to facilitate fast and efficient image matching and retrieval. Next, I will present a new shot boundary detection method that achieves a better shot boundary detection rate and the precision rate. We use the same color clustering method used in the image retrieval system for extracting color distributions from video frames. A novel approach is proposed to effectively suppress both the intra-frame and the inter-frame color variations caused by noise, minor illumination changes, as well as camera and object motions. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf-request@es.net Fri Oct 15 08:58:55 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08774 for ; Fri, 15 Oct 1999 08:58:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11c6Sh-0007E3-00; Fri, 15 Oct 1999 05:27:55 -0700 Received: from s2.smtp.oleane.net [195.25.12.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 11c6Se-0007Dt-00; Fri, 15 Oct 1999 05:27:52 -0700 Received: from Dell (dyn-1-1-247.Cor.dialup.oleane.fr [62.161.8.247]) by s2.smtp.oleane.net with SMTP id OAA92798; Fri, 15 Oct 1999 14:27:47 +0200 (CEST) Message-ID: <007e01bf1708$a62234a0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: Media Gateway Control Date: Fri, 15 Oct 1999 14:27:05 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01BF1719.5AF83360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP, Megaco, H.248: performing seamless interoperation between IP and = PSTN networks. The international rendez-vous in Paris, 15-17 December 1999. More infos:=20 http://www.upperside.fr/bamgc.htm ------=_NextPart_000_0077_01BF1719.5AF83360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0077_01BF1719.5AF83360-- From rem-conf-request@es.net Fri Oct 15 08:59:53 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08813 for ; Fri, 15 Oct 1999 08:59:52 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11c6YS-0007G0-00; Fri, 15 Oct 1999 05:33:52 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11c6YQ-0007Fq-00; Fri, 15 Oct 1999 05:33:51 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07696; Fri, 15 Oct 1999 08:33:48 -0400 (EDT) Message-Id: <199910151233.IAA07696@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: An RTP Payload Format for Generic Forward Error Correction to Proposed Standard Date: Fri, 15 Oct 1999 08:33:47 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'An RTP Payload Format for Generic Forward Error Correction' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary The document provides a means of providing FEC for an RTP flow by XOR'ing together data packets to generate a separate FEC stream. The FEC format is generic in the sense that it works with arbitrary algorithms for deciding which data packets to combine and how many FEC packets to generate. There are two ways in which the FEC data may be transported: as a separate RTP flow, or by piggy-backing onto the original flow using the RFC2198 "redundant audio" payload format. Working Group Summary The FEC process was not controversial in AVT, and the draft includes appropriate warnings about misuse. The draft was held up in the working group for some time because it proved difficult to define SDP parameters to describe transport of FEC as a separate flow. A clean solution would require grouping the FEC flow with the original media flow, but SDP doesn't support grouping. The solution adopted in the draft is to include an SDP connection specification as a codec parameter, indicating where the FEC information for a flow is to be found. This is ugly, but the only workable solution the WG found. Protocol Quality The document was reviewed for the IESG by Vern Paxson. From rem-conf-request@es.net Fri Oct 15 11:47:43 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15381 for ; Fri, 15 Oct 1999 11:47:42 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11c9GO-0002ND-00; Fri, 15 Oct 1999 08:27:24 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11c9GM-0002Mw-00; Fri, 15 Oct 1999 08:27:23 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 15 Oct 1999 16:27:08 +0100 To: rem-conf@es.net Subject: AVT agenda and scheduling Date: Fri, 15 Oct 1999 16:27:09 +0100 Message-ID: <3079.940001229@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The AVT working group has two slots scheduled at the Washington DC IETF meeting: Wed 10th November, 15:30-17:30 Thu 11th November, 09:00-10:30 Those wishing agenda time in those slots should contact myself or Steve, and we'll put together a draft agenda. Thanks, Colin From rem-conf-request@es.net Fri Oct 15 20:51:49 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23660 for ; Fri, 15 Oct 1999 20:51:48 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11cHiT-0000z7-00; Fri, 15 Oct 1999 17:28:57 -0700 Received: from ip-124.remac.com (mailserv.netondemand.com) [207.171.26.124] by mail1.es.net with smtp (Exim 1.81 #2) id 11cHiO-0000yx-00; Fri, 15 Oct 1999 17:28:55 -0700 From: "ray@netondemand.com" To: Message-Id: <419.436447.69332245ray@netondemand.com> Subject: FREE ISP DISCONNECT IDLE SOLUTION Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 15 Oct 1999 17:28:55 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit ELIMINATE THIS PROBLEM FOR GOOD: "YOU HAVE BEEN IDLE FOR XX MINUTES, YOU WILL BE DISCONNECTED..." FREE SOFTWARE AVAILABLE AT: http://www.netondemand.com KEEP IT ALIVE! As a responsible user of e-mail for mass broadcasting, we filtered our e-mailing list at OptList.com 24 hours before the transmission of this message. At which time, all e-mail addresses registered at OptList.com with the preference to not receive unsolicited e-mail were removed from our list. To register your e-mail address for future removal, please visit http://www.OptList.com/register.html. We are not affiliated with OptList.com and they have no knowledge of our e-mailing activities. This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618 From rem-conf-request@es.net Sat Oct 16 10:28:49 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11917 for ; Sat, 16 Oct 1999 10:28:49 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11cUNi-0000TL-00; Sat, 16 Oct 1999 07:00:22 -0700 Received: from tempest.ocis.temple.edu [155.247.166.120] (jmulik) by mail1.es.net with esmtp (Exim 1.81 #2) id 11cUNh-0000TB-00; Sat, 16 Oct 1999 07:00:21 -0700 Received: from localhost (jmulik@localhost) by tempest.ocis.temple.edu (8.8.8/8.8.8) with ESMTP id KAA27356 for ; Sat, 16 Oct 1999 10:00:17 -0400 (EDT) Date: Sat, 16 Oct 1999 10:00:17 -0400 (EDT) From: Jaiwant Mulik X-Sender: jmulik@tempest.ocis.temple.edu To: rem-conf@es.net Subject: Calculating Control messages bandwidth. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The SRM famework suggests that all control traffic be limited to 5% of the total traffic. How can I estimate the total traffic so far and keep my control messages limited to within the 5% constraint? Is the limit on a per host basis or for the whole group? Pointers to relevent literature would be highly appreciated. regards, ----------------------------------------------------------------------- Jaiwant Mulik Home : (215) 204-5775 Room 203, 1928 N Broad St. Email: jmulik@unix.temple.edu Philadelphia, PA : jmulik@hotmail.com USA 19121 : jmulik@acm.org ----------------------------------------------------------------------- Office hours : Monday 10:30am to 12:30pm and Monday 4:30pm to 6:30pm Location : Room 1000M, Wachman Hall. Phone : (215) 204-3668 Home page : http://members.tripod.com/~jaiwant ----------------------------------------------------------------------- Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ? From rem-conf-request@es.net Tue Oct 19 07:20:11 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09350 for ; Tue, 19 Oct 1999 07:20:10 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11dWrX-0005Av-00; Tue, 19 Oct 1999 03:51:27 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11dWrV-0005Al-00; Tue, 19 Oct 1999 03:51:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08272; Tue, 19 Oct 1999 06:51:23 -0400 (EDT) Message-Id: <199910191051.GAA08272@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-video-01.txt Date: Tue, 19 Oct 1999 06:51:23 -0400 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 DV Format Video Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-video-01.txt Pages : 11 Date : 18-Oct-99 This document specifies the packetization scheme for encapsulating DV compressed digital video data streams, commonly known as A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-video-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-dv-video-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-dv-video-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: <19991018121615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-video-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-video-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121615.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Oct 19 07:21:20 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09440 for ; Tue, 19 Oct 1999 07:21:20 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11dWrS-0005Aj-00; Tue, 19 Oct 1999 03:51:22 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11dWrR-0005AZ-00; Tue, 19 Oct 1999 03:51:21 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08258; Tue, 19 Oct 1999 06:51:17 -0400 (EDT) Message-Id: <199910191051.GAA08258@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-format-guidelines-04.txt Date: Tue, 19 Oct 1999 06:51:17 -0400 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 : Guidelines for Writers of RTP Payload Format Specifications Author(s) : M. Handley, C. Perkins Filename : draft-ietf-avt-rtp-format-guidelines-04.txt Pages : 9 Date : 18-Oct-99 This document provides general guidelines aimed at assisting the authors of RTP [9] Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. The principles outlined in this document are applicable to almost all data types, but are framed in examples of audio and video codecs for clarity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-format-guidelines-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-format-guidelines-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-format-guidelines-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: <19991018121541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-format-guidelines-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121541.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Oct 19 13:44:45 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27578 for ; Tue, 19 Oct 1999 13:44:44 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11dd6Q-0002Gj-00; Tue, 19 Oct 1999 10:31:14 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11dd6P-0002GY-00; Tue, 19 Oct 1999 10:31:13 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA14484; Tue, 19 Oct 1999 10:22:43 -0700 (PDT) Message-Id: <3.0.3.32.19991019102308.00b55100@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Oct 1999 10:23:08 -0700 To: Florissa Colina From: Florissa Colina Subject: 10/20 New Approaches to Image Retrieval and Video Shot Boundary Detection -- Yihong Gong, NEC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar New Approaches to Image Retrieval and Video Shot Boundary Detection Wednesday October 20, 1999, 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Yihong Gong NEC The explosive growth of digital images in computer systems and networks has dramatically increased the need for multimedia database systems that effectively index, store, and retrieve image and video data based on their contents. Techniques for content-based image retrieval enable users to retrieve images based on their visual similarities, while techniques for video shot boundary detection aim to segment a continuous video sequence into visually consistant units, so that the sequence can be efficiently indexed and retrieved. In this talk, I will present two novel approaches for image retrieval and video shot boundary detection. First, I will present an image retrieval system that strives to achieve advanced content-based image retrieval using seamless combination of two complementary approaches: on one hand, we propose a new color clustering method to better capture color properties of the original images; on the other hand, expecting that image regions acquired from the original images inevitably contain many errors, we make use of the available erroneous, ill-segmented image regions to accomplish the object region-based image retrieval. We also propose an effective image indexing scheme to facilitate fast and efficient image matching and retrieval. Next, I will present a new shot boundary detection method that achieves a better shot boundary detection rate and the precision rate. We use the same color clustering method used in the image retrieval system for extracting color distributions from video frames. A novel approach is proposed to effectively suppress both the intra-frame and the inter-frame color variations caused by noise, minor illumination changes, as well as camera and object motions. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf-request@es.net Tue Oct 19 23:58:04 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08715 for ; Tue, 19 Oct 1999 23:58:03 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11dmXC-0006zC-00; Tue, 19 Oct 1999 20:35:30 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11dmXA-0006z2-00; Tue, 19 Oct 1999 20:35:28 -0700 Received: from kaipara (kaipara.live.com [206.86.37.12]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id UAA28591 for ; Tue, 19 Oct 1999 20:33:29 -0700 (PDT) Message-Id: <3.0.6.32.19991019203323.009b5100@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 19 Oct 1999 20:33:23 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: Updated MP3/RTP Internet Draft submitted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI, I have submitted a updated version of the "A More Loss-Tolerant RTP Payload Format for MP3 Audio" Internet Draft. The major changes (additions) to the draft are: - a brief section describing how to deal with (unusual) streams that mix layer I and II audio frames with layer III frames. - an appendix with 'pseudo code' that describes how to convert a stream of regular MP3 frames into "ADU frames", or vice-versa. Until the draft is announced (likely as ), you can find it online at . (For an illustration - with MP3 files - of the benefits of the new format, see ) I'm interested in any feedback on this draft, especially from MP3 experts (e.g., at Fraunhofer), or from others who are working on implementations. Ross. Abstract While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable for MPEG 1 or 2, layer III audio (commonly known as "MP3"). The reason for this is that an MP3 frame is not a true "Application Data Unit" - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. In this document we define a new RTP payload format for MP3 audio. The new format is essentially the same as that defined in RFC 2250, except for a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 "Application Data Units". This new format is therefore more data efficient in the face of packet loss. From rem-conf-request@es.net Wed Oct 20 06:42:36 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23939 for ; Wed, 20 Oct 1999 06:42:36 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11dsqz-0002u7-00; Wed, 20 Oct 1999 03:20:21 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11dsqx-0002tx-00; Wed, 20 Oct 1999 03:20:19 -0700 Received: from baby.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Oct 1999 11:20:01 +0100 X-Mailer: exmh version 2.0.2 X-url: http://www.ucl.ac.uk To: mbone@ISI.EDU, rem-conf@es.net, release@cs.ucl.ac.uk cc: P.OHanlon@cs.ucl.ac.uk Subject: New UCL vic release (vic-2.8ucl-1.0) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Oct 1999 11:19:59 +0100 Message-ID: <4742.940414799@cs.ucl.ac.uk> From: "Piers O'Hanlon" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi folks, We are proud to release the new version vic-2.8ucl-1.0. Vic was developed by LBL as a video conferencing tool to facilitate video conferencing over the Internet. This can be between two participants directly, or between a group of participants on a common multicast group. No special features are required to use VIC in point to point mode, but to use the multiparty conferencing facilities of VIC, all participants must reside on a portion of the Internet which supports IP multicast. VIC is based on IETF standards, using RTP above UDP/IP as its transport protocol, and conforming to the RTP profile for audio and video conference with minimal control. Vic provides a range of video codecs (H.261 Intra, H.263, H.263+, jpeg, bvc, cellb, nv, nvdct) from a number of different contributers. It runs on a range of platforms: Solaris, IRIX, Linux, FreeBSD3.2 and Windows 95/98/NT. At UCL we have continued the development of vic (from LBL) and are releasing a new version (vic2.8ucl-1.0) With the following additions, since vic2.8ucl5 (an experimental release): - Reorganised code into directory structure reflecting the functionality of the different modules of vic - in a style not disimilar to MASH. - Moved vic over to use UCL's version's of tcl/tk - this is due to a number of problems we have encountered here; The variety of versions of tcl/tk installed on target machines can be very wide and therefore provides us with a multitude of bugs and 'problems' that are not related to our code. We now ship the code now with UCL statically linkable version of tcl/tk (which also uses compiled in versions of the 'init' scripts as opposed to system installed which also lead to trouble) to minimise such problems. It is still possible to get vic to use the standard libraries by specifying -without-ucltk, and/or -without-ucltcl (though we cannot offer much help with problems created by different tcl/tk versions). - Moved vic over to use UCL's common library so it shares the codebase provided by rat - where possible; It now uses common DES code and Mbus code - so both the DES and Mbus sections have been re-written. - The meteor grabber has been fixed (using the source from the freeBSD version) for FreeBSD and vic now compiles under FreeBSD. - A number of useful fixes for the video4linux grabber plus new control panel from Jean-Marc Orliaguet - IPv6 support under UNIX and WIN32. Under UNIX this enabled by specifiying the --enable-ipv6 directive to configure. We have tested it with Solaris 7 ipv6, Linux 2.2.5 ipv6 kernel support. - Created an MS Visual C++ 6.0 project for compilation of vic under win32 environments - this also, unfortunately, meant we had to rename all C++ files from .cc to .cpp. The project has a number of different configuration choices; Debug, Release, Debug_IPv6 (Microsoft research's IPv6 - requiring NT 4.0, MS ipv6 version 1.3 and MS DDK), Debug_IPv6-Musica (a non-free ipv6 implementation from Thompson-CSF). - Now IPv6 host addresses and multicast addresses are automatically recognised and vic will attempt to use IPv6 (if compiled in). We look forward to any feedback, bug reports, patches and comments on experience. More information, including download instructions, is available from http://www-mice.cs.ucl.ac.uk/multimedia/software Please send all feedback to vic@cs.ucl.ac.uk Piers O'Hanlon/Kris Hasler Networked Multimedia Group University College London From rem-conf-request@es.net Wed Oct 20 15:27:46 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20589 for ; Wed, 20 Oct 1999 15:27:45 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11e0my-0007Qg-00; Wed, 20 Oct 1999 11:48:44 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11e0mx-0007QA-00; Wed, 20 Oct 1999 11:48:43 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA10701; Wed, 20 Oct 1999 11:47:10 -0700 (PDT) Date: Wed, 20 Oct 1999 11:48:39 -0700 (Pacific Daylight Time) From: Stephen Casner To: ietf-types@iana.org Subject: Registration of RTP payload format names Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [bcc'd to rem-conf for the AVT working group] This is a request from the Audio/Video Transport working group to review draft-ietf-avt-rtp-mime which defines a procedure to register Real-time Transport Protocol payload formats (encodings) as audio or video MIME subtype names. The draft also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes (RFC 1890 which is being revised as draft-ietf-avt-profile-new). The move to establish this procedure was instigated by Keith Moore and Harald Alvestrand for two purposes: - To use the existing MIME namespace for audio and video encodings to be transported by RTP rather than creating a new namespace as RFC 1890 implicitly did. - To increase the number of encodings available for use with existing MIME transport modes. Not all of the RTP payload formats represent encodings that make sense for other transport modes, or at least it will be necessary to specify how the media data should be packaged for those modes since just concatenating a sequence of packet payloads won't be sufficient. The draft currently just registers the names for RTP transport and leaves the specification of packaging for other modes to future drafts. Your review is requested in particular for the registration procedure which says what additional information is required to specify RTP transport of a media type. The current version of the draft is draft-ietf-avt-rtp-mime-00.txt, but it is about to be updated to -01 (before draft deadline) with some minor additions. If anyone has comments right away, those can be addressed in the update, otherwise the review will be on the -01 version. As new RTP payload formats are defined in the future (beyond those included in RFC 1890 and its revision), each of those RFCs should include its own registration template. I believe you have already been informed of one such RTP payload format specification that happens to fall under "text" rather than "audio" or "video", i.e. draft-ietf-avt-rtp-text-XX. -- Steve From rem-conf-request@es.net Wed Oct 20 16:28:19 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22921 for ; Wed, 20 Oct 1999 16:28:17 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11e27q-00010C-00; Wed, 20 Oct 1999 13:14:22 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11e27o-0000zs-00; Wed, 20 Oct 1999 13:14:20 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA12221; Wed, 20 Oct 1999 13:13:15 -0700 (PDT) Date: Wed, 20 Oct 1999 13:14:45 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: RTP spec questions Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list AVT working group: I have a few questions regarding changes to the RTP spec. I'm interested in any comments you may have now, and we can discuss these at the upcoming meeting as well. 1. At the Oslo IETF meeting, and as reported in the minutes of that meeting, we agreed to change the representation of the loop/collision detection algorithm to pseudo-C. This was part of the question, when a new source transport address is seen for a known SSRC id, whether packets from the old address should be kept and from the new address ignored, as is currently specified, or vice versa. The motivation for changing the spec is to accommodate mobile hosts that may change their address. Since following the new source requires hysteresis in case there really are two sources colliding, I propose to not add any additional complexity to the pseudo-code algorithm, but to add in the text the following statement: For applications in which sources may change addresses, the RTP implementation SHOULD modify the collision detection algorithm to accept packets from the new source transport address. To guard against flip-flopping between addresses if a genuine collision does occur, the algorithm should include some means to detect this case and avoid switching. 2. As discussed in August, if a source has not been sending data for a while, so it is sending RR's with a fairly large interval according to the receiver fraction of the RTCP bandwidth, and then it begins to transmit, it may be quite a while before the RTCP interval expires and the first SR is sent. The change is to add a statement to 6.3.8 that a transition of we_sent from false to true SHOULD trigger a "reverse reconsideration" recalculation of the RTCP interval. 3. In scenarios with one or a small number of data senders and many receivers, the sender's RTCP interval may be much shorter than that of the receivers. Therefore, 6.3.5 on timing out an SSRC needs to be based on the RTCP interval using the receiver fraction rather than the sender fraction, even for senders. 4. In Oslo we decided _not_ to change the calculation of avg_rtcp_size to include only the RTCP packets being transmitted and exclude those received from other sources, even though there is a potential for unfair use of RTCP bandwidth, because it would complicate many parts of the algorithm without a clear gain. A related question has occurred to me just recently: If an RTCP compound packet includes information from more than one host, as in the case where an RTP mixer aggregates SDES information from multiple sources, should the size of that packet be divided by the number of sources before being figured into the average? The scenario which tiggered this question was the idea we discussed in Oslo for a possible new one-to-many RTP profile in which RTCP packets are sent via unicast from receivers to the sender which then reflects them back out to all receivers using multicast. Packets from multiple receivers could be aggregated, which would perturb the existing average size calculation. For a new profile, it would be possible to specify a modification to the calculation for that profile. -- Steve From rem-conf-request@es.net Thu Oct 21 06:55:33 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14134 for ; Thu, 21 Oct 1999 06:55:33 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eFPW-0007db-00; Thu, 21 Oct 1999 03:25:30 -0700 Received: from giasbm01.vsnl.net.in [202.54.1.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eFPT-0007dQ-00; Thu, 21 Oct 1999 03:25:28 -0700 Received: from hyd.chiplogic.com ([203.197.21.112]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id PAA29328; Thu, 21 Oct 1999 15:55:18 +0530 (IST) Received: from localhost (rafiq@localhost) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id PAA15406; Thu, 21 Oct 1999 15:51:06 +0530 X-Authentication-Warning: hyd.chiplogic.com: rafiq owned process doing -bs Date: Thu, 21 Oct 1999 15:51:06 +0530 (IST) From: Rafiq Shaikh To: rem-conf@es.net cc: hariv@chiplogic.com Subject: Silence Supression - Frame Based Speech Codecs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, As far as RTP is concerened, how is Silence Supression implemented w.r.t. Frame Based speech codecs? During Silence supression, are RTP packets sent without any Payload or we don't need to send RTP packets at all? If No RTP packet is sent for the Silence period: a) How do we distinguish a Packet loss with No packet sent? (During Silence frames) b) In RTP, is there a restriction on the duration of Silence period? c) What is the possible effect on the statistical calculations done in the RTCP part. How can we utilize the Marker bit in the RTP Header to distinguish between the NULL frame and the Active frame within the same RTP Packet? Thanks in advance. Regards, -Rafiq. From rem-conf-request@es.net Thu Oct 21 07:09:28 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14552 for ; Thu, 21 Oct 1999 07:09:28 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eFn7-0000SS-00; Thu, 21 Oct 1999 03:49:53 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eFn6-0000SI-00; Thu, 21 Oct 1999 03:49:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13539; Thu, 21 Oct 1999 06:49:50 -0400 (EDT) Message-Id: <199910211049.GAA13539@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-mp3-00.txt Date: Thu, 21 Oct 1999 06:49:50 -0400 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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rtp-mp3-00.txt Pages : 7 Date : 20-Oct-99 While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable for MPEG 1 or 2,layer III audio (commonly known as 'MP3'). The reason for this is that an MP3 frame is not a true 'Application Data Unit' - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. In this document we define a new RTP payload format for MP3 audio. The new format is essentially the same as that defined in RFC 2250, except for a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units'. This new format is therefore more data efficient in the face of packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mp3-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mp3-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991020133259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mp3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mp3-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991020133259.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 21 09:58:01 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23628 for ; Thu, 21 Oct 1999 09:58:00 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eITs-0002OG-00; Thu, 21 Oct 1999 06:42:12 -0700 Received: from okigate.oki.co.jp (titanic.potato.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eITq-0002O3-00; Thu, 21 Oct 1999 06:42:10 -0700 Received: from kangaroo (dh22.potato.kansai.oki.co.jp [10.173.7.222]) by titanic.potato.kansai.oki.co.jp (8.9.3/3.7W) with SMTP id WAA53423; Thu, 21 Oct 1999 22:41:04 +0900 (JST) Message-ID: <00c401bf1bc9$eb35a0c0$de07ad0a@kangaroo.potato.kansai.oki.co.jp> From: "Shigeru Fukunaga" To: Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "=?iso-2022-jp?B?GyRCTFpBNBsoQiAbJEIxUUxAGyhC?=" Subject: RTCP payload format for backward messages Date: Thu, 21 Oct 1999 22:41:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Dear AVT experts, Japanese MPEG-4 experts are planning to propose a new RTP format for MPEG-4 Audio/Visual to Washington meeting. This proposal was discussed in the last MPEG meeting (October), and ISO send a liaison to IETF to recommend this new proposal. Now we are discussing this issue on the MPEG-4 over IP AdHoc Group's reflector. We will input the internet-draft soon until tomorrow dead line. In this internet-draft, there is a new proposal of RTCP payload format, as well as RTP formats. This RTCP payload will be used to transport the backward messages of NEWPRED from the decoder to the encoder. NEWPRED is an error resilience video tool selecting the reference pictures according to the network error conditions. The syntax of the backward messages of NEWPRED is defined in the Visual part of MPEG-4 version 2, and the streams of the back messages are generated in the video decoder corresponding to the forward Video Packets or VOPs. The contents of the messages are changed message by message. Therefore the RTCP, we proposed, has a payload to deliver the backward message as 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| BMT | $B!!!!!!(BPT $B!!!!!!(B| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | MPEG-4 Backward Channel Message Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding should only be required on the last individual packet because the compound packet is encrypted as a whole. backward channel message type (BMT): 5 bits Identifies the type of the MPEG-4 backward channel messages. 0: forbidden 1: MPEG-4 Visual NEWPRED 2-63: reserved In this internet-draft, only NEWPRED is assigned as the candidate of the BMT for the moment. Some other MPEG-4 Audio/Visual applications using the backward channel messages may be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant for MPEG-4 backward channel messages. The assignment of an RTCP payload type for this new packet format is outside the scope of this document, and will not be specified here. SSRC: 32 bits SSRC is the synchronization source identifier for the sender of this packet. MPEG-4 Backward Channel Message Payload: variable The syntax and semantics of the MPEG-4 backward channel messages are defined in the ISO/IEC 14496-2/3. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, and several messages with same BMT could be continuously mapped onto one RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. -- To tell the truth, we had wondered which format (RTP or RTCP) is appropriate for the backward messages of NEWPRED, and we decided to use RTCP at the Melbourne. If there is other good solution, would you please propose it, and discuss here and at Washington? We understand that RTCP has a limit of sending timing, and the receiver has to send RTCP report to all terminals. However there is a exceptional procedure in the RFC2032 (RTP payload format for H.261). In the document, the control messages can be sent immediately after error detection only to one encoder (not all terminals). Therefore we copy the description of RFC2032 to our proposal for the moment. Comments are welcome. Best Regards, Shigeru Fukunaga -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5105; Fax. +81 6 6949 5108 From rem-conf-request@es.net Thu Oct 21 11:01:05 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27842 for ; Thu, 21 Oct 1999 11:01:04 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eJWJ-0003Tz-00; Thu, 21 Oct 1999 07:48:47 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11eJWI-0003TF-00; Thu, 21 Oct 1999 07:48:46 -0700 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 21 Oct 1999 09:47:57 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256811.00512499 ; Thu, 21 Oct 1999 10:46:17 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Rafiq Shaikh cc: rem-conf@es.net, hariv@chiplogic.com Message-ID: <85256811.00512440.00@notes4.nmss.com> Date: Thu, 21 Oct 1999 10:49:11 -0400 Subject: Re: Silence Supression - Frame Based Speech Codecs? 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 As far as RTP is concerened, how is Silence Supression implemented w.r.t. Frame Based speech codecs? During Silence supression, are RTP packets sent without any Payload or we don't need to send RTP packets at all? Answer: I believe you do not need to send any packets at all. This is vocoder specific, however, all of the ones which I am familiar with send special packets at the beginning of a silence period and periodically during one (at a very reduced rate). If No RTP packet is sent for the Silence period: a) How do we distinguish a Packet loss with No packet sent? (During Silence frames) Answer: Excellent question. I believe that you cannot tell. There are some augmentations in the works for RTP such as redundancy which attempt to grapple with this. b) In RTP, is there a restriction on the duration of Silence period? Answer: As far as I know, RTP itself imposes no restriction. c) What is the possible effect on the statistical calculations done in the RTCP part. Answer: I believe there is no major effect on the calculation of jitter. Packet loss however does have an effect. How can we utilize the Marker bit in the RTP Header to distinguish between the NULL frame and the Active frame within the same RTP Packet? Answer: Again this is vocoder specific. Some vocoders have rules about what sort of frame can follow another frame. Others have implicit length indicators within each frame. The marker bit is essentially useless/redundant in my humble opinion. Hope that helps. Other replies invited. From rem-conf-request@es.net Thu Oct 21 15:38:14 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11980 for ; Thu, 21 Oct 1999 15:38:13 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eNYA-0006UW-00; Thu, 21 Oct 1999 12:06:58 -0700 Received: from gateway.mitel.ca (semimail.semird.mitel.com) [198.53.180.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eNY8-0006UD-00; Thu, 21 Oct 1999 12:06:56 -0700 Received: from mitel.com (spruce [134.199.98.152]) by semimail.semird.mitel.com (8.9.3/8.9.3) with ESMTP id PAA03123; Thu, 21 Oct 1999 15:05:33 -0400 (EDT) Sender: ALEXANDER_TULAI@Mitel.COM Message-ID: <380F63FC.D980FBDD@mitel.com> Date: Thu, 21 Oct 1999 15:05:33 -0400 From: Alexander Tulai - icpd Reply-To: alexander_tulai@Mitel.COM Organization: MITEL Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: wp3audio@ctd.comsat.com CC: rem-conf@es.net Subject: Re: Study of CNG References: <4.2.0.58.19991021113628.00aac4e0@basset.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Dear Colleagues, I am afraid that proper means for adopting standards are under serious preasure in the case of a new proposal for CNG coming from Lucent. I would like to point out to you, that the "urgent work" is actually urgent due to the presentation of one contribution only, from Lucent, to the following ITU working groups: SG 16 Q19 SG 15, Q6, SG 15, Q21 These working groups are perhaps not the only ones the contribution went to. The fact that Lucent wants it badly doesn't mean the ITU community has to cut corners. At this point in time, the Comfort Noise Generation for G.711 method adopted by IETF for IP networks (see RFC1890) and ITU-T for ATM networks (see I.366.2 Appendix I2) are identical (one byte representing the power level, with the least significant 7 bits carrying the level). I would like to point out to you that noise spectral parameters are sometimes byproducts of VAD algorithms. As such, by standardizing one, automatically, a certain algorithm must be used as a VAD. Both ITU and the ATM forum, as I pointed out to Mr Zopf, have decided in the past not to standardize VAD algorithms for G.711. I believe that any work in this area has to be done after a very careful examination of the implications of breaking the existing CNG mechanism and proposing a new one. Due ITU-T standardization procedures have to be in place and, if the decision is taken that such an alhorithm is required, enough time should be given for proposals to be advanced from the interested companies. Best regards, Alexander Tulai Mitel Corporation Ph: (613) 592-2122 Fax: (613) 592-4784 Email: alexander_tulai@mitel.com Robert Zopf wrote: > Dear Colleagues, > > I would like to commence the work on defining a Comfort Noise Generation > scheme for speech codecs without a built-in algorithm. The proposed steps > to complete this work as outlined by the Rapporteur of Q.19 include : > > (1) Complete the Performance Requirements and Objectives > (2) Draft preliminary test methodology and ask Q.14/12 for comments > (3) Complete the Test Methodology > (4) Collect candidate algorithms for CNG > (5) Performance assessment for the candidates > (6) Select a candidate and define the algorithm (Draft Appendix to G.711) . > > Because the work is urgently needed by WP2/16 and the IETF, the goal should > be to have a draft appendix ready for approval at the SG16 meeting in Feb. > 2000. The plan is to use wp3audio as the reflector for discussions. > > Please offer any comments or suggestions with respect to this proposed > procedure. > I will circulate a revised draft of the Terms of Reference for review and > comments shortly. > > Best regards, > > Rob. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Rob Zopf > Principal Engineer > Speech Technology Group > Lucent Technologies, INS > > Phone : (732) 578-3207 > Fax : (732) 578-3213 > Email : zopf@lucent.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Thu Oct 21 17:07:59 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14209 for ; Thu, 21 Oct 1999 17:07:59 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ePAj-00001l-00; Thu, 21 Oct 1999 13:50:53 -0700 Received: from othello.physics.gla.ac.uk [130.209.204.200] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ePAi-0007nA-00; Thu, 21 Oct 1999 13:50:52 -0700 Received: from a5.ph.gla.ac.uk ([130.209.45.103]) by othello.physics.gla.ac.uk with esmtp (Exim 3.03 #1) id 11ePAU-0000J3-00; Thu, 21 Oct 1999 21:50:38 +0100 Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with ESMTP id VAA04628; Thu, 21 Oct 1999 21:50:28 +0100 (BST) Date: Thu, 21 Oct 1999 21:50:27 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: Andrew Daviel cc: rem-conf@es.net Subject: Re: pruning required in mrouted ? In-Reply-To: Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello there... On Tue, 12 Oct 1999, Andrew Daviel wrote: > Is pruning absolutely required everwhere, I think the answer is basically "yes", though there might be some exceptional situations. I'm not sure what kind of multicast support your router is offering. I guess we both started this at a time when DVMRP with IP-in-IP tunnels was the only way, but there's all kinds of different ways nowadays! > or just at routing nodes? No, a non-pruning leaf node can do just as much harm, as far as I know. > I haven't been following the list for a while; I remember some push to > make sure no-one ran mrouted3.7. Even 3.8 is buggy, especially in the face of routing instabilities: NB those instabilities need not be anywhere close to the v3.8 mrouted - we found all kinds of leakage until we moved to the so-called 3.9beta3, associated with routing instabilities that, as far as we could tell, were entirely outside of the UK. > Would it cause trouble if we enable multicast on this router ? I recommend keeping a close eye on the multicast traffic levels if you try it. It's easiest if you have an SNMP-capable mrouted upstream, so that you can graph its multicast traffic to check what's going on. If not, then use mtrace to investigate the aggregate packet rates. May I suggest you contact me off the list if you're interested in this issue, and we can report a summary back to the list. Disclaimer: I'm not an expert in these matters, but I do know a few of them, and I run an mrouted myself for the Physics dept. p.s I get excellent results with a quite elderly PC dedicated to running mrouted under FreeBSD. From rem-conf-request@es.net Thu Oct 21 17:16:10 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14342 for ; Thu, 21 Oct 1999 17:16:09 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ePMl-0000W4-00; Thu, 21 Oct 1999 14:03:19 -0700 Received: from ns.mosaid.com [207.236.95.98] by mail1.es.net with smtp (Exim 1.81 #2) id 11ePMj-0000Vr-00; Thu, 21 Oct 1999 14:03:18 -0700 Received: from email.mosaid.com by ns.mosaid.com via smtpd (for mail1.ES.NET [198.128.3.181]) with SMTP; 21 Oct 1999 21:03:16 UT Received: from mosaid.com (MOP412.mosaid.com [10.1.6.234]) by mosaid.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA13023; Thu, 21 Oct 1999 17:03:06 -0400 (EDT) Message-ID: <380F7F63.45C9391C@mosaid.com> Date: Thu, 21 Oct 1999 17:02:27 -0400 From: Robert Wood Organization: MOSAID Technologies Inc. X-Mailer: Mozilla 4.61 [en]C-CCK-MCD MOSAID Technologies Inc. (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: alexander_tulai@Mitel.COM CC: wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: Study of CNG References: <4.2.0.58.19991021113628.00aac4e0@basset.eng.ascend.com> <380F63FC.D980FBDD@mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit alexander_tulai@Mitel.COM wrote: > > Dear Colleagues, > > I am afraid that proper means for adopting standards are under serious > preasure in the case of a new proposal for CNG coming from Lucent. > > At this point in time, the Comfort Noise Generation for G.711 method adopted by > IETF for IP networks (see RFC1890) and ITU-T for ATM networks (see I.366.2 > Appendix > I2) are identical (one byte representing the power level, with the least > significant 7 bits > carrying the level). Hi Alex, how are you? Sorry, maybe I've missed something but I cannot find the RFC1890 reference - which section or page number is it on? > I would like to point out to you that noise spectral parameters are sometimes > byproducts of VAD algorithms. As such, by standardizing one, automatically, a certain > algorithm must be used as a VAD. You don't necessarily have a DSP resource available for a G.711 application, do you? Either for VAD or CNG. > Both ITU and the ATM forum, as I pointed out to Mr Zopf, have decided in the past > not to standardize VAD algorithms for G.711. > I believe that any work in this area has to be done after a very careful > examination of > the implications of breaking the existing CNG mechanism and proposing a new one. What existing CNG mechanism (in VoIP apps, that is)? Many people just play D.C. which sounds terrible, I agree. But work has been done in a company not a stone's throw from here that produces reasonable results. [\] Robert Wood mailto:rwood@mosaid.com <---- note address The St. Lawrence River - fresh, warm, visible diving From rem-conf-request@es.net Thu Oct 21 19:01:40 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15542 for ; Thu, 21 Oct 1999 19:01:39 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eQzO-0002Ac-00; Thu, 21 Oct 1999 15:47:18 -0700 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eQzM-0002AS-00; Thu, 21 Oct 1999 15:47:16 -0700 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA28280; Thu, 21 Oct 1999 15:41:57 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 21 Oct 1999 22:47:15 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA14792; Thu, 21 Oct 1999 15:47:14 -0700 (PDT) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA16960; Thu, 21 Oct 1999 15:49:08 -0700 (PDT) Received: from aguilar_nt-pc ([192.168.59.116]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA21540; Thu, 21 Oct 1999 18:47:12 -0400 (EDT) Message-Id: <4.2.0.58.19991021175313.00c78b30@basset.eng.ascend.com> X-Sender: gaguilar@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 21 Oct 1999 18:47:07 -0400 To: alexander_tulai@mitel.com, wp3audio@ctd.comsat.com From: Gerard Aguilar Subject: Re: Study of CNG Cc: rem-conf@es.net In-Reply-To: <380F63FC.D980FBDD@mitel.com> References: <4.2.0.58.19991021113628.00aac4e0@basset.eng.ascend.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 Alexander, Please see my comments below: Regards, Gerard At 03:05 PM 10/21/1999 -0400, Alexander Tulai - icpd wrote: >Dear Colleagues, > >I am afraid that proper means for adopting standards are under serious >preasure in the case of a new proposal for CNG coming from Lucent. > >I would like to point out to you, that the "urgent work" is actually >urgent due to the presentation of one contribution only, from Lucent, >to the following ITU working groups: >SG 16 Q19 >SG 15, Q6, >SG 15, Q21 >These working groups are perhaps not the only ones the contribution went to. >The fact that Lucent wants it badly doesn't mean the ITU community has >to cut corners. Lucent is not asking the ITU to cut corners. It is simply requesting that the ITU promptly address the deficiencies associated with the current CNG scheme as outlined in RFC1890 for running VoIP within H.323 sessions. The primary problem is that there is no descriptor for shaping the spectrum of comfort noise. >At this point in time, the Comfort Noise Generation for G.711 method >adopted by >IETF for IP networks (see RFC1890) and ITU-T for ATM networks (see I.366.2 >Appendix >I2) are identical (one byte representing the power level, with the least >significant 7 bits >carrying the level). > >I would like to point out to you that noise spectral parameters are sometimes >byproducts >of VAD algorithms. As such, by standardizing one, automatically, a certain >algorithm >must be used as a VAD. The need to utilize the feature set generated by CNG analysis/synthesis by any VAD is simply not true. Although, it could be desirable depending on the feature set produced by a CNG system, it is in no way a requirement. Therefore, any design decisions made by the CNG will not impact any proprietary VAD. >Both ITU and the ATM forum, as I pointed out to Mr Zopf, have decided in >the past >not to standardize VAD algorithms for G.711. > >I believe that any work in this area has to be done after a very careful >examination of >the implications of breaking the existing CNG mechanism and proposing a >new one. We of course agree with this position and look forward to contributions within the ITU which satisfy this requirement. >Due ITU-T standardization procedures have to be in place and, if the decision >is taken that such an alhorithm is required, enough time should be given for >proposals >to be advanced from the interested companies. > >Best regards, > >Alexander Tulai >Mitel Corporation >Ph: (613) 592-2122 >Fax: (613) 592-4784 >Email: alexander_tulai@mitel.com > > >Robert Zopf wrote: > > > Dear Colleagues, > > > > I would like to commence the work on defining a Comfort Noise Generation > > scheme for speech codecs without a built-in algorithm. The proposed steps > > to complete this work as outlined by the Rapporteur of Q.19 include : > > > > (1) Complete the Performance Requirements and Objectives > > (2) Draft preliminary test methodology and ask Q.14/12 for comments > > (3) Complete the Test Methodology > > (4) Collect candidate algorithms for CNG > > (5) Performance assessment for the candidates > > (6) Select a candidate and define the algorithm (Draft Appendix to > G.711) . > > > > Because the work is urgently needed by WP2/16 and the IETF, the goal should > > be to have a draft appendix ready for approval at the SG16 meeting in Feb. > > 2000. The plan is to use wp3audio as the reflector for discussions. > > > > Please offer any comments or suggestions with respect to this proposed > > procedure. > > I will circulate a revised draft of the Terms of Reference for review and > > comments shortly. > > > > Best regards, > > > > Rob. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Rob Zopf > > Principal Engineer > > Speech Technology Group > > Lucent Technologies, INS > > > > Phone : (732) 578-3207 > > Fax : (732) 578-3213 > > Email : zopf@lucent.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Thu Oct 21 20:33:46 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16437 for ; Thu, 21 Oct 1999 20:33:45 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eSWh-0003Uw-00; Thu, 21 Oct 1999 17:25:47 -0700 Received: from altbier.cisco.com [171.71.154.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eSWf-0003Uc-00; Thu, 21 Oct 1999 17:25:45 -0700 Received: from lsun-nt (dhcp-71-133-204.cisco.com [171.71.133.204]) by altbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA19044; Thu, 21 Oct 1999 17:24:11 -0700 (PDT) Message-Id: <4.1.19991021172415.00b60460@altbier.cisco.com> X-Sender: lsun@altbier.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 21 Oct 1999 17:24:28 -0700 To: Internet-Drafts@ietf.org, IETF-Announce:; From: Larry Sun Subject: unsubscribe Cc: rem-conf@es.net In-Reply-To: <199910211049.GAA13539@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 06:49 AM 10/21/99 -0400, Internet-Drafts@ietf.org wrote: >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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio > Author(s) : R. Finlayson > Filename : draft-ietf-avt-rtp-mp3-00.txt > Pages : 7 > Date : 20-Oct-99 > >While the RTP payload format defined in RFC 2250 is generally applicable >to all forms of MPEG audio or video, it is less suitable for MPEG 1 or >2,layer III audio (commonly known as 'MP3'). The reason for this is that an >MP3 frame is not a true 'Application Data Unit' - it contains a >back-pointer to data in earlier frames, and so cannot be decoded >independently of these earlier frames. Because RFC 2250 defines that >packet boundaries coincide with frame boundaries, it handles packet loss >inefficiently when carrying MP3 data. The loss of an MP3 frame will >render some data in previous (or future) frames useless, even if they are >received without loss. >In this document we define a new RTP payload format for MP3 audio. >The new format is essentially the same as that defined in RFC 2250, except >for a data-preserving rearrangement of the original MPEG frames, so that >packet boundaries now coincide with true MP3 'Application Data Units'. This >new format is therefore more data efficient in the face of packet >loss. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-avt-rtp-mp3-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtp-mp3-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. >Content-Type: text/plain >Content-ID: <19991020133259.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-avt-rtp-mp3-00.txt > > From rem-conf-request@es.net Thu Oct 21 20:54:38 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16649 for ; Thu, 21 Oct 1999 20:54:38 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eSsX-0004GT-00; Thu, 21 Oct 1999 17:48:21 -0700 Received: from athm-209-218-xxx-130.home.net (grumpy.omneon.com) [209.218.172.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eSsV-0004GI-00; Thu, 21 Oct 1999 17:48:19 -0700 Received: by grumpy.omneon.com with Internet Mail Service (5.5.2448.0) id ; Thu, 21 Oct 1999 17:46:52 -0700 Message-ID: <3A54A80C464CD311BAAA00A0C9C85E6704532C@grumpy.omneon.com> From: Bill Nowicki To: rem-conf@es.net Cc: Bill Nowicki Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt Date: Thu, 21 Oct 1999 17:46:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Generally the protocol is very nice and simple. However, the document has some minor problems. There are two spaces between "Carsten" and "Bormann" on the first page? Be consistent about "IEC 61834" having a space between the letters and numbers. Similarly, "IEEE 1394" is the convention, not "IEEE1394". Also put a space before open parentheses consistently. The designations "D-7" and "D-9" are tape formats. They correspond to products with the DVCPRO and Digital-S trademarks respectively; is the policy to avoid trademarks in IETF standards? If not, mentioning them might be useful. The professional 25Mbps variants are generally the same DV stream, just on different physical tape, so it is not clear the full matrix is relevant to an RTP payload, but I suppose it does not hurt. There are some subtle differences in audio support, 625 line color model, etc. Might mention somewhere that SD-VCR stands for "Standard Definition Video Cassette Recorder", etc. I do not know exactly what "SDL" stands for, since nobody uses it that I know of. Section 2 and the first paragraph of section 3 have many English errors, and are redundant. Suggested rewording: 2. Introduction This document specifies payload formats for encapsulating both consumer and professional use DV format data streams into the Real-time Transport Protocol (RTP), version 2 [6]. DV compression audio and video formats were designed for helical-scan magnetic tape media. The DV standard for consumer market devices, the IEC 61883 and 61834 series, includes many aspects of consumer use digital video, including mechanical specifications of a cassette, magnetic recording format, error correction on the magnetic tape, DCT video encoding format, and audio encoding format[1]. The digital interface part of IEC 61883 defines an interface on an IEEE 1394 network[2,3]. This specification set supports several video formats: SD-VCR (Standard Definition), HD-VCR (High Definition), SDL-VCR (Standard Definition - Long), PALPlus, DVB (Digital Video Broadcast) and ATV (Advanced Television). North American formats are indicated with a number of lines and "/60", while European formats use "/50". DV standards extended for professional use were published by SMPTE as 306M and 314M, for higher color resolution and faster bit rates[4,5]. IEC 61834 also includes magnetic tape recording for digital TV broadcasting systems (such as DVB and ATV) that use MPEG2 encoding. The payload format for encapsulating MPEG2 into RTP has already been defined in RFC 2250[7] and others. Consequently, the payload specified in this document will support six video formats of the IEC standard: SD-VCR (525/60, 625/50), HD-VCR (1125/60, 1250/50) and SDL-VCR (525/60, 625/50), and six of the SMPTE standards: 306M (525/60, 625/50), 314M 25Mbps (525/60, 625/50) and 314M 50Mbps (525/60, 625/50). In the future it can be extended for other high-definition formats. Throughout this specification, we make extensive use of the terminology of IEC and SMPTE standards. The reader should consult the original references for definitions of these terms. 3. DV format encoding The DV format the DCT compression technique only within each frame, contrasting with the interframe compression of the MPEG video standards [ref]. "Audio data part" should be "The audio data" several DIF sequence. should be "several DIF sequences." Section 4.1 "in VAUX. Because" should be "in VAUX, because" ... Even if VAUX data is received, the receiver cannot obtain the attribute until the video encoding format is determined. This sentence is confusing, and I think is just trying to say what has already been said - use payload types to determine format, not the DV stream. It is ambiguous, however, in the bundled case, if just changing the audio format counts as a payload type change? Looks like "no" in this draft. Section 4.2: It is not clear if Header and Subcode DIF blocks may, should or must be sent? How can the sender omit AAUX blocks in a bundled stream? If so, then all the audio information must be specified in ugly "a-encode" lines like the previous draft, but those are now gone? So I would say remove the reference to AAUX here. They are not separate DIF blocks anyway, but embedded in the Audio blocks, so just passing them through sounds like the best idea. Section 5: ... SDP carries several m=?? lines which is for media type ... should be: ... SDP carries several m=?? lines, one for each media type ... Section 5.2: "Too many audio formats" omit "Too", please be objective (thought I agree!). flame --> frame Reword middle of paragraph to: ... These attributes are carried as AAUX data within audio DIF blocks. Describing all these attributes with SDP would require large SDP descriptions to enumerate all combinations. Therefore, the SDP entry to describe bundled streams does not include audio format parameters. Does it include video format parameters? MAY? The example uses "encode:" instead of "v-encode:" why be inconsistent? Looking forward to implementations, Bill Nowicki Omneon Video Networks 408-558-2126 From rem-conf-request@es.net Thu Oct 21 23:12:04 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20072 for ; Thu, 21 Oct 1999 23:12:04 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eUre-0005gW-00; Thu, 21 Oct 1999 19:55:34 -0700 Received: from lame.delegation.to.rip.psg.com (relay.lanka.net) [202.51.128.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eUrb-0005gE-00; Thu, 21 Oct 1999 19:55:32 -0700 Received: from lanka.net (namal.lanka.net [202.51.128.16]) by relay.lanka.net (8.9.3/8.9.3) with ESMTP id IAA12637 for ; Fri, 22 Oct 1999 08:54:26 +0600 (GMT) Received: from 202 ([202.51.130.34]) by lanka.net (8.9.3/8.9.3) with SMTP id IAA02907 for ; Fri, 22 Oct 1999 08:54:22 +0600 (GMT) Message-Id: <199910220254.IAA02907@lanka.net> X-Sender: chayan@mail4.lanka.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Demo Date: Fri, 22 Oct 1999 08:52:35 +0600 To: From: CHANDRAMOHAN Subject: Re: unsubscribe In-Reply-To: <4.1.19991021172415.00b60460@altbier.cisco.com> References: <199910211049.GAA13539@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:24 PM 10/21/99 -0700, you wrote: >At 06:49 AM 10/21/99 -0400, Internet-Drafts@ietf.org wrote: >>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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio >> Author(s) : R. Finlayson >> Filename : draft-ietf-avt-rtp-mp3-00.txt >> Pages : 7 >> Date : 20-Oct-99 >> >>While the RTP payload format defined in RFC 2250 is generally applicable >>to all forms of MPEG audio or video, it is less suitable for MPEG 1 or >>2,layer III audio (commonly known as 'MP3'). The reason for this is that an >>MP3 frame is not a true 'Application Data Unit' - it contains a >>back-pointer to data in earlier frames, and so cannot be decoded >>independently of these earlier frames. Because RFC 2250 defines that >>packet boundaries coincide with frame boundaries, it handles packet loss >>inefficiently when carrying MP3 data. The loss of an MP3 frame will >>render some data in previous (or future) frames useless, even if they are >>received without loss. >>In this document we define a new RTP payload format for MP3 audio. >>The new format is essentially the same as that defined in RFC 2250, except >>for a data-preserving rearrangement of the original MPEG frames, so that >>packet boundaries now coincide with true MP3 'Application Data Units'. This >>new format is therefore more data efficient in the face of packet >>loss. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-00.txt >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-avt-rtp-mp3-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-avt-rtp-mp3-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. >>Content-Type: text/plain >>Content-ID: <19991020133259.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-ietf-avt-rtp-mp3-00.txt >> >> > From rem-conf-request@es.net Fri Oct 22 00:54:33 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21521 for ; Fri, 22 Oct 1999 00:54:32 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eWQu-0007Gs-00; Thu, 21 Oct 1999 21:36:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 11eWQs-0007Gf-00; Thu, 21 Oct 1999 21:36:02 -0700 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Oct 22 00:35:55 EDT 1999 Received: from dnrc.bell-labs.com (arrakis.dnrc.bell-labs.com [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA08326; Fri, 22 Oct 1999 00:35:55 -0400 (EDT) Message-ID: <380FE9BE.B05E655@dnrc.bell-labs.com> Date: Fri, 22 Oct 1999 00:36:14 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: RTP spec questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Stephen Casner wrote: > > AVT working group: > > I have a few questions regarding changes to the RTP spec. I'm > interested in any comments you may have now, and we can discuss these > at the upcoming meeting as well. > > 1. At the Oslo IETF meeting, and as reported in the minutes of that > meeting, we agreed to change the representation of the loop/collision > detection algorithm to pseudo-C. This was part of the question, when > a new source transport address is seen for a known SSRC id, whether > packets from the old address should be kept and from the new address > ignored, as is currently specified, or vice versa. The motivation for > changing the spec is to accommodate mobile hosts that may change their > address. Since following the new source requires hysteresis in case > there really are two sources colliding, I propose to not add any > additional complexity to the pseudo-code algorithm, but to add in the > text the following statement: > > For applications in which sources may change addresses, the RTP > implementation SHOULD modify the collision detection algorithm to > accept packets from the new source transport address. To guard > against flip-flopping between addresses if a genuine collision > does occur, the algorithm should include some means to detect this > case and avoid switching. The problem is that your RTP implementation above may not be mobile. It may be just a normal host talking to a mobile. In this case, the normal host does have to implement this modified collision detection algorithm. So, how would a non-mobile host know which algorithm to implement? > > 2. As discussed in August, if a source has not been sending data for a > while, so it is sending RR's with a fairly large interval according to > the receiver fraction of the RTCP bandwidth, and then it begins to > transmit, it may be quite a while before the RTCP interval expires and > the first SR is sent. The change is to add a statement to 6.3.8 that > a transition of we_sent from false to true SHOULD trigger a "reverse > reconsideration" recalculation of the RTCP interval. Yes. > > 3. In scenarios with one or a small number of data senders and many > receivers, the sender's RTCP interval may be much shorter than that of > the receivers. Therefore, 6.3.5 on timing out an SSRC needs to be > based on the RTCP interval using the receiver fraction rather than the > sender fraction, even for senders. Yes. > > 4. In Oslo we decided _not_ to change the calculation of avg_rtcp_size > to include only the RTCP packets being transmitted and exclude those > received from other sources, even though there is a potential for > unfair use of RTCP bandwidth, because it would complicate many parts > of the algorithm without a clear gain. Agree again. > > A related question has occurred to me just recently: If an RTCP > compound packet includes information from more than one host, as in > the case where an RTP mixer aggregates SDES information from multiple > sources, should the size of that packet be divided by the number of > sources before being figured into the average? Good catch; I believe it does need to be divided in this way. Otherwise, if the packet size is more than 5 times the average size, there will be constant timeouts. Basically, the inverval between appearances of data from a particular user in the mixer must be the same as if they were not being mixed. So, if a mixer mixes 3 people, the interval between RTCP packets containing data for user 1 should be the same as if user 1 were not in the mixer. Hmm; another way to divide this is to actually allocate N times the bandwidth if N users are being mixed, but don't divide the packet size by N. I think this is more or less equivalent to what you suggest. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf-request@es.net Fri Oct 22 01:07:25 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21927 for ; Fri, 22 Oct 1999 01:07:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eWgF-0000bg-00; Thu, 21 Oct 1999 21:51:55 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eWgF-0000Wy-00; Thu, 21 Oct 1999 21:51:55 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA07512; Thu, 21 Oct 1999 21:50:52 -0700 (PDT) Date: Thu, 21 Oct 1999 21:52:23 -0700 (Pacific Daylight Time) From: Stephen Casner To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: RTP spec questions In-Reply-To: <380FE9BE.B05E655@dnrc.bell-labs.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 22 Oct 1999, Jonathan Rosenberg wrote: > > For applications in which sources may change addresses, the RTP > > implementation SHOULD modify the collision detection algorithm to > > accept packets from the new source transport address. To guard > > against flip-flopping between addresses if a genuine collision > > does occur, the algorithm should include some means to detect this > > case and avoid switching. > > The problem is that your RTP implementation above may not be mobile. It > may be just a normal host talking to a mobile. In this case, the normal > host does have to implement this modified collision detection algorithm. > So, how would a non-mobile host know which algorithm to implement? Right. I was attempting to distinguish by using "application" and "implementation" that all nodes, both mobile and non-mobile, which participate in an application like IP telephony where addresses might change on the fly are affected by this consideration. Would "scenarios" do better than "applications"? > > A related question has occurred to me just recently: If an RTCP > > compound packet includes information from more than one host, as in > > the case where an RTP mixer aggregates SDES information from multiple > > sources, should the size of that packet be divided by the number of > > sources before being figured into the average? > > Good catch; I believe it does need to be divided in this way. Otherwise, > if the packet size is more than 5 times the average size, there will be > constant timeouts. I'm not sure that's true. Everyone should be averaging over the same set of packets, so the intervals should be roughly consistent. Well, execept that the estimator gain is 1/16 so it could bounce around if the big packet was only one out of many. My concern was more that the average would be wrong -- too large, which means intervals longer than they should be, which is the safer direction. -- Steve From rem-conf-request@es.net Fri Oct 22 04:13:32 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04063 for ; Fri, 22 Oct 1999 04:13:31 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eZZS-0002ka-00; Fri, 22 Oct 1999 00:57:06 -0700 Received: from hemul.nada.kth.se [130.237.227.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eZZQ-0002kQ-00; Fri, 22 Oct 1999 00:57:04 -0700 Received: from localhost (nv91-tob@localhost) by hemul.nada.kth.se (8.8.7/8.8.7) with ESMTP id JAA17356; Fri, 22 Oct 1999 09:56:59 +0200 (MET DST) Date: Fri, 22 Oct 1999 09:56:58 +0200 (MET DST) From: =?ISO-8859-1?Q?Tobias_=D6brink?= Reply-To: =?ISO-8859-1?Q?Tobias_=D6brink?= To: Bill Nowicki cc: rem-conf@es.net Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt In-Reply-To: <3A54A80C464CD311BAAA00A0C9C85E6704532C@grumpy.omneon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by hemul.nada.kth.se id JAA17356 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04063 On Thu, 21 Oct 1999, Bill Nowicki wrote: : : : > Looking forward to implementations, There are at least three implementations under way that I know of: http://www.sfc.wide.ad.jp/DVTS http://www.it.kth.se/~nv91-tob/Report/Prototype/ And Carsten Bormann has something brewing. I have no pointer to that work, though. /Tobias ............................................................................ Tobias Öbrink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: tobias@it.kth.se URL: http://www.it.kth.se/~nv91-tob/ See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html From rem-conf-request@es.net Fri Oct 22 04:34:44 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04179 for ; Fri, 22 Oct 1999 04:34:43 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eZzv-0003iT-00; Fri, 22 Oct 1999 01:24:27 -0700 Received: from dokka.maxware.no [195.139.236.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eZzs-0003iJ-00; Fri, 22 Oct 1999 01:24:25 -0700 Received: from alden (ALDEN.maxware.no [10.128.1.84]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id KAA24818 for ; Fri, 22 Oct 1999 10:24:21 +0200 Message-Id: <4.2.0.58.19991022100954.0172f1e0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 22 Oct 1999 10:11:19 +0200 To: rem-conf@es.net From: Harald Tveit Alvestrand Subject: Fwd: Liaison Statment to IETF (SC 29 N 3290) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_508417375==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_508417375==_ Content-Type: text/plain; charset="us-ascii"; format=flowed The attached comments to the MPEG RTP spec were contributed from our liaison with ISO SC29. They are forwarded without much comment from me. Harald >Date: Fri, 22 Oct 1999 14:29:06 +0900 >From: Narumi Hirose >To: Harald.T.Alvestrand@uninett.no >Cc: Barry , Leonardo , > kogure@drl.mei.co.jp >Subject: Liaison Statment to IETF (SC 29 N 3290) >Reply-To: hirose@itscj.ipsj.or.jp >X-Mailer: Becky! ver 1.25.07 > >Dear Mr. Alvestrand, > >In accordance with Resolution 2.8.3 taken at the forty-ninth >ISO/IEC JTC 1/SC 29/WG 11 meeting, 1999-10-04/08, Melbourne, >Australia, I have pleasure in forwarding the liaison statement >to IETF. > >SC 29 N 3290 [SC 29/WG 11 N 2987]: >Liaison Statement from SC 29/WG 11 to IETF on MPEG-4 on >the Internet >Attachment: SC 29/WG 11 N 3021 >Study on Internet draft for the carriage of MPEG-4 on IP > >Should you have any questions, please do not hesitate >to contact me. > >Thank you for your cooperation. > >Regards, > >Narumi >=============================================== >Narumi Hirose >Secretariat, ISO/IEC JTC 1/SC 29 >IPSJ/ITSCJ Room 308-3 Kikai-Shinko-Kaikan Bldg >3-5-8 Shiba-koen Minato-ku Tokyo 105-0011 Japan >Tel: +81-3-3431-2808 Fax: +81-3-3431-6493 >E-mail: hirose@itscj.ipsj.or.jp >=============================================== > --=====================_508417375==_ Content-Type: application/x-zip-compressed; name="29n3290.ZIP" Content-Disposition: attachment; filename="29n3290.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAFddVSdquHy19CkAAAC6AAAMAAAAMjluMzI5MDEuZG9j7Z0LnBxVne//PZk8htAk hIeAEA4jhhky05lHEpKBQCbzSCZkHsx0AmyIsaa7eqagu6qpqp7JaO794C6+kI+Liiui7upd9Lp6 VXyse0Ue6uoK6q6sH/244IqIb/UiAns/V3GZ+/ufc6q6+jUzgejG3T7Jd7qr6tQ5//M+53/+Vf3w 1099/H0fP+f7VOYup2X0/HwTrYici4FrgoO1RH+izz0/Pz/Pp64G83X3R+V++f7P043UdDIRjT8Q lixcI9G1SaJTaPL6yev9jf5GqnBNjWdS8wzRmb0xybVjlX6ibn5+zaLfA3dI/l0Ro/Az+r3W5+mR EL4QW/yTk/1P+ExHztunEl2M75c3qOMX+tmNcPjrllPV8VI+L8TnHeuInkX8tyIx9+D4Wpw/gypd kO4gvooWvIh81+p471xdPT/Lwy2/P7iv/JOvdy2vDKf8uFvHX+7Ogb8kl4P+XKzcy8OTciyPyLWW aD0+/wWfE1Xuf6EuiC+Iv6tB1afHb3/o2dxLH4iV17f8SqKLG4k24r5VNUP9Q7uhkeTA+Ehvcmh0 pHefGB3f3TsyNCEPxeDouJhI9o70947363PxEg8l9w6I/gExMjo+3Lsv8Dw0MbppaKBP7E32ic5N E32ia/umq3eLzs5432j/0MhuMToohkcP8Lexob7k/vGBCYHoRO/+/qHR2neLke6Ors74aMp3Jk1X dG7fvj0eT1p+1uwRE34hPSccWwzZvunapi/SrpHxRcZxhT9tipThupYxZQonI4bHBna3b5aex+IT TsFNcQBznm/mvPiEb/gFr0f05vOuM2OmEQNuzzjZrDNr2VPCN4/4YtrwxKRp2gJ+8o5npgVO4IJp exaCRRwcZ/N4ckyMGXNZx0iLQcfNGUoeHf+E75pGzmtWkrZbpp9pN2b8dtfPt+fy5tTm9o7OhH/E T8TjQ5EoXTPlTNnWqxCpP40QOZK8jiQjI/FkLK4xG8RkZs2cafuGOyc8FanIGXMIDv9tM2OlLCMr LFt4Ts4URj6ftVKGzwnxUqZtuJbjqajSjrAdfJie5ZrCd0TBM8PUqPzDWSfrtQmvkJrmTOEQTL4j 5Vp5GSZEcyavN1N+eNZxvYTgXA5z08ubKSsTSjHtFLJpFtewjewcp9yw08LKqRIS1zuW7Wc5Pf4s 59DQQHJQ+mDRhHkkb7q+l4jHTz44FkTgmjOWKip7sexfYikeisfjoqU3nZZFX6wvecM1plwjPy1w H1+aNKcs2+ZLTkZ0J5pLg25ujcd7iyWgM37WsH3O75xxgykzXdewoKl0bt68fWt7p0gZeWPSylq+ ZXriYOehNmEmphKV+S1zp6Jo2mTQHG5lnYK/jGWbaa4m3YnOhIjHW4adGVMMWlMF1xRdLJ6HWDhT 4QHJaOmbNuwpFaDPrZSljnjhOzKukxNv4+j2mEbadBGcmU17Yr9nTJm3s49aF2UZTOyDmKkbTF82 B1W3b+eoFyqH6wueLyZN3G9qSWtnOGeI7QgHYbmluS18MzVtO1lnak6YR1Jm3i8rjS7R0qzryAHL KxjZ5lau+6Weuoueegtpy4GftOEbYTPl+BcrjC5Zmt2J7oQYsiG+5YmU4ZltwhAZpJlbPue8Ifqc XN41PVnv9xlzSNGk5auYxMSe3n37uImlLddMcWvKGfm8jMJ3cK8SgrNaNVU+nlalklGlUpClwqLI jNcxqxbsFrLmQl2xyqCiOF7YfIOMKbnmBtV2siIP2gRSmOdKNmNm57iaxqtWB10PPVUbjIyPhKjK wIGpJq8qlkpBbVl5gLC8sGLrrsv0ajWk2WnTLgsr5dg+lxKCCbNf5hKS58xAMg5m1vKnnYIvCh7L X9brRhs+J/pqjoQF8KYd1xczVtp0gvLKOWmToyp4ZrqtmoRcUHsSXVu7w8TIXObgXDNrznDbGB/s 82RXLluG5xt22nDTnhjuvZZrEYctM79DVLrOKue6qpzrxt2duNItNostYqu4RGwT28UxnItvbH+R /+JHD+zoOjp29JqjQvT1Qaajw0elbGNJJeNRLatn3lgw7ZQp7EKOJyeBO8oZfDzkqJI/gfOtnOn5 Ri6/gJ+jug89zqJ4c3Zq2nXsoJl4cjYlWiYmxvtahZU2bZ/rj1siSnzjjhf5rzQ7uPm41mTBlw1b S9BXJoFXmh0LZqgQCbgFPRz/VLwApypXEEppn6L79ZbJOd8URtaass10a41Q9BTkxcuzaAjHVruq uZ5EIjE6ppctqvNKp7ngi+Vy7HW6TAYZkJ7YHBHtoteOjH/RyV9JXsfl2JHorDk2VtwYjweTv+Rc 3hQtY8lWdUfQPfMMumykk1Ov+EC41mi5ppXHoh7Rr+cEk3PFkcd1MlY20htPBL3UiOylesSQnXLl 2oBvc2wlo2mkpuX9ciqiU+3BU0IM+dzXu74nhyNhCNew004Oolk+LyJmjGxBBeKZqYJr+XPCNQ3P seWoFB823BtMV7QMa5l5JpFT53As5DAq510symwwhkXynpu6YdlqcMVBhgtJdT2WrYYvmSmeaYqt sjCaJ1he+E2bXjMP42WztINdh1rbxG7XKeQPO5nDB3ikHJXz5bGsYZstuIgkbtJzl4zlen7ptIpj 9l2jnWNIiwOjYwkxyoPirMVzMJ2eV5muI3NAzhV0WmUJ46Jlp3n2aaqpZ1mK4c8QeV7h6FWdzG8j lTI9r02Yruu47bwknDHdOT03qBRJpkFob3IVu1D2KUGDQUWVUnGMCaQNyiCXdzxLBsF+2oTOKZ5p hvM/vsLV1xC20x7cAo9pk0V0ufLpVmywWDyd8IOkOpmMp1tdZZ0a5LWMnt7oVU6ei61NqCxOFxvF jJM/zHIctsI63wKRCrble1yQnZsqfRxGIpxsQQ1tkNVOe62IoKDTXsgVskjgTDjqI5jZaSdrBp4j EyhIkHPShaypopg0PD1Z5iPOBb55gWoorEyQp3qeb8ppPt9msc4ja6QQjcwKnvofGB2TWWl5KnlZ yzY9td7yZ52gYwqm60st3mDhqdsBBwJpMjWbqWPzVLZmO9Uta8HWt5AYXmFSTbx8mV49SU05sio5 Llct3c4SIr7fzppeWZEYtnAKfruTaZ/krMiZhu2pKCMlryOL5FHYT3HdSZsZo5D1VQc7Md7XxjNF Do2nIGFGu2b1Hn18sE90btu2XRzcciihh5AuMViyfFpo8dEb9kZmupYvFlgv58L1hcPruvIlSrDG MGzVIIPYzSO+a5SNadwZmTlnBhHJbnAuHA3nIPeRQOmkVTvFlRevBT2pZZoLl4Qlq0WpW+hsFb1B hDr/a1ejTMFOBfVpwTYUrnLzqrVUU8mU50lLZIXol6x85Xq+7GqpyDIrIFrKyCK1hXwel7Jy5R2I LBPb1cptiMc8BJhjvYQKhnWKFoK37HKp2irEDJKGlKixeTFppq2paZMbcVSS7ki2qxBHRpOcYV4+ yz2qUgbkswXXyHJHjJCLzV6O8S2bW0Vy1glTcmB0zCvme6SuyrDSViZjutx+I8EIz1FDIedIaa8S dmecHjk94fmtJwzPc1KWweGqiYns2G8sVBuHWmTYQT8nR+DS5q2nYBWTD13qCSRyC+cTD7ZZU48+ 2s/EntH9+/qPMde4gXjWq2S3ZlQNj3Wfaa5qrOZi1Wo4VUDyClm58imdNLCiNmu4U7JeGiotecOf bh9O7pdd1R7TNdtCnQB3fFWqzOJtzhMtqt2rlhbMMLnnjp4vP5b6p5bW1nAEMm3fnQsmOmHYGTm+ V+ivWxYcMaqdk5l6WM4NDnMNOSwVI4dVatnDsOlNF0UdNFJmcKTHoGLGTDmTh7NKfjWx0oHLvA+D lJnMvXm3GDhi5PLc6+HmiL6yZp/exxU9HczUDL/MZzB15A5PzMKjmDFcy1QVyzb9Wce9QQ/1njlj urjlysm8pxTI9pwYxkGbuj5VMFzD9nk0DG9UDSibczxfzy8zrinV/TlnkpcTpT65H1H+hGv44cyr uFEgW5jq730HgXD1dU2k1VKdtmNX0RhmrRtMpK5aE/OmjWwWAs4ac7wlEoxsMje0/6i2clQFrxRV 04ad5tlRymBNlueJnJm2DFGwjVkeoUtlmLUQT8pgHWzanHKNtBGdDugkI4lZy7RTc2FN5pnErJX2 p4WZ4b0VvqgHwZLgU67lmy5iL9dlsjaThcmaR6xJpGayIOcaai4ro8hZtpUr5PRYimt515zhXlRe NA1bZoPnlcXIIznvB8huyVfTbV2tZR8V6cZ5Yq1yXc+mVEYF2zqsHuwUwXq2c1OXaiPBnMHIBv71 Rk50TazqjpnJBFpatbApLk6kjIbIWym/EI6FkMN1C3m5UNUVIet4Hqs79zizXM2lCK5UbRp2efGY YaeiumBLtrCyhuU7gRhhbHog5vJDuKVhpBBNysnl5CRXKz25GiKtm4bGgmbC2TVrco31dCUM2k9C tOxJdHV1b1Ltqk1J07UpOdEmTD+VaOVK48qNikjabIc7QYdnUnIVFKkaZVqJIO/V7K1CKyE7KK3l 6GZF8SzPN4o9VXREnjJt05WjJS9c0kGbXagKx+MtRmtQGCrY0tVDZLxS62gt/owSXy/nAsWqLoFj 0gMkRG8q5biy/upRXkvMOoLOio696kB2YCKc7nH8S544toUdQjCZK4tBXq8cEw+M6hvaxIHRfWHc agItLLnOaJksz9myqYocNcJMqj1a7h490Mqr6HB3u3oWwduxJV5qiqTqYtbwfFNXp037+2XLCHJ8 xnT5K5dNUMFKtpqCFMg4uJEZUpLZacczRda0p/xpjuQSNQlMRJtLCyuuXK5ZrWU7P3JhbNiRVYCe 6XlGriQPefd62pnlGiVaJuV43pKqzHc9Ty0ZosKKKsd52beWzmUTItyhUSfauTOTA2iQmwU7bbrZ ORY56EkQLI+2bWqT7wbLTkdnFLr6e7IPy+VM3B+Wg+oxsnPRa2rH1uc+cs5OHVZ6uMNpyzN40MHF jiBnivWQT5u29KDmo4EajL2VjtJIekIMzCCVCyjygjrHhRKMRLwJ5qUMN62X6NHuvi0ylkf7J12g Sp8kb1OqMPa9Z6CvRW8gF9WmffDXWjKh1WktSYQSKSFGnBqdqOyQTdbFGa7cbWxJV60hcikk5+Hl dUWpBharLckFCzwcS2WRGjOqOwibV7XG57E+SbZiy29fvNplndnIOGv5am6UNlM8BpmV9bg4K5o0 1Qwqx6uUfNlcTu/llhZ3xRxOlryaQUH0GwssbVHhVhqeVDJGG7Hug6OhqY4jbeZNfbGiCYZTuUUz R86V1Bi6eZExNO860xZCLOrow+FTWoJ04R+HVj5lK52jhfkYCbpNTZdbjNY2VTA8+ZYdptRkBiW0 SIXgaaaR9ZzSYi2f5pb0smqqXzNhPIR0t4b70SnH5hW3bcip50JNosLooC3aQwRT0/IVl14ZcOIr OveclU4XJyAlI1Vy2ixrUio31RjLoRk8dlRNXVerbpus1dc1vcb6ICHtLwy9qLPCeqJWUeE8rCXF Y+6sU6WdhAsdnsvAR7RyIZmTDsJhlXD1KXGoa0mZoaVU7XYbGaCULrtMvQDvfpuKslTQTtl41AqG PYVKWa2rDhsL5+8sS2doNXFJz9sVRFLjfplRXLN6a4wqpdWLtVBBK+EMLi1YORNW25PSVf+Q81m5 5Sq3/Q9MqI9R/uARUhyVYRxV1bH6xxJiqfSiD6Juo5wChsLwrOionNwJPbeU07tSgUTUXqFk13Zp MdaWXR8sfFVOnkKJuTkHIo/JwjsqoplbcbVa3vIp1hTrhFW72tVaK43HJvyi9y/1nJwhLJTQpZ6r lSFBjlTNhui57qVmzZKTFm8KW2eJzqvYQhfWe1WRpFbxVM/aSAMdlGvMaSObgQSRurXPiJyunaEy x/V4E61b0fMqu2u3omMTfrFiWCCkBSrbZEWbEyU5oxIXVsdo7hxDQ4x64PoXybCKSy+kdb6gtC8l 0AWv1O6xSjrZ2ldqNtFIv1XaKCOZstR8WTgJxclpqRa6OGWLNk6t2q8wcIm2UVZqdy9oIVlmsBmP l21X83e7kM0WzXdDjUeJ4Xe40TM+lqzcDwmsJ3zXsL08WzlWjz6YQOzrTQ6Lln3ObHs4Dy65IVkM R0+xj7Rqi8iD2w8lZLK1cY+uzcpiWz0gIENXurEaYmjjSrbjN2xhyKvB5l2zPBwuHBlQOx3NxRna rCON7GYdNx2sgUr9iuH9E8mIHnxpO7xlW7flYZbt4ZboQnSN2pL4jzbvFPETwL6TM/d4yFElg47J vrNu3vmfz7yTrTt7Kk6Xt9WFTTx7jp9x53EyrAxc0I8sZGCpOlH5AJRUbN5YkBuKgd1IeVaUGtNF tb5RTV8Nu59EPM4WBWyKOaaMBgakprNHGTjxIj+qLvTE6EhbhQTK0sGyU9lC2lSWeOngOSY2+2sO omjWigNpC1hicyXNGnw2COXOuSx83DE7bUr9Z7Nn+oV8P3w3Bx01q0aadVePm8LziXitJAwOVqah ZHOlGFoxsLjUbYy5jq8eegjyKVkRQ5iwQGilFcmHt4b2WfH4YMFlL7lguytQ1OlJQEVO2Nr2IzQu qagePCi3q0FZjbfa3lBnvQ5fP7LAisVs0XSmNPLSrY0aAnkV5i3B9nuJrq7MdLAYESuvojqdsmcp eP6hHk2p8jhUTVNiXSqLmxUvbp0bFmZ5yiedAj/+YZletFKXGPNK2wP3hpqGgsGUKBKqLsSsUWlx W+Y18Yc1V0Uig+CVYq58U0VaHBt+0Tx6AbPoYzbKXpI99sIRvlgjRa6J3TVtFCun/9oUl41Bgr2l fEFtm5UXOlvIRZ8zC82iKusHwvTlI1II7njbR4XdpfKYdzyPTTHaqjZ83U4jjd9IpVzWpwbtP2jR JZvnZSaRgdljSf89O20hMVHDt2AiH07NK2Ov1fUsxa4uaoRYHlVC9JafK7N3KwqB1IjAsLFanpXb 8tU2NIsMc22LeC2xWIzIoletmxMCye6rvXCdxPlZw02L1LRh2yYbsXjcuXoLPuOnHu6Qaq6+Yl77 jnyET+0YyICdKgFHDCuKG5bRdrQpWIFXD4FviRqlQCb9zO/IwNVj4wP9Bzs7DiVKJSt7qC+SLpV/ oyP7wnFH7d2q3rxoMan3QYLHS7gbyZozECoy2dGG2GbKE9O8IylbZZmoCdEiZe1Nzxg2b9aMm0gq d65iwpJ7Izr1YyomTkxrXC24Fysy2ZlJ3UDO8v3AMKeYDZeKeKkxk7wo1xpOscEe3HYoIUT1GHVM oV+1v6Ls6myuk9nSfLdsEQ+6pTkpHnctURH1ej16c9r0fMvWWRpqKOJGOu1K+y6naJTs6Ud7W1Sn YXHb8k0exeSeYYrHUX1fKydqyPZ8U5sSe2YxXdEtJx5lihqFGWkqp0JSTxIg6njwEEdgYaOGSNl7 R6WXgmt5PbMipyFuPLTCkH7DLlwFX/CknS9vEKs1YDHAIAuDXj7ewnPo1qI9W5khlVcsNP0ehJS2 uDTToplN6VzPbBbxMhkT8Xivp59Q0WN2W43UcLAlZmGyHdlyzy6es45IcyAtedbgNyCohzhm+JF8 qzgaFbM5msfxcCLC3ausxvJuaXPns6G3eio47RRDDQ30ZL1xMvFioLPy9QoQLuvYPB5OhtMhzm9Z I9Vmd7tq5Sr/wzoIcYNku2bKtGaKPYSWU5lCwV/GSPly1zhnTU37XP/jHJkeXcPaHKlRkCIdaWG6 IpZUtXh8gt9b4ZpZS84uirWdlxlOysmq5+g9K2dlDVeM9PZdWV5g8ZKeYkYb8+uGWAwwbXlaFcH2 m6rHaRPTarNV1l/INpcP7P0RqZ6Ppc0sW6tGLDUNJQd3c45sthAW0ucSsq+ZcpRuTpZtMRmWDsLh vdKqKZbJiSM6Sz4QplsQvwPDVspXKUmbCPsIg99zkndlveH8jxvRlyEEXaTBe+uurMeWb046hsuj 6milaa1rGtl2OX9W27k6X1XPxI+hOKpX4Tm4sleJS4lkDUk7pppv6ZWcyLCWWCWTH26fSwhRNEwt ETSuxigZfKk5TGDksVj3bXhxz2EjYi8y3bMSZkIqP/UVQ9qiqOksr2D5CfrwoRn5BFuc1aklpc6t tOS9DGFxlQ34oWjxctlUCw1t5AqeMl72XYMtjENlsW5+LuS1eEERl11QpKGzbYh+x0cOYu1iw2KW K2ciCXJ5KO8oZqDstmRXUTS4KcbCU4eckc3q3n6xHI6H6wttm6LM/dt9p13Z/acc21ZTEdk7Rj0o sxfpKx71FtiWIWRpcSCzhefznR2I1/WtlJU3bDX6BpNHZQSRUFPCzkT5k9O1phTFboitbeUaUu0x iY4XpQXXQby4Nx0s6eHqJenntEYc33YNJ5UGfCy5gycjh4fHNu8q2fXUuouq5gTHRRaxoOOF7CI6 SynLi9bkhrLomrIrqCJ9uooM6yoSKGGq6GSPLiVFS3hAfimhlCqNy56QP45lFK/ZVqT+smXXcLK1 R2yRyoB401CgrVeTikDFWa0HLJ/NJ+JNHT2iKeO4k1YawcSbOnFYajCuVzzxpq72rd09TTyDcfkF XoFJdKAX6xHbtEDcaSlNiRaj3Gt0i8Pygg5EPZ4cb4roqRcQnCtpj+ju0nHKOqvDqrG9Eok0mBHx KKZ633iTX7SDT4j4Emtkj3xGiGcLKtl6g0++B8rM8SNAKW+phQEZ1Ct4wpcQVbyLKhjz9KZvOJUP d3zjTUVzXzkkIJSyt1nJ91eVbxGrhahnur6ZjjfptzgtQehQe1vrhUCuGRjHBebtju/Lx8/F1kTz eHDV4xd0Hdx2SCQTIllws6bvW22iLyH2WL6ZM9pqvvRNLTKVkUDwzrA22QxZudbV0d3VJvjNdjPq zXZbIejB7YdE5GV4/C48+Sq8zs5NI12XbN+MyJL8Eiqebor+6CvWVDnuc2bF6FL3ukULa8tbm9vE 3kJ2Tr5cjzVSvOSueLHV4Fh/77DoLPMaHxjpx9+lv4Kw7uqu7uqu7v4jXCPRFJgGWZADLvDAp8Bn wD3g8+DL4EGwcjnRKrAGrAUvAevB+UCAFtAKLgYp8EZwC/gQ+F/g6RVEz4BnwZtWEd0K/hrcBT4I /gY8Ah7lz5OIfgxObSdKdhC9Hfykm+hvx4juB9ck1Xuqn3tG/vvVT5557ofPPfbcDx97hnmU/oUe fogexZ/w3wP499DDjy4td37P7rS+vetodO8yugrYe05tdFpiJ0ePaU3Z1WVgpf6+um/vucH5Rv5O p2xZ9Zq+vSI4SSvl8TZ9/tyy87ihk8t/E7gOzIA7dXkHZc3lfFakPLn8PhIpw/GVRBMgCe4E7wK9 q4h2AQNMgn8Fv4sme4kHv4kePBU9+EXNgydqHjwePXhsaQffObEOQrcM/y9cRrE16gX8q+ThxRfG 4v+wnGJ2o2zV69Jr54ma+FLDmps3nCmvbThT3dsg/8bo7ONR/kEbDNzzzz//u9/9Dn+ryl53J4Jb 1rCGGmKxddw2vwtWNxGdDH56EtHPwM/BL8AvwVmric4Ge8GV4LvgMWCeTJQBU+D94EfgojhRDnwM /D/QcwrRUXA/oDVEu8DNa15Yf1A/OA4HpT3IeVwWXwGnryU6AO4Aj4JzTyWaAEmwH7wWvA7cC+4D 94NnwLPg34C3jsgHBTBzGtEsWH860flAgKfPRFgvQVjgwEvqRXGilD+XxV+Ad4A7wJfBg+A9ZxH9 JbjlbKI3gdPPIToDXA2uAZe9lGgHmAd0LlEMpM8jMkEGvAu8G6wXROeD5c1EK8BKMNlcL4oTpfy5 LFLg3pcR3Qc2v5xoCzhwEdHVYG8r0ZXgDvBOkLuYyAZfbiN6EKxpJ1rbrubn3WA/mAXvBHeCz4Ef g5MTRF2gG7iJelGcKOXPZfFx8BTYtImoA8yBL4DVHWrNtR+8Ddyu11/fBKd1Eo2Dt4C3gh+Dni6i N4MnwA/Ahd1EJvhAt1qz/RRcsplo2+Z6UZwo5c9lsR30gEvBDSALOrcQdYG94ErQv5VoAAyCm8GX wMpLiIbBn4Nvg7O3ER0E7wHfAxdsJ0qBD4Jfg+4eogL4SE+9KE6U8uey+Cg4/VKiM8CvwGWXEe0A bwFvBR/fQfQJ8DD4Z7DucqLTwD+Br4M3XkF0C/gteA5cuhNhgOvBDeD2XqK3g8ldRGnwf3bVi+JE KX8uiyfBr8BT4Ncg0Ue0CdzTT/RZcC9YNkDUDhJgBtwPGgaJ9oLbwXfBhbuJtoCt4NXgPhDbQ7QL vAF8FXwNrBmqF8WJUv5cFklwJ/guOHsvUR/oB7eAh8HpVxJdC94DfgTa9hH54LNg2TBRIxgEu8Et 4OvgjBGig+B94CegfZTIA58B86P1ojhRyp/LYmCMaBC44G7wAHgU/Bwsu4poF7DALPgMeBD8FuwY J7oJfBH8BvwWPAd+B/4dXDpBdBl4Hfgf4K/BhiTRRcl6UZwo5c9lcRUYBxPg6mRRn/ui4/ot1d2J 6GJh+a8QtGGsic6/+88S4u4Hey+4225sBi+7zW688LZblr/87iWHWXd/lG4draWTKEYHaY38tdpG kr9Cu/PX8w3y12hX0Ag55FKODMoSaT+5PU2Ne3BXDMd7+JeA8deEjzRZZNMUCeqUPyQcoxUXxk67 6yk6/a7LaOcGOo30xuOVe86l0b0NdNXehkqZLqPenU/Pvw+fRGdSP0LOIOwC4vcR8hi+u2BK/s3T NM4NQkYbV6PuYtq1M0ZP45Pl2wUfaZqD3yTCOyL9NiDNjdS39yz1e7hjciNtRv0i8fw8/0Zr4wXz 8/rnW/FNicrnloXnGsNzy8NzK8JzK8NzxV98fRbB3BsniiHad76caC9n1Q6irw8pGYheIZtoTEqY km31mzLX+cxyul2WyiD+rqToLzW36++8o8NafdbssnaPNTy8yueVHs/2ecbHo/5FupfHZeoALEYX /64tgHfaAraCS8A2sB30ROLbpNPDu4TfABdAnAS4AvH3gVMgw0Xg12uRAt4hAH8G3gDeAt4OPgpu XUf0fvAI7xKA6TOJsuDKs4gOgxRwgAduBveDb4PvgF+AX4GTzyZaC84B60ELuBT0g33gMDgC/hQ8 CZ4Gz4F51myfD/9gBvwpeD24A/wSLBdEr7yA6HrwFfBtcFIz0fngzS+DP/BZ8CC4fwPRP4NTLiJ6 KXiyBfGAP2lF2OB74EfgF+Bp8KaLid4K/gbcDT4Nvgi+CZ7gaxuJ3gk+AD4C7gGfB18G3wJPgJ+B /wv+HeTbiF4FfgGeBA3tkBWsBuvAWeB80AEuaVfa2O3gCjAODJADc+Am0L+JaC94BUiD68ER8Cbw VhDvIDoH9IEx8OZOoveAD4NPgXvAQ+CULqLzwD1bcLxFaY6+Cc64hOhisBscAEfATeB/gk+Dvwdf A4+CH4LV2xAfaAFdYAcYBx8HnwO7thNdBS7rIboSvBW8D9wHvgZuvIzo1eD14C/AJ8DnwaU7kE5w CKTBneAu4FxO9N/Bh8Anwe9A0xVEOVAAHwN/B74CHgHpnUrjUQA3g227iK4A14JXgA+Du5k+or8F y/uJTgJfBA+BJ3cTPQM+tofoM6BvFOkAY+AAuB28Cxwc45Z/bp0/Sth9axnR98HUKqKjYFMT0Wbw VfBNMHgS0X7wVfBtQKuJmsEdJxPdC16yhqgF/OWpRB/jnnQd0QfAE6cTPQMeO5Pocd2DvhK8+2yi n55D9J3ziBrWI15grVc9Xyv4PPh7sP0CokvBz5uJngQHX0Z0CHx1A9E3wOWtRH2tqkd7pe7Jfg3e dTHRe3UPdi+4eSPRG3VP9Y/gUBvRdJvqgdaD0xJE5+ieZyChepY8+BX4LdjQSdQOBrsgA1jTDVnB h8GnwMs3E20GHwKfBt8DsS3FHiboWYIe4guXET1yWbFlP34F0U/B63cSvQlQL+4Hy8BKMANeBe4H XwJ7dxFdBW4H7wCPgSfAhX1EG8GrwWvAfeCLINZP1Ah2gSHwBnALWDOAdIMkuAZ8F/wInD2INIFb wJ+Dh8E3wOm7ic4C14LrwHvAXeBH4GegbQ/RJuCDWfBZ8A9g3xCRAc7fS7QB3HclZAaD+4hGwM/B U6BP623uAfeDy0eIesFrwOvBl8BXwS2jRO8DbWNEo2NBD3ROnd8r8/OnE9FJNE4bqJ8E9ZEp57gm udSJox66joYpj+Mp2ozvOXwzcV3NwNvxLYer7GeMBmg3/LTTEL5fRyO0iz7Z8f2OZzoe7LiO9tEE /Dq4NkBJGqQEpXGUolMQB8+0PRmnDQn2yLg5xixdhCOWYDv+dVIHrg7L85O4twBfNo6uQ5w8L1ex lsfTjvD3hLFVT+fm32M62xFb9yLxb/m9xp+kaSosIsElx1ECjr8gV0HjiHsM96fhcxCxWCeYFAvX vYuPue79ccZ53THHOUvd8NcF34JaIhII6UfAV1Citiw7gau8is7I7xm50hf4Po2rAvKxbCwvr7ZN GUpGSqFKuB1xF0Meo9YwXXEakfcWKIe7OVUWjhyk06TTqF+mqgupyuDvJSAqeRBGjJ6f124NlblY +YmyqxdLH3w/H7d9zJPHHNQ2fBc6hJfsLL3vBzzVWkW05uYf0Kk3nzc/ujdGVwGnBd7/7qlAFTC/ cxmOv84LcJxYexcHro7ZBZ8Na/UXXtPfxKoFxMY6gt1n3obbGhpWLFveuLxhWePryzQgf6U/k2TJ NsbyjuBzFp/j5EhNjM3rc4TTQMuXxxpiK1c0LNfKAFobCeom/jNBc7iH6wzrb7o3yNhXr2hsYFcz 9l5d7nzPFVvkPSuXNTU0LG9orHlPn66XlqxhgdSI84zbYjdxipsaG5avWtaosnHlqrVhCCrA9vnu eUGnZM6bImqmRrpx1a1n0VMP4+K0vOW5zp7Mzz/U8zqS4yLrdQ6sJnrvTs7cC6RiYtnaN0bkWiVL OagrFyyjp9ZS3b0w9/4Vn1v5KfoU3USXd3AlO5vSOHs2ODS6xCAWcFz+Aw3z8+v0cYKGaISSNEDj +OzFtyEald/2kcC3cdqN7yM4OxG5ynpAviZwNimv9+PvOP6W+lMuTrt0/zYneyiDPLpB9q/ZBfuv /1zu+XmixpMqlbDcah5/7V89/ZvR6bUffssq2njRJx/pwLm7cOFUff02XXJ3qP0keljrj/+VVE/3 rNRUKs/cPZ0ckxpWEjH5XAJtwyeXeH+M2zPRK/F5Mj6zMS4doiP4PAWfN8ek6TjdGlPd2+34PA2f 746p+O9C5OtJaSSHRpID4yO9+ofhR8d3944MTchDMTg6LiaSvSP9veP9+hx1rA96CNzH3zm+XfKF XXsM7wYzm6XR8dAPzpd/X823yvfDJNKOT9kgjBHDLeQsscdyHc/UYXAedXZQgb+z/MMWvx7Oyfji an6l17ZEBw3t5LCPNj3G+Se/j//blteueSAmv9/a+0jupQ/ElqlHPmR43APyJ/eCWitdd3VXd3VX d3VXd3VXd3VXd3VXd3W35PU/n2n41j9+692Jl6592ztW0ca233y0n9f1Zed4zX6uXrfzunhaPeZN ea0DuEnrAN5ASm9wG+tdtc6A187v1SrLD+o18d3S5ovof5PSAXyOVNjPUelan8PuTbI1cVKue9+o 18MX6E/WSsn19hmrZDyk46v2uX6tkv0F6A9OXqvEWq+TmbT8rCkj1mrHQDfCTujTW3VaLtfH/J31 H4fHhvoP794/1B+mtJc1CeDVtIW6aRf1495uGgTtoJe6aBu+deJfvzy3TftjzTz/2yKPt+Bbh/73 36ju6q7u6q7u6q7u6q7u6q7u6q7u/os+CihXm8v03v1yvZBdqfeYm/TadLVeh8f1/vYavW7nNf06 vXZne9Uz9Pqd1/hnaQuRc4B+TRSdpxfL5+v1MK/Xm8HL1HNn9HKwAVwEWkCrfJKLaCPbcZF6yimh 1+odx/DU0qXaHmyHXndfoffXeYW9S9ouEbF+YwAMar97WB8A9oIrwT7es9crcr4+hs+reIteWlmx JoJoP+/J6+v/Dq7V3wNONMcWZY60/huQtoFsDXMs7kxaHgvC4jq0oknpkj6nLg/K76/55OVst/D4 7Q89y58HA9M0WX5JMmiSsi/QsuYUaqBoepZyDz9XOHiG+n61tHlMU7+0OSxIi7vyJwkXcudQQ2y5 ti1cavzsmmfU53KakLHmpL3RnLTQzIRPXLJ1rSOt/Wq5FsQfPLe51Ph3R+wEl1ek/Njk2Yb4jzX/ RyPxx6TVIFsOj9IkXb+Eu8ufX22IxXSfdSz5f30oC8dqUgppG5NtIbuk+4v1P7Zo/QvqffBZK6wX 6o41/8v7/xOxX6q7P4xjK+tlJ6k6VN53n1Vpo9bvpAr8a5pyTjA8wedwSjZm/p4Irie20bPbP3Hj glWv7k4A9/8BUEsDBBQAAAAIAIBJVicbtma2yggAAL8UAAAMAAAAMjluMzI5MGMuaHRttVhZc9s4 En53lf9Dr7a2xsmIOn1JkVVLS5RNR5a0JJ3U7NQ8wCRkISYJLQA60fz6bQDU5ciVmT34IBFko/H1 143uBnu30f24f3zUu/Xcof7/i+PA+//+AsdZa3MLteCiC/qaEFFkDG6Z4JJWIaSxoIoIRlQV/HBa 970B3EUDaNbDAbQ6sL622oZE0W75tNnpdJxmw2k14U9dW20jllIElWmVrU7ebnUacW2hsj+ua1fb H6fnR7xFfjT2+ocYmYAG2atbiV597bfr6fAXgwM14AVGi3s99uB6Ggy94KoBn/1hdHvVbDT+Zl4G /V407Pf8+5utSBgMripMckbj2hObV8AdR1eVX0sgv1VwwcgsFw3xlX8zuQr8m9uo3xtNJxGE/j+9 q59bb+Du1bXQnmi7b42xL64D1Dx0I6+741n7NPBmY3fghV20zkDAn0D/aAv7vdlrywfeJPK0gbsM nMHAG49n7nDoT26Qh5KQizUfpUWbubjK9SFbNCQLa8ATlj8Bn4NbJIxXYcZiVQhahfsiVSyjCSNA 8gRuV0sq7NDP51xkRDGebxXtbIQu9Fy4DbzRVeWv+YJV+ndkSXI4ufPDwbte3UWrr/sHOKivcX9H xh4JzT0Szg4GRfmwhc+QgeF0UIPol5m3XXgjcoki00I9cU3DmBEmeQ6hIopmNFdblFvVluNoOtOq TRDvqu1/pwPmgmdgeK9/voFmExQH34tGgFL3M+/GOdV3akGRWUVFThX8uis+wdvLiyq4SpF4oVV2 Yf2m3Wg1f/shynD6EAz2YR6ICrvcD5XNgumdN4hgMq3tadyN67dwRG70EO7jyIHEMRcJyWMKX5la QEAlTwsdXtCqXdbaoMgzRTFlOJpzoVZOznKUtCxklCr0XnWz5xqn9cZlFe5p+sgL5BOpK6QSJGWk anTYDb0TsrAgUmv+SkRCE5RhEtLSkXLjSPSbnr1+wcUTydnvZiNY5LteqUKoimSlXbtxayLIXOl1 jJ6YCFz7ierdt40Df1Y7wKNmL/BGXuBNBt4+gyiz3m6mAJyfmQJQ6W/T7fmZ3nbw6zaeGu3fujtE yyqcdtCA3bC7t7S+AcYdRP50Av5wPwhGv/hvov/HgxdG3hBw6qtJSIhZ+ScJbCe5HFY0fPBA59gf B5+Wnkxrmt+Ze4O0XQf9kT/2TO6Gk4/X7/SToR9+9CIbzzj0wxAXKAdGeuLe27mIHMkPYex98sb6 wdid3DygZngIveEGjyku/fOThMdmgbNWrQMn9FtMlwq2pcm8a3WG7fMLezdqXbT03VakulfSN6Nm DVUb6HQO+t/Ln1ImF28R5odR4F8/aIftkVbug1kVpibHj52MZo9UyA/lm+l8zmI9tjne5IrdbfNh 0/L4UTR6s6w5/6tLa9sWX6fZ77nGO1cVU2f+ZG9mSpH2+Cy8q/tROLh7X4WA8wzajUunXYWP7Jkw J1yw/Jk7HwmOcrhOk6daFdrOmXOJSyzYI3E+cppX4Z7lRKFcARF/XnFoNs6cRqPZBFP+9EIRTely wXPahZ8vm07baZ+2m07rsnH5AWBEYskylu6/PD/ttD+A52SEpTt1VQ8V7y6MpX9nSsZfamwpv9S4 qH1ZVvpvvFhbfHz0HnbLOMwEj6mUugaGPGZUrfSmMcDru3IRjRc5T/nTSte3PCEikTDgWcZwsk6J 5SQ4cXXeLAX2EiWJ0SsJUzSBxxWUPYFtn/4P0XIb2Fi5LLVf99edla9/J67eFO4YpsGNO/FDM4TR FGdF7mToBsPymWVtT2pPgQdDnTSCe3e8N+PtMmvbr6luYmA6gvvpJ3038wfRQ+CFgKuD+zD0p6/a oqH/qaypFdO4Vt6u5Lpj3etqdRux16pOY1UzVbNXR72mL8MlZgdaroOdd8RUSrs7OW/d+5QNzqF8 FPJCxHuTBjx/oTkX6zK4N6tMJCWqaEHyZ1jxwtRQ/BcQ81yxvNCRy3SZpVLhDWTkWT8qy6rahi15 ISwljyl93XPVAD5TWJAEJH2hgqSQMBkXJq6lxnZ8ZNSwGF8pvmSxrMLXBYsXEBdppjc/TfTSBL5w hKKRzRGPbmtwSmo7hDVGFF0SoRiVtj00tjwJXixrpa1hiYJJWaDUV5wGcUoEmzOa1PT2tRpwcSKq xlIQNOZZRvNEomllvyRZtkRrg2i2ZmNJVilHO+22hkcKhTTQmWIIdIXKj4/8ue2CyHIpOEEj8X7O izzRzl2QFwoJnbOYoX3aCLQ7pkIR/JcxzREml6am4AwqNu+Qk4SVDQeCywHBCf5i2iuJTltpNCgk Gc4yZpZsoLVcaE24+pzELGW6K4MlR/9oZ84LfWrZU1dyYgx4MU0dvs/jtFhnKv0goU+CJDYzLRG0 YGoFyHBqXYluC8dIWPxMtcLjo5wr+FJIte5GpUIfaGUk1gkUzWVKIuxb/lX7rwo41PSiazIkQELO cye3+fSFblrBpaASMa99/7lUTA3baz6QT6DfFM13DdB+feVQuaQxQ99Yq/QSpeMlt2FRDs2Jr/6J yYKkuJ6gJJNoovYC0QGHxqM3EiZorNIVeme5NGGCkOyqhpUahEW8OIADVfACedzGl/ZFWuIqI5Tn qFnQfxW4irFHc3V8hMaxPGEvLNHYiAb6YnHG9sCqOE+lhqmjMLfa14mweXraOXdaJvycdg28b0Rv AWm9n+wcs06iT+/AVGQjnPFH/TUl25589Z4Xem+naCd65ZGmDP262V0Iltiw40KRXO1buOnra+CW vf/3vjG77IAX9d4zBz407vjoxB4q3hkUlteUPdMyPHQGtPRtc5bNQsiuyTs7+QW2QZZy/rw+9pid VQhUopNqmpJHLsqKjdTEnC9pObaJE01HmEiPtFHbuw02NXZ7Ut0pKbuHo+5/fDiyhav3YD75jX1z rL+qDP1wUOmbb2G5+Rb2ulPeEdayVtQy3YX7ED5zYZiHzsWb4pL9jppPL6rnzXN4XCkqD4nOyBOh sgvnunpZmJYcPV5/46qXHy2Pj/4NUEsDBBQAAAAIAJekOCJdOXAqxAQAALsFAAAKAAAASVNPSUVD LkdJRm1TCVBTVxR9iYhUBUSQiAtFIkvAZVor2ChIAQMEFcoASl0IskVhyBhLTFAIQWJiQonIIksU RAhbZesgLtQvVECQzigGrVUsoGIIGVfIj1vpexIL7fhm3r/3nXvuOfdvPn60da4RaWAdwAFcE3CZ zhwwMJ1pnN3DrxzrFOrmArBBFwgQhjbQryh9PDyGY1fh9nX5QYC472HP/7FP/UXiHr4WDwTB453C NjUAp2H8nKYH+PzaDPnYoR4+0iTAsykAV6drIc94GCNdcAxxBMQpHosqV2+Eh1RYJ1vh2KTi90BA eYPxFuFYi3ry7lfBGuKiqlzNojJGZqfSoM5bNRFc2EAEFZYAbHRwgEos6sc4mu7WaWmgn/Aqp4eP 3JArck93m6evaNRPeBMTLCoYvQH5HzOANMQDNv2eowDM+Ni74LiMNDkvAfbr5ooHiKD+AXL9yix2 WsWmH4qnTiqjXD6aYDBVRR0sKrr6PiJOm2PIHMdc4Wjt83FM6oljfhDz088nGXuHrfWYwkwbwwQv tJ3Ca+44ZgHPryH/he4ddqJ2MqZsJ4L3WJgAMEIEUfZzWh1TcSwQ5kgr8wR8vvp8Hd4pRFwDqId0 AIwT66fqn3DESYSbq+sUItxCPxeN8N+5p+dgG/xmoDc3HMd+mgH+7U+HnibPJjEWtVeD3rsSYl7U wBgAjDwIIFWzh08iRPNRvprQpnlNJ0HOCmSI/gVgNAEIRkt860tajxiZO21YWBLxm3AemZ6+kFHa Lp2/1P3a9QZyq8Taa4/SKKisS2wXUO3tyy73P7o60iSesiamu9Bp79BO3oEK31PuW7Qa394z/iXf eZk0MXMGO4oXZZ/eSTeLUhZsKWZ7OyXWbBOEOrs/2B7kfLtml1tQ9Jv9ih0g+n6md5E2rqOe1Tps dznPrl/GJ5CMM5pUbVfYRep+Z+5L71rGF6bWmh8bwy5aEJ4mzm1+MVwtmcNuit/+Te/N/AWKFYsL 14ZcE672oRmfrA//85cI6639FzkjRTXPh7TJVuzoey3fynoclVrmfYUottZfyWM8upUVUJfSl7S3 76HUa0JmXLSS1/3UYfHylf26AyOP+2afl+/+cFjbnIWJAlpant0bGxeFJxNimpUp2nYfZbIq2YGR ZChxXZKmojBJRwytDz5MMiFyBxIf8Ry/FPFDjEpEjYl/hKe4RcQOspeX0hZJKRyVtfj9uQuMjJiG u2clRCJpt3SZmjt41MyeaZuON1wn0zcVkgb3rzH0eyIzH6rclX353EE77ppVx0qPh/UO255s5nWR C/wyZ5ZJXAutysW5H0SDh8Pd8x9nB9dS5PJZX+sWp0VeojGL4+wdHTk1xiryLhndJcrTPchJwZRy SJSCXFv60gzhvreqXI8rupHIgpjoYEGZLWe4itNWMjs6s9G+QpFTPH7eKr7uTqGzqPjYpuLQ1t+r /1JcN2SS6fld4oram9YusYH+eXcrQ/KvCPP4tDvVlfyfyy1XhWadColpVL16YtNc09Gef/5B70hc E+nleELDrb+tnm+9kVadcPBxwtqoS10dnLhfIyiKqqDbSXP6RDvUo84HzI9Y7m9/s0d+piOHHU85 Z/780L66ZYc0ZV2zzq6o6+6u2vyqhUAA6/8BUEsBAhQAFAAAAAgAV11VJ2q4fLX0KQAAALoAAAwA AAAAAAAAAAAgAAAAAAAAADI5bjMyOTAxLmRvY1BLAQIUABQAAAAIAIBJVicbtma2yggAAL8UAAAM AAAAAAAAAAAAIAAAAB4qAAAyOW4zMjkwYy5odG1QSwECFAAUAAAACACXpDgiXTlwKsQEAAC7BQAA CgAAAAAAAAAAACAAAAASMwAASVNPSUVDLkdJRlBLBQYAAAAAAwADAKwAAAD+NwAAAAA= --=====================_508417375==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no --=====================_508417375==_-- From rem-conf-request@es.net Fri Oct 22 07:06:31 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06551 for ; Fri, 22 Oct 1999 07:06:31 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ecKn-0005WE-00; Fri, 22 Oct 1999 03:54:09 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ecKl-0005W4-00; Fri, 22 Oct 1999 03:54:07 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05598; Fri, 22 Oct 1999 06:54:06 -0400 (EDT) Message-Id: <199910221054.GAA05598@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-mp3-01.txt Date: Fri, 22 Oct 1999 06:54:06 -0400 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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rtp-mp3-01.txt Pages : 7 Date : 21-Oct-99 While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable for MPEG 1 or 2, layer III audio (commonly known as 'MP3'). The reason for this is that an MP3 frame is not a true ''Application Data Unit' - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. In this document we define a new RTP payload format for MP3 audio. The new format is essentially the same as that defined in RFC 2250, except for a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units'. This new format is therefore more data efficient in the face of packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-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-mp3-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-mp3-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: <19991021142104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mp3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mp3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142104.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Fri Oct 22 07:30:58 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07075 for ; Fri, 22 Oct 1999 07:30:57 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11eckW-0006M7-00; Fri, 22 Oct 1999 04:20:44 -0700 Received: from ns.koganei.wide.ad.jp (happy.koganei.wide.ad.jp) [202.249.37.254] by mail1.es.net with esmtp (Exim 1.81 #2) id 11eckU-0006Lw-00; Fri, 22 Oct 1999 04:20:42 -0700 Received: from localhost (eeyore.koganei.wide.ad.jp [202.249.37.70]) by happy.koganei.wide.ad.jp (8.9.3/8.9.3) with ESMTP id UAA12663; Fri, 22 Oct 1999 20:21:49 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) To: BNowicki@Omneon.com Cc: rem-conf@es.net Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt In-Reply-To: <3A54A80C464CD311BAAA00A0C9C85E6704532C@grumpy.omneon.com> References: <3A54A80C464CD311BAAA00A0C9C85E6704532C@grumpy.omneon.com> X-Mailer: Mew version 1.94b56 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991022202157P.ikob@koganei.wide.ad.jp> Date: Fri, 22 Oct 1999 20:21:57 +0900 From: ikob X-Dispatcher: imput version 990826(IM126) Lines: 148 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Bill, Thanks for useful comment. From: Bill Nowicki Subject: RE: I-D ACTION:draft-ietf-avt-dv-video-01.txt Date: Thu, 21 Oct 1999 17:46:41 -0700 Message-ID: <3A54A80C464CD311BAAA00A0C9C85E6704532C@grumpy.omneon.com> > Generally the protocol is very nice and simple. However, the document has > some minor problems. > > There are two spaces between "Carsten" and "Bormann" on the first page? > > Be consistent about "IEC 61834" having a space between the letters and > numbers. Similarly, "IEEE 1394" is the convention, not "IEEE1394". Also put > a space before open parentheses consistently. > We will correct them in the next publication. > The designations "D-7" and "D-9" are tape formats. They correspond to > products with the DVCPRO and Digital-S trademarks respectively; is the > policy to avoid trademarks in IETF standards? If not, mentioning them might > be useful. I agree it, the name DVCPRO and Digital-S are well known compared with SMPTE standard number. I don't know the exact attitude of IETF for trademark. If we can import it without trouble, it is better to clearly specify trademark. Does someone know the IETF attitude or the reference concerning the trademark issue ? > The professional 25Mbps variants are generally the same DV > stream, just on different physical tape, so it is not clear the full matrix > is relevant to an RTP payload, but I suppose it does not hurt. There are > some subtle differences in audio support, 625 line color model, etc. I think generally the same. But system data treatment is different, it is safe to distinguish them. As you mentioned, the picture sampling structures in 625 are not the same, cunsumer uses 4:2:0 and professional is 4:1:1. I think this difference is not small. In the implementation, same CODEC hardware and software can be used with mode switching. > > Might mention somewhere that SD-VCR stands for "Standard Definition Video > Cassette Recorder", etc. I do not know exactly what "SDL" stands for, since > nobody uses it that I know of. > The relation between SDL and SD is the same between LP and standard on DAT. That standarization is working in IEC SC100B/PT 61834-6. The SDL is also specified in the BlueBook. > Section 2 and the first paragraph of section 3 have many English errors, and > are redundant. Suggested rewording: > Thanks, we will incorporate your input in the next draft. ..snip.. > > Section 4.1 > > "in VAUX. Because" should be "in VAUX, because" > > ... Even if VAUX data is > received, the receiver cannot obtain the attribute until the video > encoding format is determined. > > This sentence is confusing, and I think is just trying to say what has > already been said - use payload types to determine format, not the DV > stream. It is ambiguous, however, in the bundled case, if just changing the > audio format counts as a payload type change? Looks like "no" in this draft. > In bundled case, only audio format changing is permitted. How about remove sentence bellow as ? ... Although VAUX data contains some encoding attributes of the stream, the sender MUST NOT expect to notify the receiver of an encoding format change with the information included in VAUX because the packet carrying the VAUX data might be lost. And changes the sentence concerning VAUX: ...Even if the VAUX data is received, the receiver cannot obtain the attributes until the video encoding format is determined because the VAUX data only represents sub-attribute information which relies on the video encoding format. > Section 4.2: > > It is not clear if Header and Subcode DIF blocks may, should or must be > sent? > Add sentence as: ...Other system data header and subcode DIF block MAY also be sent. When header and subcode DIF blocks is sent, the both blocks MUST be included in the video stream. > How can the sender omit AAUX blocks in a bundled stream? If so, then all the > audio information must be specified in ugly "a-encode" lines like the > previous draft, but those are now gone? So I would say remove the reference > to AAUX here. They are not separate DIF blocks anyway, but embedded in the > Audio blocks, so just passing them through sounds like the best idea. > I think our draft only say as "... send null AAUX information and omit VAUX DIF block....". If this sentence leads other people in confusion, we have to change it. > Section 5: ..snip.. > > Reword middle of paragraph to: > > ... These attributes are carried as > AAUX data within audio DIF blocks. Describing all these attributes > with SDP would require large SDP descriptions to enumerate > all combinations. Therefore, the SDP entry to describe bundled streams > does not include audio format parameters. > We will change to: This includes audio attribute information carried as AAUX data within audio DIF blocks. Many audio format attributes are defined in DV, such as sampling, quantization, number of audio channels, channel assignment, language, emphasis and the picture frame locking. Describing all these attributes with SDP would require large SDP descriptions to enumerate all combinations. Therefore, the SDP entry to describe bundled streams does not include audio format parameters. > > Looking forward to implementations, If we get stable implementation, we will demonstrate in opportunity. ikob@koganei.wide.ad.jp From rem-conf-request@es.net Fri Oct 22 10:17:35 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15063 for ; Fri, 22 Oct 1999 10:17:34 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ef92-0000QR-00; Fri, 22 Oct 1999 06:54:12 -0700 Received: from gateway.mitel.ca (semimail.semird.mitel.com) [198.53.180.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ef90-0000QG-00; Fri, 22 Oct 1999 06:54:10 -0700 Received: from mitel.com (spruce [134.199.98.152]) by semimail.semird.mitel.com (8.9.3/8.9.3) with ESMTP id JAA07534 for ; Fri, 22 Oct 1999 09:52:49 -0400 (EDT) Sender: ALEXANDER_TULAI@Mitel.COM Message-ID: <38106C32.510FAB74@mitel.com> Date: Fri, 22 Oct 1999 09:52:50 -0400 From: Alexander Tulai - icpd Reply-To: alexander_tulai@Mitel.COM Organization: MITEL Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: New internet draft "Dynamic Nx64" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hi, We put together an internet draft that talks about the Nx64 problem (transporting multiple 64 kb/s streams between two gateways). This is a subset of the multiplexing problem and, because all multiplexed streams are identically coded, further bandwidth savings could be achieved with a different RTP payload type. The implementation of this method is very simple, robust, and allows for an easy mapping to existing dynamic Nx64 methods used in ATM which could be very useful in equipments bridging IP and ATM networks. In addition, the method proposed allows for silence supression and the continuous sending of the CN packet payload (see draft-ietf-avt-profile-new-06.txt) that allows the receiver to better follow the noise level at the source. The draft is an individual submission, and will appear in the archives shortly with the title: draft-ietf-avt-dynamic-nx64-00.txt Until then, to pick up a copy ftp to "semicon.mitel.com" and cd to "incoming" directory. Comments welcome. Thanks, Alexander Tulai Mitel Corporation Ph: (613) 592-2122 Fax: (613) 592-4784 Email: alexander_tulai@mitel.com From rem-conf-request@es.net Fri Oct 22 12:12:10 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21545 for ; Fri, 22 Oct 1999 12:12:09 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11egzl-0001wE-00; Fri, 22 Oct 1999 08:52:45 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11egzk-0001w4-00; Fri, 22 Oct 1999 08:52:44 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 889B14CE0B; Fri, 22 Oct 1999 11:52:43 -0400 (EDT) Received: from pcbasso (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA09186; Fri, 22 Oct 1999 11:52:37 -0400 (EDT) Message-ID: <00da01bf1ca5$77d829e0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, Subject: Submission of updated draft : draft-ietf-avt-rtp-mpeg4-02.txt Date: Fri, 22 Oct 1999 11:52:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit The updated draft on the MPEG-4 RTP payload format should be appearing shortly in the on-line IETF I-D archives. It can also be found at http://www.research.att.com/~mrc/draft-ietf-avt-rtp-mpeg4-02.txt Any comment is more than welcome. -A Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf-request@es.net Fri Oct 22 14:33:35 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00434 for ; Fri, 22 Oct 1999 14:33:34 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ejGs-0003ct-00; Fri, 22 Oct 1999 11:18:34 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ejGq-0003cj-00; Fri, 22 Oct 1999 11:18:32 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA01530; Fri, 22 Oct 1999 10:56:30 -0700 (PDT) Message-Id: <3.0.3.32.19991022105629.00b4e630@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 22 Oct 1999 10:56:29 -0700 To: Florissa Colina From: Florissa Colina Subject: 10/27 Supporting Multicast Services in the Emerging Internet2 Network Infrastructure The View from Minus Six Feet -- Ken Lindahl, Communication and Network Services U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Supporting Multicast Services in the Emerging Internet2 Network Infrastructure The View from Minus Six Feet Wednesday October 27, 1999, 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Ken Lindahl Communication and Network Services U.C. Berkeley This seminar will cover the architecture of networking @ Berkeley and support for multicast @ Berkeley and Internet2. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf-request@es.net Fri Oct 22 14:39:13 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00770 for ; Fri, 22 Oct 1999 14:39:13 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ejMn-0003kn-00; Fri, 22 Oct 1999 11:24:41 -0700 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ejMl-0003j9-00; Fri, 22 Oct 1999 11:24:40 -0700 Received: from komperdell.cdt.luth.se ([130.240.52.26]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id UAA00347; Fri, 22 Oct 1999 20:21:56 +0200 (MET DST) Message-Id: <199910221821.UAA00347@basil.cdt.luth.se> X-Sender: micke@mailhost.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 22 Oct 1999 20:39:19 +0200 To: Zoran Kostic , pilc@grc.nasa.gov, rem-conf@es.net From: Mikael Degermark Subject: Re: Header Stripping in Cellular In-Reply-To: <381092C9.AA95A2DC@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Zoran, At the coming IETF in Washington DC, there will be a BOF discussing robust header compression for cellular. One of the proposals to be presented at that BOF can compress RTP/UDP/IP down to 2 bytes (or possibly less in coming releases!) even in the presense of substantial loss on the link. Please come to the BOF. Even if we rehash this here, we will have to come to some agreement as to what the IETF should do about header stripping and similar ideas. The BOF is a good venue to hash this out! Cheers, Mikael Degermark (who will chair the BOF) (I've commented your letter at some places below.) At 12:37 PM 99/10/22 -0400, Zoran Kostic wrote: >Header Stripping in Cellular > >This topic was touched on briefly before, and the consensus was >Do not allow it to be put into any standard !! > >Let me be the devil's advocate, which does not mean that the principal >idea appeals to me any more than to anyone else on this list. > >I am afraid that header stripping will almost inevitably be included >at least as an option in standards that deal with cellular. And service >providers will probably choose that option as a default operation mode. > >This is why: > >* Cellular service providers have paid a LOT for bandwidth >* Improvements over current 2nd generation cellular systems consist > to a large degree of improving spectral efficiency of cellular > networks (bits/second/hertz/cell) - improving the capacity - > improving the revenue flow With suitable header compression it is possible to get within less than a dB from circuit-switched voice. So the incentives aren't quite so large as you say. >* Pretty much every single bit is accounted for in framing of RLPs, > speech blocks etc... >* If there is even a remote chance that some bit does not have to be >carried > over the air, it should not be carried over the air, because spectral > > efficienty suffers, cellular capacity gets hurt, revenue and profit >go down > >The questions we have to ask us are: > >1) What might be the highest compression rate achievable for TCP/IP >headers ? > Even it is 10, I believe that stripping will be what service >providers > would opt for. And can we even come close to 10 ? Do you mean TCP/IP or RTP/UDP/IP? For TCP/IP I find it difficult to go below 4 bytes. Which is 10. For RTP/UDP/IP 2 bytes or less seems within reach (provided the UDP checksumming issues can be resolved in a reasonable manner.) Which would be 20. >2) If we buy into the argument that header stripping will be legitimized > > regardless of our opinion, what should IETF do about it ? Maybe >there > should be something that from spectral efficiency mimicks header > stripping but is more acceptable to this community (again I am not > sure that compression will do the job). Please come to the BOF! >3) Heretic thought: Cellular services are a kinda special, since the >base does many things > for its mobiles anyway... do we have to be exclusive on the topic of >header > stripping and recreation ? Maybe we should come up > with recommnedations on how should header stripping and recreation > be done ?? Perhaps if one could somehow view the cellular link as a kind of RTP mixer it could be legal to fiddle with the IP/UDP headers. The RTP header must, as far as I can see, be recreated *exactly*. One thing the cellular people seem to like is "All-IP" or "IP all-the-way" which implies that the data is carried using IP end-to-end. If header stripping is used, that seems to be a mis-nomer. (Not that that would stop any marketing people from using it...) Personally, I believe it is possible to design a sufficiently good header compression scheme that will satisfy both die-hard IP people and the spectrum-efficiency hungry cellular people! Micke From rem-conf-request@es.net Fri Oct 22 14:51:57 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01597 for ; Fri, 22 Oct 1999 14:51:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ejVj-0004gR-00; Fri, 22 Oct 1999 11:33:55 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ejVg-0004gB-00; Fri, 22 Oct 1999 11:33:52 -0700 Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.10 1999/10/20 18:19:05 spurcell Exp $) with ESMTP id OAA27583; Fri, 22 Oct 1999 14:34:21 GMT Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 22 Oct 1999 11:33:49 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B323@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'internet-drafts@ietf.org'" Cc: "'rem-conf@es.net'" Subject: Please post - draft-ietf-avt-rtp-mib-07.txt Date: Fri, 22 Oct 1999 11:33:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF1CBB.FACE2E27" 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_000_01BF1CBB.FACE2E27 Content-Type: text/plain; charset="ISO-8859-1" <> This draft contains typo fixes of errors found in WG Last call. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me ------_=_NextPart_000_01BF1CBB.FACE2E27 Content-Type: text/plain; name="draft-ietf-avt-rtp-mib-07.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mib-07.txt" Content-Transfer-Encoding: quoted-printable Audio Video Transport Group Mark Baugher Internet-Draft Intel Corp. Expires April 27, 2000 Irina Suconick VideoServer Corp. Bill Strahm Intel Corp. October 27, 1999 Real-Time Transport Protocol Management Information Base =20 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. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet- Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, venera.isi.edu, or munnari.oz.au. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time=20 Transport Protocol(RTP) systems [RFC1889]. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 1] =0C Internet Draft RTP MIB October 1999 Table of Contents 1 The Network Management Framework ................................ 3 2 Overview ........................................................ 4 2.1 Components .................................................... 4 2.2 Applicability of the MIB to RTP System Implementations ........ 5 2.3 The Structure of the RTP MIB .................................. 5 3 Definitions ..................................................... 7 4 Security Issues ................................................. 33 5 Acknowledgements ................................................ 34 6 Intellectual Property ........................................... 34 7 References ...................................................... 34 8 Authors Addresses ............................................... 37 9 Full Copyright Statement ........................................ 37 =20 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 2] =0C Internet Draft RTP MIB October 1999 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. =20 o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. =20 o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of = the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. =20 o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. =20 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 3] =0C Internet Draft RTP MIB October 1999 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the = MIB. 2. Overview An "RTP System" may be a host end-system that runs an application program that sends or receives RTP data packets, or it may be an intermediate-system that forwards RTP packets. RTP Control=20 Protocol (RTCP) packets are sent by senders and receivers to=20 convey information about RTP packet transmission and reception = [RFC1889]. RTP monitors may collect RTCP information on senders and receivers to and from an RTP host or intermediate-system. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.1 Components The RTP MIB is structured around "Session," "Receiver" and "Sender"=20 conceptual abstractions. 2.1.1 An "RTP Session" is the "...association of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport addresses may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast addresses plus a common port pair," as defined in section 3 of [RFC1889]. 2.1.2 A "Sender" is identified within an RTP session by a 32-bit=20 numeric "Synchronization Source," or "SSRC", value and is "...the=20 source of a stream of RTP packets" as defined in section 3 of = [RFC1889]. =20 The sender is also a source of RTCP Sender Report packets as specified=20 in section 6 of [RFC1889]. 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or multicast Receiver as described in 2.1.1, above. An RTP Receiver has=20 an SSRC value that is unique to the session. An RTP Receiver is a=20 source of RTCP Receiver Reports as specified in section 6 of [RFC1889]. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 4] =0C Internet Draft RTP MIB October 1999 2.2 Applicability of the MIB to RTP System Implementations=20 The RTP MIB may be used in two types of RTP implementations, RTP Host Systems (end systems) and RTP Monitors, see section 3 of [RFC1889]. =20 Use of the RTP MIB for RTP Translators and Mixers, as defined in=20 section 7 of [RFC1889], is for further study. 2.2.1 RTP host Systems are end-systems that may use the RTP MIB=20 to collect RTP session and stream data that the host is sending or receiving; these data may be used by a network manager to detect and diagnose faults that occur over the lifetime of an RTP session as=20 in a "help-desk" scenario. 2.2.2 RTP Monitors of multicast RTP sessions may be third-party or may be located in an RTP intermediate-system or in the RTP host. RTP=20 Monitors may use the RTP MIB to collect RTP session and stream=20 statistical data; these data may be used by a network manager for capacity planning and other network-management purposes. An RTP=20 Monitor may use the RTP MIB to collect data to permit a network=20 manager to detect and diagnose faults in RTP sessions or to permit=20 a network manger to configure its operation. =20 2.2.3 Many host systems will want to keep track of streams beyond what they are sending and receiving. In a host monitor system, a host agent = would use RTP data from the host to maintain data about streams it is sending and receiving, and RTCP data to collect data about other hosts in the=20 session. For example an agent for an RTP host that is sending a stream = would use data from its RTP system to maintain the rtpSenderTable, but it may want to maintain a rtpRcvrTable for endpoints that are receiving its = stream. =20 To do this the RTP agent will collect RTCP data from the receivers of = its=20 stream to build the rtpRcvrTable. A host monitor system MUST set the=20 rtpSessionMonitor object to 'true(1)', but it does not have to accept=20 management operations that create and destroy rows in its = rtpSessionTable. 2.3 The Structure of the RTP MIB There are six tables in the RTP MIB. The rtpSessionTable contains objects that describe active sessions at the host, intermediate system, or monitor. The rtpSenderTable contains information about senders to the RTP session. The rtpRcvrTable contains information about receivers of RTP session data. The rtpSessionInverseTable,=20 rtpSenderInverseTable, and rtpRcvrInverseTable contain information to efficiently find indexes into the rtpSessionTable, rtpSenderTable, and rtpRcvrTable, respectively. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 5] =0C Internet Draft RTP MIB October 1999 The reverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables to help management applications efficiently access conceptual rows in=20 other tables. Implementors of this MIB SHOULD implement these tables=20 for multicast RTP sessions when table indexes (rtpSessionIndex of=20 rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair in=20 the rtpRcvrTable) are not available from other MIBs. Otherwise, the=20 management application may be forced to perform expensive tree walks=20 through large numbers of sessions, senders, or receivers. For any particular RTP session, the rtpSessionMonitor object indicates=20 whether remote senders or receivers to the RTP session are to be = monitored. RTP sessions are monitored by the RTP agent that updates rtpSenderTable = and rtpRcvrTable objects with information from RTCP reports from remote = senders or remote receivers respectively. =20 rtpSessionNewIndex is a global object that permits a network-management application to obtain a unique index for conceptual row creation in the rtpSessionTable. In this way the SNMP Set operation may be used to configure a monitor. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 6] =0C Internet Draft RTP MIB October 1999 3. Definitions RTP-MIB DEFINITIONS ::=3D BEGIN IMPORTS Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY, OBJECT-IDENTITY,=20 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI RowStatus, TAddress,=20 TDomain, TestAndIncr,=20 TimeStamp, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF Utf8String FROM SYSAPPL-MIB InterfaceIndex FROM IF-MIB; rtpMIB MODULE-IDENTITY =20 LAST-UPDATED "9910200000Z" ORGANIZATION "IETF AVT Working Group" =20 CONTACT-INFO "Mark Baugher =20 Postal: Intel Corporation 2111 NE 25th Avenue =20 Hillsboro, OR 97124 United States =20 Tel: +1 503 466 8406 Email: mbaugher@intel.com =20 =09 Bill Strahm Postal: Intel Corporation =20 2111 NE 25th Avenue Hillsboro, OR 97124 =20 United States Tel: +1 503 264 4632 =20 Email: bill.strahm@intel.com =20 Irina Suconick =20 Postal: Videoserver Corporation 63 Third Street =20 Burlington, MA 01803 United States =20 Tel: +1 781-505-2155 Email: isuconick@videoserver.com" Baugher, Strahm, Suconick Expires April 27, 2000 [Page 7] =0C Internet Draft RTP MIB October 1999 DESCRIPTION =20 "The managed objects of RTP systems. The MIB is=20 structured around three types of information. 1. General information about RTP sessions such as the session address. 2. Information about RTP streams being sent to an RTP session by a particular sender. =20 3. Information about RTP streams received on an RTP session by a particular receiver from a=20 particular sender. There are two types of RTP Systems, RTP hosts and RTP monitors. As described below, certain objects are unique to a particular type of RTP System. An RTP host may also function as an RTP monitor. Refer to RFC 1889, 'RTP: A Transport Protocol for=20 Real-Time Applications,' section 3.0, for definitions." REVISION "9910200000Z" DESCRIPTION "Initial version of this MIB. Published as RFC xxx." -- RFC-Editor assigns xxx ::=3D { mib-2 xxx } -- to be assigned by IANA -- -- OBJECTS -- rtpMIBObjects OBJECT IDENTIFIER ::=3D { rtpMIB 1 } rtpConformance OBJECT IDENTIFIER ::=3D { rtpMIB 2 } rtpDomains OBJECT IDENTIFIER ::=3D { rtpMIB 3 } rtpUDPDomain OBJECT-IDENTITY STATUS current =20 DESCRIPTION "RTP over UDP transport domain over IPv4. This definition=20 uses the transport address type, snmpUDPAddress, which is=20 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of=20 the Simple Network Management Protocol (SNMPv2)'." REFERENCE "RFC 1906, sec. 2 " ::=3D { rtpDomains 1 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 8] =0C Internet Draft RTP MIB October 1999 -- -- SESSION NEW INDEX -- rtpSessionNewIndex OBJECT-TYPE SYNTAX TestAndIncr =20 MAX-ACCESS read-write STATUS current =20 DESCRIPTION "This object is used to assign values to rtpSessionIndex as described in 'Textual Conventions for SNMPv2'. For an RTP=20 system that supports the creation of rows, the network manager=20 would read the object, and then write the value back in the Set that creates a new instance of rtpSessionEntry. If =20 the Set fails with the code 'inconsistentValue,' then the=20 process must be repeated; If the Set succeeds, then the object is incremented, and the new instance is created according to=20 the manager's directions. However, if the RTP agent is not = acting=20 as a monitor, only the RTP agent may create conceptual rows in = the RTP session table." =20 ::=3D { rtpMIBObjects 1 } -- -- SESSION INVERSE TABLE -- rtpSessionInverseTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF RtpSessionInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Maps rptSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr to an unsigned integer index, rtpSessionInverseIndex, which has the rtpSessionIndex=20 value that maps to the same rtpSessionDomain,=20 rtpSessionRemAddr, and rtpSessionLocAddr in the=20 rtpSessionTable. rtpSessionIndex can thereby be retrieved based upon the domain and TAdress pair that uniquely define an RTP Session." ::=3D { rtpMIBObjects 2 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 9] =0C Internet Draft RTP MIB October 1999 rtpSessionInverseEntry OBJECT-TYPE =20 SYNTAX RtpSessionInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Each entry corresponds to exactly one entry in the rtpSessionTable - the entry containing the triple, rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr." INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr,=20 rtpSessionIndex } ::=3D { rtpSessionInverseTable 1 } RtpSessionInverseEntry ::=3D SEQUENCE { =20 rtpSessionInverseStartTime TimeStamp =20 } rtpSessionInverseStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSessionInverseEntry 1 } -- =20 -- SESSION TABLE -- rtpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "There's one entry in rtpSessionTable for each RTP session on which packets are being sent, received, and/or=20 monitored." =20 ::=3D { rtpMIBObjects 3 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 10] =0C Internet Draft RTP MIB October 1999 rtpSessionEntry OBJECT-TYPE =20 SYNTAX RtpSessionEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Data in rtpSessionTable uniquely identify an RTP session. A = host=20 RTP agent will create a read-only row for each session to which=20 packets are being sent or received. Rows are created by the=20 RTP Agent at the start of a session when one or more senders or=20 receivers are observed. Rows created by an RTP agent are = deleted=20 when the session is over and there are no rtpRcvrEntry and no=20 rtpSenderEntry for this session. An RTP session can be = monitored=20 to create management information on all RTP streams being sent = or=20 received when the rtpSessionMonitor has the TruthValue of = 'true(1)'. =20 An RTP monitor may permit row creation with the side effect of=20 causing the RTP System to join the multicast session for the=20 purposes of gathering management information (additional = conceptual=20 rows are created in the rtpRcvrTable and rtpSenderTable). Thus, = rtpSessionTable rows can be created for RTP session monitoring=20 purposes. Rows created by a management application may be = deleted=20 via SNMP operations by management applications. Rows created by = management operations are deleted by management operations by = setting=20 rtpSessionRowStatus to 'destroy(6)'." INDEX { rtpSessionIndex } =20 ::=3D { rtpSessionTable 1 } RtpSessionEntry ::=3D SEQUENCE { =20 rtpSessionIndex Integer32, rtpSessionDomain TDomain, =20 rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus =20 } Baugher, Strahm, Suconick Expires Feb 6, 2000 [Page = 11] =0C Internet Draft RTP MIB October 1999 rtpSessionIndex OBJECT-TYPE =20 SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "The index of the conceptual row which is for SNMP purposes only and has no relation to any protocol value. There is no requirement that these rows are created or maintained sequentially." ::=3D { rtpSessionEntry 1 }=20 rtpSessionDomain OBJECT-TYPE SYNTAX TDomain =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "The transport-layer protocol used for sending or receiving the stream of RTP data packets on this session. Cannot be changed if rtpSessionRowStatus is 'active'." ::=3D { rtpSessionEntry 2 } rtpSessionRemAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-create =20 STATUS current DESCRIPTION "The address to which RTP packets are sent by the RTP system. In = an IP multicast RTP session, this is the single address used by all = senders and receivers of RTP session data. In a unicast RTP = session=20 this is the unicast address of the remote RTP system. 'The=20 destination address pair may be common for all participants, as = in=20 the case of IP multicast, or may be different for each, as in = the=20 case of individual unicast network address pairs.' See RFC = 1889,=20 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. = The transport service is identified by rtpSessionDomain. For=20 rtpUDPDomain, this is an IP address and even-numbered UDP Port=20 with the RTCP being sent on the next higher odd-numbered port,=20 see RFC 1889, sec. 5. Cannot be changed if rtpSessionRowStatus=20 is 'active'." =20 ::=3D { rtpSessionEntry 3 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 12] =0C Internet Draft RTP MIB September 1999 rtpSessionLocAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The local address used by the RTP system. In an IP multicast = RTP=20 session, rtpSessionRemAddr will be the same IP multicast address = as=20 rtpSessionLocAddr. In a unicast RTP session, rtpSessionRemAddr = and=20 rtpSessionLocAddr will have different unicast addresses. See = RFC=20 1889, 'RTP: A Transport Protocol for Real-Time Applications,' = sec.=20 3. The transport service is identified by rtpSessionDomain. = For=20 rtpUDPDomain, this is an IP address and even-numbered UDP Port=20 with the RTCP being sent on the next higher odd-numbered port,=20 see RFC 1889, sec. 5." ::=3D { rtpSessionEntry 4 } rtpSessionIfIndex OBJECT-TYPE SYNTAX InterfaceIndex =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "The ifIndex value is set to the corresponding value=20 from IF-MIB (See RFC 2233, 'The Interfaces Group MIB using=20 SMIv2'). This is the interface that the RTP stream is being sent to or received from, or in the case of an RTP Monitor the=20 interface that RTCP packets will be received on. Cannot be=20 changed if rtpSessionRowStatus is 'active'." =20 ::=3D { rtpSessionEntry 5 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 13] =0C Internet Draft RTP MIB October 1999 rtpSessionSenderJoins OBJECT-TYPE SYNTAX Counter32 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "The number of senders that have been observed to have joined the session since this conceptual row was created (rtpSessionStartTime). A sender 'joins' an RTP session by sending to it. Senders that leave and then=20 re-join following an RTCP BYE (see RFC 1889, 'RTP: A=20 Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice. Every time a new RTP sender is detected either using RTP or RTCP, this counter is incremented." =20 ::=3D { rtpSessionEntry 6 } rtpSessionReceiverJoins OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The number of receivers that have been been observed to have joined this session since this conceptual row was created (rtpSessionStartTime). A receiver 'joins' an RTP session by sending RTCP Receiver Reports to the session. Receivers that leave and then re-join following an RTCP BYE=20 (see RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications,' sec. 6.6) or session timeout may be counted=20 twice." =20 ::=3D { rtpSessionEntry 7 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 14] =0C Internet Draft RTP MIB October 1999 rtpSessionByes OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of RTCP BYE (see RFC 1889, 'RTP: A Transport=20 Protocol for Real-Time Applications,' sec. 6.6) messages=20 received by this entity." =20 ::=3D { rtpSessionEntry 8 } rtpSessionStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSessionEntry 9 } rtpSessionMonitor OBJECT-TYPE =20 SYNTAX TruthValue MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Boolean, Set to 'true(1)' if senders or receivers in=20 addition to the local RTP System are to be monitored using RTCP. = =20 RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD=20 initialize this 'false(2)'. Note that because 'host monitor'=20 systems are receiving RTCP from their remote participants they MUST set this value to 'true(1)'." ::=3D { rtpSessionEntry 10 } rtpSessionRowStatus OBJECT-TYPE SYNTAX RowStatus =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "Value of 'active' when RTP or RTCP messages are being=20 sent or received by an RTP System. A newly-created conceptual row must have the all read-create objects initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes." ::=3D { rtpSessionEntry 11 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 15] =0C Internet Draft RTP MIB October 1999 -- -- SENDER INVERSE TABLE -- rtpSenderInverseTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF RtpSenderInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Maps rtpSenderAddr, rtpSessionIndex, to the rtpSenderSSRC=20 index of the rtpSenderTable. This table allows management=20 applications to find entries sorted by rtpSenderAddr rather than sorted by rtpSessionIndex. Given the rtpSessionDomain and=20 rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values can be returned from a tree walk. When rtpSessionIndex is specified in the SNMP Get-Next operations, one or more=20 rtpSenderSSRC values may be returned." ::=3D { rtpMIBObjects 4 } rtpSenderInverseEntry OBJECT-TYPE =20 SYNTAX RtpSenderInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Each entry corresponds to exactly one entry in the rtpSenderTable - the entry containing the index pair, rtpSessionIndex, rtpSenderSSRC." INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex,=20 rtpSenderSSRC } ::=3D { rtpSenderInverseTable 1 } RtpSenderInverseEntry ::=3D SEQUENCE { =20 rtpSenderInverseStartTime TimeStamp =20 } rtpSenderInverseStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSenderInverseEntry 1 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 16] =0C Internet Draft RTP MIB October 1999 -- -- SENDERS TABLE -- rtpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Table of information about a sender or senders to an RTP=20 Session. RTP sending hosts MUST have an entry in this table=20 for each stream being sent. RTP receiving hosts MAY have an=20 entry in this table for each sending stream being received=20 by this host. RTP monitors create an entry for each observed=20 sender to a multicast RTP Session as a side-effect when a=20 conceptual row in the rtpSessionTable is made 'active' by a=20 manager." =20 ::=3D { rtpMIBObjects 5 } rtpSenderEntry OBJECT-TYPE =20 SYNTAX RtpSenderEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Each entry contains information from a single RTP Sender=20 Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport=20 Protocol for Real-Time Applications' sec.6). The session is identified to the the SNMP entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted." INDEX { rtpSessionIndex, rtpSenderSSRC } =20 ::=3D { rtpSenderTable 1 } RtpSenderEntry ::=3D SEQUENCE { =20 rtpSenderSSRC Unsigned32, rtpSenderCNAME Utf8String, rtpSenderAddr TAddress, rtpSenderPackets Counter64, rtpSenderOctets Counter64, rtpSenderTool Utf8String, rtpSenderSRs Counter32, rtpSenderSRTime TimeStamp, =20 rtpSenderPT INTEGER, rtpSenderStartTime TimeStamp =20 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 17] =0C Internet Draft RTP MIB October 1999 rtpSenderSSRC OBJECT-TYPE =20 SYNTAX Unsigned32 MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely=20 identify a sender to an RTP session (see RFC 1889, 'RTP: A=20 Transport Protocol for Real-Time Applications' sec.3)." =20 ::=3D { rtpSenderEntry 1 } rtpSenderCNAME OBJECT-TYPE =20 SYNTAX Utf8String MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The RTP canonical name of the sender." =20 ::=3D { rtpSenderEntry 2 } rtpSenderAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The unicast transport source address of the sender. In the case = of=20 an RTP Monitor this address is the address that the sender is = using=20 to send its RTCP Sender Reports." ::=3D { rtpSenderEntry 3 } rtpSenderPackets OBJECT-TYPE SYNTAX Counter64 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Count of RTP packets sent by this sender, or observed by an RTP monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 4 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 18] =0C Internet Draft RTP MIB October 1999 rtpSenderOctets OBJECT-TYPE =20 SYNTAX Counter64 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Count of RTP octets sent by this sender, or observed by an RTP monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 5 } rtpSenderTool OBJECT-TYPE SYNTAX Utf8String (SIZE(0..127)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Name of the application program source of the stream." ::=3D { rtpSenderEntry 6 } rtpSenderSRs OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of the number of RTCP Sender Reports that have=20 been sent from this sender, or observed if the RTP entity is a monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 7 } rtpSenderSRTime OBJECT-TYPE SYNTAX TimeStamp =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "rtpSenderSRTime is the value of SysUpTime at the time that the last SR was received from this sender, in the case of a monitor or receiving host. Or sent by this sender, in the=20 case of a sending host." =20 ::=3D { rtpSenderEntry 8 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 19] =0C Internet Draft RTP MIB October 1999 rtpSenderPT OBJECT-TYPE =20 SYNTAX INTEGER (0..127) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Payload type from the RTP header of the most recently received=20 RTP Packet (see RFC 1889, 'RTP: A Transport Protocol for=20 Real-Time Applications' sec. 5)." =20 ::=3D { rtpSenderEntry 9 } rtpSenderStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSenderEntry 10 } -- -- RECEIVER INVERSE TABLE -- rtpRcvrInverseTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF RtpRcvrInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Maps rtpRcvrAddr and rtpSessionIndex to the rtpRcvrSRCSSRC and =20 rtpRcvrSSRC indexes of the rtpRcvrTable. This table allows=20 management applications to find entries sorted by rtpRcvrAddr rather than by rtpSessionIndex. Given rtpSessionDomain and=20 rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and rtpRcvrSSRC values can be returned from a tree walk. When=20 rtpSessionIndex is specified in SNMP Get-Next operations, one or = more rtpRcvrSRCSSRC and rtpRcvrSSRC pairs may be returned." ::=3D { rtpMIBObjects 6 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 20] =0C Internet Draft RTP MIB October 1999 rtpRcvrInverseEntry OBJECT-TYPE =20 SYNTAX RtpRcvrInverseEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Each entry corresponds to exactly one entry in the rtpRcvrTable - the entry containing the index pair, rtpSessionIndex, rtpRcvrSSRC." INDEX { rtpSessionDomain, rtpRcvrAddr, rtpSessionIndex,=20 rtpRcvrSRCSSRC, rtpRcvrSSRC } ::=3D { rtpRcvrInverseTable 1 } RtpRcvrInverseEntry ::=3D SEQUENCE { =20 rtpRcvrInverseStartTime TimeStamp =20 } rtpRcvrInverseStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpRcvrInverseEntry 1 } -- -- RECEIVERS TABLE -- rtpRcvrTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF RtpRcvrEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Table of information about a receiver or receivers of RTP=20 session data. RTP hosts that receive RTP session packets=20 MUST create an entry in this table for that receiver/sender=20 pair. RTP hosts that send RTP session packets MAY create an entry in this table for each receiver to their stream using RTCP feedback from the RTP group. RTP monitors=20 create an entry for each observed RTP session receiver as a side effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::=3D { rtpMIBObjects 7 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 21] =0C Internet Draft RTP MIB October 1999 rtpRcvrEntry OBJECT-TYPE =20 SYNTAX RtpRcvrEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Each entry contains information from a single RTP=20 Synchronization Source that is receiving packets from the=20 sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889,=20 'RTP: A Transport Protocol for Real-Time Applications'=20 sec.6). The session is identified to the the SNMP entity by=20 rtpSessionIndex. Rows are removed by the RTP agent when=20 a BYE is received from the sender or when the sender times=20 out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is=20 deleted." INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } ::=3D { rtpRcvrTable 1 } RtpRcvrEntry ::=3D SEQUENCE { rtpRcvrSRCSSRC Unsigned32, =20 rtpRcvrSSRC Unsigned32, rtpRcvrCNAME Utf8String, rtpRcvrAddr TAddress, =20 rtpRcvrRTT Gauge32, rtpRcvrLostPackets Counter64, =20 rtpRcvrJitter Gauge32, rtpRcvrTool Utf8String, rtpRcvrRRs Counter32, rtpRcvrRRTime TimeStamp, =20 rtpRcvrPT INTEGER,=20 rtpRcvrPackets Counter64, =20 rtpRcvrOctets Counter64, rtpRcvrStartTime TimeStamp =20 } rtpRcvrSRCSSRC OBJECT-TYPE SYNTAX Unsigned32 =20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely=20 identify a sender or receiver of an RTP stream (see RFC=20 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications' sec.3)." =20 ::=3D { rtpRcvrEntry 1 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 22] =0C Internet Draft RTP MIB October 1999 rtpRcvrSSRC OBJECT-TYPE =20 SYNTAX Unsigned32 MAX-ACCESS not-accessible =20 STATUS current =20 DESCRIPTION "The RTP SSRC, or synchronization source identifier of the receiver. The RTP session address plus an SSRC uniquely=20 identify a receiver of an RTP stream (see RFC 1889, 'RTP: =20 A Transport Protocol for Real-Time Applications' sec.3)." =20 ::=3D { rtpRcvrEntry 2 } rtpRcvrCNAME OBJECT-TYPE =20 SYNTAX Utf8String MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The RTP canonical name of the receiver." =20 ::=3D { rtpRcvrEntry 3 } rtpRcvrAddr OBJECT-TYPE =20 SYNTAX TAddress =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "The unicast transport address on which the receiver is receiving = RTP=20 packets. In the case of an RTP Monitor this address is the = local address of the receiver on which it is sending RTCP Receiver = Report=20 packet is received." ::=3D { rtpRcvrEntry 4 } rtpRcvrRTT OBJECT-TYPE =20 SYNTAX Gauge32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The round trip time measurement taken by the source of the=20 RTP stream based on the algorithm described on sec. 6 of=20 RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications.' This algorithm can produce meaningful=20 results when the RTP agent has the same clock as the stream=20 sender (when the RTP monitor is also the sending host for the particular reciever). Otherwise, the entity should return=20 'noSuchInstance' in response to queries against rtpRcvrRTT." ::=3D { rtpRcvrEntry 5 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 23] =0C Internet Draft RTP MIB October 1999 rtpRcvrLostPackets OBJECT-TYPE =20 SYNTAX Counter64=20 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of RTP packets lost as observed by this receiver since rtpRcvrStartTime." =20 ::=3D { rtpRcvrEntry 6 } rtpRcvrJitter OBJECT-TYPE =20 SYNTAX Gauge32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "An estimate of delay variation as observed by this=20 receiver. (see RFC 1889, 'RTP: A Transport Protocol=20 for Real-Time Applications' sec.6.3.1 and A.8)." ::=3D { rtpRcvrEntry 7 } rtpRcvrTool OBJECT-TYPE =20 SYNTAX Utf8String (SIZE(0..127)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Name of the application program source of the stream." ::=3D { rtpRcvrEntry 8 } rtpRcvrRRs OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of the number of RTCP Receiver Reports that have=20 been sent from this receiver, or observed if the RTP entity is a monitor, since rtpRcvrStartTime." ::=3D { rtpRcvrEntry 9 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 24] =0C Internet Draft RTP MIB October 1999 rtpRcvrRRTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "rtpRcvrRRTime is the value of SysUpTime at the time that the=20 last RTCP Receiver Report was received from this receiver, in=20 the case of a monitor or RR receiver (the RTP Sender). It is=20 the value of SysUpTime at the time that the last RR was sent by = this receiver in the case of an RTP receiver sending the RR." ::=3D { rtpRcvrEntry 10 } rtpRcvrPT OBJECT-TYPE SYNTAX INTEGER (0..127) =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Static or dynamic payload type from the RTP header (see=20 RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications' sec. 5)." =20 ::=3D { rtpRcvrEntry 11 } rtpRcvrPackets OBJECT-TYPE =20 SYNTAX Counter64 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Count of RTP packets received by this RTP host receiver=20 since rtpRcvrStartTime." ::=3D { rtpRcvrEntry 12 } rtpRcvrOctets OBJECT-TYPE SYNTAX Counter64 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Count of RTP octets received by this receiving RTP host=20 since rtpRcvrStartTime." ::=3D { rtpRcvrEntry 13 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 25] =0C Internet Draft RTP MIB October 1999 rtpRcvrStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpRcvrEntry 14 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 26] =0C Internet Draft RTP MIB October 1999 -- -- MODULE GROUPS -- rtpGroups OBJECT IDENTIFIER ::=3D { rtpConformance 1 } rtpSystemGroup OBJECT-GROUP =20 OBJECTS { rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionSenderJoins, rtpSessionReceiverJoins, rtpSessionStartTime, rtpSessionByes, =20 rtpSessionMonitor, rtpSenderCNAME, =20 rtpSenderAddr, rtpSenderPackets, =20 rtpSenderOctets, rtpSenderTool, =20 rtpSenderSRs, rtpSenderSRTime, rtpSenderStartTime, =20 rtpRcvrCNAME, rtpRcvrAddr, =20 rtpRcvrLostPackets, rtpRcvrJitter, =20 rtpRcvrTool, rtpRcvrRRs, =20 rtpRcvrRRTime, rtpRcvrStartTime =20 } STATUS current =20 DESCRIPTION =20 "Objects used by all RTP systems." =20 ::=3D { rtpGroups 1 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 27] =0C Internet Draft RTP MIB October 1999 rtpHostGroup OBJECT-GROUP =20 OBJECTS { rtpSessionLocAddr, =20 rtpSenderPT, rtpRcvrPT, =20 rtpRcvrRTT, rtpRcvrOctets, =20 rtpRcvrPackets } =20 STATUS current =20 DESCRIPTION =20 "Objects used by all RTP Host systems and optionally by=20 RTP Monitor systems." =20 ::=3D { rtpGroups 2 } rtpMonitorGroup OBJECT-GROUP =20 OBJECTS { rtpSessionNewIndex, =20 rtpSessionRowStatus } STATUS current =20 DESCRIPTION "Objects used by RTP monitor systems." =20 ::=3D { rtpGroups 3 } rtpInverseGroup OBJECT-GROUP OBJECTS { rtpSessionInverseStartTime, rtpSenderInverseStartTime, rtpRcvrInverseStartTime } STATUS current DESCRIPTION "Objects used in the Inverse Lookup Tables." ::=3D { rtpGroups 4 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 28] =0C Internet Draft RTP MIB October 1999 -- -- Compliance -- rtpCompliances OBJECT IDENTIFIER ::=3D { rtpConformance 2 } rtpHostCompliance MODULE-COMPLIANCE =20 STATUS current DESCRIPTION =20 "Host implementations must comply." MODULE RTP-MIB =20 MANDATORY-GROUPS { rtpSystemGroup, rtpHostGroup } GROUP rtpMonitorGroup DESCRIPTION "The objects in the rtpHostGroup MUST be implemented=20 in RTP host systems, i.e., that are the source or the=20 destination of RTP data packets." GROUP rtpInverseGroup DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSessionNewIndex MIN-ACCESS not-accessible =20 DESCRIPTION "RTP system implementations support of row creation and deletion is OPTIONAL so implementation of this object is OPTIONAL." OBJECT rtpSessionDomain =20 MIN-ACCESS read-only DESCRIPTION "RTP system implementation support of row creation and deletion is OPTIONAL. When it is not supported so write access is=20 OPTIONAL." =20 OBJECT rtpSessionRemAddr MIN-ACCESS read-only =20 DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionIfIndex =20 MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." Baugher, Strahm, Suconick Expires April 27, 2000 [Page 29] =0C Internet Draft RTP MIB October 1999 OBJECT rtpSessionRowStatus =20 MIN-ACCESS not-accessible DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." ::=3D { rtpCompliances 1 } Baugher, Strahm, Suconick Expires April 27, 2000 [Page 30] =0C Internet Draft RTP MIB October 1999 rtpMonitorCompliance MODULE-COMPLIANCE =20 STATUS current DESCRIPTION =20 "Monitor implementations must comply. RTP Monitors are not=20 required to support creation or deletion." MODULE RTP-MIB =20 MANDATORY-GROUPS {=20 rtpSystemGroup, rtpMonitorGroup } GROUP rtpHostGroup DESCRIPTION "The objects in the rtpMonitorGroup MUST be implemented in RTP monitors." =20 GROUP rtpInverseGroup DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSessionLocAddr =20 MIN-ACCESS not-accessible DESCRIPTION "RTP monitor sourcing of RTP or RTCP data packets=20 is OPTIONAL and implementation of this object is=20 OPTIONAL." OBJECT rtpRcvrPT MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems NEED NOT support retrieval of the RTP Payload Type from the RTP=20 header (and may receive RTCP messages only). When queried for the payload type information" OBJECT rtpSenderPT =20 MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems NEED NOT support retrieval of the RTP Payload Type from the RTP=20 header (and may receive RTCP messages only). When queried for the payload type information." OBJECT rtpRcvrOctets MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL" =20 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 31] =0C Internet Draft RTP MIB October 1999 OBJECT rtpRcvrPackets MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL." =20 OBJECT rtpSessionIfIndex =20 MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION "Multicast RTP Systems SHOULD implement the optional tables." ::=3D { rtpCompliances 2 } END Baugher, Strahm, Suconick Expires April 27, 2000 [Page 32] =0C Internet Draft RTP MIB October 1999 4. Security Issues In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a=20 system, or to change some parameter at the system, is a tool, not a=20 threat. However, there are a number of management objects defined in = this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Suc= h objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. None of the read-only objects in this MIB reports a password, though some SDES [RFC1889] items such as the CNAME [RFC1889], the canonical = name,=20 may be deemed sensitive depending on the security policies of a = particular=20 enterprise. If access to these objects is not limited by an=20 appropriate access control policy, these objects can provide an=20 attacker with information about a system's configuration and the=20 services that that system is providing. Some enterprises view their=20 network and system configurations, as well as information about=20 usage and performance, as corporate assets; such enterprises may=20 wish to restrict SNMP access to most of the objects in the MIB. This MIB supports read-write operations against rtpSessionNewIndex=20 which has the side effect of creating an entry in the rtpSessionTable=20 when it is written to. Five objects in rtpSessionEntry have=20 read-create access: rtpSessionDomain, rtpSessionRemAddr,=20 rtpSessionIfIndex, rtpSessionRowStatus, and rtpSessionIfAddr identify = an RTP session to be monitored on a particular interface. The values of these = objects are not to be changed once created, and initialization of these = objects affects only the monitoring of an RTP session and not the=20 operation of an RTP session on any host end-system. Since write=20 operations to rtpSessionNewIndex and the five objects in=20 rtpSessionEntry affect the operation of the monitor, write access to=20 these objects should be subject to the appropriate access control=20 policy. Confidentiality of RTP and RTCP data packets is defined in section 9 of = the RTP specification [RFC1889]. Encryption may be performed on RTP = packets, RTCP packets, or both. Encryption of RTCP packets may pose a problem for third-party monitors though "For RTCP, it is allowed to split a compound RTCP 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=20 accommodate third-party monitors [RFC1889]." =20 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 33] =0C Internet Draft RTP MIB October 1999 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5. Acknowledgements The authors wish to thank Bert Wijnen and the participants from the=20 ITU SG-16 management effort for their helpful comments. Alan Batie and Bill Lewis from Intel also contributed greatly to the RTP MIB through their review of various drafts of the MIB and their work on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com=20 and John Du from Intel contributed to the original RTP MIB design and=20 co-authored the original RTP MIB draft documents; much of their work=20 remains in the current RTP MIB. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Baugher, Strahm, Suconick Expires April 27, 2000 [Page 34] =0C Internet Draft RTP MIB October 1999 7. References [RFC1889] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, = "RTP: A Transport Protocol for real-time applications," RFC 1889. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An = Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April = 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, = "Message Processing and Dispatching for the Simple Network = Management Protocol (SNMP)", RFC 2572, April 1999 =20 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 35] =0C Internet Draft RTP MIB October 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 36] =0C Internet Draft RTP MIB October 1999 8. Authors Addresses Mark Baugher Email: mbaugher@intel.com Intel Corporation 2111 N.E.25th Avenue =20 Hillsboro, Oregon 97124 U.S.A. =20 Bill Strahm Email: Bill.Strahm@intel.com =20 Intel Corporation 2111 N.E.25th Avenue =20 Hillsboro, Oregon 97124 U.S.A. =20 Irina Suconick Email: isuconick@videoserver.com Videoserver Corporation 63 Third Street Burlington, Massachusetts 01803 U.S.A. 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. =20 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=20 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. =20 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =20 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. =20 Baugher, Strahm, Suconick Expires April 27, 2000 [Page 37] =0C ------_=_NextPart_000_01BF1CBB.FACE2E27-- From rem-conf-request@es.net Fri Oct 22 16:32:27 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05491 for ; Fri, 22 Oct 1999 16:32:26 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11el65-0006jy-00; Fri, 22 Oct 1999 13:15:33 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11el63-0006jo-00; Fri, 22 Oct 1999 13:15:31 -0700 Received: from pigpen (PPPa16-ResaleRedBank1-3R1082.saturn.bbn.com [4.16.164.123]) by mail.pi.se (8.8.8/8.8.8) with SMTP id WAA20093; Fri, 22 Oct 1999 22:15:09 +0200 (MET DST) From: "Gunnar Hellstrom" To: "Internet drafts" , "IETF-avt list" Cc: "Michele Mizzaro" , "Mickey Nasiri (ECS)" Subject: New version of draft-ietf-avt-rtp-text Date: Fri, 22 Oct 1999 22:13:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01BF1CDA.BAD78D00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF1CDA.BAD78D00 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id WAA20093 Content-Transfer-Encoding: quoted-printable Please find the attached new revision of the RTP-text specification to be reviewed in the Washington IETF / avt meeting. File name: draft-ietf-avt-rtp-text-02.txt Main changes: Stricting up nomenclature. Send empty packets to squeeze out redundant packets. Specify order of redundant data for recovery procedure to work. Regards Gunnar Hellstr=F6m ______________________________________ Gunnar Hellstr=F6m LM Ericsson Sweden Mob +46 708 204 288 Tel +46 8 556 002 03 Fax +46 8 556 002 06 Video +468 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom@omnitor.se ------=_NextPart_000_000D_01BF1CDA.BAD78D00 Content-Type: text/plain; name="draft-ietf-avt-rtp-text-02.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtp-text-02.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force AVT WG Internet Draft Gunnar Hellstrom draft-ietf-avt-rtp-text-02.txt LM Ericsson October 22, 1999 Expires: April 22, 2000 RTP Payload for Text Conversation STATUS OF THIS MEMO This document is an Internet-Draft and it 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/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. ABSTRACT This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. Hellstrom [Page 1] Internet Draft 1 Introduction This memo defines a payload type for carrying text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. Text in text conversation sessions is sent as soon as it is available, or with a small delay for buffering. The text is supposed to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per second or less. Therefore, the expected number of characters to transmit is low. Only one or a few new characters are expected to be transmitted with each packet. T.140 specifies that text and other T.140 elements SHALL be transmitted in ISO 10 646-1 code with UTF-8 transformation. That makes it easy to implement internationally useful applications, and to handle the text in modern information technology environments. The payload of an RTP packet following this specification consists of text encoded according to T.140 without any additional framing. A common case will be a single ISO 10646 character, UTF-8 encoded. T.140 requires the transport channel to provide characters without duplication and in original order. Text conversation users expect that text will be delivered with no or a low level of lost information. If lost information can be indicated, the willingness to accept loss is expected to be higher. Therefore a mechanism based on RTP is specified here. It gives text arrival in correct order, without duplications, and with detection and indication of losses. It also includes an optional possibility to repeat data for redundancy to lower the risk of loss. Since packet overhead is usually much larger than the T.140 contents, the increase in channel load by the redundancy scheme is minimal. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4] Hellstrom [Page 2] Internet Draft 2. Usage of RTP When transport of T.140 text session data in RTP is desired, the payload as described in this specification SHOULD be used. A text conversation RTP packet as specified by this payload format consists of an RTP header as defined in RFC 1889 [2] followed immediately by a block of T.140 data, defined here to be a "T140block". There is no additional header specific to this payload format. The T140block contains one or more T.140 code elements as specified in [1]. Most T.140 code elements are single ISO 10646 [5] characters, but some are multiple character sequences. Each character is UTF-8 encoded [6] into one or more octets. The T140blocks MAY be transmitted redundantly according to the payload format defined in RFC 2198 [3]. In that case, the RTP header is followed by one or more redundant data block headers, the same number of redundant data fields carrying T140blocks from previous packets, and finally the new (primary) T140block for this packet. 2.1 RTP packet header Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for T.140 text streams: Payload Type (PT): The assignment of an RTP payload type is specific to the RTP profile under which this payload format is used. For profiles which use dynamic payload type number assignment, this payload format is identified by the name "T140" (see section 6). If redundancy is used per RFC 2198, the Payload Type SHALL indicate that payload format ("RED"). Sequence number: The Sequence Number SHALL be increased by one for each new transmitted packet. It is used for detection of packet loss and packets out of order, and can be used in the process of retrieval of redundant text, reordering of text and marking missing text. Timestamp: The RTP Timestamp encodes the approximate sampling instance of the primary text in the packet. A clock frequency of 1000 Hz SHALL be used. Sequential packets MUST NOT use the same timestamp because the timestamps are used for sequencing of redundant T140blocks. Hellstrom [Page 3] Internet Draft 2.2 Additional headers There are no additional headers defined specific to this payload format. When redundant transmission of the data according to RFC 2198 is desired, the RTP header is followed by one or more redundant data block headers, one for each redundant data block to be included. Each of these headers provides the timestamp offset and length of the corresponding data block plus a payload type number indicating this payload format ("T140"). 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra framing. When using the format with redundant data, the transmitter MAY select a number of T140block generations to retransmit in each packet. A higher number introduces better protection against loss of text but increases the data rate. Because the redundant data block headers do not contain sequence number information, some rules must be followed to allow the redundant data corresponding to missing primary to be merged properly into the stream of primary data T140blocks: - Each redundant data block MUST contain the same data as a T140block previously transmitted as primary data, and be identified with a timestamp offset equating to the original timestamp for that T140block. - The redundant data MUST be placed in age order with most recent redundant T140block last in the redundancy area. - All T140blocks from the oldest desired generation up through the generation immediately preceding the new (primary) T140block MUST be included. These rules allow the sequence numbers for the redundant T140blocks to be inferred by counting backwards from the sequence number in the RTP header. The result will be that all the text in the payload will be contiguous and in order. 3. Recommended procedures This section contains RECOMMENDED procedures for usage of the payload format. Based on the information in the received packets, the receiver can: - reorder received text out of order. - mark where text is missing because of packet loss. - compensate for lost packets by using redundant data. Hellstrom [Page 4] Internet Draft 3.1 Recommended basic procedure On reception, the RTP sequence number is compared with the sequence number of the last correctly received packet. If they are consecutive, the T140block is retrieved from the packet. If redundant transmission is in use, any redundant data blocks in the received packet are ignored and only the new (primary) T140block is retrieved. 3.2 Recommended procedure for compensation for lost packets. For reduction of data loss in case of packet loss, redundant data MAY be included in the packets following to the procedures in RFC 2198. If network conditions are not known, it is RECOMMENDED to use one redundant T140block in each packet. If there is a gap in the RTP sequence numbers, and redundant T140blocks are available in a subsequent packet, the sequence numbers for the redundant T140blocks should be inferred by counting backwards from the sequence number in the RTP header for that packet. If there are redundant T140blocks with sequence numbers matching those that are missing, the redundant T140blocks may be substituted for the missing T140blocks. Both for the case when redundancy is used and not used, missing data SHOULD be marked. T.140 defines a missing data marker (Unicode character 2607 "Lightning") which SHOULD be used as a marker to indicate each missing T140block. 3.3 Recommended procedure for compensation for packets out of order. For protection against packets arriving out of order, the following procedure MAY be implemented in the receiver. If analysis of a received packet reveals a gap in the sequence and no redundant data is available to fill that gap, the received packet can be kept in a buffer to allow time for the missing packet(s) to arrive. It is suggested that the waiting time be limited to 0.5 second or until three packets subsequent to the missing packet(s) have arrived, whichever is shorter. If a packet with a T140block belonging to the gap arrives before the waiting time expires, this T140block is inserted into the gap and then consecutive T140blocks from the leading edge of the gap may be consumed. Any T140block which does not arrive before the time limit expires should be treated as lost. Hellstrom [Page 5] Internet Draft 3.4 Transmission during "silent periods" when redundancy is used. When using the redundancy transmission scheme, and there is nothing more to transmit from T.140, the latest T140block has a risk of getting old before it is transmitted as redundant data. The result is less useful protection against packet loss at the end of a text input sequence. For cases where this should be avoided, a zero-length primary T140block MAY be transmitted with the redundant data. Any zero-length T140blocks that are sent as primary data SHOULD be included as redundant T140blocks on subsequent packets just as normal text T140blocks would be so that sequence number inference for the redundant T140blocks will be correct, as explained in section 2.3. Redundancy for the last T140block SHOULD NOT be implemented by repeatedly transmitting the same packet (with the same sequence number) because this will cause the packet loss count, as reported in RTCP, to decrement. Hellstrom [Page 6] Internet Draft 4. Examples This is an example of a T140 RTP packet without redundancy. 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=0 |M| T140 PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (1000Hz) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + T.140 encoded data + | | + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is an example of an RTP packet with one redundant T140block. 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=0 |M| "RED" PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding "P" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| T140 PT | timestamp offset of "R" | "R" block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| T140 PT | | +-+-+-+-+-+-+-+-+ + | | + "R" T.140 encoded redundant data + | | + +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | "P" T.140 encoded primary data | + + + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure: Examples of RTP text packets. Hellstrom [Page 7] Internet Draft 5. Security Considerations. Since the intention of the described payload format is to carry text in a text conversation, security measures in the form of encryption are of importance. The amount of data in a text conversation session is low and therefore any encryption method MAY be selected and applied to T.140 session contents or to the whole RTP packets. When redundant data is included, the same security considerations as for RFC 2198 apply. 6 MIME Media Type Registrations This document defines a new RTP payload name and associated MIME type, T140 (text/t140). The registration form for this MIME type has been submitted to IANA. 6.1 Registration of MIME media type text/t140 MIME media type name: text MIME subtype name: t140 Required parameters: None Optional parameters: None Encoding considerations: T140 text can be transmitted with RTP as specified in "draft-ietf-avt-rtp-text-02". Security considerations: None Interoperability considerations: None Published specification: ITU-T T.140 Recommendation. draft-ietf-avt-rtp-text-02. Applications which use this media type: Text communication terminals and text conferencing tools. Additional information: None Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Intended usage: COMMON Author/Change controller: Gunnar Hellstrom e-mail: gunnar.hellstrom@omnitor.se Hellstrom [Page 8] Internet Draft Expires: April 22, 2000 7. Author's Address Gunnar Hellstrom Ericsson Mobile Communication AB Home Communications SE-164 80 Stockholm Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 8 References [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1999. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889. [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, "RTP payload for redundant audio data," RFC 2198, Internet Engineering Task Force, Sept. 1997. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character Set [6] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 2279, Internet Engineering Task Force, Jan. 1998. 9 Revision history. Oct 6 1999. draft-01. Explanations in recommended procedures improved. Oct 22 1999. draft-02. Nomenclature, ordering of redundant packets, send empty info to expire redundancy. Hellstrom [Page 9] ------=_NextPart_000_000D_01BF1CDA.BAD78D00-- From rem-conf-request@es.net Fri Oct 22 16:33:33 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05513 for ; Fri, 22 Oct 1999 16:33:32 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11el2q-0006hW-00; Fri, 22 Oct 1999 13:12:12 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 11el2n-0006hM-00; Fri, 22 Oct 1999 13:12:09 -0700 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA13096 for ; Fri, 22 Oct 1999 13:11:04 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 22 Oct 1999 13:11:50 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id NAA09058 for ; Fri, 22 Oct 1999 13:11:49 -0700 (PDT) MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: Date: Fri, 22 Oct 1999 13:09:59 -0700 To: rem-conf@es.net From: Dave Singer Subject: Updated hint track format Content-Type: multipart/mixed; boundary="============_-1271499387==_============" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --============_-1271499387==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" The MPEG folks have asked that we update the hint track format specification for RTP hint tracks in QuickTime files to both bodies. I have sent this in to the IETF but it seems to be having trouble getting through. It is provided as an informative and discussion document at this point. I'll be available to discuss it in Washington, if appropriate. --============_-1271499387==_============ Content-ID: Content-Type: application/mac-binhex40; name="draft-singer-rtp-qtfile-01.txt" Content-Disposition: attachment; filename="draft-singer-rtp-qtfile-01.txt" ; modification-date="Thu, 21 Oct 1999 12:39:16 -0700" (This file must be converted with BinHex 4.0) :(Q4bB@Cd,A0TEQGPFLebG(!YFA4QD@aP,6!a,R4iG!"849K869"6)!%!!!"mpJ! !!Ai,L!S+#JS+#NPZG'9bEQ9d)%9ZCfPZC@9bD@jR)&4KFfXJ4QpbBf8J)#!J)#! J)#!J)#!J)#!J)%&eC'P[,9CTC'9[)&4bB@jcF'pbG#"A4`T*6P4&8Nj&9#e%8N& '9#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#"%,L"6D@jRCA)+C(*KCR3YFfPZCf9b,A*dF#eaG'CTE'8Y-$%J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)%&`F'aP)%0[EA"eG'9b,#"*EQ-Z#L!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)%p MG'pLCA)J-M)J-6Nj13SJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J4AK`DA*PFb!k)%&`FQPX)$)b)$%j16N+#L!J)#!J)#! J)#!J)&0eF("[FR3JCQpb)&*88#"TEL"K)(0dEh*PC#"4G@PMDe4TE@8J6@pfD@8 J4QPXC3S+8h4KG(9c)'pQ)&4SDA-J6@9YE`S+)#!J9'KTFb"NEf0eE@9ZG#"TFb" KEL"*ER4PFQjPG#e%FQ&QG#"KEQ3JDA-J6Np8)'pQCQ9bC@3JD@iJB@0MEh*NB@j MC3SJ)#"hDA4S)&0PBh4TEfiJ-6!JEfBJ8NC$-M!b0L`JB@jN)(4SC5"KGA4SEh) JC'pPFb"ZEh3JF(*[GQPNC5"dD'8J58984JSJ)#"hDA4S)'&ZH5"bD@GSG(-JEh4 SCA)JG'KKEL"dEb"`G@*XDA0S)'&c)'&Z)%PZG'9bEQ9d,84bB@Cd,L!J5@i+)#! JB@4NDA4TEfiX)'%JE'PMC@jcC5"YBANJBQ8JFQ9aG@PbC@3JG'mJD@e`E'9YC@j d)(0[E@8JBA0`C@0dFb"[CL"dD'Pc#L!J)'C[FQeKG#i+#L!J)%PZG'9bEQ9d,84 bB@CdFb"KFQ8JGfpbDfPZCb"NEf0eE@9ZG(-JEfBJG'KP)%PZG'9bEQ9d)%9ZCfP ZC@9bD@jR#L!J)&4KFfXJ4QpbBf8J+%P&9%BT,#"TG(-JBA*PBA-X)'&ZC#"TG(- JGfpbDfPZCb"RFQpeF(-Z)#"1Eh4P)(4SBA3+)#!JEh4SCA)JCh*[GA"c)'eKH5" KE(0[)'4TFh4bD@*eG'8JGfpbDfPZCb"NEf0eE@9ZG(-JBA-J5@jdCA*ZCA3Y#L! J)%4bB@CdFbi+#L!J)%PZG'9bEQ9d,84bB@CdFb"KFQ8JC(*KCR3JC'pMG@ePER4 c)(CKE'PN)'C[FL"K)'eKH'PYG@dJEfBJFfPi)'e[ER4SF`SJ)#"KEQ3JE@&j)'* P)(9`C'&dC@3X)(*PF'aKBf9N,#"[FL"[BR0[E'9dC@3JBRNJEh4SCA)JC'pMG@e PER4c)'&d)'&ZH3SJ)#"dD@eP,L!J5A3JDA-JD@jKF("bEh"bD@&dC5"dEb"eFf8 J5@jdCA*ZCA3Y4(*KCR4c)'&c)(*PCQ9bC@jMC3SJ)#"YBA4PFQPKE#"[FL"dEb" MDA4P)(4SC@dJEh4SCA)JG'KKEL"KFb!LGfpbDb"TEL"`FQpRFQ9cFbiL#JSJ)#" 8D'8JE'PcG#"[CL"MGA*bC@jd)%PZG'9bEQ9d,84bB@CdFb"MB@iJBQ8JB@0MCA0 cC@3JBA3+)#!JD(4dF$S[,hGhGbjTCA4Q,QpbCbpTCA4Q,c&TC#eKBR0dFQ&MG(- ZG(Kd#JSJ)#"8D'8JE'PcG#"[CL"*ER4PFQjPG#e%FQ&QG#"6D'&NEhFJ4'PbC@0 dEh*TCA-JBf&Z)'*P)'&MBf9cFf9N)'&d#L!J)'KdG(!k,bphGhFZD@9dCLj[FQF [FfKKC'ph,QKdE@`Z#JS+#JS+3@*cG(*KBh3+#L!J)&4SDA-JC'pMG@ePER3JC'p MG@ePER4c)(0dFR9MG(9bCA-JGfPdD'PZ)'%J8A9TBfY8D@eP)'e[GQPP)'CTE'8 +)#!JGfKTBfJJF'9bE@Pd)'9KFhNJG(*KER0YDA0cD@pZ)'pQ)(4SC5"YC@4TB5" MEfjdC@jd)'pfCA)J8P43,L!J9'KTF`SJ)#"cF'9MD@CTBf&dD@pZ)'Pc)'PZG'9 ZC'9N)(4[)'&cFfPcG#"dD'pcC5"hD'mJGfPcD#"dEb"cG(*PB@dJFh4[FQ9N#L! J)'e[GQPPFb"[GQ9b)&*88#`JG'K[Ff8JGfPcD'PZCb"dEb"`FQ9`BA*P)'e[GQP PFb"QEh)JFh4bC@&YD@jR,#"KEQ3+)#!JCQpb)(4SEh0P)(GSEb"YD@GSG#"hDA0 S)(4[)(*PBfpbC#"TER4[)&&eD@0V9'PYC5"hD'PXC5"`FQ9cCA*fD@jR#L!J)&* 88#"TEQC[FQeKG'P[ELiJ9'KP)'*TG#ecG(*PB@dSFbNJEfBJ8P43)("KBfYPG(- JBA*P)'j[FQeKE'aj#L!J)'0[EA"XD@&ZG#"hDA4S)(4SC5"59&!JF'&jE'pKC#" NC@CTEQPdD@pZFb"QEh)JG'KPDA)JBfpZG'9ZG#`JB@jN#L!J)'CeE'`JD@jdCA) YEh"PFQ&LD@aTG(NJBf&Z)'*P)'&MD'PPGQ9N,L"&B@0S)&&eD@0V9'PYC5"YC@4 TB5"dFQ&MD`SJ)#"hDA4SD@iJB5"YEhCTC5"TFb"cC@jd)'pfCA)JB5"cCA"KFQ& dC5"59&!JFf9cFfP[EL"KEQ3JFhPZBfKbEfjTHQ9N#L!J)(9cD@jR)(0dB@jNBA* N)&*88#"dC@0SEQPaG@9c,L"8D'Pc)(0`C@0TCQPMBA4TEfiJBR9TE'4c)'pZ)(4 SC3S+#JT%,L"6D@jRCA)J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J@e"KCf8J-9d0$!e*ER4PFQjPG#"%FQ&QG#! J)#!J)#!J)'4bB@Cd,A0TEQGPFLebG(!YFA4QD@aP,6!a)#!J)#!J)#"2Bh4[BQ9 b)$%i)$%j16N+#JSJ)#"`G@*XDA0SC@3J8A9TBfY8D@eP)'CTE'8JCQpbE@&d)(0 `C@0TCQPMBA4TEfiX)'&ZC#"YBA4MD'9c)(4SC5"SD@jd#L!J)(4bB@0V)'C[FQe KG#"eFf9N)'*j)(4SC5"%BA*hD@iJEh"PELecEh9bBf8JFh4bC@&YD@jR)(0PFRC PFLi+#M%J5@jdFQpNG@0dD@pZ#JSJ)#"8D'Pc)'4[Bh9YC@jd)'peG'aTEQ9c)'K [Gb"K)(0PG#"[CL"cCA0cD@pZFb"eFfPZCb"dD'8J8Q9KE(4TE@8+)#!J9(*KER0 `Eh*d)&"bEh4[BfpX)#K59&!T)&XaA5"YBANJBQ8JG(*KER0YDA4dC@3JBRNJB5" cCA*fCA)JF(*[Ch*KE3SJ)#"LH5"bC@&ND@jR)'%J8A9TBfY8D@eP)'e[GQPP,L! J8P43)'Pc)'%JCf9ZCA*TBb"`FQpdEf0[E#"NCA0TCfjPC#"dE`SJ)#"MBA*bH5" bC@&XG'PYC5"YC@4TB5"NBA4K)'&XEfjR)(GTG'JJFhPZBfKbEfjTHQ&dD@pZ)'P ZCQpbE@&dD@pZ)'pfCA)+)#!JB5"NBA4KCh*KE5"`FQpdEf0[E#!SE@pcG'aj)&9 %8#"[GQ9b)%P3+5i+#L!J)&&eD@0V9'PYC5"QD@aPFb"QEh*Y)(4SC5"cG'pbB@G P)'*KFfPc)'pQ)(4SC5"4G@PMDe4TE@8JE@9ND@%+)#!JBA*MD'PdC@0dGA*P1b" SEhGPGQ9b,#"TG#"TFb"ZEh3JEQ9MCA0cBA*j)(4[)(9cC5"dD'8J8A9TBfY8D@e P#L!J)(0[CR4hBA*P)(4[)(*PB@3X)'0[ER0dFR9MG#`JEh)JFh4bC@&Y)&*88#" QFQpY)(4SC5"QD@aPFbiJ9'KP)'CTE'8+)#!JCQpbE@&d,#"hDA4SEh9d)(0eF(" [FR3JCQpb)(0dFQ9KE@PZCb"[FL"59&!X)'Pc)'CeE'aj)'4PFf0bD@*PC#"TEJS J)#"dD'8JF(9LE'PcD'9N)(0`C@0TCQPMBA4TEfiJ@c*G,JS+)#!J9'KP)'CTE'8 JCQpbE@&d)'Pc)'0KF'&LE'8JEfBJFQ9QCA*bD@jR)(4[)'ePC'PK)'4KG'%JD@i JEh4SCA)JCQPXCA-l#L!J)(4SDA-JC@jKBQaPFb"bC5eeFf8JEfBJBfpZG'9ZG#i J9'KPFf8JEh4SCA)JCQPXCA-JEQ9PC#"ZEh3JBQ8+)#!JFh4bG@0dGA*PC#"KFb" 4G@PMDe4TE@8JE@pfD@9c,#"KEQ3JB5"ZG@eLCA)JEfBJ*fC[FQ9TCfiR)'C[FQe KG(-JBf&Z#L!J)(4SGA-JBQ8JFh4bC@&YC@3JEhCPFL"59&!JG@jNCA)JG'KTFb" cF'9MD@CTBf&dD@pZ,#"`FQpfD@4PC#"dD'&d#L!J)(4SCANJBf&Z)'&XFfmJBQ8 JC'9cBh*TBQ9N)'*j)(4SC5"4G@PMDe4TE@8JE@pfD@8J+'NZC5iJC'9cBh*TBQ9 N)'*j#L!J)(4SC5"YEhCTC5"YCA4K,@4KG'%T,#"KEQ3JG'KKG#"dD'8JFh4bC@& YD@jR)(0PFRCPFL"TFb"hD@aXD@jR)'&ZC!SJ)#"KBQaP)(4[)'C[E'a[Gb"dD'8 JE'PZDh-JG'mJG'KPFf8JEh4SCA)JCQPXCA-Z#JSb)&&eD@0V9'PYC5"'D@aP)%C [FQeKG#"2GQ9bGQPPG`S+)#!J9'KTFb"cC@0dD@pZ)'GTGQ9c)'%JBR*TC@BJEhC PFRCTCAFJEfBJG'KP)'CTE'8JCQpbE@&d,L"5C@&NCA*c#L!J)(GKER4TEQFJB5" NCA4KD@aPC#"NCA0MFQP`G'P[EL"KFQ8JC@jMEh9bB@GPC#"dEb"bC@CPFL"dEb" dD'8+)#!JF(9LE'PcD'9N)(0`C@0TCQPMBA4TEfiJ@c*G,JS+)#!J35"QG@jNB@e PER4KE#"eEQ4PFQajD@jR)'0[EQ0PF(3JD@iJG'KP)&&eD@0V9'PYC5"QD@aP)'C [FQeKG#"TFb"dD'&d#L!J)(4SC5"`D(PcD@0KE#"cG(*eBh4eFQ8JEfBJG'KP)'e PC'PK)'4KG'%J+(4SC5"YBA"`D@jR)'pQ)(4SC5"YC@4TB3SJ)#"[ER4[)("SHA0 TBf&X)(0dEh*KCf8JFQ9MEh*NFbNJDA-JD@jNCA"PEQ4PER3JEfBJG'KP)'a[CfP MB@`+)#!JFh4bG@0dGA*P)'pQ)(4SC5"YC@4TB5"QD@aP,L"")&&eD@0V9'PYC5" YC@4TB5"MEfe`Eh0TG'P[EL"TF`SJ)#"NCA0MFQPLC@3JBRNJB5"cCA3JEfBJ)Qe [GQPP)L"YCA4K,@4KG'%l)(4SDA-JE@9dB5eNBA4K)("bEhCTC'9c#L!J)'4PBfa KFQ&dDACP,#"cG(*eBh4eFQ&X,f0[EA"[FfPdD@pZB@`X)'&ZC#"dC@e`Eh*KE#" TEQC[FQeKG'P[EL"KBQpeG!SJ)#"dD'8JB@0dG@&X)'ePC'PK)'4KG'%Z#JSJ)#" 8D'8JE@9ND@%JC'&dB5"YBANJBQ8JD@iJG'KP)(0KE@8JCQPXC5"KFb"dD'8JC'9 cBh*TF(4TGQ8JE'pRD@0KE!SJ)#"NBA4K)#KT,Q8Z,#"hDA4S)(4SC5!LE@pfD@8 L)'ePG'%YC'&dB5NJEh)JD@iJFf9`BA*KG'8JCQPXCA-Z)%%JE@pfD@8+)#!JFh4 bG@0dGA*PC#"TER4[)'pZC5"QD@aP)'Pc)'0[E@e[EQaj)'0KE'aPC#!LCQaKG#) JEh)J)R0PE'BY#L!J)'0[ER4KD@jPC#)Z)%e[GQPPFb"hD'PMD#"KFQ8JEQpd)(0 PE'BYBfpZG'&TEQ9N)'eKH5"bC@CPFQ9ZBf8JFfpYC5"[FJSJ)#"KE'`JEfBJG'K PDA)JE@9ND@%JC'&dB5"TEL"[G'KPFL"QD@aPFbi+#L!J)&4SDA-JFf9`BA*KG'P [EL"LCA4hC@9Z)'a[CfPMB@`JEh*RB@jTHQ&dD@pZ)'&ZC#"`D(PcD@0KE!SJ)#" [FQGKEQPkBA4TEfiJE@&VCA-JG'KP)&&eD@0V9'PYC5"QD@aP)'C[FQeKG#"TC'9 KE'aj)(0eDA4PC#"dE`SJ)#"[F(4TE@PkBA4TEfiJD@iJC'PQCQ9bC@jd)(GKHA- JCQpb)'4TCQCPFQ9ZG#"cBf9ZBA*TEh-Z)&GSC@iJC@4TG'PZC`S+#JT%,L"6D@j RCA)J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J@e"KCf8J-Pd0$!e*ER4PFQjPG#"%FQ&QG#!J)#!J)#!J)'4bB@C d,A0TEQGPFLebG(!YFA4QD@aP,6!a)#!J)#!J)#"2Bh4[BQ9b)$%i)$%j16N+#JS J)#"KEQ3JBfpYF'pcDA4TEQFX)(4SDA-JE@9KER-JG'KKG#"YC@4TB5"NBA4K)'j PC@3JEQpd)'*P)'0[F'PPC#"[FJSJ)#"bC5eMEf4PC#"KFb"PC'PdFb"KFQ8JBA" `E'PPC#"KEQ3JE@9ND@%JDA-JFQ8YEh*NCA*PC$XJG'KP)'ePG'%YC'&dB3SJ)#" QD@aP)'eKH5"LC5"PH(4PEQ4PC#"KEQ3JG'9YF'pbB@`JE@&`F'PZCb"TEQC[FQe KG'P[EL"KC'TeFh4PC#iJ9fKPEJSJ)#"PC'PdD@jR)'Pc)'0[EA"XCA4PC#`JG'K P)(*PE'9fB@jd)'ePC'PK)'4KG'%JB@jN)'ePG'%YC'&dB5"YBANJBQ8+)#!JFQ9 hFQPdG'9Z)'PZG'mJB5"cD@jRE'8X)'PZG'9bE'9KGQ9N,#"[F(4TE@PkC@3JCQP XC5"QEh)JC@CQD@0TC@jd#L!J)'a[Bf&X)'pb)'jPG(G[FQXJB@0MCA0c,L")EhG PGQ9b,#"LEh4S)(4SC5"cG(*eBh4eFQ9N)'&ZC#"dD'8+)#!JEh"dD@eTHQ9N)'C TE'9c)'&bC5"fB@aTC#"4G@PMDe4TE@8JCQPXCA-X)'&ZC#"LEh4S)'eKH5"LC5" TER0`C@0dC@3X#L!J)("XBAPPC#`JFh4bC@&YC@3X)'&ZC#"bCAG[FQYPC#i+#L! J)&4SC5"eFf8JEfBJE@pfD@9c)(GSD@0S)'&bC5"ZEh3JFf9XCLeMEfjdB@PZC@3 JC@jKBQaPFb"dD'8JFf&YC5"LBA0TB`SJ)#"YC@4TB5"NBA4K)(4[)'*P)(9cC@3 JB@jN)(*P,A9cC@3JD@iJB@jj)'jeE@*PFL"[CL"`FQ9cC@jdBA4TEfjc,JSJ)#" 8D'Pc)(0KE@8JB@4fB@jdB@GP)'&`F'aTCA-JGfKPEL"cCA*fD@jR,#"KFb"hD@a X)'*P)(0PC@iJBQ9XEhFZ#JSJ)#"*EL"LEh4S)'9NDA4TEQFJB@jN)(0dFQ9KE@P ZCb`JG'KTFb"KE(0[)("PFQeTG(-JB@jj)'jeE@*PFL"[CL"[G'KPFJSJ)#"QD@a PFb"dEb"LC5"dFQ9KG'9N)'&c)("KFR3JEfBJB5"`FQ9cC@jdBA4TEfiJGfPdD'p eG#"MEh"jD@jR)(4SC3SJ)#"YC@4TB5"NBA4K)(GSD@0S)(4SCANJBfpZG'&TELi J4@4TG'PZCb"MB@iJBfKKEQGP)'&ZC#"bC5ehFQPdC5"UGA0d#L!J)(4SC5"YCA4 K,@4KG'%JD@iJG'KP)'e[GQPP)'CTE'8X)(GSD@0S)'Pc)'eeBfJJFA9TBfYPFL" dD'&Z)(*PB@4TEQF+)#!JB@jN)(*P,AGbDA4TEQFJB@aX)(4SC5"YC@4TB5"NBA4 K,Li+#L!J)&4SC5"4G@PMDe4TE@8JCQPXC5"TFb"NDACTC'9N)'PZG'mJB5"cCA3 JEfBJEf*UC@0dFb`JBf&XE'9N)'&dEfec,JSJ)#"&B@0S)'pLDQ9MG#"cG'&bG(- JGfPdD#"KEL"KG'pY)'KPB@4PFL`JGfKTBfJJC'9ME'&bCA-JDA4c)(0THQ8JB@j N#L!J)(4jF'8k#JS+)#!J)#!J)#!J)#"ME'&cFb""G'pY)(X+)#!J)#!J)#!J)#! J)#!J)#!J)'PZG#Jc-LNJFfPkC6X+)#!J)#!J)#!J)#!J)#!J)#!J)'0SBA)J)#! J)#!J)#!J)#"dHA"P@c4G1`SJ)#!J)#!J)#!J)#!J)#!J)#!JD@jd+$JT)#"MEfj dC@jdFeYG1`SJ)#!J)#!J)#!J)(d+#JSJ)#"8D'8JFfPkC5"TFb"K)$-b,@*TG#" TER4PCf9b,#"TEL"LHA4PFb`JD@jME(9ND@jR)(4SC5"cDATP)'&ZC#"dHA"P#L! J)'KPB@4PFL"QD@9XC(-Z)&4SCA*P)'Pc)'&XFfmJF(*[GQPcD@pZ)'C[FL!f0#e LDA3JFfPkC5"QD@9XC(-Z)&4SC3SJ)#"dHA"P)'CTC@aN)'Pc)'C[GA)JBfKKFQ& MG'9bFb!SGA0eB@aXH5"`FQPZG'&LE'8T,#"dEb"`CA*YDA3JC@&cH3SJ)#"NEf0 eE@9ZG'&dD@pZ)'&ZC#"TC'9ZG'PQD@0KG'P[ELiJ9'KP)'4KG'%JD@iJB@iJEf* UC@0d)'&QG'9b)(4SC3SJ)#"dHA"P)'CTC@aN)'eKH5"LC5"QD@9XC(-X)'%JFf9 aG@9ZBf8JEfBJBfpZG'&TEQ9N)'pLDQ9MG(-X)'pb)'*[G'JZ#L!J)%&XE#"QD@9 XC#"NBA4K)'&bC5"cG'pbC@3JD@iJBQPR,@9ZC'PKEL"QEh*YBA3Z#JSJ)#"")&& eD@0V9'PYC5"QD@aP)'0[ER0TFh4c)'pQ)'%JFf9aG@9ZBf8JEfBJEf*UC@0dFbi J9'KP)(4hEb"SD@GSCA0d,3SJ)#"XCACPE#"[BQTPBh4c)'&bC5"dD'8JE@9ND@% YC'&dB5!SE@4KG#NJB@jN)(4SC5"YCA4K,@4KG'%J+'e[EhBT#L!J)'&dEfec,JS +)#!J9'KP)'ePC'PK,@4KG'%JEf*UC@0d+(-T)'0[ER4KD@iJG'KP)'&MG(9KE#" YC@4TB5!SCQpb)'9iB@e`E'8X#L!J)(0PFA9PEQ0PFb"[CL"cEh9ZC#"cB@e`E'9 c)'pb)(CTC'9[)'CbB@ePFbNZ)#"8D'9TFL"QEh*YBA3JDA-JEQpd#L!J)'0[ER0 dFQ&TEQ9N)'*j)(4SC5"QD@aP)'C[FQeKG$XJG'KPH5"KFQ8JEQpd)(9cG@&XE(N JEf*UC@0dFbiJ9'KPDA)+)#!JCQpbE@&d)'Pc)'4PFf0bD@*PC#"TEL"dD'8JE@9 dB5eNBA4K,#"ZEh3JBRNJB@jj)'4PBfaKFQ&dD@pZF`SJ)#"`D(PcD@0KE'aj)'0 [ER4TCh9[GA-JGfPdD#"dD'9Y,L"6Eb`JCQpb)'9iB@e`E'8X)'PZ)'%JE@pfD@8 +)#!JBfpZFfPcG'PZCb"cEfaPE(NJEfBJE@pdD@pZ,8T348FX)%T348FJCR*KE@9 c)'&bC5"cG'pbC@3JBfpZG'PRG@peFfaj#JS+#N3Z)&0TEQGPFL!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"E8'& RC5!cA3d-$8PZG'9bEQ9d)%4bB@Cd)#!J)#!J)#!JC(*KCR3YFfPZCf9b,A*dF#e aG'CTE'8Y-$%J)#!J)#!J)%pMG'pLCA)J-6JJ-6Nj13S+#L!J)'PZ)(4SC5"YC@4 TB5"NBA4K)(GTG'JJEQmJFQ9aG@PbC@3JD@jdCA*fC@jTEQFJCAKdFQ%JD'9KC'9 bFbiJ9'KP#L!J)'ePC'PK)'4KG'%JGfPdD'PZ)(4SC5"YC@4TB5"NBA4K)'pLDQ9 MG(-JDA-JE'pRD@0KE'aj)'4TGQPNC@3JD@jdE`SJ)#"MD(9ZDh-l)'K[Gf9fCA) X)(4SCA*P)'&bC5"ZEb"PH("XD@0TG#"MD(9ZDb"YBA*VCA*c,JS+)#!J9fKPEL" dD'8J8A9TBfY8D@eP)'CTE'8JFQ9QCA*PEQ0PFb"YC@4TB5"NBA4K)'PZ)'pdD'9 b)'CTE'9c,#"TG#"TF`SJ)#"ZEh3JFQ9aG@PbC@3JG'KKG#"dD'9cC5!RFf9MEfj NBA*j*b"QD@aPFb"LC5"QEh*YBA4dC@3JG'mJG'KTF`SJ)#"cF'9MD@CTBf&dD@p Z,#"cD@jMC5"dD'9cC5"YC@4TB5"NBA4K)'CTE'9c)'&bC5"QEh*YBA4dC@3JBA- JD@BJG'KPH3SJ)#"hCA*P)(4SC5"MEfjdC@jdFb"[CL"K)'ePC'PK)'pLDQ9MG#i J)&0TEQ0P)(4SC5"QEh*YBA3JD'9bC5"NEf9c)'j[G!SJ)#"bCA&eDA*P)'&ZH5" SC@&NCA*c)'pb)'pdD'9b)'PZCQpbE@&dD@pZ)("SHA0TBf&XE(NJBfpZG'PRG@p eFb"hDA4S#L!J)(4SC5"YC@4TB5"NBA4K,#"TG#"TFb"`Eh0cD@*XC5"QEh)JG'K P)'ePC'PK)'4KG'%JG'mJBQ8JCQPXCA-JGfKTBfJ+)#!JBfpZG'&TEL!RCQpbC@P RELFJD'9KC'9bFb!SC5jR,L"96NPB)#)ZBA8L)'CTE'9c,#"[FL""9NNJCQPXCA- T)'&ZC!SJ)#"QEh)JG'KP)&&eD@0V9'PYC5"YCA4K,@4KG'%JG'mJBfpZG'&TEL" dD'8JBA"`FQp`FQPKG'8JC'9ME'&bBA4TGQ8+)#!JD@jQEh*YBA4TEfiJB@jN)(* PCQ9bC@jMC5"dD'8JE@9ND@%JC'&dB5"TEL"dD'8J*fC[FQ9TCfiR)'CTE'8Z)#" *EJSJ)#"dD'Pc)(GKH5"dD'8JCQPXC5"QEh*YBA3JBf&Z)'*P)(9cC@3JG'mJGA" NBA4P,#"hDA4SEh9d)'0[F(PTEQFX#L!J)'9iDA0dD@jR)'*[C'PPFb"[CL"YBA4 PFQPKE#"TEL"NDA0`BA*KG'8JCQpbE@&dFbiJ9'KeFb"PC'PdD@jR)'&ZC!SJ)#" cCA*fD@jR)'eKH5"LC5"NEfjP)'4TFQ9MG'aj)'CbEfdJG'KPFf8JCQPXCA-X)'G bC@&dE(NJCAKdC@jND@jR#L!J)(4SC@Pb)(9dD@aTG(NZ)&4SC5"4G@PMDe4TE@8 JCQPXC5"QEh*YBA3JDA-JB5"dFR9P)(9ZD@CjD@jR)'0[EQ0PF(3l#L!J)'Pd)'P c)'*[G'JJB@iJCA0dB@*XDA0SC@3JCQpbE@&d)'&ZC#"TFb"KBQaP)(4[)(G[FQX JGfPdD#`JD@jME(9NC5`+)#!JB@jN)(4SCA*PBRNJBR*TEQFJCQpbGf&bC#`JEh4 SCA)JCA0dB@*XDA0SC@3JCQpbE@&dFbiJ+&4SC5"QG@aX)(*KEQGP#L!J)'pQ)(0 eF("[FR4PC#"QD@aP)(4jF'9c)'Pc)'aKFQGP1b"MEfjcG@ad)(4SC5"4G@PMDe4 TE@8JGf9L)(0TG'8+)#!J2'KdG(!k,bphGhFZBA"`E'8ZBfpY,h&eD@0VG'PYC6i JCQpb)'e[FQ8JD@jQEh*YBA4TEfiZ+5i+#L!J)%CbC@8JFh"KBf8J+'8ZCbiJC'9 XCA4PC#"LH5"KEL"PC'PdD@jR)'p`CA*KG'P[ELNJBf&Z)'&XFfmJBQ8+)#!JC'9 cBh*TBQ9N)'*j)'&Z)'pLDQ9MG#"KG#"dD'Pc)'aPGQ9X,L""ERNJFfpQG(GKFQ8 JFQ9KC'PZCb"dD'8JCQPXC3SJ)#"cD'peE'3JD@GZEh*P)'CbC@8JFh"KBf8JEf* UC@0dFb`JB@jN)'pLDQ9MG(-JBA3JB@jj)'aPGQ9X)(GSD@0S)'Pd#L!J)'4[CA- JEQpd)(9ZC'9bFh4KEQ3l)(4SDA-JF'9bE@PdFb"PH(4PER0TEfiJEfBJG'KP)'C TE'8JBA3JB@jj)'aPGQ9X#L!J)'*j)'PZG(*[C(9MD@jR)'jPGb"[BQTPBh4c,L! J9'KP)("bD@eKFRNJE@9dB5eNBA4K)'Pc)(4SC5"YEhCTC3SJ)#"[BQTPBh3Z)%% J8A9TBfY8D@eP)'CTE'8JEQpbE@&XE(NJD'&c)'9iB@0dE(NJEfjP)'e[GQPP)'p LDQ9MG$XJDA3JDA-+)#!JG(P`D@0KE'aj)'&d)(4SC5"LC@GTEQjTEQFJEh)JC@j N)'pQ)(4SC5"QD@aP,#"dEb"`CA*YDA3JDA4c)'9KFhN+)#!JE'pMBA4TEfiJ+'& XG'K[G@GS)(4SDA-JDA-JEQpd)(*PFA9TFQ9N+5i+#L!J)&4SC5"YEhCTC5"SC@& NCA)JF(*[GQPNCA-JBQ&cD@-JD@jQEh*YBA4TEfiJB@*[GA3JG'KP)'pfCA*KE'` +)#!JF(*PFf9ZG'&dD@pZ)#KTG(-JBh*PBA4TEfiJC'&dC5`JEhCPFQ&XE#"dD@e PFf0KE'8X)'&ZC#"cEb"[ELNZ)%PZ#L!J)(4SC5"cCA&eC@jMC5"[CL"MEfjdB@P ZC@3JEf*UC@0dFb"dD'9bC5"hEh9XC#"ZEh*YB@aXH5"LC5"KG#"XC@&cG!SJ)#" [EQ8JG(*KBfXX)(GSD@0S)'4PFf0bD@*PFb"dC@e`Eh*KE'aj)("bCA0PER4PC#" NBA4K,L"")(4bB@0V)'Pc)'%+)#!JE@9ND@%JFh4bC@&Y,JS+)#!J9'KP)(4bB@0 V)'KPB@4PFL"`FQpfD@4PFb"LBA0TBb"TEQC[FQeKG'P[EL"KBQpeG#"dD'8JG(* KBfXJ+'PdFb"*4#`+)#!JG'PYCA0MB@aP,#"KEQ3JFfmJEfiT,L"*EQC[FQeKG'P [EL"KG#"dD'8JG(*KBfXJE'9fC@`JDA-JD@jNCA"PEQ4PER3+)#!JEfBJG'KP)'e PC'PK)(4jF'8JBfpZG'&TEQ9N)'PZ)(4SC5"dFQ&MDbiJ6f*UC@0dFb"MEfjdB@P ZC@3JD@iJG'KP#L!J)(4bB@0V)'eTCfKd)'*P)(*PCQ9bC@jMCA-JG'mJEh4SCA) JG(*KBfYc)#KP,QFZ)'C[FL"MEfe`E'9i#L!J)'0[EA"[FfPdD@jR+5`JEh)JC@4 TG#"XDA0dFbiJ)%PZ)(4SDA-JFf9aG@9ZBf8JEfBJBfpZG'&TEQ9N)'pLDQ9MG(- +)#!JG'KPFQ8JGfpeE'3JEQpbE@&XE(NJBQ8JB5"YC@4TB5"[BQTPBh3X)(GSD@0 S)'4PFf0bD@*PFb"dD'8JE@9ND@%+)#!JGfKTBfJJDA-JF(*PFf9ZG'9N)(GSC@i JG'KP)(4bB@0V)'Pc)("XBAPPC#i+#L!J)&4SC5"YC@4TB5"[BQTPBh3JBfpZG'& TER-JC'9ME'&bBA4TEfjc)'pQ)(4SC5"PH'&MG#"`FQ9cC@jdBA4TEfi+)#!JFQ9 aG@PbC@3JBRNJG'KP)(4bB@0V)#KP,QFZ)(4SBA3JDA3JDA-JFf&YF'aPC#"KG@4 TEb`JEh)J68P%55`JEh)+)#!JEh*TC@jdBA4TEfiJD@jQEh*YBA4TEfiJCQpb)'% J-d3J8f0PEQ8T,L"8D'8JG(P`C5"[CL"dFQ&MDb"TF`S+#JT%,L"6D@jRCA)J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J@e"KCf8J0&d0$!e*ER4PFQjPG#"%FQ&QG#!J)#!J)#!J)'4bB@Cd,A0TEQG PFLebG(!YFA4QD@aP,6!a)#!J)#!J)#"2Bh4[BQ9b)$%i)$%j16N+#JSJ)#"NC@0 XBA*PC#"LH5"TG(-JD'&ZC'aPFLi+#L!J)>G'KTEL"dD'8JE@9ND@%JD@jQEh* YBA4TEfiJG'KPFQ8JDA-JE'PVCAGTFf8JB5"SB@jNE'9b)'4PBfaKFQ&dD@pZ#L! J)'C[FL"dD'8JC'&dB5"SB@jNE'9b)#KhD'PMD#"QCA4MD'9c)'ePC'PK)'4KG'% T,#"KEQ3JB5"NBA4K#L!J)'PZCQpbE@&dD@pZ)'4PBfaKFQ&dD@pZ,L"8D'Pc)'4 PCQPZCA-JGfKTBfJJCQPXCA-JBfpZG'&TEL"dD'8JE@9ND@%+)#!JC'&dB5"QEh) JG'KTFb"dFQ&MDcXJDA3JDA-JBRNJGA0TEQFJG'KTFb"NC@0XBA*KG'P[EL"dD'& d)'e[GQPPFb"YBAN+)#!JBQ8JBR9TE(3JGfKTBfJJFh"KEL"cCACPFQ&X)'CTE'9 c,L!J3A3JG'KP)'a[Gf9cG#"XCACPE#`JB5"cB@e`E'8+)#!JG'&LE'8JDA-JGA0 PC#"hD'PMD#"bC@aKG'9c)(4SC5"dC@e`Eh*KE#"KFh"PBh3JEfBJG'KP)(4bB@0 V)(4[)(4SC3SJ)#"NBA4K)(0dEh*PC#"TEL"dD'8JCQPXC6S+#JS+)#!J)#!J)#! J)#"ME'&cFb"cB@e`E'9dB@*XC5"l#L!J)#!J)#!J)#!J)#!J)#!J)#"TER3S-c) T)(0THQ8l#L!J)#!J)#!J)#!J)#!J)#!J)#"MD'&b)#!J)#!J)#!J)#!JG(P`C9X dA5!p)#GcG'*X*cX+)#!J)#!J)#!J)#!J)#!J)#!J)(0KEA"XC@4PFf0bDA"dD@p Z)#!J)#!J)(0N1`SJ)#!J)#!J)#!J)#!J)#!J)#!JG'PYCA4[Ff&YF'aP)#!J)#! J)#!J)#!JG(4c1`SJ)#!J)#!J)#!J)#!J)#!J)#!JFhPZBh0KEA"XCA4KBQaP)#! J)#!J)#!JFhPZBh-l#L!J)#!J)#!J)#!J)#!J)#!J)#"cB@e`E'9dEf0SG@jV)#! J)#!J)#!J)#"cG'pM1`SJ)#!J)#!J)#!J)#!J)#!J)#!JFf&YF'aPFfPkC5!J)#! J)#!J)#!J)#!J)#!J)#!J)#"cFfPkC6X+)#!J)#!J)#!J)#!J)#!J)#!J)'0SG@j VEfCQFf9d)#!J)#!J)#!J)#!J)'0[CQCcCA3l#L!J)#!J)#!J)#!JI3S+#L!J)&4 SC5"cB@e`E'8JC'9cBh*TF(4TEfiJBfpZG'&TER-JD@jQEh*YBA4TEfiJB@*[GA3 JG'KP)'ePC'PK)#KP,QFZ)(4SC3SJ)#"MEfe`FQ9cFfP[EL"QEh*YBA4c)(9cC@3 JD@iJGQPNC@mT,L"8D'8JG'PYC5edEbecB@e`E'8JG'&LE'8JFQ9XBA4PF`SJ)#" dD@eP)'PZ)(4SC5"dFQ&MDb`JG'mJG'KP)(0KEA"XC5!SBRNJD@jNCAJT)(GSD@0 S)(0SEh9XC#"LC5"NDA0`E'&jC@3+)#!JBA3JG'KKG#"dD@eP,L"8D'8JFhPZBb" cB@e`E'8JG'&LE'8JC'9ME'&bCA-JGfKTBfJJEfBJG'KPFf8JBA*P)(0jEQ-+)#! J+'YPH5NJFf&YF'aPFb`JEQpd)'4PF'9ZC'9ZG#"[EL"[G'KPFL"cB@e`E'9c,JS +)#!J9'KP)(0KEA"XC5edEbeMD(9ZDb"[BQTPBh3JC'9ME'&bCA-JD'ph)(4[)'C TEQ3JG'KP)'ePC'PK)'4KG'%JCQpb)'%+)#!JCfPfC@iJFf&YF'aP,#"KEQ3JDA4 c)'4PFf0bDA"dD@pZ)'GTGQ9Z)'PdFb"TEQ4PH#i+#L!J)&4SC5"cB@e`E'8JFfP kC5"dB@*XC5"RDACPFb"dD'8JFfPkC5"[CL"PB@0S)(0KEA"XC6XJB@jN)(4SC5" MD(9ZD`SJ)#"[CQCcCA3JG'&LE'8JCfPfCA-JG'KP)'pQCR0PG#"TER4[)(4SC5" MEfjdB@PZD@jR)'CTE'8JEfBJG'KP)(0dBA*d#L!J)'pQ)'9KBfJJBfKeEQXZ)&4 SC5"MD(9ZDb"[CQCcCA3JG'&LE'8JBf&Z)'0[ER4KD@iJ-c)YBQPd)'pb)$Bd,@* TG!SJ)#"QD@aP)'pQCR0PG(-JCQpb)'0SG@jVFb`JF'9bE@PdG'PZCb"dD'8JGA0 P)'pQ)(CPFRNJE'&bCf8JCQPXCA-Z#JSJ)#"AB@aVD@jR)(4SDA-JFh4bG@0dGA* P)(4[)'CTEQ3JG'KP)'&`F(*[F(*TBA4P)'4KG'%JG'mJC'PcF'aKH5"QEh)JB3S J)#"RDACPEL"dD@eP)'Pc)(0dFQ&TCfKdCQpbGf&bC#`JE@pcG'aj)'PZGQpXGQP ZCb"TEQ4PH'PZCb"KEQ3JB@4ND@jR,JSJ)#"9FfPZCb"dD'8JFhPZBb"dB@*XC5" TG#"TFb"KE(0[)("[Fh0TBQaP)(4SC@iJG'mJBQ&MDbeeF#"dEb"dD'8+)#!JF(* PBf9ND@jR)(0jEQ-JFf&YF'aP,#"KEQ3JFQpXE#"QEh*hBA*N)#GcD@aPER4XH5F JB@0MG@eeE'&dD@jR#L!J)'4PE(4KFb"dEb"dD'8JC'9cDA*PC#"cG'&bG'PZCb" `EfPZG#iJ6QpdC5"dD'&d)(4SCA0P)(4KBQaPFb"hD'PMD!SJ)#"RDACP)(0KEA" XC5"dD@eTEQFX)(0THQ8X)'&ZC#"`Eh0TG'P[EL"TEQC[FQeKG'P[EL`JBA*P)'0 [ER0dFR9MG'9N#L!J)'PZ)(0eBfJJB5"hBANJG'KKG#"dD'9j)'&bC5"ZBA4eFQ& XE(NJBfpYF'&MG#i+#JSc)&0eF("[FR3JCQpb)(0dFQ9KE@PZCb"`FQpdEf0[E(- +#JS+4#iJ8fPZCf9b)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)&Y3B@GP)$9G$3`05@jdCA*ZCA3J4(*KCR3J)#! J)#!J)#"NFQ&QG#ecD@jRCA)YFR4`,A&dCQPXC5d`-5!J)#!J)#!J6f0dEf*PFL! a1#!a16Nj#JS+)#!J9'KP)&&eD@0V9'PYC5"QD@aP)'C[FQeKG#"cGA"`Eh*dFb" cG(*PB@eTEQFJEfBJE@9ND@%JC'&dB5"[GQ9b)'%+)#!JEQ9dGfpbDb"KFb"hC@a X)'&c)'a[Bf&X)("XBAPLB@0V,L"8D'8JF(*[Bf9cFb"[CL"cC@jND@jR)("bEh4 [BfpX#L!J)'4KG'%JG@jTG(-JDA-JG'PYC5eLBA0PC#`JDR9cG#"XD@YP)(4SC5" NDA0`E'&j)'pQ)(4TE@8YBQ&cC@3JC'&dB5`+)#!JB@jN)'Pc)(4SCA*PCQpbC5" cG@PdB@*XH5"NCA0MFQPLC@3JBRNJB5"dD@eP,@*KFf9N)'C[FQeKG#iJ33SJ)#" 4G@PMDe4TE@8JCQPXC5"[FL!RE@pfD@8R)(GSD@0S)(0eF("[FR4c)(0dFQ9KE@P ZCb"TEQ0XG@4PF`SJ)#"TEQC[FQeKG'P[EL"KBQpeG#"dD'8JC'&dB5"eEQPdFb" dEb"cG(*PB@dZ)&4SDA-JD@jQEh*YBA4TEfiJDA-+)#!JD@jME(9NC@3JD@iJB@4 NDA4TEfjKE#"dFQ&MDh-JEfBJG'KP)'e[GQPP)'0KE'aPC#!LD'PZG#)JG(*KBfY c,JS+)#!J5'PZG#"dFQ&MDh-JBfpZG'&TEL"TER0dFR9MG'P[ER-JCQpb)'%JFh4 bC@&YD@jR)(0PFRCPFL"hD'PMD#"KFh0TFh3+)#!JD@iJG'KP)'C[FQeKG'P[EL" [CL"`B@0VCA4c,L!J9'KPFf8JD@jcG(*eBh4TEfjc)'eKH5"MEfjdB@PZ#L!J)'P YE@9ND@&dC5"NBA4K)'C[FL"dD'8JFf9bGQ9b)(4[)(0PEQ3J+'8ZCbiJD'9KC'9 b)'PZCQpbE@&dD@pZ+5"[FJSJ)#"bC@CPFQ9ZBf8JFf9RE@9ZG(-JEfBJG'KP)'e PC'PK)'4KG'%Z)#"8D'9cC5"TER0dFR9MG'P[ER-JBA*P)'9ZBfpNC@3+)#!JD@i JG'KP)&&eD@0V9'PYC5"QD@aP)'PZ)(4SC5"cB@eP)(GKH5"dD'&d)'9NDA4TEQF JEh)JF(*PFf9ZG'&dD@pZ#L!J)'PZCQpbE@&dD@pZ)'Pc)'9ZBfpNC@3JD@iJB5" 4G@PMDe4TE@8JCQPXC5"QEh)JE'pMB@`JF'aKH@*KBfXZ#L!J)%PZFh4PB@3JEfB JC@4TG'PZCb"[FL"`FQ9cC@jdBA4TEfiJD@jQEh*YBA4TEfiX)'PZCQpbE@&dD@p Z)'Pc#L!J)("bEhCTC'9N)(GSD@0S)'&XE'phFb"K)(0PFRCPFL"dEb"`B@0VCA4 THQ8JG'KP)'ePC'PK)'4KG'%JD@iJB3SJ)#"YB@jZCA)JFh9TG'&LE'8JCQpb)(0 dFQ9KE@PZCb"eFfPZCb"K)(0`C@0TCQPM)'jPG(G[FQXJG(*KER0`Eh*d,JS+)#! J9'KP)(0KE@8JE@9ND@%JC'&dB5"TFb"eFf9N)'PZ)'%J8A9TBfY8D@eP)'CTE'8 JGfKTBfJJBfpZG'&TER-JD'PZG(-X#L!J)(GSCA4SCA)JDA3JDA-JCQpb)'a[Bf& X)("XBAPLB@0V,#"[FL"cG(*PB@eTEQFJEhCPFL"K)'jeE@*PFL"[CJSJ)#"ND@C QCA*PER3JG(*KER0`Eh*d)(4jF'9c,L!J8f9`BA*KG'8J*fKTER3R)(4bB@0VFb" QEh)JC'PQCQ9bC@jd#L!J)(4bB@jcF'pbG#"dHA"PFb"YBANJBQ8JD@jME(9NC@3 JGfPdD'PZ)(4SC5"cB@eP)'CTE'8JB@jN)(4SC5"YC@4TB3SJ)#"hD@aX)("XBAN JEhCPFL"KE'`JFh9MD#"dFQ&ZFh"[FR3JG(P`CA-JGfPdD'peG#"YB@YTEQFJB@j j)'&NC'PdD@pZB@`+)#!JBfp`D@9c)'pQ)(4SC5"YC@4TB5"TG(0PE'BZ)#"*EL" KC'4TG'P[EL`JCAKTFh4TEQFJE@9ND@%JBf&Z)'*P#L!J)'9KFfPXH5"YB@4P)(0 dFQ9KE@&LE'8JBRNJG'KP)'&NC'PdD@pZ)'pQ)'&`F(*[F(*TBA4P)'KTER3JG(* KBfYc)'C[FJSJ)#"cF'9MD@CTBb"dFQ&ZFh"[FR4c,L!J9'KP)'ePC'PK)'4KG'% JDA4cC@aQ)'jPC@3JEQpd)'*P)(*PBf&cG#"[FJSJ)#"bC@C[FQeKG(4PC#"TEL" KERNJGf&j,JS+)#!J9'KTFb"KF("bEf&MD#"dEb"cG(*PB@eTEQFJDA-JE@pbC5" cF'&MC5"PCQCTBfPPER3JG'KKEL"KEL"KF("bEf&MD!SJ)#"dD'&d)(*PFA9TFQ9 c)(4SBA3JG'KP)'ePC'PK)'PZCQpbE@&dD@pZ)'*P)("KFR4TG'P[EQ9N)'PZG'm JG'KP#L!J)'&MG(9KE#"NBA4K)(9ZDA4c)(GSD@0S)(GTE'`JBQ8JG(*KER0YDA4 dC@3JCQpb)'%JCfPfC@iJG(*KER0`Eh*d)'&ZC!SJ)#"YC@4TB5"QEh*YBA3Z)&9 ZC'9b)(0eBfJJB@iJBA"`FQpKBfJX)'a[Bf&X)("XBAPLB@0V)(*PFA9TFQ9c)'9 TG'KPFJSJ)#"bC5eKFh0PE@*XD@jR)(4SC5"YC@4TB5"QFQpY)(4SC5"`B@0VCA4 c,#"[FL"SBACTEQFJG(G[)'0[F'PPFb"[CL"dD'8+)#!JE@9ND@%YEfjP)'C[FL" XEf0KE#"`E'&jBQ&MDb"KEQ3JEfjP)'C[FL"cG(*PB@eTEQFZ)#"6D@eTE'&bE(N X#L!J)(0dFQ9KE@PZCb"cG@0S)'ePC'PK)'pfCA)JEA9XG'P`E'8JG(*KER0`Eh* dFb"eFfPZCb"dD'Pc)'&`F(*[B@0S#L!J)(*PFA9TFQ9c)'eeE(4TF'aP)'0[F'P PFb"[CL"dD'8JE@9ND@%JC'&dB5"QEh)JC@&MD#"dFQ&ZFh"[FR3Z)&4SDA-+)#! JDA-JEA9MD#"XCA0c)(0`B@0P)'9QCQPMD@9ZG#"dD'&Z)'KTER3JG(*KBfYc,#" eEQaPFh-JG'KP)'ePC'PK)'4KG'%+)#!JEA9cG#"LC5"SC@&fD@aj)(4bB@jcCQp bE@9N)(4[)'*P)(0dFQ9KE@9N)#KP,QFZ,#"LH5"dD'8JBA"`E'PMBA4TEfi+)#! JEfBJCA*bEh)YBfpbFQ9MG'PZCb"MEf4TEQFJG'9MD'jTFA9PFb`JEh)JBRNJC@j MFRP`G'P[ELNZ#JSJ)#"6GA"`Eh*d)'C[FL"cG(*PB@eTEQFJD@iJG'KP)&&eD@0 V9'PYC5"QD@aP)'C[FQeKG#"TFb"LBA0PC#"eF'pZ)(4SC3SJ)#"QEfaXEhGTEQF JG'KbC@8JC'9cD@GZ)("KFQ&YCA4PFR-k#JSJ)#!S-5NJ9'KP)'ePC'PK)'4KG'% JDA-JFQ9`FQ9cC@jdC@3JBA-JB5"cCA3JEfBJEQ9dGfpbDbeTEQ4PF'9ZC'9ZG!S J)#"cG'&ZC'&bC#"4G@PMDe4TE@8JG(*KBfYc,#"hD'PMD#"YBANJBQ8JF'aKH@9 N,#"PC'PdC@3X)'&ZC#"cEb"[EL`JBA-+)#!JEQpbE@&X1`S+)#!J+$)T)&4SCA* P)'Pc)'%JBfpYE@pZ)'4PBfaKFQ&dD@pZ)'&ZC#"LBA0P)(0dFR9MG(9bC5"QEh) JFf9bGQ9b)'KTER3+#JS+4#iJ8fPZCf9b)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)&Y3B@GP)$CG$3`05@jdCA* ZCA3J4(*KCR3J)#!J)#!J)#"NFQ&QG#ecD@jRCA)YFR4`,A&dCQPXC5d`-5!J)#! J)#!J6f0dEf*PFL!a1#!a16Nj#JS+)#!JG(*KBfYc1b"dD'Pc)'0[E@e[EL"QEh* YBA3JDA-JF(*[G'pMEf`JD@jNCA"PEQ4PER3X)'*eG#"MEfjdB@PZFb"dD'8+)#! JC'9ME'&bBA4TEfjc)'pQ)(GSD@0S)("bEh4[BfpX+(-T)'&bC5"NCA0MFQPLC@3 JD@iJG'KP)(0PFRCPFJSJ)#"dFQ&MDbKc+6X+#L!J)#Jc+5"8D'9bC5"TFb"K)(0 `C@0TCQPM)'4PFfPREL"[CL"dD'8JFf9bGQ9b)'KTER3JG(*KBfYc)'C[FL"PB@0 S#L!J)("bEh4[BfpX)(GSD@0S)'eKH5"LC5"dFQ&ZFfeTG(4PC$XJB@aX)(4SCA0 P)'4PFfPRER-JGA0P)(4SC5"cB@eP#L!J)'*KFfPM)(0dFR9MG(9bC5iJ4Qpb)'9 iB@e`E'8X)(4SCA*P)'eKH5"LC5"NCA0TCfjc)'C[FL"59&!J+'C[FL"dD'8+)#! J5@jdCA*ZCA3T)'&ZC#"08%9(,6)JG(*KER0`Eh*d)#KQEh)JBR*[B@4MBA0d+5` JEh)JCQpb)'jPGb"cG'&ZC'&bC!SJ)#"[FL"fC@jNEh)YFh"PBfPQD@-JF(*[G'p MEfac,JS+)#!J9'KP)(*PFh9XG'PZCb"cG(*PB@ec,#"cC@jd)'*j)(4SC5"cCA* fCA*c)(9ZC'9b)(4SC5"NDA*PBh4TEfiJEfBJG'KP#L!J)'KTER3JG(*KBfYc,#" ZC@9N)'0[ER4KD@iJEQmJG(*KBf8JEfBJ8A9TBfY8D@eP)'PZCQpbE@&dD@pZ,L" 8D'Pc#L!J)'4PFfPREL"NEf9c)'j[G#"bCA&eDA*P)(4SBA3J8A9TBfY8D@eP,#" [FL"TG(-JFh4bG@0dGA*PFb"[FJSJ)#"NC@0XBA*KG'P[EL"cG(PXC5`JBQ8JGA0 PC#"PDA4SCA)JD@iJG'KP)'4KG'%JEfiJG'KP)(GTFQ8JEh)JD@iJG'KP#L!J)'4 PBfpND@jR)(0dBA4TEfiZ)%C[FL"PH'&YF'aP,#"K)&&eD@0V9'PYC5"QD@aP)(9 cD@jR)%JZ-MBa)(CTC'9[)'&ZC!SJ)#"%9NNJBA9ND@mX)(0dFQ9KE@9N)(9ZC'9 b)&*88#`JFQ9cG@adFb"TEL"K)("KBfYPG#"cG(*PB@dJGfKTBfJJDA-+)#!JCR9 XE(NJBfpYF'aTB@jd)(GTG'JJG'KP)%P&9%BJFh"PBfPQD@0KG'P[ER-JCQpb)(" KBfYTEQFJG'K[Ff8+)#!JBfpND@jRFb"TER4[)&*88#i+#L!J)&4SC5"SD@jd)(4 bB@0VFb"KFQ8JBR9TE(3JB@jN)'CXB@GRC@3JFfmJG'KKG#"hD'9Z)(4SC5"`FQ9 cC@jdBA4TEfi+)#!JDA-JGQPPGf9N)'4TFQ9MG'aj)#KZEh3JFh4bC@&YC@3T,#" dD'9j)'&bC5"TCfj[FQ9N,JS+-bia)&*88#")D@jd)&4bB@0VF`S+)#!J9'KP)&* 88#"cF'9MD@CTBf&dD@pZ)(*PBfpYE@9ZC(-JFf9ZC'PZCb"PB@0S)'ePC'PK)(0 dFQ9KE5"KFb"K#L!J)(0PF'&bBA4P)&*88#"cG(*PB@dl)'eeE(4TF'aPH'PZCb" TFb"KBfKTCACPC#"LH5"eFfPZCb"*8#Gc)("[FR3Y#L!J)'aPGQ9X)'eeE(4TF'a PH'PZCb`JEQpd)'*j)'PZG'9bE'9KGQPZCb"dD'8JC'&dB5"QFQpY)'eeE(4TF'a P#L!J)(0dFQ9KEA-JD@jdEb"K)(0TEQGXC5"59&!JFf9cFfP[ELiJ5'phCACPFL` J69"&4b"cF'9MD@CTBf&dD@pZFb"NE`SJ)#"NC@CTEQ8JE@9dD'pNFb"dEb"YG@a dDA"XCAJJFf9fCA*KE#"YC@4TB5"dFQ&MDh-JD@jdEb"[EQ8J8P43)(4bB@0V,!S J)#"KEQ3JG'KTFb"YBANJBQ8JEQ9MCA0cBA*j)'PZ)(0[E@8JBA"`E'PMBA4TEfj c,L!J4@&MD#"SD@jd)(4bB@0V)'Pc#L!J)(4SCA*PCQpbC5"dD@9N,#"ZEh3JG'm JEfjP,#"LGA3JB5"cCA3JEfBJE@9ND@%JG(*KBfYc)'*j)(4bB@0V#L!J)(*PCQ9 bC@jMCA-Z)&4SC5"cCA3JEfBJFQ9QCA*PEQ0PFb"QEh*Y)'%JG'&LE'8X)(GSD@0 S)'Pc)'PZC'9iC@3JBRN+)#!JG'KP)(0KEA"XCA-J+(0PC5"LC@a[GbNJGfKPEL" cC@aPBh4TEQFJC'&dB5"QFQpY)(4SC5"YC@4TB5"dFQ&MDh-Z#L!J)&4SDA-JE@& VCA-JC@PdD'9b)'eeE(4TF'aPH'PZCb"cBfKPE@8JF'pcFfPLE'8Z#JSJ)#"8D'P c)'4PFfPREL"NC@0TC'9c)(4SC5"`B@0VCA3JFfPkC5"KG#"dD'8JG'PYC5"dD'8 JD'PZG#"dFQ&MDb"TF`SJ)#"MFQ9KG'9N1b"dD'9bC@C[FQ8X)'PZ)(4SC5"cB@e `E'8JC'9cBh*TF(4TEfiJCQpb)(4SC5"SD@jd)(4bB@0V)#KK#L!J)'4KG'%JFh4 bG@0dGA*P)(GSD@0S)'0KEL"MEfjdB@PZ)'CTC@aNFb"cF'9MD@CTBb"dEb"dD'8 J*f0[C'PZCbFJ,3SJ)#"hD'PMD#"TEL"dD'Pc)'0KFf8JDA-JB5"`FQpdEf0[E#N X)(GP)'PZC'PMBA4P)(4SC5"MD'pcC@iJF'&MDf9d#L!J)(0THQ8Z)%j[G'8JG'K KG#"TG#"TFb"fB@aTC#"QEh)JG'KPFQ8JG'mJBQ8JFf9fCA*KE#"59&!JD'PZG#" dFQ&MDh-+)#!JCQpb)'9KBfJJE@9ND@%JG(*KBfXX)(GTG'JJC'PQCQ9bC@jd)(" KBfYPG#"cDATP)'0SEfPMCA-Z)%pdD'9b#L!J)("bEh4[BfpXFb"MB@iJBQ8JF'& bB@ePG'9bDATPC#"TEL"K)(0TE@PXBA)JGf&j,L"6D@eTE'&bE(NJG'KP)(4TE@8 Y#L!J)(0MB@aP)'C[FL"dD'8J8P43)'0XEf0V)'Pc)("bEhCTC'9N)'PZ)(4SC5" cB@e`E'8JC'9cBh*TF(4TEfiZ#JSc,M%Z-5"6B@e`E'8J4'9cBh*TF(4TEfiJ4Qp bE@&d#JSJ)#"*EL"dD'8JCQPXC5"QEh*YBA3X)'9KBfJJG(*KBfXJD'&c)'%JC'9 cBh*TF(4TEfiJEfBJDA4c)'0[ER4PER4c1b"QEh)+)#!JD'PZG#"dFQ&MDh-X)(4 SDA-JC'9cBh*TF(4TEfiJC'9QD@jPFb"KEQ3JF'&bB@ePG'9bDATPFb"dD'8JF(* [G'pMEf`Z#JS+#N3Z)&0TEQGPFL!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"E8'&RC5!hA3d-$8PZG'9bEQ9d)%4 bB@Cd)#!J)#!J)#!JC(*KCR3YFfPZCf9b,A*dF#eaG'CTE'8Y-$%J)#!J)#!J)%p MG'pLCA)J-6JJ-6Nj13S+#L!J)&*88#"SD@jd)(4bB@0VFb"KFQ8JD'PZG#"dFQ& MDh-J+'ePC'PK)'KKEQ4XCA)J*fKTER3R+5`JGfPdD#"KEJSJ)#"PER4bH5eQEh* YBA3JD@iJG'KP)(0KEA"XC5"NCA0MFQP`G'P[EL"[CL!RFR4`)#F+#L!J)'&XD@G ZC@3S1#NJBfaKFh-J8R4`8f&YF'aP4@jdFRNJCAKdC@jNFb"6B@e`E'9&ER4bH5J RFR4`)#FT)(X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)(4TE@9cBf&XC6X+)#! J)#!J)#"eER0TCfjPC#"TER3S-6BT)(*dF'KTER4dFQ&MDhCPFR0TEfiJ25!a1`S J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja0LNJFR4`E'&cG'0[EA"KG'PLE'9fCA*cD@p Z)$dJ-6X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)'eKH("KBfYPG(0THQ8l#L! J)#!J)#!JFR4`G'&RFeYG)(*dF'4KG'%l#L!J)(d+#L!J)'&XD@GZC@3S1#NJBfa KFh-JFR4`G'&R+(4KCh4jF'8T)(X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)(0 THQ8l#L!J)#!J)#!JG@jcD@GZC@3JD@jd+$-b+5"dHA"P)$dJG'&RG(P`C6X+)#! JI3S+)#!JB@aTCfjPC$JT)'0XBA0c)(4TE@9cBf&XCA4KCb"PH(4PEQ4c)(*dF(4 KCbJRG'PYFbFT)(X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)#!J)(4TE@9cBf& XC6X+)#!JI3S+)#!JB@aTCfjPC$JT)'0XBA0c)(4TE@9cG'&YF'pQCR0PG(4KCb" PH(4PEQ4c)(*dF(4KCbJRG(0bEbFT)(X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c) T)#!J)(4TE@9[CQCcCA3l#L!J)(d+#L!J)'&XD@GZC@3i+5"ME'&cFb"cCA&eC@j MC@pQCR0PG(4KCb"PH(4PEQ4c)(*dF(4KCbJRFfjbEbFT)(X+)#!J)#!J)#"eER0 TCfjPC#"TER3S-c)T)#!J)(0PFA9PEQ0PEfCQFf9d1`SJ)#"p#JS+)#!J9'KP)(0 PE@&ZG'PMFb"[CL"dD'9cC5"QD@9XC(-JBA*P)'&c)'C[E'a[Gh-k)#"bG("SD@j dG(*KBfYfCA*cD@pZ#L!J)'Pc)(4SC5"fCA*cD@pZ)'pQ)(4SDA-JD'PZG#"dFQ& MDcXJ)(4SDA-JC'pMG@ePER3JDA-JGQ9bFfP[EL!a#L!J)(*dF'aKFh4MEfe`BA4 TBQaPGQ9bFfP[EL!JDA-JG'KP)(CPFR0TEfiJEfBJG'KP)'pXC'9cG#"MEfe`BA4 TBQaP#L!J)(*PB@4PFL"dD'&d)(0SEh9XC#"LC5"KBQaP)(4[)(*PB@3JG'KTFb" SD@jd)(4bB@0V)'eKH("KBfYPG(0THQ8J)'Pc#L!J)(4SC5"cDATP,#"TEL"LHA4 PFb`JEfBJG'KP)'aKFQGPFh3JF'&MDf9d)(4SDA-JG(*KBfXJGfPXE#"QEh*Y#L! J)(*dF'4KG'%J)'Pc)'%JFf9bD@9c)'pQ)(*dF(4KCh-X)(4[)'CTE'`JG'KP)(* PFh3JEfBJG'KP)'&dEfdX#L!J)(0PE'9MG'9N)'CbEfdJG'KP)(0eBQ0XBA0cCA- JEfBJFR4`G'&R)(4TE@9cBf&XC5!JDA-JB@iJEf*XD@GKG'pbH3SJ)#"dB@Fl)#" TG#"TFb"dD'8JFR4`G'PYCA0MB@aP)(4SBA3JGf&c)(9cC@3JG'mJCQpbE5"dD'P c)'KTER3JG(*KBfX+)#!JG'PYC@pQCR0PG#"KEQ3JFf9aG@9ZBf9[CQCcCA3J)'& bC5"[F(4TEfjKE$XJ)(4SCANJD@jND@0KG'8JG'KKG#"dD'8+)#!JFf9bGQ9b)(0 SEh9XC#"eFf8JG'KPFf8JCQPiC@3JEfCQFf9dFb"QEh)JG'KPFf8JCQPPE'4c)'P Z)(4SC5"59&!+)#!JF'&MDf9dFb`JD@jcG'9KC#"[CL"dFR9XH5"bB@jNEfdJER9 YBQ9bF`S+-bia,M)J4'9ME'&bBA4TGQ8JB@jN)&0PFh0TEfiJ4'9cBh*TF(4TEfi JC'&dB3S+)#!J9'mJB@PN)(0PFRCPFR-JGfKTBfJJGA0P)(4SC5"64&!JCQpbE@& d,#"dD'8JD'PZG#"dFQ&MDh-JBfpZG'&TEL"LBA0P#L!J)'4KG'%JGfKTBfJJBf& Z)'*P)(9cC@3JD@iJBA0cC@eLE'PZCb"K)'0[EA"XCA4P)&0%8#"NCA0MFQP`G'P [ELi+)#!J9'KTFb"NBA4K)'Pc)(0dEh*PC#"TEL"SD@jd,@PZCQpbE@&dD@pZ)#J RD'jdD5FT)'&dEfec)(GTG'KTEL"eFf9b,3SJ)#"NBA4K)#JRG@4dB5FT)'&dEfe c)'PZ)(4SC5"YEhCTC5"KG'pY,#"[FL"TEL"PB@0S)(4bB@0V,L!J5@iJG'KP#L! J)'e[GQPP,#"dD'8JD'jdD5"KG'pY)'KKFb"K)(0eBLeKG'pY)'pQ)(4jF'8J*h* dF#!R)'&ZC#"cG'&bG(-JGfPdD!S+#JT%,L"6D@jRCA)J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J@e"KCf8J1&d 0$!e*ER4PFQjPG#"%FQ&QG#!J)#!J)#!J)'4bB@Cd,A0TEQGPFLebG(!YFA4QD@a P,6!a)#!J)#!J)#"2Bh4[BQ9b)$%i)$%j16N+#JSJ)#!RFf4`)#FJ+'j[G'8JG'K P)(0`B@0PFbNZ)#"ADA4SD@iJ8P43)'KTER3JG(*KBfYc,#"dD'8JFh9L,@&dEfd JD'&c#L!J)(4SC5"dHA"P)#GcC(!J*b!SB@GKD@iX)'j[G'8JG'KP)(0`B@0P+5i J)&4SC5"MEfjdC@jdFb"TEL"PDA4SCA)JBf&cC3SJ)#"TFb""8d0*55"dCAKd,#" cG@PdB@*XC5"QEh)JCQpbE@PZCb"TER4[)'0[EA"XCA4P)&0%8#"NCA0MFQP`G'P [ER-Z#L!J)&4SC5"cCA*fCA)JGfPXE#"ZC@9N)(4[)'GPEQ9bBA4P)'%JER9YBQ9 b)'pQ)(4SC5"XD@jPFb"[CL"dD'8J8d431`SJ)#"dD'8JC'&dB5"cGA"`E'PPC#" SCA*P)'Pc)'pZE(NJF'&bG'PKE#`JE'PYDA4PC#"dEb"dD'&d)'YZEhGZ)'&d#L! J)'KTER4TEQFJG'PYC5iJ)&4SCA*P)'Pc)'&XFfmJB@iJEh"dD@pZB@`JGA0PFLe NBA4K)'&dEfdJCfPfD@jR#L!J)'pfCA*KE'`JD@jQEh*YBA4TEfiJB@*[GA3JG'K P)'KTER3JG(*KBfXZ#JSJ)#"KE'PREQ9N+$JT)'0XBA0c)'KTER4TEQC[FQeKG'P [EL"PH(4PEQ4c)%&dEfdS*fKTEQBR+5"l#L!J)#!J)#!JD@jQEh4KCh0EA5"TEQC [C'&dB6X+)#!JI3S+)#!JB@aTCfjPC#Ji+5"ME'&cFb"TEQC[G'&R+(4KCh4jF'8 T)(X+)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)(0THQ8l#L!J)#!J)#!JG@jcD@G ZC@3JD@jd+$-b+5"dHA"P)$dJG'&RG(P`C6X+)#!JI3S+#L!J)&4SC5"QEfaXEhG TEQFJD@jQEh*YBA4TEfiJG'&RFb"KEQ3JGQ&XG@9c)'&bC5"NC@CTEQ9N,L!J9'K PH5"KFQ8JB@aX#L!J)'p`G'P[EQ&X,#"KEQ3JG@jbC@0[CfjTHQ9N)(4KCh-JFfK [G@aN)'*P)'PREQpbC@3Z#L!J)(4KCb!J)#!JGQ&XG@8JCQPPE'3JG(P`C5!J)#! J)#!J)#!J)#!JGQ&XG@8+)#!JG(*`H5!J)#"eER0TCfjPC#"TER3S0M3T)#!J)#! J)#!J)#!J)#"dEh4KE#"LHA4PFb"dD'&d)(GTE'`JBQ8JFf9ZG#`+)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"TEQ0XG@4TEQFJ8P43)'K PB@4PFR-X)'*eG#"ZEh3+)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#"[G'KPFL"SC@&NCA*c)'peG(0TC'8JG'KKG#!SC5jR#L!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J9843,#"*8#"[FL"XD@j V)'aKH@9b)'KPB@4PFR-T#L!J)'jeEA!J)#!JG@jcD@GZC@3JD@jd+$Bd+5!J)#! J)#!J)#!J)#!JG'pdB@`JER9YBQ9b)'pQ)("KBfYPG(-JFf9ZG!SJ)#"dF(PX)#! J)(9ZFfPREQ9N)'PZG#Jf0#NJ)#!J)#!J)#!J)#!J)(4[G'&X)'*jG'9c)(4SBA3 JGfPXE#"LC5"cC@jd,!SJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)'j[G#"TEQ0XG@4TEQFJ8P43)'KPB@4PFR-+)#!JE@&iFL!J)#"eER0 TCfjPC#"TER3S-c)T@c*G)#!J)#!J)#!J)#"YBAKTEA9Y)'4KG'%JFQ&dC5iJ)(4 hEb"fB@aeCA-X#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!JCh*KER9XBA*TG(NJ+'PZ)'eTE'aTFf9MEfjNFbNX#L!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!JB@jN)'dX)(4SC5"YBAKTEA9Y)'4 KG'%+)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"dFQ& ZFfeTG(4PC#"TEL"KERNJD@jdCA*fB@`JEfB+)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#"dD'&d)'4eFQ&dD@pZ,L!J9'KPFQ8JE@&j)'* P#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!JEA9XG'P `E'8JE@&iFL"dB@Gc,JSJ)#"NE@9N)#!J)(9ZFfPREQ9N)'PZG#Jf0#NJ)#!J)#! J)#!J)#!J)(4[G'&X)'*jG'9c)'0[F'PPC#"LH5"bC@CPFQ9ZBf8+)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"QFQpY)'ePC'PK)(4bB@0 VF`SJ)#"ND@eY)#!J)(9ZFfPREQ9N)'PZG#Jf0#NJ)#!J)#!J)#!J)#!J)(4[G'& X)'*jG'9c)(0PER3JBA-JD@eYC@4TBA4P#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!JC'&dB5"QFQpY)(4SC5"SD@jd)(4bB@0V#L!J)'4 bCA!J)#!JG@jcD@GZC@3JD@jd+$Bd+5!J)#!J)#!J)#!J)#!JG'pdB@`JBRPdCA- JEfBJFQ9`C@&dC@3JC'&dB3SJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)(4SBA3JGfPXE#"LC5"cC@jd#L!J)(4YD@iJ)#!JG@jcD@GZC@3 JD@jd+$-b+5!J)#!J)#!J)#!J)#!JFfeKE'aPFh3JFQ9XBA4TGQ8JG(*KER0YDA0 cD@pZ#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!JG'P YC5`JD@iJE@PXE'PcC@0[EQ4c#L!J)(4YBAJJ)#!JG@jcD@GZC@3JD@jd+$-b+5! J)#!J)#!J)#!J)#!JE'&bCf9cG#"bC@aKG'PfC5"dFQ&ZFfeTFh0TEfi+)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"dD@eP,#"TEL"YD@a XDA0PBfpZC(-+)#!JF'eKH#!J)#"eER0TCfjPC#"TER3S-c)T)#!J)#!J)#!J)#! J)#"XBA*RCA0d)("KBfYPG#"cC@jd,#"TEQ0XG@4TEQF+)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"59&!JD'9KC'9b#L!J)'4YBAJJ)#! JG@jcD@GZC@3JD@jd+$-b+5!J)#!J)#!J)#!J)#!JE'&bCf9cG#"`B@0VCA3JC(9 bBA4TEfiX)'PZ#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!JE@PXE'PcC@0[EQ4c#JS+#N3Z)&0TEQGPFL!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#"E8'&RC5!jA3d-$8P ZG'9bEQ9d)%4bB@Cd)#!J)#!J)#!JC(*KCR3YFfPZCf9b,A*dF#eaG'CTE'8Y-$% J)#!J)#!J)%pMG'pLCA)J-6JJ-6Nj13S+#L!J)("KHA3J)#!JG@jcD@GZC@3JD@j d+$-b+5`JFh4bD@jR)#!J)#!JG'KP)("KH@a[B@3JG(P`C5`JCQpXE'phC@3JBRN JB3SJ)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)'0[G@j dC@3JFh4bD@jR)'pQ)(4SC5"bG("YBA!+)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#"TEQC[FQeKG'P[EJS+-bia,M-J8P43)&0KEA"XC5" 'Eh*YBA3+#L!J)%9KBfJJFf&YF'aP)'PZ)(4SC5"59&!JD'PZG#"dFQ&MDb"MEfj dB@PZFb"dD'8JD@jcG(*eBh4TEfjc)(4[)(0PEQ3+)#!JEh9d)'%JFf9d)'pQ)(" KBfYPG(-JGfKTBfJJEA9cG#"LC5"dFQ&ZFfeTG(4PC#"KG#"K)'GTGQ9Z)(4TE@8 Z)&4SC3SJ)#"dD@eP)'PZ)(4SC5"SD@jd)(4bB@0V)'Pc)(4bB@jcE@PcFfP[EL" dD@eP,#"ZEh3JEQ9MCA0cBA*TE(NJG'KP#L!J)'ePC'PK)(4TE@8JEfBJG'KP)'& cFfpMD@&dC@3JE@9ND@%Z#JSJ)#"1Eh4TBf8JG'KKG#"hC5"ZEhFJC'9cBh*TBQ8 JG'KP)'PZG'9bEQ&X)(0dFR9MG(9bC5"[CL"cB@e`E'9c,#"hD'PMD!SJ)#"KFQ8 JE@9ND@%JC'&dB5`JEQpd)'ePG'%JC'&dB5`JD@iJG'KP)(4PFQeTEQpXEfGj)'p Q)(4SDA-JF(*[F'pcB@`Z#L!J)&4SCA0P)'jPC@3JEQpd)'*P)(0dFR9MG(9bC@3 JBA-JEf*UC@0dFbi+#L!J)%9KBfJJFf&YF'aP)'0[ER4KD@jc)(4hEb"KFQ9KFcS JG'KP)'PZFh4bG@0dD@pZFb"dEb"MEfe`Eh0P)(4SC3SJ)#"`B@0VCA4c,#"KEQ3 JB@jj)'9iG(*K)'4KG'%JEQ9PC'9N)(GSC@iJFf9ZC'PZCb"dD'pcC5"`B@0VCA4 c)#KP,QFZ#L!J)'&Z)'9ZBh*jF(4PC#"fCA*cD@pZ)'pQ)(4SC5"YC@4TB5"NBA4 K+5i+#JSJ)#!J)#!J)#!J)'&XD@GZC@3S1#NJBfaKFh-J8P43Ff&YF'aP)(X+)#! J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja0LNJ)#!J)#!J)("KBfYPG'0 [G@jd1`SJ)#!J)#!J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$%f+5!J)#!J)#! JFQ9cCA*fC@3l#L!J)#!J)#!J)#!J)#!J)#!J)#"59&"`B@0VCA3J)#!J)#!JF'& MDf9dFeY`B@0VCA4MEh9ZG&dl#L!J)#!J)#!J)#!J)#!J)#!J)#"LHA4P)#!J)#! J)#!J)#!JCAKdFQ&NBA4K@edl#L!J)#!J)#!J)#!JI3S+#L!J)%9KBfJJ8P43)(" KBfYPG#"MEfjdB@PZFb"dD'8JD@jQEh*YBA4TEfiJG'mJFf9ZC#"K)(0TEQGXC5" `B@0VCA3Z)%PZ#L!J)'pbC'9b)(4[)(0PF'&bBA4P)'ePC'PK)(4TE@8JCR*[E5" dFQ&ZFfeTFh0TEfiJG'PYC5`JB@iJ8P43)(4TE@8+)#!JFh4KEA!JDA-JFh"PBfP QD@0KE'aj)'PZBfaeC'9N,#"KE'pZCb"hDA4S)'4KG'%JEQ9PC'9N)(4[)'C[FQd JG'KP#L!J)&*88#"SC@&NCA)Z)%pdD'9b)'KPB@4PFL"TEQC[FQeKG'P[EL"TFb" cGA"`E'PPC$XJG'KP)'&XCfpbDA4SEA-JCQpb#L!J)'C[FQeTEQFJG'KP)&*88#" SC@&NCA)JCfPfC@iJG'KP)'PZCQpbE@&dD@pZ)'KPFQ8JBA*P)(0TEA"XC5iJ9'K PEJSJ)#"dD'9bC5"TFb"K)(4KBQaP)'pQ)'0[ER0dFR9MG'P[EL"PER4bD@9c1JS +#JS+#JS+#JS+#JS+#JS+#N3Z)&0TEQGPFL!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)&Y3B@GP)$%`A3d-$8PZG'9 bEQ9d)%4bB@Cd)#!J)#!J)#!JC(*KCR3YFfPZCf9b,A*dF#eaG'CTE'8Y-$%J)#! J)#!J)%pMG'pLCA)J-6JJ-6Nj13S+#JSJ)#!J)#!J)#!J)'&XD@GZC@3S1#NJBfa KFh-J8P43F'&MDf9d)(X+)#!J)#!J)#!J)#!J)#!J)#!J)(0TCfjPC#"TER3S-c) T)#"bC@aKG'PfC5edD@eP1`SJ)#!J)#!J)#!J)#!J)#!J)#!J,bmJG'KP)'jPH(3 JCQPPE'4c)'C[FQdJD@jTG'PKE'PkBA4TEfiJCQpb)(4SC5"59&!+)#!J)#!J)#! J)#!J)#!J)#!J)#m[)'KPB@4PFL!S-6BJBQPdFbNX)'&ZC#"dD'8JBQPd)("[FfP dD@pZFb"MEh*bCA0`EfjN#L!J)#!J)#!J)#!J)#!J)#!J)#"LDA3S-LNJ)(*PFf9 bGQ9N1`SJ)#!J)#!J)#!J)#!J)#!J)#!JBQPd+$%T)#"3,@*TG$X+)#!J)#!J)#! J)#!J)#!J)#!J)'*TG#Ja+5!J@#eLDA3l#L!J)#!J)#!J)#!J)#!J)#!J)#"LDA3 S0#NJ)(*PFf9bGQ9N1`SJ)#!J)#!J)#!J)#!J)#!J)#!JBQPd+$%T)#"0,@*TG$X +)#!J)#!J)#!J)#!J)#!J)#!J)'*TG#Jh+5!JF'&jE'pKC#edHA"P1`S+)#!J)#! J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja0LNJ)#!J)#!J)&*88(0PFA9PEQ0 PFf9PC$X+)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja-bNJ)#!J)#! J)'CXB@Gc1`SJ)#!J)#!J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$%T)(JYCQa KCcX+)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja+5"L,@CXB@Fl#L! J)#!J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3S-5NJFLeQE'&R1`SJ)#!J)#! J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$%f+5!J)#!J)#!JC@jdFRPMEh9ZG$X +)#!J)#!J)#!J)#!J)#!J)#!J)'4KG'&PER4bH5!J)#!J)#"MEfjcG(*eBh4[FR0 EC@jdFRPMEh9ZG&dl#L!J)#!J)#!J)#!J)#!J)#!J)#"TCL!SH#eQE'&R+5"l#L! J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Jc-LNJ)#!J)#! J)'9iG(*K,@PZCQpbE@&dD@pZ,A0THQ8l#L!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)&4-9L!J)#!JG'afC@jdFQPPFeYG1`SJ)#!J)#!J)#!J)#!J)#!J)#!JI3S J)#!J)#!J)#!J)(d+#L!J)#!J)#!J)#!JB@aTCfjPC#Jc-LNJBfaKFh-J9%a@)(X +)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Jc-LNJG'afFfPkC6X+)#! J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Jc-LNJG'afG(P`C6X+)#!J)#! J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ji+5"dE(CNBA4K1`SJ)#!J)#!J)#! J)(d+#JS+)#!J9'KP)(*PE'&dDACP,A4TE@8JCQPPE'3JDA-JB5"cD@GZC@3JGQ& XG@8JD@iJG'KP)'KTER3JG(*KBfXRF`SJ)#"dD@ePFf0KE'8X)'&NDR9cG'PZCb" dD'8JG(*KER0YDA0cD@pZ)(4TE@8JEfBJG'KP)("KBfYPG#"KGf&j)'CbEfd+)#! JG'KP)&*88#"cB@e`E'8JG'PYC5iJ)&4SDA-JB@aXEhGc)(4SC5"SD@jdCA)JG'm JFfe[Eh4S)(4SC5"NBA4K)(*KG'8+)#!JEfBJG'KP)(4bB@jcE@PdG'9N)("KBfY PG(-Z#JSJ)#"8D'8JH#eQE'&R)'PZC'PMBA4PFb"dD'&d)(4SCA*P)'Pc)'9iG(* K)'PZCQpbE@&dD@pZ)'&QG'9b)(4SC3SJ)#"MEfjcG(*eBh4[FR-X)'PZ)(4SC5" QEh*Y)'pQ)&4-9Q9ZG(*TCA-Z)%pZE(NJEfjP)(0eBfJJC@jdFRNJDA-+)#!JBh9 bFQ9ZG'aj)'4PCQPZC@3l)(4XGR4jF'8J25!RFR4`EbFJCfPfCA-JB5!c-LeLDA3 JFfPREQ9N)'PZG'9RCA)+)#!JEfCQFf9d)(4[)(4SC5"KBh4eB@`J8P43)(4TE@8 YFh4KEA!JG'mJF'aKBf8JD@iJG'KP)("KBfYPG#iJ9'KTF`SJ)#"PEQ&LE'9c)(" KBfYPG(-JG'mJBQ8JF'aKBf9N)'PZ)(4SC5"SD@jd)(4bB@0V)'PZ)'4PBfpND@j R)'pbC'9b,#"LGA3+)#!JD'&fC5"dD'9TFL"`FQ9cC@jdBA4TEfiJG'PYC5ecG'& YF#"TEL"dD'8JG(*KER0YDA4dC@3JF'&MDf9d)'*P)'PZ)'%+)#!JC'PQCQ9bC@j d)'pbC'9b,L!J6QpdC5"dD'&d)'&XE#"86&CPER4bD@9c)'&bC5"NC@CTEQ9N)(4 [)'*P)$-b,@*TG!SJ)#"KE'PREQ9N,#"KEQ3JG'KPFQ9QEh*P)(4SC@Pb)'aPEQG dD#"cD'peE'3JBQ8JF'&NC'9N)(4[)'%J0#eLHA4P#L!J)'*[G@jNBA*j1b!JG'K P)'pZE(NJCAKTFh4TEQFJC@jdFRNJD'&c)'%JE'9ZCh4S)'pQ)$3JBRPdCA-X)(0 [)(4SDA-+)#!JDA-JEQpd)'0eFR*PER4XH5"KEL"TFh0eC5i+#JS+4#iJ8fPZCf9 b)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J@e"KCf8J-6&G$3`05@jdCA*ZCA3J4(*KCR3J)#!J)#!J)#"NFQ&QG#e cD@jRCA)YFR4`,A&dCQPXC5d`-5!J)#!J)#!J6f0dEf*PFL!a1#!a16Nj#JS+)#! J9'KP)')YCQaKCb"TEQ4TBf&dCA-JB5"NDA0`Eh0KBQaP)#GL,@CbB@eP*biJ9'K P)()YCQaKCb"TEQ4TBf&dCA-JB3SJ)#!RFQ9`C@&d)("KBfYPG#FX)'pZC5"dD'& d)'Pc)(0PER3JBA-JB5"NGA"XD@0KG'8JEfBJB5"`FQ9fD@peF`SJ)#"`B@0VCA3 Z)&0PFRCPFR-JE@&j)(GTFfJJG'mJEh"dD@eTHQ8JD'&ZC'aTEQFJEfBJG'KPFf8 JF'&MDf9dFbi+#L!J)&4SCA*P)'&bC5"fBA*TEh9c)'C[FQec)'pQ)(4SC5"MEfj cG(*eBh4[FLiJ4@&MD#"MEfjcG(*eBh4[FL"TFb!a0JSJ)#"LHA4PFb`JG'mJE@& VC5"TG'9bBA4TEfiJC@&cD@9b,L"8D'8JCQPbFh3JBRPdC5"TFb"K)(9ZD@pZ#L! J)'4TFf0bD@eTEQ&dEh)k#JS+)#!J)#!J)#!J)#"KE'PREQ9N+$JT)'0XBA0c)&* 88'0[ER0dFR9MG'pb+(4jF'8T)(X+)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9 N)'PZG#Ji+5"MEfjcG(*eBh4[FLedHA"P)$dJG(P`C6X+#L!J)#!J)#!J)#!JI3S +)#!J)#!J)#!J)#"KE'PREQ9N+$JT)'0XBA0c)&*88'j[Eh"MEfjcG(*eBh4[FJS J)#!J)#!J)#!J)#!J)#!J)#!JCAKdC@jNFb"59&"MEfjcG(*eBh4[FLJ`+3SJ)#! J)#!J)#!J)(X+)#!J)#!J)#!J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ji+5"`B@4 E-69G1b!J)#!J)#!J)#!J)#!J)#![,b!a05"LHA4PFb"TCfj[FQ9N#L!J)#!J)#! J)#!JI3S+)#!J)#!J)#!J)#"KE'PREQ9N+$JT)'0XBA0c)&*88'PYE@9ND@&dC@0 [ER0dFR9MG'pb#L!J)#!J)#!J)#!J)#!J)#!J)#"PH(4PEQ4c)&*88'0[ER0dFR9 MG'pb+$%T#L!J)#!J)#!J)#!JH`SJ)#!J)#!J)#!J)#!J)#!J)#!JG@jcD@GZC@3 JD@jd+$JT)'0[G@jd1`SJ)#!J)#!J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$J T)'4KG'&EBfpeER4G1`SJ)#!J)#!J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$J T)("KC&Xa0#eMEh9ZG&dl#L!J)#!J)#!J)#!JI3S+)#!J)#!J)#!J)#"KE'PREQ9 N+$JT)'0XBA0c)&*88(0KEA"XC@0[ER0dFR9MG'pb#L!J)#!J)#!J)#!J)#!J)#! J)#"PH(4PEQ4c)&*88'0[ER0dFR9MG'pb+$)T#L!J)#!J)#!J)#!JH`SJ)#!J)#! J)#!J)#!J)#!J)#!JG@jcD@GZC@3JD@jd+$JT)(4bB@0VFQ9QD@jNCAJl#L!J)#! J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3S-6BT)#!J)#!J)#"XC@jRG'Jl#L! J)#!J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)#!J)#!J)#"cB@e`E'9 ZG@eLCA)l#L!J)#!J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)#!J)#! J)#"cB@e`E'9[CQCcCA3l#L!J)#!J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3 S-6BT)#!J)#!J)#"LHA4PFh"PFQ*XEf0V)$dJ-6X+)#!J)#!J)#!J)#!J)#!J)#! J)(9ZFfPREQ9N)'PZG#Ja0LNJ)#!J)#!J)(0KEA"XCA0`CA*LE'pMDb!p)$%l#L! J)#!J)#!J)#!JI3S+)#!J)#!J)#!J)#"KE'PREQ9N+$JT)'0XBA0c)&*88(0KEA" XC@4PFf0bDA"dD@pZBfpZFh4bG@0dEh)+)#!J)#!J)#!J)#!J)#!J)#!J)'9iG'9 ZC(-J8P43BfpZFh4bG@0dEh)S-bN+)#!J)#!J)#!J)#"l#L!J)#!J)#!J)#!J)#! J)#!J)#"eER0TCfjPC#"TER3S1#NJG(*KBfYbC@CTEQ4PH$X+)#!J)#!J)#!J)#! J)#!J)#!J)(9ZFfPREQ9N)'PZG#Ja0LNJ)#!J)#!J)'aPEQGdD$X+)#!J)#!J)#! J)#!J)#!J)#!J)(9ZFfPREQ9N)'PZG#Jc-LNJ)#!J)#!J)(0KEA"XC@4PFf0bDA" dD@pZD@jNCAJl#L!J)#!J)#!J)#!J)#!J)#!J)#"eER0TCfjPC#"TER3S-c)T)#! J)#!J)#"NCA0MFQP`G'P[EQpQCR0PG$X+)#!J)#!J)#!J)#"p#JS+#JT%,L"6D@j RCA)J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#"E8'&RC5!a-Pd0$!e*ER4PFQjPG#"%FQ&QG#!J)#!J)#!J)'4bB@C d,A0TEQGPFLebG(!YFA4QD@aP,6!a)#!J)#!J)#"2Bh4[BQ9b)$%i)$%j16N+#JS J)#"8D'8JD@eYC@4TBA4P)'e[C'8JF'9bE@PdFb"dD'8JD@jcCA*dD@pZ)'pQ)(" KH@a[B@3YFh"PBfPQD@-JD'9KC'9bF`SJ)#!SC5jR,L"dD'8J8P43)%JZ-MBa)'K PB@4PFLNZ)%C[FL"SD@jd)(4bB@0VFb"hD'9bC5"dD'8JE@9ND@%JDA-JFf9ZG!S J)#"eEQ0SB@jRC@3X)(4SC5"cB@e`E'8JC@jdFRNJG'KPEL"cF'9MD@CTCA-JG'K P)'*jG'9c)(4[)'0[F(NJCR*[E5"dD'8+)#!JE@9ND@%JG(*KBfXX)'*j)'GTGQP ZCb"dD'8JFf&YF'aP)'jeE@*PFL`JC'&dB5"[CQCcCA3X)'&ZC#"XC@jRG'JJG'm +)#!JBfp`H5iJ4Qpb)'0[EA"XCAJJBf&cCA-J+'8ZCbiJC@jMFRP`G'P[EL"[FL" QEh*hBA*N)'9bFQpb#L!J)'0[FR*PBh4TEfiT,#"dD'8JG(*KER0QEh*YC@3JC'& dB5"hEh9XC#"LC5"`E'&MC@3JD@jdEb"dD'8JD'PZG!SJ)#"cB@e`E'9c,#"KEQ3 JG'KPEL"SD@jdFf&YF'aP)'e[C'8JGfpeE'3JBQ8JGA0PC#iJ6QpdC5"dD'&d)(4 SDA-JGfpeE'3+)#!JBQ8JCR*[E5"dD'8JCAKdFQ&NBA4K)'CTC@aN)'PZ)(4SC5" 59&"cB@e`E'8JDA4cC@aQ,JS+)#!J9'KP)'*jG'9cF'9bBQa[BfXJB@jN)(0KEA" XCA0`CA*LE'pMDb"MEfjMCA*Z)'0[EA"bCA0cC@3JBA9ND@mZ)&4SDA-+)#!JB@a XEhGc)(4bB@jcE'&dD@pZ)'pQ)(4SC5"cB@e`E'9ZG@eLCA)JD@jdEb"KEL"KBh4 eB@`JBRPdC5"[CQCcCA3JD@i+)#!JG'KP)'&eC'P[)(4bB@0V,L"8D'8JFf&YF'a PC'9cBh*TF(4TEfiJE@pNC5"KE'a[Gh-JFf9ZC'PZCb"[CJSJ)#!SF'pbG'P[ER- JEfBT)(0KEA"XC5"NCA0MFQP`G'P[ER-JBA-JF'&bG#"[CL"KEL"59&!JF'&MDf9 d,JS+)#!J6QpdC5"dD'&d)(4SCA0P)(0dFR9MG(9bCA-JFfK[G@aN)'*P)'CXCAK TBQaP)'9ZEh9RD#"dEb"MEhCPFL"ZEh3+)#!JEfjXH5"dD'8JFh4KEQ4KFQ3J8P4 3)("KH@a[B@4c)#K),M)f-5`J69"&4b`JCA4M,LNJBR9d)'&XFfmJF(*TGQ&dC3S J)#"`B@0VD@jRFb"cG@0S)'&c)(4SC5"4G@PMDe4TE@8YD@iY8P43)&XcA5`JEh) JCf9ZCA*TBb"`B@0VD@jR)'&c)'Pc#L!J)'j[Gb"LC@PZCb"`FQp`Eh0PC#"E0&d Z#JSJ)#"1Eh4TBf8JG'KKG#"dD'9bC5"TFb"ZEb"bCA&eDA*PE@9ZG#"dD'&d)(0 eBf0PFh0TGQ8JF'&MDf9dFb"dFQ&ZFfeTG!SJ)#"cG@0MCA0cDACP)'*jG'9c)'C bEfdJG'KP)'ePC'PK)(0dFQ9KE5iJ4Qpb)'9iB@e`E'8X)(4[)'0[EQC[FQdJGfP dD!SJ)#"59&!YFh4KEQ4KFQ3JF'&MDfPZCb"[CL"),M)f-5`JDA3JDA-JFfpYCA4 TE@9c)(*PFA9TFQ9N)(4SBA3JB5"LHA4P#L!J)'*P)(0PER3JBA3JG'KP)'9ZC#" [CL"[EQ8JF'&MDf9d)'&ZC#"KE(0[)'&d)(4SC5"LC@GTEQjTEQFJEfBJG'KP#L! J)'jPH(3J+(GSC@iJB5"YB@0bEf*XEf0V)'*[G@jNBA*j)'CKE'ac)(GTG'KTEL" K)'*jG'8T,L!J3fpZGQ9bFf9XH5`+)#!JF'&jE'pKC#"`B@0VD@jRFb"dD'&d)'P ZG'9bE'9KGQ8JG'KP)'4KG'%JG'mJB@0SD@9fC5"PFR*[FL"bCA0TE'PPEQ0P#L! J)(GTE'`JFfYTF#"cEfeP)'*jG'9c,#"dEb"cC@jN)(4SC@dJD@iJB@j[G'KPFL" `B@0VCA3Z#JSJ)#"1Eh4P)(4SBA3JDA3JDA-JF'pcFfPLE'8X)'&ZC#"XC@GKE#` JG'mJBfp`H5"KE'`JC'&dB5"TER4[)(4SC5"SD@jd#L!J)(4bB@0V,#"KEQ3JGA0 P)(0KEA"XC5"MEfjcG(*eBh4[FR-JGfPdD#"K)(4bB@0VFQ9QD@jNCAJJEfBJ,6% +)#!JG@jTCQpbE@aj,L!J9'KPFf8JGfPXE#"LC5"cD@e`E'9b)(4[)'PZG'9bF(* PG#"QEh)JG'KP)(0PFRCPFL`JBR9d#L!J)(4SC5"QD@aP)(GTE'`JBQ8JE'&bCf9 b,JS+#N&MDfj[GfaPC'GYC@jdF`S+)#!J9'KP)'&eG'K[FL"hEh9XC#"XD@YP)(4 [)(4SB@jV)'%JER9YBQ9b)'pQ)("PEh"XC5`JF'&bG'PMG@aKFQaj)&"PG'9b#L! J)%K[C'4TC5!S3A"`E'8J3fpYF(9dCA)T,#"AD@aXD@&Y)%*PE'YZBA!J+%P#65" $Eh*`Eh*KG'P[ELNX#L!J)%0SFQPcG'p`D'9b)&GKE(4[EL!S6Q9dFf0KF'8T,#" %BACP)&"KGh0[EL!S6h*KBfaP+5`J8QpZB@aN)%TKBfpLH3SJ)#!S8fPXD@0[EL" (FQ&`D'PMFb`J5@jM,LNX)'&ZC#"(CA*KFQ3J4Q9bEQ&ZC'mJB@jN)%eTBfKKC@` J8h"PCA)J+&0eEJSJ)#"0D@0bEh0jFh4PEA-T,JS+#JS+#JS+#JS+#N3Z)&0TEQG PFL!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)&Y3B@GP)$%cA3d-$8PZG'9bEQ9d)%4bB@Cd)#!J)#!J)#!JC(*KCR3 YFfPZCf9b,A*dF#eaG'CTE'8Y-$%J)#!J)#!J)%pMG'pLCA)J-6JJ-6Nj13S+#P* PCQ9bC@jMCA-+#L!J)&XaA5"),L"6BfKeE(TbD@jZC5`JCA3Z)'&X,L`J)P*88#! k)%%J9(*KER0`Eh*d)&"bEh4[BfpX)'C[FL"5C@&X,3SJ)#"8D@eP)%&`F'aTBf& dD@pZFb)X)%P&9%BJ8NC$)$%i1$NX)%TKER9KFRNJ-6Nj0Li+#L!J)&XbA5""F(" XC5"$Efe`GA4PFL`J5@jM,L`J)P&eD@0V9'PYC5"'D@aP)%C[FQeKG#"6F'9MD@C TBf&dD@pZ)L`J6@&j#L!J)$%j16BZ#L!J)$aQG(!k,bpQG(!ZBA"`E'8ZBfpY,e& eD@0VG'PYC5pNCAChEh*XC#p4G@PMDe4TE@8[E@&M,e&eD@0V9'PYC5j`C'Bq,JS +4AK`DA*PFb!k)%&`FQPX)$)b)$%j16N+#N&eG'K[FLGc)%0[ER4KBh3J5@jQEh* YBA4TEfi+)#!J4'&fD@3J8fPZCf9b#L!J)%9YB@PX1L"cD@jRCA*!BA"`E'8ZBfp Y#L!J)&4PE$SJ+$3`1#NJ16Fd)$-a0M)+#L!J)%&`F'aP)%0[EA"eG'9b,#"*EQ- Z#L!J)%pZC5"*EQCTEQPdC5"-Efp`,#"08cSc-$)Y-de8#L!J)%0eF'9bG'PZEb! J3d%J168`-63+)#!J990"#JS+#JS+#JS+#JS+#JS+#JS+#JS+#JS+#JS+#JS+#JT %,L"6D@jRCA)J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#!J)#! J)#!J)#!J)#!J)#!J)#"E8'&RC5!a0&d0$!fRRJ!!!3!!!!&-!!!!6!!!!$+ehGK K%&A#DeGl*lNfY,"XJKET9"1SX2%SXQD9`3j)rH-q6ba4(fYLqAXHT"1Z4ZmLBYm 4KS&4l-"N2!"2qB%2YMZ16e&`XjKJ5!5'X2k`B`$LfE)C"VES631lBYKHP96kjYE Zc!KT00K$Jm!+d#IldalKEU(NAhIADkfj$RVaIQJSfSR0Pm2Cb3JQ`#2Vaa!rbH5 DdGMF$1EUVJZ2+B1MD6a`r5TC6C([DjQjrSDbTP@5&PJCh8+Q1VbGpEGEm,"kU%* (03Sk'R`ir855-i(&I'jFblM")i&LRTJQfDM+e0Q%h+%qA5Q0aeH0i9*jSY%!!!" )!!P0EfjKBfm!6@!`!!!!!!K&Mr`)CEX3)J!%5!K!cU$rr!!%!!3!+!!#!ZX#!!! S!!)#k`)!Y$5k&J!!!!!!!!!!!!!VL3%!!!!"!!!!!8`!!!"-!!!!-JJmB#JdK!! !!"`!-J!!69"68J!!!!S$lIrr!!!!!!K)-)4N)!: --============_-1271499387==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" David Singer Apple Computer/QuickTime --============_-1271499387==_============-- From rem-conf-request@es.net Fri Oct 22 16:47:18 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06056 for ; Fri, 22 Oct 1999 16:47:17 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11elUi-0000Xi-00; Fri, 22 Oct 1999 13:41:00 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11elUg-0000XY-00; Fri, 22 Oct 1999 13:40:58 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id E196A4CE47; Fri, 22 Oct 1999 16:40:57 -0400 (EDT) Received: from alyssa (alyssa [135.207.130.223]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id QAA21391; Fri, 22 Oct 1999 16:40:48 -0400 (EDT) Message-ID: <016301bf1ccd$dd063c30$df82cf87@research.att.com> From: "Baldine Paul" To: , , , "Gary Sullivan" , Cc: Subject: H.263 RFC 2429 Date: Fri, 22 Oct 1999 16:41:45 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01BF1CAC.53AA3700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0160_01BF1CAC.53AA3700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a comment regarding the packetization scheme described in=20 Section 5.1.2 of the RFC. It specifies that a redundant copy of the = picture header may be attached to the RTP header for packets that begin with = GBSC or SSC. What is not obvious is whether that redundant picture header is full = length (with UFEP=3D001) or not.=20 Although, it could be left to the implementer to decide whether to = include a complete picture header or not, I suggest, to be consistent with the recommendation of = Section 5.1.1, that all redundant picture headers(for packets beginning with a Picture Start = Code, a GBSC, a SSC or even a Follow-on packet), be complete, with UFEP=3D001. =20 Baldine-Brunel Paul AT&T Labs-Research Room 3-225, 100 Schultz Drive Red Bank, NJ 07701 phone: 732-345-3312 baldine@research.att.com http://www.research.att.com/info/baldine ------=_NextPart_000_0160_01BF1CAC.53AA3700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a comment regarding the = packetization scheme=20 described in
Section 5.1.2 of the RFC. It specifies = that a=20 redundant copy of the picture
header may be attached to the RTP = header for=20 packets that begin with GBSC or SSC.
What is not obvious is whether that = redundant=20 picture header is full length (with UFEP=3D001) or
not.
Although, it could be left to the = implementer to=20 decide whether to include a complete picture
header or not, I suggest, to be = consistent with the=20 recommendation of Section 5.1.1, that
all redundant picture headers(for = packets beginning=20 with a Picture Start Code,
a GBSC, a SSC or even a Follow-on=20 packet), be complete, with = UFEP=3D001.
 
Baldine-Brunel Paul
AT&T=20 Labs-Research
Room 3-225, 100 Schultz Drive
Red Bank, NJ = 07701
phone:=20 732-345-3312
baldine@research.att.com
= http://www.research.att= .com/info/baldine
 
------=_NextPart_000_0160_01BF1CAC.53AA3700-- From rem-conf-request@es.net Sat Oct 23 00:08:31 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17169 for ; Sat, 23 Oct 1999 00:08:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11erx8-0004NZ-00; Fri, 22 Oct 1999 20:34:46 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 11erx6-0004NJ-00; Fri, 22 Oct 1999 20:34:44 -0700 Received: from tis2.tis.toshiba.co.jp by inet-tsb.toshiba.co.jp (8.8.8/3.3W9-04/12/95) id MAA26702; Sat, 23 Oct 1999 12:34:40 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id MAA09690; Sat, 23 Oct 1999 12:34:40 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id MAA08400; Sat, 23 Oct 1999 12:34:39 +0900 (JST) Received: from pcg-c1r (kwa0112.mobile.toshiba.co.jp [133.120.199.28]) by mailhost.eel.rdc.toshiba.co.jp (8.6.12-KCONV/1.10) with SMTP id MAA20954; Sat, 23 Oct 1999 12:34:37 +0900 Message-ID: <01af01bf1d07$be70bfe0$1cc77885@pcg-c1r> From: "Yoshihiro Kikuchi" To: , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" Subject: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams Date: Sat, 23 Oct 1999 12:33:43 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Dear all, I submitted an Internet draft for the RTP payload format for MPEG-4 Audio/Visual streams: Title : RTP payload format for MPEG-4 Audio/Visual streams Author(s) : Yoshihiro Kikuchi, Toshiyuki Nomura, Shigeru Fukunaga, Yoshinori Matsui, Hideaki Kimata Filename : draft-jnb-mpeg4av-rtp-00.txt Pages : 14 Date : 22-Oct-99 This document describes RTP payload formats for the carriage of MPEG-4 Audio and Visual streams, and an RTCP format for MPEG-4 backward channel messages functionalities. The specification is based on the study on Internet draft for the carriage of MPEG-4 on IP, which is sent from ISO/IEC JTC1/SC29/WG11(MPEG) as a liaison statement. In this specification, MPEG-4 Audio/Visual bitstreams are directly mapped into RTP packets without using MPEG-4 Systems. The RTP header fields usage and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are specified. It also specifies an RTCP packet usage to carry the MPEG-4 backward channel messages. I attach this document. Review and comments by the experts are much appreciated. Best regards, Yoshihiro Kikuchi ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1308 From rem-conf-request@es.net Sat Oct 23 07:20:40 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00573 for ; Sat, 23 Oct 1999 07:20:40 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ez1Q-0000t4-00; Sat, 23 Oct 1999 04:07:40 -0700 Received: from cotton.ba.npic.edu.tw [203.64.120.46] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ez1K-0000so-00; Sat, 23 Oct 1999 04:07:36 -0700 From: The Bedrisers! To: relyea@msn.com Subject: Picture a BRAND NEW LOOK for every bedroom in your home! Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-Id: Date: Sat, 23 Oct 1999 04:07:36 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list BedRiser Blowout Special!! Click the following to enlarge page: http://www.bedriser.com
If you do not wish to receive any mailings from us, click HERE to be removed.

Breakthrough Decorating & Storage Product
Guaranteed To Make Your Bedroom Beautiful & Cozy

 


Discover The Benefits Of The BedRiser:
  • Ends back pain from bending to make the bed.
  • Creates tons of hidden storage.
  • New height turns your bed into the ultimate laundry table.
  • Back problems? BedRisers make it easy to get in and out of bed.
  • Get a better nights sleep. (We don't know why.)
  • Endless decorating possibilities.
  • Feel like a kid again sleeping in Grandma's old, high bed.
  • Very Sturdy.  Used in Nursing Homes.



A division of A-1 Machine & Tool
Since 1959
(800) 679-1956

24 Hours a Day
As seen here:
  • QVC
  • Better Homes
  • Martha Stewart
  • Southern Living
  • Country Living
  • Woman's Day
  • Family Circle
  • McCall's
  • Romantic Homes
  • The Home Show
  • Jan & Nans Column
  • Boston Globe
  • Chicago Sun Times

 

 

 

Turn Your Bed Into A Secret Storage Compartment!

 


Create Up To 63 Cubic Feet Of Extra Storage Under Your Bed!

  • Winter/Summer Clothes
  • Bicycle
  • Golf Bag
  • Arts & Crafts
  • Extra Blankets & Pillows
  • Christmas Decorations
  • Shoes
  • Pet Beds
  • Old Files


Ends Storage Problems For:
  • Apartments
  • Kids' Rooms
  • Condominiums
  • Mobile Homes
  • Small Homes
  • Older Homes with Small Closets
  • Cabins
  • College Dorm Rooms

 

 

 

Transform Your Ordinary Bed Into An Extraordinary Bed!!

 


  • 100% Satisfaction Guaranteed!
  • Guaranteed to attach to your standard angle iron bed frame or your money back!
  • Installs in minutes with only a cresent wrench!
  • No Drilling Required!
  • Patented Design!
  • Made of Industrial Steel!

Important!! Check the
installation instructions
to be sure that you
have the right kind of
bed frame.

PLEASE READ

Dear Customer:

Thank you for your recent interest in our BedRisers.  A set of BedRisers consists of six heavy duty steel legs and is available in two different lengths.  The set of six 12" or 15" legs will fit any size standard, angle iron, metal bed frame.

With the 12" BedRiser legs, your frame will be 12 inches from the floor.  Now measure your box springs and mattress, add 12 inches and that is how high your bed will be.  The same goes for the 15" BedRiser legs.  Don't forget to take into consideration how thick your quilt or bedspread is because if they're very thick, that will make the bed look even higher.

 
IMPORTANT:  The 15" BedRiser legs will make your bed very high.  Be sure to measure your box springs and mattress then add 15", that's how high your bed will be.

 

Testimonials

Dear BedRiser,
It worked just fine - nice and strong and steady - I looked for years for such a product.  Happy I found you in a magazine.
       Pamela

Dear BedRiser,
I love the BedRiser I purchased.  I am almost 6 feet tall with a bad back and its so much easier for me to get in and out of my bed now!  And it looks great with my new skirt.  The BedRiser creates a romantic look with little effort.  Thank you for being so clever.
       Sherri

Dear BedRiser,
The BedRiser is wonderful.  Besides the extra "closet" our room now looks special.
       A.J. Mason

Dear BedRiser,
Love my BedRiser, didn't cost a lot of money to give our bedroom a total new look.  Easy, too!
       Jan

 

All plain dust ruffles are very full and have a 200 thread count.

12" BedRiser & any color 18" bedskirt to fit any size bed.

15" BedRiser & any color 21" bedskirt to fit any size bed.
QTY

Select BedRiser

Select Bedskirt Color

 Select Size

 12" BedRiser
BR12NET
15" BedRiser
BR15NET

BONE

WHITE

NAVY

BRGUNDY

ROSE

H GREEN

Call NOW: (800) 679-1956

24 Hours a Day / 7 Days a Week!

SHIPPING INFORMATION We ship via UPS.  Parcel post is used only if necessary.  Sorry, no C.O.D's.  Please call (800) 679-1956 for orders to Hawaii, Alaska, Puerto Rico, or Canada.  Outside US orders please call (800) 679-1956 for ordering instructions and prices.  
$60.01 to $100.00...............$8.99
$100.01 to $300.00...........$11.99
$300.01+ Please call (800) 679-1956 to order.
ADDITIONAL SHIPPING INFORMATION  We make every effort to get your order to you without delay, however, BedRisers are very much in demand and sometimes we do have to backorder.  We also try to keep our bed ruffles and accessories in stock at all times, but they are also on back order on occasion.  We do not ship partial orders unless you request it, because the full amount of your purchase would have to be charged at the time of the first shipment.
PERSONAL CHECKS OR MONEY ORDERS  Personal checks are allowed to clear two weeks before we ship.  Money orders are shipped right away if the item is in stock.  We DO NOT ship orders C.O.D.
HOW TO ORDER  Submit this form or our Order Department will take your order at (800) 679-1956, 24 hours a day, 7 days a week including holidays.  Our Customer Service Department will be more than happy to answer any questions (no matter how lengthy) or help solve any problems that may arise.  We will help you in selecting a bed ruffle and matching accessories or mix and match too.  Our customer service hours are Monday - Friday, 8:00AM. to 4:30PM CST (800) 679-1956.
THE BEDRiser GUARANTEE  Everything you buy from BedRiser is 100% satisfaction guaranteed.  If you are not completely satisfied with a product, you may return it for a courteous and prompt exchange or refund.
RETURNS  To return items, complete the Return Form which was enclosed with your order and mail back to us within 30 days.  Your package must be insured.  Returned item(s) must be in good condition.  If you have lost your order form, just list your name, address, phone number and the date of your purchase.  It is the customer's responsibility to pay shipping on returned merchandise.  If the wrong goods were sent or the goods you ordered arrived damaged, please call us for a Return Merchandise Authorization for free return shipping.

From rem-conf-request@es.net Sat Oct 23 16:57:31 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08252 for ; Sat, 23 Oct 1999 16:57:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11f7Y1-0005kv-00; Sat, 23 Oct 1999 13:13:53 -0700 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11f7Xy-0005kl-00; Sat, 23 Oct 1999 13:13:51 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg-gw.lrg.ufsc.br [150.162.63.1]) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) with SMTP id RAA14214; Sat, 23 Oct 1999 17:40:29 -0200 (EDT) Message-Id: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Date: Sat, 23 Oct 1999 17:40:29 -0200 (EDT) From: "LANOMS'99" Reply-To: "LANOMS'99" Subject: IEEE LANOMS99 - Advanced Program and Registration Form To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg-gw.lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl Cc: lanoms99@lrg-gw.lrg.ufsc.br MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: pRcPs4bOpGVEvkmzIzNUtw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4m sparc X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id QAA08252 ************************************************************** * You are very welcome to participate in the * * * * IEEE LANOMS99 * * * * LATIN AMERICAN NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM * * * * http://www.lrg.ufsc.br/~lanoms99/ * * * * Rio Atlantica Hotel * * Rio de Janeiro - Brazil * * December 3-5, 1999 * ************************************************************** ***** IEEE LANOMS99 - TECHNICAL SESSIONS ***** SESSION 1 - SECURITY MANAGEMENT Auditorium#1 - Dec 03 - 08:30 - 10:00 1.1 - Access Control In Multicast Environments: An Approach to Senders Authentication Antonio F. Gomez Skarmeta, Angel L. Mateo Martinez and Pedro M. Ruiz Martinez Universidad de Murcia (Spain) 1.2 - A Large-scale System Authorization Scheme Proposal Integrating Java, CORBA and Web Security Models and a Discretionary Prototype Carla Merkle Westphall and Joni da Silva Fraga Universidade Federal de Santa Catarina (Brazil) 1.3 - Impact of Security Policies on the TMN-X Interface Integrity and Performance. Ognjen Prnjat and Lionel Sacks University College London (England) SESSION 2 - MULTI-AGENTS AND MOBILE AGENTS Auditorium#2 - Dec 03 - 08:30 - 10:00 2.1 - Multi-agent Advisory System. Cuesta P., Barreiro E., Gonzalez E., Carrion P., Laza R. and Corchado J. M. Universidad de Vigo (Spain) 2.2 - Traffic Management A Multi-Agent System Approach Paulo Monteiro and Luis Correio Alcatel Telecom (Portugal) 2.3 - Analyzing Mobile Agent Scalability in Network Management Marcelo Goncalves Rubistein and Otto Carlos Muniz Bandeira Duarte Universidade Federal do Rio de Janeiro (Brazil) SESSION 3 - TELECOMMUNICATION POLICIES AND SOLUTIONS FOR NETWORK MANAGEMENT Auditorium#1 - Dec 03 - 10:30 - 12:00 3.1 - Methodology for Specifying And Implementing a Management Solution Sergio Clementi and Tereza Cristina Melo de Brito Carvalho Universidade de São Paulo (Brazil) 3.2 - Experiences in the Developing of a Prototype Sytem for the Exchange of Management Information Study Case: Colombia Leonor Wilches-Chaux, Carlos E. Caciedo CINTEL (Colombia) 3.3 - The Foundations and Formation of Public Policies for Telecommunications Keith von Mecklenburg University of St. Andrews (Scothland) SESSION 4 - ARTIFICIAL INTELIGENCE SOLUTIONS FOR NETWORK MANAGEMENT Auditorium#2 - Dec 03 - 10:30 - 12:00 4.1 - Solving the Parallel Task Scheduling Problem by Means of a Genetic Approach Esquivel S.C., Gatica C.R. and Gallard R.H. Universidad Nacional de San Luis (Argentina) 4.2 - Enhanced Genetic Algorithms for the Cluster Allocation Problem in Distributed Systems Apolloni R., Molina S. and Gallard R.H. Universidad Nacional de San Luis (Argentina) 4.3 - Fault Diagnosis for Local Area Network Environments Volnys Bernal, Leliane N. de Barros, Marilza Lemos and Jacques Wainer Universidade de São Paulo / Universidade de Campinas (Brazil) SESSION 5 - ATM MANAGEMENT Auditorium#1 - Dec 03 - 14:30 - 15:30 5.1 - Measure-based Estimation of The Required Capacity on ATM Switches Using Neural Networks Miguel Franklin, Adriano Nascimento, Marcelino Pequeno and Mauro Oliveira Universidade Federal do Ceará / CEFET-CE (Brazil) 5.2 - Comparative Analisys of Multicast Routing Algorithms for Multimedia Communication over ATM Networks Frank Meylan, Luis Gustavo Gasparini Kiatake, Marcelo Zanoni Santos, Sergio Takeo Kofuji and Jean Pierre Courtiart LAAS-CNRS7 (France) / Universidade de São Paulo (Brazil) 5.3 - Service Level Management in ATM Networks Daniel Puka, Manoel Camillo Penna and Vinicius Prodocimo CEFET-PR / Visionnaire (Brazil) SESSION 6 - TELECOMMUNICATION INFORMATION MANAGEMENT Auditorium#2 - Dec 03 - 14:30 - 15:30 6.1 - Defining a Generic Information Model for Addresing New Service Offers in a Competitive Scenario Jean-Daniel Guedj, Giovanni Martini and Luca Valtriani Telecom Argentina (Argentina) / CSELT (Italy) 6.2 - A process-driven methodological approach for the design of telecommunication management systems Thierry Fraize, Julio Villena, Jean-Daniel Guedj Telecom Argentina (Argentina) 6.3 - Transmuting Legacy Network Management Environment into TMN-based INM Wang-Dong Woo, Hee-Sam Hwang and Byung-Nam Yoon Eletronics and Telecommunication Research Institute (Korea) SESSION 7 - TMN TECHNOLOGIES Auditorium#1 - Dec 04 - 08:30 - 10:00 7.1 - Configuration Management Integration For Telecommunications Networks: An Implementation Experiment Linnyer Beatrys Ruiz, Manoel Camillo Penna, Karlo Adriano Nocera, Mario Jose Ferreira, Celso Antonio Alver Kaestner and Joelson dos Passos PUC-PR (Brazil) 7.2 - Experiential Knowledge in TMN Alexandre Moraes Ramos and Joao Bosco da Mota Alves Universidade do Vale do Itajaí / Universidade Federal de Santa Catarina (Brazil) 7.3 - SMART-FO: TMN Maintenance Support System for Optical Fibre Network. Francesco Russano SIRTI (Italy) SESSION 8 - PROACTIVE AND PERFORMANCE MANAGEMENT Auditorium#2 - Dec 04 - 08:30 - 10:00 8.1 - SEGRE: An Expert System for Pro-active Computer Network Management Cecilia A. Castro Cesar and Celso de Renna e Souza Instituto Tecnológico de Aeronáutica (Brazil) 8.2 - Towards Proactive Network Load Management for Distributed Parallel Programming Sergio Nesmachnow, Antonio Lopez and Carlos Lopez Universidad de la República (Uruguay) 8.3 - Performance Monitoring of Telemanagement Systems Wagner Meira Jr, Patricia Aguiar, Jose Marcos Nogueira and Christiano Mata Machado Universidade Federal de Minas Gerais / Telemar Minas (Brazil) SESSION 9 - TRAFFIC MANAGEMENT Auditorium#1 - Dec 04 - 10:30 - 12:00 9.1 - An Efficient Low-Cost Traffic Management System for Large Switching Networks Ana Luiza Barros Diniz, Sergio Campos, Jose Marcos Nogueira, Christiano Mata Machado and Luiz Geraldo Souza Universidade Federal de Minas Gerais / Telemar Minas (Brazil) 9.2 - Traffic Simulation and the Location of Mobile Units in Wireless Communication Systems Mauro Nacif Rocha, Geraldo Robson Mateus and Soraia Lucia da Silva Universidade Federal de Minas Gerais (Brazil) 9.3 - Connection Admission Management for Self-Similar Traffic Nelson L. S. Fonseca, Gilberto S. Mayor and Cesar A. V. Neto Universidade de Campinas (Brazil) SESSION 10 - WEB-BASED MANAGEMENT AND INTERNET TECHNOLOGY Auditorium#2 - Dec 04 - 10:30 - 12:00 10.1 - WebManager: A Web-Based Network Management Application Jacques Philippe Sauve Universidade Federal da Paraíba (Brazil) 10.2 - Web Based Management in Lua Edison Ishikawa, Noemi Rodriguez IME / PUC-Rio (Brazil) 10.3 - Reporting the Experience of a Post-Graduate Program in Computer Network Operations, Internet Technology and Operating Systems' Support Manuel Lois Anido Universidade Federal do Rio de Janeiro (Brazil) SESSION 11 - QUALITY OF SERVICE AND NETWORK PROVISION OPERATION Auditorium#1 - Dec 04 - 14:00 - 15:30 11.1 - Resource Allocation and Quality of Service for Distributed Multimedia Applications Carlos de Castro Goulart and Jose Marcos Silva Nogueira Universidade Federal de Viçosa / Universidade Federal de Minas Gerais (Brazil) 11.2 - Algorithms and Contracts for Network and Systems Management Paulo Pereira and Paulo Pinto Universidade Técnica de Lisboa / Universidade Nova de Lisboa (Portugal) 11.3 - Work Force Management (WFM) Bruno Guido, Gavazzi Roberto, Fabio Malabocchia and Luisella Sisto CSELT (Italy) SESSION 12 - INTELLIGENT AGENT AND HIERARCHICAL MANAGEMENT SYSTEMS Auditorium#2 - Dec 04 - 14:00 - 15:30 12.1 - An Environment for Developing Neural Network-based Intelligent Agents Adriano Nascimento, Miguel Frankin and Mauro Oliveira Universidade Federal do Ceará / CEFET-CE (Brazil) 12.2 - Distributed Network Security Management Using Intelligent Agents K. Boudaoud and N. Agoulmine EURECOM Institute / PRISM Laboratory (France) 12.3 - Hierarchical Management Protocol for Large Networks Marcial Porto Fernandez, Gardel Moreira Delfino and Aloysio de Castro P. Pedroza Universidade Federal do Rio de Janeiro (Brazil) ***** IEEE LANOMS99 - PANELS ***** PANEL1 - TELECOMMUNICATIONS OPERATIONS AND MANAGEMENT IN LATIN AMERICA Auditorium#1 - Dec 03 - 16:00 - 18:00 PANEL2 - MOBILE TELECOMMUNICATIONS: TRENDS AND OPPORTUNITIES Auditorium#1 - Dec 04 - 16:00 - 18:00 ***** IEEE LANOMS99 - TUTORIALS ***** TUTORIAL 1.1 - The technological and Economic Effects of the Deregulation of the Global Telecommunications Industry upon the Application of the Principles of Network Management Auditorium#1 - Dec 05 - 09:00 - 12:30 TUTORIAL 1.2 - Neural Networks or Distributed Algorithms for Network Management Auditorium#2 - Dec 05 - 09:00 - 12:30 TUTORIAL 2.1 - New Global Solutions of Event Correlation based on Distributed infrastructure Auditorium#1 - Dec 05 - 14:00 - 17:30 TUTORIAL 2.2 - Network Management with SNMP: The Manager-Agent and Distributed Paradigms Auditorium#2 - Dec 05 - 14:00 - 17:30 ***** IEEE LANOMS99 - REGISTRATION FORM **** NAME: TITLE: ORGANIZATION: DEPARTMENT: ADDRESS: STATE: COUNTRY: TELEPHONE: FAX: Full or Technical Sessions IEEE Members Registration - Member Number: Full (Technical Sessions + 2 Tutorials) ( ) USD 499 on / before Nov. 26 or ( ) USD 559 after Nov. 26 Technical Sessions ( ) USD 290 Profissional or ( ) USD 190 Authors or ( ) USD 60 Students Full or Technical Sessions IEEE NON-Members Registration Full (Technical Sessions + 2 Tutorials) ( ) USD 499 on / before Nov. 26 or ( ) USD 559 after Nov. 26 Technical Sessions ( ) USD 350 Profissional or ( ) USD 190 Authors or ( ) USD 70 Students Number of tutorial to be Registrated IEEE Members ( ) USD 125 - 1 Tutorial or ( ) USD 225 - 2 Tutorials IEEE Non-Members ( ) USD 150 - 1 Tutorial or ( ) USD 250 - 2 Tutorials Tutorials (Mark your choices) ( ) Tutorial 1.1 or ( ) Tutorial 1.2 ( ) Tutorial 2.1 or ( ) Tutorial 2.1 Proceedings (IEEE Members / Non-members) ( ) USD 30 Total Registration: USD______ Total Tutorial: USD________ Total Proceedings: USD_______ Total Reminttance : USD_______ Method of Payment ( ) Method 1 - Money order in USD Payable to FEESC ( ) Method 2 - Check Brazilian Banks in R$ (exchange rate 1,9 R$/USD) For both methods make transfer to the following bank account: Bank Name: Banco do Brasil Bank Number: 001 Branch Number: 1453-2 Bank Account: 204.422.6 ( ) Method 3 - ( ) Visa or ( ) Mastercard Number: Expiration Date: Account Name: Authorized ( ) I authorize FEESC to deduct the amount inserted at TOTAL REMITTANCE from my credit card. SEND BY FAX OR BY EMAIL THE COMPLETED FORM WITH PAYMENT TO: Fundacao de Ensino e Engenharia de Santa Catarina (FEESC) Caixa Postal 5040 88040-970, Florianopolis (SC) Brazil Phone: +55.48.2334455 FAX: +55.48.3319677 EMAIL: katia@feesc.ufsc.br ***** IEEE LANOMS99 - COMMITTEE MEMBERS ***** General and TPC Chair: Carlos Becker Westphall, Brazil TPC Co-Chairs: Luiz Fernando Kormann, Brazil Mirela Sechi Moretti Annoni Notare, Brazil Publication Chair: Bernardo Goncalves Riso, Brazil Publicity Chair: Juan Carlos Miguez, Uruguay Finance Chair: Fernando Augusto da Silva Cruz, Brazil Joao Bosco Mangueira Sobral, Brazil Local Arrangements Chair: Michael Stanton, Brazil IEEE CNOM Chair: Veli Sahin, USA International Liasions: Africa: J. Roos, South Africa Asia: J. Hong, Korea Europe: E. Bagnasco, Italy N. America: S. Aidarous, USA Oceania: P. Ray, Australia Advisory Board: B. Meandzijas, USA D. Zuckerman, USA M. Ejiri, Japan M. Yoshida, Japan R. Saracco, Italy S. Goyal, USA V. Sahin, USA W. Zimmer, Germany Technical Program Committee Adarsh Sethi (USA) Alan Mckinlay (UK) Alejandro Miralles (Chile) Behcet Sarikaya (Japan) Carlos de Lara (Mexico) Carlos E. Caicedo (Colombia) Edward Pinnes (USA) Edmundo R. Madeira (Brazil) Elias Procopio Duarte Junior (Brazil) Gabriel Jakobson (USA) German Goldszmidt (USA) Guy Pujolle (France) Heinz-Gerd Hegering (Germany) Joberto S. Barbosa Martins (Brazil) Jong-Tae Park (Korea) Jose Marcos Nogueira (Brazil) Jose Neuman de Souza (Brazil) Keith-Stuart von Mecklenburg (UK) Leonor W. Chaux (Colombia) Manu Malek (USA) Manoel C. Penna (Brazil) Michael Bauer (Canada) Michelle Sibilla (France) Nelson Fonseca (Brazil) Osvaldo Bianchi (Argentina) Paulo Gomide Cohn (Brazil) Raul Monge (Chile) Robert Weihmayer (USA) Roberto Vercelli (Italy) Seraphin Calo (USA) Varoozh Harikian (Belgium) From mohwo@att.net Sun Oct 24 04:16:39 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06209 for ; Sun, 24 Oct 1999 04:16:38 -0400 (EDT) From: mohwo@att.net Received: from p153.amax3.dialup.lax1.flash.net (ns.bigbear.com) [209.30.74.153] by mail1.es.net with smtp (Exim 1.81 #2) id 11fIQK-0003nM-00; Sun, 24 Oct 1999 00:50:40 -0700 Subject: We need Home Workers! Date: Sun, 24 Oct 1999 02:44:35 Message-Id: <404.471353.77101@ns.bigbear.com> Dear Future Associate, You Can Work At Home & Set Your Own Hours. Start earning Big Money in a short time NO Newspaper Advertising! Your job will be to stuff and mail envelopes for our company. You will receive $.25 for each and every envelope you stuff and mail out. Just follow our simple instructions and you will be making money as easy as 1… 2… 3 For example stuff and mail 200 envelopes and you will receive $50.00. Stuff and mail 1000 and you will receive $250.00. Stuff and mail 2000 and you will receive $500.00 and more Never before has there been an easier way to make money from home! Our Company's Home Mailing Program is designed for people with little or no experience and provides simple, step by step instructions. There is no prior experience or special skills necessary on your part, Just stuffing envelopes. We need the help of honest and reliable home workers like you. Because we are overloaded with work and have more than our staff can handle. We have now expanded our mailing program and are expecting to reach millions more with our offers throughout the US and Canada. Our system of stuffing and mailing envelopes is very simple and easy to do! You will not be required to buy envelopes or postage stamps. We will gladly furnish all circulars at no cost to you. We assure you that as a participant in our program you will never have to mail anything objective or offensive. There are no quotas to meet, and there no contracts to sign. You can work as much, or as little as you want. Payment for each envelope you send out is Guaranteed! Here is what you will receive when you get your first Package. Inside you will find 100 envelopes, 100 labels and 100 sales letters ready to stuff and mail As soon as you are done with stuffing and mailing these first letters, your payment will arrive shortly, thereafter. All you have to do is to order more free supplies and stuff and mail more envelopes to make more money. Our sales literature which you will be stuffing and mailing will contain information outlining our highly informative manuals that we are advertising nationwide. As a free gift you will receive a special manual valued at $24.95, absolutely free, just for joining our Home Mailers Program. Plus you will get your own special code number, so that we will know how much you are to get paid. And to make re-ordering of more envelopes, that our company supplies very simple for you. We are giving you this free bonus because we want you to be confident in our company and to ensure that we will be doing business with you for a long time. Benefits Of This Job: 1. You do not have to quit your present job, to earn more money at home 2. You can make between $2,500 to $4,500 a month depending on the amount of time you are willing to spend stuffing and mailing envelopes 3. This is a great opportunity for the students, mothers, disabled persons or those who are home bodies. To secure your position and to show us that you are serious about earning extra income at home we require a one-time registration fee of $35.00. This fee covers the cost of your initial start up package, which includes 100 envelopes, 100 labels and 100 sales letters and a manual, your registration fee will be refunded back to you shortly thereafter. Money Back Guarantee! We guarantee that as soon as you stuff and mail your first 300 envelopes You will be paid $75.00 and your registration fee will be refunded. Many of you wonder why it is necessary to pay a deposit to get a job. It is because we are looking for people that seriously want to work from home. * If 3.000 people told us they wanted to start working from home and we sent out 3.000 packages free to every one. And then half of the people decided not to work, this would be a potential loss of more than $60,000 in supply's and shipping that we have sent out to people that don't want to work We have instituted this policy to make sure that you really want to work and at least finish your first package. To Get Started Today Please Enclose Your Registration Fee of $35 Check, Or Money Order and fill out the application below and mail to: MOHW Co PMB 11054 Ventura Blvd #126 Studio City, CA 91604 Name_____________________________________________________ Address___________________________________________________ City____________________________________ State______________ Zip Code________________ Telephone Number(s)_________________________________________ E-mail Address______________________________________________ For all orders, please allow seven (7) days for delivery and up to 10 days. Money Orders will result in faster shipping of your package. From rem-conf-request@es.net Sun Oct 24 04:26:38 1999 Received: from mail2.es.net (mail2.es.net [198.128.3.182]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06234 for ; Sun, 24 Oct 1999 04:26:37 -0400 (EDT) Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 11fIQV-00000v-00; Sun, 24 Oct 1999 00:50:51 -0700 Received: from p153.amax3.dialup.lax1.flash.net ([209.30.74.153] helo=ns.bigbear.com) by mail2.es.net with smtp (Exim 1.92 #1) id 11fIQO-0007nQ-00; Sun, 24 Oct 1999 00:50:45 -0700 From: Subject: We need Home Workers! Date: Sun, 24 Oct 1999 02:44:31 Message-Id: <663.820814.160372@ns.bigbear.com> To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Future Associate, You Can Work At Home & Set Your Own Hours. Start earning Big Money in a short time NO Newspaper Advertising! Your job will be to stuff and mail envelopes for our company. You will receive $.25 for each and every envelope you stuff and mail out. Just follow our simple instructions and you will be making money as easy as 1… 2… 3 For example stuff and mail 200 envelopes and you will receive $50.00. Stuff and mail 1000 and you will receive $250.00. Stuff and mail 2000 and you will receive $500.00 and more Never before has there been an easier way to make money from home! Our Company's Home Mailing Program is designed for people with little or no experience and provides simple, step by step instructions. There is no prior experience or special skills necessary on your part, Just stuffing envelopes. We need the help of honest and reliable home workers like you. Because we are overloaded with work and have more than our staff can handle. We have now expanded our mailing program and are expecting to reach millions more with our offers throughout the US and Canada. Our system of stuffing and mailing envelopes is very simple and easy to do! You will not be required to buy envelopes or postage stamps. We will gladly furnish all circulars at no cost to you. We assure you that as a participant in our program you will never have to mail anything objective or offensive. There are no quotas to meet, and there no contracts to sign. You can work as much, or as little as you want. Payment for each envelope you send out is Guaranteed! Here is what you will receive when you get your first Package. Inside you will find 100 envelopes, 100 labels and 100 sales letters ready to stuff and mail As soon as you are done with stuffing and mailing these first letters, your payment will arrive shortly, thereafter. All you have to do is to order more free supplies and stuff and mail more envelopes to make more money. Our sales literature which you will be stuffing and mailing will contain information outlining our highly informative manuals that we are advertising nationwide. As a free gift you will receive a special manual valued at $24.95, absolutely free, just for joining our Home Mailers Program. Plus you will get your own special code number, so that we will know how much you are to get paid. And to make re-ordering of more envelopes, that our company supplies very simple for you. We are giving you this free bonus because we want you to be confident in our company and to ensure that we will be doing business with you for a long time. Benefits Of This Job: 1. You do not have to quit your present job, to earn more money at home 2. You can make between $2,500 to $4,500 a month depending on the amount of time you are willing to spend stuffing and mailing envelopes 3. This is a great opportunity for the students, mothers, disabled persons or those who are home bodies. To secure your position and to show us that you are serious about earning extra income at home we require a one-time registration fee of $35.00. This fee covers the cost of your initial start up package, which includes 100 envelopes, 100 labels and 100 sales letters and a manual, your registration fee will be refunded back to you shortly thereafter. Money Back Guarantee! We guarantee that as soon as you stuff and mail your first 300 envelopes You will be paid $75.00 and your registration fee will be refunded. Many of you wonder why it is necessary to pay a deposit to get a job. It is because we are looking for people that seriously want to work from home. * If 3.000 people told us they wanted to start working from home and we sent out 3.000 packages free to every one. And then half of the people decided not to work, this would be a potential loss of more than $60,000 in supply's and shipping that we have sent out to people that don't want to work We have instituted this policy to make sure that you really want to work and at least finish your first package. To Get Started Today Please Enclose Your Registration Fee of $35 Check, Or Money Order and fill out the application below and mail to: MOHW Co PMB 11054 Ventura Blvd #126 Studio City, CA 91604 Name_____________________________________________________ Address___________________________________________________ City____________________________________ State______________ Zip Code________________ Telephone Number(s)_________________________________________ E-mail Address______________________________________________ For all orders, please allow seven (7) days for delivery and up to 10 days. Money Orders will result in faster shipping of your package. From rem-conf-request@es.net Sun Oct 24 20:34:17 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14477 for ; Sun, 24 Oct 1999 20:34:17 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11fXlJ-00047i-00; Sun, 24 Oct 1999 17:13:21 -0700 Received: from router.ti.itb.ac.id [167.205.9.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 11fXlF-00047Y-00; Sun, 24 Oct 1999 17:13:18 -0700 Received: from eglm90 (ip84.providence11.ri.pub-ip.psi.net [38.26.242.84]) by router.ti.itb.ac.id (8.8.5/8.8.5) with ESMTP id FAA00324; Mon, 25 Oct 1999 05:51:18 +0700 (JAVT) Message-Id: <199910242251.FAA00324@router.ti.itb.ac.id> From: "Jon" Subject: And What? To: misc93i@router.ti.itb.ac.id X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 24 Oct 1999 18:31:23 -0500 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA14477 FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E-Commerce, including a merchant account, real-time software and shopping cart. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * E-mail receipts * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 50 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS OFFER IS FOR U.S. BASED COMPANIES ONLY! PLEASE DO NOT REQUEST MORE INFORMATION IF YOU ARE LOCATED OUTSIDE OF THE UNITED STATES. Request our free E-mail information by replying to: mailto:qkl91@bigfoot.com?subject=INFO_PLEASE ***************************************************** Remove at mailto:p.deen@angelfire.com?subject=remove ***************************************************** From rem-conf-request@es.net Sun Oct 24 20:35:19 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14494 for ; Sun, 24 Oct 1999 20:35:19 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11fXgG-00045k-00; Sun, 24 Oct 1999 17:08:08 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 11fXgD-00045a-00; Sun, 24 Oct 1999 17:08:05 -0700 Received: from tis2.tis.toshiba.co.jp by inet-tsb.toshiba.co.jp (8.8.8/3.3W9-04/12/95) id JAA07062; Mon, 25 Oct 1999 09:08:00 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id JAA15981; Mon, 25 Oct 1999 09:07:59 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id JAA05064; Mon, 25 Oct 1999 09:07:58 +0900 (JST) Received: from ef63.eel.rdc.toshiba.co.jp (srg-75.eel.rdc.toshiba.co.jp [133.196.81.75]) by mailhost.eel.rdc.toshiba.co.jp (8.6.12-KCONV/1.10) with SMTP id JAA00629; Mon, 25 Oct 1999 09:07:57 +0900 Message-ID: <008a01bf1e7d$2d329c20$4b51c485@ef63.eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Yoshihiro Kikuchi" , , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams Date: Mon, 25 Oct 1999 09:09:15 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0087_01BF1EC8.9C84BAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0087_01BF1EC8.9C84BAE0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear all, I'm sorry, I forgot to attach the document. Regards, Yoshihiro -----Original Message----- From: Yoshihiro Kikuchi To: rem-conf@es.net ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Cc: Yoshihiro Kikuchi Date: Saturday, October 23, 1999 12:34 PM Subject: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams >Dear all, > >I submitted an Internet draft for the RTP payload format for MPEG-4 >Audio/Visual streams: > >Title : RTP payload format for MPEG-4 Audio/Visual streams >Author(s) : Yoshihiro Kikuchi, Toshiyuki Nomura, Shigeru Fukunaga, > Yoshinori Matsui, Hideaki Kimata >Filename : draft-jnb-mpeg4av-rtp-00.txt >Pages : 14 >Date : 22-Oct-99 > >This document describes RTP payload formats for the carriage of MPEG-4 >Audio and Visual streams, and an RTCP format for MPEG-4 backward channel >messages functionalities. The specification is based on the study on >Internet draft for the carriage of MPEG-4 on IP, which is sent from >ISO/IEC JTC1/SC29/WG11(MPEG) as a liaison statement. In this >specification, MPEG-4 Audio/Visual bitstreams are directly mapped into >RTP packets without using MPEG-4 Systems. The RTP header fields usage >and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are >specified. It also specifies an RTCP packet usage to carry the MPEG-4 >backward channel messages. > > > >I attach this document. Review and comments by the experts are much >appreciated. > >Best regards, >Yoshihiro Kikuchi > >---- > Yoshihiro Kikuchi > >E-mail: kiku@eel.rdc.toshiba.co.jp >Corporate Research and Development Center >TOSHIBA Corporation >TEL: +81 +44 549 2288 FAX: +81 +44 520 1308 > > > ------=_NextPart_000_0087_01BF1EC8.9C84BAE0 Content-Type: text/plain; name="draft-jnb-mpeg4av-rtp-00.txt" Content-Disposition: attachment; filename="draft-jnb-mpeg4av-rtp-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Yoshihiro Kikuchi - Toshiba Internet Draft Toshiyuki Nomura _ NEC Document: draft-jnb-mpeg4av-rtp-00.txt Shigeru Fukunaga _ Oki Yoshinori Matsui _ Matsushita Hideaki Kimata _ NTT October 22, 1999 RTP payload format for MPEG-4 Audio/Visual streams Status of this Memo This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes RTP payload formats for the carriage of = MPEG-4 Audio and Visual streams[2][3], and an RTCP format for MPEG-4 = backward channel messages functionalities[4]. It is based on the RTP/RTCP specification descried in the study on Internet draft for the = carriage of MPEG-4 on IP[5]. In this specification, MPEG-4 Audio/Visual = bitstreams are directly mapped into RTP packets without using MPEG-4 Systems[6]. = The RTP header fields usage and the fragmentation rule for MPEG-4 Visual = and Audio bitstreams are specified. It also specifies an RTCP packet = usage to carry the MPEG-4 backward channel messages. 1. Introduction 1.1 Why MPEG-4 Audio/Visual RTP format needed? The RTP payload formats described in this Internet-Draft specify the normative way on how MPEG-4 Audio/Visual streams are fragmented and =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D mapped directly onto RTP packets. No extra header field is used for = such functionality as error protection or grouping of streams. H.323 terminals could be the case. MPEG-4 Audio/Visual streams are = not managed by Object Descriptors[6] but H.245, and directly mapped into = RTP packets without Sync Layer[6]. The semantics of RTP headers in this = case need to be clearly defined including the association with the MPEG-4 Audio/Visual data elements. In addition, it would be beneficial to define the fragmentation rule of RTP packets for MPEG-4 Video streams = to enhance error resiliency by utilizing the error resilience tools = provided inside the MPEG-4 Video stream. However, they have not been studied until now. 1.2 Consideration on the MPEG-4 Visual RTP payload format Considering that MPEG-4 Visual is used on a wide variety of networks = from several Kbps to many Mbps, from guarantied networks with almost = error- free to mobile networks with high error rate, it is not desired to = apply too much restriction on the fragmentation like a single video packet shall always be mapped on a single RTP packet. On the other hand, a careless media unaware fragmentation will cause degradation of the = error resiliency and the bandwidth efficiency. The fragmentation rule = described in this document is flexible but to define the minimum rules to = prevent the meaningless fragmentation of e.g. splitting a header into = packets. For video coding media such as H.261 or MPEG-1/2, the additional = media specific RTP header works effectively for recovering e.g. a picture header corrupt by packet losses. However, there is an error = resilience functionality inside MPEG-4 Visual to recover corrupt headers. This functionality can commonly be used on RTP/IP network as well as other networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, there is no = strong reason to define MPEG-4 Visual specific extra RTP header fields. 1.3 Consideration on the MPEG-4 Audio RTP payload format MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. It also supports a mechanism representing synthesized sounds. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequence of the compressed or the represented audio data by MPEG-4 Audio tools with relatively small overhead. In audio-only applications, the LATM-based MPEG-4 Audio bitstreams, therefore, are desirable to be directly mapped into the = RTP packets without using MPEG-4 Systems. Furthermore, if the payload of a packet is a single audio frame, a = packet loss does not impair the decodability of adjacent packets. Therefore, = a payload specific header for MPEG-4 Audio is not required as same as = one for the other audio coders. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D 1.4 MPEG-4 Audio/Visual backward channel messaging on RTCP packets In some cases, MPEG-4 Audio/Visual has backward channel messaging functionalities. These messages are extremely Audio/Visual specific, since coders directly use these messages for controlling coding parameters. From the point of view of controlling parameters, these messages should be transmitted without delay. Therefore these = messages are directly mapped onto some kind of low delay RTCP packets. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. 3. RTP Packetization of MPEG-4 Visual bitstream This section specifies the RTP packetization rule for MPEG-4 Visual content. An MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or removal of any Visual syntax elements. The Combined Configuration/Elementary streams mode is used so that the configuration information is carried in the = same RTP port as the elementary stream. (see 6.2.1 "Start codes" of = ISO/IEC 14496-2 [2]) When the short video header mode is used, RTP payload format for = H.263 specified in the relevant RFCs or other standards MAY be used. 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=3D2|P|X| CC |M| PT | sequence number | = RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | = Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=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+ | contributing source (CSRC) identifiers | | .... | = +=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+ | | RTP | MPEG-4 Visual stream (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D 3.1 RTP header fields usage for MPEG-4 Visual Payload Type (PT): Distinct payload type should be assigned to = specify MPEG-4 Visual RTP payload format. If the dynamic payload type = assignment is used, it is specified by some out-of-band means (e.g. H.245, SDP, etc.) that the MPEG-4 Visual payload format is used for the = corresponding RTP packet. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Increment by one for each RTP data packet sent. It starts with a random initial value for security reasons. Marker (M) bit: The marker bit is set to one when the RTP packet = contains the configuration information (see 6.2.1 "Start codes" of ISO/IEC = 14496-2 [2]), Group_of_VideoObjectPlane(), and/or the first fragment of an = intra- coded VOP. Otherwise, set to zero. This bit is used to indicate that the RTP packet is a point for = random access, error-recovery using an intra-coded VOP, and recovering the configuration information. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder by adding a constant = random offset for security reasons. For a video object plane, it is defined = by vop_time_increment (in units of 1/vop_time_increment_resolution = seconds) plus the cumulative number of whole seconds specified by = module_time_base and time_code of Group_of_VideoObjectPlane() if present. In the case = of interlaced video, a VOP consists of lines from two fields and the timestamp indicates the composition time of the first field. If the = RTP packet contains only configuration information and/or Group_of_VideoObjectPlane(), the composition time of the subsequent = VOP in the coding order is used. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 3.2 Fragmentation of MPEG-4 Visual bitstream A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or removal of any =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. (1) A header of the configuration information function and Group_of_VideoObjectPlane() SHALL be placed at the beginning of the = RTP payload (just after the RTP header) or just after the header of the syntactically upper layer function. (2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Two or more VOPs SHALL be fragmented into different RTP packets = so that one RTP packet consists of the data bytes associated with an = unique presentation time (that indicated to the timestamp field in the RTP packet header). (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted such that the resulting RTP packet is not larger than the path-MTU. Here, header means the header of the configuration information = functions (VisualObjectSequence(), VisualObject(), VisualObjectLayer()) and the entry point functions for a elementary stream (Group_of_VideoObjectPlane(), VideoObjectPlane(), video_plane_with_short_header(), MeshObject(), FaceObject()), the = header of gob_layer(), and video_packet_header(). (see 6.2.1 "Start codes" = of ISO/IEC 14496-2 [2]) 3.3 Examples of packetized MPEG-4 Visual bitstream Considering that MPEG-4 Visual is used on a wide variety of networks = from several Kbps to many Mbps, from guarantied networks with almost = error- free to mobile networks with high error rate, it is not desired to = apply too much restriction on the fragmentation like a single video packet shall always be mapped on a single RTP packet. On the other hand, a careless media unaware fragmentation will cause degradation of the = error resiliency and the bandwidth efficiency. The fragmentation criteria described in 3.2 are flexible but to define the minimum rules to = prevent the meaningless fragmentation of e.g. splitting a header into = packets. For video coding media such as H.261 or MPEG-1/2, the additional = media specific RTP header works effectively for recovering e.g. a picture header corrupt by packet losses. However, there is an error = resilience functionality inside MPEG-4 Visual to recover corrupt headers. This functionality can commonly be used on RTP/IP network as well as other networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, there is no = strong reason to define MPEG-4 Visual specific extra RTP header fields. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D Figure 2 shows examples of RTP packets generated based on the = criteria described in 3.2 (a) is an example of the first RTP packet of an MPEG-4 visual object sequence. This packet contains the configuration information. = According to the criterion (1), the header of VisualObjectSequence(VS header) = is placed at the beginning of the RTP payload, and the headers of VisualObject and VisualObjectLayer(VO header, VOL header) follow it. (b) is an example the RTP packet that contains Group_of_VideoObjectPlane(GOV). Following the criterion (1), the GOV = is placed at the beginning of the RTP payload. It is a waste of = RTP/UDP/IP header overhead to generate a RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be = placed in the same RTP packet as shown in (b). (c) is an example that one video packet is packetized into one RTP packet. When the packet-loss rate of the underlying network is high, = this kind of packetization is recommended. It is strongly recommended to = set resync_marker_disable to 0 in the VOL header to enable adjustment of = the video packet size. Even when the RTP packet containing the VOP header = is discarded by a packet loss, the other RTP packets can be decoded by = using the HEC(Header Extension Code) information in the video packet = header. No extra RTP header field is necessary. (d) is an example that more than one video packets are packetized = into one RTP packet. This kind of packetization is effective to save the overhead of RTP/UDP/IP headers if the bit-rate of the underlying = network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The adequate number of video packets in a RTP packet and the RTP packet length depend the packet-loss rate and the bit-rate of the underlying network. Figure 3 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, like (a), will = not only increase the overhead of RTP/UDP/IP headers but also decrease = the error resiliency. Therefore, it is prohibited by the criterion (3). When concatenating more than one video packets into a RTP packet, VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization like (b) is not allowed by the = criterion (2). This is because of the error resiliency. Comparing this example = with Figure 2(c), two video packets are mapped onto two RTP packets in = both cases. However, there is a difference between the packet-loss = resiliency. When the second RTP packet is lost, both video packets 1 and 2 are = lost in the case of Figure 3(b) whereas only video packet 2 is lost in the case of Figure 2(c). A RTP packet containing more than one VOPs, like (c), is not allowed. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+-----+------------------+ (b) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (c) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (d) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ = +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video = Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) = | +------+------+----------+ = +------+---------+------+------------+ +------+------+------------------+------+------------------+ (c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane| |header|header| (1) |header| (2) | +------+------+------------------+------+------------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream 4. RTP Packetization of MPEG-4 Audio bitstream When tools defined in MPEG-4 Systems are not used MPEG-4 Audio stream = is formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) format[9], and then mapped onto RTP packets as described the = subsequent section. 4.1 RTP Packet Format =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D The LATM consists of the sequence of audioMuxElements that include = one or more audio frames. A complete audioMuxElement or the part of audioMuxElements SHALL be mapped directly onto the RTP payload = without removal of any audioMuxElement syntax elements as shown in Figure 4. = The first byte of each audioMuxElement SHALL be located at the first = payload location of an RTP packet. 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=3D2|P|X| CC |M| PT | sequence number = |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp = |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=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+ | contributing source (CSRC) identifiers | | .... | = +=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+ | |RTP : audioMuxElement (byte aligned) = :Payload | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - An RTP packet for MPEG-4 Audio It is required for the audioMuxElement to indicate the following information by an out-of-band means. dataTypePresentEnable: If this information is ON, audioMuxElement = SHALL include an indication bit "dataType". This bit indicates the data = type of audioMuxElement is whether "setupData" element or "payloadMux" = element. If this information is OFF, audioMuxElement contains the payloadMux element. errorProtectionEnable: This information indicates whether error protection is used. Furthermore, the length of the audioMuxElement in bytes SHALL be = required for the LATM-based audio decoder. This length MAY be equal with the length of the RTP payload. If the audioMuxElement is fragmented into several RTP packets, the cumulative length of all RTP packets MAY be used. 4.2 RTP Header Fields Usage Payload Type (PT): Distinct payload type should be assigned to = specify MPEG-4 Audio RTP payload format. If the dynamic payload type = assignment is used, it is specified by some out-of-band means (e.g. H.245, SDP, etc.) that the MPEG-4 Audio payload format is used for the = corresponding RTP packet. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = This bit is set to one to mark the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. Timestamps are = recommended to start at a random value for security reasons. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default. Sequence Number: Increment by one for each RTP packet sent. It starts with a random value for security reasons. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is desirable to put one audioMuxElement per RTP packet. The size = of an audioMuxElement is tried to be adjusted such that the resulting RTP packet is not larger than the path-MTU. If this is not possible, the audioMuxElement MAY be fragmented across several packets based on the following rules. (1) "payloadMux" which consists of payload elements MAY be fragmented into several RTP packets so that one RTP packet consists of one or = more payload elements. A payload element SHOULD NOT be fragmented. (2) If the audioMuxElement consists of the configuration information "setupData", the configuration information SHALL NOT be fragmented. 5. RTCP Packetization of MPEG-4 backward channel messages This section specifies the usage of particular RTCP packets to carry = the backward channel messages generated using the MPEG-4 Audio/Visual backward channel messaging functionalities, e.g. NEWPRED[4]. RTCP = packets specified in this section SHALL ONLY be used when it is indicated by = the profile and level indication of MPEG-4 the codecs have such functionalities. (e.g. Advanced Real Time Simple Visual Profile[4]) The MPEG-4 backward channel messages are transmitted on particular = RTCP packets, like H.261 RTCP control packets [10]. The MPEG-4 backward message packets differ from normal RTCP packets = in that they are not transmitted to the normal RTCP destination = transport address for the RTP session (which is often a multicast address). Instead, these backward packets are sent directly via unicast from = the decoder to the coder. The destination port for these control packets = is the same port that the coder uses as a source port for transmitting = RTP =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D (data) packets. Therefore, these packets may be considered "reverse" control packets. As a consequence, these control packets may only be used when no RTP mixers or translators intervene in the path from the coder to the decoder. If such intermediate systems do intervene, the address of the coder would no longer be present as the network-level source address in packets received by the decoder, and in fact, it might not be possible for the decoder to send packets directly to the coder. Some reliable multicast protocols use similar NACK control packets transmitted over the normal multicast distribution channel, however they typically use random delays to prevent a NACK implosion problem. The goal of such protocols is to provide reliable multicast packet delivery at the expense of delay, which is appropriate for applications such as a shared whiteboard. On the other hand, real-time Audio/Visual transmission is more = sensitive to delay and does not require full reliability. For Audio/Visual applications it is more effective to send the MPEG-4 backward message packets as soon as possible, i.e. as soon as a loss is detected, = without adding any random delays. 5.1. MPEG-4 Visual backward channel message packets definition 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=3D2|P| BMT | PT | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | = +=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+ | MPEG-4 Backward Channel Message Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding should only be required on the last individual packet because the compound packet is encrypted as a whole. backward channel message type (BMT): 5 bits Identifies the type of the MPEG-4 backward channel messages. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D 0: forbidden 1: MPEG-4 Visual NEWPRED 2-63: reserved In this internet-draft, only NEWPRED is assigned as the = candidate of the BMT for the moment. Some other MPEG-4 Audio/Visual = applications using the backward channel messages may be assigned in the = future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant for MPEG-4 backward channel messages. The assignment of = an RTCP payload type for this new packet format is outside the scope of this document, and will not be specified here. SSRC: 32 bits SSRC is the synchronization source identifier for the sender of this packet. MPEG-4 Backward Channel Message Payload: variable The syntax and semantics of the MPEG-4 backward channel messages = are defined in the ISO/IEC 14496-2/3[4][11]. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, = and several messages with same BMT could be continuously mapped onto = one RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. 6. Security Considerations RTP packets using the payload format defined in this specification = are subject to the security considerations discussed in the RTP = specification [8]. This implies that confidentiality of the media streams is = achieved by encryption. Because the data compression used with this payload = format is applied end-to-end, encryption may be performed on the compressed = data so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in = the receiver side computational complexity for packet processing to = cause a potential denial-of-service threat. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. 2 ISO/IEC 14496-2 FDIS, _Information technology _ Generic coding of audio-visual objects _ Part2: Visual_, October 1998. =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D 3 ISO/IEC 14496-3 FDIS, _Information technology _ Generic coding of audio-visual objects _ Part3: Audio_, October 1998. 4 ISO/IEC 14496-2 FPDAM 1, July 1999. 5 _Study on Internet draft for the carriage of MPEG-4 on IP_, ISO/IEC = JTC 1/SC 29/WG 11 N3021, October 1999. 6 ISO/IEC 14496-1 FDIS, _Information technology _ Generic coding of audio-visual objects _ Part1: Systems_, October 1998. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A = Transport Protocol for Real Time Applications", RFC 1889, Internet = Engineering Task Force, January 1996. 9 ISO/IEC JTC1/SC29/WG11/N2794, "Technical Description of the Low Overhead MPEG-4 Audio Transport Multiplex (LATM)", July 1999. 10 T. Turletti, C. Hitema, "RTP Payload Format for H.261 Video = Streams", RFC 2032, Octover 1996. 11 ISO/IEC 14496-3 FPDAM 1, July 1999. 8. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 210-8582, Japan Email: kiku@eel.rdc.toshiba.co.jp Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan Email: matsui@drl.mei.co.jp Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN Email: t-nomura@ccm.cl.nec.co.jp Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan Email: kimata@nttvdt.hil.ntt.co.jp Kikuchi/Nomura/Fukunaga/Kimata/Matsui =0CRTP payload format for MPEG-4 Audio/Visual streams October = 1999=0D Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Kikuchi/Nomura/Fukunaga/Kimata/Matsui =0C ------=_NextPart_000_0087_01BF1EC8.9C84BAE0-- From rem-conf-request@es.net Mon Oct 25 00:42:39 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18830 for ; Mon, 25 Oct 1999 00:42:39 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11fblf-0007I5-00; Sun, 24 Oct 1999 21:29:59 -0700 Received: from mta4.snfc21.pbi.net [206.13.28.142] by mail1.es.net with esmtp (Exim 1.81 #2) id 11fble-0007Hv-00; Sun, 24 Oct 1999 21:29:58 -0700 Received: from ieee.org ([63.195.83.6]) by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FK500AFW5R1H4@mta4.snfc21.pbi.net> for rem-conf@es.net; Sun, 24 Oct 1999 21:28:52 -0700 (PDT) Date: Sun, 24 Oct 1999 21:21:51 -0700 From: Willie LU Subject: 3Gwireless'2000 and wmATM'2000 To: cellular@comnets.rwth-aachen.de Cc: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg-gw.lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl Message-id: <3813DADE.5EF49F6F@ieee.org> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit *********************************** Sorry for Multiple copies of this mesage. *********************************** Dear Colleagues: The CFP for 3Gwireless'2000 and wmATM'2000 (the first and biggest global 3G Wireless technical conference, with 3rd workshop on wmATM) will be due on Nov. 19, 1999. For details, pls look at the web: http://www.itu.int/imt/5_mtgs/other_mtgs.htm, then go to "3G Wireless 2000". OR go to: 3gwireless.com/3g/3gwireless00. Thank you. Sincerely, Willie Lu General Chair From rem-conf-request@es.net Mon Oct 25 06:18:02 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02229 for ; Mon, 25 Oct 1999 06:18:02 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11fgp6-0003f5-00; Mon, 25 Oct 1999 02:53:52 -0700 Received: from promet1.deis.unibo.it [137.204.59.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11fgp3-0003ev-00; Mon, 25 Oct 1999 02:53:50 -0700 Received: from ghost.dsi.unimo.it (promet1.deis.unibo.it [137.204.59.1]) by promet1.deis.unibo.it (8.9.1a/8.9.1) with SMTP id KAA14670; Mon, 25 Oct 1999 10:10:14 +0200 (MET DST) Message-Id: <199910250810.KAA14670@promet1.deis.unibo.it> To: merani@dsi.unimo.it Cc: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg-gw.lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl From: mcasoni@deis.unibo.it Subject: Fwd: 3Gwireless'2000 and wmATM'2000 Date: Mon, 25 Oct 99 08:11:40 +0000 X-Mailer: Endymion MailMan v2.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Forwarded Message: > To: cellular@comnets.rwth-aachen.de > From: Willie LU > Subject: 3Gwireless'2000 and wmATM'2000 > Date: Sun, 24 Oct 1999 21:21:51 -0700 > ----- 
***********************************
Sorry for Multiple copies of this mesage.
***********************************

Dear Colleagues:

The CFP for 3Gwireless'2000 and wmATM'2000 (the first and biggest global 3G
Wireless technical conference, with 3rd workshop on wmATM) will be due on Nov.
19, 1999. For details, pls look at the web:
http://www.itu.int/imt/5_mtgs/other_mtgs.htm,then
go to "3G Wireless 2000". OR
go to: 3gwireless.com/3g/3gwireless00.

Thank you.

Sincerely,

Willie Lu
General Chair
From rem-conf-request@es.net Mon Oct 25 16:52:51 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05164 for ; Mon, 25 Oct 1999 16:52:50 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11fqc4-0002ep-00; Mon, 25 Oct 1999 13:21:04 -0700 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 11fqc3-0002dJ-00; Mon, 25 Oct 1999 13:21:03 -0700 Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-green.research.att.com (Postfix) with ESMTP id 72BBE1E002 for ; Mon, 25 Oct 1999 16:20:55 -0400 (EDT) Received: from research.att.com (descant [135.207.17.202]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id QAA18835 for ; Mon, 25 Oct 1999 16:21:03 -0400 (EDT) Sender: mathias@research.att.com Message-ID: <3814BB90.F28FA7F5@research.att.com> Date: Mon, 25 Oct 1999 16:20:32 -0400 From: Mathias Kretschmer Organization: AT&T Labs Research X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Updated draft: draft-ietf-avt-rtp-mpeg2aac-01.txt Content-Type: multipart/mixed; boundary="------------ACECC18AD8824C03CDA784CF" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------ACECC18AD8824C03CDA784CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The updated draft on the MPEG-2 AAC RTP payload format is available at: http://www.research.att.com/~mrc/draft-ietf-avt-rtp-mpeg2aac-01.txt Comments are welcome. -Mathias Mathias Kretschmer, AT&T Labs Research Room B285 180 Park Ave, Florham Park,NJ 07932 ph: (973) 360-8899 fax (973) 360-8455 mathias@research.att.com --------------ACECC18AD8824C03CDA784CF Content-Type: application/x-gzip; name="draft-ietf-avt-rtp-mpeg2aac-01.txt.gz" Content-Disposition: inline; filename="draft-ietf-avt-rtp-mpeg2aac-01.txt.gz" Content-Transfer-Encoding: base64 H4sICA7QEDgAA2RyYWZ0LWlldGYtYXZ0LXJ0cC1tcGVnMmFhYy0wMS50eHQA7Fxbc9u4kn4e 1P4IlB82dq1FW8rdlUmVJ1EmqRMnju3MZiqVmoJISGJMkTq82Nas97/v190ASMrK7cQP52GV kiOTRKPR6MvXjZZf5bUtc1vrcT5Lc2vLNJ/pM1Od6xdFGVvdvv5R2rqK5wtbDg7P/vNs7zdT VQV/VK/enI1P3ozP9POTwxdn+iuvZ+mFyTPjSLxrTHxu80lTzYXQizSzB0lppvUgtfV0YC7q QVkvB4ulnY2MiQf7w6i+qkHoNF8ljhP1tQn7r7dxXUxsqUejXT18/PjxDwwdXy3T0lYH+nBZ phlTGO3v7/8Aha+/lLpB6uTsWB+bVVaYhHZjYWo9LUp9dDz+fTDSh4fP9GldWrOoNowNr9Oz w7P3p/rtC3328tWpPhofvVXqbJ5WOiniZmHzWuOzyfUrpwmD5yR/XEnoRprraZNlOi7yKbGQ Qycu03quTZapZVlcpFVa5JUupvrUxjU+6+E+/Xby4tlof/QgUqpPGHOVIFGU56RpngcmUM9t 4OKGPirRx+1X47MXO7s6FUKm2hVO8aunOSuLZllFWr8paguiEFsB0qWSG3phVuC+KnSSVnWZ Tpp6Ez+mWpNI9YWlsLp2Bl6YLE14owymukoXzYIWV6VXelHk9bxSxDAxMbG6WSamtsmuLu0y MzF9wsBiUhWZxXU9WQnvXcZob1aqThcWa3xVyy6ZJTYDmmloyYVuqlaUA+25rTDN1JYWm6ig TRCuyWg+DIhTlpVduPkgtpwGbJFkSAtAfgb9r6ItUh+rMwiP1hU3ZUlKtC6aGOOxQBPHGISV mFrN63p5sLd3eXkZkXVHRTnbow97wzQZmAk2w8QQMwy8P8WaZp7OTVJc6ucwR5hzmdrvnqzi kdG8XmTYzK8YjX8dOqbWLSaxVQzNwcxGL52FTlsLxZi8WhZlTSrVmquC4IsE7GHPDbaI7sLG o65Fky1il2KapaqhKaYE6bJY6Fenb/dejZ8pmgBkaPCiyep0EGOrcptp0yRpwbQjzeyucZbm MRkMmMYOqyW53lpnRUVaUaVZSmpB4iY2hE+hGFajzaS48BY11XfAu/qCfxru0c+R/iNNbKG3 4QzgMe/v79zRH+9/Iq0GM0UJooZkpGhK0l8LkVlSZ2gkeYP+CiJ9CLPd5TsdqU5g/OwHw0Ir nRe1nmCFlxAf1KNYLDHRJHO+S1TckeBFKhkKr3FqL2wJs6hseZFCnTQ7uURskTwy2fzE5naa xmQ+rUfmVfS2uJUc5Fb2/BvWkiQp+Us40pWsiYy2mCqeJMuKy0qUCXeqVR7PyyJP/zbsYiH9 js501gQxZANyDUpEUrGe+1cbwiV67/lw3I3EexJaN5nDx2Mzs3r4Sf2Hj/gDF/G/O1S1MZjj rxpGJJKySBoOHmL4TtXD8OSC4k6iD1kfn4nyb4Pqjv44/KRrG8/zIitmKxhmlkLUlXr2fJCl 55a828TWkLkYS99W/tnAV9crcqlQRLJmRAg45wf31PlkWe25pyPysnNDljnN7BXrUat02Jva XIlVVM2StrsSix0qqPG9R24yRwwBq1mSxx0+wOOTy6KARw43OZj5+8ouJjYJ2uSfgdcngYa5 DBQgsVhBPmP7rcximZFVTUv7zwYKSSa1LRw90Ocv/ybqj/nTDs8H52mvsJiFzVZ9WmRbLJlI vAKedNNqBJwsjVkdK36e9oQngcFM4YZZtSF/NS8WHFoo4OiKBVytqtpCGcBICPgLOMRYT0qo UGzg+N0zkaiEWJzghOA513WMxeS2pbU9uJqsSeyB+Ps00sdi0cEhJvoLznDCN2FvncUykcys sJZpaRbgJHKEQflwkrJCYV2tyXadleOu6tosLcQ5usqTAq0jjKXw1gshXsFXGr4yALIaEzWz OSg9O3YULiLYyWKS5mvjab/XXEVXbBXHHsyQMBneTzacJXTe5snA7xy7aIyyAgKgBAVgD2EZ T4kJtJwd60V6BcskpEt3mMH8wkqQFHe5WlqYh63jKAxs/SLT4F3NDOTiFePcrgi9wctvHb0/ Pdvalf/1m7f8+WT87v2rk/Fz+nz68vD16/BBnlD45e371+4+fWpHPnt7dDR+81wGHx3+uSVY c+vt8dmrt28OX28RLqoRaVUABhQcIJgJKRf0elkyioPr8IghoTEcDofDx/rj3U/koIfRUL+9 oIBjL/u+XSmJxrSTErh97LdTCkDOujHG6HkKeUF7i6zhIDFNM7K4icnPdxVwSnEJlWkyoFAo EQ9hvwRFiu2SRuyGkDkwicElBHusIEnZNe+qzwUW5d2Q40NE8rKZTqGKnjdSjXieIpIyUwPn Z1WVzsgnUDguxUMQgs0pFDwKUd15efhGxuvw7hXJkG5PYW/ZSjkJeb+K5UCttiuL2VrQV+d1 1OTpgLil6Bsldg+e6TMw4x6lk3tKhu8tmwlse+8S2dyDaJlMdwg9WZ6WpAnlJ21PyPwd9hFs D65KW7g17Ypx1exXf0vrvUoCRi/MMAwpDYUPSMht8mt2JXfV9tZieXdrh2gMR48ckUj2n0Hh JCvic014N+eM4cIAvhMtctBe8iab4Yl6vqAgkXdAJ3CEOYemDPdH9yRCELRpIw+nFZrdwbbR d3iyOzukuWm+bGrOWUT7ZO+wI0hZ8AncCCZJq5Yl6HgFxwf2T4Q5CvGZh+mNQHSmF7gr9Awu ntdi2J8A/CL5x+8twIv0GHrlJeGRamCIniM2YqAnmkFvleaSXYviIc5+HReJFaS2xTB7YLIi t1u7ssMp3BB56KKh8CHYkHy/i28pFMCTFm4qB7mniHINfACjb7i2uAG6QlTFksn0QEnRqoMX d4tgeEjRZ+VDESIiZV4V5Cge3kp0IrP12D0prCDdhFMhTGOmU3zQMgWWZ1w8csm1ST4byiwc AQaHt4MJR7eLCUf6t4CvThlfibN3WIuEwMrdgWEp57fTgoEzYv2TcOupZ/XXp/oJtu0v2ra/ eNuedp9S6zdlyMcnNrPk3J9+eoJo8PTJ8eHzp0pdIoZa3R3vnYS46R53u/pJRu4XwMZ2HlQc JBbwsJK2Q9pQvCfvj4/HJ88OT8c9mngwJe8pj7Emf/yk2gegvoR2FwXYKmJJy2MbaWZaXAgP dRreZRY+IpEY0pcAT8LrlfHBvjObz4BfWnqUP8Vu5XVRg033yCaqEiCxg7T8GSVbeQOkW5Jj n6wIbCImiDeAY90gIw6zpPg3aTBoXdWcRDoeHFAI29glwriHHCdN7eDl2irFaWBhK+XLDHmw KNE3ECCNI1ia2b+cR/0rzEcvo+VuPxlQT/zDS5OW/RE6xBjd87Pbo5AJ7GA8QiSB/U2zGr2w dDmtODVeKxd0orB6kk2/wLewsbSc61p2L1XLPW+qqPiNYVvweSW7yC31hKtHeIjKiOlsXTR9 Nh1UYiAx72ZaX6/XUJAh3/YEuOfmIsJa2rlcmYy3fVuqKhJ1OKJ+Y7KwAz3dqp5ydGHzAzaW SgIFVVZHrwOqbw8ReUdkYByUpRKwZjACOO4DJVYwa8qglMujBFBdFk2G8IcUB+j6S2q4WdWi KPqCEm7UCXYmSsUFvAuyq9zDPYYGBEzKXZiNKx+XwH61+90z3t5QvUtrqgUfcOTTDpYm5Tm+ SPwlq+FqbFoNDNDyrDGufrqwJncIGXgQCbG+N8Ceq5SgeEV5IDH/Bemo9dfthMu7txkuR/CX VdVQGZRwhKya0pI1cvTkUJ9YWiE8bEA1tH/AD6T8ZRNzFlzzfC9gsQhS6lBXC4AZl38KXiM1 X6R1OhNUbMMGQtBMwEEMSdYVl2hI+AA0DSAc40pKkIrMocdcCl3wNDUZTVIsTIr04CXCJoGj dKo2GAYblUNDaeVTmYZKamwbKXIkMmiucmRVoSgdITiWu7yG/fy2jWYRTw8ZSEILCLpaTChX KU0136GbgLQIk4hSVLqP50VRMYw3CSNhkmkHKWrSjThlHeRUn4Pkut3/N9Uj6XAFDLuNec6J MFgJUYiANFS7NIg/cHFGUnqWYmdC4H1yRB0iLJsZYGbeSkghxU5jFs86g+tRWrIg/xQtaQJI am2+aR98dtCdHqowIW7XrVBxNMHGIEG1WeLR+snp+B3lCy0FzpqnTICxloMgdLpCmrjOrj4k UKR6frRDzcdu7VSgkzcsirxYzoscLFHtkAKiC+/Ov04suzmqPUDnIbLIJVc+QIfENpHMxkgI AZU2H2x9Jte96HiF4sPshjB5wzF09PCxZigTwQI7K3E8ijPEZDxqt7sgqS66eX1w0Pce3EBG Wv/OCsJ0etaDCFyTprj0BrYOly2uWBU5HigoLaEEcri/H3CnPCyyb1dXt6W2jtopZxfYVir8 cIXnxnZxkgSEFenfBQ+6WnlXTyQ6iqbTnlBZzuoPWqo8IBLDelJRQ4MAMeUjsJocrs+k2LzF AbgcX8ZU+oNDj01lpLq6ruYdm08pW1ukCAY+JBI5OteAr0gA1T/e++Ts1JeQuqSODv8kbsN5 A63LsgB4RZG6KR6fMnNVaUG49NKsKlfxJJ2VUilSSZ9oV7uKXThXaxm8imDcJUyJ+ekUzcOv AsGa8442C1cUSUYUHmaLAEtdJutjhpxLAsqloeCRQTa1M6u/gyzbHaNHMLEcPcoRVT0fHJ29 R3ybiqK4kx3Is6IqvCiajHYSmTqmyA7jEs8pD8OkzCp57xrvXDAU0IatbxOFCcETQ3oAE8w7 FLTzxJW2KRdTfSKCjyEPYYukY9x2jZWiPc0q2xLwDDuI4rKEMGJXk7VF+rSZVFzND8m77kQD 0113K9E5bJAgL8UKaCaYKeFKDQUxV+bQnxvEatIPcQ1Zkc/Y86+8QKGKeQ137e3nZHx8+Ork 9fiNgitueBuHo4ecsvEWUYqr3//26ux0LSFu5dLkjS/XKBf3p2kJPogHjwSYDnPp9njmexX4 bA9PDhAKZogOERvoetbZGxVKPpJFW3ekGrJV1Y5zG2yvvAmxwWPnRXASFk/Gp+OTP8bPXQhD YKUMrbxwVjttuAiEVUa3jRzv3SZy3N8wzXDDtdGGa3cxeog7d/U9fV8/0A/1I/1Y/8A19V+D n/ynrj9cB3Uknq5Z767D7lyzRzo5/P1o/Obsl19+uf72nF/N+jCDuv7GE996/XtQ+HnZUwy4 q489jA51xl7iEDzRsv+cO94Opwzw+EnmyjCdszjLvTJ70GWJ7hP8dpkmMFTJVuD9yJmPOUi2 k00suTFGWVwUk9QhlGrobMneYCnODE1Ip4QDvX8gcaZNEujq8IDpcc7Yzx8kCLwedK+C65Pu hR0iMTpgZ7tOgm7dPdDeiSh12IUygvLaRTGrMKGYjjZqwQxMyvs1LlAxS50tcH61G8a/Y5ah 953tFG61NJPC1Yu0aCq93V8rrb4V+Pbr/s3OVjW1ojUw25OCi3XfwdXoJlfeoRNLsfVgpuWh JVmUvenWVHgN0Amkb6EY+VruVnEplSCVNRpw6BIzS719/G5HX85TytaIbzmjaAH4ixa8qg6+ 4PTu+J0UKYtyZugcOXH5bn+yC+6CkjlUOJOhXGkBIImVY/nULwXTAsFd6iqSM1eHv21o4ZK5 71Tq+F0PG7YSddDjDlESGHhP/06ndAxCkATyaX5mzYUz5puQsJjWsOQeMJRzvo0QqkVOHHjV 8oa/kXJCD5ylAjhuPuvwpuoZRGdg2CesoOqZf9TFcKKOncpXtcHFiaI6TM8r5P1zPqnNPaJO m2I6dVMQs22i0qOcWlEKR1IxuHNrk1Om3FahnXL5VeWmQo3IVbBl7FFapZGN30Docuhw4m5J 5H1+eHbI/BCkU1xJqmpKBWV2aumC/hKkKUTcrr+gZB8IHQrq05nGNxcIFu7vrM+coqB4SmoL ic2osZOqotRw0utPoZLNJRWCfD4pT0e3h8vu325F774eSx3DEeHVn7pNkozUFTrYOV7qak4B FT+4KcNtZs+A9LaJomi544s1KaID1ssQ+qaKuXAYUdH9NpAa2LrWE7xjvBO8Ld5TvGd4z/FO 8f6M9zneGd4LvHO8C7yXt4JYruF+2/cQ7333/2jDe8P920BNZ32DWvMPJo5hLK1nScs1C47U yfbVjvdwX6hDkP9n7+48XMeCAG9+UogIVvrz9QR7dn4dY9cK2k7aSOwobx1tGnaPfi75Zxd2 /voT/xzsdT9PtgEk1q4s1q50f/7kupW6G4Xgv15X95saKpudli6Gqmnl8/u7I8IfD+4REHAp 5a42vbInlXrbULTeUyG17PZye+zZiZXCkpBvSw3GYwWCApsQy9/cSAPE4mq0K5//hri/GTS7 +T7wopwQyI1L/FhnY8giGD1iEKH1oWT4BKMmFlE1d9CB/BifTu5yXLSXoOFLH1zYmFgq2rVF 2T3le9dCCYlOePEmIOVswTETCn7U+Gg80lJpLvVlkjEXhWCbdCIAa9zX2y6CyTEAx6+d3pNw pYh8idreFOp2qLgdktVWSNzZ0ata3NAFe+ULu2mu7o5IyNzxFrXFmMCDK9KDXeLs8X3de/4P KtlUalZKMyZuk3hsFZulDWFDwjyVi1YCS/KiG+zTSjmMuWn+IK30C4vBcLtYwpO5tK0HI+QB Bzh9xcnzpZyqMwARK3CC89LEPfASrXEbaq2++Ye//NHuF32vY9of40/cWz3pFKiCIrParpak Nq3zPTn783jMHcOEcWd5qH/5IjdLpZ2MzxYUoadIPxMgTjVurrEbnTSCYrp1Ut9izucM3Fai XZuuSsORie9H4vrUWje5cZ3nxE1uL/3xFbdfijCMV/LQYuSq0h6IfQ1X1qwMijSBzrXItkgj AKHhL1JfjhPhMz/d0d1ue4xU0v7kMyHihJqa09IlZaGWzeuK6fCilVTEFDzncyoWiELbnF2n yziyLJ3JlzpCKxqUv5SvOriGDeV7+C7n4TxNWGIMfVso8sH/V/c6UGO9und88lz/MX529vZk kwRvvK71S6l13wIrnam3yf7TvLHJDkemD7/+ukmqfVZ+DvkI+mHP0qHJfrD7u5NT+L11MkMW x3cA+W+u4/oXvKJvSl7c/vc+TeHBPfvLV6Zeu/IvbOM6zR8Q4Rv9L4HIb67iR1//HhRuQZ37 om9p97egve5q+UdjcWK3shffpZ63+xh/eefndVn7stoNnf5Ruf68e9SqszkbJ/nW699EqX9W EMgS20BxsJ5jSfLF0HD9+DikRIr93xfLyZKdyRmkP0Sn7EW7I2s3PlSa5UnBrniKv/1b+arl xoIl8kgmcbMu7GiFgjphMibo6S2o7UtGuy+whtOBcO5+6r6+6RLRrCjOK81f1KPD4wM3/H+O 323XiK7032DoP4x2oij6X/fI2ZcX0GsJ819WlTTLVLUM7x7UrB02pOFkXQrubf4LmPfhoFWY P2QN46va5pKnbpCqW2hDX7u9/4A6DmuAErcIavK55zbqJaU41GssBzdt2kYMecxLOSShgIMg g9A6EyLVpjQiHNXvEzWZ3PdWSaWhVQ0jrTw326Q6PQlCYdq2rXJR2ycm1ItSIGmkr7L4NiTq mFpJsZ5pCAWfNXZSmlBPly+pcPtQpF/IiTr3MIS+jUqIVHPf4RTKmdJAR7muHkJphqOHu7TO LFz1abJQoC/cUHI4fDxkTO/P4XzCHB4fPh7xg6P7kjl7SbpEzx0UXS1tmTKXmV42JXX/VLdY an54m0lCQNgHTp+4jaI9gOmUD7oNJ66L1Pdf9Zqlg9X7g5uQXWOaX7lZLPz69PH9kGNzi59I NC829FR+f7lDiLiaR3d2bSmPoxLUw45dt+54kSaJHN1mwVWEJhL2LJv6bCL64x0EJVuzpCDc CrHf59RL/v3BJlk27UKg4EobsCXpzOnbeEfgqr18QG2Jj2jDXGuMfENJ6io3du95+EsBLmp0 0nDf/CMVEv/HQCj9XtDfJIBLW3Egk69Myvhu7xp9AdZ9UdhVwnx7sas7hCZjd6bGFKRbTUp9 fFDq63htF1pH6Hx06gouwZ/ur9dXuMGWGz/b1lFHANsWNm3IAdNF1v5h2I0ddK2xne8EMwn6 wh/WvTCIZlVTdrqXbpyugWLqT0qtjwbuSAAkSM7Uyp2Z/2vl6nrahqHou3+F31akpEoLG6VP gyJAfEyoBTQJ8WDSdCnQmNnJtvLrdz9sJ2kL06TyUq1rbMe+vvf6+pzzCnbBm5P/msNsVw1X ix9Use6RY+BjsDzBWpCVt4hkHHLFtsY1caXIhqu8NpnKu5YbjDad65udoUcHg4WEzVG06t4U mbjkhKaT/fZgy1qlQVdlAODbVPv6WENpg8k3tIYMdfDoYQcK7joBFPS5KdNE3ZzTUIyeodNn hGhNyBN1qtC8JaRu+J0auh7t96BIRbxX8HrzWUgZiIbH6NFs7WmXRUyXhVrMU8eut7kiyxRp DgGigIW+UuYZIQNXO7jIQznhWiq1inZlnjmNwbvp4JU6WM+HKC/8NzsNepwDjoqQo8jOd9f4 sQv/xBVoTxcVI8FAkLdSQhSWnZsJrPhuH3kT8iC5kKghEP43YA4Il+7EB5hK6qE3lIC6gO6x efTdGjzF55q8rljR14sF1iKdpA5Mma++0dTTbkOWcJ6t+Gbh96ofqGXog8dnF1O9cIlRo+Jn M8h66aJNTCbj0ZAK2hv4273B4EDe94m+PWJa/Qh+v2kbrVG/m88iZd950ZoaWwPfV57YXhIx 2GYSsYeyKTxvSOrHPW1chtYAtViPRs5XhV2ar0u7zF+kOS6FgW1fPT4RtdUhLnx3aas7pP+k lbsq8XYt2q3hxHNxHLNJvoJRlAPMGOuqmnARIh56MRWiIDCxnTYOOAOzfOXc5ChLVWXZl7Fc R82vY3BEjXdfFeax7IcQW1VM41LH8BE1WndqUcJpPrAmRdlmY7OIgw6JFOZQ+E7g3sqQJuEl G+LPEJbBM4Y22BILIocVyv7Zn3xO+UTRJtQUuogr+BeMhuv/Yu3CiwZXcabuSP8ongK/RqMK 9wg12FwLnkGUKih5IcAwCviI9Sx2ejwE3lN4FEOrG3s5KxLOQC0YLx3T2x30BvH+R9ox9Ej/ QU7SvHp5M/OigJPNSNkCr2RPIO2BLB6JFecqRUEuim6QYcFTN0Fb5NroUqeaZYDGGYwY3Y08 bIaVsIMjId/XN2O9PeytqJRZ4s76Qsoi97swRLAvo6Y0sosgeDHjg6VzEk5NhSHX8NyYz4wU JC7BYlF5xgtPRBJiDRzFoJN97mTvQV5nqIFmowtdwa+Vjc70FF47OlNmClkffBaQHC+jI/2i y+gu+6HiU2hlrvC9ThCuGV8rM7dgTE1PwjMzRSQ9jISXgc4N8NSq1J/7WbqM8QwBZh0nCeuB SRKOOkZCGElNRPIUMkCYSvTjkbzrylO9RLrwVTeIDIoPXVpbokp6iar/XaQBmuJnON5WZa6N /YS6TrQlLQZ02O7gzWuXLVCwUF6qRytjmBWb4TKI3iCBUUJ4P/wF0frkRZtcLeibSH47l8n+ wW5f3E4ORRYv1PxlCP6AGv5qXAtdVZZd2GEInoTelaTI8E5nScImX77JYwPbVcDqwAOF72w/ 6bU6e8S2NnS1tVh0sM1YdIVeIVe1EWxnElLX3IZ5wHaWSK0Yd2Xjtbe01Nb83NDnOR0VzrpO B3NLfT3lm0zq339b0hVLHsRf53Ci+I9UAAA= --------------ACECC18AD8824C03CDA784CF-- From rem-conf-request@es.net Mon Oct 25 20:08:35 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09539 for ; Mon, 25 Oct 1999 20:08:34 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ftxy-0005Xp-00; Mon, 25 Oct 1999 16:55:54 -0700 Received: from u-mail.rd.francetelecom.com [208.25.178.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ftxw-0005Xf-00; Mon, 25 Oct 1999 16:55:52 -0700 Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Mon, 25 Oct 1999 16:56:03 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F032B88@u-mail.rd.francetelecom.com> From: SIGNES Julien FTR&D/TD To: "'Yoshihiro Kikuchi'" , rem-conf@es.net, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams Date: Mon, 25 Oct 1999 16:55:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF1F44.7E2B9B8C" 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_01BF1F44.7E2B9B8C Content-Type: text/plain; charset="ISO-2022-JP" Hi, I am not an MPEG audio expert, but, could anybody tell me what is the right MPEG audio forum to inform them about our proposal to use MPEG-4 systems to compose ITU audio streams? :) Julien -----Original Message----- From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] Sent: Sunday, October 24, 1999 5:09 PM To: Yoshihiro Kikuchi; rem-conf@es.net; 4on2andIP-sys Subject: RE: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams Dear all, I'm sorry, I forgot to attach the document. Regards, Yoshihiro -----Original Message----- From: Yoshihiro Kikuchi To: rem-conf@es.net ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Cc: Yoshihiro Kikuchi Date: Saturday, October 23, 1999 12:34 PM Subject: Submission of I/D: RTP payload format for MPEG-4 Audio/Visual streams >Dear all, > >I submitted an Internet draft for the RTP payload format for MPEG-4 >Audio/Visual streams: > >Title : RTP payload format for MPEG-4 Audio/Visual streams >Author(s) : Yoshihiro Kikuchi, Toshiyuki Nomura, Shigeru Fukunaga, > Yoshinori Matsui, Hideaki Kimata >Filename : draft-jnb-mpeg4av-rtp-00.txt >Pages : 14 >Date : 22-Oct-99 > >This document describes RTP payload formats for the carriage of MPEG-4 >Audio and Visual streams, and an RTCP format for MPEG-4 backward channel >messages functionalities. The specification is based on the study on >Internet draft for the carriage of MPEG-4 on IP, which is sent from >ISO/IEC JTC1/SC29/WG11(MPEG) as a liaison statement. In this >specification, MPEG-4 Audio/Visual bitstreams are directly mapped into >RTP packets without using MPEG-4 Systems. The RTP header fields usage >and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are >specified. It also specifies an RTCP packet usage to carry the MPEG-4 >backward channel messages. > > > >I attach this document. Review and comments by the experts are much >appreciated. > >Best regards, >Yoshihiro Kikuchi > >---- > Yoshihiro Kikuchi > >E-mail: kiku@eel.rdc.toshiba.co.jp >Corporate Research and Development Center >TOSHIBA Corporation >TEL: +81 +44 549 2288 FAX: +81 +44 520 1308 > > > ------_=_NextPart_001_01BF1F44.7E2B9B8C Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: Submission of I/D: RTP payload format for MPEG-4 = Audio/Visual streams

Hi,

I am not an MPEG audio expert, but, could anybody = tell me what is the right MPEG audio forum to inform them about our = proposal to use MPEG-4 systems to compose ITU audio streams? = :)

Julien

-----Original Message-----
From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.c= o.jp]
Sent: Sunday, October 24, 1999 5:09 PM
To: Yoshihiro Kikuchi; rem-conf@es.net; = 4on2andIP-sys
Subject: RE: Submission of I/D: RTP payload format = for MPEG-4
Audio/Visual streams


Dear all,

I'm sorry, I forgot to attach the document.

Regards,
Yoshihiro

-----Original Message-----
From: Yoshihiro Kikuchi = <kiku@eel.rdc.toshiba.co.jp>
To: rem-conf@es.net <rem-conf@es.net>; = 4on2andIP-sys
<4on2andIP-sys@advent.ee.columbia.edu>
Cc: Yoshihiro Kikuchi = <kiku@eel.rdc.toshiba.co.jp>
Date: Saturday, October 23, 1999 12:34 PM
Subject: Submission of I/D: RTP payload format for = MPEG-4 Audio/Visual
streams


>Dear all,
>
>I submitted an Internet draft for the RTP = payload format for MPEG-4
>Audio/Visual streams:
>
>Title : RTP payload format for MPEG-4 = Audio/Visual streams
>Author(s) : Yoshihiro Kikuchi, Toshiyuki Nomura, = Shigeru Fukunaga,
>          = ;       Yoshinori Matsui, Hideaki = Kimata
>Filename : draft-jnb-mpeg4av-rtp-00.txt
>Pages : 14
>Date : 22-Oct-99
>
>This document describes RTP payload formats for = the carriage of MPEG-4
>Audio and Visual streams, and an RTCP format for = MPEG-4 backward
channel
>messages functionalities. The specification is = based on the study on
>Internet draft for the carriage of MPEG-4 on IP, = which is sent from
>ISO/IEC JTC1/SC29/WG11(MPEG) as a liaison = statement. In this
>specification, MPEG-4 Audio/Visual bitstreams = are directly mapped into
>RTP packets without using MPEG-4 Systems. The = RTP header fields usage
>and the fragmentation rule for MPEG-4 Visual and = Audio bitstreams are
>specified. It also specifies an RTCP packet = usage to carry the MPEG-4
>backward channel messages.
>
>
>
>I attach this document. Review and comments by = the experts are much
>appreciated.
>
>Best regards,
>Yoshihiro Kikuchi
>
>----
>        = Yoshihiro Kikuchi
>
>E-mail: kiku@eel.rdc.toshiba.co.jp
>Corporate Research and Development Center
>TOSHIBA Corporation
>TEL: +81 +44 549 2288    FAX: +81 = +44 520 1308
>
>
>

------_=_NextPart_001_01BF1F44.7E2B9B8C-- From rem-conf-request@es.net Tue Oct 26 07:53:41 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02709 for ; Tue, 26 Oct 1999 07:53:40 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11g4kc-0003m2-00; Tue, 26 Oct 1999 04:26:50 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11g4ka-0003lq-00; Tue, 26 Oct 1999 04:26:48 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01833; Tue, 26 Oct 1999 07:26:40 -0400 (EDT) Message-Id: <199910261126.HAA01833@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-00.txt Date: Tue, 26 Oct 1999 07:26:40 -0400 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 bits, 20bits and 24 bits DV Audio Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-audio-00.txt Pages : 10 Date : 25-Oct-99 This document specifies the packetization scheme for encapsulating the 12 bits nonlinear, 20 bits linear and 24 bits linear audio data streams into a payload of the Real-Time Transport Protocol (RTP). This Internet draft is a revised draft we submitted name as 'draft- kobayashi-dv-audio12-00.txt'. Changing the title is due to the draft incorporating 20 bits and 24 bits audio mode in addition to 12 bits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-audio-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-audio-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-audio-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025150439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-audio-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-audio-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025150439.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Oct 26 10:26:58 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07854 for ; Tue, 26 Oct 1999 10:26:57 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11g7Ja-0005rc-00; Tue, 26 Oct 1999 07:11:06 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11g7JY-0005rS-00; Tue, 26 Oct 1999 07:11:04 -0700 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 26 Oct 1999 09:10:14 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256816.004DB18A ; Tue, 26 Oct 1999 10:08:37 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Stephen Casner cc: rem-conf@es.net Message-ID: <85256816.004DB149.00@notes4.nmss.com> Date: Tue, 26 Oct 1999 10:11:32 -0400 Subject: Re: inband dtmf 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 Thank you for asking. The latest version does seem to be an improvement. I especially like the end or 'E' bit. I still have some concerns and questions though, to wit: Paragraph 2 of section 3.1 (Intro to RTP Payload Format for Named Telephone Events): states that "DTMF digits ... SHOULD use the same sequence number and time-stamp base as the regular audio channel". It strikes me that a receiver might use VERY different strategies for processing these events depending on whether the sequence number is the same as the regular audio or not. This basic fact would need to somehow be negotiated by out of band means. I think this is too much wiggle room and would argue for MUST instead of SHOULD. Alternatively, some discussion of how SDP or other techniques could be used to negotiate or declare this should be inserted. If, for example, one is not taking advantage of redundancy then detecting a missing DTMF packet which is isolated or in the beginning of a sequence is impossible if the same sequence number as the regular audio channel is not used because you don't know when to expect it (of course you know when the next one arrives with the sequence number bumped up by two but that is too late). If this concern is correct, then I think it merits at the very least a cautionary statement in the document. There are also some issues related to compound packets and jitter buffers raised by having a different sequence of sequence numbers/timestamps. One might need to maintain two parallel buffers. In section 3.5 on the 'E' bit is the sentence: "A sender MAY set the end bit only when retransmitting the last packet for a tone. This avoids having to wait to detect whether the tone has indeed ended." The second sentence seems to suggest that the authors meant to say MUST instead of MAY, and that the emphasis is on last and not retransmit. The sentence is sort of ambiguous. In any case, it seems to me most useful to set the E bit for each of the transmissions and retransmissions of the last packet for a tone. This affords maximum protection for detecting the end in the event of packet loss. Avoiding the wait would best be acheived by setting the end bit on the first transmission of the last packet, not the retransmission (If I'm following this correctly.) (There is also some kind of typo in the first sentence of the 2nd paragraph for the 'E' bit where it says: "Receiver implementations MAY use at different ....") In the example in section 3.8, I believe the E bit has been left out and two R bits are still shown. Translating between milliseconds and timestamp units is helpful, it would be more helpful still to point out things like 4800 = 11200 - 6400 right in the timestamp offset field for the second digit. From rem-conf-request@es.net Tue Oct 26 13:19:57 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15010 for ; Tue, 26 Oct 1999 13:19:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11g9uF-0000GV-00; Tue, 26 Oct 1999 09:57:07 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11g9uF-0000GL-00; Tue, 26 Oct 1999 09:57:07 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id JAA21288; Tue, 26 Oct 1999 09:49:38 -0700 (PDT) Message-Id: <3.0.3.32.19991026094936.00b61c20@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 26 Oct 1999 09:49:36 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/27 Supporting Multicast Services in the Emerging Internet2 Network Infrastructure The View from Minus Six Feet -- Ken Lindahl, Communication and Network Services U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Supporting Multicast Services in the Emerging Internet2 Network Infrastructure The View from Minus Six Feet Wednesday October 27, 1999, 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Ken Lindahl Communication and Network Services U.C. Berkeley IP multicast is recognized by the Internet2 Project to be an important technology for the delivery of education and other services in future advanced communication infrastructure. The I2 Multicast Working Group was created to encourage the deployment of "a consistent and ubiquitous multicast service within the Internet2 community." In this talk, I will describe the current state of multicast routing in the high-performance "next generation" backbones, vBNS and Abilene; in California's advanced educational network, CalREN-2, and in the UC Berkeley campus network. I'll mention some successes and difficulties encountered in trying to deploy and support multicast service, as well as our attempts to implement the recommendations and results of activies in the I2 Multicast Working Group and the IETF MBONE Deployment (mboned) Working Group. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf-request@es.net Tue Oct 26 15:20:04 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21212 for ; Tue, 26 Oct 1999 15:20:03 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gBtY-0001wU-00; Tue, 26 Oct 1999 12:04:32 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gBtW-0001wK-00; Tue, 26 Oct 1999 12:04:31 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA01106; Tue, 26 Oct 1999 15:04:27 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA26519; Tue, 26 Oct 1999 15:04:26 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3815FB27.9FCFC603@cs.columbia.edu> Date: Tue, 26 Oct 1999 15:04:07 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Levens@nmss.com CC: Stephen Casner , rem-conf@es.net Subject: Re: inband dtmf References: <85256816.004DB149.00@notes4.nmss.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Bruce_Levens@nmss.com wrote: > > Paragraph 2 of section 3.1 (Intro to RTP Payload Format for Named Telephone > Events): > states that "DTMF digits ... SHOULD use the same sequence number and > time-stamp base as the regular audio channel". > It strikes me that a receiver might use VERY different strategies for > processing these events depending on whether the sequence number is > the same as the regular audio or not. This basic fact would need to > somehow be negotiated by out of band means. I think this is too much > wiggle > room and would argue for MUST instead of SHOULD. Given that nobody has indicated a valid reason why one should use a different timestamp base (and that switching encoders, say, between G.711 and G.723.1 wouldn't change the sequence number either), I'd agree that requiring this simplifies life. Changed, unless I hear a counter-argument. > > In section 3.5 on the 'E' bit is the sentence: > "A sender MAY set the end bit only when retransmitting the last packet for > a tone. This avoids having to wait to detect whether the tone has indeed > ended." I've reworded the sentence to "A sender {\MAY} delay setting the end bit until retransmitting the last packet for a tone, rather than on its first transmission. This avoids having to wait to detect whether the tone has indeed ended." > In any case, it seems to me most useful to set the E bit for each of the > transmissions and retransmissions of the last packet for a tone. This > affords maximum protection for detecting the end in the event of packet > loss. Avoiding the wait would best be acheived by setting the end bit on > the first transmission of the last packet, not the retransmission (If I'm > following this correctly.) Yes, from a receiver perspective. But a sender wouldn't necessarily know whether the tone has ended when it sends the packet, as it would have to look into the future for that. It is rather unlikely that the tone will end just after the packet interval, but it could conceivably happen. The problem would not exist if tones were truly continuous, but since the detector has to "bridge" short gaps, it can't decide whether the short gap at the end of the interval is indeed just a spike and should be ignored or the end of the tone was reached. In ASCII art: | transmission point xxxxx | xxxx - tone with small gap xxxxx | end of tone > In the example in section 3.8, I believe the E bit has been left out and > two R bits are still shown. Forgot to correct the example; fixed. > Translating between milliseconds and timestamp units is helpful, it would > be more helpful still to point out things like 4800 = 11200 - 6400 right > in the > timestamp offset field for the second digit. I added the calculation in the figure. Thanks for your comments. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Tue Oct 26 15:30:24 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21791 for ; Tue, 26 Oct 1999 15:30:23 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gC79-0002Vz-00; Tue, 26 Oct 1999 12:18:35 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gC77-0002Vn-00; Tue, 26 Oct 1999 12:18:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21122; Tue, 26 Oct 1999 15:18:31 -0400 (EDT) Message-Id: <199910261918.PAA21122@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-00.txt Date: Tue, 26 Oct 1999 15:18:30 -0400 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 bits, 20bits and 24 bits DV Audio Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-audio-00.txt Pages : 10 Date : 25-Oct-99 This document specifies the packetization scheme for encapsulating the 12 bits nonlinear, 20 bits linear and 24 bits linear audio data streams into a payload of the Real-Time Transport Protocol (RTP). This Internet draft is a revised draft we submitted name as 'draft- kobayashi-dv-audio12-00.txt'. Changing the title is due to the draft incorporating 20 bits and 24 bits audio mode in addition to 12 bits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-audio-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-audio-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-audio-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025150439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-audio-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-audio-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025150439.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Oct 27 01:44:13 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24583 for ; Wed, 27 Oct 1999 01:44:12 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gLRT-00009o-00; Tue, 26 Oct 1999 22:16:11 -0700 Received: from dialin-13.nyc.bestweb.net (surfree.com) [216.179.5.13] by mail1.es.net with smtp (Exim 1.81 #2) id 11gLRC-000092-00; Tue, 26 Oct 1999 22:15:58 -0700 Date: Wed, 27 Oct 1999 01:14:13 -0400 From: "Tempting Tear-Outs" Message-ID: To: =?ISO-8859-1?Q?=9D=A1?= Subject: FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices! 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 Content-Transfer-Encoding: 7bit ===>> FREE* 1 yr USA Magazine Sub sent worldwide-200+ Choices! Up to $81.00 value! (*with your first purchase of any size of any new or renewal subscription; customers living overseas pay only for FPH (foreign postage & handling) on the free subscription). To be removed from our mailing list, please see instructions at the end of this message. FOR MORE INFO: please "cut out" the below form on the "cut" lines shown, and fax it, for the fastest reply to either our USA or United Kingdom fax numbers: 1-602-294-5643 (fax # in the USA) OR FAX US AT 44-7050-696528 (fax # in the United Kingdom) 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 SORRY, BUT.... our software is not set up to accept the below form via return email; WE CAN ONLY acknowledge forms sent in via fax or smail. --> IMPORTANT complete directions, to ensure that you get a reply, and more info follow, below the reply form and the catalogue options. *------------cut here/begin-------------------------------------------* Name (First Middle Last): Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Cellular (Mobile) Tel. #: Beeper (Pager) Tel. #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 102699-em-l Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY: 1. no reply forms can be accepted by email....only via fax or smail. 2. your form must be typewritten or printed out on your computer printer before you fax it; sorry, but *no* handwritten forms will be acknowledged. If you can't find someone with a typewriter or a computer printer, we apologize for not being able to reply to you. 3. forms not *completely* filled in will not be acknowledged. 6. you will receive a reply within 1 business day directly from the company making the offer via email. Therefore you must have an email address. If you read this message, then you must have an email address, or access to one, at least. :-) 7. your fax must not exceed 2 pages in length (*including* cover page); your first page may be a cover page, but your reply form must appear on next page if you include a cover page. Faxes of 2 or more pages will be detected, then auto-terminated and deleted. Your fax goes directly onto our 10.0 gigabyte hard drive and we must limit all incoming faxes to 1 page. 8. all faxes must begin with: *------------cut here/begin-------------------------------------------* and must end with: *------------cut here/end--------------------------------------------* 9. Any fax not conforming to this format will be sensed by our software, then auto-terminated and deleted from the hard drive, before any human ever gets to see it. 10. The type on your fax must be dark and legible. If in doubt, please print it out darker before faxing it in. If we can't read it, we can't reply to you or send you our FREE catalogue. :-( 11. If this all seems too complicated for faxing, just do it the old fashioned way via smail!!! WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER 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 $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,100+ titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas customers. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new customers who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the two formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa, American Express, Diner's Club and Carte Blanche. Overseas, they accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche, even if your credit card is a local one in local currency (that most merchants in the USA would not normally be willing to accept). That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on marketing & consulting rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828, USA. This email message has been sent to you by: Tempting Tear-Outs, PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828, USA.. TO BE REMOVED FROM OUR MAILING LIST: There are 4 easy methods to let us know that you would like to be removed from our mailing list (please use whichever way is most convenient for you; if you are unable to reach us via your chosen method, please try another of the methods below, in order that we can remove you from our mailing list): 1. email us at our "from" email address at the top of this message, with a subject of "remove" and a blank body OR 2. fax us a 1-line message at: 1-435-302-5907* ; the 1-line message should say: "Remove ________@_________ (your email address)" OR 3. leave us a 1-sentence voicemail message at: 1-435-302-5907* ; the 1-sentence message should say: "Remove ________@_________ (your email address)"; please speak clearly and spell out your email address phonetically OR 4. mail us a 1-line message at: Tempting Tear-Outs, PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828; the 1-line message should say: "Remove ________@_________ (your email address)." *Please note: 1-435-302-5907 is ONLY for remove requests. Requests for more information forms sent to 1-435-302-5907 CANNOT be acknowledged. For more information, please use the fax numbers listed earlier above the reply form, following the directions very carefully. From rem-conf-request@es.net Wed Oct 27 03:55:31 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03474 for ; Wed, 27 Oct 1999 03:55:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gNl9-0001ic-00; Wed, 27 Oct 1999 00:44:39 -0700 Received: from tyo203.gate.nec.co.jp [202.32.8.211] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gNl7-0001iS-00; Wed, 27 Oct 1999 00:44:37 -0700 Received: from mailsv.nec.co.jp ([192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.3/3.7W99100611) with ESMTP id QAA21571 for ; Wed, 27 Oct 1999 16:44:33 +0900 (JST) Received: from dcdmail.dcd.abk.nec.co.jp (dcdmail.dcd.abk.nec.co.jp [10.42.124.102]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id QAA19940 for ; Wed, 27 Oct 1999 16:44:32 +0900 (JST) Received: from trds166.holontech.dcd.abk.nec.co.jp by dcdmail.dcd.abk.nec.co.jp (8.8.8+2.7Wbeta7/3.6W05/29/98) id QAA24844 for ; Wed, 27 Oct 1999 16:44:31 +0900 (JST) Received: from seeyes.co.in ([192.168.4.241]) by trds166.holontech.dcd.abk.nec.co.jp (5.x/3.6W) id AA15244; Wed, 27 Oct 1999 16:48:36 +0900 Message-Id: <3816ADC0.D299E30F@seeyes.co.in> Date: Wed, 27 Oct 1999 16:46:08 +0900 From: Murthy Nanduri X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: rem-conf@es.net Subject: Padding in RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hi, I am working on the implementation of RFC2508.i.e., the RTP/UDP/IP Header compression and decompression. I have tested my implementation, with an equipment which sends the RTP packets with the Marker bit and Padding bits NOT set. The implementation is working fine and I could able to hear the voice properly between the two machines. When I started testing the CRTP implementation with another equipment which sends the RTP packets with the Marker bit and Padding bits SET(for some packets of stream), I am unable to hear the voice between the two machines. As per the RFC2508, I am setting the Bitmask for the Marker bit while sending the compressed RTP packet. When the padding bit is set, I am sending the compressed UDP packet.. Can you please let me know what has to be done by CRTP with the padding bytes? I want to know whether the padding bytes have to be removed by CRTP compressor/decompressor OR it is the responsibility of the RTP applications to ignore the padding bytes.. I think it is the responsibility of the Voice applications to take care of the padding bytes.. Am I right? can U please let me know what for the Marker bit and Padding bits are used? Murthy NVN From rem-conf-request@es.net Wed Oct 27 07:07:23 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05094 for ; Wed, 27 Oct 1999 07:07:23 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gQio-0003lR-00; Wed, 27 Oct 1999 03:54:26 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11gQim-0003lH-00; Wed, 27 Oct 1999 03:54:25 -0700 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 27 Oct 1999 11:54:05 +0100 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id LAA02260; Wed, 27 Oct 1999 11:51:38 +0100 Message-Id: <199910271051.LAA02260@cperkins-d.cs.ucl.ac.uk> To: Stephen Casner cc: Jonathan Rosenberg , rem-conf@es.net Subject: Re: RTP spec questions In-Reply-To: Message from Stephen Casner of "Thu, 21 Oct 1999 21:52:23 PDT." Date: Wed, 27 Oct 1999 11:51:38 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephen Casner writes: >On Fri, 22 Oct 1999, Jonathan Rosenberg wrote: >> > A related question has occurred to me just recently: If an RTCP >> > compound packet includes information from more than one host, as in >> > the case where an RTP mixer aggregates SDES information from multiple >> > sources, should the size of that packet be divided by the number of >> > sources before being figured into the average? >> >> Good catch; I believe it does need to be divided in this way. Otherwise, >> if the packet size is more than 5 times the average size, there will be >> constant timeouts. > >I'm not sure that's true. Everyone should be averaging over the same >set of packets, so the intervals should be roughly consistent. Well, >execept that the estimator gain is 1/16 so it could bounce around if >the big packet was only one out of many. My concern was more that the >average would be wrong -- too large, which means intervals longer than >they should be, which is the safer direction. I'd be more tempted to follow Jonathan's other suggestion, and allow a mixer which is mixing N sources to use N times the single source RTCP bandwidth. This would also let you get away with the naive implementation of sending an RTCP packet on the mixed side each time a packet is received on the non-mixed side (ie: rewrite the SR/RR but forward SDES packets as soon as they are received). Colin From rem-conf-request@es.net Wed Oct 27 08:21:16 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07877 for ; Wed, 27 Oct 1999 08:21:15 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gRno-00051a-00; Wed, 27 Oct 1999 05:03:40 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gRnn-00051Q-00; Wed, 27 Oct 1999 05:03:39 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06819; Wed, 27 Oct 1999 08:03:37 -0400 (EDT) Message-Id: <199910271203.IAA06819@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-02.txt Date: Wed, 27 Oct 1999 08:03:37 -0400 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-02.txt Pages : 6 Date : 26-Oct-99 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-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-rtp-interop-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-rtp-interop-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: <19991026144916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026144916.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Oct 27 08:21:18 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07888 for ; Wed, 27 Oct 1999 08:21:18 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gRny-00051y-00; Wed, 27 Oct 1999 05:03:50 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gRnx-00051o-00; Wed, 27 Oct 1999 05:03:49 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06858; Wed, 27 Oct 1999 08:03:47 -0400 (EDT) Message-Id: <199910271203.IAA06858@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-rtptest-02.txt Date: Wed, 27 Oct 1999 08:03:46 -0400 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 Testing Strategies Author(s) : C. Perkins, J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtptest-02.txt Pages : 19 Date : 26-Oct-99 This memo describes a possible testing strategy for RTP implementations. The tests are intended to help demonstrate interoperability of multiple implementations, and to illustrate common implementation errors. They are not intended to be an exhaustive set of tests and passing these tests does not necessarily imply conformance to the complete RTP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-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-rtptest-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-rtptest-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: <19991026144953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtptest-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtptest-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026144953.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Oct 27 08:21:39 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07900 for ; Wed, 27 Oct 1999 08:21:39 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gRox-00052E-00; Wed, 27 Oct 1999 05:04:51 -0700 Received: from max.poly.edu [128.238.32.105] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gRow-000524-00; Wed, 27 Oct 1999 05:04:50 -0700 Received: (from icme2000@localhost) by max.poly.edu (8.8.7/8.8.7) id DAA26862; Wed, 27 Oct 1999 03:44:36 -0400 Date: Wed, 27 Oct 1999 03:44:36 -0400 Message-Id: <199910270744.DAA26862@max.poly.edu> From: icme2000@penguin.poly.edu Subject: IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA AND EXPO To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA AND EXPO JULY 30 -- AUGUST 2, 2000, NEW YORK CITY http://www.ieee-multimedia.poly.edu -----------------CALL FOR PAPERS-------------------- International Conference on Multimedia & Expo 2000 is the first IEEE multimedia conference that will take place in joint collaboration with four IEEE societies. The same four IEEE societies that have recently launched the IEEE Transactions on Multimedia, namely the Circuits and Systems Society, the Computer Society, the Signal Processing Society and the Communications Society have again come together in making this one-of-a-kind conference a reality. The goal is to unify all IEEE as well as non-IEEE multimedia related activities under the common umbrella of ICME 2000 -- the millennium multimedia meeting. It is expected that this will become a yearly event as the flagship Multimedia conference of the IEEE. New York City (the Big Apple) is uniquely suited for this first-time event in view of its large concentration of high tech Industries, first-rate academic institutions and numerous small multimedia companies. The intent is to blend the traditional IEEE conference framework into an Expo by providing the industry an opportunity to showcase products. Authors should submit a four-page manuscript in double-column format including authors' names, affiliations and a short abstract. Only electronic submission (in postscript format) will be accepted. Electronic submission procedure will be made available at the conference web site: http://www.ieee-multimedia.poly.edu Topics covered include but are not limited to the following: * Signal processing for media integration * Components and technologies for multimedia systems * Human-machine interface and interaction * Multimedia databases and file systems * Multimedia communication and networking * System integration * Applications * STDS standards and related issues Once accepted, the authors will be asked to prepare a four-page camera ready paper to appear in the conference proceedings and CD-ROM proceedings. Proposals for special sessions and half-day or full-day tutorial courses may be submitted to the respective chairs before the respective deadlines. Visit the conference web site for further information. DEADLINES December 1, 1999 Submission of regular papers February 1, 2000 Proposals for special sessions, panels, tutorials, demos March 1, 2000 Notification of acceptance for papers March 15, 2000 Notification of acceptance for proposals April 1, 2000 Paper camera-ready copy due CONFERENCE COMMITTEE General Chair: Sankar Basu, IBM sankar@watson.ibm.com Finance Chair: Peter Westerink, IBM Technical Program Co-Chairs: Tsuhan Chen, Carnegie Mellon Jeff H. Derby, IBM Peiya Liu, Siemens Chung-Sheng Li, IBM Special Sessions: Raj Acharya, SUNY, Buffalo Chalapathy Neti, IBM Tutorials: Rama Chellappa, U. Maryland Alexandros Eleftheriadis, Columbia Plenaries: S. Y. Kung, Princeton U. Shih-Fu Chang, Columbia U. Demos/Exhibits: Yao Wang, NY Polytechnic U. Publicity: Jelena Kovacevic, Bell Labs Ed Wong, NY Polytechnic Publications: Y. Q. Shi, NJIT Bhuvana Ramabhadran, IBM Registration: Junehwa Song, IBM Local Arrangements: Goran Djuknic, Lucent Tech. Ravi Rao, IBM Atul Puri, AT&T Electronic Media: Raj Kumar Rajendran, Columbia University Nasir Memon, Polytechnic University European Liaison: Alberto Del Bimbo, U. Florence Martin Vetterli, EPFL Far East Liaison: Masahito Hirakawa, Hiroshima U. Sadaoki Furui, Tokyo Inst. Tech. Steering Committee: Tadao Ichikawa, Hiroshima U. Rama Chellappa, U. Maryland Gary W. Cobb, Dell Alberto Del Bimbo, U. Florence Jeff H. Derby, IBM Alexander D. Gelman, Panasonic Yih-Fang Huang, U. Notre Dame Chung-Sheng Li, IBM Peiya Liu, Siemens Antonio Ortega, USC Dipankar Raychaudhuri, NEC Bing Sheu, Avanti Corporation John A. Sorensen, TU Denmark Advisory Committee: Richard Cox, AT&T Ed Deprettere, Delft U. Tech. Cesar Gonzales, IBM Scott Kirkpatrick, IBM Michael Picheny, IBM  From rem-conf-request@es.net Wed Oct 27 08:22:45 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07931 for ; Wed, 27 Oct 1999 08:22:44 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gRns-00051m-00; Wed, 27 Oct 1999 05:03:44 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gRnr-00051c-00; Wed, 27 Oct 1999 05:03:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06838; Wed, 27 Oct 1999 08:03:42 -0400 (EDT) Message-Id: <199910271203.IAA06838@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-mpeg4-02.txt,.ps Date: Wed, 27 Oct 1999 08:03:41 -0400 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 MPEG-4 Streams Author(s) : R. Civanlar, A. Basso, S. Casner, C. Herpel, C. Perkins Filename : draft-ietf-avt-rtp-mpeg4-02.txt,.ps Pages : 10 Date : 26-Oct-99 This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force and ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. 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-mpeg4-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-rtp-mpeg4-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-rtp-mpeg4-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: <19991026144940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026144940.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Oct 27 10:38:53 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14258 for ; Wed, 27 Oct 1999 10:38:52 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gTsM-000148-00; Wed, 27 Oct 1999 07:16:30 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gTsK-00013y-00; Wed, 27 Oct 1999 07:16:28 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id JAA02315 for ; Wed, 27 Oct 1999 09:16:22 -0500 (CDT)] Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA01331 for ; Wed, 27 Oct 1999 09:16:22 -0500 (CDT)] Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2580.0) id ; Wed, 27 Oct 1999 09:16:22 -0500 Message-ID: <5D7E7DD6AAEDD21187950008C791361DCB5F41@il02exm05.comm.mot.com> From: Parekh Rishabh-crp049 To: "'rem-conf@es.net'" Cc: "Mike Korus (E-mail)" Subject: RTP port range question Date: Wed, 27 Oct 1999 09:16:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a question regarding the UDP ports used for RTP. Here is an excerpt from RFC 1889. "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number with the next lower (even) number." Does RTP use an even UDP source port or an even UDP destination port? Thanks to all who reply, Rishabh Parekh Motorola From rem-conf-request@es.net Wed Oct 27 11:33:34 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17324 for ; Wed, 27 Oct 1999 11:33:33 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gUsP-0002H3-00; Wed, 27 Oct 1999 08:20:37 -0700 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gUsO-0002Gt-00; Wed, 27 Oct 1999 08:20:36 -0700 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQhmth08809; Wed, 27 Oct 1999 15:23:58 GMT Message-ID: <38171884.E4F530EE@dynamicsoft.com> Date: Wed, 27 Oct 1999 11:21:40 -0400 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Parekh Rishabh-crp049 CC: "'rem-conf@es.net'" , "Mike Korus (E-mail)" Subject: Re: RTP port range question References: <5D7E7DD6AAEDD21187950008C791361DCB5F41@il02exm05.comm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Parekh Rishabh-crp049 wrote: > > I have a question regarding the UDP ports used for RTP. Here is an excerpt > from RFC 1889. > > "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP > data and RTCP control streams. For UDP and similar protocols, RTP uses an > even port number and the corresponding RTCP stream uses the next higher > (odd) port number. If an application is supplied with an > odd number for use as the RTP port, it should replace this number with the > next lower (even) number." > > Does RTP use an even UDP source port or an even UDP destination port? The source port is irrelevant. Its the destination port. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 210 Dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf-request@es.net Thu Oct 28 03:21:18 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11315 for ; Thu, 28 Oct 1999 03:21:18 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gjUO-0002gg-00; Wed, 27 Oct 1999 23:56:48 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gjUN-0002gW-00; Wed, 27 Oct 1999 23:56:47 -0700 Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA27745; Wed, 27 Oct 1999 23:55:46 -0700 (PDT) Date: Wed, 27 Oct 1999 23:55:16 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net cc: Colin Perkins Subject: Working group last call on RTP to Draft Standard Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT Working Group: This message announces the working group last call for comments on the set of drafts needed to advance RTP spec to Draft Standard status. This working group last call is to end with the AVT session at the IETF meeting in two weeks. At the meeting, we will propose submission for IESG Last Call. Assuming there are no objections, the goal will be to make edits on site if possible to address any comments, and then submit to the Area Directors. We'd like to conclude this process! In addition, this is a request to RTP implementors to fill in the interoperability checklist that we will need to accompany the drafts for advancement to Draft Standard. We've made the same request informally before, but this time we're asking that you do this in the next two weeks so that we can have at least a first-pass tally at the meeting. If it looks like there are features for which we don't have two interoperable implementations, we may have to remove those features from the draft, or do some additional implementation and interop testing! Here are the details on the drafts starting WG last call: The RTP spec and the A/V Profile have been updated to reflect the changes agreed upon at the last meeting. These drafts have not made it through the Internet-Drafts queue yet, so you can get them from ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-new-05.ps ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-new-05.txt ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-profile-new-07.ps ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-profile-new-07.txt The .ps versions have changebars relative to RFC 1889 and 1890. The spec and profile drafts need to be accompanied by the drafts on RTP MIME type registration and SDP bandwidth specifiers for RTCP which are referenced (non-normatively) by the spec and profile drafts. These drafts will be submitted for publication as Proposed Standards. ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-mime-01.txt draft-ietf-avt-rtcp-bw-00.txt (no recent edits) RTP testing and interoperability are addressed in Informational drafts that have also been updated and should appear shortly: draft-ietf-avt-rtptest-02.txt draft-ietf-avt-rtp-interop-02.txt The second of these drafts is the checklist for interoperability statements on the RTP spec. We do need one more draft to cover the interoperability criteria for the A/V profile, which is to be posted shortly after the IETF meeting. -- Steve and Colin From rem-conf-request@es.net Thu Oct 28 04:38:40 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12094 for ; Thu, 28 Oct 1999 04:38:39 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gkvA-0004CE-00; Thu, 28 Oct 1999 01:28:32 -0700 Received: from hts.on.ca [206.47.33.2] by mail1.es.net with smtp (Exim 1.81 #2) id 11gkv8-0004Bs-00; Thu, 28 Oct 1999 01:28:30 -0700 Received: from mail.mia.mailprogram78844.com by hts.on.ca;Thu, 28 Oct 1999 08:35:13 GMT From: To: Date: Sat, 30 Oct 1999 03:26:26 Message-Id: <519.813628.114987@mail.mia.mailprogram78844.com> Subject: GET YOUR 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH! 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 Content-Transfer-Encoding: 7bit Why pay over $19.00 a month or more for web space? Call PES CONSOLIDATED ENTERPRISES Today AT 1 888 248 0765. SAVE BIG MONEY ON WEB HOSTING WITH PES CONSOLIDATED ENTERPRISES AND PAY ONLY $11.95 PER MONTH FOR YOUR WEB SITE. OUR SPECIAL PRICE INCLUDES HAVING YOUR OWN DOMAIN WITH 5 megs of web space! WE offer high-speed OC - 3 multiple backbone connnections! WITH every domain you get: - 5 meg web site - front page 2000 EXTENSIONS - customized cgi bins & much much more! All for only $11.95 per month! *set up charges are only $39.95 Simply park your domain with us, upload your data and you are all ready on the web. Stop overpaying for your web site and host with PES CONSOLIDATED ENTERPRISES TODAY! Need A web site designed? Just give us a call TODAY! We will be more than happy to quote you a price on what it will take to get your business on the web today! If you are calling within the United States please call 18882480765. If you reside outside of the United States please call 514 221 2032 for more information. All web sites hosted by us are pre-paid for the year with a 10 day money back guarantee! A $39.95 setup fee applies for each new domain set up with us. to unsubcribe from our list please email webhost1887@indiasite.com PES CONSOLIDATED ENTERPRISES INC Montreal Quebec 514 221 2032 From rem-conf-request@es.net Thu Oct 28 07:14:19 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14398 for ; Thu, 28 Oct 1999 07:14:18 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnJ4-0005ud-00; Thu, 28 Oct 1999 04:01:22 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnJ3-0005uT-00; Thu, 28 Oct 1999 04:01:21 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13361; Thu, 28 Oct 1999 07:01:19 -0400 (EDT) Message-Id: <199910281101.HAA13361@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-multiplexing-rtp-01.txt Date: Thu, 28 Oct 1999 07:01:19 -0400 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 : Multiplexing Scheme for RTP Flows between Access Routers Author(s) : K. El-khatib, G. Luo, G. Bochmann, P. Feng Filename : draft-ietf-avt-multiplexing-rtp-01.txt Pages : 13 Date : 27-Oct-99 This draft proposes a light-weight data driven approach for multiplexing low bit rate RTP streams at the edge router of the Internet in order to reduce the RTP/UDP/IP header overhead associated with each RTP stream. Audio packets from different sources in a local access network destined to different users in the same remote access network are multiplexed into one packet, with the original RTP/UDP/IP header of each packet replaced with a mini-header (2 bytes), resulting in a reduction of the overhead. Access routers can use the IP telephony Border Gateway Protocol (TBGP) to exchange the reachability of IP destinations in their domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-multiplexing-rtp-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-multiplexing-rtp-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-multiplexing-rtp-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: <19991027135717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-multiplexing-rtp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-multiplexing-rtp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027135717.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 07:14:23 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14409 for ; Thu, 28 Oct 1999 07:14:23 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnJA-0005uy-00; Thu, 28 Oct 1999 04:01:28 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnJ9-0005ug-00; Thu, 28 Oct 1999 04:01:27 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13373; Thu, 28 Oct 1999 07:01:25 -0400 (EDT) Message-Id: <199910281101.HAA13373@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-07.txt,.ps Date: Thu, 28 Oct 1999 07:01:24 -0400 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-07.txt,.ps Pages : 37 Date : 27-Oct-99 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-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-profile-new-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-profile-new-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: <19991027135727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027135727.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 07:14:35 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14443 for ; Thu, 28 Oct 1999 07:14:34 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnJL-0005vf-00; Thu, 28 Oct 1999 04:01:39 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnJK-0005vV-00; Thu, 28 Oct 1999 04:01:38 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13403; Thu, 28 Oct 1999 07:01:37 -0400 (EDT) Message-Id: <199910281101.HAA13403@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-mib-07.txt Date: Thu, 28 Oct 1999 07:01:36 -0400 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 : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick,B. Strahm Filename : draft-ietf-avt-rtp-mib-07.txt Pages : 37 Date : 27-Oct-99 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-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-mib-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-mib-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: <19991027135747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027135747.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 07:14:46 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14488 for ; Thu, 28 Oct 1999 07:14:45 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnIA-0005uP-00; Thu, 28 Oct 1999 04:00:26 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnI8-0005uF-00; Thu, 28 Oct 1999 04:00:25 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13230; Thu, 28 Oct 1999 07:00:22 -0400 (EDT) Message-Id: <199910281100.HAA13230@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-01.txt Date: Thu, 28 Oct 1999 07:00:21 -0400 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-01.txt Pages : 18 Date : 27-Oct-99 This document defines the procedure to register RTP Payload Formats as audio or video 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-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-mime-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-mime-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: <19991027135649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mime-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mime-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027135649.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 07:15:12 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14505 for ; Thu, 28 Oct 1999 07:15:11 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnJG-0005vT-00; Thu, 28 Oct 1999 04:01:34 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnJF-0005vJ-00; Thu, 28 Oct 1999 04:01:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13391; Thu, 28 Oct 1999 07:01:31 -0400 (EDT) Message-Id: <199910281101.HAA13391@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-05.txt,.ps Date: Thu, 28 Oct 1999 07:01:31 -0400 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-05.txt,.ps Pages : 100 Date : 27-Oct-99 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-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-new-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-new-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: <19991027135737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027135737.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 07:38:28 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15463 for ; Thu, 28 Oct 1999 07:38:27 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gnl8-0001N3-00; Thu, 28 Oct 1999 04:30:22 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gnl6-0001Mt-00; Thu, 28 Oct 1999 04:30:20 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14999; Thu, 28 Oct 1999 07:30:18 -0400 (EDT) Message-Id: <199910281130.HAA14999@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tones-02.txt,.ps Date: Thu, 28 Oct 1999 07:30:18 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-02.txt,.ps Pages : 28 Date : 27-Oct-99 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-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-tones-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-tones-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: <19991028064532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028064532.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 28 14:11:42 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02298 for ; Thu, 28 Oct 1999 14:11:41 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gsYo-0004no-00; Thu, 28 Oct 1999 09:37:58 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11gsYn-0004ne-00; Thu, 28 Oct 1999 09:37:57 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 28 Oct 1999 17:37:52 +0100 To: rem-conf@es.net Subject: Outline AVT agenda cc: casner@cisco.com Date: Thu, 28 Oct 1999 17:37:52 +0100 Message-ID: <3702.941128672@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Enclosed is the list of requests for agenda time I have received for the AVT meeting at the Washington DC IETF. If there are any additional items or corrections, please contact me as soon as possible. I will be putting the final agenda together early next week. Thanks, Colin =============================================================================== - Introduction and status update draft-ietf-avt-fec-08.txt draft-ietf-avt-rtp-format-guidelines-04.txt draft-ietf-avt-rtpsample-05.txt draft-ietf-avt-rtp-mib-07.txt draft-ietf-avt-tones-01.txt - RTP and the audio/video profile draft-ietf-avt-rtp-new-05.txt draft-ietf-avt-profile-new-06.txt draft-ietf-avt-rtp-mime-00.txt draft-ietf-avt-rtcp-bw-00.txt draft-ietf-avt-rtp-interop-02.txt draft-ietf-avt-rtptest-02.txt - RTP Payload for text conversation draft-ietf-avt-rtp-text-02 (Hellstrom) - RTP Payload Format for DV Format Video draft-ietf-avt-dv-video-01.txt (Kobayashi) - RTP Payload Format for 12 bits, 20bits and 24 bits DV Audio draft-ietf-avt-dv-audio-00.txt (Kobayashi) - RTP Payload Format for MPEG-2 AAC Streams draft-ietf-avt-rtp-mpeg2aac-01.txt (Basso) - A More Loss-Tolerant RTP Payload Format for MP3 Audio draft-ietf-avt-rtp-mp3-01.txt (Finlayson) - Transport of MPEG-4 draft-ietf-avt-rtp-mpeg4-02.txt (Basso) draft-guillemot-genrtp-01.txt (Christ) draft-jnb-mpeg4av-rtp-00.txt (Harasaki) draft-singer-rtp-qtfile-01.txt (Singer) Liason statement from MPEG (29n3290.zip) - An RTCP-based Retransmission Protocol for Unicast RTP Streaming Multimedia draft-podolsky-avt-rtprx-00.txt (Yano) - Dynamic Nx64 trunking draft-tulai-avt-dynamic-nx64-00.txt (Tulai) =============================================================================== From rem-conf-request@es.net Thu Oct 28 14:15:08 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02547 for ; Thu, 28 Oct 1999 14:15:05 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11gtQI-0006Dd-00; Thu, 28 Oct 1999 10:33:14 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11gtQH-0006DT-00; Thu, 28 Oct 1999 10:33:13 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA23471 for ; Thu, 28 Oct 1999 13:33:12 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA29154 for ; Thu, 28 Oct 1999 13:33:11 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <381888D7.A10E0EC4@cs.columbia.edu> Date: Thu, 28 Oct 1999 13:33:11 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Voice activity detection software Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit I'm looking for voice-activity detection software modules. I'm aware of the modules in vat, nevot and rat. Anything else? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Thu Oct 28 22:58:09 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28211 for ; Thu, 28 Oct 1999 22:58:09 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h1tQ-0003oC-00; Thu, 28 Oct 1999 19:35:52 -0700 Received: from hubbub.cisco.com [171.69.11.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h1tP-0003nr-00; Thu, 28 Oct 1999 19:35:51 -0700 Received: from hcliu-nt (dhcp-71-149-143.cisco.com [171.71.149.143]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id TAA20147 for ; Thu, 28 Oct 1999 19:34:50 -0700 (PDT) Message-Id: <4.1.19991028192210.00b6ce00@mailhost.cisco.com> X-Sender: hcliu@mailhost.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 28 Oct 1999 19:37:59 -0700 To: rem-conf@es.net From: Humphrey Liu Subject: Submission of RTP payload for MPEG2 MPTS Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_373887712==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_373887712==_ Content-Type: text/plain; charset="us-ascii" Dear all, I am submitting a draft of delivering MPEG2 multiple program transport stream (MPTS) for consideration. Essentially, this draft is the extension of RFC2250. The reason why this extension is needed is that when the encapsulated MPEG2 MPTS has high bandwidth such as 30-60Mbps, the original base clock, 90KHz, defined in RFC2250, is not good enough. Thus, I propose in this draft to extend the clock frequency to 27MHz, the same frequency as MPEG2 Program Clock Reference. I understand that I missed the submission deadline for the upcoming meeting. However, I wonder if there is any chance that the draft can be still included for discussion. I certainly would like to present this draft to the working group to moving forward. Any help will be highly appreciately!! Humphrey Liu --=====================_373887712==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mp2t-00.txt" Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT H. Liu draft-ietf-avt-rtp-mp2t-00.txt Cisco Systems October 22, 1999 Expires: 04/22/2000 Extension of RTP payload Type for Multiple Program MPEG Transport Stream Abstract This document is to define a dynamic payload type that extends the payload type of 33, defined in RFC1890 [4] for MPEG2 transport streams. The usage of payload type of 33 is defined in RFC2250 [1]. This purpose of this extension is to enhance the RTP protocol in such way that it can be used to deliver multiple program MPEG transport stream as well. 1. Introduction Recent effort in the DVB and ATSC standard body has endorsed MPEG2 transport stream format as the broadcast transport standard. With appropriate internet standard such as RFC 2236 [2] for multicast and RFC 2205 [3] and other RFC's for QoS, real-time streaming becomes quite feasible. Also with the technology advances on the "last-mile" network such as cable modem and DSL, it is quite possible to deliver high bandwidth, broadcast quality, and individualized MPEG video directly to home. Section 2 in RFC2250 defines how to encapsulate MPEG2 transport stream into RTP packet format. RFC2250 defines the base frequency for MPEG2 transport stream to be 90KHz. While this base clock is proper for an MPEG single program transport stream (SPTS), it losses the precision for MPEG multiple program transport stream (MPTS). Thus, a new payload type is needed when RTP is used to transport MPEG MPTS. 2. Extension to Payload Type for MP2T ISO/IEC 13818-1 [5] defines MPEG transport packet format to be able to carry not only video, audio, but also any program related data. Further more, with ISO/IEC 13818-6, DSM-CC [6], and the Radio Frequency Interface Specification of Data-Over-Cable Services Interface Specification (DOCSIS), defined by CableLab [7], the same packet format can be used to deliver IP data as well. According to ISO/IEC 13818-1, at MPEG transport packet layer, every transport packet is a sample unit in time, instead of the video or audio access units. Thus, the sample clock frequency should be suitable for the packet samples. In the satellite and cable industry, each video frequency carrier typically contains from 27Mbps to 50Mbps. Each frequency carrier can contain up to 40,000 MPEG transport packets. If the base clock frequency 90,000 defined by the payload type of 33 is to be used, each packet only has 2.5 clock tick time. Any round-off error can count for 30% error rate. Thus, the existing payload type 33 is not suitable to deliver MPEG MPTS. Furthermore, if payload type of 33 is to be used for SPTS, one can argue that, in this case, PCR and continuity counter embedded in the MPEG transport packet header can be used for the purpose of clock synchronization and packet drop detection, repectively. In fact, several vendors in the MPEG industry have selected UDP/IP for transporting MPEG2 SPTS in the IP network, instead of RTP. Thus, the most compelling application for the RTP payload type of 33 is for transporting MPEG MPTS. Because of that, the base clock with higher frequency should be defined to allow a reasonable RTP deliver scheme for MPEG MPTS. This document defines a new dynamic payload type of 96 that extends the base clock frequency payload type of 33 from 90KHz to 27MHz. 27MHz is the same as the Programe Clock Reference (PCR) defined in ISO/IEC 13818-1. Now that MPEG MPTS is to feed any NTSC/PAL receiver, the clock recovery has to be very conservative. The same requirement on the clock frequency and clock recovery rate from ISO/IEC 13818-1 is applied here as well. Now that a dynamic payload type is to be used, RFC2327 [8], Session Decription Protocol (SDP), should be used to broadcast the session information. More specifically, the attribute parameter, a, in the SDP should be defined as follow: a=rtpmap:96 MP2T/27000000 Other parameters should be set followed the direction of RFC2327. 3. A four layer model: When delivering MPEG transport stream using the profile defined in this draft, the buffer model given in Fig. 1 is assumed. +-----------+ +-----------+ +-----------+ +-----------+ | | | MPEG | |MPEG | | MPEG | |RTP packet |---->| transport |---->| PES |---->|A/V Compr. | | | | packet | | packet | | layer | +-----------+ +-----------+ +-----------+ +-----------+ RTP timestamps MPEG PCRs | | v v +-----------+ +-----------+ +-----------+ +-----------+ | IP | | MPEG | Vid.| MPEG | | MPEG | | Dejitter |---->| Transport |---->|Demultiplex|---->|Elementary | | Buffer | | Buffer |\ | Buffer | | Buffer | +-----------+ +-----------+ \ +-----------+ +-----------+ | \ | \ Audio | \ | \ +-----------+ | \ | MPEG | | --------------> | Audio Main| | | Buffer | | +-----------+ |System info & other data | +-----------+ | | MPEG | +---------------------------> |System Main| | Buffer | +-----------+ Figure 1: The Packet/Buffer Model for MPEG MPTS over RTP The Buffer model shown in Figure 1 is the extension of the buffer model given in ISO/IEC 13818-1. In addition to different MPEG packet layers, RTP layer and its associated IP dejitter buffer is added. The model given in Fig. 1 implies two clock recovery functions. The timestamps from RTP packets are used to synchronize the receiver clock for RTP session, while MPEG PCRs from MPEG transport packets are used to recover the MPEG decoder clock. The size of the dejitter buffer is determined by the maximal delay variation introduced by the IP network. However, there are many ways to determine size of the dejitter buffer statically or statistically. For example, the jitter can be computed from the "interarrival jitter" from the sender report in its corresponding RTCP session. Alternatively, the jitter can also be computed from the guaranteed service block in ADSpec in the RSVP PATH message if RSVP is used for QoS. This document does not specify any method to determine the buffer size. There are two benefits by using layered approach given in Fig. 1. The first benefit is that all the standardized tables and new services defined by DVB and ATSC can be included without any extra work. Thus, any video content that is available from digital broadcast industry can be easily delivered to the end user through IP network with minimal work at the RTP layer. The second benefit of this layered model is that the IP dejittering layer does not need to implement at the decoder side. For example, one can remove jitter induced by IP network first and broadcast MPEG MPTS to the end customer. The purpose of the IP dejitter buffer is to recover the temporal relationship between MPEG transport packet at the buffer output. By doing so, as long as the the MPEG MPTS is compliant at the ingress point, the output of the dejitter buffer should be compliant to ISO/IEC 13818-1. Thus, as long as QoS can be supported, the IP network can be viewed as another streaming transport method, just like ATM. 4. The Use of Timestamp In addition to its original purpose of clock synchronization, when the payload type of 33 is used with marker bit set to one, the timestamp is also used for the following information: a. Derived Piece-wise constant-bitrate(CBR) for the current RTP packet. It is assumed under this document that the session bitrate for any RTP packet is a constant. By knowing the size of RTP packet (from the length field in UDP packet), the timestamps from the current and the next RTP packet, this constant bitrate can be derived. However, the bitrate between packets can be different. Thus, a more constrained VBR can be implemented by changing the channel bitrate at the boundary of each RTP packet. b. Derived timestamp for every MPEG transport packets encapsulated in the RTP packet. Now that the session bitrate within one RTP packet is a constant and the timestamp of the RTP packet represents the timestamp of the first MPEG packet, it implies that the timestamp corresponding to the rest of MPEG packets in the RTP packet can be derived from it. As an example, suppose the current RTP packet has a timestamp of 200, the next RTP has a timestamp of 400, and the number of MPEG packets encapsulated in one RTP packet is five. The first MPEG packet has a timestamp of 200, the second 240, the third 280, the fourth 320, and the fifth 360. Thus, the packet flowing out of the dejitter buffer is deterministic. 4. Limitation on the rate change when M is set to one According to RFC2250, when M is set to one, it indicates that the session has switched to different source. Thus, the receiver should reset its PLL and lock to the new clock immediately. The implication of this marker bit is that there is no relationship between the current RTP packet and the previous RTP packet. Thus, the rate change must be prohibited on the last RTP packet before performing any source switching. 5. References [1] D. Hoffman et al., "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, Jan. 1998. [2] W. Fenner, "Internet Group Management Protocol Ver. 2", RFC2236, Nov. 1997. [3] R. Braden et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, Sept. 1997. [4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, Jan. 1996. [5] ISO/SEC. Generic Coding of Motion Pictures and Associated Audio: Systems. ISO/IEC Standard 13818-1, 1995. [6] ISO/IEC. Generic Coding of Motion Pictures and Associated Audio: Extension for DSM-CC. ISO/IEC Standard 13818-6, 1998. [7] CableLab. Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification. SP-RFIv1.1-I01-990311, 1999. [8] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC2327, Apr. 1998. --=====================_373887712==_ Content-Type: text/plain; charset="us-ascii" --=====================_373887712==_-- From rem-conf-request@es.net Fri Oct 29 03:00:39 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14461 for ; Fri, 29 Oct 1999 03:00:38 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h5qF-0006LP-00; Thu, 28 Oct 1999 23:48:51 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h5qE-0006LE-00; Thu, 28 Oct 1999 23:48:50 -0700 Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA17033; Thu, 28 Oct 1999 23:47:49 -0700 (PDT) Date: Thu, 28 Oct 1999 23:46:41 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Re: Working group last call on RTP to Draft Standard In-Reply-To: Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT Working Group: I should add a followup to my working group last call for comments on the RTP spec: *** If you have in the past sent comments to me or the other authors *** of the RTP spec or profile which you feel have not been *** appropriately addressed, then PLEASE repeat them now to the *** rem-conf list, or to me individually if you prefer, because it is *** entirely possible that I may have overlooked something. Of course, I won't reopen issues that we have decided, but I want to make sure there aren't corrections or clarifications that I have missed. As I mentioned, the changes to the RTP spec drafts were those we discussed at the last meeting and/or on the list. The changes made in draft-ietf-avt-rtp-new-05 are: - The pseudo-code for the collision/loop detection algorithm in Section 8 has been changed to pseudo-C syntax to make the if- then-else structure more clear. - As discussed at the last meeting and on the list, text was added about keeping packets from the new address after a SSRC collision of two remote sources occurs. This is for the case of mobile sources that change their IP address. - Reverse reconsideration is also used to possibly shorten the delay before sending RTCP SR when transitioning from passive receiver to active sender mode. - Timing out a participant is to be based on inactivity for a number of RTCP report intervals calculated using the receiver RTCP bandwidth fraction even for active senders. - Added text to say that active senders use RR packets in addition to SR packets when they have more than 31 sources to report on. The changes made in draft-ietf-avt-profile-new-07 are: - The Comfort Noise (CN) static payload type number was changed from 19 back to 13 as it was in the -01 version from which the value was incorporated into other groups' specifications. - The RTP timestamp clock rate for G722 was changed from the actual sampling rate of 16000 Hz back to 8000 Hz as it was in RFC 1890. A note has been added to clarify this discrepancy between the actual sampling rate and the RTP timestamp clock rate. - A note was added about MPA always using RTP timestamp clock rate 90000 regardless of the audio sampling rate. The changes to draft-ietf-avt-rtp-mime-01.txt are: - The mapping between MIME parameters and fmtp was clarified. - A registration form for the RED payload format was added. - An optional parameter "type" was added to the registration form for MPV. -- Steve From rem-conf-request@es.net Fri Oct 29 03:01:27 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14541 for ; Fri, 29 Oct 1999 03:01:26 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h5rY-0006Lk-00; Thu, 28 Oct 1999 23:50:12 -0700 Received: from 24.64.96.204.sk.wave.home.com (SaleBait Server) [24.64.96.204] by mail1.es.net with smtp (Exim 1.81 #2) id 11h5rV-0006La-00; Thu, 28 Oct 1999 23:50:11 -0700 From: SNB Marketing To: Message-Id: <419.436462.07473808chucky22254@go.com> Subject: Advertise your product or website to millions free Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 28 Oct 1999 23:50:11 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit I'm sorry if you already read or replied to this message earlier for "more info", my mail client is down, If you requested info last time just do it once more. Listen, I am trying to be as straight forward as possible with you. I can hook you up with the most powerful targeted email software you have ever seen. A twelve year old could learn it in minutes. Free advertising, how can you go wrong, it's the same software I used to send this mail to you. If you are serious about promoting your site or product with all bullshit aside, let me know. Just reply to this email and type "more info" in the subject line. I am not kidding you this is the most cost effective way to advertise, period. Free tech support with all our products. Thanks, SNB Marketing From rem-conf-request@es.net Fri Oct 29 03:07:06 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14622 for ; Fri, 29 Oct 1999 03:07:06 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h5yM-0007D8-00; Thu, 28 Oct 1999 23:57:14 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h5yM-0006zL-00; Thu, 28 Oct 1999 23:57:14 -0700 Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA17119; Thu, 28 Oct 1999 23:56:12 -0700 (PDT) Date: Thu, 28 Oct 1999 23:55:02 -0700 (Pacific Daylight Time) From: Stephen Casner To: Parekh Rishabh-crp049 cc: "'rem-conf@es.net'" , "Mike Korus (E-mail)" Subject: Re: RTP port range question In-Reply-To: <5D7E7DD6AAEDD21187950008C791361DCB5F41@il02exm05.comm.mot.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 27 Oct 1999, Parekh Rishabh-crp049 wrote: > I have a question regarding the UDP ports used for RTP. Here is an excerpt > from RFC 1889. > > "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP > data and RTCP control streams. For UDP and similar protocols, RTP uses an > even port number and the corresponding RTCP stream uses the next higher > (odd) port number. If an application is supplied with an > odd number for use as the RTP port, it should replace this number with the > next lower (even) number." > > Does RTP use an even UDP source port or an even UDP destination port? This paragraph refers to the destination port number. I will clarify this in the text. -- Steve From rem-conf-request@es.net Fri Oct 29 03:17:11 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14685 for ; Fri, 29 Oct 1999 03:17:10 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h6Ao-0000Vc-00; Fri, 29 Oct 1999 00:10:06 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h6An-0000Tv-00; Fri, 29 Oct 1999 00:10:05 -0700 Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA17435; Fri, 29 Oct 1999 00:08:20 -0700 (PDT) Date: Fri, 29 Oct 1999 00:07:09 -0700 (Pacific Daylight Time) From: Stephen Casner To: Murthy Nanduri cc: rem-conf@es.net Subject: Re: Padding in RTP In-Reply-To: <3816ADC0.D299E30F@seeyes.co.in> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 27 Oct 1999, Murthy Nanduri wrote: > I am working on the implementation of RFC2508.i.e., the > RTP/UDP/IP Header compression and decompression. ... > As per the RFC2508, I am setting the Bitmask for the Marker bit while > sending the compressed RTP packet. Right. > When the padding bit is set, I am sending the compressed UDP packet.. If the padding bit is set on all the packets, then you should be able to still send them as COMPRESSED_RTP packets. You only need to send COMPRESSED_UDP when the P bit changes (since there is no way to indicate that in a COMPRESSED_RTP packet). > Can you please let me know what has to be done by CRTP > with the padding bytes? Nothing. They should be passed through just as they are, along with the rest of the payload. > I want to know whether the padding bytes have to be removed > by CRTP compressor/decompressor OR it is the responsibility > of the RTP applications to ignore the padding bytes.. The answers are no and yes. A properly operating RFC2508 compressor and decompressor will produce packets at the output of the decompressor which are identical to the packets as they went into the compressor. > can U please let me know what for the Marker bit and Padding bits are > used? This is explained in the RTP spec (RFC 1889 or draft-ietf-avt-rtp-new-07) -- Steve From rem-conf-request@es.net Fri Oct 29 03:38:14 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15044 for ; Fri, 29 Oct 1999 03:38:13 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h6UZ-0001Sm-00; Fri, 29 Oct 1999 00:30:31 -0700 Received: from giasbm01.vsnl.net.in [202.54.1.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h6UV-0001Ru-00; Fri, 29 Oct 1999 00:30:28 -0700 Received: from hyd.chiplogic.com ([203.197.21.164]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id NAA09175 for ; Fri, 29 Oct 1999 13:00:19 +0530 (IST) Received: from chiplogic.com ([192.168.2.56]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id MAA24875 for ; Fri, 29 Oct 1999 12:01:20 +0530 Message-ID: <381941CD.D64BCB9E@chiplogic.com> Date: Fri, 29 Oct 1999 12:12:21 +0530 From: Rafiq Shaikh X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "rem-conf@es.net" Subject: RTP Profiles and Payload formats Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hi, In the section 12 of RFC 1889, it says to refer to 'companion documents' 1. draft-ietf-avt-profile 2. RTP Payload formats for xyz audio/video encodings. can anyone help me finding these docs? I am concerned about speech over RTP. Thanks in advance. Regards, -Rafiq. From rem-conf-request@es.net Fri Oct 29 04:53:17 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15985 for ; Fri, 29 Oct 1999 04:53:16 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h7bg-0002yf-00; Fri, 29 Oct 1999 01:41:56 -0700 Received: from omzrelay01.mcit.com (alpha.mcit.com) [199.249.19.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h7bf-0002yL-00; Fri, 29 Oct 1999 01:41:55 -0700 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #38416) id <0FKC00G01TJWLD@firewall.mcit.com> (original mail from dean.willis@wcom.com) for rem-conf@es.net; Fri, 29 Oct 1999 08:38:37 +0000 (GMT) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FKB00010SO9SE@firewall.mcit.com> for rem-conf@es.net; Thu, 28 Oct 1999 18:31:37 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id SAA26025; Thu, 28 Oct 1999 18:24:14 +0000 (GMT) Received: from dwillispc4 ([166.35.149.222]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19991028182850.XKPJ1099@dwillispc4>; Thu, 28 Oct 1999 18:28:50 +0000 Date: Thu, 28 Oct 1999 13:31:02 -0500 From: Dean Willis Subject: RE: RTP port range question In-reply-to: <5D7E7DD6AAEDD21187950008C791361DCB5F41@il02exm05.comm.mot.com> To: Parekh Rishabh-crp049 , rem-conf@es.net Cc: "Mike Korus (E-mail)" Message-id: <000a01bf2172$96968b20$de9523a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit RTP traditonally uses an even destination port number. I believe the source port number to be indeterminate, and have seen even, odd, and downright random implementations. One of the big problems we're seeing in SIP-PSTN gateway work is port number and the description thereof in SDP. As used, the SDP only specifies the destination port number (and IP address) and says nothing about the source. It is quite legal to use a model where, for one "end" of the conversation, one host is listening and an entirely different host is sending. The other end has no information about where the stream is coming from. This makes writing a dyamically stateful firewall very difficult. It also caused a number of SIP implementations to blow chunks at the last bakeoff. -- Dean > -----Original Message----- > From: Parekh Rishabh-crp049 [mailto:R.Parekh@motorola.com] > Sent: Wednesday, October 27, 1999 9:16 AM > To: 'rem-conf@es.net' > Cc: Mike Korus (E-mail) > Subject: RTP port range question > > > I have a question regarding the UDP ports used for RTP. Here is an excerpt > from RFC 1889. > > "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP > data and RTCP control streams. For UDP and similar protocols, RTP uses an > even port number and the corresponding RTCP stream uses the next higher > (odd) port number. If an application is supplied with an > odd number for use as the RTP port, it should replace this number with the > next lower (even) number." > > Does RTP use an even UDP source port or an even UDP destination port? > > Thanks to all who reply, > Rishabh Parekh > Motorola > From rem-conf-request@es.net Fri Oct 29 05:49:30 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16615 for ; Fri, 29 Oct 1999 05:49:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h8W1-0004Gf-00; Fri, 29 Oct 1999 02:40:09 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11h8Vz-0004GV-00; Fri, 29 Oct 1999 02:40:07 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Oct 1999 10:40:00 +0100 To: Rafiq Shaikh cc: "rem-conf@es.net" Subject: Re: RTP Profiles and Payload formats In-reply-to: Your message of "Fri, 29 Oct 1999 12:12:21 +0530." <381941CD.D64BCB9E@chiplogic.com> Date: Fri, 29 Oct 1999 10:39:59 +0100 Message-ID: <1044.941189999@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Rafiq Shaikh writes: >Hi, > >In the section 12 of RFC 1889, it says to refer to 'companion documents' >1. draft-ietf-avt-profile This was published as RFC1890, and is being updated as http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-07.txt >2. RTP Payload formats for xyz audio/video encodings. These are referenced from the audio/video profile, or you can find them at http://www.ietf.org/html.charters/avt-charter.html Colin From rem-conf-request@es.net Fri Oct 29 07:34:51 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18512 for ; Fri, 29 Oct 1999 07:34:51 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11h9uq-0005TE-00; Fri, 29 Oct 1999 04:09:52 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 11h9un-0005Sy-00; Fri, 29 Oct 1999 04:09:50 -0700 Received: from fokus.gmd.de (basil [193.175.132.64]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id NAA07634 for ; Fri, 29 Oct 1999 13:09:48 +0200 (MET DST) Sender: le@fokus.gmd.de Message-ID: <3819807A.5D51C73B@fokus.gmd.de> Date: Fri, 29 Oct 1999 13:09:46 +0200 From: Long Le X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Voice activity detection software References: <381888D7.A10E0EC4@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 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I'm looking for voice-activity detection software modules. I'm aware of > the modules in vat, nevot and rat. Anything else? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs My Diploma thesis under supervision of Henning Sanneck at GMD Fokus was about Internet speech transmission and also addresses the problem of voiced/unvoiced and silence detection (page 32-36). ftp://ftp.fokus.gmd.de/pub/glone/papers/Le9906_Loss-resilient.pdf.gz i only have an implementation in Matlab but implementation in C is really straight forward. -- long From rem-conf-request@es.net Fri Oct 29 07:57:59 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19334 for ; Fri, 29 Oct 1999 07:57:58 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11hAYP-0006Pn-00; Fri, 29 Oct 1999 04:50:45 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11hAYN-0006Pb-00; Fri, 29 Oct 1999 04:50:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18977; Fri, 29 Oct 1999 07:50:40 -0400 (EDT) Message-Id: <199910291150.HAA18977@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-text-02.txt Date: Fri, 29 Oct 1999 07:50:40 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-02.txt Pages : 9 Date : 28-Oct-99 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-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-rtp-text-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-rtp-text-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: <19991028141602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028141602.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Fri Oct 29 10:42:56 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28286 for ; Fri, 29 Oct 1999 10:42:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11hD2a-0000Sa-00; Fri, 29 Oct 1999 07:30:04 -0700 Received: from crufty.research.bell-labs.com [204.178.16.49] by mail1.es.net with smtp (Exim 1.81 #2) id 11hD2Y-0000SP-00; Fri, 29 Oct 1999 07:30:03 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Oct 29 10:29:15 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA09557; Fri, 29 Oct 1999 10:29:13 -0400 (EDT) Message-ID: <3819AF3B.9C12FE83@cs.columbia.edu> Date: Fri, 29 Oct 1999 10:29:15 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Rafiq Shaikh , "rem-conf@es.net" Subject: Re: RTP Profiles and Payload formats References: <381941CD.D64BCB9E@chiplogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Rafiq Shaikh wrote: > > Hi, > > In the section 12 of RFC 1889, it says to refer to 'companion documents' > 1. draft-ietf-avt-profile > 2. RTP Payload formats for xyz audio/video encodings. > > can anyone help me finding these docs? > I am concerned about speech over RTP. Related information and a reasonably complete listing of Internet Drafts can be found on the RTP page at http://www.cs.columbia.edu/~hgs/rtp Current drafts are also available through the IETF web site, but not all RTP-related drafts are listed on the AVT working group web page. (Individual submissions are not listed there.) > > Thanks in advance. > > Regards, > -Rafiq. From rem-conf-request@es.net Sat Oct 30 13:43:08 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28319 for ; Sat, 30 Oct 1999 13:43:07 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11hc7V-0004fO-00; Sat, 30 Oct 1999 10:16:49 -0700 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11hc7S-0004fE-00; Sat, 30 Oct 1999 10:16:47 -0700 Received: (from lanoms99@localhost) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) id PAA06488; Sat, 30 Oct 1999 15:08:06 -0200 (EDT) Date: Sat, 30 Oct 1999 15:08:06 -0200 (EDT) From: "LANOMS'99" Subject: IEEE LANOMS99 - Tutorilas Info and Registration Form To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl cc: "LANOMS'99" In-Reply-To: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list YOU COULD REGISTER ON-LINE VIA www.lrg.ufsc.br/~lanoms99. ***** IEEE LANOMS99 - TUTORIALS ***** TUTORIAL 1.1 - The technological and Economic Effects of the Deregulation of the Global Telecommunications Industry upon the Application of the Principles of Network Management By Keith von Mecklenburg (St. Andrews University, Scotland) Auditorium#1 - Dec 05 - 09:00 - 12:30 TUTORIAL 1.2 - Neural Networks and Distributed Algorithms for Network Management By Jayantha Herath (St. Cloud State University, USA), and By Susantha Herath (Aizu University, Japan) Auditorium#2 - Dec 05 - 09:00 - 12:30 TUTORIAL 2.1 - New Global Solutions of Event Correlation based on Distributed infrastructure By Gabriel Jakobson (GTE, USA) Auditorium#1 - Dec 05 - 14:00 - 17:30 TUTORIAL 2.2 - Network Management with SNMP: The Manager-Agent and Distributed Paradigms By Elias P. Duarte Jr. (Federal University of Parana, Brazil) Auditorium#2 - Dec 05 - 14:00 - 17:30 ***** IEEE LANOMS99 - TUTORIALS ABSTRACS ***** TUTORIAL 1.1 - The Technological and Economic Effects of the Deregulation of the Global Telecommunications Industry upon the Application of the Principles of Network Management Deregulation has increased the level of competition within National and International Telecommunications Industries, as State firms (e.g. Deutsche Telekom) and those private firms that dominate the telecoms market ( e.g. the Bell Companies and BT) within national jurisdictions, have to consider the lowering of line access charges to meet that competitive situation. It means that all firms, incumbents and new entrants, have to be focussed on the level of fixed and variable costs. Instead of being able to design and implement technological network systems with little regard to costs, the pressure is upon management to find the most effective technological solution which will also meet the measure of the lowest fixed and variable costs. The tutorial will therefore advance a new set of network management principles to meet the new and developing market competitive situation. Network Management will seek to develop operational models which satisfy the conflicting demands of the best technological and the best economic models of effective Network Management. TUTORIAL 1.2 - Neural Networks and Distributed algorithms for Network Management This tutorial provides an overview to network management issues in high performance distributed computing which promises wide range of new computationally intensive applications such as intelligent agents, data mining, computing at remote sites across wide variety of networks including the web. Network management and development of such applications and tools are neither easy nor quick because of the heterogeneous nature of the distributed systems. The problem becomes much difficult because of the service needs of distributed computations to be considered in the design and implementation process. Such needs include locating resources, allocating resources, communication protocols, security, accessibility, files, faults, memories and control. Network management is crucial to achieving highest performance from a dynamically changing distributed computing environment. This tutorial addresses the importance of applying learning techniques to distributed algorithms for network management. After providing an overview of centralized, hierarchical and distributed management models, protocols and architectures it will introduce the importance of integrating learning algorithms to the distributed algorithms. It will describe neural network based computations as one out of many learning techniques available for such applications. The focus will be to examine the integration of learning techniques to distributed algorithms for network management. This tutorial will also overview the recent activities and issues in the areas of communication protocols, synchronization algorithms for clocks, elections and deadlock handling, scheduling and fault tolerance of distributed processes and processors, sharing and replication management of distributed file systems and distributed shared memories. >From this tutorial you will learn network management models, neural network algorithms and distributed algorithms for network management. TUTORIAL 2.1 - New Global Solutions of Event Correlation based on Distributed infrastructure Audience: This is an introductory/intermediate level tutorial. The intended audience includes network/service managers and technical operations support professionals interested in learning new advanced methods of fault, performance. Abstract: Event correlation is a widely accepted technology for managing the complexity of modern telecommunication and data networks. Specific correlation applications have been developed to manage switched, SS7, wireless, ATM, SONET, IP, and other networks. All major players in the network management arena have either developed their own, usually embedded event correlation procedures, or have used event correlation products such as InCharge, NerveCenter, ILOG, ART-Enterprise, RTWorks, NetExpert, and G2. Various approaches to event correlation exist, including rule-, case-, and model-based reasoning, finite Major network operations support functions, based on real-time event correlation have emerged, including reduction of event flow by context-sensitive event filtering, fault management by fault diagnostics, localization, root cause identification and generation of corrective actions, and status reporting of complex multi-level hierarchical networks by semantic generalization of Despite the progress in the development of event correlation systems, there is a need to re-evaluate the current event correlation solutions and define new directions. It is important to broaden the utility of event correlation to other aspects of network management, such as performance, configuration, testing, security, and service quality management. Most importantly, the technology should be extended to perform cross-correlation between different domains, e.g. cross-correlation This tutorial is divided into three parts. In the first introductory part we will review the tasks, objectives, major technologies and products of existing solutions of event correlation. In the second part, we will introduce the concept, architectural framework, and components of a distributed global event correlation solution. In the third part we will illustrate how the concepts and architectural framework were implemented in a particular system GRACE, developed at GTE Laboratories. We will discuss the use of CORBA, Java, XML, SWING, Jacc and other technologies in GRACE, and illustrate the use of event correlation ith practical network management examples. TUTORIAL 2.2 - Network Management with SNMP: The Manager-Agent and Distributed Paradigms [Abstract] This tutorial starts with an introduction to the SNMP network management framework, describing its main components, including the SMI, MIB's, agents, management applications and the protocol itself. Following this introduction, the distributed paradigm for network management is examined, as well as different approaches for its deployment using SNMP. Case studies are presented, including the Routing Proxy, the Delegado MIB and the implementation of distributed system-level diagnosis using SNMP. Finally, an overview of the IETF's DisMan MIB's is presented. [Audience] This is an introdutory/intermediate tutorial. The intended audience includes network managers and technical professionals interested in learning about SNMP and how it can be used both a manager-agent and a distributed management paradigm. ***** IEEE LANOMS99 - TUTORIALS REGISTRATION FORM **** NAME: TITLE: ORGANIZATION: DEPARTMENT: ADDRESS: STATE: COUNTRY: EMAIL: TELEPHONE: FAX: Number of tutorial to be Registrated IEEE Members ( ) USD 125 - 1 Tutorial or ( ) USD 225 - 2 Tutorials IEEE Non-Members ( ) USD 150 - 1 Tutorial or ( ) USD 250 - 2 Tutorials Tutorials (Mark your choices) ( ) Tutorial 1.1 or ( ) Tutorial 1.2 ( ) Tutorial 2.1 or ( ) Tutorial 2.1 Total Tutorial: USD________ Method of Payment ( ) Method 1 - Money order in USD Payable to FEESC ( ) Method 2 - Check Brazilian Banks in R$ (exchange rate 1,9 R$/USD) For both methods make transfer to the following bank account: Bank Name: Banco do Brasil Bank Number: 001 Branch Number: 1453-2 Bank Account: 204.422.6 Swift Code: BRASBRRJFNS ( ) Method 3 - ( ) Mastercard Number:__________________ Expiration Date:______________ Account Name:________________ Authorized ( ) I authorize FEESC to deduct the amount inserted at TOTAL REMITTANCE from my credit card. SEND BY FAX OR BY EMAIL THE COMPLETED FORM WITH PAYMENT TO: Fundacao de Ensino e Engenharia de Santa Catarina (FEESC) Caixa Postal 5040 88040-970, Florianopolis (SC) Brazil Phone: +55.48.2334455 FAX: +55.48.3319677 EMAIL: katia@feesc.ufsc.br From rem-conf-request@es.net Sat Oct 30 14:09:30 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02683 for ; Sat, 30 Oct 1999 14:09:30 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11hcg3-0005dL-00; Sat, 30 Oct 1999 10:52:31 -0700 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11hcfz-0005d5-00; Sat, 30 Oct 1999 10:52:28 -0700 Received: (from lanoms99@localhost) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) id PAA07188; Sat, 30 Oct 1999 15:48:23 -0200 (EDT) Date: Sat, 30 Oct 1999 15:48:21 -0200 (EDT) From: "LANOMS'99" Subject: IEEE LANOMS99 - Tutorials Info and Registration Form To: Willie LU cc: cellular@comnets.rwth-aachen.de, activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, xtprelay@cs.concordia.ca, "LANOMS'99" , lyko@kt.agh.edu.pl In-Reply-To: <3813DADE.5EF49F6F@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list YOU COULD REGISTER ON-LINE VIA www.lrg.ufsc.br/~lanoms99. ***** IEEE LANOMS99 - TUTORIALS ***** TUTORIAL 1.1 - The technological and Economic Effects of the Deregulation of the Global Telecommunications Industry upon the Application of the Principles of Network Management By Keith von Mecklenburg (St. Andrews University, Scotland) Auditorium#1 - Dec 05 - 09:00 - 12:30 TUTORIAL 1.2 - Neural Networks and Distributed Algorithms for Network Management By Jayantha Herath (St. Cloud State University, USA), and By Susantha Herath (Aizu University, Japan) Auditorium#2 - Dec 05 - 09:00 - 12:30 TUTORIAL 2.1 - New Global Solutions of Event Correlation based on Distributed infrastructure By Gabriel Jakobson (GTE, USA) Auditorium#1 - Dec 05 - 14:00 - 17:30 TUTORIAL 2.2 - Network Management with SNMP: The Manager-Agent and Distributed Paradigms By Elias P. Duarte Jr. (Federal University of Parana, Brazil) Auditorium#2 - Dec 05 - 14:00 - 17:30 ***** IEEE LANOMS99 - TUTORIALS ABSTRACS ***** TUTORIAL 1.1 - The Technological and Economic Effects of the Deregulation of the Global Telecommunications Industry upon the Application of the Principles of Network Management Deregulation has increased the level of competition within National and International Telecommunications Industries, as State firms (e.g. Deutsche Telekom) and those private firms that dominate the telecoms market ( e.g. the Bell Companies and BT) within national jurisdictions, have to consider the lowering of line access charges to meet that competitive situation. It means that all firms, incumbents and new entrants, have to be focussed on the level of fixed and variable costs. Instead of being able to design and implement technological network systems with little regard to costs, the pressure is upon management to find the most effective technological solution which will also meet the measure of the lowest fixed and variable costs. The tutorial will therefore advance a new set of network management principles to meet the new and developing market competitive situation. Network Management will seek to develop operational models which satisfy the conflicting demands of the best technological and the best economic models of effective Network Management. TUTORIAL 1.2 - Neural Networks and Distributed algorithms for Network Management This tutorial provides an overview to network management issues in high performance distributed computing which promises wide range of new computationally intensive applications such as intelligent agents, data mining, computing at remote sites across wide variety of networks including the web. Network management and development of such applications and tools are neither easy nor quick because of the heterogeneous nature of the distributed systems. The problem becomes much difficult because of the service needs of distributed computations to be considered in the design and implementation process. Such needs include locating resources, allocating resources, communication protocols, security, accessibility, files, faults, memories and control. Network management is crucial to achieving highest performance from a dynamically changing distributed computing environment. This tutorial addresses the importance of applying learning techniques to distributed algorithms for network management. After providing an overview of centralized, hierarchical and distributed management models, protocols and architectures it will introduce the importance of integrating learning algorithms to the distributed algorithms. It will describe neural network based computations as one out of many learning techniques available for such applications. The focus will be to examine the integration of learning techniques to distributed algorithms for network management. This tutorial will also overview the recent activities and issues in the areas of communication protocols, synchronization algorithms for clocks, elections and deadlock handling, scheduling and fault tolerance of distributed processes and processors, sharing and replication management of distributed file systems and distributed shared memories. >From this tutorial you will learn network management models, neural network algorithms and distributed algorithms for network management. TUTORIAL 2.1 - New Global Solutions of Event Correlation based on Distributed infrastructure Audience: This is an introductory/intermediate level tutorial. The intended audience includes network/service managers and technical operations support professionals interested in learning new advanced methods of fault, performance. Abstract: Event correlation is a widely accepted technology for managing the complexity of modern telecommunication and data networks. Specific correlation applications have been developed to manage switched, SS7, wireless, ATM, SONET, IP, and other networks. All major players in the network management arena have either developed their own, usually embedded event correlation procedures, or have used event correlation products such as InCharge, NerveCenter, ILOG, ART-Enterprise, RTWorks, NetExpert, and G2. Various approaches to event correlation exist, including rule-, case-, and model-based reasoning, finite Major network operations support functions, based on real-time event correlation have emerged, including reduction of event flow by context-sensitive event filtering, fault management by fault diagnostics, localization, root cause identification and generation of corrective actions, and status reporting of complex multi-level hierarchical networks by semantic generalization of Despite the progress in the development of event correlation systems, there is a need to re-evaluate the current event correlation solutions and define new directions. It is important to broaden the utility of event correlation to other aspects of network management, such as performance, configuration, testing, security, and service quality management. Most importantly, the technology should be extended to perform cross-correlation between different domains, e.g. cross-correlation This tutorial is divided into three parts. In the first introductory part we will review the tasks, objectives, major technologies and products of existing solutions of event correlation. In the second part, we will introduce the concept, architectural framework, and components of a distributed global event correlation solution. In the third part we will illustrate how the concepts and architectural framework were implemented in a particular system GRACE, developed at GTE Laboratories. We will discuss the use of CORBA, Java, XML, SWING, Jacc and other technologies in GRACE, and illustrate the use of event correlation ith practical network management examples. TUTORIAL 2.2 - Network Management with SNMP: The Manager-Agent and Distributed Paradigms [Abstract] This tutorial starts with an introduction to the SNMP network management framework, describing its main components, including the SMI, MIB's, agents, management applications and the protocol itself. Following this introduction, the distributed paradigm for network management is examined, as well as different approaches for its deployment using SNMP. Case studies are presented, including the Routing Proxy, the Delegado MIB and the implementation of distributed system-level diagnosis using SNMP. Finally, an overview of the IETF's DisMan MIB's is presented. [Audience] This is an introdutory/intermediate tutorial. The intended audience includes network managers and technical professionals interested in learning about SNMP and how it can be used both a manager-agent and a distributed management paradigm. ***** IEEE LANOMS99 - TUTORIALS REGISTRATION FORM **** NAME: TITLE: ORGANIZATION: DEPARTMENT: ADDRESS: STATE: COUNTRY: EMAIL: TELEPHONE: FAX: Number of tutorial to be Registrated IEEE Members ( ) USD 125 - 1 Tutorial or ( ) USD 225 - 2 Tutorials IEEE Non-Members ( ) USD 150 - 1 Tutorial or ( ) USD 250 - 2 Tutorials Tutorials (Mark your choices) ( ) Tutorial 1.1 or ( ) Tutorial 1.2 ( ) Tutorial 2.1 or ( ) Tutorial 2.1 Total Tutorial: USD________ Method of Payment ( ) Method 1 - Money order in USD Payable to FEESC ( ) Method 2 - Check Brazilian Banks in R$ (exchange rate 1,9 R$/USD) For both methods make transfer to the following bank account: Bank Name: Banco do Brasil Bank Number: 001 Branch Number: 1453-2 Bank Account: 204.422.6 Swift Code: BRASBRRJFNS ( ) Method 3 - ( ) Mastercard Number:__________________ Expiration Date:______________ Account Name:________________ Authorized ( ) I authorize FEESC to deduct the amount inserted at TOTAL REMITTANCE from my credit card. SEND BY FAX OR BY EMAIL THE COMPLETED FORM WITH PAYMENT TO: Fundacao de Ensino e Engenharia de Santa Catarina (FEESC) Caixa Postal 5040 88040-970, Florianopolis (SC) Brazil Phone: +55.48.2334455 FAX: +55.48.3319677 EMAIL: katia@feesc.ufsc.br From rem-conf-request@es.net Sun Oct 31 04:47:58 1999 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24348 for ; Sun, 31 Oct 1999 04:47:57 -0500 (EST) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11hr9i-0004DF-00; Sun, 31 Oct 1999 01:20:06 -0800 Received: from mail.kedah.gov.my (kedah.gov.my) [202.184.166.1] by mail1.es.net with smtp (Exim 1.81 #2) id 11hr9f-0004D3-00; Sun, 31 Oct 1999 01:20:03 -0800 Received: from 202.184.166.1 by kedah.gov.my (SMI-8.6/SMI-SVR4) id RAA00149; Sun, 31 Oct 1999 17:30:22 +0800 From: Publishers-Company@excite.com Message-Id: <199910310930.RAA00149@kedah.gov.my> To: PublishingCompany1@excite.com Date: Sun, 31 Oct 99 01:52:57 EST Subject: Publishing Company for Sale! Reply-To: removeforever1@bigfoot.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list See information about Free Credit Application Below! My Multi-Million Dollar Publishing Company ONLY $149 Free Pre-Approved Merchant Account Application with Order!! To Start Your Business Out Right!! If you ever wanted "the easy way out" to make a lot of money with a business of your own.... Here is the EASIEST WAY TO START! I'm writing this letter to let you in on something that'll blow you away. What I'm about to present is something I've never done before...something that I'll never do again.... So PAY ATTENTION! For the past few years...I've have been running ads in newspapers & magazines, by direct mail, and throughout the internet. These ads were always small and very cheap... On these ads, we have been selling little manuals. These manuals have sold for anywhere between $10 to $99 each. We always ran different ads for each manual we were selling. I like selling information because NOBODY can put a price on it...ESPECIALLY when it is your own...The Sky is the Limit! Plus it is very cheap to reproduce How-To manuals. It costs between 40 cents and $3 to print the entire print manuals and around 35 cents to copy the manuals on disk. AND you can sell them for up to $99 each. That is one hell of a markup! These manuals tell you how to get a car with no money down and no credit...another one tells you how to avoid taxes by depositing income offshore...now you may not be interested in saving money by going offshore...but believe me....there are MILLIONS OF PEOPLE WHO DO...and they are willing to pay me to teach them!!! Well this is where the unbelievable offer comes in...I hope you are sitting down for this one...because this is a once in a lifetime chance for you. I do not know of an easier way to become financially independent...In fact THERE IS NO EASIER WAY!!! The next few paragraphs will reveal everything to you. I am willing to sell you my entire informational product line with FULL REPRINT RIGHTS and complete step-by-step instructions on how to start your mail order information business with very little money. Remember, these are PROVEN WINNERS. If you are stumped on something to sell or if you are having trouble writing a good ad, I have also included an entire book on disk to help you produce KILLER ads! This entire package which I call a Publishing Company in a Box will come on 1 CD containing over 2000 'Hot-Selling' Books, Reports And Manuals ready to print and sell, Sell, SELL! It also will come with a signed letter giving YOU FULL REPRINT RIGHTS allowing you to sell them for as much as you want and however you want. You Can even sell the entire kit to someone else to resale on their own! You also receive copies of KILLER ads which can fill your mailbox with cash! I am not even going to ask you for any of the money either... What you make is yours to keep . In fact...you get to make a ton of money on these manuals for as long as you wish...and you will never have to pay me another red cent in royalties! I am even going to print out and prepare our #1 selling report which contains the secrets of starting and operating your own million dollar mail order business on a shoestring budget so that you will be able to take it down to your local copy shop and be ready to sell it the same day you have received it. Watch out though - one individual is making $30,000 a month on this report alone! (Why - Because you can also include a special report On How to Write Order Pulling Ads that practically force people to whip out their checkbooks and order!) Note: THIS REPORT IS INCLUDED! All I ask for is...$149 and I will include FREE Priority Mail Shipping! Yes, I said $149. There are no zeros missing. Plus if you order before Nov 6, 1999 I will include 4 extra special bonuses... Bonus #1 - "Search Engine Magic" on disk. This report will shoot your web site up to the top of the search engine listings. Other web advertisers are selling this manual for $99 by itself - But I will give it to you for FREE with this package. Bonus #2 - The report "How to Make at least $1,600 a week online...Starting Now!" which is taking the internet by storm will be included absolutely FREE! Bonus #3 - I will include special details about a secret source for creating Your own direct mail leads and how you can get your own mail order business up and running for just a few bucks! Bonus #4 - I also will include a pre-approved application for a merchant account for your business benefit. Taking credit cards will increase your business up to 100%. The normal $195 application fee will be waved with this pre-approved application. But there is one drawback... I am sending this ad to 10,000 other people...and I will only allow 50 kits to be sold. It wouldn't make much sense if I sold this kit to 1,000 or 2,000 people...The market would be saturated with these same manuals... and I don't want to do that. To make sure that the people in this offer get the same results I have...ONLY 50 people can have it for $149.00! Chances are, I will get all 50 within a week's time. So if this is something you are interested in...RUSH me a check or money order for $149.00 TODAY to insure your future business. But, even if you decide to pass this up...Don't sweat it. It's not like I am going to be mad or anything like that. I know I will get my 50 order limit really fast. And anyone who gets their check into me late... I will simply send it back. For only $149.00, I am going to let you have the easiest money you will ever make. The manuals are written, the ads are presented, the advertising plan is laid out, and all you have to do is print them out for pennies and place the ads. Do it today! Rush me your payment of $149.00 right now...and get your very own MILLION DOLLAR publishing company going! You can start with one or two manuals...even the day you receive the package...and then expand to include ALL of them! For $149.00, you have everything you need to make a killing with your very own business. If you want to make real money - then this offer is for you! "I took the report "Search Engine Magic" and sold over 50 copies on disk within 2 weeks! They sold for $99 and I was able to copy them for under 50 cents each. Wait till I start marketing the other products included in this line!!!" Joe Fisher - Internet Marketer To rush order this "MILLION DOLLAR Publishing Company in a Box" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------------- Please send to: Your Name_____________________________________________ Your Address__________________________________________ Your City______________________________________________ State / Zip_____________________________________________ Your Country___________________________________________ Phone #: _____________________________________________ (For problems with your order only. No salesmen will call.) Email Address________________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard, American Express and Discover. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $149.00 Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ [ ] YES! Please rush my Publishing Company in a Box. I understand I have FULL REPRINT Rights and can sell any of the items for whatever price I desire, even the entire kit. [ ] DOUBLE YES! I am ordering before Nov 6, 1999! Please include the extra special bonuses! * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $149.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $149.00! Note - If ordering outside continental US, please add $5 to S&H P.S. Don't forget you will receive 2,000 Manuals, Books, and Reports (Some of which are up to 200 pages each)...all for $149...You have full reprint and resale rights to make as much money as you want without ever paying any royalties whatsoever! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * You have been carefully selected to receive the following as a person obviously interested in this subject based upon your previous internet postings, or visits to one of our affiliate web sites. If you have received this message in error,hitl Reply with the word unsubscribe in the subject. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *