From rem-conf Sun Oct 01 01:40:40 2000 From rem-conf-request@es.net Sun Oct 01 01:40:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13febr-0005Jx-00; Sun, 1 Oct 2000 01:36:35 -0700 Received: from www.sigmatel.it (relay.sigmatel.it) [194.91.230.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 13febp-0005Jn-00; Sun, 1 Oct 2000 01:36:34 -0700 Received: from 207.36.161.230 (tsbrk1-230.gate.net [207.36.161.230]) by relay.sigmatel.it (8.8.5/SCO5) with SMTP id JAA02744; Sun, 1 Oct 2000 09:40:18 +0100 (cet) From: noriyuki@new-prodmail.com Message-Id: <200010010840.JAA02744@relay.sigmatel.it> Subject: Program Your Own Channels Date: Sun, 01 Oct 00 04:28:57 Eastern Daylight Time X-Priority: 3 X-MSMailPriority: Normal Importance: Normal Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OPEN EVERY CHANNEL ON YOUR SATELLITE SYSTEM REGARDLESS OF THE TYPE OR BRAND WHY WASTE $400 - $600 $$$$$$$ BUYING AN AFTER MARKET CARD WHEN THEY AREN'T GUARANTEED TO STAY UP! WHEN YOU CAN PROGRAM YOUR CARD YOURSELF IN AS LITTLE AS 5-10 MIN. Unlock the full Potential of YOUR Satellite System ALL SPORTING EVENTS ALL PAY-PER-VIEWS ALL PREMIUMS ALL NBA ALL NFL FOOTBALL EVERY ADULT CHANNEL EXTRA HIDDEN CHANNELS 100'S OF CHANNELS. EVERY CHANNEL IS UNLOCKED VISIT OUR WEBSITE BELOW FOR MORE INFORMATION http://www.priprod.com/lucas/ From rem-conf Sun Oct 01 15:25:07 2000 From rem-conf-request@es.net Sun Oct 01 15:25:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13frMZ-0003lK-00; Sun, 1 Oct 2000 15:13:39 -0700 Received: from (galaxy.uss-inc.com) [207.114.155.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 13frMY-0003l9-00; Sun, 1 Oct 2000 15:13:38 -0700 Received: from quotepool.com (impacs.bc.ca [209.153.207.2]) by galaxy.uss-inc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TXYB4KR8; Sun, 1 Oct 2000 15:13:25 -0700 X-Mailer: Internet Mail Service [29.5.1754.73] (Solaris; Sparc10) Date: Sun, 01 Oct 2000 15:13:21 X-Accept-Language: en From: To: Subject: save on a 2nd mortgage or refinance... X-References: 0F6FF594D, 0BF817A8A Message-ID: <7fgc66tveml5vru.011020001513@quotepool.com> Content-Type: text/html X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

FREE NO OBLIGATION LOAN QUOTE
YOU COULD SAVE SUBSTANTIALLY!!!

For A Quick Quote Now
Click Here

WE SPECIALIZE IN THESE LOANS

Refinancing
Consolidating Debt
2nd Mortgage
Making Home Improvements

WITHOUT ANY OBLIGATION

COMPARE!
Fill out this 1 minute form and receive a custom quote
>from some of the top loan sources in the country!

SAVE TIME!
Harness the power of the internet by submitting your
information instantly! Your quote is on the way!!

SAVE MONEY!
These companies spend less trying to get your
business, so you save on interest rates!

SATELLITE TV SYSTEM GIVAWAY!
The first 100 complete quote requests will recieve
a free DIGITAL SATELLITE SYSTEM!
(Name, Phone # and Email required fields)


From rem-conf Sun Oct 01 20:24:02 2000 From rem-conf-request@es.net Sun Oct 01 20:24:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fw8c-0001vx-00; Sun, 1 Oct 2000 20:19:34 -0700 Received: from mercury.internetsecure.com [216.98.32.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13fw8b-0001vn-00; Sun, 1 Oct 2000 20:19:33 -0700 Received: from 2RS5dD25f (sdn-ar-001calangP293.dialsprint.net [168.191.247.31]) by mercury.internetsecure.com (8.8.5/8.8.5) with SMTP id XAA22719; Sun, 1 Oct 2000 23:09:45 -0400 (EDT) From: mail.ru@mercury.internetsecure.com DATE: 01 Oct 00 8:20:49 PM Message-ID: SUBJECT: 100 minutes long distance for under a buck! Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Talk to Anyone, Anywhere in the U.S. for Less than a Penny per Minute. With our calling card you'll get the lowest long distance prices anywhere! No connection fees, or any hidden costs of any kind. We can offer this fantastic deal because of our high volume of repeat business. We deliver the highest value in the industry and, best of all, your satisfaction is absolutely guaranteed! For just $39 you get 3910 minutes to call anywhere in the U.S., any time. That's less than a buck for 100 minutes! Don't wait! This is the best deal going from one of America's most dependable telecommunication's companies. For your convenience we accept personal checks, cash, cashiers checks and money orders. CA residents please add 8.25% sales Tax. Mark your order then print the following form and mail to: SMARTEC 1626 N. Wilcox, Suite 590 Hollywood, CA 90028 ___$39 for 3910 minutes ___ $59 for 6000 minutes ___$49 for 4950 minutes ___ $79 for 8300 minutes Ship to: _______________________________________________ Shipping Address: _______________________________________ City: __________________________________________________ State: _________________________________________________ Zip Code: ______________________________________________ Your email: _____________________________________________ Your telephone: _________________________________________ Make all checks payable to: SMARTEC All orders are shipped within 48 hours. To be removed from our future mailing please email list2299@losangeles.usa.com and you will be removed instantly. From rem-conf Sun Oct 01 23:16:59 2000 From rem-conf-request@es.net Sun Oct 01 23:16:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fyrw-0005vn-00; Sun, 1 Oct 2000 23:14:32 -0700 Received: from research.gate.nec.co.jp [202.247.6.217] by mail1.es.net with esmtp (Exim 1.81 #2) id 13fyru-0005vc-00; Sun, 1 Oct 2000 23:14:30 -0700 Received: from luke.dsp.cl.nec.co.jp (root@luke.dsp.cl.nec.co.jp [10.56.47.3]) by research.gate.nec.co.jp (8.9.3+3.2W/000323) with ESMTP id PAA08200; Mon, 2 Oct 2000 15:14:26 +0900 (JST) Received: from kero (dhcp021.dsp.cl.nec.co.jp [10.56.44.21]) by luke.dsp.cl.nec.co.jp (8.9.1b+Sun/CL-000424) with SMTP id PAA08365; Mon, 2 Oct 2000 15:14:23 +0900 (JST) Message-ID: <010601c02c38$01841d00$152c380a@dsp.cl.nec.co.jp> From: "Toshiyuki Nomura" To: "John Lazzaro" Cc: , References: <200009251800.LAA05183@snap.CS.Berkeley.EDU> Subject: Re: LATM specified in a public MPEG document? Date: Mon, 2 Oct 2000 15:14:20 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear John and members, As you pointed out, it seems difficult to transmit SA data by LATM. I have forwarded this issue to MPEG Audio Experts and have not been received any objections. Therefore, I'll modify the I/D text so that SA data MUST NOT be handled by the LATM-based RTP specification, following the suggestion below: John Lazzaro wrote: > it sounds like the earlier suggestions I > made on the draft-ietf-avt-rtp-mpeg4-es-04.txt document about > Structured Audio issues, which made it into the current draft, > are inappropriate, since they assume the header described in > "4.1 RTP Packet Format" is meant for all audio, not only > "natural" audio. Perhaps the I-D should simply state that > Structured Audio isn't currently transportable over any of > the packet formats described in the document. The modified text will be published as draft-ietf-avt-rtp-mpeg4-es-05.txt. Best Regards, Toshiyuki Nomura, NEC ---------------------- From rem-conf Mon Oct 02 03:26:48 2000 From rem-conf-request@es.net Mon Oct 02 03:26:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g2kE-0002oN-00; Mon, 2 Oct 2000 03:22:50 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13g2kC-0002oD-00; Mon, 2 Oct 2000 03:22:48 -0700 Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id DAA11071 for ; Mon, 2 Oct 2000 03:21:58 -0700 (PDT) Message-Id: <4.3.1.1.20001002024141.00baf550@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 03:21:53 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: Announcing: An open-source library for RTP/RTCP streaming Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [This is something that I've been promising people for a long time. I'm pleased to report that I finally have it in a releasable state. (Not perfect, but releasable..)] The C++ source code that forms the basis of my "liveCaster" (& "playRTPMPEG") media streaming tools is now available as "open source" (released under the LGPL). This code forms a set of libraries that can be used within RTP/RTCP streaming applications, and/or can be extended to support additional media types and codecs (in addition to MP3 audio). For a description of these libraries, and instructions for how to install and build them, see . You can use this code right now to build real applications - in fact, the distribution includes code for building two demo applications: (i) a server that reads a MP3 file and streams it (using RTP/RTCP), and (ii) a client that reads from the same RTP/RTCP stream, and outputs the resulting MP3 stream to stdout. These libraries can be built and run on Unix (various flavors) and Windows. (However, the demo applications mentioned above don't yet compile on Windows.) These libraries are similar to existing toolkits such as "Open Mash", although - for now, at least - not nearly as rich in functionality. Also, they do not require the use of a specific scripting language - or any scripting language at all. (However, the libraries can, and have, been used with scripting languages - e.g., "liveCaster" and "playRTPMPEG" were built using these libraries in combination with Tcl.) Once again, the URL for this code is . Ross. From rem-conf Mon Oct 02 06:19:01 2000 From rem-conf-request@es.net Mon Oct 02 06:19:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g5Mq-0006bG-00; Mon, 2 Oct 2000 06:10:52 -0700 Received: from olympus.noc.uoa.gr [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g5Mn-0006ay-00; Mon, 2 Oct 2000 06:10:50 -0700 Received: from Aragorn (Aragorn.noc.uoa.gr [195.134.90.37]) by olympus.noc.uoa.gr (8.10.2/8.10.2) with SMTP id e92DAfE25924 for ; Mon, 2 Oct 2000 16:10:41 +0300 (EET DST) Message-ID: <013501c02c71$9aa4ebc0$255a86c3@noc.uoa.gr> From: "Nikos Laoutaris" To: Subject: video frame arrival traces Date: Mon, 2 Oct 2000 16:06:40 +0300 Organization: University of Athens, Networks Operation Center MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C02C8A.BFC8F0E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C02C8A.BFC8F0E0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear list members I am searching for traces of interarrival distributions or (better) = one-way delay distributions of streaming video, at the frame level. That = is, i would like to have a real measurement of the distortion of = interstream synchronization of a series of equally spaced frames (at the = source) as they travel over a (multi hop) network path. This information = is to be used for the evaluation of an adaptive playout controller for = packet video receivers. Thanking you in advance Nikos Laoutaris Communication Networks Laboratory National and Kapodestrian University of Athens, Greece e-mail : laoutaris@noc.uoa.gr tel. : +301 7275603 fax : +301 7275601 ------=_NextPart_000_0132_01C02C8A.BFC8F0E0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear list members
 
    I am searching for traces of = interarrival distributions or (better) one-way delay distributions of = streaming=20 video, at the frame level. That is, i would like to have a real = measurement of=20 the distortion of interstream synchronization of a series of = equally=20 spaced frames (at the source) as they travel over a = (multi hop)=20 network path. This information is to be used for the evaluation of an = adaptive=20 playout controller for packet video receivers.
 
Thanking you in advance
 
Nikos Laoutaris
Communication Networks=20 Laboratory
National and Kapodestrian University of Athens, = Greece
e-mail :=20 laoutaris@noc.uoa.gr
tel. = : +301=20 7275603
fax : +301 7275601
------=_NextPart_000_0132_01C02C8A.BFC8F0E0-- From rem-conf Mon Oct 02 06:35:56 2000 From rem-conf-request@es.net Mon Oct 02 06:35:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g5jO-00006b-00; Mon, 2 Oct 2000 06:34:10 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g5jI-00006R-00; Mon, 2 Oct 2000 06:34:04 -0700 Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e92DY1t24002; Mon, 2 Oct 2000 15:34:01 +0200 (MEST) Received: from era.ericsson.se (rcur34ip54.ericsson.se [147.214.34.54]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA26659; Mon, 2 Oct 2000 15:34:00 +0200 (MET DST) Message-ID: <39D88E7D.DFCD1BC7@era.ericsson.se> Date: Mon, 02 Oct 2000 15:32:45 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, The payload format is designed with IP networks in mind. The problem we see is that IP is transported over a wide range of different links with different behavior, e.g. different radio and wireline links. Radio and wire do not have the same error characteristics. AMR will be widly used over wireless links and on these links bandwidth efficiency is extremely important. This lead to the bitwise sorting. Octet sorting needs octet alignement for each block of the payload, i.e. padding at the end of each block. Which we considered to be to expensive. The optional sensitivity sorting facilitates the use of different error robustness schemes. The need for different robustness enhancing schemes may depend on the application and the lower transport layers. The application can be for example conversational speech or streaming. Lower layers are here layer 1 and 2. Regards Magnus W. Qiaobing Xie wrote: > Magnus, > > Correct me if I am wrong, but I find hard to understand your reasoning. > > What you are saying is basically that, in order to make the current > payload format design general enough and flexible enough to be used "for > a wide range of networks and applications" and with "any mechanism that > exploit" unequal bit sensitivity, you've chosen to compromise the > implementation efficiency and performance (and even some functionality) > for AMR over RTP/whatever-partial-checksum-UDP/IP. > > I think it should be the other way around - the AMR payload design > should primarily focus on finding the optimal solution for > AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design > something that is meant for a wide range of networks but is > suboptimal/compromised (even functionally handicapped) for IP networks. > > Regards, > -Qiaobing Xie > > Magnus Westerlund wrote: > > > > Dear Qiaobing, everyone, > > > > The unequal error protection/correction scheme is not designed just for > > UDP-Lite. Any mechanism that can exploit the fact that the data is > > sorted in sensitivity order is possible to use, e.g. a partial FEC > > scheme based on the same techniques as RFC2733. > > > > We have made some design choices that makes the payload format flexible > > and bit efficient, i.e. usefull for a wide range of networks and > > applications. > > > > Best regards > > > > Magnus Westerlund > > > > Qiaobing Xie wrote: > > > > > Hello, everyone: > > > > > > I have some serious concerns on the design of the AMR payload format as > > > defined in . In brief, the design seems > > > very limiting in terms of taking advantage of the error tolerant > > > features built into the AMR codec algorithm. Also, it seems that not > > > enough consideration has been given to implemenation efficiency and > > > performance. > > > > > > Since my concerns are rather fundamental to the design, the email is a > > > little long, please bear with me.. > > > > > > 1) Basic idea > > > > > > The basic idea of the draft is to transport AMR frames over IP in an RTP > > > payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that. > > > > > > Therefore, the packet *passed to the UDP layer* will contain three types > > > of bits: > > > > > > +--------------+ > > > | header bits | > > > +--------------+ > > > | Class A bits | > > > | and/or | > > > | other bits | > > > +--------------+ > > > > > > Here, the "header bits" will include all the AMR speech frame control > > > bits (ie., frame header), the RTP payload header bits, and the RTP > > > header bits. > > > > > > "Class A bits" is the most sensitive coded speech data bits, as defined > > > by the AMR codec. The "other bits" (also called Class B and C bits in > > > AMR terminology) are less sensitive coded speech data bits. > > > > > > 2) Problems with the current AMR payload format design > > > > > > The design in the current draft apparently was guided under the > > > misconception that the "Class A bits" of an AMR speech frame need to be > > > delivered error-free, and if that part of the frame is corrupted the > > > whole frame should be tossed. This is not correct. > > > > > > What the AMR codec really wants from the transport is: "if Class A bits > > > is found corrupted in a frame, raise a Bad Frame flag but still pass the > > > whole frame to the decoder since the decoder still may want to use Class > > > B and C bits to help error concealment." The purpose of the flag is to > > > tell the decoder that Class A bits are bad and do not use them. > > > > > > However, the draft seems to suggest on the use of a partial checksum > > > (such as the one provided by the proposed UDP-lite) to protect the > > > "header bits" AND the "Class A bits" at the transport leverl. This means > > > if Class A bits have any error, the whole packet will be tossed by the > > > transport. Even worse, if the packet is a compound payload, you will > > > have all the AMR frames tossed by the transport if a bit error occurs in > > > the Class A bits of any one of the enclosed frames. > > > > > > It becomes more problematic when, in order to support multiple AMR > > > frames in a compound RTP payload and to use > > > the partial checksum, a *very ugly* bit-wise shuffling scheme is > > > proposed to copy (bit by bit) all the "Class A bits" of each enclosed > > > AMR speech frame to the front of the packet!! The hugely computational > > > intensive operation is required no each RTP packet on both ends of the > > > RTP session. > > > > > > 3) A better way to do it: > > > > > > To get what AMR codec wants, we should only checksum the "header bits", > > > and carry an 8-bit CRC in the AMR frame header to cover the "Class A > > > bits" of the frame. This CRC is for the RTP receiver (that is above the > > > transport) to verify the integrity of the Class A bits and to raise the > > > Bad Frame flag before passing the AMR frame to the decoder. > > > > > > In other words, > > > > > > 1. Partial checksum at the transport level to cover all the "header > > > bits" -- if checksum fails, toss the whole packet. > > > 2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails, > > > raise the bad frame flag. > > > 3. No error checking on the "other bits". > > > > > > When bundling multiple AMR frames in one RTP packet (the compound > > > payload), we should use a table of contents (TOC) structure to avoid > > > bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then > > > use the transport level checksum to cover the header bits and TOC bits > > > only (the Class A CRC of each AMR frame is in the TOC). > > > > > > +------------------+ > > > | RTP header bits | -- RTP and payload headers > > > +------------------+ > > > | Table of Contents| -- list of frame headers of the > > > +==================+ \ included AMR frames > > > | Fmr1 Cls A bits | \ > > > +------------------+ | > > > | Fmr1 Cls B bits | | > > > +------------------+ | > > > | Fmr1 Cls C bits | | > > > +==================+ | > > > | Fmr2 Cls A bits | > not covered by transport level chksum > > > +------------------+ | > > > | Fmr2 Cls B bits | | > > > +------------------+ | > > > | Fmr2 Cls C bits | | > > > +==================+ | > > > | Fmr3 Cls A bits | / > > > +------------------+ / > > > ..... > > > ..... > > > > > > This way, you get what the AMR codec asks for and yet avoid bit-wise > > > copying. > > > > > > =============================================================== > > > Qiaobing Xie, Ph.D > > > Principal Staff Engineer > > > Network Architecture & Technology > > > Motorola, Inc. > > > TEL: (847) 632-3028 > > > =============================================================== > > > > -- > > > > Magnus Westerlund > > > > Audio Technology, Ericsson Research > > ---------------------------------------------------------------------- > > Ericsson Radio Systems AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se -- Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf Mon Oct 02 10:10:37 2000 From rem-conf-request@es.net Mon Oct 02 10:10:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g93U-0004dA-00; Mon, 2 Oct 2000 10:07:08 -0700 Received: from audrey.enst-bretagne.fr [192.108.115.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g93S-0004Zv-00; Mon, 2 Oct 2000 10:07:06 -0700 Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e92H3Ro39908; Mon, 2 Oct 2000 19:03:31 +0200 Received: from pchoukair (pchoukair.enst-bretagne.fr [192.44.75.57]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id TAA07126; Mon, 2 Oct 2000 19:02:59 +0200 (MET DST) From: ddma-announcement@enst-bretagne.fr Message-Id: <3.0.3.32.20001002185642.00989790@antares.enst-bretagne.fr> X-Sender: choukair@antares.enst-bretagne.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 02 Oct 2000 18:56:42 +0200 To: ddma@enst-bretagne.fr Subject: DDMA workshop CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_970498602==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_970498602==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague, You are invited to submit a paper to the International "Distributed Dynamic Multiservice Architectures" (DDMA) Workshop. This workshop is in conjunction with the 21st International Conference on Distributed Computing Systems (ICDCS2001), one of the major conferences in the Distributed Computing Systems Area. DDMA workshop covers aspects concerning adaptive architectures and service composition and management. The submission deadline is November 1st. Further details are at the web site http://ddma.enst-bretagne.fr/. A text version is also in attachment. The DDMA workshop will be held in Phoenix, Arizona; April 16-19, 2001. [We apologize if you receive multiple copies of this announcement] --=====================_970498602==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ddma-cfp.txt" Call for Papers International Workshop on Distributed Dynamic Multiservice Architectures http://ddma.enst-bretagne.fr/ in conjunction with ICDCS2001 sponsored by IEEE Computer Society April 16 =96 19, 2001 Phoenix, Arizona, USA The growing need to integrate new services while complying with the= requirements of end=20 users puts strong emphasis on the management and combination of future= services and the QoS=20 they should be able to provide and guarantee. Dynamic Multiservice= Architectures constitute a=20 challenging paradigm for distribution theory and practice due to their= unique requirements in terms=20 of adaptability, behavioural integration, separation of concerns, service= composition and service=20 management. In particular, the deployment of multimedia telecommunication= services is a highly=20 challenging area where those paradigms should apply because advanced= services require that the=20 user's profiles, preferences and context be taken into account. "Distributed= Dynamic=20 Multiservice Architectures" hence add a new dimension to distributed= computing to help the=20 composition and deployment of new services guaranteeing final user's= requirements. The goals of this workshop are to bring together users and researchers to= present their=20 recent work related to diverse aspects of dynamic multiservice= architectures, their fundamental=20 issues, their paradigms and some appropriate approaches and experiments. The= workshop will=20 thus present opportunities for discussing further evolutions and their= expected benefits. Scope of Workshop ----------------- The scope of this workshop encompasses but is not limited to : Evolution of distributed multiservice architectures Separation of aspects and composition of aspects. Methodological approaches for aspect oriented programming. Components as cornerstones for dynamic composition. Composition requirements for reflection. Auto-adaptive ad hoc architectures and protocols. Impact on the management and control Management of adaptive architectures Management and monitoring of composed services. Platforms, tools, languages, ...=20 Languages, tools and platforms for auto-adaptive systems. Environments for specification and design of dynamic architectures. Experience with design, implementation and use of auto-adaptive systems. Application to telecommunication services Open critical issues in terms of composition of services. Panorama of QoS integration approaches for multimedia telecom services. Paradigms and requirements for telecom services architectures. Architectures for 3rd generation multimedia services. Distribution protocols for telecom (WAP, CORBA, CAMEL, mobile agents). Submission Instructions and Workshop Format ------------------------------------------- Interested participants should submit a 4-8 pages position paper that= focuses on one of the=20 relevant topics or related issues. Papers will be reviewed by the program= committee. Electronic=20 submissions should be sent to zied.choukair@enst-bretagne.fr. Mail body= should include name,=20 address, affiliation and a brief biography along with paper's title and= abstract. The workshop will follow the following format: The morning and part of the= afternoon will=20 be dedicated to presentations and discussions of accepted proposals,= including demonstrations of=20 existing software. The afternoon session will end with an identification of= issues, followed by=20 discussion. The organisers will then elaborate a summary of the workshop= based upon a summary=20 of the papers and the major outlined points of the discussion. Program Committee Members : Mehmet Aksit, Twente University, NL Zi=E8d Choukair, ENST Bretagne, FR Jaime Delgado, Universitat Pompeu Fabra, ES Byung-Guk Kim, University of Massachusetts Lowell, USA Marwan Krunz, University of Arizona, USA Abdul H. Sadka, University of Surrey, GB Antonio Rito Silva, University of Lisbon, PT Timothy K. Shih, Tamkang University, TW Katsuya Tanaka, Tokyo Denki University, JP Important Dates : Paper submission due : Nov 1, 2000 Notification : Dec 30, 2000 Camera ready : Jan 20, 2001 Conference : April 16-19, 2001 Web Pages : Conference URL : http://cactus.eas.asu.edu/ICDCS2001/ --=====================_970498602==_-- From rem-conf Mon Oct 02 11:35:17 2000 From rem-conf-request@es.net Mon Oct 02 11:35:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gANV-00077q-00; Mon, 2 Oct 2000 11:31:53 -0700 Received: from hum.cari.net [209.126.133.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gANU-00077g-00; Mon, 2 Oct 2000 11:31:52 -0700 Received: (from httpd@localhost) by hum.cari.net (8.9.3/8.9.3) id LAA31236; Mon, 2 Oct 2000 11:32:18 -0700 Date: Mon, 2 Oct 2000 11:32:18 -0700 Message-Id: <200010021832.LAA31236@hum.cari.net> To: rem-conf@es.net Subject: ADV: Free Search Engine Placement Report - Get Yours Today From: "Doug Solomon" Organization: the Ad Network X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Comments: This advertisement is brought to you by the Ad Network Comments: www.adnetwork.cc Comments: Specialists in Inter-Networking and Promotions. Comments: Removal Instructions in plain text following message. X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ****************************************************************************** Complete list REMOVAL instructions outlined below message. ****************************************************************************** F R E E R E P O R T Is your website at the top of the major search engines? It needs to be! If it is not, you are missing out on serious amounts of web traffic and business! Did you know that 85% of web traffic originates from search engines? AND did you know that 98.2% of searches do NOT go past the third page of search results? (from the GVU 10th WWW User survey, Oct-Dec 1999) As a means of introduction we are offering you FREE a one time, no obligation, report of your website`s rank on the major search engines. You must know whether or not your website is achieving top rank on the major search engines. If you are not within the first 30 results you loose a distinct advantage over your competition. Obviously the higher the better. Click the link below and find out immediately if your website has the ranking that will make you money. http://www.adnetwork.cc/search-engine-free-report.htm If you have any questions or comments either before or after you have received your free report, please don`t hesitate to write us at info@adnetwork.cc Thank you for your time Your search engine Placement Specialists http://www.adnetwork.cc Creating Positive Solutions for Your Internet Business We apologies if you are not interested in internet traffic building technologies. E-mail is the fastest method of distributing this type of timely business information. If you wish to have your e-mail address removed from our business information update data base simply click on the hyperlink below: http://www.adnetwork.cc/removal.htm This message is being sent to you in compliance with the Federal legislation for commercial e-mail (S.1618-SECTION 301) This letter is not considered spam as long as we include contact information and a remove link. Doug Solomon Inter-Networking Promotions Specialist ****************************************************************************** Removal Instructions To unsubscribe from the Ad Network (www.adnetwork.cc) emailing list, please browse to the following URL: https://marketing.adnetwork.cc/removal.htm This page is secured by a 40 bit SSL Encryption for your protection and email privacy. You may list as many emails you wish to be removed from this and all sequent messages. We keep an extensive and complete database of removes that is cross referenced before any new promotions are broadcast. You may also email with "UNSUBSCRIBE" in the Subject Line: removes@adnetwork.cc This email is in complete compliance to Opt-Out mailing practices as stated in the Rules under California Business & Professions Code Section 17538.45 ****************************************************************************** From rem-conf Mon Oct 02 15:51:28 2000 From rem-conf-request@es.net Mon Oct 02 15:51:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gEF6-0004qZ-00; Mon, 2 Oct 2000 15:39:28 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gEF4-0004qP-00; Mon, 2 Oct 2000 15:39:27 -0700 Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA10539; Tue, 3 Oct 2000 00:38:48 +0200 (MET DST) Message-ID: <39D90E55.217B38D@fokus.gmd.de> Date: Tue, 03 Oct 2000 00:38:13 +0200 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kuthan@fokus.gmd.de Subject: iptel2001 Call for Papers Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id AAA10539 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers 2nd IP Telephony Workshop =20 April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ----------=20 Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service=20 providers active in this area and stimulate discussion on=20 innovation, research, implementation, deployment experiences and future directions. Scope & Topics=20 -------------- Original technical articles related to IP telephony are solicited.=20 Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms,=20 architectures, measurements, theoretical and/or analytical=20 contributions)=20 - Surveys, state-of-the-art studies, technology comparisons=20 - Implementation and deployment reports=20 - Standardization reports=20 Particular areas of interest include, but are not limited to, the following:=20 - Integration with Internet services (e.g., web, instant=20 messaging, games)=20 - Added-value services (e.g., call centers, conferencing)=20 - Mobility and 3rd generation wireless=20 - Authentication, authorization, accounting, charging,=20 settlement - QoS support=20 - Security (e.g., privacy, authentication, certification=20 authorities, firewall traversal)=20 - Call signaling & processing=20 - Feature creation=20 - Supporting services (e.g., call routing, lookup services)=20 - Audio & video encoding and transmission=20 - Management and provisioning=20 - Interworking with the PSTN=20 - Design and deployment considerations (e.g., performance,=20 scalability, reliability)=20 Important Dates ---------------=20 Full paper due November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee=20 ------------------------------ Program Chair =20 H. Schulzrinne Columbia University=20 Program Committee=20 M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research K. Mehdi University of Kansas D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. St=FCttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig=20 Submission Instructions=20 ----------------------- Authors are invited to submit full papers written in English=20 before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for=20 submission of camera-ready copies is January 31st, 2001. Authors=20 of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry.=20 Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents=20 cannot be accepted. Postscript papers must use only standard=20 PostScript fonts: Times Roman, Courier, Symbol, and Helvetica.=20 Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are=20 available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/=20 Because of the size limitation on the final manuscript, and to=20 ensure that the reviewed paper and the final version have a=20 similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract,=20 list of keywords, and contact information. One of the authors of=20 each accepted paper must present the paper at iptel'2001.=20 Contact Address --------------- Please, send all your inquiries regarding iptel2001 to=20 iptel2001@egroups.com. From rem-conf Mon Oct 02 16:39:34 2000 From rem-conf-request@es.net Mon Oct 02 16:39:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gF91-0006v3-00; Mon, 2 Oct 2000 16:37:15 -0700 Received: from (hhrhk.robertson.com.hk) [202.64.226.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gF8w-0006te-00; Mon, 2 Oct 2000 16:37:10 -0700 Received: from 202.64.226.2 (cranston-ip-1-238.dynamic.ziplink.net [209.206.4.238]) by hhrhk.robertson.com.hk (8.7.5/8.6.9) with SMTP id KAA18326; Tue, 3 Oct 2000 10:29:00 +0800 From: dont8@planet-mail.com Message-Id: <200010030229.KAA18326@hhrhk.robertson.com.hk> Date: Mon, 02 Oct 00 18:20:06 EST To: jhzk9@2s31hg.com Subject: They All Laughed at Me X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Now I am the one laughing! THE PROGRAM $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ INCREDIBLE $0 to $50,000 in 90 days!!! Dear Friend, You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. "AS SEEN ON NATIONAL TV" 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 have 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 $50,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 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram 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 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump 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!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to 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 10,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, my 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 made 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 $50,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 $50,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 10,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 and 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 $50,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. It really 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 in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke 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 thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...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 $50,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. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it 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 4 reports shown on the list below (you can't sell them if youdon'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 four reports. You will need all four 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 four 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 "f" 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 four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, 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 $20). You obviously already have an Internet connection and e-mail is FREE! 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.5% 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.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 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 justthat, 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 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. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 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 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 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. CHECKS 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: Becki Owens 30 Sea Star Court Dana Point, CA 92629 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Kristin Butler 32 McCullough Rd. Cody, WY 82414 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: ADRP10 PO Box 7794 Athens, GA 30604-7794 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: P. Drucker 1517A Rolling Glen Rd. Boothwyn, PA 19061 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- 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, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at derr9@goplay.com ///////////////////////////////////////////////////////////////// From rem-conf Mon Oct 02 16:50:39 2000 From rem-conf-request@es.net Mon Oct 02 16:50:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gFKY-0000NX-00; Mon, 2 Oct 2000 16:49:10 -0700 Received: from (motgate3.mot.com) [144.189.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gFKS-0000NI-00; Mon, 2 Oct 2000 16:49:05 -0700 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA12805; Mon, 2 Oct 2000 16:46:23 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA09556; Mon, 2 Oct 2000 16:47:15 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id SAA02874; Mon, 2 Oct 2000 18:48:51 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id SAA16501; Mon, 2 Oct 2000 18:48:51 -0500 (CDT) Message-Id: <200010022348.SAA16501@agevole.cig.mot.com> Date: Mon, 02 Oct 2000 18:49:07 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: Qiaobing Xie , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Magnus, See my comments below.... Magnus Westerlund wrote: > > Hello, > > The payload format is designed with IP networks in mind. The problem we see is > that IP is transported over a wide range of different links with different > behavior, e.g. different radio and wireline links. Radio and wire do not have > the same error characteristics. AMR will be widly used over wireless links and > on these links bandwidth efficiency is extremely important. This lead to the > bitwise sorting. Octet sorting needs octet alignement for each block of the > payload, i.e. padding at the end of each block. Which we considered to be to > expensive. This further convinces me that the current design presented in the AMR draft is a radio-link-centric design, which is wrong in my opinion, because: 1) bandwidth efficiency over wireless links is more of a concern for ROHC working group. Architecturally, it should be delt with below IP by header compression/stripping, as being worked upon in rohc. It doesn't belong to RTP payload layer (unless it is something facilitating the underlying header compression/stripping). 2) AMR itself is not specfic to radio links, it is a general purpose codec. It is in the best interest of the AVT working group to define a *general* RTP payload format for carrying AMR speech over any IP connection, not something optimized for radio links only. This is why I am against the bitwise sorting - it may be inevitable for a radio link (even for radio links, it is expensive and often done at a lower layer by DSP or with hardware assistance), but it is a magnitude more expensive than byte-oriented handling to most applications running on a general purpose machine. > The optional sensitivity sorting facilitates the use of different > error robustness schemes. The need for different robustness enhancing schemes > may depend on the application and the lower transport layers. The application > can be for example conversational speech or streaming. Lower layers are here > layer 1 and 2. Since the bitwise sorting is so expensive, I think it is more than necessary that you justify it by showing exactly what "robustness echancing schemes" you have in mind and exactly how they would work together. Here you also brought out another concern of mine: the current design put no consideration on frame quality classification support (you would need CRC and bad frame indicator to do so, as I pointed out in my original email). Is this because you assume those functions are provided by "the lower transport layers", such as by the Iu-UP protocols defined in 3GPP? Unfortunately, in a general IP network, there is no such support from the transport layer. In order to make the AMR over IP work effectively over any IP connections (not only for a 3GPP Iu-UP interface), you will need to support those functions in your RTP payload format. regards, -Qiaobing > > Regards > > Magnus W. > > Qiaobing Xie wrote: > > > Magnus, > > > > Correct me if I am wrong, but I find hard to understand your reasoning. > > > > What you are saying is basically that, in order to make the current > > payload format design general enough and flexible enough to be used "for > > a wide range of networks and applications" and with "any mechanism that > > exploit" unequal bit sensitivity, you've chosen to compromise the > > implementation efficiency and performance (and even some functionality) > > for AMR over RTP/whatever-partial-checksum-UDP/IP. > > > > I think it should be the other way around - the AMR payload design > > should primarily focus on finding the optimal solution for > > AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design > > something that is meant for a wide range of networks but is > > suboptimal/compromised (even functionally handicapped) for IP networks. > > > > Regards, > > -Qiaobing Xie > > > > Magnus Westerlund wrote: > > > > > > Dear Qiaobing, everyone, > > > > > > The unequal error protection/correction scheme is not designed just for > > > UDP-Lite. Any mechanism that can exploit the fact that the data is > > > sorted in sensitivity order is possible to use, e.g. a partial FEC > > > scheme based on the same techniques as RFC2733. > > > > > > We have made some design choices that makes the payload format flexible > > > and bit efficient, i.e. usefull for a wide range of networks and > > > applications. > > > > > > Best regards > > > > > > Magnus Westerlund > > > > > > Qiaobing Xie wrote: > > > > > > > Hello, everyone: > > > > > > > > I have some serious concerns on the design of the AMR payload format as > > > > defined in . In brief, the design seems > > > > very limiting in terms of taking advantage of the error tolerant > > > > features built into the AMR codec algorithm. Also, it seems that not > > > > enough consideration has been given to implemenation efficiency and > > > > performance. > > > > > > > > Since my concerns are rather fundamental to the design, the email is a > > > > little long, please bear with me.. > > > > > > > > 1) Basic idea > > > > > > > > The basic idea of the draft is to transport AMR frames over IP in an RTP > > > > payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that. > > > > > > > > Therefore, the packet *passed to the UDP layer* will contain three types > > > > of bits: > > > > > > > > +--------------+ > > > > | header bits | > > > > +--------------+ > > > > | Class A bits | > > > > | and/or | > > > > | other bits | > > > > +--------------+ > > > > > > > > Here, the "header bits" will include all the AMR speech frame control > > > > bits (ie., frame header), the RTP payload header bits, and the RTP > > > > header bits. > > > > > > > > "Class A bits" is the most sensitive coded speech data bits, as defined > > > > by the AMR codec. The "other bits" (also called Class B and C bits in > > > > AMR terminology) are less sensitive coded speech data bits. > > > > > > > > 2) Problems with the current AMR payload format design > > > > > > > > The design in the current draft apparently was guided under the > > > > misconception that the "Class A bits" of an AMR speech frame need to be > > > > delivered error-free, and if that part of the frame is corrupted the > > > > whole frame should be tossed. This is not correct. > > > > > > > > What the AMR codec really wants from the transport is: "if Class A bits > > > > is found corrupted in a frame, raise a Bad Frame flag but still pass the > > > > whole frame to the decoder since the decoder still may want to use Class > > > > B and C bits to help error concealment." The purpose of the flag is to > > > > tell the decoder that Class A bits are bad and do not use them. > > > > > > > > However, the draft seems to suggest on the use of a partial checksum > > > > (such as the one provided by the proposed UDP-lite) to protect the > > > > "header bits" AND the "Class A bits" at the transport leverl. This means > > > > if Class A bits have any error, the whole packet will be tossed by the > > > > transport. Even worse, if the packet is a compound payload, you will > > > > have all the AMR frames tossed by the transport if a bit error occurs in > > > > the Class A bits of any one of the enclosed frames. > > > > > > > > It becomes more problematic when, in order to support multiple AMR > > > > frames in a compound RTP payload and to use > > > > the partial checksum, a *very ugly* bit-wise shuffling scheme is > > > > proposed to copy (bit by bit) all the "Class A bits" of each enclosed > > > > AMR speech frame to the front of the packet!! The hugely computational > > > > intensive operation is required no each RTP packet on both ends of the > > > > RTP session. > > > > > > > > 3) A better way to do it: > > > > > > > > To get what AMR codec wants, we should only checksum the "header bits", > > > > and carry an 8-bit CRC in the AMR frame header to cover the "Class A > > > > bits" of the frame. This CRC is for the RTP receiver (that is above the > > > > transport) to verify the integrity of the Class A bits and to raise the > > > > Bad Frame flag before passing the AMR frame to the decoder. > > > > > > > > In other words, > > > > > > > > 1. Partial checksum at the transport level to cover all the "header > > > > bits" -- if checksum fails, toss the whole packet. > > > > 2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails, > > > > raise the bad frame flag. > > > > 3. No error checking on the "other bits". > > > > > > > > When bundling multiple AMR frames in one RTP packet (the compound > > > > payload), we should use a table of contents (TOC) structure to avoid > > > > bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then > > > > use the transport level checksum to cover the header bits and TOC bits > > > > only (the Class A CRC of each AMR frame is in the TOC). > > > > > > > > +------------------+ > > > > | RTP header bits | -- RTP and payload headers > > > > +------------------+ > > > > | Table of Contents| -- list of frame headers of the > > > > +==================+ \ included AMR frames > > > > | Fmr1 Cls A bits | \ > > > > +------------------+ | > > > > | Fmr1 Cls B bits | | > > > > +------------------+ | > > > > | Fmr1 Cls C bits | | > > > > +==================+ | > > > > | Fmr2 Cls A bits | > not covered by transport level chksum > > > > +------------------+ | > > > > | Fmr2 Cls B bits | | > > > > +------------------+ | > > > > | Fmr2 Cls C bits | | > > > > +==================+ | > > > > | Fmr3 Cls A bits | / > > > > +------------------+ / > > > > ..... > > > > ..... > > > > > > > > This way, you get what the AMR codec asks for and yet avoid bit-wise > > > > copying. > > > > > > > > =============================================================== > > > > Qiaobing Xie, Ph.D > > > > Principal Staff Engineer > > > > Network Architecture & Technology > > > > Motorola, Inc. > > > > TEL: (847) 632-3028 > > > > =============================================================== > > > > > > -- > > > > > > Magnus Westerlund > > > > > > Audio Technology, Ericsson Research > > > ---------------------------------------------------------------------- > > > Ericsson Radio Systems AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > -- > > Magnus Westerlund > > Audio Technology, Ericsson Research > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf Mon Oct 02 18:42:01 2000 From rem-conf-request@es.net Mon Oct 02 18:42:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gH0z-0003zP-00; Mon, 2 Oct 2000 18:37:05 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gH0r-0003yK-00; Mon, 2 Oct 2000 18:36:58 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id KAA18910; Tue, 3 Oct 2000 10:36:21 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id KAA19861; Tue, 3 Oct 2000 10:36:21 +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 KAA17654; Tue, 3 Oct 2000 10:36:19 +0900 (JST) Received: from ave (kwa0106.mobile.toshiba.co.jp [133.120.199.22]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id KAA90983; Tue, 3 Oct 2000 10:36:08 +0900 (JST) Message-ID: <024601c02cda$592eb5e0$16c77885@ave> From: "Yoshihiro Kikuchi" To: "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 10:36:25 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0243_01C02D25.C7F165E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0243_01C02D25.C7F165E0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear experts, Attached find please a draft text for the revision of MPEG-4 Audio/Visual RTP Internet-Draft. The revisions are mostly to reflect suggestions by the AVT chair. Most of them are editorial and there are some minor revisions and clarifications. The following is a summary of the changes: (1) MIME subtype names were changed to "video/MP4V-ES" for video and "audio/MP4A-LATM" for audio. (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short video header mode was changed to "MAY" to "SHOULD". (3) Clarification of timestamp definition There was a suggestion not to describe the detailed definition of the video timestamp in the RTP spec. and change it as a reference to MPEG-4 visual document, so as to keep consistency with the MPEG-4 visual. A description about the RTP timestamp in the RTCP SR packet was added. (4) SA/TTSI over LATM A description was added to restrict the LATM usage so as not to transmit SA data by LATM. (5) Other editorial and wording changes. Please let us know if there is comment on the attached draft. The authors need to submit it soon as an updated I-D and hopefully final before RFC. Best regards, Yoshihiro Kikuchi and authors of the Internet Draft ---- 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 1267 ------=_NextPart_000_0243_01C02D25.C7F165E0 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-es-05-Sep29.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-05-Sep29.txt" Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-05.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT September 29, = 2000 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 carrying each of = MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For = the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields = and also specifies fragmentation rules. It also provides specifications = for MIME type registrations and the use of SDP. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 1. Introduction The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented = and mapped directly onto RTP packets. These RTP payload formats enable transport of MPEG-4 Audio/Visual = streams without using the synchronization and stream management functionality = of MPEG-4 Systems [6]. Such RTP payload formats will be used in systems = that have intrinsic stream management functionality and thus require no = such functionality from MPEG-4 Systems. H.323 terminals are an example of = such a systems, where MPEG-4 Audio/Visual streams are not managed by = MPEG-4 Systems Object Descriptors but by H.245. The streams are directly = mapped onto RTP packets without using MPEG-4 Systems Sync Layer. Other = examples are SIP and RTSP where MIME and SDP are used. MIME types and SDP = usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g. media = type, packetization format and codec configuration) without using MPEG-4 Systems. The obvious benefit is that these MPEG-4 Audio/Visual RTP payload formats can be handled in an unified way together with those formats defined for non-MPEG-4 codecs. The disadvantage is that interoperability with environments using MPEG-4 Systems may be = difficult, other payload formats may be better suited to those applications. The semantics of RTP headers in such cases need to be clearly = defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it is beneficial to define the fragmentation rules of RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream. 1.1 MPEG-4 Visual RTP payload format MPEG-4 Visual is a visual coding standard with many new features: = high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrates = from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to = mobile networks with high error rates. With respect to the fragmentation rules for an MPEG-4 visual = bitstream defined in this document, since MPEG-4 Visual is used for a wide = variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video = packet shall always be mapped on a single RTP packet" may be inappropriate. = On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but = manage to define the minimum rules for preventing meaningless fragmentation = while utilizing the error resilience functionalities of MPEG-4 Visual. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D The fragmentation rule recommends not to map more than one VOP in an = RTP packet so that the RTP timestamp uniquely indicates the VOP time = framing. On the other hand, MPEG-4 video may generate VOPs of very small size, = in cases with an empty VOP (vop_coded=3D0) containing only VOP header or = an arbitrary shaped VOP with a small number of coding blocks. To reduce = the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet. (See fragmentation rule (4) in = section 3.2 and marker bit and timestamp in section 3.1.) While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual has already error resilience functionalities for recovering corrupt headers, and these can be used on RTP/IP networks as well as on other networks (H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header = fields are defined in this MPEG-4 Visual RTP payload format. 1.2 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. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly = mapped onto the RTP packets without using MPEG-4 Systems. While LATM has several multiplexing features as follows; - Carrying configuration information with audio data, - Concatenation of multiple audio frames in one audio stream, - Multiplexing multiple objects (programs), - Multiplexing scalable layers, in RTP transmission there is no need for the last two features. Therefore, these two features MUST NOT be used in applications based = on RTP packetization specified by this document. Since LATM has been developed for only natural audio coding tools, i.e. not for synthesis tools, it seems difficult to transmit Structured Audio (SA) data and = Text to Speech Interface (TTSI) data by LATM. Therefore, SA data and TTSI = data MUST NOT be transported by the RTP packetization in this document For transmission of scalable streams, audio data of each layer should = be packetized onto different RTP packets allowing for the different = layers to be treated differently at the IP level, for example via some means = of differentiated service. On the other hand, all configuration data of = the scalable streams are contained in one LATM configuration data "StreamMuxConfig" and every scalable layer shares the = StreamMuxConfig. The mapping between each layer and its configuration data is achieved = by LATM header information attached to the audio data. In order to = indicate the dependency information of the scalable streams, a restriction is applied to the dynamic assignment rule of payload type (PT) values = (see section 4.2). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D For MPEG-4 Audio coding tools, as is true for other audio coders, if = the payload is a single audio frame, packet loss will not impair the decodability of adjacent packets. Therefore, the additional media specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward = Error Correction (RFC 2733) and Redundant Audio Data (RFC 2198), MAY be = applied to improve error resiliency. 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 RTP packetization rules for MPEG-4 Visual = content. An MPEG-4 Visual bitstream is mapped directly onto RTP packets = without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be = used so that configuration information will be carried to the same RTP = port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4]) The configuration information MAY additionally be = specified by some out-of-band means. If needed for an H.323 terminal, H.245 = codepoint "decoderConfigurationInformation" MUST be used for this purpose. If needed by systems using MIME content type and SDP parameters, e.g. = SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information. (see 5.1 and 5.2) When the short video header mode is used, RTP payload format for = H.263 (e.g., RFC 2190 or RFC 2429) SHOULD be used. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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 3.1 Use of RTP header fields for MPEG-4 Visual Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, = or if that is not done then a payload type in the dynamic range shall be = chosen by means of an out of band signaling protocol (e.g. H.245, SIP, etc). Extension (X) bit: Defined by the RTP profile used. Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value. Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. When multiple VOPs are carried = in the same RTP packet, the marker bit is set to 1. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. It is the same time instance as that conveyed in the timestamp field (modulo_time_base = and vop_time_increment) of the video stream. (See ISO/IEC 14496-2[2], = section 6 for the detailed definition.) A constant offset, which is random, = is Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D added for security reasons. The detailed definition of the timestamp = is as follows: - When multiple VOPs are carried in the same RTP packet, the = timestamp indicates the earliest of the presentation times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the presentation time of the = next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the presentation time of the immediately preceding VOP = in the coding order is used. The resolution of the timestamp is set to its default value of 90KHz, unless specified by an out-of-band means (e.g. SDP parameter or MIME parameter as defined in section 5). Other header fields are used as described in RFC 1889 [8]. RTP timestamps in RTCP SR packets: According to the RTP timing model, = the RTP timestamp that is carried into an RTCP SR packet is the same as = the presentation time that would be applied to an RTP packet for data = that was sampled at the instant the SR packet is being generated and sent. = The RTP timestamp value is calculated from the NTP timestamp for the = current time which also goes in the RTCP SR packet. To perform that = calculation, an implementation needs to periodically establish a correspondence between the presentation time of a data packet and the NTP time at = which that data was sampled. 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 any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. In the following header means one of the following: - Configuration information (Visual Object Sequence Header, Visual = Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the = definition of the configuration information and the entry point functions. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (1) Configuration information and Group_of_VideoObjectPlane() fields 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. Note: The visual_object_sequence_end_code is regarded as the lowest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Different VOPs SHOULD be fragmented into different RTP packets so that one RTP packet consists of the data bytes associated with a = unique presentation time (that is indicated in the timestamp field in the = RTP packet header), with the exception that multiple consecutive VOPs MAY = be carried within one RTP packet in the decoding order if the size of = the VOPs is small. Note: When multiple VOPs are carried in one RTP payload, the = presentation time of the VOPs after the first one may be calculated by the = decoder. This operation is necessary only for RTP packets in which the marker = bit equals to one and the beginning of RTP payload corresponds to a start code. (See timestamp and marker bit in section 3.1) (5) It is RECOMMENDED that a single video packet is sent as a single = RTP packet. The size of a video packet SHOULD be adjusted in such a way = that the resulting RTP packet is not larger than the path-MTU. Note: Rule (5) does not apply when the video packet is disabled by = the coder configuration (by setting resync_marker_disable in the VOL = header to 1), or in coding tools where the video packet is not supported. In this case, a VOP MAY be split at arbitrary byte-positions. The video packet starts with the VOP header or the video packet = header, followed by motion_shape_texture(), and ends with = next_resync_marker() or next_start_code(). 3.3 Examples of packetized MPEG-4 Visual bitstream 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 or the random access point = of an MPEG-4 visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS = header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL = header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning = of the RTP payload, RTP receivers can detect the random access point by Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet = containing only the configuration information may thus increase the overhead, = the configuration information and the immediately following GOV and/or (a part of) VOP can be packetized into a single RTP packet as in this example. (c) is an example of an RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of = RTP/IP header overhead to generate an 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 (c). (d) is an example of the case where 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. 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. (e) is an example of the case where more than one video packet is packetized into one RTP packet. This kind of packetization is = effective to save the overhead of RTP/IP headers when 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 optimal number of video packets in an RTP packet and = the length of the RTP packet can be determined considering the = packet-loss rate and the bit-rate of the underlying network. (f) is an example of the case when the video packet is disabled by setting resync_marker_disable in the VOL header to 1. In this case, a = VOP may be split into a plurality of RTP packets at arbitrary = byte-positions. For example, it is possible to split a VOP into fixed-length packets. This kind of coder configuration and RTP packet fragmentation may be = used when the underlying network is guaranteed to be error-free. On the = other hand, it is not recommended to use it in error-prone environment = since it provides only poor packet loss resiliency. Figure 3 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, as in (a), will = not only increase the overhead of RTP/IP headers but also decrease the = error resiliency. Therefore, it is prohibited by the criterion (3). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D When concatenating more than one video packets into an RTP packet, = VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization as in (b) is not allowed by criterion = (2) due to the aspect of the error resiliency. Comparing this example = with Figure 2(d), although two video packets are mapped onto two RTP = packets in both cases, the packet-loss resiliency is not identical. Namely, = if 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(d). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+------------+ (b) | RTP | VS | VO | VOL |Video Packet| |header|header|header|header| | +------+------+------+------+------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ +------+------+------------+ +------+------------+ (f) | RTP | VOP |VOP fragment| | RTP |VOP fragment| |header|header| (1) | |header| (2) | ___ +------+------+------------+ +------+------------+ 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) = | +------+------+----------+ = +------+---------+------+------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 4. RTP Packetization of MPEG-4 Audio bitstream This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams MUST be formatted by LATM = (Low-overhead MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams = are then mapped onto RTP packets as described the three sections below. 4.1 RTP Packet Format LATM-based streams consist of a sequence of audioMuxElements that = include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of = each audioMuxElement SHALL be located at the first payload location in 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - An RTP packet for MPEG-4 Audio In order to decode the audioMuxElement, the following = muxConfigPresent information is required to be indicated by an out-of-band means. When = SDP is utilized for this indication, MIME parameter "cpresent" = corresponds to the muxConfigPresent information (see section 5.3). muxConfigPresent: If this value is set to 1 (in-band mode), the audioMuxElement SHALL include an indication bit "useSameStreamMux" = and MAY include the configuration information for audio compression "StreamMuxConfig". The useSameStreamMux bit indicates whether the StreamMuxConfig element in the previous frame is applied in the = current frame. If the useSameStreamMux bit indicates to use the = StreamMuxConfig from the previous frame, but if the previous frame has been lost, the current frame may not be decodable. Therefore, in case of in-band = mode, the StreamMuxConfig element SHOULD be transmitted repeatedly = depending on the network condition. On the other hand, if muxConfigPresent is set = to 0 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (out-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, MIME parameter "config" is utilized (see section 5.3). 4.2 Use of RTP Header Fields for MPEG-4 Audio Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, = or if that is not done then a payload type in the dynamic range shall be = chosen by means of an out of band signaling protocol (e.g. H.245, SIP, etc). = In the dynamic assignment of RTP payload types for scalable streams, a different value should be assigned to each layer. The assigned values should be in order of enhance layer dependency, where the base layer = has the smallest value. Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates the sampling instance of the first audio frame contained in the RTP packet. 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 value of 90 kHz. Sequence Number: Incremented by one for each RTP packet sent, = starting, for security reasons, with a random value. Other header fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is RECOMMENDED to put one audioMuxElement in each RTP packet. If = the size of an audioMuxElement can be kept small enough that the size of = the RTP packet containing it does not exceed the size of the path-MTU, = this will be no problem. If it cannot, the audioMuxElement MAY be = fragmented and spread across multiple packets. 5. MIME type registration for MPEG-4 Audio/Visual streams The following sections describe the MIME type registrations for = MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the = MPEG-4 Visual stream are described in Sections 5.1 and 5.2, respectively, = while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 5.3 and 5.4, respectively. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (In the following sections, the RFC number "XXXX" represents the RFC number, which should be assigned for this document.) 5.1 MIME type registration for MPEG-4 Visual MIME media type name: video MIME subtype name: MP4V-ES Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates = the resolution of the timestamp field in the RTP header. If this = parameter is not specified, its default value of 90000 (90KHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile Level indication value (profile_and_level_indication) defined in = Table G-1 of ISO/IEC 14496-2 [2][4]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual = codec is capable. If this parameter is not specified by the procedure, = its default value of 1 (Simple Profile/Level 1) is used. config: This parameter indicates the configuration of the corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. = It is a hexadecimal representation of an octet string that expresses = the MPEG-4 Visual configuration information, as defined in subclause = 6.2.1 Start codes of ISO/IEC14496-2[2][4][9]. The configuration = information is mapped onto the octet string in an MSB-first basis. The first = bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this = parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2). Example usages for these parameters are: - MPEG-4 Visual Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=3D1 - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v-es; profile-level-id=3D34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=3D145 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D Published specification: The specifications for MPEG-4 Visual streams are presented in = ISO/IEC 14469-2[2][4][9]. The RTP payload format is described in RFCXXXX. Encoding considerations: Video bitstreams must be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is binary data = and must be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer = via RTP. The RTP packets MUST be packetized according to the MPEG-4 = Visual RTP payload format defined in RFCXXXX. Security considerations: See section 6 of RFCXXXX. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding = of visual objects. For effective implementation of the standard, = subsets of the MPEG-4 Visual tool sets have been provided for use in = specific applications. These subsets, called 'Profiles', limit the size of = the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each = Profile. A Profile@Level combination allows: o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and o checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange/announcement procedure to set = this parameter mutually to the same value. Applications which use this media type: Audio and visual streaming and conferencing tools, Internet = messaging and Email applications. Additional information: none Person & email address to contact for further information: The authors of RFCXXXX. (See section 8) Intended usage: COMMON Author/Change controller: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 14] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D The authors of RFCXXXX. (See section 8) 5.2 SDP usage of MPEG-4 Visual The MIME media type video/MP4V-ES string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (video) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4V-ES) goes in SDP "a=3Drtpmap" as the encoding = name. o The optional parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "profile-level-id" and "config" go in the "a=3Dfmtp" line to indicate the coder capability and configuration, respectively. These parameters are expressed as a MIME media type = string, in the form of as a semicolon separated list of parameter=3Dvalue = pairs. The following are some examples of media representation in SDP: Simple Profile/Level 1, rate=3D90000(90KHz), "profile-level-id" and "config" are present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V-ES/90000 a=3Dfmtp:98 profile-level- = id=3D1;config=3D000001B001000001B5090000010000000120008440FA282C2090A21F Core Profile/Level 2, rate=3D90000(90KHz), "profile-level-id" is = present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V-ES/90000 a=3Dfmtp:98 profile-level-id=3D34 Advance Real Time Simple Profile/Level 1, rate=3D25(25Hz), = "profile-level- id" is present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V-ES/25 a=3Dfmtp:98 profile-level-id=3D145 5.3 MIME type registration of MPEG-4 Audio MIME media type name: audio MIME subtype name: MP4A-LATM Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. = The default value is 90000. Other rates MAY be specified only if they = are Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 15] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D set to the same value as the audio sampling rate (number of samples per second). Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 [10]. This = parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability = exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used. object: a decimal representation of the MPEG-4 Audio Object Type = value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool = to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: this parameter indicates whether audio payload = configuration data has been multiplexed into an RTP payload (see section 4.1). If not specified, the default value is 1. config: a hexadecimal representation of an octet string that = expresses the audio payload configuration data "StreamMuxConfig", as defined = in ISO/IEC 14496-3 [5] (see section 4.1). Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. = In the last octet, zero-padding bits, if necessary, shall follow the configuration data. ptime: RECOMMENDED duration of each packet in milliseconds. Published specification: Payload format specifications are described in this document. = Encoding specifications are provided in ISO/IEC 14496-3 [3][5]. Encoding considerations: This type is only defined for transfer via RTP. Security considerations: See Section 6 of RFCXXXX. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding = of audio objects. For effective implementation of the standard, = subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual = have been provided (see section 5.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 16] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D arranging in the capability exchange procedure to set this = parameter mutually to the same value. Furthermore, the "object" parameter can = be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Audio and video streaming and conferencing tools. Additional information: none Personal & email address to contact for further information: See Section 8 of RFCXXXX. Intended usage: COMMON Author/Change controller: See Section 8 of RFCXXXX. 5.4 SDP usage of MPEG-4 Audio The MIME media type audio/MP4A-LATM string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (audio) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4A-LATM) goes in SDP "a=3Drtpmap" as the = encoding name. o The required parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "ptime" goes in SDP "a=3Dptime" attribute. o The optional parameter "profile-level-id" goes in the "a=3Dfmtp" = line to indicate the coder capability. The "object" parameter goes in the "a=3Dfmtp" attribute. The payload-format-specific parameters = "bitrate", "cpresent" and "config" go in the "a=3Dfmtp" line. These parameters = are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of the media representation in SDP: For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A-LATM/8000 a=3Dfmtp:96 = profile-level-id=3D9;object=3D8;cpresent=3D0;config=3D9128B1071070 a=3Dptime:20 For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of = 24 kHz), Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 17] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A-LATM/24000 a=3Dfmtp:96 profile-level-id=3D1; bitrate=3D64000; cpresent=3D0; config=3D9122620000 In the above two examples, audio configuration data is not = multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate. If the clock rate has been set to its default value and it is = necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter (see the following example). m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A-LATM/90000 a=3Dfmtp:96 object=3D8; cpresent=3D0; config=3D9128B1071070 The following example shows that the audio configuration data appears = in the RTP payload. m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A-LATM/90000 a=3Dfmtp:96 object=3D2; cpresent=3D1 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. The complete MPEG-4 system allows for transport of a wide range of content, including Java applets (MPEG-J) and scripts. Since this = payload format is restricted to audio and video streams, it is not possible = to transport such active content in this format. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. 2 ISO/IEC 14496-2:1999, "Information technology - Coding of = audio-visual objects - Part2: Visual", December 1999. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 18] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 3 ISO/IEC 14496-3:1999, "Information technology - Coding of = audio-visual objects - Part3: Audio", December 1999. 4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999. 5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999. 6 ISO/IEC 14496-1:1999, "Information technology - Coding of = audio-visual objects - Part1: Systems", December 1999. 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 14496-2:1999/COR1:2000, "Information technology - Coding = of audio-visual objects - Part2: Visual, Technical corrigendum 1", = August 2000. 10 ISO/IEC 14496-1:1999/FDAM1:2000, December 1999. 8. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan Email: yoshihiro.kikuchi@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 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 [Page 19] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=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 implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =0C ------=_NextPart_000_0243_01C02D25.C7F165E0-- From rem-conf Mon Oct 02 23:26:19 2000 From rem-conf-request@es.net Mon Oct 02 23:26:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gLS2-0001p8-00; Mon, 2 Oct 2000 23:21:18 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gLS0-0001lg-00; Mon, 2 Oct 2000 23:21:16 -0700 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G1U0027WC8HS3@ss3000e.cselt.it> for rem-conf@es.net; Tue, 3 Oct 2000 08:19:29 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 03 Oct 2000 08:22:09 +0200 Content-return: allowed Date: Tue, 03 Oct 2000 08:20:06 +0200 From: Franceschini Guido Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision To: IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, 'Yoshihiro Kikuchi' Message-id: <85077463E51D6A498C453073E167794039BD69@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Change (2) means that significantly different packets are generated in case of Short Video Headers (H263) between the original proposal and this new version. Am I right, or is this just an editorial matter ? Best regards Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 3:36 AM > To: IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > <> > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > RTP Internet-Draft. > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > them are editorial and there are some minor revisions and clarifications. > The following is a summary of the changes: > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > "audio/MP4A-LATM" for audio. > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > video header mode was changed to "MAY" to "SHOULD". > (3) Clarification of timestamp definition > There was a suggestion not to describe the detailed definition of the > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > visual document, so as to keep consistency with the MPEG-4 visual. A > description about the RTP timestamp in the RTCP SR packet was added. > (4) SA/TTSI over LATM > A description was added to restrict the LATM usage so as not to > transmit > SA data by LATM. > (5) Other editorial and wording changes. > > Please let us know if there is comment on the attached draft. The authors > need to submit it soon as an updated I-D and hopefully final before RFC. > > Best regards, > Yoshihiro Kikuchi > and authors of the Internet Draft > > ---- > 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 1267 > > > From rem-conf Tue Oct 03 02:04:22 2000 From rem-conf-request@es.net Tue Oct 03 02:04:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gNwL-0005fb-00; Tue, 3 Oct 2000 02:00:45 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gNwH-0005fI-00; Tue, 3 Oct 2000 02:00:42 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id SAA20130; Tue, 3 Oct 2000 18:00:17 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id SAA28792; Tue, 3 Oct 2000 18:00:17 +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 SAA12005; Tue, 3 Oct 2000 18:00:15 +0900 (JST) Received: from ave (kwa0106.mobile.toshiba.co.jp [133.120.199.22]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id SAA22256; Tue, 3 Oct 2000 18:00:13 +0900 (JST) Message-ID: <038001c02d18$6335a920$16c77885@ave> From: "Yoshihiro Kikuchi" To: "Franceschini Guido" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E167794039BD69@exc2k02.cselt.it> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 18:00:30 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Guido, Excerpt from the new text: > When the short video header mode is used, RTP payload format for H.263 < (e.g., RFC 2190 or RFC 2429) SHOULD be used. This means that it is RECOMMENDED to use the H.263 RTP payload format for the short video header which is compatible with H.263 baseline. Regardless of MAY or SHOULD, there is a possibility that the H.263 RTP payload format may be used, although the possibility may be higher for SHOULD than MAY. If you really don't want to use the H.263 RTP payload format in some circumstances, you don't have to use it. The payload format is signaled through the MIME type. (IETF experts, please correct me if my understanding on the definition of SHOULD is wrong.) Best regards, Yoshihiro ----- Original Message ----- From: Franceschini Guido To: IETF AVT ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; 'Yoshihiro Kikuchi' Sent: Tuesday, October 03, 2000 3:20 PM Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > Change (2) means that significantly different packets are generated in case > of Short Video Headers (H263) between the original proposal and this new > version. Am I right, or is this just an editorial matter ? > > Best regards > Guido > > > ---------- > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > Sent: Tuesday, October 03, 2000 3:36 AM > > To: IETF AVT; 4on2andIP-sys > > Cc: Yoshihiro Kikuchi > > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > <> > > Dear experts, > > > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > > RTP Internet-Draft. > > > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > > them are editorial and there are some minor revisions and clarifications. > > The following is a summary of the changes: > > > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > > "audio/MP4A-LATM" for audio. > > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > > video header mode was changed to "MAY" to "SHOULD". > > (3) Clarification of timestamp definition > > There was a suggestion not to describe the detailed definition of the > > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > > visual document, so as to keep consistency with the MPEG-4 visual. A > > description about the RTP timestamp in the RTCP SR packet was added. > > (4) SA/TTSI over LATM > > A description was added to restrict the LATM usage so as not to > > transmit > > SA data by LATM. > > (5) Other editorial and wording changes. > > > > Please let us know if there is comment on the attached draft. The authors > > need to submit it soon as an updated I-D and hopefully final before RFC. > > > > Best regards, > > Yoshihiro Kikuchi > > and authors of the Internet Draft > > > > ---- > > 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 1267 > > > > > > > From rem-conf Tue Oct 03 09:30:27 2000 From rem-conf-request@es.net Tue Oct 03 09:30:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gUqP-0000CD-00; Tue, 3 Oct 2000 09:23:05 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gUqN-0000AM-00; Tue, 3 Oct 2000 09:23:04 -0700 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G1V00H2R42B30@ss3000e.cselt.it> for rem-conf@es.net; Tue, 3 Oct 2000 18:20:35 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 03 Oct 2000 18:23:17 +0200 Content-return: allowed Date: Tue, 03 Oct 2000 18:21:15 +0200 From: Franceschini Guido Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision To: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, 'Yoshihiro Kikuchi' Message-id: <85077463E51D6A498C453073E167794039BD70@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does it mean that a stream with short video header (H263) SHOULD use the traditional Payload Format for H263, but could as well (not recommended) use the new Payload Format for MPEG-4 Video, and that the choosen PF is notified as usual (SDP etc) ? If so, OK Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 11:00 AM > To: Franceschini Guido; IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > > Dear Guido, > > Excerpt from the new text: > > > When the short video header mode is used, RTP payload format for H.263 > < (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > This means that it is RECOMMENDED to use the H.263 RTP payload format for > the short video header which is compatible with H.263 baseline. Regardless > of MAY or SHOULD, there is a possibility that the H.263 RTP payload format > may be used, although the possibility may be higher for SHOULD than MAY. > If > you really don't want to use the H.263 RTP payload format in some > circumstances, you don't have to use it. The payload format is signaled > through the MIME type. > > (IETF experts, please correct me if my understanding on the definition of > SHOULD is wrong.) > > Best regards, > Yoshihiro > > ----- Original Message ----- > From: Franceschini Guido > To: IETF AVT ; 4on2andIP-sys > <4on2andIP-sys@advent.ee.columbia.edu>; 'Yoshihiro Kikuchi' > > Sent: Tuesday, October 03, 2000 3:20 PM > Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > Change (2) means that significantly different packets are generated in > case > > of Short Video Headers (H263) between the original proposal and this new > > version. Am I right, or is this just an editorial matter ? > > > > Best regards > > Guido > > > > > ---------- > > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > > Sent: Tuesday, October 03, 2000 3:36 AM > > > To: IETF AVT; 4on2andIP-sys > > > Cc: Yoshihiro Kikuchi > > > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > > > <> > > > Dear experts, > > > > > > Attached find please a draft text for the revision of MPEG-4 > Audio/Visual > > > RTP Internet-Draft. > > > > > > The revisions are mostly to reflect suggestions by the AVT chair. Most > of > > > them are editorial and there are some minor revisions and > clarifications. > > > The following is a summary of the changes: > > > > > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > > > "audio/MP4A-LATM" for audio. > > > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > > > video header mode was changed to "MAY" to "SHOULD". > > > (3) Clarification of timestamp definition > > > There was a suggestion not to describe the detailed definition of > the > > > video timestamp in the RTP spec. and change it as a reference to > MPEG-4 > > > visual document, so as to keep consistency with the MPEG-4 visual. A > > > description about the RTP timestamp in the RTCP SR packet was added. > > > (4) SA/TTSI over LATM > > > A description was added to restrict the LATM usage so as not to > > > transmit > > > SA data by LATM. > > > (5) Other editorial and wording changes. > > > > > > Please let us know if there is comment on the attached draft. The > authors > > > need to submit it soon as an updated I-D and hopefully final before > RFC. > > > > > > Best regards, > > > Yoshihiro Kikuchi > > > and authors of the Internet Draft > > > > > > ---- > > > 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 1267 > > > > > > > > > > > > > From rem-conf Tue Oct 03 09:41:31 2000 From rem-conf-request@es.net Tue Oct 03 09:41:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gV4o-00019m-00; Tue, 3 Oct 2000 09:37:58 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gV4n-00019c-00; Tue, 3 Oct 2000 09:37:57 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id JAA04910; Tue, 3 Oct 2000 09:27:33 -0700 Message-Id: <3.0.3.32.20001003093000.00aae9c0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 03 Oct 2000 09:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/4 Studying and Modeling Real Audio Traffic -- John Heidemann, USC Information Sciences Institute 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 Studying and Modeling Real Audio Traffic Wednesday October 4, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) John Heidemann USC Information Sciences Institute The delivery of multimedia content on the Internet is rapidly growing in importance. While there have been extensive studies on the growth and effects of Hyper Text Transfer Protocol (HTTP) traffic used on the Web, little work has been performed in analyzing streaming multimedia traffic. Based on traces from broadcast.com, we will present a study of Real Audio traffic. We will describe the characteristics of typical real audio flows and compare them to web traffic. In addition, we observed consistencies in audio traffic packet sizes and data rate patterns that may be useful as a tool for identifying audio data flows. Finally, we will present recent analysis of real audio traffic and show how it has guided our approaches to model this traffic in simulation. This is joint work with Art Mena and Kun-chan Lan at USC. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Oct 03 11:39:16 2000 From rem-conf-request@es.net Tue Oct 03 11:39:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gWth-0004ky-00; Tue, 3 Oct 2000 11:34:37 -0700 Received: from out2.prserv.net (prserv.net) [32.97.166.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gWtg-0004ko-00; Tue, 3 Oct 2000 11:34:36 -0700 Received: from rpcaragonite ([139.92.226.87]) by prserv.net (out2) with SMTP id <2000100318343222902f428he>; Tue, 3 Oct 2000 18:34:34 +0000 Message-ID: <000d01c02d68$b8ef19a0$57e25c8b@rpcaragonite> Reply-To: "Olivier Avaro" From: "Olivier Avaro" To: , "rem-conf" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "CURET Dominique FTRD/DMI" References: <0056890014249640000002L902*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Tue, 3 Oct 2000 12:14:13 +0200 Organization: France Telecom R&D MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jan, > I would like to verify my understanding on the types of MPEG-4 streams that > need tools for transport over IP. I summarized my understanding by the > following list. Here is the list you can find in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream I don't have anything for Flexmux. cu, O. From rem-conf Tue Oct 03 11:51:51 2000 From rem-conf-request@es.net Tue Oct 03 11:51:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gX9i-0007EG-00; Tue, 3 Oct 2000 11:51:10 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gX9h-0007C2-00; Tue, 3 Oct 2000 11:51:09 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <41BTA9P4>; Tue, 3 Oct 2000 12:50:11 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA81E6EF@el-postino.s-vision.com> From: Kris Huber To: Franceschini Guido Cc: IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, 'Yoshihiro Kikuchi' Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 12:50:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Guido, I think you are right. It appears that the other alternative (change MAY to SHALL or SHOULD) was taken rather than insertion of the MPEG-4 visual semantics regarding picture rate in short header mode (which lacks modulo_time_base, vop_time_increment, and vop_time_increment_resolution). These were spelled out for short header in draft-ietf-avt-rtp-mpeg4-es-04.txt based on a suggestion I made (e-mail of 9/8/00 "RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - timestamp of short header VOP"). Since then, I have learned that a more typical way (I think) that hardware-assisted compression systems are used with PAL devices is with the picture clock frequency driving the temporal_reference/TR field set to 25 Hz rather than giving rounded values of a 30 Hz picture clock. However, my suggestion does match baseline H.263 and MPEG-4 short-header mode, although I think H.263 implementers have been a little loose in their interpretation, perhaps with good reason. Another opinion I respect is that a better partitioning of functions would have placed all timing information in the systems part, as (I think) was done for the audio part. But on the other hand you can't properly decode video without some timing information (sequence number at least) due to temporal prediction and B-VOPs. I heard no discussion of the text I proposed for clarification of the timestamp relationship to temporal_reference in short header mode after Gary Sullivan's clarifications and suggestion that MAY be changed to SHALL. I'm not on the IETF AVT mailing list or at other meetings where the discussion probably occurred. Regards, Kris -----Original Message----- From: Franceschini Guido [mailto:Guido.Franceschini@cselt.it] Sent: Tuesday, October 03, 2000 12:20 AM To: IETF AVT; 4on2andIP-sys; 'Yoshihiro Kikuchi' Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision Change (2) means that significantly different packets are generated in case of Short Video Headers (H263) between the original proposal and this new version. Am I right, or is this just an editorial matter ? Best regards Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 3:36 AM > To: IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > <> > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > RTP Internet-Draft. > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > them are editorial and there are some minor revisions and clarifications. > The following is a summary of the changes: > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > "audio/MP4A-LATM" for audio. > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > video header mode was changed to "MAY" to "SHOULD". > (3) Clarification of timestamp definition > There was a suggestion not to describe the detailed definition of the > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > visual document, so as to keep consistency with the MPEG-4 visual. A > description about the RTP timestamp in the RTCP SR packet was added. > (4) SA/TTSI over LATM > A description was added to restrict the LATM usage so as not to > transmit > SA data by LATM. > (5) Other editorial and wording changes. > > Please let us know if there is comment on the attached draft. The authors > need to submit it soon as an updated I-D and hopefully final before RFC. > > Best regards, > Yoshihiro Kikuchi > and authors of the Internet Draft > > ---- > 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 1267 > > > From rem-conf Tue Oct 03 17:08:14 2000 From rem-conf-request@es.net Tue Oct 03 17:08:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gby3-0002di-00; Tue, 3 Oct 2000 16:59:27 -0700 Received: from netsys.kaist.ac.kr [143.248.148.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gby0-0002dY-00; Tue, 3 Oct 2000 16:59:24 -0700 Received: from eunhasu.kjist.ac.kr (eunhasu.kjist.ac.kr [203.237.32.200]) by netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id HAA20722; Wed, 4 Oct 2000 07:29:34 +0900 Received: from vivaldi (vivaldi.kjist.ac.kr [203.237.51.8]) by eunhasu.kjist.ac.kr (8.9.3/8.9.3) with SMTP id IAA05797; Wed, 4 Oct 2000 08:35:41 +0900 (KST) Message-ID: <004101c02d8f$7ccda8c0$0833edcb@vivaldi.kjist.ac.kr> From: "=?euc-kr?B?yKO/5Ly6?=" To: "PV2001" , , , , , , Subject: PCS2001 Final Call for Papers Date: Wed, 4 Oct 2000 08:13:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003D_01C02DDA.EC7B5500" 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_003D_01C02DDA.EC7B5500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003E_01C02DDA.EC7B5500" ------=_NextPart_001_003E_01C02DDA.EC7B5500 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgYXR0YWNoZWQgRmluYWwgQ2FsbCBmb3IgUGFwZXJzIG9mIFBpY3R1cmUgQ29k aW5nIFN5bXBvc2l1bSANCjIwMDEgdG8gYmUgaGVsZCBpbiBTZW91bCwgS29yZWEgZHVyaW5nIDI1 IEFwcmlsIC0gMjcgQXByaWwsIDIwMDEuDQoNClRoZSBkZWFkbGluZSBmb3IgcGFwZXIgc3VibWlz c2lvbiwgMTUgT2N0b2JlciAyMDAwLCBpcyBjb21pbmcgc29vbi4NCg0KVXBkYXRlZCBwYXBlciBz dWJtaXNzaW9pbiBpbmZvcm1hdGlvbiBpcyBhdCBodHRwOi8vcGNzLmthaXN0LmFjLmtyLg0KDQpG b3IgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gcGNzQHBjcy5r YWlzdC5hYy5rci4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3UgYXQgdGhlIGV4Y2l0 aW5nIFBDUzIwMDEuDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpZby1TdW5nIEhvDQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KWW8t U3VuZyBIbywgQXNzb2NpYXRlIFByb2Zlc3Nvcg0KDQpEZXBhcnRtZW50IG9mIEluZm9ybWF0aW9u IGFuZCBDb21tdW5pY2F0aW9ucw0KS3dhbmctSnUgSW5zdGl0dXRlIG9mIFNjaWVuY2UgYW5kIFRl Y2hub2xvZ3kgKEstSklTVCkNCjEgT3J5b25nLURvbmcgUHVrLUd1DQpLd2FuZ2p1LCA1MDAtNzEy LCBLb3JlYQ0KDQpURUw6ICAgKzgyLTYyLTk3MC0yMjExDQpGQVg6ICAgKzgyLTYyLTk3MC0yMjA0 DQpFTUFJTDogaG95b0BramlzdC5hYy5rcg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo= ------=_NextPart_001_003E_01C02DDA.EC7B5500 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PXRleHQvaHRtbDtjaGFyc2V0PWtzX2NfNTYwMS0xOTg3 IGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0LjcyLjMx MTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0K PERJVj48Rk9OVCBzaXplPTI+UGxlYXNlIGZpbmQgYXR0YWNoZWQgRmluYWwgQ2FsbCBmb3IgUGFw ZXJzIG9mIFBpY3R1cmUgQ29kaW5nIA0KPC9GT05UPjxGT05UIHNpemU9Mj5TeW1wb3NpdW0gPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+MjAwMSB0byBiZSBoZWxkIGluIFNlb3VsLCBL b3JlYSA8L0ZPTlQ+PEZPTlQgc2l6ZT0yPmR1cmluZyAyNSANCkFwcmlsIC0gMjcgQXByaWwsIDIw MDEuPEJSPjxCUj48Rk9OVCBjb2xvcj0jZmYwMDAwPlRoZSBkZWFkbGluZSBmb3IgcGFwZXIgDQpz dWJtaXNzaW9uLCAxNSBPY3RvYmVyIDIwMDAsIGlzIGNvbWluZyBzb29uLjxCUj48L0ZPTlQ+PEJS PlVwZGF0ZWQgcGFwZXIgDQpzdWJtaXNzaW9pbiBpbmZvcm1hdGlvbiBpcyBhdCA8QSANCmhyZWY9 Imh0dHA6Ly9wY3Mua2Fpc3QuYWMua3IiPmh0dHA6Ly9wY3Mua2Fpc3QuYWMua3I8L0E+LjxCUj48 QlI+Rm9yIGZ1cnRoZXIgDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gPEEg DQpocmVmPSJtYWlsdG86cGNzQHBjcy5rYWlzdC5hYy5rciI+cGNzQHBjcy5rYWlzdC5hYy5rcjwv QT4uPEJSPjxCUj5XZSBsb29rIA0KZm9yd2FyZCB0byBzZWVpbmcgeW91IGF0IHRoZSBleGNpdGlu ZyBQQ1MyMDAxLjxCUj48QlI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjxCUj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAg ZmFjZT0iIiBzaXplPTI+WW8tU3VuZyBIbzwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwMDAgDQpzaXplPTI+PEJSPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+WW8tU3VuZyANCkhvLCBBc3NvY2lhdGUgUHJv ZmVzc29yPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkRlcGFydG1l bnQgb2YgSW5mb3JtYXRpb24gYW5kIA0KQ29tbXVuaWNhdGlvbnM8QlI+S3dhbmctSnUgSW5zdGl0 dXRlIG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kgKEstSklTVCk8QlI+MSANCk9yeW9uZy1Eb25n IFB1ay1HdTxCUj5Ld2FuZ2p1LCA1MDAtNzEyLCBLb3JlYTwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDAwIHNpemU9Mj5URUw6Jm5ic3A7Jm5ic3A7IA0KKzgyLTYyLTk3MC0yMjExPEJS PkZBWDombmJzcDsmbmJzcDsgKzgyLTYyLTk3MC0yMjA0PEJSPkVNQUlMOiA8QSANCmhyZWY9Im1h aWx0bzpob3lvQGtqaXN0LmFjLmtyIj5ob3lvQGtqaXN0LmFjLmtyPC9BPjxCUj4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPjwvRk9O VD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_003E_01C02DDA.EC7B5500-- ------=_NextPart_000_003D_01C02DDA.EC7B5500 Content-Type: application/msword; name="PCS-callforpapers.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PCS-callforpapers.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASAAAAAAAAAAA EAAASgAAAAEAAAD+////AAAAAEcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATQAJBAAACFK/AAAAAAAAEAAAAAAABAAAlxMAAA4AYmpiaicyJzIAAAAAAAAAAAAAAAAAAAAA AAASBBYANiYAAEVYAABFWAAAlw8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAIQBAAAAAAAAhAEAAIQB AAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAhAEAABQAAAAAAAAAAAAAAJgBAAAAAAAAmAEA AAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAACQAAAC8AQAAJAAAAJgBAAAAAAAA6BEAAIQCAADsAQAA KAAAABQCAAAAAAAAFAIAAAAAAAAUAgAAAAAAABQCAAAAAAAAqwMAAD4AAADpAwAAFAAAAP0DAAAM AAAA0REAAAIAAADTEQAAAAAAANMRAAAAAAAA0xEAAAAAAADTEQAAAAAAANMRAAAAAAAA0xEAAAAA AABsFAAA9AEAAGAWAABiAAAA0xEAABUAAAAAAAAAAAAAAAAAAAAAAAAAhAEAAAAAAAAJBAAAAAAA AAAAAAAAAAAAAAAAAAAAAACnAwAABAAAAKsDAAAAAAAACQQAAAAAAAAJBAAAAAAAANMRAAAAAAAA tQUAAAAAAACEAQAAAAAAAIQBAAAAAAAAFAIAAAAAAAAAAAAAAAAAABQCAACTAQAA7AEAAAAAAAC1 BQAAAAAAALUFAAAAAAAAtQUAAAAAAAAJBAAAigEAAIQBAAAAAAAAFAIAAAAAAACEAQAAAAAAABQC AAAAAAAA0REAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmAEAAAAAAACYAQAAAAAAAIQBAAAAAAAAhAEA AAAAAACEAQAAAAAAAIQBAAAAAAAACQQAAAAAAADREQAAAAAAALUFAAD0AwAAtQUAAAAAAACpCQAA cgAAAG8RAABUAAAAhAEAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0REAAAAAAAAUAgAAAAAAAOABAAAMAAAAwOE/GfTq vwGYAQAAAAAAAJgBAAAAAAAAkwUAACIAAADDEQAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKFBy ZWxpbWluYXJ5KQdDYWxsIGZvciBQYXBlcnMgYW5kIEFubm91bmNlbWVudAcHUGljdHVyZSBDb2Rp bmcgU3ltcG9zaXVtIDIwMDEHBw0yNS0yNyBBcHJpbCAyMDAxLCBTZW91bCwgS29yZWENU3BvbnNv cmVkIGFuZCBvcmdhbml6ZWQgYnk6IEtJQ1MgKEtvcmVhIEluc3RpdHV0ZSBvZiBDb21tdW5pY2F0 aW9uIFNjaWVuY2VzKQ1JbiBjb29wZXJhdGlvbiB3aXRoICh0ZWNobmljYWwgY28tc3BvbnNvcik6 IEVVUkFTSVAsIElFRUUgQ0FTLCBJRUVFIFNQIChwZW5kaW5nKQ0NUENTIGlzIHRoZSBwcmVtaWVy IGludGVybmF0aW9uYWwgZm9ydW0gZGV2b3RlZCBzcGVjaWZpY2FsbHkgdG8gcGljdHVyZSBjb2Rp bmcuIEZvciBtb3JlIHRoYW4gdGhyZWUgZGVjYWRlcyB0aGUgSW50ZXJuYXRpb25hbCBQaWN0dXJl IENvZGluZyBTeW1wb3NpdW0gaGFzIHByb3ZpZGVkIHRoZSBtZWV0aW5nIHBsYWNlIGZvciB0aGUg cGljdHVyZSBjb2RpbmcgY29tbXVuaXR5OiBpbmR1c3RyeSwgcmVzZWFyY2gsIGFjYWRlbWlhIGFu ZCB1c2Vycy4gVGhlIDIybmQgUENTIHdpbGwgYmUgaGVsZCBpbiBTZW91bCBvbiAyNSAtIDI3IEFw cmlsIDIwMDEsIGluIHRoZSB3ZWVrIHByaW9yIHRvIHRoZSAxMXRoIEludGVybmF0aW9uYWwgUGFj a2V0IFZpZGVvIFdvcmtzaG9wIHRoYXQgd2lsbCB0YWtlIHBsYWNlIGluIEt5b25nanUsIEtvcmVh IGZyb20gMzAgQXByaWwgdG8gMSBNYXkuIEZ1cnRoZXIgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHJl Z2lzdHJhdGlvbiwgaG90ZWwgcmVzZXJ2YXRpb24sIGFuZCB2ZW51ZSB3aWxsIGJlIGFubm91bmNl ZCBvbiB0aGUgd2ViIHNpdGUuDQ1Qcm9zcGVjdGl2ZSBhdXRob3JzIGFyZSBhc2tlZCB0byBzdWJt aXQgZm9yIHJldmlldyBlaXRoZXIgYW4gZWxlY3Ryb25pYyB2ZXJzaW9uIChNUy1Xb3JkIDcuMCBv ciBQb3N0c2NyaXB0KSBieSBlLW1haWwgb3IgMyBjb3BpZXMgb2YgYSAxMDAwIHdvcmQgYWJzdHJh Y3Qgb2YgdGhlaXIgcGFwZXIuIFRoZSBhdXRob3JzIG9mIGFjY2VwdGVkIHBhcGVycyBhcmUgcmVx dWVzdGVkIHRvIHN1Ym1pdCB0aGUgZmluYWwgNC10by02IHBhZ2UgY2FtZXJhLXJlYWR5IG1hbnVz Y3JpcHQgdGhhdCB3aWxsIGFwcGVhciBpbiB0aGUgcHJvY2VlZGluZ3Mgb2YgdGhlIHN5bXBvc2l1 bS4gVHdvIHR5cGVzIG9mIHByZXNlbnRhdGlvbiB3aWxsIGJlIHVzZWQsIG9yYWwgYW5kIHBvc3Rl ciBhdCB0aGUgc3ltcG9zaXVtLiBBYm91dCAyMCBtaW51dGVzIHdpbGwgYmUgYWxsb3R0ZWQgdG8g ZWFjaCBvcmFsIHByZXNlbnRhdGlvbiwgaW5jbHVkaW5nIGRpc2N1c3Npb24uIE92ZXJoZWFkIHBy b2plY3RvciwgMzUgbW0gc2xpZGUgcHJvamVjdG9yLCBhbmQgbW9zdCBjb21tb24gdmlkZW90YXBl IGZvcm1hdHMgc3VjaCBhcyBWSFMgYW5kIEQxIGNhbiBiZSBhY2NvbW1vZGF0ZWQuIEF1dGhvcnMg YXJlIGVuY291cmFnZWQgdG8gdXNlIHRoZXNlIGZhY2lsaXRpZXMgdG8gZGVtb25zdHJhdGUgdGhl aXIgcmVzdWx0cy4NDUFyZWFzIG9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0 ZWQgdG86DUh1bWFuIG9ic2VydmVyL3BzeWNob3BoeXNpY3MNRmVhdHVyZSBleHRyYWN0aW9uIGFu ZCBwaWN0dXJlIHByb2Nlc3NpbmcNTW90aW9uIGVzdGltYXRpb24gYW5kIG9iamVjdCBzZWdtZW50 YXRpb24NQ29kaW5nIGZvciBzdGlsbCBhbmQgbW92aW5nIHBpY3R1cmVzDUNvZGluZyBvZiBzdGVy ZW8gYW5kIG11bHRpdmlldyBpbWFnZXMvc2VxdWVuY2VzIA1Db250ZW50LWJhc2VkIG9yIG9iamVj dC1vcmllbnRlZCBjb2RpbmcHTW9kZWxpbmcgYW5kIHN5bnRoZXRpYyBjb2RpbmcNSHlicmlkIG5h dHVyYWwgc3ludGhldGljIGNvZGluZw1WZXJ5IGhpZ2ggcmVzb2x1dGlvbiBpbWFnaW5nIGFuZCBw cm9jZXNzaW5nDUpvaW50IHZpZGVvLWF1ZGlvIHByb2Nlc3NpbmcsIGNvZGluZyBhbmQgcmVwcmVz ZW50YXRpb24NQ29kaW5nIGZvciBtb2JpbGUgYW5kIElQIGNvbW11bmljYXRpb25zB0NvZGluZyBh bmQgaW5kZXhpbmcgZm9yIGRhdGFiYXNlIGFwcGxpY2F0aW9ucw1FcnJvciBwcm90ZWN0aW9uIGFu ZCByZXNpbGllbmNlDUpvaW50IHNvdXJjZSBhbmQgY2hhbm5lbCBjb2RpbmcNVmlydHVhbCByZWFs aXR5IGFuZCB0ZWxlcHJlc2VuY2UNTWVkaWEgdHJhbnNmb3JtIChpbWFnZSBhbmltYXRpb24gYnkg dm9pY2UgYW5kIHRleHQpDUltcGxlbWVudGF0aW9uIGFyY2hpdGVjdHVyZXMgYW5kIFZMU0kHBw1H ZW5lcmFsIENoYWlyOiAJSmFlLWt5b29uIEtpbSwgS0FJU1QsIEtvcmVhDUludGVybmF0aW9uYWwg U3RlZXJpbmcgQ29tbWl0dGVlOg1Kb2huIEFybm9sZAkgICAgVS4gb2YgTmV3IFNvdXRoIFdhbGVz LCBBdXN0cmFsaWEJCUtpbmcgTi4gTmdhbgkgICBVLiBvZiBXZXN0ZXJuIEF1c3RyYWxpYSwgQXVz dHJhbGlhDUxlb25hcmRvIENoaWFyaWdsaW9uZSAgICBDU0VMVCwgSXRhbHkJCQkJSm9lcm4gT3N0 ZXJtYW5uCSAgIEFUJlQsIFVTQQ1Nb2hhbW1lZCBHaGFuYmFyaQkgICAgVS4gb2YgRXNzZXgsIFVL CQkJCUZlcm5hbmRvIFBlcmVpcmEJICAgSVNUL1VUTCwgUG9ydHVnYWwNSGFtaWQgR2hhcmF2aQkg ICAgTklTVCwgVVNBCQkJCVJhbGYgU2NoYWVmZXIJICAgSGVpbnJpY2gtSGVydHogSW5zdGl0dXQs IEdlcm1hbnkNQmVybmQgR2lyb2QJICAgIFN0YW5mb3JkIFUuLCBVU0EJCQlBbGkgVGFiYXRhYmFp CSAgIFNvbnksIFVTQQ1UaG9tYXMgSHVhbmcJICAgIFUuIG9mIElsbGlub2lzLCBVcmJhbmEsIFVT QQkJCU1hc2F5dWtpIFRhbmltb3RvCSAgIE5hZ295YSBVLiwgSmFwYW4NSmFlLWt5b29uIEtpbQkg ICAgS0FJU1QsIEtvcmVhCQkJCUEuIE11cmF0IFRla2FscAkgICBVbml2LiBvZiBSb2NoZXN0ZXIs IFVTQQ1NdXJhdCBLdW50CSAgICBFUEZMLCBTd2l0emVybGFuZAkJCUpvaG4gV29vZHMJICAgUmVu c3NlbGFlciBQb2x5dGVjaG5pYyBJbnN0LiwgVVNBDUNsYXVkZSBMYWJpdAkgICAgSVJJU0EsIEZy YW5jZQkJCQlIaXJvc2hpIFlhc3VkYQkgICBVLiBvZiBUb2t5bywgSmFwYW4NU2FuZyBVayBMZWUJ ICAgIFNlb3VsIE5hdGlvbmFsIFUuLCBLb3JlYQkJCVlhc3VoaWtvIFlhc3VkYQkgICBXYXNlZGEg VS4sIEphcGFuDU1pbmcgTC4gTGlvdQkgICAgSG9uZyBLb25nIFUuIG9mIFNjaS4gJiBUZWNobm9s b2d5CQlBdmlkZWggWmFraG9yCSAgIFUuIG9mIENhbGlmb3JuaWEsIEJlcmtlbGV5LCBVU0ENSGFu cyBHLiBNdXNtYW5uCSAgICBVLiBvZiBIYW5vdmVyLCBHZXJtYW55CQkJWWEtUWluIFpoYW5nCSAg IE1pY3Jvc29mdCBSZXNlYXJjaCwgQ2hpbmENR2VvZmYgTW9ycmlzb24JICAgIEJyaXRpc2ggVGVs ZWNvbSwgVUsJCQkNVGVjaG5pY2FsIFByb2dyYW0gQ2hhaXI6IAkgICAgIFNhbmcgVWsgTGVlLCBT ZW91bCBOYXRpb25hbCBVbml2LiwgS29yZWENT3JnYW5pemluZyBDb21taXR0ZWUgQ2hhaXI6ICAg Sm9uZyBCZW9tIFJhLCBLQUlTVCwgS29yZWENDVN1Ym1pdCBwYXBlcnMgdG86IFBDUyAyMDAxCQkJ CURlYWRsaW5lczoNRGVwdC4gb2YgRUVDUywgS0FJU1QJCU9jdG9iZXIgMTUsIDIwMDAJU3VibWl0 IGFic3RyYWN0cw1ZdXNvbmctZ3UsIFRhZWpvbiAzMDUtNzAxCQlKYW51YXJ5IDE1LCAyMDAxCU5v dGljZSBvZiBhY2NlcHRhbmNlDVJlcHVibGljIG9mIEtvcmVhCQkJTWFyY2ggMTUsIDIwMDEJU3Vi bWl0IG1hbnVzY3JpcHRzDQ1PciBhbm9ueW1vdXMgZnRwIHRvOiBmdHA6Ly9wY3Mua2Fpc3QuYWMu a3INDUZvciBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBvciBmb3IgcmVjZWl2aW5nIHJlZ3Vs YXIgdXBkYXRlcyBvbiBQQ1MgMjAwMSwgcGxlYXNlIHZpc2l0IHRoZSB3ZWIgcGFnZSBhdDogEyBI WVBFUkxJTksgImh0dHA6Ly9wY3Mua2Fpc3QuYWMua3IiIAEUaHR0cDovL3Bjcy5rYWlzdC5hYy5r chUgIFNlbmQgYW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIHRvOiATIEhZUEVSTElOSyAibWFp bHRvOnBjc0BwY3Mua2Fpc3QuYWMua3IiIAEUcGNzQHBjcy5rYWlzdC5hYy5rchUNDQEJAQkBDQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAOBAAAIgQA ACMEAAAvBAAAMAQAAE4EAABPBAAAUAQAAG8EAACJBAAAigQAAIsEAAC8BAAA5gQAAAIFAAAMBQAA DQUAAA4FAABrBQAAcAUAAA0GAAAQBgAAEgYAABMGAAAVBgAALwYAADIGAAAzBgAANQYAADYGAAA3 BgAAOQYAADoGAABFBgAARgYAAGAGAABiBgAAZAYAAGUGAACIBgAAiQYAAMYGAADHBgAANAcAADUH AACOBwAAjwcAACAIAAAnCAAA2AkAANoJAAAMCgAAsQwAALkMAAC/DAAAwAwAAMEMAADODAAAzwwA ANAMAADWDAAA1wwAANwMAADdDAAA/gwAAPv18PUA7gDm4Nng++DZ4PvTzcjCyMLIwrrIwsjCyMLI wsjCyMK6wrTIwsjC08jCyMLIwrDC4LDIwsjCqMKowuCwAAAAAAAAAA9DShIAT0oAAFJIyABvKAEH NQiBT0oAAAs1CIFDShIAT0oAAA5DShIASCoBT0oAAG8oAQALQ0oSAE9KAABvKAEIQ0oSAE9KAAAA C0NKDgBPSgAAbygBC0NKEABPSgAAbygBDTUIgTYIgU9KAABvKAEKNQiBT0oAAG8oAQAPQ0oQAE9K BwBRSgcAbygBA28oAQhPSgYAUUoGAAALT0oGAFFKBgBvKAEHT0oAAG8oAQBBAAQAAA4EAAAvBAAA MAQAAE4EAABPBAAAUAQAAG8EAAC8BAAADQUAAA4FAAA0BwAANQcAANkJAADaCQAADQoAAPwAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAAyXwAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAAChAAAAAAAAAAAA AAAAnwAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAJkA AAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACfAAAAAAAA AAAAAAAAnwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABgAAEmTwAAAARyQAAAEAAAAkAAAWJAEXJAEClmMAB5T5AQXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWGgABnf9rKYAGzikMAQAA/////xIBAAD/////AwEAFiQBAC0AABYkARck AQKWYwAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAAp3/RgtrKQAGqQv///////////// ////////AAYlHv////////////////////8ABAAAAyQCFiQBAwAAFiQBAA8ABAAADgQAAC8EAACX EwAA/f37AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAAQDAQUKAw0KAAAqCgAAVAoAAH4K AACjCgAA1AoAAPwKAAAaCwAAOgsAAGYLAACeCwAAxgsAAPQLAAAUDAAANAwAAFUMAACJDAAArwwA ALAMAACxDAAA3QwAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA ADgAABYkARckAQKWYwAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1kYAA53/jA17G2spAAbv Df////////////////////8ABu8N/////////////////////wAG8A3///////////////////// ABMAAAMkAAomAAtGAwAOhMgAEmTIAAAARyQAFiQBDcYHAWgBAbQABgAU3QwAAP8MAABkDQAAqg0A APkNAABKDgAAiA4AAN0OAAAqDwAAfQ8AAMQPAAATEAAAeBAAAM8QAAD5EAAAQREAAHoRAAB7EQAA pBEAANwRAAAdEgAAUxIAAFQSAAB/EgAAgBIAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAADqAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAA AAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAAAF AAANxgUAAVMHAAAGAAASZDj/AAATpIgACgAAD4TIABGEeAUSZPAAAABHJAAABAAAEmTIAAAAAAQA ABJktAAAAAgAABJk8AAAABOkiABHJAAGAAASZMgAAABHJAAAAQAAABj+DAAA/wwAAAsNAAAmDQAA Lw0AAGQNAAB5DQAAfQ0AAIkNAACNDQAAnA0AAKANAACpDQAAqg0AALwNAADADQAA0A0AAPkNAAAG DgAADw4AABQOAAAYDgAAJQ4AACkOAABJDgAASg4AAFYOAABaDgAAaw4AAIgOAACVDgAAmQ4AALQO AAC3DgAAyQ4AAMwOAADcDgAA3Q4AAOoOAAACDwAADA8AAA0PAAAPDwAAEg8AACkPAAAqDwAANQ8A ADkPAABMDwAATQ8AAFgPAABbDwAAfA8AAJ8PAACuDwAAtw8AAMMPAADvDwAA/w8AAAIQAAAKEAAA CxAAABIQAAATEAAAIBAAACQQAABFEAAARxAAAFUQAABYEAAAdxAAAHgQAACIEAAAjBAAAKIQAACl EAAAshAAALUQAAC+EAAAxxAAAM4QAADPEAAA3RAAAOIQAAD1EAAA+RAAABERAAASEQAAJBEAAP34 8vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy +PL48vjy+PL48vjy+PL48vjy+PL48vjy+PLs6PIAAAAAAAAAAAAAAAAAAAAAAAAAAAdPSgAAbygB CjUIgU9KAABvKAEAC0NKEgBPSgAAbygBCENKEgBPSgAAAARDShIAWCQRAAAlEQAAOhEAADsRAABB EQAAXBEAAF8RAABsEQAAbREAAHMRAAB0EQAAehEAAHsRAACNEQAAlREAAJgRAACZEQAApBEAALgR AADcEQAA5hEAAOcRAAD1EQAA9hEAAPcRAAAdEgAAMRIAAFISAABTEgAAVBIAAGgSAABpEgAAfhIA AH8SAACAEgAA6hIAAOsSAADsEgAA+BIAAA4TAAAQEwAAERMAABITAAAoEwAAKRMAACoTAABQEwAA URMAAGQTAAB3EwAAeRMAAHoTAAB7EwAAjhMAAI8TAACQEwAAkRMAAJITAACTEwAA9/H38evn8ffx 9/Hf29jb69vn2OfY59jn2OfY5/Hb2NLKxNjnu9vr26+7prvn2Lvb69uau6a768SVkwNvKAEJA2qm AQAAVQgBFgIIgQNq0wAAAAYIATUIgU9KAABVCAEAETBKDwA1CIE+KgBPSgAAbygBFgIIgQNqAAAA AAYIATUIgU9KAABVCAEAEANqAAAAADUIgU9KAABVCAEAC0NKEABPSgAAbygBDjUIgUNKFgBPSgAA bygBAAtDShcAT0oAAG8oAQRPSgAAAAc1CIFPSgAADjUIgUNKDgBPSgAAbygBAAdPSgAAbygBCjUI gU9KAABvKAEAC0NKEgBPSgAAbygBD0NKEgBPSgAAUkjIAG8oAQA6gBIAAJATAACREwAAlxMAAPkA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAwAAAyQBBgAAEmTIAAAARyQABgAAEmTwAAAARyQAAAOTEwAAlBMAAJUTAACWEwAAlxMA APr48+0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL Q0oSAE9KAABvKAEJA2rzJgAAVQgBA28oAQkDamEdAABVCAEABDQAJlAJADGQEQEyUAIAH7CCLiCw xkEhsL0CIrC9AiOQiQMkkIUDJbAAABewUwMYsOADDJCpAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0wAAAEQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGM ggCqAEupCwIAAAAXAAAAFwAAAGgAdAB0AHAAOgAvAC8AcABjAHMALgBrAGEAaQBzAHQALgBhAGMA LgBrAHIAAADgyep5+brOEYyCAKoAS6kLMAAAAGgAdAB0AHAAOgAvAC8AcABjAHMALgBrAGEAaQBz AHQALgBhAGMALgBrAHIALwAAANMAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABQA AABwAGMAcwBAAHAAYwBzAC4AawBhAGkAcwB0AC4AYQBjAC4AawByAAAA4Mnqefm6zhGMggCqAEup CzYAAABtAGEAaQBsAHQAbwA6AHAAYwBzAEAAcABjAHMALgBrAGEAaQBzAHQALgBhAGMALgBrAHIA AAC7GwAARABkAAAAAAAAAAIAAAAAAAAAAAAAAAAAUwdTB0ACQAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAABBAAAAAoAAEMAC/AYAAAABEEBAAAAgQERAAAQ vwEAABAA/wEAAAgAAAAQ8AQAAAAAAACAYgAH8CsbAAAGBh+hduk+FDynX/wzs4eEkyL/AAcbAAAB AAAA6gEAAAAAwQAAbh7w/xoAAB+hduk+FDynX/wzs4eEkyL/iVBORw0KGgoAAAANSUhEUgAAAH0A AAB9CAMAAAC4XpwXAAAAAXNSR0IArs4c6QAAAwBQTFRF////jIyMlJSUAAAAnJycGAha7+/vvb29 5+fnzs7OxsbGra2t3t7e9/f3QkJCEBAQe3t7Y2NjISEhxggppaWlxgAh1tbWUlJStbW1MTExc3Nz IRBahISEjIStCAgIOTk5KSkpGBgYWlpaxsbWUkqESkpKKRhjlIyta2trvRAxSkJ7/+/3rUJr5+fv WlKEOSlrlIyUQjl775ytziFCMSFrraXGY1KMvbXOc2uEhHOllISM973O1mN7nJyl54yl987W1lJr zilK1kJa1tbera21paWtSkJznJS1c2Oce0Jz/97n7629zjlSzhAxjIycc2uUY1qMjISUhGOU58bO xjFSnHN73mN7xiFCvRg57+fn1tbnpZy9raW9e3OMpZy1Qilrxr3OnIyUvXOMxmN7tTFK3nOEzjFK 597e3tbWta2t3s7OlJSle3Ola2OUe3OchHulMSFjY1p7e2ucMRhjvbXGe2OUczFrpTFaxpSlpXuE 3pSlvVJrtSFCpVJjzlJrxkpj3qWttWtzhISclIy1a2OMWlJ7UjlzSjFrMQhSOQhSShhae1KEvaW9 tZS1nHOcezFrnGOMjEJzpWOMhDFjhCFazr3G1sbOpVJ7jCFSxoSctVJzrSFK3r3GtSFKvXuMrWNz 53uUrTlS1q21vWt7xhg51nOEvWNzxjFKtSlC1mt7pWNr76WtAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWNNcqAAAF5xJREFUaEPtW+VjHEeW766u6WomtaZB45mRZMkyxXYcx4nDDJtsGJaZmW6ZjpmZ Gf/J+733qntGtmzL3r37tBVFnmmox1hPjvOLdTccMJHBT3g3r979O37k9lnnra0825vF/w9YJLqs PK/KigJU+0xBaCI9KxdAJiuiu6fptm+GfeXlezNz9IOh7pee1+j0tvvcxQMJQC/727A31U0OBO5i +1u+ojNvu0+OtatuvPyYjx5rP0dXXhOvPerOiibLViTG4La/YktSVF55PFRvDx+wr9vLK2baLYLx 1Ryq4JbrO934zu3hHPWEOYIOqD30fuSG74HQWXH4bcDvxSjufiWZ1ww89GcDvMyNwPwReu9BCIuV aHyBqvPcvXvIeNPNq8G+kj5fNnazIltUi1kr3/wid/OpU03tTV1rC9XvvezuxQ/CB3YmJWQ/nQuA difLqhzcZ9JaKEU/d7yBzHC7U5V9L+zumvw4Xw70ONusd3lZEYzYjUD9KIeQtD3kO8TvrGzyncCx RBdec1fS772dw26L6WcI03zZz4rOanlDLDCDVDJVeEXWFcP3KK/uPAL42bw+pDKAnSVaVKuolNFl btm7aIrWpAOF5U4a5tC4EeQNOx3a9sgvENjIdXogKeezOK8qka7vNlnpDg8EbpEtPasTRZFtl7k/ YMaPl6P63B4wPRHmndDSWZUviqCoOu106y7vqL2mVaZnpqny9Qdr75Arug0OFnjqwuTCRhDIFxQ+ 3dnqVUot6Gfl85gvfe66lZ8cuqrvALwFHm6XZdZ7lgvrmmtme4eyC8T7dnXfVOR5ZcWpYSYcH/zA 9rzfAeTsOqYlbgY32xQx+fpauUod9HsdIns3hN90W40MKpaznKPRccGPMg87L/fysFpzl6nGtTIG naHSrTLGVbHSKtIqiRH/q4IschVvUnfW5Fb9jwfe7yyrna6BM8uKcCQ+6edz687hcAJlUte4qTK1 Clq3TR2Tzb1yPfNxu3IONRBOaIoGt1tZPkgwdjMof+hY8H7pbbsJMzVROvCVceI6cJ2pSmrl06W6 Tg62vWyw9CLQnVPPVW7E3RXebdO+fr6yc533sNsw7/ndvCoAsEVsiVw4FxU7gRsAOnBwau2ksauC UEVx55WCf7/08yapTDu33Cvnh83jBkbE3rqH0zNyXMQw6HHhg8w60EkMP5PqOnViIABepG5IX41S mj2QriyzSzhkbxnNByv1u+UtOZ/kgmY8c8Wjd0sG3nsLRtuvoeYKpNVIXUE6/sfVSIEVSk21Eskm jQ0tJVRouuaxLRtvhkLGGhfnCBI5CyulBDXp5lZzfAc2BrkawgCkC/RUhaFStaoTXfvTWCm3z8XP l118KFxo7ybpOD3sevSOYS/pN5nFMcy3h3ciADGujojDRLpAhyLA7BRlG7XrRiEwS/dEw7NBkqFh fWqqm8bbQGJDJc7Cr4SP2mtmFGqjOAo09A36pZRJmHSWO4zfVa5pFZ6C8O32BTlX37r7uKqyOaVJ vqjwUWvBGUIyZCniNbS34xjjpHX8kx9qKD0RWE9rwGvDIAjdJGpBNyGhW8dXEayP9572DJ4/16w8 ilC5Ke+N2KOBx4gbKsuI9drLtE/WBLjf+0/mRsT7xyrWrgsk4jb0jdImiFSrYDE1rAHA4QCH0OLP xdDjHL941yNWJelI4JVZhmQ9yXYI+AKuXChI658+8RgFd1IOX8K7yB3JnUvccCMAhvUBuAtsB/D1 noVG8To82uVpysppWceebtdOhOwqjOFJGXXl/M/pe52ag1YoyiFyJ+9HBIP3hJhqI5ep1ZJ3Foh5 IUhqFmT5khtev6rBnxsOkP5O5iRzsMO0qaHNQhcsuHfzx9eYE1qYOdAu3wPxEqEa8h7lEaozJMB5 aYxm8SdHET+SLvZezrOUA45PVIUqnjLDnZ9svvM+2sKVjHOEHrFKtPQbZjkovrOXA5/Qho7UYx4e RbwlnQlL9ayAWA/IZaSI4IBSWz8W/cPmy+8BGJs4jdB94gz5nakGG+o6lnTDrTr8ztjz+0uxtiOI t6TXBT/AywiLEpYhEQSdgk+/d2PzU87A2kHuEAWzpnXJI+CdNiL8wnhKPsTPqiIqqiGzLwmjQysT hV/k1seQt5FLIWkBSTSCr4mBEMD/xzX78ki7Y2rHZxQZCe0iKYRO+unMI+OIy+xgjK/h9f42YfVw jBNt57lYZDGHBsO78X6i6HAyOjpP4E8/JOBX0KeIPzpKEXFwWcE5AboO/Vpt32jgQx0y0N+LGcAd Nqpghgde42qtpo6P7aZWySKNJEo9/S8bm5uPCnSxuIQux6xTChLwFdACLxS54HZNx+OsoGe0d9jb b7NChA24tJD0Yqeq9XR4SEuYgVJRk6J95NsbG5uPfz6gCBuEBqGljoJaniHlD8CpuoYTQLIRjTqe lElVlqQe6WGjmw6eBrd6Ri/xavhXm+dMYUFncXFqfUsbP7wJ7r/Fnla3ERPNakZ0JwxdudCCgKQ/ 6HhdhJ7PscnZGao8fuVAtDBGZepLy4uNMnKlRifSH7t8+cnv//tDzA3I4+1NkP89RBl+gPEdnG5L 0AMooEHMIYZYAw9RHjgN79geYn3FjDdN5FodsfhiD3iLhJ3H2SdBL36efPvf/vsNxyHqNx/+7Cp1 T9niWUcik0auRqoZMfOsSjtFEzrxgojz11mfcFbhsKu1Ck/hiDFy42BwLZ8geulnc3Pz8pP88Z23 RtqJI7xU2LYKSmedMa40wui0iA6AFX1s1moULbA4Fxd/JMygFcQIXUFEDlz/vQW+wVjILzg+u6Bg grCGzKNoCES4EotahX3SOT7DVdvja04puCGy6xlHw1CYIQt5k1vXEfTp/GMvEeUkAP6XJfGp4Tkj SoLkEhE+aOEXx6aNTXJ3nP6gYbihuHxe25zzxhQGC9a5fjuMmNyA8lcTUKboh+DZWYj7EHh8e4nM gbCEOsPbqJZMJaE8Y0whrW8t87xxRVNWgk/F8/VdicqI71V7JopqHUQUMii4wYm6qia1epToFaot HoPjS1ykNyryY66psRGhKysWHWePWfCVbBStkUzObfe6yqZ2jA6qo2nqTuMrJ2Q9/bT8e2Vj1165 8uZp8ju/+8WTJ1+5Gqhffg5Ut1fv37/v/g9MT+5K3BNS2cwTSlwMM3q2GG4V4maTHSR2NpOUWxHs Dbnar16Y0PrqU7sn9/HvfV/b/MOP8JXf/B142ofeuH8y+a3f2J9c+sCFE+D9ByZbz566NLkw2WWv K8uSyvrFmmUVHZ96trLQ6/V2xpyXC7LgLpOn9rcmW79GArs62foVVX9/8/LJydbkGy9v/vS1eHpp svW1z0XJCaBzCjLan3wUmdirk61dpx0FX4g7o32nvLkZ/Y24fmq7KRG7XLBLT53PEqz3EvNOTD7o XAyce19+fWsy+SVw/ZN/Bsrv50dfmUxA+3OTSzVorrdAezQWhbEIt8iQNIlHHqNsx8DQ9gIKcofz rymrf0oly0nA+hBuv3/yPAILrj/2OvB5gbT/9/DhKr+V3ke0n5mcNMpM9SlATy4OJATWhOtszzZY PfuvRWOG7ofHKPqQfxJrw2kKR3Ci/YEI+5+h4pGeAZ+3XgDwxy9NJvsWxoeI9snkAioanZwH9FX0 tzAMjnNcOb0Z+StVBPStSFkTjYe6jFK6WNsq9SRgPTB1Hpw8NQS6E5b2j+POr1voz+yDdlzf5XB3 aRdmNPqUjjU96o0r5ekI3RcRZI4uxc9Gq44vavKLcRzfA84/EOxOnqO7LLdTuEK0P0jy//SLDD9+ lmmf7J+iR66eX4cupPr+1NboDuf2TCojUxSRQa8ES9u+I31OTY0kgjn/1IWTjBtDJ84/+NLm5XsA 7Q82TrO3j58GQFjHZPJ12dmRMoTWQrxLTbW4+DZrV5bUVdNitp6JMTBwfjK7f/LqOvQt6NjbL90H YH8JHvwjQScJwgRw6dL7GdiK83ZPL8+apqBbhQViXd1BM5y0FItgtdo6SPwzoOh5bPtRXCdmBMFX 8O0rQfAGIG2dI91/8jPIrXDjw0T71mT/gz6+uChzZR0IMFDu+6xm10GH3u1IV3RWIWUaF4rD+B7a Ev+fwReqFt1rr+DbK64bkss7xz5/462LdPNjkAU9PDml3Iv4z649ho6egJku2f0P0C3nfeT8Fct0 uMHYWosjGrHllVHu+AYdIxWfMO2IOz9kKafkHPCzD3Nd4zxbU1T4WWI4yl1He5MPp0yzJcOVJdCx 2xcuYM8L6ah1JHdS8S2hnSLe4xJrHxRUn0NGMGrdHrt4U6QF9SKwhjCTSObBmQ1/soog0LmKZJ1/ jiCdGCxOvDrT/vsU6Jj6y6jvsT6MYLQ1ObnubcTiIj64ZrnbbGtwuQZBPGbprOydvhH32N7DM2TL qVTu5G2I86QRJ158YqD+9F99kTaISU0nYwaOS5kkMESdnJVf7+sWs4OcQ1G4lt1z+sy0f6jdpS2/ JOXLCZH7Zx4ERs9Lhst53rkLtH+UEqZDik/PS6d6tjdDOckMHqHLHdA+NIgPVXlkxeRpEePI7Le+ Ofp5cD74AhB6Fm/fy+nO5c1zk0+8SPXsLtFObVW7ZEs6wF1ICju2vgc0mmWaMF7V2gkEE0Ba94xy zpOUz3yMHjklnA/afXygYPjYOxsbf/r1y+cmf3L6PaRseNBBKmqX8Thg4oAFrpSvjS1jm1yXXr8j 9XOz4wRG2nvSoSHpXkFN8TyBfy9tdApsIOiKPnz5oYcecs6+9Df73zp9bnLp5c1/QqG/NXnQWSW1 Spw3HU1Kmm9LCMKIbTHQaAE64ocqgyYE6kC+jnhOUryKvc6TLn+VoJPWfQm9Ohe6uLX/JuqLzb/7 xn0/Aue3XtjYeOLslckkCLia5iU5+7Tg3enXyq7aMabZZyOP37Niuzi9SkDveQSYPcteLI6fQaq3 tf8A2lnxMzCvj3z7yTf/aH//49A6mMVfbGy8eR9IX+W0jhyNJhnimc0qlwNi6zouQhE9TAX3iHSO oL5GgY0+fpk/YJ0kX/R+RglQPw7FOzd5Fcj89v7knnRN6RJuYFCbtuipjzQwgy8OjYsAB4xsjNYV 1Oyqpo/s0vrmI6898t4Pf3R395kPnj/PV3Z3nwou0hNXXt2fnHn9YXI4f/2tlz/x+smTz//xEz8+ OxR2sFoRu3HczB6dDOfEuCr5bkszK9TwGJsLLaPiX6PuRXzR9mTW7WjNm90LyVubpyoTX/71rVHs Sykaq4NUikgkb2O660i+66MzavNd21wIqH4mLW3VNepKyxuh7ZbR57XM7W/flRJr890f/IBLzKG7 QgrOhm/aEOUKU2RzXOGIZDeBoxtbv9vmPDcFU5y78Su2Ozq0Ca6DHsWPSl377jV08VPnxe9+5w1b 4dlyJdxGWhUzIusVg63pik5P7TGirXmdOECbFH0ARtIWpb5tITH0VfcAPvHFx7m6PX3tET4zoqYm r0HIU+PUC95rTeyDlvmxg+asFF+2dYkjP1QTQx/AFqUrJ7LOeW7yfOc0Mf+dz6nX0EwagOu1clnK 7EMV+lhVocdRSjElvUtfunWRpRCnLyTzlQNdg47OIG61f/4wMf/T74vHTvFISTFgQw3U1WdqYYkm NXmRJOKcifip0sJz27yK1bQFhfD8aRIZuBpkUjqOEtJtcS0qjb77BMA/cRYHCraGHPrPXTbOYK1a IwJWuhc41EvyHbY/vGOU9LeoGSJItDU6ItxLUHUcRTgZUWGE1gqyNZbKlLs10L7NT+N0VtEMEnK5 sUejtg+khbLeGhFYdNlvYtM5cpbYLRWqdzFZnx1HgIPPGk2ZGi0CwcpyPghBqQ5TR0+ptef4j29u fFIHAQ6H6WxAGigGpVrXH90jt6MKKGgyIyephg6zWqs6THyC0g6NegAZ6/LR3hPXEFpOLSH9Pac3 PokTS5yZJp6Ea+NV3PsgWm4Yg7GNWt2gg1t0jG0/x9M20qAzDraqOmJmyIn+ina6hLYs2rpMLVb0 sf/a/BEhrLhBjzX13YyjKDF6dIJ2m6GdqcngjE2+8Q8nlVg4nVBQI+leTscO5WjvuKfCNIVCkNKm +P3P776NT4UVcbgDW6pF1StyqofX2nkF5pukX06zIjB32q5VKoVIVcQp+tq8iewCewsgpEShW63R boGgng4f/RSVw3w/yYzKF9IeWDf/AYeBeNMuq8iXA0sX/tkQLegfGYWtwXI2gzFhG+QOxlNrmA6l 4BxjoEjh+eznc7Elh843fDv2s7KBNfot8X4OLTFa3irnEJcPb4M+QqtChcOWgOgeWT9wHoyHfcjR ALV68A6QWc0xFOCiI22DteOnNeij5HEttDWV083DEJrO3LeDRoZADKHb0s6nB5iAEEcV6xaNPxxn La2xofuCOYBADgWPJB06bg+uEqjKLK7EAXR5aE9f4XZlc4IBTqcB+pmtihIISQIXn8biHqZBcCpM 79rE9CCPw8bbY6kP5r9GN38czodBOJqyiQx/+N28R9uXP0+FB+hJ4mgQXkfHce3Cobst21no1nRC ja4mzodxDrscZq3ixs2HOcOEBHvkkuN3qAicpt8MB3Qdgm4kPoTP3aFz6PxjyIM+EudTOpGmSYwI Z+P4KM+a7YHyMNNBuOykedFsD27yBhSy8aAs7BZ+KcbiN8hwrYHTzAF0WunUnhOJ1tEZoKLDXwdV nk2A8s46xERmtsSBxreYO0mG0bCMDunhmwQ/DCgOzg0ydfU0gOjlxHeYu0DYtccYAtxdDfV1YUmm JinizQ//+SVRrJAMrhyFFefbtiZKhLGhmvLgg3CeQil0Ak49JKGRb1mbaYPzKeeSmjnZzQcf6HYz F8cKLYKtj/VAsJDx1NYlLccHiABjNpJZkZUndBWoSa2YjyOePPUI0SyljLsusvK9teVXQ+eapoww OjO02Gk8FQeLoHfKrj5WCfXtiXaQToNH5I01shEM4GI0x67E6yhBkXHzyLrd64GuvodDN88gJ9Cl lh4uVlp4uUSHgPQ9rTHnQJ5Ppm2AEEfzusy8vbFdAg42QLsUrZkOM0c3h74axsIZBhBAZjJmEjve fEaGnUIAKalZnaLEVKGPcQuEcgx9uBizWpUJLsY8NPJkYbu/HMbHbgEdwhkyCpJZuYyWIy1pse11 lNFivm2akmkHbqsDYDFF+NV7mDCQ8M4rMykSQEjSuq38+qh+JBbl2lFdkfuYaxvDOR1l58iPdIQ2 dIisEj9GtaFb7uGPBxqbg/KuSSj9wbLgf8hl34rm1b0RfFKSv+q7epylpofMjP5MoaoWTba3h5+K WutdTzN/40qy3lAqkWrqst8JcBpBtapOgTaEpuo16hlCGM+KLMsW9NPPVqeOAt7vexdTrdRzFy04 PuXMrgE8wmTX9xhlvYOV+D4MJuvDedVZZ31stguY1QBugxYTia7Ps+PMw6e6p1G8xg/RMLCSxmjw MWU+0Ig5ISvHuCGvphH8dRGt69WN7ICU/d6YLMvRBiuXQykyjAbfAf/MGKR8+hsM6qpFme+V5U2l oBvypEnvZL7J8qEQgQWPHuMOwCeddG9kZfDjOw3GNH0oIsYn4L/MTDsJnXoazJMDuWzbocZ/41Cs lcwd+pbd1r3eBKd+bfZdH6CzYppFD0U2EClBDFWXdPAmOFZu0AnJPHg2KEmS2iM3bIvJ7zsU+QoX zHKO5OtsL3a8kFpuPBtvKF5VGKGN/M7Dpap1K5Pmxs8cf3COGLA8jqbeTCD0lw9ruDeSd84O6Dc1 +TIzm2276GlHOtueLhRkwkMlsjAEu3L6NwNxy+smW/9jGQnXMXIE3ycrysPCx7G1B/+SVEmzs+7u MNgqh/k/0zriD2/cLNvBSLVBg7dUutdeoctBzSwsvIU/nvh5LIJ/hO4kEdIKOea4bqU/P9i0M3br jv2nZ2GJYe61SPtzYIApPa/kTsitV+h2XjUO993u6ePfx9++IYTLhOHRK+UZ+tv9Dd3xIV73pM9/ l5gVq2GS4YEkKuTWXfuW4yGV6B5/ukDTtllfzPAfhkXpb8a6xsby423zszzlm7goekotFtlOgbn6 /2OSfxZcf/HuURz4X7OZop4c5RHQAAAAAElFTkSuQmCCkgkAAEQAZAAAAAAAAAAAAAAAAAAAAAAA AAAAALgLbQsfAXkBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwmAAAALIECvAI AAAAAgQAAAAKAABjAAvwdAAAAARBAgAAAAXBUAAAAAYBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAEMA OgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAVwBvAGoAdABlAGsAXABFAFUAUgBBAFMASQBQ AF8AUwBJAEcATgAuAEcASQBGAAAAAAAQ8AQAAAABAACAYgAH8KYIAAAGBmmHvpDadqDZxOBtyi0P zbj/AIIIAAABAAAApR0AAAAAwQAAbh7weggAAGmHvpDadqDZxOBtyi0Pzbj/iVBORw0KGgoAAAAN SUhEUgAAAMgAAADDCAMAAADwQa5vAAADAFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIAEBAT8 /PwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMD/AAAA/wD//wAAAP//AP8A///////+ GzE6AAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAUKSURBVHic7djbEqMwCADQPur///DO7OxG kwDhHnTkKdUKnKqJ9Xe+JH67G/CKD1ItXgg5nhcQZHdPupgh42ZloGX8A4f4pY9XtFrXpx+wzZo9 xzH8+r95kzV5EuNvsWscAnHKxSnWxhEQp1SsYm3sDEl1fBBW5kRHHCTZEQbJdkRB0h1BkHxHDGSD IwSywxEFMWYwFv0gRM60+CB0znfc7K+Zft+zIL4HIpE4vaHY/fTr9s5o8/+RfwYHyd5/iBfALNn6 n/1+IqySna+D+gvKeHlFQhaSca9NEgohJfM+kyQWQvQG7bBIgiFob7LNvEJtHAFBJKITxa3TxiEQ UEK0q5XEQ4DeyGaVkgzI2NuiVZ1kA2Q1NxWGdL2t51iVJAcyPB2uCmgkSRDh87pCkgUR/oOSS9Ig 7aQIvizM3sbBEFlIJWUhUokEYnrMloesnAAiuVl9QlKNDblmnZoSLuS/oKyECbklLCrhQbp0NSUs yJCspIQDGVPl3id+kDlTRckaAuUpKFlC4Cz1JCsImqOaZAEhMqRLlv+P23iGkIfXkpCQxcGlJBSE czrLSEDI0Q/o5NYG+bG60Nv4gvwPW273oKqREGNu/6An0TYeIdbcAYFXIyDm3BFBLdBt3EPsuUMC q4ZCZKn3P61gEGnu3ZLDA1JBgkEUufdKnCDbn1YON8heyeEI2SkZJ1r1zX6lszYoKnZ/Skch5SWt WnsSMa/sc+6cOMZoe3TPWmNupzaZ1TiQZ8xdLMjDJG37DCkuEUBKSwSXlhaSIxFBCktGxwJSVjI5 VpCa68nMWEMqSiDHGlJPAjoYkGoS2MGB1JIgDhakkgRz8CB1JKiDCanytII72JASEsLBhxSQUA4B ZLuEdEggmyW0IwHiJXGEbJUsHDLIvvVkxZBCdknWDilkj4ThEEN2SDgOOSRfwnIoINkSnkMDyZUw HSpI5hrPdSghaRK2QwtJkvAdakiKRODQQxIkEocBEi4ROfIh/MPSIMESmcMEiVwZhQwjJE4idhgh URK5wwqJkSgcZkiEROOwQ/wlKocDxFuic3hAfNd4pcMH4ijROpwgbhK1wwviJNE73CAuEoPDD+Ig sTi2Q47x836IdT0xMVwhNonR4QqxSKwOX4hW4hG+kI0SZ0joy0ReYSeIXGIv2df1gogpHiWPEEjg e1FOUUdI3HtRTk1PSNh7UU5JVwhb4lUvDMKUuJWLg3AkfsWOQMha4ljriIQsKK6VjliI/1s4TqkQ yAFb/KskQI7RElIiB5ISH6RavB8CzzXjHXv/yJqasF3QkUTyOUccBOx41UW3X5Q8FjJ2vGqi3y9K Hgzpq2FAJQTOnQvBNkPFeMlXkP6nY0HQH3/lQ8ZzO5kQqNgdAvQwfUAh0IvvMMhcrHNAPQy1CAjQ XRxkytBDoDP1DMjggC85JgT4ehwE+epCcs6nEC0kggwF2JCpFpwP3kkkxzLkrSN0H+CuUhDCgT1j jMXQ4+HDYx8aQQc64bIg2KF+NztUignpKxDJ8eMCIGAZdkNwckAeDyGv09tX0JSREGqFbc1NENQx 9Zt2RoYmT6DWia+FcJ476gDGPpD+xyOnUaw3yAGxp5ShEGJC10LQlOmQubVuQQAdC8nUvD8En5yg Js7r3scqQzm7b0RBhl1wZ/erC+sBds+/jBFCxzKvJiwZTyWkWpyvhTxUcs6QR0pOCPI4yTnEb9zw 1Pgg1eKDVIvXQP4AAcYraZdmOkQAAAAASUVORK5CYIIDBgAARABkAAAAAAAAAAAAAAAAAAAAAAAA AAAA3gNlBPoD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBaAAAAsgQK8AgA AAADBAAAAAoAAGMAC/A2AAAABEEDAAAABcESAAAABgECAAAAgQERAAAQvwEAABAA/wEAAAgAaQBl AGUAZQAuAGcAaQBmAAAAAAAQ8AQAAAACAACAYgAH8FUFAAAGBpGSed8yQefj640WqOVuF3b/ADEF AAABAAAANycAAAAAwQAAbh7wKQUAAJGSed8yQefj640WqOVuF3b/iVBORw0KGgoAAAANSUhEUgAA AEIAAABLCAMAAADzhaESAAAAA3NCSVQICAjb4U/gAAAAYFBMVEX////v7+/W1t7W1ta1vcarq6ul paWUrcaUlJSMnK2IiIiEhIRzjK1ze3tra3Nra2tae6VSa4RSY2tSUlI+Pj45UmsxY5QtLS0hSnMY SoQWFhYODg4IQnsASoQAQnsAAADiyCPtAAAAAWJLR0T/pQfyxQAABFdJREFUeJy1mItyqzgMhvGl MQ4mMfTgxWdtv/9jruQLmDQJkM66Mx2R0C+/fknGadP874twTn5J0NYZ/iuE9iEEy35BkA4IwQ+f 58JsiMurTwk0E0Jwl88IxBRC8PYjS4mOf221AUO8oZ8SjBRCSJRz3lKi0AIttAvOCOWC12cZEnOQ yqVkpLDAO8dADUYMi58DxE6eYBDUoOVaEeSBN/I4QaENOYnSGVao4wyifHCqEIzKDCcPMwgWQery 8YKUHnUSRuaIH1SHmuBIs8RBHdJBDRJWI3XT8NUQTE/t6GBmowHygBeryqCO9wxu40dVhcDbRah1 gLI3DOnxpkoD5gEG24oBEt3wauawmEnqNo+mqaEW+vTV3NLYzoPYdJSCe6mo2xT6FC6fbsnc+vi+ DZsFZpjtK3DPDGJ+7GMpiTCvhDTowdGIcJU2p9Dfx+Fn+ZPUsNyGN3BXVAjC5aovVV3XhpT8dS6f s/FdirsEaYboCW3IosTwOTm72pDfc8W3SCDKhrXBLVSBL4xcNrtMTHxkRZ+KmrWSgChV1ksEMvJ2 VgrTZoQtZhqEJ1s8jXsgrmHtj4LwbZbBJ7/Rl2SkPgkk9zdsnXRJRCes911GsHbyEeJ46YHYflwZ awUzbrZaUlIVPN/np0uuCuX96JDhqt4cRPSUUsYpIVCdenyjWu+mW0EQxrtx9ptU0BqjleBccKG0 qZtWxTT8PN5atvQX4+0tGuLEQztbIX82uI0SgMDJ2qKEXfoJp+RxSMBY6h4IU0qiv7BNjwOjG134 MaqAIJsXLIfHNCbR1RKKqW1k6A1DPSDmOHxAuDw7xoEhaKpTsvobsUVYLIyfxscklmTAVGRItUFQ XxNgeIHAnxOiIY8MUW+dM2oAIzv++gy4MPQzRHzUu1jLl4QnOmBvKqc23DS92/TTK0ZfM5wxZiE4 BwQwcud5VhhqeziAWlsXbCS8B9SMuk8tPNUdNNSrYr5g6HVe8MDmgjumITNuOPyGJ0MANoTo5FFC ZECvOzzpmRnOjDGlU4TCCDh0nHOcinMaIoO3aUOFokYW7lCnCA1ZGGn5RPi637+OQxjvZ18RsCev 33++r9dTjNJcbk5zcW/+/Qd+Hc8FLE0y/IxbVIOIv3/PICpLx7zJfX/9uV6/TyCA0cOO7P3Ul/3h fr+fIqAd8Ig6X86NDNaO4/4G8Z7BL/3B4Xyjg/HdLWa7uNa8EVor+IEILnsNV7KhKr24dwLH8y98 u9Y+rYHIElGeo/0vrIhgyvt5gtVRmSNAhBwdQ4CKGwcPGF5OMSKgYm5jdFiF7pSOiHmACFyBHAal 9P6X96IirrYpXnQkeXHk/xBJBQ533/cc7ZwxuhD0YoSo3f3uXlQMnGLacDliRDGR+RKjo15YeIgZ FRPBSMdEYrTLULUXEytezGzpi10/2TC2MOPj7XYbbi1lKRo7xjqMbnCy2M2EwEQQwiBrBod/PHei AZTECNcv/8v1fP0Hy9DCyp7c5GUAAAAASUVORK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIAAAAIAAAATgAAQPH/AgBOAAwAAgBc1ADJAAAUAAAA AyQDMSQANCQANyQAOCQAYSQDJABLSAIAT0oIAFBKCABfSAEEYUoYAG1ICQRuSBIEc0gJBHRIEgQ0 AAFAAQACADQADAAEABzIqbogADEAAAAOAAEAAyQBBiQBQCYAYSQBDABDSiAAT0oHAFFKBwAAAFIA AwABAAIAUgAMAAQAHMipuiAAMwAAACYAAwADJAAGJAERhHgFMSQBNCQBNyQBOCQBQCYCV0S8AmCE eAVhJAASADYIgUtIAABPSgAAUEoJAF0IgQAAAAAAAAAAAAAAACAAQUDy/6EAIAAMAAgAMK74vCAA 6LJ9tyAAAK40rwAAAAAAAAAAAAAAACYAVUCiAPEAJgAMAAUAWNV0x3zTwbls0AAADAA+KgFCKgJw aAAA/wA0AFZAogABATQADAAMAFjVdMd808G5bNAgAOSyTMcgADi7kMf0xQAADAA+KgFCKgxwaIAA gAAAAAAAlw8AAAUAACYAAAAA/////wAEAAD+DAAAJBEAAJMTAACXEwAACgAAAA8AAAAQAAAAEgAA AAAEAAANCgAA3QwAAIASAACXEwAACwAAAA0AAAAOAAAAEQAAAAAEAACXEwAADAAAAOsOAAARDwAA KA8AAFAPAAB6DwAAjg8AAJcPAAATWBT/FYQTWBT/FYQPAADw8AAAAAAABvAYAAAAAggAAAIAAAAG AAAAAQAAAAEAAAAHAAAATwAB8LAAAABiAAfwJAAAAAYGH6F26T4UPKdf/DOzh4STIv8ABxsAAAAA AAD/////AAAAAGIAB/AkAAAABgZph76Q2nag2cTgbcotD824/wCCCAAAAAAAAP////8AAAAAYgAH 8CQAAAAGBpGSed8yQefj640WqOVuF3b/ADEFAAAAAAAA/////wAAAABiAAfwJAAAAAYGRarKxgaa nxEHElhZQLvyof8AXWsAAAAAAAD/////AAAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALw kgAAABAACPAIAAAAAQAAAAYEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAA ywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAlw8AAP//AgAAAA0AXwBIAGwAdAA0 ADcAOQA2ADYAMwAwADYAMQANAF8ASABsAHQANAA3ADkANgA2ADMAMAA2ADIAfg8AAH4PAACZDwAA AAAAQAEAAEB/DwAAfw8AAJkPAAAAAAAAoQIAAKgCAAC4BgAAwQYAAEgIAABUCAAAwQgAAMoIAAA5 CQAAPQkAAG0JAAB5CQAAjQkAAJIJAACTCQAAnAkAALMJAAC7CQAA+QkAAP4JAAD/CQAABgoAADgK AABACgAAUAoAAFUKAABxCgAAegoAAMAKAADICgAA3QoAAOYKAAACCwAABwsAAAgLAAAOCwAAKgsA AC8LAAAwCwAANAsAAIQLAACJCwAAyQsAAMsLAAACDAAACAwAABsMAAAfDAAANAwAADcMAABHDAAA TQwAAE4MAABUDAAAgAwAAIcMAAClDAAAqwwAAB0NAAAfDQAA3A0AAOUNAADnDQAA7Q0AAJkPAAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAAAAAAFsNAABjDQAAKQ8AAC8PAACZDwAABwAzAAcAMwAHAP//FAAAAAoA SgBhAGUAeQBvAHUAbgAgAFkAaQAbAEQAOgBcALXR4MKpxlwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAYAdgBpAHMAYwBvAG0AFwBEADoAXABQAEMAUwAtAGMAYQBsAGwA ZgBvAHIAcABhAHAAZQByAC4AZABvAGMABgB2AGkAcwBjAG8AbQAsAEMAOgBcAFcASQBOAEQATwBX AFMAXABUAEUATQBQAFwAkMfZsyAA9bxsrSAAAMilx1AAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBhAHMAZAAMAEoAbwBuAGcAIABCAGUAbwBtACAAUgBhACsAQwA6AFwAagBiAHIAYQBc AEwAYQBiAEoAbwBiAHMAXAD8yFzNXABQAEMAUwBcAFAAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBkAG8AYwAMAEoAbwBuAGcAIABCAGUAbwBtACAAUgBhACsAQwA6AFwAagBiAHIAYQBc AEwAYQBiAEoAbwBiAHMAXAD8yFzNXABQAEMAUwBcAFAAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBkAG8AYwAFADjWIACUxiAAMcEgAEUAOgBcAFAAQwBTADIAMAAwADEAXABQAEMAUwAt AGMAYQBsAGwAZgBvAHIAcABhAHAAZQByAHMALgBkAG8AYwAEABVckg1YYdzW/w//D/8P/w//D/8P /w//D/8PEABoHucxWGHc1v8P/w//D/8P/w//D/8P/w//DxAA7wa2PlJO4kX/D/8P/w//D/8P/w// D/8P/w8QAHIN43sBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQABAAAAFxAAAAAAAAAAAAAAkAEAAAAA AAALGAAAD4SQARGEcP4VxgUAAZABBl6EkAFghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAA AAAAAJABAAAAAAAACxgAAA+EIAMRhHD+FcYFAAEgAwZehCADYIRw/k9KCgBRSgoAbygAAQBu8AEA AAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5PSgoAUUoK AG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZg hHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E0AcRhHD+FcYF AAHQBwZehNAHYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAP hGAJEYRw/hXGBQABYAkGXoRgCWCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEA AAAAAAALGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAA AAAAAAAAAJABAAAAAAAACxgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw/k9KCgBRSgoAbygAAQBu 8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP5PSgoA UUoKAG8oAAEAdfABAAAAFxAAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TIABGEOP8VxgUAAWgBBl6E yABghDj/T0oKAFFKCgBvKAABAHfwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EIAMRhHD+ FcYFAAEgAwZehCADYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsY AAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAA kAEAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQ AAAAAAAAAAAAAJABAAAAAAAACxgAAA+E0AcRhHD+FcYFAAHQBwZehNAHYIRw/k9KCgBRSgoAbygA AQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP5P SgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TwChGEcP4VxgUAAfAK Bl6E8ApghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EgAwR hHD+FcYFAAGADAZehIAMYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAA AAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP5PSgoAUUoKAG8oAAEAdfABAAAAFxAAAAAAAAAA AAAAkAEAAAAAAAALGAAAD4QgAxGEcP4VxgUAASADBl6EIANghHD+T0oKAFFKCgBvKAABAGzwAQAA ABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EsAQRhHD+FcYFAAGwBAZehLAEYIRw/k9KCgBRSgoA bygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhEAGEYRw/hXGBQABQAYGXoRABmCE cP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TQBxGEcP4VxgUA AdAHBl6E0AdghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E YAkRhHD+FcYFAAFgCQZehGAJYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAA AAAAAAsYAAAPhPAKEYRw/hXGBQAB8AoGXoTwCmCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAA AAAAAAAAkAEAAAAAAAALGAAAD4SADBGEcP4VxgUAAYAMBl6EgAxghHD+T0oKAFFKCgBvKAABAGzw AQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EEA4RhHD+FcYFAAEQDgZehBAOYIRw/k9KCgBR SgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhKAPEYRw/hXGBQABoA8GXoSg D2CEcP5PSgoAUUoKAG8oAAEAdfABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SpARGEV/4V xgUAAakBBl6EqQFghFf+T0oKAFFKCgBvKAABAGzwBAAAAO8Gtj4AAAAAAAAAAAAAAAAVXJINAAAA AAAAAAAAAAAAaB7nMQAAAAAAAAAAAAAAAHIN43sAAAAAAAAAAAAAAAD///////////////////// //8EAAAAAAAAAAAAAAD/QAIQAAAAAAAAAJcPAABQAAAIAEAAAAsAAABHFpABAAACAgYDBQQFAgME AwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1 FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAALxWQAYEAAgMG CQABAQEBAQEAAAAAAAYJEAAAAAAAAAAAAAgAAAAAABS81dC0zAAALzWQAYEAAgsGCQABAQEBAQEA AAAAAAYJEAAAAAAAAAAAAAgAAAAAAMuzwMa0zAAAVxKQAQAIAAAAAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAABAAAAAAAAAEMAZQBuAHQAdQByAHkAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEA bgAAAEUmkAEAAAILBQICAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAGUAbgB0AHUAcgB5 ACAARwBvAHQAaABpAGMAAAA3JpABAAACCwYEAwUEBAIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAA VgBlAHIAZABhAG4AYQAAAC0WkAGBAAIDBgAAAQEBAQEBAAAAAAAGCRAAAAAAAAAAAAAIAAAAAAAU vNXQAAAtNpABgQACCwYAAAEBAQEBAQAAAAAABgkQAAAAAAAAAAAACAAAAAAAdK28uQAAOwaQAQIA BQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAIAAE AHEIiBgAACADAABoAQAAAAB2W0dGdltHRu/bRIYDAAAAAABBAgAA2gwAAAEABgAAAAQAAxAbAAAA AAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAAAAAAAAAiABMAIQAlACkALAAuADoAOwA/AF0AfQCi ALAAGSAdIDIgMyADIQkwCzANMA8wETAVMAH/Bf8J/wz/Dv8a/xv/H/89/13/4P8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAWwBcAHsAowClABggHCAIMAowDDAOMBAwFDAE/wj/O/9b/+b/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL0C iQO0ABEBgYAyAAAAEAAZAGQAAAAZAAAAyA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAADQAoAFAA cgBlAGwAaQBtAGkAbgBhAHIAeQApAAAAAAAAAAoASgBhAGUAeQBvAHUAbgAgAFkAaQAFADjWIACU xiAAMcEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJABAAASAAAA AQAAAJgAAAACAAAAoAAAAAMAAAC4AAAABAAAAMQAAAAFAAAA2AAAAAYAAADkAAAABwAAAPAAAAAI AAAABAEAAAkAAAAYAQAAEgAAACQBAAAKAAAAQAEAAAsAAABMAQAADAAAAFgBAAANAAAAZAEAAA4A AABwAQAADwAAAHgBAAAQAAAAgAEAABMAAACIAQAAAgAAALUDAAAeAAAADgAAAChQcmVsaW1pbmFy eSkAbwAeAAAAAQAAAABQcmUeAAAACwAAAEphZXlvdW4gWWkAeR4AAAABAAAAAGFleR4AAAABAAAA AGFleR4AAAALAAAATm9ybWFsLmRvdAB5HgAAAAkAAADIoyC/5CC8ugB0AHkeAAAAAgAAADMAIL8e AAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAAQAAAAAAAAAAAAAAAQAAAAABKNmMUsL8BQAAAAACk /wb06r8BQAAAAACk/wb06r8BAwAAAAEAAAADAAAAQQIAAAMAAADaDAAAAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoC AAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu XAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACgAAAABgAAAKgAAAARAAAAsAAAABcAAAC4 AAAACwAAAMAAAAAQAAAAyAAAABMAAADQAAAAFgAAANgAAAANAAAA4AAAAAwAAAD6AAAAAgAAALUD AAAeAAAAJgAAAElTTCwgRGl2LiBvZiBFRSwgRGVwdC4gb2YgRUVDUywgS0FJU1QARQADAAAAGwAA AAMAAAAGAAAAAwAAAMgPAAADAAAA8Q4IAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAEAAAAOAAAAKFByZWxpbWluYXJ5KQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAABc AgAABAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAAAAMAAACyAAAAAgAAAAIAAAAKAAAAX1BJRF9H VUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAALUDAABBAAAATgAAAHsAQgAyADMAMgAyADgAQwAw AC0ANQA3ADMAMgAtADEAMQBEADQALQA4ADcAOQA2AC0AMAAwADYAMAA5ADcAMQA5ADcAOAA2ADMA fQAAAAAAQQAAAKABAAAYAAAAAwAAABAAKQADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGwAA AG0AYQBpAGwAdABvADoAcABjAHMAQABwAGMAcwAuAGsAYQBpAHMAdAAuAGEAYwAuAGsAcgAAAAAA HwAAAAEAAAAAAAAAAwAAAHAAYwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0 AHAAOgAvAC8AcABjAHMALgBrAGEAaQBzAHQALgBhAGMALgBrAHIALwAAAB8AAAABAAAAAAAAAAMA AABXABcAAwAAAJMTAAADAAAAAgQAAAMAAAABAAAAHwAAACgAAABDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAFcAbwBqAHQAZQBrAFwARQBVAFIAQQBTAEkAUABfAFMASQBHAE4ALgBHAEkA RgAAAB8AAAABAAAAAAAAAAMAAABLAAEAAwAAAJUTAAADAAAAAwQAAAMAAAABAAAAHwAAAAkAAABp AGUAZQBlAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAA AAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA EwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA/v///ywAAAAtAAAALgAAAC8A AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v///zgAAAA5AAAAOgAAADsAAAA8AAAAPQAA AD4AAAD+////QAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAP7////9////SQAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////// ////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAYPxkFvTqvwGgqlAZ9Oq/AUsAAACAAAAAAAAAAEQA YQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FAAAAPYsAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAArAAAAwhYAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2JgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwAAAAAQAAAAAAAABQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ AAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAA AMAAAAAAAABGFAAAAE1pY3Jvc29mdCBXb3JkILmuvK0ACgAAAE1TV29yZERvYwAQAAAAV29yZC5E b2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_003D_01C02DDA.EC7B5500-- From rem-conf Tue Oct 03 22:15:55 2000 From rem-conf-request@es.net Tue Oct 03 22:15:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ggpE-0001I6-00; Tue, 3 Oct 2000 22:10:40 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ggp9-0001GU-00; Tue, 3 Oct 2000 22:10:37 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA09294; Wed, 4 Oct 2000 00:44:46 -0400 Message-Id: <200010040444.AAA09294@purple.east.isi.edu> To: Yoshihiro Kikuchi cc: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Yoshihiro Kikuchi of "Tue, 03 Oct 2000 18:00:30 +0900." <038001c02d18$6335a920$16c77885@ave> Date: Wed, 04 Oct 2000 00:44:46 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Yoshihiro Kikuchi writes: >> When the short video header mode is used, RTP payload format for H.263 >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. You should specify which of RFC 2190 or RFC 2429 is intended. >This means that it is RECOMMENDED to use the H.263 RTP payload format for >the short video header which is compatible with H.263 baseline. Regardless >of MAY or SHOULD, there is a possibility that the H.263 RTP payload format >may be used, although the possibility may be higher for SHOULD than MAY. If >you really don't want to use the H.263 RTP payload format in some >circumstances, you don't have to use it. The payload format is signaled >through the MIME type. > >(IETF experts, please correct me if my understanding on the definition of >SHOULD is wrong.) SHOULD = "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." MAY = "an item is truly optional" [see RFC 2119 for the full wording] Colin From rem-conf Tue Oct 03 22:15:55 2000 From rem-conf-request@es.net Tue Oct 03 22:15:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ggpA-0001H8-00; Tue, 3 Oct 2000 22:10:36 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ggp3-0001GR-00; Tue, 3 Oct 2000 22:10:32 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA09317; Wed, 4 Oct 2000 00:50:31 -0400 Message-Id: <200010040450.AAA09317@purple.east.isi.edu> To: Kris Huber cc: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, "'Yoshihiro Kikuchi'" Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Kris Huber of "Tue, 03 Oct 2000 12:50:10 MDT." <6E031E06378BD311AEF20090273CE1BA81E6EF@el-postino.s-vision.com> Date: Wed, 04 Oct 2000 00:50:31 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A brief note - the issue of the timestamp is one area where I had some concerns with this draft, but unfortunately I haven't had enough spare cycles this past week to follow up on them. This is likely just my mis- understanding, but input from those who know both MPEG4 and RTP, to ensure that this is both accurate and consistent with the two timing models, would be greatly appreciated. Colin --> Kris Huber writes: >Hello Guido, > >I think you are right. It appears that the other alternative (change MAY to >SHALL or SHOULD) was taken rather than insertion of the MPEG-4 visual >semantics regarding picture rate in short header mode (which lacks >modulo_time_base, vop_time_increment, and vop_time_increment_resolution). >These were spelled out for short header in >draft-ietf-avt-rtp-mpeg4-es-04.txt based on a suggestion I made (e-mail of >9/8/00 "RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - >timestamp of short header VOP"). > >Since then, I have learned that a more typical way (I think) that >hardware-assisted compression systems are used with PAL devices is with the >picture clock frequency driving the temporal_reference/TR field set to 25 Hz >rather than giving rounded values of a 30 Hz picture clock. However, my >suggestion does match baseline H.263 and MPEG-4 short-header mode, although >I think H.263 implementers have been a little loose in their interpretation, >perhaps with good reason. > >Another opinion I respect is that a better partitioning of functions would >have placed all timing information in the systems part, as (I think) was >done for the audio part. But on the other hand you can't properly decode >video without some timing information (sequence number at least) due to >temporal prediction and B-VOPs. > >I heard no discussion of the text I proposed for clarification of the >timestamp relationship to temporal_reference in short header mode after Gary >Sullivan's clarifications and suggestion that MAY be changed to SHALL. I'm >not on the IETF AVT mailing list or at other meetings where the discussion >probably occurred. > >Regards, >Kris > >-----Original Message----- >From: Franceschini Guido [mailto:Guido.Franceschini@cselt.it] >Sent: Tuesday, October 03, 2000 12:20 AM >To: IETF AVT; 4on2andIP-sys; 'Yoshihiro Kikuchi' >Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > > >Change (2) means that significantly different packets are generated in case >of Short Video Headers (H263) between the original proposal and this new >version. Am I right, or is this just an editorial matter ? > >Best regards >Guido > >> ---------- >> From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] >> Sent: Tuesday, October 03, 2000 3:36 AM >> To: IETF AVT; 4on2andIP-sys >> Cc: Yoshihiro Kikuchi >> Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision >> >> <> >> Dear experts, >> >> Attached find please a draft text for the revision of MPEG-4 Audio/Visual >> RTP Internet-Draft. >> >> The revisions are mostly to reflect suggestions by the AVT chair. Most of >> them are editorial and there are some minor revisions and clarifications. >> The following is a summary of the changes: >> >> (1) MIME subtype names were changed to "video/MP4V-ES" for video and >> "audio/MP4A-LATM" for audio. >> (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short >> video header mode was changed to "MAY" to "SHOULD". >> (3) Clarification of timestamp definition >> There was a suggestion not to describe the detailed definition of the >> video timestamp in the RTP spec. and change it as a reference to MPEG-4 >> visual document, so as to keep consistency with the MPEG-4 visual. A >> description about the RTP timestamp in the RTCP SR packet was added. >> (4) SA/TTSI over LATM >> A description was added to restrict the LATM usage so as not to >> transmit >> SA data by LATM. >> (5) Other editorial and wording changes. >> >> Please let us know if there is comment on the attached draft. The authors >> need to submit it soon as an updated I-D and hopefully final before RFC. >> >> Best regards, >> Yoshihiro Kikuchi >> and authors of the Internet Draft >> >> ---- >> 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 1267 >> >> >> From rem-conf Wed Oct 04 01:38:23 2000 From rem-conf-request@es.net Wed Oct 04 01:38:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gk1G-0007NF-00; Wed, 4 Oct 2000 01:35:18 -0700 Received: from p-mail2.rd.francetelecom.fr (p-mail2.cnet.fr) [193.49.124.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13gk1F-0007Li-00; Wed, 4 Oct 2000 01:35:17 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4HLBQZS7>; Wed, 4 Oct 2000 10:34:02 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Cc: CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, 'Olivier Avaro' Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 10:35:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list dear all, *********Jan proposed: - ObjectDescriptorStream - ClockReferenceStream (is this needed over IP ?) - SceneDescriptionStream - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - FlexMux stream - MP4 file *****Olivier found in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream (or MPEG-J Streams as Viswanathan said) *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams ******about the muxcode table in band/out of band: Dave said that :"The MuxCodeTable needs to be delivered out-of-band". **it certainly needs to be delivered. Pierre showed how it is possible to deliver it, accurately in time, by=20 out of band means **But is 'out of band' compatible with a multicast or broadcast = scenario. **So, I think agree with Jan that an inband means is necessary. regards Dominique _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel=20 > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ From rem-conf Wed Oct 04 02:40:42 2000 From rem-conf-request@es.net Wed Oct 04 02:40:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gkz0-00021R-00; Wed, 4 Oct 2000 02:37:02 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gkyx-00021H-00; Wed, 4 Oct 2000 02:36:59 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA00725; Wed, 4 Oct 2000 11:36:57 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma000721; Wed, 4 Oct 00 11:36:57 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA21804; Wed, 4 Oct 2000 11:36:57 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA08319; Wed, 4 Oct 2000 11:36:56 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014577469; Wed, 4 Oct 2000 11:38:00 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014577469000002L992*@MHS> Date: Wed, 4 Oct 2000 11:38:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/04/00 12:35:15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dominique, all, Dominique wrote: *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams A few comments : 1) I don't think that SL stream is an additional stream type; in my vie= w SL streams are included in the stream types that use MPEG-4 systems. 2) The wording MP4 file stream is confusing; I don't think there is a n= eed to "stream" an MP4 file; instead only a mime type is needed for file transfer. A question : for which streams we need to specify use of RTP and SDP ? = In my understanding for : - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - FlexMux stream Can we assume that the following streams are probably most efficiently contained in a FlexMux stream, and consequently that is no need to spec= ify use of RTP and SDP for those streams: - ObjectDescriptorStream - ClockReferenceStream - SceneDescriptionStream - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - MPEGJStream Regards, Jan -----Original Message----- From: dominique.curet@rd.francetelecom.fr [mailto:dominique.curet@rd.francetelecom.fr] Sent: woensdag, 04 oktober, 2000 10:39 To: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Cc: olivier.avaro@francetelecom.fr; Jan vanderMeer; dominique.curet@francetelecom.fr Subject: RE: Types of MPEG-4 streams over IP dear all, *********Jan proposed: - ObjectDescriptorStream - ClockReferenceStream (is this needed over IP ?) - SceneDescriptionStream - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - FlexMux stream - MP4 file *****Olivier found in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream (or MPEG-J Streams as Viswanathan said) *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams ******about the muxcode table in band/out of band: Dave said that :"The MuxCodeTable needs to be delivered out-of-band". **it certainly needs to be delivered. Pierre showed how it is possible to deliver it, accurately in time, by out of band means **But is 'out of band' compatible with a multicast or broadcast scenari= o. **So, I think agree with Jan that an inband means is necessary. regards Dominique _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ = From rem-conf Wed Oct 04 04:18:28 2000 From rem-conf-request@es.net Wed Oct 04 04:18:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gmVy-0005r6-00; Wed, 4 Oct 2000 04:15:10 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gmVu-0005qU-00; Wed, 4 Oct 2000 04:15:07 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id UAA14754; Wed, 4 Oct 2000 20:15:02 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id UAA13966; Wed, 4 Oct 2000 20:15:02 +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 UAA04794; Wed, 4 Oct 2000 20:15:01 +0900 (JST) Received: from ave (srg-204 [133.196.81.204]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id UAA98250; Wed, 4 Oct 2000 20:15:01 +0900 (JST) Message-ID: <067f01c02df4$61442560$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Colin Perkins" Cc: "IETF AVT" , "Yoshihiro Kikuchi" References: <200010040444.AAA09294@purple.east.isi.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Wed, 4 Oct 2000 20:15:19 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin, all, > >> When the short video header mode is used, RTP payload format for H.263 > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > You should specify which of RFC 2190 or RFC 2429 is intended. > Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? Or, if ITU-T does not have any preference, I'm not sure if it is really necessary to change the text to decide this in "MPEG-4" RTP payload spec. Best regards, Yoshihiro ---- 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 1267 From rem-conf Wed Oct 04 04:19:36 2000 From rem-conf-request@es.net Wed Oct 04 04:19:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gmYV-0005zI-00; Wed, 4 Oct 2000 04:17:47 -0700 Received: from eolo.inm.es (inm.es) [193.144.152.132] by mail1.es.net with smtp (Exim 1.81 #2) id 13gmYJ-0005sL-00; Wed, 4 Oct 2000 04:17:36 -0700 Received: from maish13 (sdn-ar-001wimadiP290.dialsprint.net) by inm.es (5.x/SMI-SVR4) id AA02301; Wed, 4 Oct 2000 11:04:11 +0100 Message-Id: <10010041004.AA02301@inm.es> From: "Dave" Reply-To: Dave_Bo821@mail.sol.dk Subject: Re: Here Is The Information As Your Requested To: Dave_93@mail.sol.dk X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 04 Oct 2000 07:46:05 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You were recently referred to me as someone who was ready for a CHANGE, a financial breakthrough, so I'll get right to the point=2E I am the one that can help you make $125,000 plus this year from HOME with your computer and phone=2E This is Not MLM and it IS very REAL=2E Are you Serious about making $2000 plus per week starting Right Away with a SIMPLE system where customers are contacting you and you do absolutely ZERO selling? Can you follow simple step-by-step instructions and put forth the effort to make this a reality for yourself starting today? If your answer is YES, then we need to talk=2E I have few positions available on my team and its in my best interest to train you for success=2E In fact, I'm so sure that I can do so, I'm willing to put my money where my mouth is! Upon accepting you as a member on my team, I will provide you with complete Professional Training and Advertising Assistance to put you immediately on the road to success=2E No experience necessary=2E=2E=2E=2E However you must have two qualities: moderate people skills and a serious desire for a personal and financial change=2E Take a moment to take the next step by calling me at my Home Office and I will get you the details=2E 1-800-318-8477 24 Hrs/ 7 Days Prosperous Regards! Dave "Profits are better than wages=2E Wages make you a living; Profits make you a fortune" - Jim Rohn To be removed send email to boonmeri@yahoo=2Ecom From rem-conf Wed Oct 04 06:44:22 2000 From rem-conf-request@es.net Wed Oct 04 06:44:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gokg-0004lz-00; Wed, 4 Oct 2000 06:38:30 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gokf-0004li-00; Wed, 4 Oct 2000 06:38:29 -0700 Received: from young ([203.238.126.154]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000100422375907:32895 ; Wed, 4 Oct 2000 22:37:59 +0900 Message-ID: <007f01c02e07$a9411f40$9a7eeecb@techway.co.kr> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: , Cc: , <4on2andIP-sys@advent.ee.columbia.edu> References: <0056890014577469000002L992*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 22:33:20 +0900 Organization: MP4CAST MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-04 10:37:59 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-04 10:38:10 PM, Serialize complete at 2000-10-04 10:38:10 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBKYW4sIERvbWluaXF1ZSBhbmQgYWxsLA0KDQoNCj5Eb21pbmlxdWUgd3JvdGU6DQo+Kioq KioqKnNvLCB0byBteSB1bmRlcnN0YW5kaW5nLCBhdCBsZWFzdDoNCj4gMyBzdHJlYW1zIGFyZSBt aXNzaW5nOiBGbGV4bXV4IHN0ZWVhbXMsIFNMIHN0ZWFtcyAmIE1QNCBmaWxlIHN0cmVhbXMNCg0K PkEgZmV3IGNvbW1lbnRzIDoNCj4xKSBJIGRvbid0IHRoaW5rIHRoYXQgU0wgc3RyZWFtIGlzIGFu IGFkZGl0aW9uYWwgc3RyZWFtIHR5cGU7IGluIG15IHZpZXcgU0wNCj5zdHJlYW1zIGFyZSBpbmNs dWRlZCBpbiB0aGUgc3RyZWFtIHR5cGVzIHRoYXQgdXNlIE1QRUctNCBzeXN0ZW1zLg0KDQo9PT4g SW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIHN0cmVhbXR5cGUgaWRlbnRpZnkgdGhlIGNvbnRlbnQg b2YgdGhlIGJpdHN0cmVhbS4gSWYgeW91IHdhbnQgdG8gaWRlbnRpZnkgdGhlIGZvcm1hdCBvZiB0 aGUgc3RyZWFtIGl0IGlzIHVzZWZ1bCB0byBkaWZmZXJlbnRpYXRlIFNMIHN0cmVhbSwgRmxleE11 eCBzdHJlYW0gYW5kIEVTIG9mIGVhY2ggbWVkaWEgc3RyZWFtcyBhbmQgZXRjLiBCdXQgaWYgeW91 IHdhbnQgdG8gZGlmZmVyZW50aWF0ZSB0aGUgY29udGVudCBvZiB0aGUgc3RyZWFtcywgdGhlbiB0 aGVyZSBpcyBubyBuZWVkIHRvIGRpZmZlcmVudGlhdGUgU0wgc3RyZWFtcyBmcm9tIG90aGVycy4g V2hhdCBpcyB5b3VyIGludGVudGlvbiBmb3Igc3RyZWFtIHR5cGUgZGlzY3Vzc2lvbnM/DQoNCg0K PjIpIFRoZSB3b3JkaW5nIE1QNCBmaWxlIHN0cmVhbSBpcyBjb25mdXNpbmc7IEkgZG9uJ3QgdGhp bmsgdGhlcmUgaXMgYSBuZWVkDQo+dG8gInN0cmVhbSIgYW4gTVA0IGZpbGU7IGluc3RlYWQgb25s eSBhIG1pbWUgdHlwZSBpcyBuZWVkZWQgZm9yIGZpbGUNCj50cmFuc2Zlci4NCg0KPT0+IEkgYWdy ZWUgd2l0aCB0aGlzLiBJbiBhbnkgY2FzZSB0aGVyZSBpcyBubyBNUDQgc3RyZWFtLg0KDQo+QSBx dWVzdGlvbiA6IGZvciB3aGljaCBzdHJlYW1zIHdlIG5lZWQgdG8gc3BlY2lmeSB1c2Ugb2YgUlRQ IGFuZCBTRFAgPyBJbiBteQ0KPnVuZGVyc3RhbmRpbmcgZm9yIDoNCg0KPi0gVmlzdWFsU3RyZWFt ICh3aXRoIGFuZCB3aXRob3V0IHVzZSBvZiBNUEVHLTQgU3lzdGVtcykNCj4tIEF1ZGlvU3RyZWFt ICh3aXRoIGFuZCB3aXRob3V0IHVzZSBvZiBNUEVHLTQgU3lzdGVtcykNCj4tIEZsZXhNdXggc3Ry ZWFtDQoNCj5DYW4gd2UgYXNzdW1lIHRoYXQgdGhlIGZvbGxvd2luZyBzdHJlYW1zIGFyZSBwcm9i YWJseSBtb3N0IGVmZmljaWVudGx5DQo+Y29udGFpbmVkIGluIGEgRmxleE11eCBzdHJlYW0sIGFu ZCBjb25zZXF1ZW50bHkgdGhhdCBpcyBubyBuZWVkIHRvIHNwZWNpZnkNCj51c2Ugb2YgUlRQIGFu ZCBTRFAgZm9yIHRob3NlIHN0cmVhbXM6DQoNCj4tIE9iamVjdERlc2NyaXB0b3JTdHJlYW0NCj4t IENsb2NrUmVmZXJlbmNlU3RyZWFtDQo+LSBTY2VuZURlc2NyaXB0aW9uU3RyZWFtDQo+LSBNUEVH LTdTdHJlYW0NCj4tIElQTVBTdHJlYW0NCj4tIE9iamVjdENvbnRlbnRJbmZvU3RyZWFtDQo+LSBN UEVHSlN0cmVhbQ0KDQpJbiBnZW5lcmFsIHdlIGFyZSBub3QgYWxsb3dlZCB0byBhc3N1bWUgdGhp cyBjb25kaXRpb24gYmVjYXVzZSB0aGVyZSBpcyBubyBub3JtYXRpdmUgbGltaXRhdGlvbiB0byB0 aGlzIGV2ZW4gdGhvdWdoIHByYWN0aWNhbGx5IGl0IGlzIHZhbGlkLiBEbyB5b3Ugd2FudCB0byBw dXQgYSBub3JtYXRpdmUgdXNhZ2Ugb2YgRmxleE11eCBmb3IgdGhvc2UgY2FzZXM/ICBBbmQgSSB0 aGluayBJUE1QIHN0cmVhbXMgc2hvdWxkIG5vdCBiZSBtdWx0aXBsZXhlZCB3aXRoIG90aGVyIHN0 cmVhbXMuDQoNClNpbmNlcmVseSwNCllvdW5nLg0K From rem-conf Wed Oct 04 07:27:20 2000 From rem-conf-request@es.net Wed Oct 04 07:27:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gpTn-0000PU-00; Wed, 4 Oct 2000 07:25:07 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gpTm-0000PI-00; Wed, 4 Oct 2000 07:25:06 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA06267; Wed, 4 Oct 2000 16:24:59 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma006265; Wed, 4 Oct 00 16:24:59 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA23312; Wed, 4 Oct 2000 16:24:59 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA25697; Wed, 4 Oct 2000 16:24:58 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014590674; Wed, 4 Oct 2000 16:26:02 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014590674000002L942*@MHS> Date: Wed, 4 Oct 2000 16:26:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/04/00 17:23:14" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Young, You wrote : >Can we assume that the following streams are probably most efficiently= >contained in a FlexMux stream, and consequently that is no need to spe= cify >use of RTP and SDP for those streams: >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream In general we are not allowed to assume this condition because there is= no normative limitation to this even though practically it is valid. Do yo= u want to put a normative usage of FlexMux for those cases? And I think = IPMP streams should not be multiplexed with other streams. I am asking just for getting opinions; I am not sure how practical it i= s to have a separate session for each of the above streams. You may be right= that IPMP streams should not be multiplexed with other streams, but for that= case FlexMux could offer a useful multiplex solution for multiple IPMP messa= ges within an RTP payload. Kind regards, Jan = From rem-conf Wed Oct 04 08:07:32 2000 From rem-conf-request@es.net Wed Oct 04 08:07:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gq78-0003Jd-00; Wed, 4 Oct 2000 08:05:46 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gq73-0003J0-00; Wed, 4 Oct 2000 08:05:43 -0700 Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e94F5Ut16023; Wed, 4 Oct 2000 17:05:30 +0200 (MEST) Received: by lms001.lu.erisoft.se id RAA16490; Wed, 4 Oct 2000 17:05:28 +0200 (MET DST) Message-ID: <39DB4736.8DEF25F9@lu.erisoft.se> Date: Wed, 04 Oct 2000 17:05:26 +0200 From: Krister Svanbro Organization: Ericsson Research X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie , Magnus Westerlund CC: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Qiaobing, Magnus and others, I am Krister Svanbro and work mainly in the ROHC WG. I noticed that the ROHC WG name was mentioned below and thought I perhaps could bring some information from a ROHC point of view, which might help somewhat in this issue. The ROHC WG has spent year 2000 on mainly developing a robust header compression scheme for RTP/UDP/IP. We have also created a framework based on compression profiles to enable development of other compression profiles such as compression of TCP/IP the coming year. The term robust origins from that fact we realised that we need to design header compression schemes more robust to make them cope with the relative large amount of packet loss that occur in e.g. cellular systems. That does not, however, preclude in any way the usage of the ROHC scheme in other types of (possible error prone) environments. We have to this date not looked upon compression of RTP payloadformats and we do not plan to that either. I also think that there should not be any need for compression of payloadformats. They should be as efficient as possible from the beginning. AMR is certainly a highly interesting codec in usage together with ROHC to enable VoIP to a mobile, hence it is important that the AMR format is efficient and does not waste any bits. It becomes kind of strange if we in the ROHC WG maximize compression efficiency with rather sofisticated methods to enable to go down to a compressed header size of 1 byte for the IP/UDP/RTP header, and then is 1 byte extra used for the RTP payloadformat only. Hence, I would like to encourage you to keep efficiency in mind when developing this payload format. I look forward to see the results of this work. Cheers, / Krister Qiaobing Xie wrote: > > Hi, Magnus, > > See my comments below.... > > Magnus Westerlund wrote: > > > > Hello, > > > > The payload format is designed with IP networks in mind. The problem we see is > > that IP is transported over a wide range of different links with different > > behavior, e.g. different radio and wireline links. Radio and wire do not have > > the same error characteristics. AMR will be widly used over wireless links and > > on these links bandwidth efficiency is extremely important. This lead to the > > bitwise sorting. Octet sorting needs octet alignement for each block of the > > payload, i.e. padding at the end of each block. Which we considered to be to > > expensive. > > This further convinces me that the current design presented in the AMR > draft is a radio-link-centric design, which is wrong in my opinion, > because: > > 1) bandwidth efficiency over wireless links is more of a concern for > ROHC working group. Architecturally, it should be delt with below IP by > header compression/stripping, as being worked upon in rohc. It doesn't > belong to RTP payload layer (unless it is something facilitating the > underlying header compression/stripping). From rem-conf Wed Oct 04 08:17:50 2000 From rem-conf-request@es.net Wed Oct 04 08:17:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqIB-0004Wu-00; Wed, 4 Oct 2000 08:17:11 -0700 Received: from mailhost.talarian.com (phobos.talarian.com) [207.5.32.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqIA-0004T9-00; Wed, 4 Oct 2000 08:17:10 -0700 Received: from VAIO (ta037.talarian.com [204.147.187.37]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id IAA02018; Wed, 4 Oct 2000 08:16:11 -0700 (PDT) From: "Phil Farrar" To: Subject: Seminar: Catch the Vision of IP Multicast Date: Wed, 4 Oct 2000 10:07:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2919.6700 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by phobos.talarian.com id IAA02018 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Learn first hand about the latest advances in IP multicast technology in = a half-day seminar. (Registration is filling fast! Reserve your seat now!) Get expert advice on creating efficient one-to-many communications from industry leaders Talarian, Nortel Networks and SkyStream. Join us for registration and continental breakfast beginning at 8:00 am. The seminar program runs from 9 am =96 12 noon. Talarian, a leader in real-time publish-subscribe messaging and reliable multicast is hosting the seminar series. Seating is limited so register now! www.talarian.com/seminar or call 800-543-8096 If you're a software developer, network architect, CIO, CTO or Director o= f MIS, this seminar is for you. Hear presentations about: =B7 New developments in IP multicast technology =B7 How to know when to use reliable multicast technology =B7 Applications enabled by IP and reliable multicast =B7 What multicast is doing for customers today =B7 Where multicast needs to go in the future Learn how to: =B7 Optimize satellite uplink/downlink throughput using PGM forward error correction =B7 Re-architect your network to stream audio and video content to client applications =B7 Reduce overhead of global data distribution and software updates =B7 Instantly transfer financial data to wireless devices in real-time =B7 Easily and effectively scale the distribution of data =B7 Ensure your network infrastructure (e.g., routers) is multicast enabl= ed Attend and you could win a TiVo with a 1-year subscription! This series of Talarian Seminars are being held in the following cities: New York, NY Wednesday, October 18 Marriott World Trade Center Richardson, TX Tuesday, October 24 Omni Richardson Hotel Denver, CO Wednesday, October 25 Hilton Denver Tech South Redwood City, CA Tuesday, October 31 Hotel Sofitel To attend a seminar or obtain information regarding other seminars in you= r area, please register at www.talarian.com/seminars or call 800-543-8096. = To learn more about Talarian and their reliable multicasting and real-time publish-subscribe messaging products, visit www.talarian.com. From rem-conf Wed Oct 04 08:35:04 2000 From rem-conf-request@es.net Wed Oct 04 08:35:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqYM-0006En-00; Wed, 4 Oct 2000 08:33:54 -0700 Received: from jack.see.plymouth.ac.uk (jack.see.plym.ac.uk) [141.163.49.98] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqYL-0006Ec-00; Wed, 4 Oct 2000 08:33:53 -0700 Received: from len (sfres1.see.plymouth.ac.uk [141.163.49.101]) by jack.see.plym.ac.uk (8.9.3/8.9.3) with SMTP id QAA29432 for ; Wed, 4 Oct 2000 16:29:51 +0100 Message-ID: <004c01c02e18$cf2587d0$6531a38d@see.plym.ac.uk> From: "Bogdan Ghita" To: Subject: Routing for UDP/real-time vs TCP Date: Wed, 4 Oct 2000 16:36:05 +0100 Organization: NRG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C02E21.30CFFF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C02E21.30CFFF30 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all I have a question related to general routing issues: I am looking into measuring RTT for a specific path using 2 different = methods: TCP acknowledgements and RTCP NTP/LSR/DLSR fields. Is there any specification regarding different handling by the servers = of packets that carry TCP segments vs packets carrying UDP datagrams? I = had several discussions lately about how some/all routers tend to drop = first ICMP traffic, then TCP traffic and, at the end, UDP traffic, as = the first category is not critical and the second can recover. If so, it = would mean that there are several different transport performance rates = for the same path, depending on the type of traffic being sent. Are the = assumption/conclusion correct? Could you point me to some materials that = detail this matter? Thank you very much Best regards Bogdan Ghita ------=_NextPart_000_0049_01C02E21.30CFFF30 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear all
 
I have a question related to general = routing=20 issues:
I am looking into measuring RTT for a = specific path=20 using 2 different methods: TCP acknowledgements and RTCP NTP/LSR/DLSR=20 fields.
Is there any = specification regarding different=20 handling by the servers of packets that carry TCP segments vs packets = carrying=20 UDP datagrams? I had several discussions lately about how some/all = routers tend=20 to drop first ICMP traffic, then TCP traffic and, at the end, UDP = traffic, as=20 the first category is not critical and the second can recover. If so, it = would=20 mean that there are several different transport performance rates for = the same=20 path, depending on the type of traffic being sent. Are the = assumption/conclusion=20 correct? Could you point me to some materials that detail this=20 matter?
 
Thank you very much
 
Best regards
Bogdan Ghita
 
 
 
------=_NextPart_000_0049_01C02E21.30CFFF30-- From rem-conf Wed Oct 04 08:50:23 2000 From rem-conf-request@es.net Wed Oct 04 08:50:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqnK-00005N-00; Wed, 4 Oct 2000 08:49:22 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqnJ-00005C-00; Wed, 4 Oct 2000 08:49:21 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-174.dialup.cs.tu-berlin.de [130.149.145.174]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id RAA19580; Wed, 4 Oct 2000 17:43:35 +0200 (MET DST) Message-Id: <5.0.0.25.2.20001004173727.02f62990@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 04 Oct 2000 17:39:19 +0200 To: "Yoshihiro Kikuchi" From: Stephan Wenger Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Cc: "Colin Perkins" , "IETF AVT" , "Yoshihiro Kikuchi" In-Reply-To: <067f01c02df4$61442560$cc51c485@eel.rdc.toshiba.co.jp> References: <200010040444.AAA09294@purple.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Yoshihiro, Group, To my knowledge the only reason why RFC2190 is not yet OBSOLETE is that some early H.323 products still use it. Interoperability with such products is probably not your main concern. So I would suggest to select RFC2429 only. Stephan At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: >Dear Colin, all, > > > >> When the short video header mode is used, RTP payload format for >H.263 > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? >Or, if ITU-T does not have any preference, I'm not sure if it is really >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > >Best regards, >Yoshihiro > >---- > 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 1267 From rem-conf Wed Oct 04 09:19:21 2000 From rem-conf-request@es.net Wed Oct 04 09:19:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13grEi-0001rX-00; Wed, 4 Oct 2000 09:17:40 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13grEf-0001rH-00; Wed, 4 Oct 2000 09:17:37 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA05157 for ; Wed, 4 Oct 2000 09:17:33 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 09:17:33 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA24057; Wed, 4 Oct 2000 09:17:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <0056890014577469000002L992*@MHS> References: <0056890014577469000002L992*@MHS> Date: Wed, 4 Oct 2000 09:17:04 -0700 To: jan.vandermeer@philips.com From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: dominique.curet@rd.francetelecom.fr, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime From rem-conf Wed Oct 04 09:19:36 2000 From rem-conf-request@es.net Wed Oct 04 09:19:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13grEq-0001rx-00; Wed, 4 Oct 2000 09:17:48 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13grEf-0001rF-00; Wed, 4 Oct 2000 09:17:37 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA05138 for ; Wed, 4 Oct 2000 09:17:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 09:17:31 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA24025; Wed, 4 Oct 2000 09:17:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> Date: Wed, 4 Oct 2000 09:15:55 -0700 To: CURET Dominique FTRD/DMI/REN From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, "'Olivier Avaro'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >*******so, to my understanding, at least: > 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams SL is not a stream type. It's the layer that carries streams. MP4 files are not directly streamed; they may be downloaded, but that requires a MIME type, not a stream type. >******about the muxcode table in band/out of band: >Dave said that :"The MuxCodeTable needs to be delivered out-of-band". >**it certainly needs to be delivered. > >Pierre showed how it is possible to deliver it, accurately in time, by >out of band means > >**But is 'out of band' compatible with a multicast or broadcast scenario. >**So, I think agree with Jan that an inband means is necessary. of course it is. my framework proposal showed how. in a multicast or broadcast, there is always some information that is given to the terminal to enable it to open the streams. in IETF world, that is an SDP file. I showed how to put the IOD and the flexmux info into the SDP file. -- David Singer Apple Computer/QuickTime From rem-conf Wed Oct 04 10:19:08 2000 From rem-conf-request@es.net Wed Oct 04 10:19:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gs8R-0005YX-00; Wed, 4 Oct 2000 10:15:15 -0700 Received: from p-mail2.rd.francetelecom.fr (p-mail2.cnet.fr) [193.49.124.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13gs8P-0005Wf-00; Wed, 4 Oct 2000 10:15:14 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4HLBRC33>; Wed, 4 Oct 2000 19:13:38 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: 'Dave Singer' , jan.vandermeer@philips.com Cc: CURET Dominique FTRD/DMI/REN , rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 19:15:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, dear Dave, Dave said: "I would be strongly opposed to mandating the use of flexmux for any=20 stream."=20 answer: The applications that you have in mind don't seem to need multiplexing=20 at the application level. Fine with me. When some other applications find this approach interesting, our job=20 is to give solutions to them. There should not be any technical=20 fundamentalism. Dominique _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel=20 > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ -----Message d'origine----- De: Dave Singer [mailto:singer@apple.com] Date: mercredi 4 octobre 2000 18:17 =C0: jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Objet: RE: Types of MPEG-4 streams over IP >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to = specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any=20 stream. What is wrong with Carsten et al.'s sync layer mapping into=20 RTP? --=20 David Singer Apple Computer/QuickTime From rem-conf Wed Oct 04 10:29:10 2000 From rem-conf-request@es.net Wed Oct 04 10:29:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gsJu-0006bz-00; Wed, 4 Oct 2000 10:27:06 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gsJt-0006ZS-00; Wed, 4 Oct 2000 10:27:05 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JUXPGEBVIQEVQYUX@GI.COM> for rem-conf@es.net; Wed, 4 Oct 2000 10:25:47 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 04 Oct 2000 10:25:00 -0400 Content-return: allowed Date: Wed, 04 Oct 2000 13:28:24 -0400 From: "Narasimhan, Sam (SD-EX)" Subject: RE: Types of MPEG-4 streams over IP To: 'Dave Singer' , jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239DD@ntas0026.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, The MPEG requirements document asks for a payload mapping scheme to carry flexmux streams. This is possible in MPEG-2 transport and must be possible in RTP. We need to define a mapping scheme which will be normative for those applications that want to transmit flexmux streams over RTP. I will strongly object to a mapping scheme that excludes or precludes the carriage of flexmux streams over RTP. Regards Sam Narasimhan Motorola -----Original Message----- From: Dave Singer [mailto:singer@apple.com] Sent: Wednesday, October 04, 2000 9:17 AM To: jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime From rem-conf Wed Oct 04 12:56:18 2000 From rem-conf-request@es.net Wed Oct 04 12:56:17 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13guZQ-000276-00; Wed, 4 Oct 2000 12:51:16 -0700 Received: from sdn-ar-003flmiamp018.dialsprint.net ([168.191.253.26] helo=50460l3t.aol.com) by mail2.es.net with smtp (Exim 1.92 #1) id 13guZG-00026T-00; Wed, 4 Oct 2000 12:51:08 -0700 To: sturtevantap@es.net Message-Id: <1g7jvs70.86y67u28e@50460l3t.aol.com> Subject: 3000 VISITORS TO YOUR SITE IN 24 HOURS--GUARANTEED Date: Thu, 05 Oct 2000 03:49:23 -0500 From: sowens7426@lxafehtcsc.earthlink.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Give us 10 key words and 24 hours...Let us send you 3000 vistors minimum! YOU MAY HAVE THE BEST PRODUCT OR SERVICE IN THE WORLD BUT, without effective exposure...what good does it do?? Add 3,000 eager visitors (minimum) to your web site, in 24 hours, guaranteed, through OBC. For More Information call us at the number below or mailto:hitgenerator@n2mail.com, CALL IN BONUS: With your first order receive our BONUS worth over $250 FREE. 919-839-2942. Today, there are almost 30 million sites on the Internet. To merely have a "net presence"- without actively promoting your site, is comparable to … taking out a 2-line ad in the "New York Times": not many people will see it and even fewer will respond. The OBC has developed a proven technique to generate and deliver thousands of visitors directly to your web site, within 24 hours. We absolutely guarantee it. Our campaign will bring active visitors, looking to learn more about your offers. These are not just surfers. They are excited, expectant visitors, who find your web site through our heavily and strategically advertised portals, search engines, key words directories and other techniques. We are interested in your marketing your web site. Do you have an interest in our services which GUARANTEES 3000 visitors or more to your site within any 24 hour period? NO BULK MAILING INVOLVED! NO SPAMMING INVOLVED! NO PAID SURFERS INVOLVED! NO PAID EMAIL READERS INVOLVED! ALL CAMPAIGNS ARE 100% GUARANTEED! We also create various new forms of revenue which could be created for your site. If you are interested please do drop us a line including your name and phone number and mailto:hitgenerator@n2mail.com, or feel free to ring us directly at: 919-839-2942. Act Now!!!! Reap the Benefits in 24 Hours!!! ___________________________________________________ This message is sent in compliance of current rules and regulations related to bulk email transmission. ================================================= If you wish to be removed from future mailings, please mailto:nohitgenerator@n2mail.com ============================= From rem-conf Wed Oct 04 14:24:09 2000 From rem-conf-request@es.net Wed Oct 04 14:24:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gvyc-0001M5-00; Wed, 4 Oct 2000 14:21:22 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gvyb-0001Lu-00; Wed, 4 Oct 2000 14:21:21 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id OAA19582; Wed, 4 Oct 2000 14:21:19 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id OAA19379; Wed, 4 Oct 2000 14:21:16 -0700 (MST) Message-Id: <200010042121.OAA19379@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 04 Oct 2000 23:23:19 +0200 To: Krister Svanbro From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Qiaobing Xie , Magnus Westerlund , rem-conf@es.net In-Reply-To: <39DB4736.8DEF25F9@lu.erisoft.se> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ROHC WG co-chair speaking. I have a couple of comments to this letter: >Qiaobing Xie wrote: >> >> Hi, Magnus, >> >> See my comments below.... >> >> Magnus Westerlund wrote: >> > >> > Hello, >> > >> > The payload format is designed with IP networks in mind. The problem we see is >> > that IP is transported over a wide range of different links with different >> > behavior, e.g. different radio and wireline links. Radio and wire do not have >> > the same error characteristics. AMR will be widly used over wireless links and >> > on these links bandwidth efficiency is extremely important. This lead to the >> > bitwise sorting. Octet sorting needs octet alignement for each block of the >> > payload, i.e. padding at the end of each block. Which we considered to be to >> > expensive. >> >> This further convinces me that the current design presented in the AMR >> draft is a radio-link-centric design, which is wrong in my opinion, >> because: >> >> 1) bandwidth efficiency over wireless links is more of a concern for >> ROHC working group. That statement is too general. ROHC deals with the efficient transmission of the RTP/UDP/IP header. The payload format is NOT a concern of the ROHC WG. If a payload format is to be efficient over a wireless link, it must be made so by others than ROHC. >> Architecturally, it should be delt with below IP by >> header compression/stripping, as being worked upon in rohc. It doesn't >> belong to RTP payload layer (unless it is something facilitating the >> underlying header compression/stripping). Architecturally speaking (and here I remove my ROHC chair hat), bandwidth efficiency over wireless links will best be obtained by a) having an efficiently compressed payload, which might be somewhat resilient to errors introduced by the wireless link. b) compressing the RTP/UDP/IP header robustly and efficiently. ROHC deals with b). Others, perhaps you people, need to deal with a). The best result will be obtained if a) is done close to the application, i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should it be. The IETF should not worry ONLY about wireless, of course, but it certainly seems appropriate to ensure that things work over wireless as well as over the rest of the currently largely wired Internet. Cheers, Mikael Degermark From rem-conf Wed Oct 04 15:45:00 2000 From rem-conf-request@es.net Wed Oct 04 15:44:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gxFC-0004T9-00; Wed, 4 Oct 2000 15:42:34 -0700 Received: from (motgate3.mot.com) [144.189.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gxFB-0004Sx-00; Wed, 4 Oct 2000 15:42:33 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA08568; Wed, 4 Oct 2000 15:39:49 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA12322; Wed, 4 Oct 2000 15:40:57 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id RAA20206; Wed, 4 Oct 2000 17:40:57 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id RAA22247; Wed, 4 Oct 2000 17:40:56 -0500 (CDT) Message-Id: <200010042240.RAA22247@agevole.cig.mot.com> Date: Wed, 04 Oct 2000 17:41:11 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Krister Svanbro , Qiaobing Xie , Magnus Westerlund , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mikael and Krister (and other ROHCers on the list): Ok, I know I was getting myself in trouble when I mentioned the "dreadful" word ROHC :-) :-) Mikael Degermark wrote: ...snip... > >> Architecturally, it should be delt with below IP by > >> header compression/stripping, as being worked upon in rohc. It doesn't > >> belong to RTP payload layer (unless it is something facilitating the > >> underlying header compression/stripping). > > Architecturally speaking (and here I remove my ROHC chair hat), bandwidth > efficiency over wireless links will best be obtained by > > a) having an efficiently compressed payload, which might be somewhat resilient to > errors introduced by the wireless link. > > b) compressing the RTP/UDP/IP header robustly and efficiently. > > ROHC deals with b). Others, perhaps you people, need to deal with a). > The best result will be obtained if a) is done close to the application, > i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should > it be. I think we are in "violent" agreement here :) The point I was trying to make is, when you are looking at optimizing the bandwidth efficiency over a *link* with a unique error characteristics, the framework/approach used by ROHC is more appropriate, which is to look for header compression/stripping solutions below the IP layer. This matches your b) above. But if you are designing an RTP payload format, which is meant to be sent end-to-end over a routable IP connection, it does not make much sense to optimize the payload format design according to the error characteristics of any one type of the link which, after all, may or may not be present in the connection. I have not problem with a) and I think it is in deed the job of AVT WG. No doubt that it is universally desirable to design any protocol message as compact and as compressed as possible (as Krister said: not to waste a bit) But in reality, you often have to make trade-off between saving a bit in the message and the associated processing cost, especially when the processing is done in a higher stack layer. The error resilience part (or the lack of it) in the current AMR draft is exactly one of my big concerns as I talked about in my first email. Cheers, -Qiaobing > > The IETF should not worry ONLY about wireless, of course, but it certainly > seems appropriate to ensure that things work over wireless as well as over > the rest of the currently largely wired Internet. > > Cheers, > > Mikael Degermark From rem-conf Wed Oct 04 16:40:46 2000 From rem-conf-request@es.net Wed Oct 04 16:40:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gy6v-0006SL-00; Wed, 4 Oct 2000 16:38:05 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gy6t-0006S2-00; Wed, 4 Oct 2000 16:38:03 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA00297 for ; Wed, 4 Oct 2000 16:38:02 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 16:38:01 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id QAA07580; Wed, 4 Oct 2000 16:38:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> Date: Wed, 4 Oct 2000 16:36:23 -0700 To: CURET Dominique FTRD/DMI/REN From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: jan.vandermeer@philips.com, CURET Dominique FTRD/DMI/REN , rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 7:15 PM +0200 10/4/00, CURET Dominique FTRD/DMI/REN wrote: >Dear all, dear Dave, > >Dave said: >"I would be strongly opposed to mandating the use of flexmux for any >stream." > >answer: >The applications that you have in mind don't seem to need multiplexing >at the application level. Fine with me. >When some other applications find this approach interesting, our job >is to give solutions to them. There should not be any technical >fundamentalism. and Sam said: > The MPEG requirements document asks for a payload >mapping scheme to carry flexmux streams. This is possible in >MPEG-2 transport and must be possible in RTP. We need to >define a mapping scheme which will be normative for those >applications that want to transmit flexmux streams over >RTP. I will strongly object to a mapping scheme that >excludes or precludes the carriage of flexmux streams >over RTP. I am not opposed to allowing the use of flexmux. The proposal was that certain stream types (e.g. MPEG-7) could *only* be carried in flexmux. Flexmux is not always suitable; it should be possible to carry a single MPEG-4 stream in a simple RTP stream, without requiring flexmux. Indeed, I am not being a fundamentalist; though I personally do not see much need for flexmux, I am happy that it be allowed. I would like a technical solution for MPEG-4 which does not *mandate* it, that's all. -- David Singer Apple Computer/QuickTime From rem-conf Wed Oct 04 18:53:06 2000 From rem-conf-request@es.net Wed Oct 04 18:53:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h05i-00029f-00; Wed, 4 Oct 2000 18:44:58 -0700 Received: from mail0.ced.mei.co.jp (vsm.ctmo.mei.co.jp) [202.224.188.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h05h-000288-00; Wed, 4 Oct 2000 18:44:57 -0700 Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id KAA00727; Thu, 5 Oct 2000 10:43:04 +0900 (JST) Received: from dragon.drl.mei.co.jp(132.182.104.28) by vsm.ctmo.mei.co.jp via smap (V2.0) id ; Thu, 5 Oct 00 10:43:01 +0900 Received: by dragon.drl.mei.co.jp (8.9.3/5.9:4.9:drl-mx-com:20000202) id KAA28437; Thu, 5 Oct 2000 10:41:57 +0900 (JST) Message-ID: <00b301c02e6d$6663bfa0$156bb684@drl.mei.co.jp> From: "Y. Matsui" To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: References: <0056890014577469000002L992*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Thu, 5 Oct 2000 10:41:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jan and all, >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream In my opinion, those streams should be carried on a reliable channel rather than RTP. What I am not sure is the scene description stream. There are two kind of the scene description stream, one is BIFS-update and another is BIFS-Anim. In my understanding, BIFS-Anim should be streamed like audio/visual streams. Best regards, Yoshinori Matsui From rem-conf Wed Oct 04 18:53:06 2000 From rem-conf-request@es.net Wed Oct 04 18:53:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h0Av-0002Gt-00; Wed, 4 Oct 2000 18:50:21 -0700 Received: from u-mail.rd.francetelecom.com [208.25.178.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h0At-0002GS-00; Wed, 4 Oct 2000 18:50:20 -0700 Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Oct 2000 18:48:54 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F355324@u-mail.rd.francetelecom.com> From: SIGNES Julien / ENVIVIO To: "'Y. Matsui'" , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 18:48:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E6E.69E69BD8" 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_01C02E6E.69E69BD8 Content-Type: text/plain; charset="iso-8859-1" Hello, > -----Original Message----- > From: Y. Matsui [mailto:matsui@drl.mei.co.jp] > Sent: Wednesday, October 04, 2000 6:42 PM > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: Re: Types of MPEG-4 streams over IP > > > Dear Jan and all, > > >Can we assume that the following streams are probably most > efficiently > >contained in a FlexMux stream, and consequently that is no > need to specify > >use of RTP and SDP for those streams: > > > >- ObjectDescriptorStream > >- ClockReferenceStream > >- SceneDescriptionStream > >- MPEG-7Stream > >- IPMPStream > >- ObjectContentInfoStream > >- MPEGJStream > > In my opinion, those streams should be carried on a reliable channel > rather than RTP. > I agree in general they should be fully reliable channels carrying those,as well as BIFS comands. However, note that a lot of streaming those days is actually done by RTP over TCP. > What I am not sure is the scene description stream. > There are two kind of the scene description stream, one is BIFS-update > and another is BIFS-Anim. In my understanding, BIFS-Anim should > be streamed like audio/visual streams. I agree. > > Best regards, > Yoshinori Matsui > Julien ------_=_NextPart_001_01C02E6E.69E69BD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Types of MPEG-4 streams over IP

Hello,

> -----Original Message-----
> From: Y. Matsui [mailto:matsui@drl.mei.co.jp]
> Sent: Wednesday, October 04, 2000 6:42 = PM
> To: 4on2andIP-sys@advent.ee.columbia.edu
> Cc: rem-conf@es.net
> Subject: Re: Types of MPEG-4 streams over = IP
>
>
> Dear Jan and all,
>
> >Can we assume that the following streams = are probably most
> efficiently
> >contained in a FlexMux stream, and = consequently that is no
> need to specify
> >use of RTP and SDP for those = streams:
> >
> >- ObjectDescriptorStream
> >- ClockReferenceStream
> >- SceneDescriptionStream
> >- MPEG-7Stream
> >- IPMPStream
> >- ObjectContentInfoStream
> >- MPEGJStream
>
> In my opinion, those streams should be carried = on a reliable channel
> rather than RTP.
>

I agree in general they should be fully reliable = channels carrying those,as well as BIFS comands. However, note that a = lot of streaming those days is actually done by RTP over = TCP.

> What I am not sure is the scene description = stream.
> There are two kind of the scene description = stream, one is BIFS-update
> and another is BIFS-Anim.  In my = understanding, BIFS-Anim should
> be streamed like audio/visual streams.

I agree.


>
> Best regards,
> Yoshinori Matsui
>

Julien

------_=_NextPart_001_01C02E6E.69E69BD8-- From rem-conf Wed Oct 04 19:29:26 2000 From rem-conf-request@es.net Wed Oct 04 19:29:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h0lr-0004Kn-00; Wed, 4 Oct 2000 19:28:31 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h0lp-0004Kd-00; Wed, 4 Oct 2000 19:28:30 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id TAA24267; Wed, 4 Oct 2000 19:28:28 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id TAA27598; Wed, 4 Oct 2000 19:28:26 -0700 (MST) Message-Id: <200010050228.TAA27598@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 05 Oct 2000 04:30:33 +0200 To: Qiaobing Xie From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Mikael Degermark , Krister Svanbro , Qiaobing Xie , Magnus Westerlund , rem-conf@es.net In-Reply-To: <200010042240.RAA22247@agevole.cig.mot.com> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:41 PM 10/4/00 -0500, Qiaobing Xie wrote: (snip) >The point I was trying to make is, when you are looking at optimizing >the bandwidth efficiency over a *link* with a unique error >characteristics, the framework/approach used by ROHC is more >appropriate, which is to look for header compression/stripping solutions >below the IP layer. This matches your b) above. >But if you are designing an RTP payload format, which is meant to be >sent end-to-end over a routable IP connection, it does not make much >sense to optimize the payload format design according to the error >characteristics of any one type of the link which, after all, may or may >not be present in the connection. If one expects that a common case will be that the payload is sent across such links, it may make a lot of sense. But this is of course difficult to predict. >I have not problem with a) and I think it is in deed the job of AVT WG. >No doubt that it is universally desirable to design any protocol message >as compact and as compressed as possible (as Krister said: not to waste >a bit) But in reality, you often have to make trade-off between saving >a bit in the message and the associated processing cost, especially when >the processing is done in a higher stack layer. The tradeoff is between the cost of sending the bits across the link and the processing cost at the sender/receiver. As the end user will ultimately pay for both, one has to consider the relative costs. When the amr format is used for voice, it seems that either of two scenarios will occur: 1) users use some sort of mobile terminal. 2) users use stationary terminals. For 1, the cost of bandwidth is very likely to be higher than the processing cost if the mobile uses cellular radio. For 2, the cost of bandwidth is very low, but on the other hand the incremental processing cost is zero when something like a PC is used as the stationary terminal. So this very simple analysis does seem to favor a high degree of compression. >The error resilience >part (or the lack of it) in the current AMR draft is exactly one of my >big concerns as I talked about in my first email. > >Cheers, >-Qiaobing > >> >> The IETF should not worry ONLY about wireless, of course, but it certainly >> seems appropriate to ensure that things work over wireless as well as over >> the rest of the currently largely wired Internet. >> >> Cheers, >> >> Mikael Degermark > From rem-conf Wed Oct 04 21:39:33 2000 From rem-conf-request@es.net Wed Oct 04 21:39:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h2mQ-000717-00; Wed, 4 Oct 2000 21:37:14 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h2mM-00070v-00; Wed, 4 Oct 2000 21:37:11 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id NAA17396; Thu, 5 Oct 2000 13:36:43 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id NAA29241; Thu, 5 Oct 2000 13:36:42 +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 NAA19575; Thu, 5 Oct 2000 13:36:34 +0900 (JST) Received: from ave (srg-204 [133.196.81.204]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id NAA35856; Thu, 5 Oct 2000 13:36:33 +0900 (JST) Message-ID: <046501c02e85$e2994f00$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Stephan Wenger" Cc: "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <200010040444.AAA09294@purple.east.isi.edu> <5.0.0.25.2.20001004173727.02f62990@mail.cs.tu-berlin.de> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Thu, 5 Oct 2000 13:36:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan, Kris and all, Thank you very much for your comments. Seeing a comment from Kris and a suggestion form Stephan about H.263 RTP format, I think it is reasonable to keep the use of H.263 RTP format as "SHOULD", specifying only RFC2429 as suggested, and not to add the detailed timestamp definition of the short video header mode. When the short video header mode is used, RTP payload format for H.263 (RFC 2429) SHOULD be used. Best regards, Yoshihiro ----- Original Message ----- From: Stephan Wenger To: Yoshihiro Kikuchi Cc: Colin Perkins ; IETF AVT ; Yoshihiro Kikuchi Sent: Thursday, October 05, 2000 12:39 AM Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > Dear Yoshihiro, Group, > > To my knowledge the only reason why RFC2190 is not yet OBSOLETE is > that some early H.323 products still use it. Interoperability with such > products is probably not your main concern. So I would suggest to select > RFC2429 only. > > Stephan > > At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: > >Dear Colin, all, > > > > > >> When the short video header mode is used, RTP payload format for > >H.263 > > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? > >Or, if ITU-T does not have any preference, I'm not sure if it is really > >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > > > >Best regards, > >Yoshihiro > > > >---- > > 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 1267 > > > > From rem-conf Thu Oct 05 01:05:09 2000 From rem-conf-request@es.net Thu Oct 05 01:05:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h5yD-0004gO-00; Thu, 5 Oct 2000 01:01:37 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h5yC-0004gD-00; Thu, 5 Oct 2000 01:01:36 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id KAA01377; Thu, 5 Oct 2000 10:01:26 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma001346; Thu, 5 Oct 00 10:01:28 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA11541; Thu, 5 Oct 2000 10:01:23 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA15956; Thu, 5 Oct 2000 10:01:21 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900012513789; Thu, 5 Oct 2000 10:08:11 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu>, Subject: Re: Types of MPEG-4 streams over IP Message-ID: <0056900012513789000002L092*@MHS> Date: Thu, 5 Oct 2000 10:08:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 09:55:29" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list matsui@drl.mei.co.jp wrote: > Dear Jan and all, > > >Can we assume that the following streams are probably most efficient= ly > >contained in a FlexMux stream, and consequently that is no need to s= pecify > >use of RTP and SDP for those streams: > > > >- ObjectDescriptorStream > >- ClockReferenceStream > >- SceneDescriptionStream > >- MPEG-7Stream > >- IPMPStream > >- ObjectContentInfoStream > >- MPEGJStream > > In my opinion, those streams should be carried on a reliable channel > rather than RTP. I wish that was possible too, however ... In a truly scalable distribution architecture you must use connectionless protocols. RTP on UDP multicast is the key candidate. NB: Retransmission of lost data requires a return channel that is not always present and if it were present would probably be not very scalable so forget about absolute reliability too, repetition (and FEC) are what we have to make sure can work Therefore scalable broadcast requires RTP transport of ALL these streams as well as SDP in repeated SAP packets. > > > What I am not sure is the scene description stream. > There are two kind of the scene description stream, one is BIFS-updat= e > and another is BIFS-Anim. In my understanding, BIFS-Anim should > be streamed like audio/visual streams. > Same thing for both, must be possible to broadcast them too. Regards, -- Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com = From rem-conf Thu Oct 05 01:24:31 2000 From rem-conf-request@es.net Thu Oct 05 01:24:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h6Jh-0006CV-00; Thu, 5 Oct 2000 01:23:49 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h6Jf-0006C6-00; Thu, 5 Oct 2000 01:23:48 -0700 Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e958NbZ21280; Thu, 5 Oct 2000 10:23:38 +0200 (MEST) Received: from era.ericsson.se (rcur34ip54.ericsson.se [147.214.34.54]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id KAA25011; Thu, 5 Oct 2000 10:23:36 +0200 (MET DST) Message-ID: <39DC3A89.2DF44B03@era.ericsson.se> Date: Thu, 05 Oct 2000 10:23:37 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Qiaobing Xie , Krister Svanbro , Qiaobing Xie , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello everyone! We agree with the comments from Mikael Degermark, and would like to address some issues raised in the last days: 1) AMR is of course suitable for a multitude of applications. We know that it will be used for wireless and also over internet. The wireless case is important and in this case saving an octet per packet is very desirable. Therefore, bandwidth efficiency should be prioritiesed. 2) The IAB supports, as I see it, the design of bandwidth efficient solutions, see e.g. section 3.8 in http://www.ietf.org/internet-drafts/draft-iab-wirelessws-01.txt . 3) What is to complex? We have compared the payload packetization with the speech codec. We are using the optimized official ETSI/3GPP floating point AMR codec and an unoptimized payload packetizer. The load is expressed in percent of an Windows NT machine with a Pentium III 500 MHz processor. Speech encoder: 7.1% Payload packetizer: 0.058 % Payload depacketizer: 0.058 % Speech decoder: 1.1% All figures are for the AMR mode with the most complex packetization and the least favorable number of frames per packet, i.e. worst case for the payload packetizer. The data bits are already reshuffled bitwise in the speech encoder. If the robust sorting is done in conjunction with the reshuffling in the speech encoder the extra complexity would decrease. Note also that the default operation is the simple and not the robust sorting. 4) UEP/UED schemes under development that can utilise the fact that the payload is sorted in error sensitivity order. The UDP Lite Protocol, http://search.ietf.org/internet-drafts/draft-larzon-udplite-03.txt An RTP Payload Format for Generic FEC with Uneven Level Protection, http://search.ietf.org/internet-drafts/draft-li-ulp-00.txt An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams, http://search.ietf.org/internet-drafts/draft-lnt-avt-uxp-02.txt Best regards Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf Thu Oct 05 02:11:19 2000 From rem-conf-request@es.net Thu Oct 05 02:11:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h71f-0000lV-00; Thu, 5 Oct 2000 02:09:15 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h71d-0000lB-00; Thu, 5 Oct 2000 02:09:13 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA06318; Thu, 5 Oct 2000 11:09:07 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma006316; Thu, 5 Oct 00 11:09:08 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA22987; Thu, 5 Oct 2000 11:09:07 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA15192; Thu, 5 Oct 2000 11:09:06 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900012516881; Thu, 5 Oct 2000 11:15:55 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Message-ID: <0056900012516881000002L012*@MHS> Date: Thu, 5 Oct 2000 11:15:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 10:53:31" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list kiku@eel.rdc.toshiba.co.jp wrote: > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Vi= sual > RTP Internet-Draft. > > > > Please let us know if there is comment on the attached draft. The aut= hors > need to submit it soon as an updated I-D and hopefully final before R= FC. > I would like to know why the presence of configuration information in t= he SDP is OPTIONAL. I would think much preferable if the profile-level-id and config fields= would be REQUIRED. The reasons being that: - it is only a few bytes anyway - a decoder implementation would always have the possibility to be initialized using the information in the SDP= , which is easier for many implementation because parsing the video syntax requires a video decoder and when you instanciate a video decoder it is VERY handy to already have the configuration ! - it would help a receiver discover that it cannot decode a given strea= m (without having to request and start receiving the actual stream and pa= rse it) and that may be the key reason: in all modes of delivery this would solve a "security" issue: A malignant (or stupid) user of a non-capable decoder could generate a lot of traffic by requesting repeatedly streams that cannot be decode= d, which the decoder could discover "at once" by parsing the SDP, if the SDP would always contain the config info... - it would save (a little) bandwidth since frequent repetition of VOL i= n the stream is required only for clients who do not use SDP info, you could then have streams that actually do not repeat the VOL, or only rarely. In point to point delivery, in case the stream cannot be decoded by cli= ent, it saves: - several round trips - quite some network traffic - quite some server load In broadcast (IP multicast) it saves: - some start time since the decoder can start parsing immediatly after receiving the SDP, without having to wait for repeated VOL - quite some traffic too (in case the stream cannot be decoded by clien= t) since issuing a IGMP "join" in order to receive the stream will "flood" all the network legs between broadcaster and client. ************************************************************* Furtheremore I would like to know the exact status of video B frames re= lative to this proposal. > Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com = From rem-conf Thu Oct 05 03:34:17 2000 From rem-conf-request@es.net Thu Oct 05 03:34:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h8IW-0003O1-00; Thu, 5 Oct 2000 03:30:44 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h8IV-0003Nr-00; Thu, 5 Oct 2000 03:30: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 GAA24608; Thu, 5 Oct 2000 06:30:42 -0400 (EDT) Message-Id: <200010051030.GAA24608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-amr-01.txt Date: Thu, 05 Oct 2000 06:30:42 -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 AMR Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt Filename : draft-ietf-avt-rtp-amr-01.txt Pages : 17 Date : 04-Oct-00 This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-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-amr-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-amr-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: <20001004102612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001004102612.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Oct 05 04:21:55 2000 From rem-conf-request@es.net Thu Oct 05 04:21:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h91u-00058R-00; Thu, 5 Oct 2000 04:17:38 -0700 Received: from katto.comm.waseda.ac.jp (pisces.katto.comm.waseda.ac.jp) [133.9.196.230] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13h91o-00058A-00; Thu, 5 Oct 2000 04:17:32 -0700 Received: from i810 ([133.9.250.220]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id UAA13785; Thu, 5 Oct 2000 20:17:10 +0900 Message-ID: <026f01c02ebd$ce12a940$dcfa0985@katto.comm.waseda.ac.jp> From: "Jiro Katto" To: "SIGNES Julien / ENVIVIO" , "'Y. Matsui'" , <4on2andIP-sys@advent.ee.columbia.edu> Cc: References: <337055FBC675D311A85D00508B5A9C4F355324@u-mail.rd.francetelecom.com> Subject: Re: Types of MPEG-4 streams over IP Date: Thu, 5 Oct 2000 20:17:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I completely agree with Yoshinori, > Hello, > > > Dear Jan and all, > > > > >Can we assume that the following streams are probably most > > efficiently > > >contained in a FlexMux stream, and consequently that is no > > need to specify > > >use of RTP and SDP for those streams: > > > > > >- ObjectDescriptorStream > > >- ClockReferenceStream > > >- SceneDescriptionStream > > >- MPEG-7Stream > > >- IPMPStream > > >- ObjectContentInfoStream > > >- MPEGJStream > > > > In my opinion, those streams should be carried on a reliable channel > > rather than RTP. > > I agree in general they should be fully reliable channels carrying those,as > well as BIFS comands. However, note that a lot of streaming those days is > actually done by RTP over TCP. That may be. But, I guess RTP is still used for video and audio streams even in this case, too. When we say the listed streams above are conveyed as "data" or "control" (not "video" nor "audio"), this is fully aligned with the underlying layers (TransMux, in MPEG world), i.e. H.323 and SIP/SDP. I think it is free for MPEG to attach a SL header to the listed streams in order to treat them as synchronized time events. However, I cannot find any reason why RTP usage is forced. > > What I am not sure is the scene description stream. > > There are two kind of the scene description stream, one is BIFS-update > > and another is BIFS-Anim. In my understanding, BIFS-Anim should > > be streamed like audio/visual streams. > > I agree. I agree, too. This is the final thing to complete the "MPEG4 over IP" framework, in my mind. Quite sorry for my noises. -- Jiro Katto Waseda University From rem-conf Thu Oct 05 05:47:42 2000 From rem-conf-request@es.net Thu Oct 05 05:47:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hAMg-0007l2-00; Thu, 5 Oct 2000 05:43:10 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hAMZ-0007kA-00; Thu, 5 Oct 2000 05:43:05 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id IAA02405; Thu, 5 Oct 2000 08:38:26 -0400 Message-Id: <200010051238.IAA02405@purple.east.isi.edu> To: philippe.gentric@philips.com cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, rem-conf Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from philippe.gentric@philips.com of "Thu, 05 Oct 2000 10:08:11 +0200." <0056900012513789000002L092*@MHS> Date: Thu, 05 Oct 2000 08:38:26 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> philippe.gentric@philips.com writes: >matsui@drl.mei.co.jp wrote: >> In my opinion, those streams should be carried on a reliable channel >> rather than RTP. > >I wish that was possible too, however ... > >In a truly scalable distribution architecture >you must use connectionless protocols. > >RTP on UDP multicast is the key candidate. > >NB: Retransmission of lost data requires a return channel >that is not always present and if it were present >would probably be not very scalable so forget >about absolute reliability too, repetition (and FEC) >are what we have to make sure can work > >Therefore scalable broadcast requires RTP transport >of ALL these streams as well as SDP in repeated SAP packets. ...or some form of reliable multicast. You will never get 100% reliability >from RTP, whereas there are reliable multicast protocols which achieve this with no backchannel. See the work ongoing in the IETF RMT working group. I'm very nervous about the use of RTP here - it's NOT appropriate for reliable transport. Colin From rem-conf Thu Oct 05 05:58:49 2000 From rem-conf-request@es.net Thu Oct 05 05:58:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hAZ6-0000oI-00; Thu, 5 Oct 2000 05:56:00 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hAZ5-0000o8-00; Thu, 5 Oct 2000 05:55:59 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA14117; Thu, 5 Oct 2000 14:55:55 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma014108; Thu, 5 Oct 00 14:55:56 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA20860; Thu, 5 Oct 2000 14:55:53 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA12149; Thu, 5 Oct 2000 14:55:53 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014616933; Thu, 5 Oct 2000 14:56:57 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014616933000002L932*@MHS> Date: Thu, 5 Oct 2000 14:56:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 15:54:04" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, all, Dave wrote : >I am not opposed to allowing the use of flexmux. The proposal was >that certain stream types (e.g. MPEG-7) could *only* be carried in >flexmux. I was not that strong, but only asked whether there is a need for direc= t carriage over RTP, given that there is a solution to carry such streams= inside a FlexMux. But anyhow, I think the answer is clear, though I still don't understan= d how to reduce the huge overhead in case of the (usually) small messages if = not by using FlexMux. Regards, Jan = From rem-conf Thu Oct 05 07:58:45 2000 From rem-conf-request@es.net Thu Oct 05 07:58:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hCPX-0004Na-00; Thu, 5 Oct 2000 07:54:15 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hCPV-0004NO-00; Thu, 5 Oct 2000 07:54:13 -0700 Received: from SMTPMail.PicTel.com (hqsmtpmail.pictel.com [140.242.100.76]) by gateway-gw.pictel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA17619; Thu, 5 Oct 2000 10:58:39 -0400 (EDT) Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision To: "Yoshihiro Kikuchi" Cc: "Stephan Wenger" , "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" From: Qunshan_Gu@pictel.com Date: Thu, 5 Oct 2000 10:54:18 -0400 Message-ID: X-MIMETrack: Serialize by Router on SMTPMail/PicTel(Release 5.0.4 |June 8, 2000) at 10/05/2000 10:53:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Yoshihiro-san, Stephan, and Kris, Since short-video-header mode of MPEG-4 is essentially H.263V1 baseline, RFC 2190 and RFC 2429 are both allowed to be the packetization format in the H.263 world. For maximal inter-operability with today's implementation, and for compatibility with H.263 definition, I would suggest the inclusion of both RFC2190 and RFC2429 in the statement. I know for a fact that many H.263 over IP implementations are still only using RFC2190. Best regards, Qunshan ------------- "Yoshihiro Kikuchi" @advent.ee.columbia.edu on 10/05/2000 12:36:52 AM Sent by: owner-4on2andIP-sys@advent.ee.columbia.edu To: "Stephan Wenger" cc: "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Dear Stephan, Kris and all, Thank you very much for your comments. Seeing a comment from Kris and a suggestion form Stephan about H.263 RTP format, I think it is reasonable to keep the use of H.263 RTP format as "SHOULD", specifying only RFC2429 as suggested, and not to add the detailed timestamp definition of the short video header mode. When the short video header mode is used, RTP payload format for H.263 (RFC 2429) SHOULD be used. Best regards, Yoshihiro ----- Original Message ----- From: Stephan Wenger To: Yoshihiro Kikuchi Cc: Colin Perkins ; IETF AVT ; Yoshihiro Kikuchi Sent: Thursday, October 05, 2000 12:39 AM Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > Dear Yoshihiro, Group, > > To my knowledge the only reason why RFC2190 is not yet OBSOLETE is > that some early H.323 products still use it. Interoperability with such > products is probably not your main concern. So I would suggest to select > RFC2429 only. > > Stephan > > At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: > >Dear Colin, all, > > > > > >> When the short video header mode is used, RTP payload format for > >H.263 > > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? > >Or, if ITU-T does not have any preference, I'm not sure if it is really > >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > > > >Best regards, > >Yoshihiro > > > >---- > > 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 1267 > > > > From rem-conf Thu Oct 05 08:18:31 2000 From rem-conf-request@es.net Thu Oct 05 08:18:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hCk0-0005Wc-00; Thu, 5 Oct 2000 08:15:24 -0700 Received: from mgw-x1.nokia.com [131.228.20.21] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hCjy-0005WS-00; Thu, 5 Oct 2000 08:15:22 -0700 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e95FF6K29827; Thu, 5 Oct 2000 18:15:06 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 5 Oct 2000 10:15:05 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B8DA@daeis05nok> From: zhigang.liu@nokia.com To: micke@CS.Arizona.EDU, xieqb@cig.mot.com Cc: micke@optima.CS.Arizona.EDU, krister.svanbro@lu.erisoft.se, Qiaobing_Xie-QXIE1@email.mot.com, magnus.westerlund@era.ericsson.se, rem-conf@es.net Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Date: Thu, 5 Oct 2000 10:11:06 -0500 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 > The tradeoff is between the cost of sending the bits across the link and > the processing cost at the sender/receiver. > ... > So this very simple analysis does seem to favor a high degree > of compression. I agree with Mikael (not only because I happen to participate the rohc work as well :-)). Another reason: it is the physical law that limits the bandwidth of radio links. You cannot increase bandwidth infinitely like it is done in wireline links by putting more and more optical fibers/cables. On the other hand, the power of chips (per volume) has keep increasing and will continue to do so in the future. So, the processing cost at the sender/receiver will become less significant as time passes by. Br, Zhigang From rem-conf Thu Oct 05 08:46:35 2000 From rem-conf-request@es.net Thu Oct 05 08:46:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hDCa-0006io-00; Thu, 5 Oct 2000 08:44:56 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hDCY-0006ie-00; Thu, 5 Oct 2000 08:44:54 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA17214; Thu, 5 Oct 2000 17:44:52 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma017204; Thu, 5 Oct 00 17:44:52 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA08033; Thu, 5 Oct 2000 17:44:51 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA01245; Thu, 5 Oct 2000 17:44:50 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014623506; Thu, 5 Oct 2000 17:45:55 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014623506000002L962*@MHS> Date: Thu, 5 Oct 2000 17:45:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 18:43:13" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, You wrote : >What is wrong with Carsten et al.'s sync layer mapping into RTP Good question, as usual. Let me list a few issues : 1) Substantial overhead for small access units; a solution is being discussed for audio, but not yet for the other streams I listed; some m= ay indeed deserve a more reliable transport method, but an RTP solution wi= ll be required too, I think. Perhaps use of FlexMux the only solution here. 2) Inclusion of a plain SL header with associated fields; I would prefe= r to start with a byte indicating the length of the subsequent field that contains the SL header. Such field is easily decodable by non-MPEG-4 sy= stem receivers, provides a future proof solution (in future more information= may be contained in the SL header with a length that is unknown by now), an= d creates room for fully compatible extensions. 3) Little commonality with the Kikuchi-san drafts for audio and video. Perhaps it is possible to merge both solutions by extending the Kikuchi= -san drafts with the option to carry an SL header (preceded by the above len= gth field), for example signaled by a new attribute "MPEG-4 SL header carri= ed" at SDP level. Kind regards, Jan >Can we assume that the following streams are probably most efficiently= >contained in a FlexMux stream, and consequently that is no need to spe= cify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime = From rem-conf Thu Oct 05 09:34:15 2000 From rem-conf-request@es.net Thu Oct 05 09:34:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hDuq-0000dx-00; Thu, 5 Oct 2000 09:30:40 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hDup-0000dn-00; Thu, 5 Oct 2000 09:30:39 -0700 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id JAA12685 for ; Thu, 5 Oct 2000 09:30:38 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Thu, 5 Oct 2000 09:30:37 -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 JAA16117; Thu, 5 Oct 2000 09:30:37 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <00b301c02e6d$6663bfa0$156bb684@drl.mei.co.jp> References: <0056890014577469000002L992*@MHS> <00b301c02e6d$6663bfa0$156bb684@drl.mei.co.jp> Date: Thu, 5 Oct 2000 09:30:23 -0700 To: "Y. Matsui" From: Dave Singer Subject: Re: Types of MPEG-4 streams over IP Cc: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:41 AM +0900 10/5/00, Y. Matsui wrote: >Dear Jan and all, > >>Can we assume that the following streams are probably most efficiently >>contained in a FlexMux stream, and consequently that is no need to specify >>use of RTP and SDP for those streams: >> >>- ObjectDescriptorStream >>- ClockReferenceStream >>- SceneDescriptionStream >>- MPEG-7Stream >>- IPMPStream >>- ObjectContentInfoStream >>- MPEGJStream > >In my opinion, those streams should be carried on a reliable channel >rather than RTP. relibaility and RTP are not necessarily exclusive; they happen to be at the moment, but there are a number of proposals before the IETF addressing this problem. I'd like to attack it as an orthogonal issue, if we can. -- David Singer Apple Computer/QuickTime From rem-conf Thu Oct 05 09:43:24 2000 From rem-conf-request@es.net Thu Oct 05 09:43:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hE4Q-0001Sq-00; Thu, 5 Oct 2000 09:40:34 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hE4P-0001Se-00; Thu, 5 Oct 2000 09:40:33 -0700 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id JAA07768 for ; Thu, 5 Oct 2000 09:40:32 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Thu, 5 Oct 2000 09:40:32 -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 JAA19115; Thu, 5 Oct 2000 09:40:31 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <0056890014623506000002L962*@MHS> References: <0056890014623506000002L962*@MHS> Date: Thu, 5 Oct 2000 09:35:55 -0700 To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 5:45 PM +0200 10/5/00, jan.vandermeer@philips.com wrote: >Dave, > >You wrote : > >>What is wrong with Carsten et al.'s sync layer mapping into RTP > >Good question, as usual. Let me list a few issues : > >1) Substantial overhead for small access units; a solution is being >discussed for audio, but not yet for the other streams I listed; some may >indeed deserve a more reliable transport method, but an RTP solution will be >required too, I think. Perhaps use of FlexMux the only solution here. I agree. Allow flexmux, where this is a problem, but don't mandate it. >2) Inclusion of a plain SL header with associated fields; I would prefer to >start with a byte indicating the length of the subsequent field that >contains the SL header. Such field is easily decodable by non-MPEG-4 system >receivers, provides a future proof solution (in future more information may >be contained in the SL header with a length that is unknown by now), and >creates room for fully compatible extensions. OK. This seems fine on the surface. >3) Little commonality with the Kikuchi-san drafts for audio and video. >Perhaps it is possible to merge both solutions by extending the Kikuchi-san >drafts with the option to carry an SL header (preceded by the above length >field), for example signaled by a new attribute "MPEG-4 SL header carried" >at SDP level. Wasn't this where the whole flare-up started; proposing to add an optional SL-header to the Kikuchi proposal. Perhaps an a=x-mpeg4-sl-header-length: attribute on any RTP stream carrying MPEG4 content should be permitted, and required if byte count is non-zero (with zero being the default)? This is just a question, as I realize there are still some messages I have not managed to read... >Kind regards, > >Jan > >>Can we assume that the following streams are probably most efficiently >>contained in a FlexMux stream, and consequently that is no need to specify >>use of RTP and SDP for those streams: >> >>- ObjectDescriptorStream >>- ClockReferenceStream >>- SceneDescriptionStream >>- MPEG-7Stream >>- IPMPStream >>- ObjectContentInfoStream >>- MPEGJStream > > >I would be strongly opposed to mandating the use of flexmux for any >stream. What is wrong with Carsten et al.'s sync layer mapping into >RTP? >-- >David Singer >Apple Computer/QuickTime -- David Singer Apple Computer/QuickTime From rem-conf Thu Oct 05 10:38:11 2000 From rem-conf-request@es.net Thu Oct 05 10:38:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hEuw-0003kT-00; Thu, 5 Oct 2000 10:34:50 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hEuu-0003kI-00; Thu, 5 Oct 2000 10:34:49 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA26900; Thu, 5 Oct 2000 10:34:47 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA12876; Thu, 5 Oct 2000 10:34:47 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id MAA05253; Thu, 5 Oct 2000 12:34:27 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id MAA08423; Thu, 5 Oct 2000 12:34:10 -0500 (CDT) Message-Id: <200010051734.MAA08423@agevole.cig.mot.com> Date: Thu, 05 Oct 2000 12:34:50 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Qiaobing Xie , Mikael Degermark , Krister Svanbro , Magnus Westerlund , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mikael, see my comments below... cheers, -Qiaobing Mikael Degermark wrote: ..snip... > >But if you are designing an RTP payload format, which is meant to be > >sent end-to-end over a routable IP connection, it does not make much > >sense to optimize the payload format design according to the error > >characteristics of any one type of the link which, after all, may or may > >not be present in the connection. > > If one expects that a common case will be that the payload is sent across > such links, it may make a lot of sense. But this is of course difficult to > predict. In my view, AMR is a general purpose codec and a good addition to the long list of codecs (eg, G711, G726, ...) currently used in many VoIP applications. To have a radio link in the path is just one of the use cases. Another thing is, even if you have a mobile unit (as your analysis goes below) at one end of the IP connection, you probably will still have a lot more ordinary wireline links to go through end-to-end. It is definitely desirable to make the payload format as radio-friendly as possible, but this should be done without compromising the "normal" link performance too much. > > >I have not problem with a) and I think it is in deed the job of AVT WG. > >No doubt that it is universally desirable to design any protocol message > >as compact and as compressed as possible (as Krister said: not to waste > >a bit) But in reality, you often have to make trade-off between saving > >a bit in the message and the associated processing cost, especially when > >the processing is done in a higher stack layer. > > The tradeoff is between the cost of sending the bits across the link and > the processing cost at the sender/receiver. As the end user will ultimately > pay for both, one has to consider the relative costs. > > When the amr format is used for voice, it seems that either of two > scenarios will occur: > > 1) users use some sort of mobile terminal. > 2) users use stationary terminals. > > For 1, the cost of bandwidth is very likely to be higher than the processing cost > if the mobile uses cellular radio. > > For 2, the cost of bandwidth is very low, but on the other hand > the incremental processing cost is zero when something like a PC is used > as the stationary terminal. > > So this very simple analysis does seem to favor a high degree of compression. I dis-agree with you here. First of all, you missed the third scenario: a transcoder supporting thousands of calls and multiple codecs in a heavy duty call center. In such a case, the computational intensity of the codec is going to be a big factor to your overall capacity. Secondly, if your analysis holds, why people are still doing bit-padding (i.e., "wasting" a few bits in order to gain octet-alignments) in almost all the protocols designed to run above IP (even IP itself is octet-aligned by bit-staffing)? Maybe we misunderstood each other, but I never said bits should be wasted, what I've been trying to point out is that the processing advantage gained by octet alignment in upper layer protocols is important and the AMR payload design is no exception if we are designing it for general purpose VoIP applications. > > >The error resilience > >part (or the lack of it) in the current AMR draft is exactly one of my > >big concerns as I talked about in my first email. > > > >Cheers, > >-Qiaobing > > > >> > >> The IETF should not worry ONLY about wireless, of course, but it certainly > >> seems appropriate to ensure that things work over wireless as well as over > >> the rest of the currently largely wired Internet. > >> > >> Cheers, > >> > >> Mikael Degermark > > From rem-conf Thu Oct 05 11:11:25 2000 From rem-conf-request@es.net Thu Oct 05 11:11:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hFQr-0005Q6-00; Thu, 5 Oct 2000 11:07:49 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hFQq-0005Pw-00; Thu, 5 Oct 2000 11:07:48 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA31407; Thu, 5 Oct 2000 11:07:42 -0700 Date: Thu, 5 Oct 2000 11:07:42 -0700 From: John Lazzaro Message-Id: <200010051807.LAA31407@snap.CS.Berkeley.EDU> To: micke@CS.Arizona.EDU, xieqb@cig.mot.com Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, Qiaobing_Xie-QXIE1@email.mot.com, rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > First of all, you missed the third scenario: a transcoder supporting > thousands of calls and multiple codecs in a heavy duty call center. In > such a case, the computational intensity of the codec is going to be a > big factor to your overall capacity. Why can't: [1] 1 bit in the AMR payload design signify "radio-friendly" or "landline-friendly" packetizations. [2] The "radio-friendly" packetization is designed to be ultra-efficient, while the "landline-friendly" packetization is designed to be CPU-friendly to general-purpose CPUs, and [3] Both packetizations are designed so that building special-purpose boxes that transcode large numbers of streams between the two packetizations is a straightforward task for an ASIC, DSP, or FPGA? This would seem to satisfy everyone's requirements in this thread ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Thu Oct 05 12:33:43 2000 From rem-conf-request@es.net Thu Oct 05 12:33:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hGiF-0000Ht-00; Thu, 5 Oct 2000 12:29:51 -0700 Received: from tmp235.east.isi.edu (purple.east.isi.edu) [38.245.76.235] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hGiE-0000Hh-00; Thu, 5 Oct 2000 12:29:50 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id PAA04989; Thu, 5 Oct 2000 15:30:53 -0400 Message-Id: <200010051930.PAA04989@purple.east.isi.edu> To: Dave Singer cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from Dave Singer of "Thu, 05 Oct 2000 09:35:55 PDT." Date: Thu, 05 Oct 2000 15:30:53 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Dave Singer writes: >At 5:45 PM +0200 10/5/00, jan.vandermeer@philips.com wrote: ... >>2) Inclusion of a plain SL header with associated fields; I would prefer to >>start with a byte indicating the length of the subsequent field that >>contains the SL header. Such field is easily decodable by non-MPEG-4 system >>receivers, provides a future proof solution (in future more information may >>be contained in the SL header with a length that is unknown by now), and >>creates room for fully compatible extensions. > >OK. This seems fine on the surface. If this is an issue, it seems to be a problem with the definition of SL headers in MPEG. The SL payload format is semantically identical to the MPEG-4 SL packets (just the bits get re-ordered on the wire). >>3) Little commonality with the Kikuchi-san drafts for audio and video. >>Perhaps it is possible to merge both solutions by extending the Kikuchi-san >>drafts with the option to carry an SL header (preceded by the above length >>field), for example signaled by a new attribute "MPEG-4 SL header carried" >>at SDP level. > >Wasn't this where the whole flare-up started; proposing to add an >optional SL-header to the Kikuchi proposal. > >Perhaps an a=x-mpeg4-sl-header-length: >attribute on any RTP stream carrying MPEG4 content should be >permitted, and required if byte count is non-zero (with zero being >the default)? In which case, signal using the payload type field... Colin From rem-conf Thu Oct 05 12:36:58 2000 From rem-conf-request@es.net Thu Oct 05 12:36:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hGnf-0000Xf-00; Thu, 5 Oct 2000 12:35:27 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hGnd-0000XO-00; Thu, 5 Oct 2000 12:35:26 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e95JJMx20481; Thu, 5 Oct 2000 21:19:22 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "John Lazzaro" , , Cc: , , , , Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Date: Thu, 5 Oct 2000 21:19:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200010051807.LAA31407@snap.CS.Berkeley.EDU> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > This would seem to satisfy everyone's requirements in this thread ... No, adding an option that increases implementation complexity further for everyone certainly does not meet *my* requirements... (In case you don't shiver already when you hear the word "option": How do you make sure the other guy sends you the variant you want?) Gruesse, Carsten From rem-conf Thu Oct 05 12:39:15 2000 From rem-conf-request@es.net Thu Oct 05 12:39:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hGq7-0000tq-00; Thu, 5 Oct 2000 12:37:59 -0700 Received: from tmp235.east.isi.edu (purple.east.isi.edu) [38.245.76.235] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hGq6-0000tG-00; Thu, 5 Oct 2000 12:37:58 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id PAA05032; Thu, 5 Oct 2000 15:37:01 -0400 Message-Id: <200010051937.PAA05032@purple.east.isi.edu> To: Qunshan_Gu@pictel.com cc: "Yoshihiro Kikuchi" , "Stephan Wenger" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Qunshan_Gu@pictel.com of "Thu, 05 Oct 2000 10:54:18 EDT." Date: Thu, 05 Oct 2000 15:37:01 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Qunshan_Gu@pictel.com writes: > >Hi Yoshihiro-san, Stephan, and Kris, > >Since short-video-header mode of MPEG-4 is essentially H.263V1 baseline, >RFC 2190 and RFC 2429 are both >allowed to be the packetization format in the H.263 world. For maximal >inter-operability with today's implementation, >and for compatibility with H.263 definition, I would suggest the inclusion >of both RFC2190 and RFC2429 in the >statement. I know for a fact that many H.263 over IP implementations are >still only using RFC2190. What about... "When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations)." Or is that still too strong? Colin From rem-conf Thu Oct 05 12:49:39 2000 From rem-conf-request@es.net Thu Oct 05 12:49:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hGyv-0002ZY-00; Thu, 5 Oct 2000 12:47:05 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hGyu-0002ZL-00; Thu, 5 Oct 2000 12:47:04 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id MAA31741; Thu, 5 Oct 2000 12:46:55 -0700 Date: Thu, 5 Oct 2000 12:46:55 -0700 From: John Lazzaro Message-Id: <200010051946.MAA31741@snap.CS.Berkeley.EDU> To: cabo@tzi.org, lazzaro@CS.Berkeley.EDU, micke@CS.Arizona.EDU, xieqb@cig.mot.com Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, Qiaobing_Xie-QXIE1@email.mot.com, rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > (In case you don't shiver already when you hear the word "option": > How do you make sure the other guy sends you the variant you want?) Basically, if you're a cell-phone, you're prepared to send/receive one option, and if you're not, you're prepared to send/receive the other. Interoperability would happen because the boxes sitting between the wired world and the wireless would translate packets on the fly. And yes, if you're hooking up a laptop running Windows to the cell network, as opposed to a cell-phone or designed-for-wireless PDA, your Windows media app will need to grok both options -- but if you've gone that route as a laptop user you expect some things might not work out of the box. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Thu Oct 05 12:51:25 2000 From rem-conf-request@es.net Thu Oct 05 12:51:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hH1u-0002w6-00; Thu, 5 Oct 2000 12:50:10 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hH1t-0002vu-00; Thu, 5 Oct 2000 12:50:09 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id MAA13781 for ; Thu, 5 Oct 2000 12:50:08 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 5 Oct 2000 12:50:07 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id MAA07591; Thu, 5 Oct 2000 12:50:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <200010051930.PAA04989@purple.east.isi.edu> References: <200010051930.PAA04989@purple.east.isi.edu> Date: Thu, 5 Oct 2000 12:49:22 -0700 To: Colin Perkins From: Dave Singer Subject: Re: Types of MPEG-4 streams over IP Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 3:30 PM -0400 10/5/00, Colin Perkins wrote: >--> Dave Singer writes: >>At 5:45 PM +0200 10/5/00, jan.vandermeer@philips.com wrote: >... >>>2) Inclusion of a plain SL header with associated fields; I would prefer to >>>start with a byte indicating the length of the subsequent field that >>>contains the SL header. Such field is easily decodable by non-MPEG-4 system > >>receivers, provides a future proof solution (in future more information may >>>be contained in the SL header with a length that is unknown by now), and >>>creates room for fully compatible extensions. >> >>OK. This seems fine on the surface. > >If this is an issue, it seems to be a problem with the definition of SL >headers in MPEG. The SL payload format is semantically identical to the >MPEG-4 SL packets (just the bits get re-ordered on the wire). OK, I elided the point that any overlapping features with RTP (sequence and timestamp) should be omitted in the contained SL header. There are other fields in it also... > >>3) Little commonality with the Kikuchi-san drafts for audio and video. >>>Perhaps it is possible to merge both solutions by extending the Kikuchi-san >>>drafts with the option to carry an SL header (preceded by the above length >>>field), for example signaled by a new attribute "MPEG-4 SL header carried" >>>at SDP level. >> >>Wasn't this where the whole flare-up started; proposing to add an >>optional SL-header to the Kikuchi proposal. >> >>Perhaps an a=x-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? > >In which case, signal using the payload type field... > >Colin which is what the framework used to say. oh boy. I personally have little trouble with progressing the framework, and Kikuchi, and Carsten, and Flexmux-in-RTP, with them all fitting into the same framework. But that was not the US NB position. -- David Singer Apple Computer/QuickTime From rem-conf Thu Oct 05 13:28:21 2000 From rem-conf-request@es.net Thu Oct 05 13:28:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hHbW-0005M2-00; Thu, 5 Oct 2000 13:26:58 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hHbV-0005Ls-00; Thu, 5 Oct 2000 13:26:57 -0700 Received: from SMTPMail.PicTel.com (hqsmtpmail.pictel.com [140.242.100.76]) by gateway-gw.pictel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA15072; Thu, 5 Oct 2000 16:23:55 -0400 (EDT) Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision To: Colin Perkins Cc: Qunshan_Gu@pictel.com, "Yoshihiro Kikuchi" , "Stephan Wenger" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> From: Qunshan_Gu@pictel.com Date: Thu, 5 Oct 2000 16:19:33 -0400 Message-ID: X-MIMETrack: Serialize by Router on SMTPMail/PicTel(Release 5.0.4 |June 8, 2000) at 10/05/2000 04:19:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, et al, I am happy with your revised statement. Thanx. Qunshan ------------- Colin Perkins @advent.ee.columbia.edu on 10/05/2000 03:37:01 PM Sent by: owner-4on2andIP-sys@advent.ee.columbia.edu To: Qunshan_Gu@pictel.com cc: "Yoshihiro Kikuchi" , "Stephan Wenger" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision --> Qunshan_Gu@pictel.com writes: > >Hi Yoshihiro-san, Stephan, and Kris, > >Since short-video-header mode of MPEG-4 is essentially H.263V1 baseline, >RFC 2190 and RFC 2429 are both >allowed to be the packetization format in the H.263 world. For maximal >inter-operability with today's implementation, >and for compatibility with H.263 definition, I would suggest the inclusion >of both RFC2190 and RFC2429 in the >statement. I know for a fact that many H.263 over IP implementations are >still only using RFC2190. What about... "When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations)." Or is that still too strong? Colin From rem-conf Thu Oct 05 13:31:13 2000 From rem-conf-request@es.net Thu Oct 05 13:31:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hHeX-0005XA-00; Thu, 5 Oct 2000 13:30:05 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hHeW-0005Wb-00; Thu, 5 Oct 2000 13:30:04 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA05344; Thu, 5 Oct 2000 13:28:43 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA17396; Thu, 5 Oct 2000 13:28:42 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id PAA20662; Thu, 5 Oct 2000 15:28:40 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id PAA10678; Thu, 5 Oct 2000 15:28:38 -0500 (CDT) Message-Id: <200010052028.PAA10678@agevole.cig.mot.com> Date: Thu, 05 Oct 2000 15:29:17 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Carsten Bormann" CC: John Lazzaro , micke@CS.Arizona.EDU, Qiaobing Xie-QXIE1 , krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree with you, and I am one of those shivering when hear the word "option" :-) Someone once said having options in a standard means partial failure of the standardization effort, but I won't go that far :) IMHO, options should only be used as the last resort. I still believe there should be a better solution which can satisfy both types of links. Bitwise swapping and shuffling are obviously very unfriendly to any general purpose CPU. I will soon put forward a proposal for a octet-oriented design. I believe that the octet-aligned payload format (I will clearly lay it out in a draft to avt WG) will be equally friendly to wireless link centric systems as well as other VoIP applications (did I mention that my employer Motorola is also a wireless/radio equipment vendor, meaning I care about wireless no less than other wireless advocates ;-)). Cheers, -Qiaobing , for the sake of the best thing is we can find something satisfy both types of links "Dr. Carsten Bormann" wrote: > > > This would seem to satisfy everyone's requirements in this thread ... > > No, adding an option that increases implementation complexity further for > everyone certainly does not meet *my* requirements... > (In case you don't shiver already when you hear the word "option": > How do you make sure the other guy sends you the variant you want?) > > Gruesse, Carsten From rem-conf Thu Oct 05 13:52:43 2000 From rem-conf-request@es.net Thu Oct 05 13:52:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hHzD-0007Ra-00; Thu, 5 Oct 2000 13:51:27 -0700 Received: from (motgate3.mot.com) [144.189.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hHzC-0007RQ-00; Thu, 5 Oct 2000 13:51:26 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA08763; Thu, 5 Oct 2000 13:48:41 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA24287; Thu, 5 Oct 2000 13:51:12 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id PAA27739; Thu, 5 Oct 2000 15:51:11 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id PAA10873; Thu, 5 Oct 2000 15:51:10 -0500 (CDT) Message-Id: <200010052051.PAA10873@agevole.cig.mot.com> Date: Thu, 05 Oct 2000 15:51:49 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Lazzaro CC: micke@CS.Arizona.EDU, Qiaobing Xie-QXIE1 , krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <200010051807.LAA31407@snap.CS.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list John Lazzaro wrote: ...snip... > [3] Both packetizations are designed so that building special-purpose > boxes that transcode large numbers of streams between the two > packetizations is a straightforward task for an ASIC, DSP, or FPGA? Even most DSPs will have a strong preference/performance gain when the operations are octet-aligned. Asking for ASIC, FPGA support to make a user level protocol operate with capacity does not sound encouraging to vendors/operators at all. Besides cell phones and laptops, transcoding is a common function for a lot of Media Gateways. Samll or large, I don't think many of them are built using special hardware. To lower the cost, the vendor would love to see that they can be built on off the shelf platforms. With the bit level shuffling loops as defined in the current payload format draft, I guess that a 700MHz Pentium II probably will only be able to sustain a few streams for real time transcoding. Of cause I have no data to back this up, just guessing. Maybe the authors can give us some performance numbers if they've even implemented it... -Qiaobing From rem-conf Thu Oct 05 16:03:27 2000 From rem-conf-request@es.net Thu Oct 05 16:03:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hK0e-000488-00; Thu, 5 Oct 2000 16:01:04 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hK0c-00047n-00; Thu, 5 Oct 2000 16:01:02 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id QAA28101 for ; Thu, 5 Oct 2000 16:01:01 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 5 Oct 2000 16:01:01 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id QAA25119; Thu, 5 Oct 2000 16:01:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: Date: Thu, 5 Oct 2000 15:56:24 -0700 To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu From: Dave Singer Subject: what Mime type for MP4 files? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list a reply from the gurus at the IETF about the (e.g. HTTP) mime type for MP4 files... >The top-level questions for MPEG are: >a) do we belong under video, or application, for general MPEG-4 >sessions? I strongly prefer video. >I prefer video, as it warns the terminal that a >presentation is coming, it's parallel to MPEG, and I'm concerned that >"application" may be treated more circumspectly by security software. >But the Beijing MPEG meeting preferred application. Without knowing why I cannot comment, but historically such formats have gone under video. I expect there to be pushback if application is attempted. >b) A taste question. Is the /mpeg4 to match the name of the standard >(my preference, along with Steve Casner), or /mp4 to match the file >format name? I personally prefer the former, but as you say, it is solely a matter of taste. >c) I'm fairly sure that we should say a lot more about security, as >we allow embedded URLs, and have a Java layer that can deliver >"applets". What sort of analysis is needed here? Basically, you need to note the issues. If I were you I'd take a look at existing registrations of similar things and add what you need. -- David Singer Apple Computer/QuickTime From rem-conf Thu Oct 05 16:14:47 2000 From rem-conf-request@es.net Thu Oct 05 16:14:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hKDG-0005Gq-00; Thu, 5 Oct 2000 16:14:06 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hKDE-0005GQ-00; Thu, 5 Oct 2000 16:14:04 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id QAA17671; Thu, 5 Oct 2000 16:14:02 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA05736; Thu, 5 Oct 2000 16:13:59 -0700 (MST) Message-Id: <200010052313.QAA05736@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Oct 2000 01:16:03 +0200 To: Qiaobing Xie From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Mikael Degermark , Mikael Degermark , Krister Svanbro , Magnus Westerlund , rem-conf@es.net In-Reply-To: <200010051734.MAA08423@agevole.cig.mot.com> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Qiaobing, At 12:34 PM 10/5/00 -0500, Qiaobing Xie wrote: >Mikael Degermark wrote: >..snip... >> >But if you are designing an RTP payload format, which is meant to be >> >sent end-to-end over a routable IP connection, it does not make much >> >sense to optimize the payload format design according to the error >> >characteristics of any one type of the link which, after all, may or may >> >not be present in the connection. >> >> If one expects that a common case will be that the payload is sent across >> such links, it may make a lot of sense. But this is of course difficult to >> predict. > >In my view, AMR is a general purpose codec and a good addition to the >long list of codecs (eg, G711, G726, ...) currently used in many VoIP >applications. To have a radio link in the path is just one of the use >cases. Another thing is, even if you have a mobile unit (as your >analysis goes below) at one end of the IP connection, you probably will >still have a lot more ordinary wireline links to go through end-to-end. >It is definitely desirable to make the payload format as radio-friendly >as possible, but this should be done without compromising the "normal" >link performance too much. The normal link performance will be improved by having smaller payloads, right? So what you must be arguing for here cannot really have much to do with link performance. >> The tradeoff is between the cost of sending the bits across the link and >> the processing cost at the sender/receiver. As the end user will ultimately >> pay for both, one has to consider the relative costs. >> >> When the amr format is used for voice, it seems that either of two >> scenarios will occur: >> >> 1) users use some sort of mobile terminal. >> 2) users use stationary terminals. >> >> For 1, the cost of bandwidth is very likely to be higher than the processing cost >> if the mobile uses cellular radio. >> >> For 2, the cost of bandwidth is very low, but on the other hand >> the incremental processing cost is zero when something like a PC is used >> as the stationary terminal. >> >> So this very simple analysis does seem to favor a high degree of compression. > >I dis-agree with you here. > >First of all, you missed the third scenario: a transcoder supporting >thousands of calls and multiple codecs in a heavy duty call center. In >such a case, the computational intensity of the codec is going to be a >big factor to your overall capacity. Yes, this is certainly a valid scenario and a valid concern. >Secondly, if your analysis holds, why people are still doing bit-padding >(i.e., "wasting" a few bits in order to gain octet-alignments) in almost >all the protocols designed to run above IP (even IP itself is >octet-aligned by bit-staffing)? Perhaps because the wireless case has not been frequent enough. When the bandwidth cost is almost zero, it does make a lot of sense for a good engineer to save on processing power. >Maybe we misunderstood each other, but I never said bits should be >wasted, what I've been trying to point out is that the processing >advantage gained by octet alignment in upper layer protocols is >important and the AMR payload design is no exception if we are designing >it for general purpose VoIP applications. I guess the real issue is not what layer the processing is done at, but rather if it is done by a general-purpose processor or by a more specialized processor. Would the call-center scenario you described above use general-purpose processors to do the transcoding or would more specialized hardware be deployed? Cheers, Micke From rem-conf Thu Oct 05 16:54:32 2000 From rem-conf-request@es.net Thu Oct 05 16:54:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hKok-0007IJ-00; Thu, 5 Oct 2000 16:52:50 -0700 Received: from cleitus.hosting.pacbell.net [216.100.99.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hKod-0007I7-00; Thu, 5 Oct 2000 16:52:45 -0700 Received: from testarosa (adsl-63-204-17-58.dsl.snfc21.pacbell.net [63.204.17.58]) by cleitus.hosting.pacbell.net id TAA22677; Thu, 5 Oct 2000 19:52:42 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Mikael Bourges-Sevenier" To: "Dave Singer" , , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: what Mime type for MP4 files? Date: Thu, 5 Oct 2000 16:41:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Even if historically MPEG is more concerned with video, MPEG-4 deals with so many different kinds of streams that I would prefer application/x-mp4 or x-mpeg4. In general as the BIFS stream defines a scene I would view it as a special kind of application. Mikael Bourges-Sevenier iVAST Inc. > -----Original Message----- > From: owner-4on2andIP-sys@advent.ee.columbia.edu > [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave > Singer > Sent: Thursday, October 05, 2000 3:56 PM > To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: what Mime type for MP4 files? > > > a reply from the gurus at the IETF about the (e.g. HTTP) mime type > for MP4 files... > > >The top-level questions for MPEG are: > >a) do we belong under video, or application, for general MPEG-4 > >sessions? > > I strongly prefer video. > > >I prefer video, as it warns the terminal that a > >presentation is coming, it's parallel to MPEG, and I'm concerned that > >"application" may be treated more circumspectly by security software. > >But the Beijing MPEG meeting preferred application. > > Without knowing why I cannot comment, but historically such formats have > gone under video. I expect there to be pushback if application is > attempted. > > >b) A taste question. Is the /mpeg4 to match the name of the standard > >(my preference, along with Steve Casner), or /mp4 to match the file > >format name? > > I personally prefer the former, but as you say, it is solely a matter of > taste. > > >c) I'm fairly sure that we should say a lot more about security, as > >we allow embedded URLs, and have a Java layer that can deliver > >"applets". What sort of analysis is needed here? > > Basically, you need to note the issues. If I were you I'd take a look > at existing registrations of similar things and add what you need. > -- > David Singer > Apple Computer/QuickTime > From rem-conf Thu Oct 05 17:23:03 2000 From rem-conf-request@es.net Thu Oct 05 17:23:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hLES-0001Tt-00; Thu, 5 Oct 2000 17:19:24 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hLER-0001Tj-00; Thu, 5 Oct 2000 17:19:23 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id RAA00975 for rem-conf@es.net; Thu, 5 Oct 2000 17:19:25 -0700 Date: Thu, 5 Oct 2000 17:19:25 -0700 From: John Lazzaro Message-Id: <200010060019.RAA00975@snap.CS.Berkeley.EDU> To: rem-conf@es.net Subject: Re: what Mime type for MP4 files? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>b) A taste question. Is the /mpeg4 to match the name of the standard >>(my preference, along with Steve Casner), or /mp4 to match the file >>format name? > >>I personally prefer the former, but as you say, it is solely a matter of >>taste. > Has the Global Music One USPTO Trademark issue on 'MP4' been brought to a resolution yet? This might be of some relevence ... Last I had heard of the matter is summarized in this M4IF web page: http://www.m4if.org/mp4.html but this is quite dated ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Thu Oct 05 17:53:51 2000 From rem-conf-request@es.net Thu Oct 05 17:53:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hLiw-0003KF-00; Thu, 5 Oct 2000 17:50:54 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hLiu-0003K5-00; Thu, 5 Oct 2000 17:50:52 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id RAA21815 for ; Thu, 5 Oct 2000 17:50:51 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 5 Oct 2000 17:50:50 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id RAA17675; Thu, 5 Oct 2000 17:50:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 5 Oct 2000 17:49:52 -0700 To: Mikael Bourges-Sevenier From: Dave Singer Subject: RE: what Mime type for MP4 files? Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 4:41 PM -0700 10/5/00, Mikael Bourges-Sevenier wrote: >Even if historically MPEG is more concerned with video, MPEG-4 deals with so >many different kinds of streams that I would prefer application/x-mp4 or >x-mpeg4. >In general as the BIFS stream defines a scene I would view it as a special >kind of application. The problems are that many people see "application" as a potential threat to their security, and try to block it. Another problem is that the mime type is supposed to indicate the kind of behavior at the client: video indicates a time-based visual presentation, whereas application can be (and often is) anything at all. The behavior of Mpeg4 is basically intended to be visual, unless an audio-only session is wanted (whereupon the mime type audio/mpeg4 should be used). In the view of this expert on mime naming, visual is much to be preferred (and I agree). By the way, we are asking for an official registration, and therefore there will be no "x-" at all. >Mikael Bourges-Sevenier >iVAST Inc. > >> -----Original Message----- >> From: owner-4on2andIP-sys@advent.ee.columbia.edu >> [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave >> Singer >> Sent: Thursday, October 05, 2000 3:56 PM >> To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu >> Subject: what Mime type for MP4 files? >> >> >> a reply from the gurus at the IETF about the (e.g. HTTP) mime type >> for MP4 files... >> >> >The top-level questions for MPEG are: >> >a) do we belong under video, or application, for general MPEG-4 >> >sessions? >> >> I strongly prefer video. >> >> >I prefer video, as it warns the terminal that a >> >presentation is coming, it's parallel to MPEG, and I'm concerned that >> >"application" may be treated more circumspectly by security software. >> >But the Beijing MPEG meeting preferred application. >> >> Without knowing why I cannot comment, but historically such formats have >> gone under video. I expect there to be pushback if application is >> attempted. >> >> >b) A taste question. Is the /mpeg4 to match the name of the standard >> >(my preference, along with Steve Casner), or /mp4 to match the file >> >format name? >> >> I personally prefer the former, but as you say, it is solely a matter of >> taste. >> >> >c) I'm fairly sure that we should say a lot more about security, as >> >we allow embedded URLs, and have a Java layer that can deliver >> >"applets". What sort of analysis is needed here? >> >> Basically, you need to note the issues. If I were you I'd take a look >> at existing registrations of similar things and add what you need. > > -- > > David Singer > > Apple Computer/QuickTime > > -- David Singer Apple Computer/QuickTime From rem-conf Thu Oct 05 18:53:21 2000 From rem-conf-request@es.net Thu Oct 05 18:53:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hMc4-0006Yc-00; Thu, 5 Oct 2000 18:47:52 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hMc2-0006YS-00; Thu, 5 Oct 2000 18:47:51 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA06246; Thu, 5 Oct 2000 21:35:05 -0400 Message-Id: <200010060135.VAA06246@purple.east.isi.edu> To: John Lazzaro cc: micke@CS.Arizona.EDU, xieqb@cig.mot.com, krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, Qiaobing_Xie-QXIE1@email.mot.com, rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt In-Reply-To: Message from John Lazzaro of "Thu, 05 Oct 2000 11:07:42 PDT." <200010051807.LAA31407@snap.CS.Berkeley.EDU> Date: Thu, 05 Oct 2000 21:35:05 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> John Lazzaro writes: >> First of all, you missed the third scenario: a transcoder supporting >> thousands of calls and multiple codecs in a heavy duty call center. In >> such a case, the computational intensity of the codec is going to be a >> big factor to your overall capacity. > >Why can't: > >[1] 1 bit in the AMR payload design signify "radio-friendly" or > "landline-friendly" packetizations. Why waste a bit in the payload? Just use a different RTP payload type number..... I strongly recommend we don't go down this road. Colin From rem-conf Thu Oct 05 18:53:21 2000 From rem-conf-request@es.net Thu Oct 05 18:53:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hMbU-0006YD-00; Thu, 5 Oct 2000 18:47:16 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hMbT-0006Xl-00; Thu, 5 Oct 2000 18:47:15 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA06115; Thu, 5 Oct 2000 21:19:36 -0400 Message-Id: <200010060119.VAA06115@purple.east.isi.edu> To: Dave Singer cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: what Mime type for MP4 files? In-Reply-To: Message from Dave Singer of "Thu, 05 Oct 2000 15:56:24 PDT." Date: Thu, 05 Oct 2000 21:19:35 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, all, We have to be careful with the various RTP payload formats, so we have consistent types, e.g. if we register video/mpeg4 for the file format, we should register video/mpeg4-es not video/mp4-es (or whatever...). Just something to think about when writing the payload format drafts. --> Dave Singer writes: >a reply from the gurus at the IETF about the (e.g. HTTP) mime type >for MP4 files... > >>The top-level questions for MPEG are: >>a) do we belong under video, or application, for general MPEG-4 >>sessions? > >I strongly prefer video. > >>I prefer video, as it warns the terminal that a >>presentation is coming, it's parallel to MPEG, and I'm concerned that >>"application" may be treated more circumspectly by security software. >>But the Beijing MPEG meeting preferred application. > >Without knowing why I cannot comment, but historically such formats have >gone under video. I expect there to be pushback if application is attempted. probably. What about audio/mp4 though? Do we need register both? >>b) A taste question. Is the /mpeg4 to match the name of the standard >>(my preference, along with Steve Casner), or /mp4 to match the file >>format name? > >I personally prefer the former, but as you say, it is solely a matter of >taste. /mp4 matches the types defined in the profile more closely... >>c) I'm fairly sure that we should say a lot more about security, as >>we allow embedded URLs, and have a Java layer that can deliver >>"applets". What sort of analysis is needed here? > >Basically, you need to note the issues. If I were you I'd take a look >at existing registrations of similar things and add what you need. Agree that there's a strong need for this - we had feedback from our area directors at the last IETF, who were very concerned about the potential security issues with MPEG-4. Colin From rem-conf Thu Oct 05 19:11:25 2000 From rem-conf-request@es.net Thu Oct 05 19:11:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hMvH-0000Ro-00; Thu, 5 Oct 2000 19:07:43 -0700 Received: from dns.3we.co.jp [210.160.164.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hMvE-0000Qm-00; Thu, 5 Oct 2000 19:07:41 -0700 Received: from t369meN18 (el06-24-131-156-224.ce.mediaone.net [24.131.156.224]) by dns.3we.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4GWJG1PC; Fri, 6 Oct 2000 11:15:38 +0900 DATE: 05 Oct 00 10:46:43 PM FROM: hHo7g3DpX@ludens.elte.hu Message-ID: TO: hedipco10q@waverider.co.uk SUBJECT: Fast Results Now! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Reach your Target Market on the Internet - Guaranteed! That's right.. Targeted direct e-mail campaigns are the fastest way to gain web awareness and cash flow when you start up a business online. As you might already know, website recipricals - links, search engine listings and online promotions can take weeks if not months to take effect. Targeted e-mailing on the other hand has immediate results and can achieve immediate cash flow. Everyone on the Internet has e-mail access. The most beneficial aspect of targeted direct e-mailing is you can test ads within a matter of days and know if the campaign is successful with in a week. There is NO other advertising medium on the web that will get you results this quick and easy. We are a Targeted Direct E-mail Marketing business. We work with serious minded business owners using our advanced targeting capability and marketing system to expand your business online. Our targeting capability takes advantage of the power of keywords and directories on the Internet, targeting your market which is tailored to your specific business needs. We can target by area code (city/state/country), age range, gender, occupation, and descriptive keywords that we use to define your market. Reach your target market on the information superhighway - GUARANTEED! Are you interested in using our services to seriously promote your business or opportunity? Prices start at $1500 and up for targeted. General mailings at $450. Take advantage of our Fall Special! To get going Now, pick up the phone and and call our offices **** 708 401 1688 * Mon-Fri 10am-5pm Central Time or email to:vx151z@yemenmail.com We look forward to working with you. Sincerly, Julie Jones Resource Marketing ******************************************************************* You received this message because you visited one of our web sites or requested information. To be removed please send an email to: jaqrv19@yemenmail.com From rem-conf Fri Oct 06 02:20:05 2000 From rem-conf-request@es.net Fri Oct 06 02:20:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hTUK-0000Xt-00; Fri, 6 Oct 2000 02:08:20 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hTUJ-0000Wh-00; Fri, 6 Oct 2000 02:08:19 -0700 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e9698Gt29249 for ; Fri, 6 Oct 2000 11:08:17 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Oct 06 11:01:04 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 6 Oct 2000 11:07:20 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA94102FA147E@edeacnt100.eed.ericsson.se> From: "Helmut Wittmann (EED)" To: "'Mikael Degermark'" , Qiaobing Xie Cc: Krister Svanbro , Magnus Westerlund , rem-conf@es.net Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Date: Fri, 6 Oct 2000 11:07:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleages, time for a small own contribution. I am working with Ericsson in Nuremberg in a department that develops realtime software for transcoders for all current mobile communication standards. My personal work is focussed more on speech transcoding software on PC platforms. I do not share the concerns on processing capacity. As mentioned before, we are talking about two totally different application scenarios: 1 Highly specialized hardware with highly optimized software, such is the case for our transcoders. In this case you are putting much effort to run as many speech channels as possible on a given piece of hardware. The additional complexity caused by some non-optimum bit-shuffling should always much smaller than the "speech processing load" itself. One speech channel is dimensioned that it can run in realtime, given the known worst case known for one channel, assuming the worst case happenening coincidently on all channels plus also "some" extra time because it is difficult to judge the worst case, you need some complexity reserve for bug fixes, work-arounds, small functional changes and simply because a clever designer would never fully go to the theoretical limit. In such a scenario we would have always enough processing power left to cope with even non-optimum bit-suffling tasks. Or, spoken in the words of a bussiness man: "We are only talking about nr of speech channels per given board, nothing else. Everything, that does not impact this key factor is beyond our considerations." And that is the case for packetizing complexity, or better: the complexity difference between optimized and non-optimized packetizing: It is NOT SIGNIFICANT compared to the overall board load. 2 General purpose hardware and non-optimized software/ software optimized to a very low degree. To illustrate this, I recall the complexity figures Magnus had given a couple of contributions before: "(...) We are using the optimized official ETSI/3GPP floating point AMR codec and an unoptimized payload packetizer. The load is expressed in percent of an Windows NT machine with a Pentium III 500 MHz processor. Speech encoder: 7.1% Payload packetizer: 0.058 % Payload depacketizer: 0.058 % Speech decoder: 1.1% (...)" This figures derive from an AMR implementation already optimized in C and compiled with optimum, machine-specific switches. Hence, the load ratio could no further be improved in favor of the speech transcoding with simple measures (assembler level optimization is not a a simple measure). And what would be a typical application scenario here? Maybe the much-mentioned call-center. The vendor wants to use PC hardware, wants to be fast at the market, machine optimization would not make sense because we would have much faster hardware available in short time (Moore's Law). So, what does he do? Compiles his C programs directly and hopes to get as many speech channels onto the CPU as possible. But he would not try to do any further optimization to gain a fraction of what he now has as nr of channels. And the nr of channels? He will make some rough estimates on the actual capacity, given simplifying assumptions on actual DTX use, actual codec use distribution (different codecs, different AMR modi), other fluctuations such as varying background load etc. In any case, this will be a rough estimate and he is well-advised not to be too optimistic in his assumptions. In this scenario, the packetizing load is also NOT SIGNIFICANT. It is even much more insignificant than for scenario 1, because there we are really optimizing a high-volume product with a very specific software architecture design. In turn, in scenario 2 we want use the same platform-non-specific C programs for years. The following fact may illustrate this further: If you are measuring the load of e.g. the AMR codec on a PC, running it several times on the same speech data, you are experiencing fluctuations which exceed the load contribution of packetizing/de-packetizing clearly. (For clarification: Each routine which is part of the AMR is measured also seperately and the fluctuations reflect also there. The above figures are average figures for a long data sequence). Summarizing, I really do consider the bit-shuffling load as insignificant. It should not be focussed on as the ultimate optimization target. The time-to-market IP world, and the IP call center with PC hardware belongs here, I guess, would reduce all our concerns to absurdum. Best regards, Helmut Wittmann -----Original Message----- From: Mikael Degermark [mailto:micke@CS.Arizona.EDU] Sent: Friday, 06 October, 2000 01:16 To: Qiaobing Xie Cc: Mikael Degermark; Mikael Degermark; Krister Svanbro; Magnus Westerlund; rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Hi Qiaobing, At 12:34 PM 10/5/00 -0500, Qiaobing Xie wrote: >Mikael Degermark wrote: >..snip... >> >But if you are designing an RTP payload format, which is meant to be >> >sent end-to-end over a routable IP connection, it does not make much >> >sense to optimize the payload format design according to the error >> >characteristics of any one type of the link which, after all, may or may >> >not be present in the connection. >> >> If one expects that a common case will be that the payload is sent across >> such links, it may make a lot of sense. But this is of course difficult to >> predict. > >In my view, AMR is a general purpose codec and a good addition to the >long list of codecs (eg, G711, G726, ...) currently used in many VoIP >applications. To have a radio link in the path is just one of the use >cases. Another thing is, even if you have a mobile unit (as your >analysis goes below) at one end of the IP connection, you probably will >still have a lot more ordinary wireline links to go through end-to-end. >It is definitely desirable to make the payload format as radio-friendly >as possible, but this should be done without compromising the "normal" >link performance too much. The normal link performance will be improved by having smaller payloads, right? So what you must be arguing for here cannot really have much to do with link performance. >> The tradeoff is between the cost of sending the bits across the link and >> the processing cost at the sender/receiver. As the end user will ultimately >> pay for both, one has to consider the relative costs. >> >> When the amr format is used for voice, it seems that either of two >> scenarios will occur: >> >> 1) users use some sort of mobile terminal. >> 2) users use stationary terminals. >> >> For 1, the cost of bandwidth is very likely to be higher than the processing cost >> if the mobile uses cellular radio. >> >> For 2, the cost of bandwidth is very low, but on the other hand >> the incremental processing cost is zero when something like a PC is used >> as the stationary terminal. >> >> So this very simple analysis does seem to favor a high degree of compression. > >I dis-agree with you here. > >First of all, you missed the third scenario: a transcoder supporting >thousands of calls and multiple codecs in a heavy duty call center. In >such a case, the computational intensity of the codec is going to be a >big factor to your overall capacity. Yes, this is certainly a valid scenario and a valid concern. >Secondly, if your analysis holds, why people are still doing bit-padding >(i.e., "wasting" a few bits in order to gain octet-alignments) in almost >all the protocols designed to run above IP (even IP itself is >octet-aligned by bit-staffing)? Perhaps because the wireless case has not been frequent enough. When the bandwidth cost is almost zero, it does make a lot of sense for a good engineer to save on processing power. >Maybe we misunderstood each other, but I never said bits should be >wasted, what I've been trying to point out is that the processing >advantage gained by octet alignment in upper layer protocols is >important and the AMR payload design is no exception if we are designing >it for general purpose VoIP applications. I guess the real issue is not what layer the processing is done at, but rather if it is done by a general-purpose processor or by a more specialized processor. Would the call-center scenario you described above use general-purpose processors to do the transcoding or would more specialized hardware be deployed? Cheers, Micke From rem-conf Fri Oct 06 02:57:28 2000 From rem-conf-request@es.net Fri Oct 06 02:57:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hUCI-0002KU-00; Fri, 6 Oct 2000 02:53:46 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hUCF-0002Ju-00; Fri, 6 Oct 2000 02:53:43 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39DCD94C00008456 for rem-conf@es.net; Fri, 6 Oct 2000 11:50:00 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39DC96F30000CFDE for rem-conf@es.net; Fri, 6 Oct 2000 11:48:54 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Fri, 06 Oct 2000 11:48:52 +0200 (Paris, Madrid (heure d'été)) X-Internal-ID: 39CA6F210000867B Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Fri, 6 Oct 2000 11:53:52 +0200 Received: from thomcast.thomson-csf.com ([178.3.1.228]) by minos.snmrennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.62) with ESMTP id 392; Fri, 6 Oct 2000 11:37:52 +0200 Message-ID: <39DDA066.C21995B7@thomcast.thomson-csf.com> Date: Fri, 06 Oct 2000 11:50:30 +0200 From: "Pierre Clement" X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Dave Singer CC: CURET Dominique FTRD/DMI/REN , rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> , CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, 'Olivier Avaro' Subject: Re: Types of MPEG-4 streams over IP References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-Printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, To announce the MuxCodeTable in a multicast scenario, it is possible to s= end it periodically thanks to SAP/SDP. Among others, SAP is used to transmit periodically the SDP file as described in Dave's proposal. Dave explicitely mentionned the use of a URL in his proposal; it may be usefull to also mention the fact that the MuxCodeTable can be also direct= ly conveyed in a SDP file in its binary format. Pierre Dave Singer a =E9crit : > > >Dave said that :"The MuxCodeTable needs to be delivered out-of-band". > >**it certainly needs to be delivered. > > > >Pierre showed how it is possible to deliver it, accurately in time, by > >out of band means > > > >**But is 'out of band' compatible with a multicast or broadcast scenar= io. > >**So, I think agree with Jan that an inband means is necessary. > > of course it is. my framework proposal showed how. in a multicast > or broadcast, there is always some information that is given to the > terminal to enable it to open the streams. in IETF world, that is an > SDP file. I showed how to put the IOD and the flexmux info into the > SDP file. > -- > David Singer > Apple Computer/QuickTime From rem-conf Fri Oct 06 04:13:23 2000 From rem-conf-request@es.net Fri Oct 06 04:13:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hVLV-00058C-00; Fri, 6 Oct 2000 04:07:21 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hVLT-00057v-00; Fri, 6 Oct 2000 04:07:19 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA18239; Fri, 6 Oct 2000 13:07:17 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma018236; Fri, 6 Oct 00 13:07:17 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA22701; Fri, 6 Oct 2000 13:07:17 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA01389; Fri, 6 Oct 2000 13:07:16 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014641266; Fri, 6 Oct 2000 13:08:21 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014641266000002L962*@MHS> Date: Fri, 6 Oct 2000 13:08:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/06/00 14:05:36" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Pierre, Possibly a misunderstanding from my side. I thought that the MuxCode ta= ble may change in the course of a stream. If yes, then it needs to be signa= led where in the FlexMux stream the new table starts to apply. For this pur= pose carriage of the table within the FlexMux stream would be useful. Howeve= r, probably the MuxCode table is intended to apply to any FlexMux packet i= n MuxCode mode throughout the entire FlexMux stream. Is this right ? Regards, Jan -----Original Message----- From: pierre.clement@thomcast.thomson-csf.com [mailto:pierre.clement@thomcast.thomson-csf.com] Sent: vrijdag, 06 oktober, 2000 12:05 To: singer@apple.com Cc: olivier.avaro@francetelecom.fr; Jan vanderMeer; dominique.curet@francetelecom.fr; 4on2andIP-sys@advent.ee.columbia.edu;= rem-conf@es.net; dominique.curet@rd.francetelecom.fr Subject: Re: Types of MPEG-4 streams over IP Dear all, To announce the MuxCodeTable in a multicast scenario, it is possible to= send it periodically thanks to SAP/SDP. Among others, SAP is used to transmi= t periodically the SDP file as described in Dave's proposal. Dave explicitely mentionned the use of a URL in his proposal; it may be= usefull to also mention the fact that the MuxCodeTable can be also dire= ctly conveyed in a SDP file in its binary format. Pierre Dave Singer a =E9crit : > > >Dave said that :"The MuxCodeTable needs to be delivered out-of-band"= . > >**it certainly needs to be delivered. > > > >Pierre showed how it is possible to deliver it, accurately in time, = by > >out of band means > > > >**But is 'out of band' compatible with a multicast or broadcast scen= ario. > >**So, I think agree with Jan that an inband means is necessary. > > of course it is. my framework proposal showed how. in a multicast > or broadcast, there is always some information that is given to the > terminal to enable it to open the streams. in IETF world, that is an= > SDP file. I showed how to put the IOD and the flexmux info into the > SDP file. > -- > David Singer > Apple Computer/QuickTime = From rem-conf Fri Oct 06 04:13:23 2000 From rem-conf-request@es.net Fri Oct 06 04:13:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hVMI-00058g-00; Fri, 6 Oct 2000 04:08:10 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hVMG-00058U-00; Fri, 6 Oct 2000 04:08:09 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id UAA25887; Fri, 6 Oct 2000 20:08:01 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id UAA16908; Fri, 6 Oct 2000 20:08:01 +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 UAA20902; Fri, 6 Oct 2000 20:08:00 +0900 (JST) Received: from ave (srg-204 [133.196.81.204]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id UAA29097; Fri, 6 Oct 2000 20:08:00 +0900 (JST) Message-ID: <085201c02f85$bc4d1ce0$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: Cc: "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <0056900012516881000002L012*@MHS> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Fri, 6 Oct 2000 20:08:19 +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 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Philippe and all, > I would like to know why the presence of configuration information in the SDP is > OPTIONAL. > > I would think much preferable if the profile-level-id and config fields would be > REQUIRED. > I'm wondering if it is better to change profile-level-id and config as mandate, although reasons are much different from Philippe's. > The reasons being that: > > - it is only a few bytes anyway > No. It is at least tens of bytes and may go up to a few hundred. It is not huge (sufficiently small compared to a VOP size) but not so very small. > - a decoder implementation would always > have the possibility to be initialized using the information in the SDP, > which is easier for many implementation because parsing the video > syntax requires a video decoder and when you instanciate > a video decoder it is VERY handy to already have the configuration ! > I don't think out-of-band transport of configuration information will always save the codec load. It much depends on the implementation. But decoders optimized for out-of-band may be relaxed. > - it would help a receiver discover that it cannot decode a given stream > (without having to request and start receiving the actual stream and parse it) > and that may be the key reason: in all modes of delivery this > would solve a "security" issue: > > A malignant (or stupid) user of a non-capable decoder could generate > a lot of traffic by requesting repeatedly streams that cannot be decoded, > which the decoder could discover "at once" by parsing the SDP, > if the SDP would always contain the config info... > > - it would save (a little) bandwidth since frequent repetition of VOL in the > stream is > required only for clients who do not use SDP info, you could then > have streams that actually do not repeat the VOL, or only rarely. > I'm not sure how much it is, but it may be save a little. Maybe, another good reason for changing config to mandate is an error resiliency. I think in most cases repetition of VOL header inside video stream work properly, but not 100% guaranty. For error-prone environment such as mobile, it should at least be recommended to use config in SDP which is delivered through reliable channel (by TCP/IP?). For detailed definition, I don't think there is no problem to change profile-level-id to required parameter. Maybe we can remove the default value by this. However, since config is defined that this parameter shall not be used for the capability exchange, and actually config is not to indicate the capability but coder configuration, there is a problem to change it as required. How about changing the first sentence of config as follows? "config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. ......" Since the parameter config is added by requests to keep interlocking with 32x-based systems, I would like to hear if this change matches the request. I would also like to hear from IETF experts if it is usual in IETF world to add this kind of parameter as required. Best regards, Yoshihiro ---- 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 1267 From rem-conf Fri Oct 06 05:50:30 2000 From rem-conf-request@es.net Fri Oct 06 05:50:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hWsN-0001hp-00; Fri, 6 Oct 2000 05:45:23 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hWsM-0001hf-00; Fri, 6 Oct 2000 05:45:22 -0700 Received: from [206.15.135.60] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 536293; Fri, 06 Oct 2000 08:42:34 -0400 Message-ID: <39DDCAD2.1B8CE037@21rst-century.com> Date: Fri, 06 Oct 2000 08:51:30 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Fethi Filali CC: rmt@lbl.gov, rem-conf@es.net Subject: Re: Multicast and Unicast Flows Fairness References: <39DD87C6.10C58153@sophia.inria.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Fethi Filali wrote: > > hi all, > > My question is how the internet community define the fairness between > reliable multicast and TCP connections sharing the same communication > link. > > Should a reliable multicast flows be treated as a TCP flow ? Or, should > the reliable multicast flows be given more bandwidth than TCP flow > because it is intended to serve more receivers? In the second case, how > much more bandwidth should be given to the multicast flow and how do the > Internet community define this fairness. > > Thanks, > > Fethi. Dear Fethi; This has been discussed at length on the AVT list, because of the desire to add something about congestion control to the RTP profile. ' The current wording is (from draft-avt-profile, 2000]) If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput that is not less the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. I did not like, and still do not like, this wording. TCP is not like UDP, especially UDP multicast, and I see nothing “fair” about having a multicast stream sharing the same bandwidth as a host of unicast TCP sessions. In case of large scale receiver based RTP/UDP congestion control, it is also very unclear how the receiver is to determine the amount of TCP traffic. I argued that a scheme based on monitoring of packet loss rates only was sufficient, and suggested a simple minded congestion monitoring wording based purely on packet loss rates. There followed a fair amount of discussion about this point, which has resurfaced a number of time. The following points have been made : 1.) UDP flows, without congestion control, can ruin a bandwidth limited pipe - see [Jeffay, 1999] for an example of congestive collapse (38% packet loss) when you try and stuff TCP traffic + a 8 or 9 mbps UDP flow into a 10 mbps channel. 2.) Conversely, most multicast applications are streaming audio or video, and these do not respond well to TCP like changes in bandwidth - especially the slow start / congestion control. It is possible that RMT would help here. To the extent that there is consensus, I would cautiously say that people have focused more on avoiding congestive collapse instead of fairness. I would also cautiously claim a VERY rough consensus that multicast streams should be allowed to take the bandwidth they need as long as there is not signs of serious congestion, but that they should throttle back or terminate entirely if there is, and that this should be determined by monitoring the rate of packet loss. I am cc:ing the AVT list, for obvious reasons. I apologize for those who get this twice. References : [draft-avt-profile, 2000] http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt [Jeffay, 1999] Towards a Better-Than-Best-Effort Forwarding Service for Multimedia Flows, K. Jeffay, IEEE Multimedia, 6, 84-88, 1999. The “long” version is available from http://www.cs.unc.edu/~jeffay/papers/IEEE-MM-99-long.pdf Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From rem-conf Fri Oct 06 06:15:40 2000 From rem-conf-request@es.net Fri Oct 06 06:15:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXK8-0003rt-00; Fri, 6 Oct 2000 06:14:04 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXK1-0003ny-00; Fri, 6 Oct 2000 06:13:57 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39DDC1EB00001C0B for rem-conf@es.net; Fri, 6 Oct 2000 15:10:19 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39DC96F3000128CD for rem-conf@es.net; Fri, 6 Oct 2000 15:09:13 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Fri, 06 Oct 2000 15:09:06 +0200 (Paris, Madrid (heure d'été)) X-Internal-ID: 39CA6F21000089B3 Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Fri, 6 Oct 2000 15:14:06 +0200 Received: from thomcast.thomson-csf.com ([178.3.1.228]) by minos.snmrennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.62) with ESMTP id 487; Fri, 6 Oct 2000 14:58:15 +0200 Message-ID: <39DDCF5D.30C2FA98@thomcast.thomson-csf.com> Date: Fri, 06 Oct 2000 15:10:53 +0200 From: "Pierre Clement" X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: jan.vandermeer@philips.com CC: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: Types of MPEG-4 streams over IP References: <0056890014641266000002L962*@MHS> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-Printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jan, In case the mux code table change in the course of a flexmux stream, it i= s true that an in band signaling can be usefull to tell the deflexmuxer when to = take the change into account. I guess it is also possible to do it by out of band mean, and among other= s thanks to SAP/SDP. The Message Identifier Hash for SAP to announce a chan= ge in a MuxCodeTable and a "t=3D " line in SDP to announce when the change should= be put in place in the deflexmuxer can be linked with the RTP time stamp of the = RTP packets containing the flexmux stream. When thinking of the jitter introd= uced by the underlying network, one implementer would have to be careful about th= e proper time to send the updated MuxCodeTable via SAP/SDP. In this issue, my feeling is that the configuration stage should be disso= ciated =66rom the maintenance stage. SAP/SDP could be used for the configuration= stage of the deflexmuxer whereas in band signalling can be thought of for maintena= nce (i.e change in the flight) of the MuxCodeTable. Regards, Pierre jan.vandermeer@philips.com a =E9crit : > Pierre, > > Possibly a misunderstanding from my side. I thought that the MuxCode ta= ble > may change in the course of a stream. If yes, then it needs to be signa= led > where in the FlexMux stream the new table starts to apply. For this pur= pose > carriage of the table within the FlexMux stream would be useful. Howeve= r, > probably the MuxCode table is intended to apply to any FlexMux packet i= n > MuxCode mode throughout the entire FlexMux stream. Is this right ? > > Regards, > > Jan > > -----Original Message----- > From: pierre.clement@thomcast.thomson-csf.com > [mailto:pierre.clement@thomcast.thomson-csf.com] > Sent: vrijdag, 06 oktober, 2000 12:05 > To: singer@apple.com > Cc: olivier.avaro@francetelecom.fr; Jan vanderMeer; > dominique.curet@francetelecom.fr; 4on2andIP-sys@advent.ee.columbia.edu; > rem-conf@es.net; dominique.curet@rd.francetelecom.fr > Subject: Re: Types of MPEG-4 streams over IP > > Dear all, > > To announce the MuxCodeTable in a multicast scenario, it is possible to= send > it periodically thanks to SAP/SDP. Among others, SAP is used to transmi= t > periodically the SDP file as described in Dave's proposal. > > Dave explicitely mentionned the use of a URL in his proposal; it may be > usefull to also mention the fact that the MuxCodeTable can be also dire= ctly > conveyed in a SDP file in its binary format. > > Pierre > > Dave Singer a =E9crit : > > > > > >Dave said that :"The MuxCodeTable needs to be delivered out-of-band"= =2E > > >**it certainly needs to be delivered. > > > > > >Pierre showed how it is possible to deliver it, accurately in time, = by > > >out of band means > > > > > >**But is 'out of band' compatible with a multicast or broadcast scen= ario. > > >**So, I think agree with Jan that an inband means is necessary. > > > > of course it is. my framework proposal showed how. in a multicast > > or broadcast, there is always some information that is given to the > > terminal to enable it to open the streams. in IETF world, that is an > > SDP file. I showed how to put the IOD and the flexmux info into the > > SDP file. > > -- > > David Singer > > Apple Computer/QuickTime From rem-conf Fri Oct 06 06:29:12 2000 From rem-conf-request@es.net Fri Oct 06 06:29:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXXp-0004yr-00; Fri, 6 Oct 2000 06:28:13 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXXn-0004yf-00; Fri, 6 Oct 2000 06:28:11 -0700 Received: from zvil (i1-28.j1.actcom.co.il [192.115.22.190]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA30344; Fri, 6 Oct 2000 15:27:59 +0200 Received: by localhost with Microsoft MAPI; Fri, 6 Oct 2000 15:27:48 +0200 Message-ID: <01C02FA9.FBDCBD60.zvil@csi.com> From: Zvi Lifshitz To: "'jan.vandermeer@philips.com'" , "singer@apple.com" Cc: "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Date: Fri, 6 Oct 2000 15:27:47 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 [jan.vandermeer@philips.com:] Perhaps it is possible to merge both solutions by extending the Kikuchi-san drafts with the option to carry an SL header (preceded by the above length field), for example signaled by a new attribute "MPEG-4 SL header carried" at SDP level. [Reply:] Or just have a new payload type which is just a different (and more common) way of signaling. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 From rem-conf Fri Oct 06 06:38:33 2000 From rem-conf-request@es.net Fri Oct 06 06:38:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXh3-0005kw-00; Fri, 6 Oct 2000 06:37:45 -0700 Received: from ns.hara-kgs.co.jp [210.226.163.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXh0-0005je-00; Fri, 6 Oct 2000 06:37:43 -0700 Received: from [210.226.163.50] ([210.226.163.51]) by ns.hara-kgs.co.jp (Post.Office MTA v3.5.3J release 223-101-J ID# 1001-66543U100L2S100V35J) with SMTP id jp for ; Fri, 6 Oct 2000 13:29:47 +0900 Received: from nobody@localhost by (8.8.5/8.6.5) with SMTP id GAA00625 for ; Thu, 05 Oct 2000 22:50:04 -0600 (EST) To: rem-conf@es.net Message-ID: <199912112040.MAA94626@addr6.addr.com> Date: Thu, 05 Oct 00 22:50:04 EST From: icorp@prontomail.com Subject: Finally, A Homebased Business that WORKS for you! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a REAL Money Making Opportunity! The "Residual" earnings from this are staggering! Donald Trump was recently a guest on the "Tonight Show". He was asked, "If you had to do it all over again, how would you go about it?" He replied, "I'd find a good network marketing company, and take it from there". The story continues that, there was a scoff in the audience, and he turned to the audience and stated, "That's why I am where I am...and you are where you are." ..and, boy do we have a good opportunity here.. We started out HUGE the first Week, over 10,000 SALES!! We're growing BIGGER daily by approximately 500!!! Between yesterday and today I've counted over 620 new distributors! Imagine if you could have bought in on the ground floor with Microsoft or Walmart, etc., Well folks, I'm here to tell you that opportunity is knocking... CASH in now, on the most Lucrative Homebased Opportunity of this Millenium with a company that will grow to be #1 in the World! We Capitalize on Three of the fastest growing trends in the history of the internet with NO: MEETINGS INVENTORY PAPERWORK GLOBAL BARRIERS Incredible....Absolutely Incredible! Find out how: After being properly set up, You can make thousands of $$ - PER POSITION! You can make HUGE MATCHING bonuses from ALL your personal sales!! Only if you are seriously interested then: Click on the following link for more info on your New success!! http://www.myfreeoffice.com/streamsuccess/index.html Or just send an email to: ezbucks@prontomail.com and ask for more info! Best Success, David in NC. PS: If you become a distributor using my ID number, then I will give you everything you need to start marketing, FREE!..including marketing tips, software, and websites, etc. -With my training to help you all the way! I am the ONLY distributor offering any type of signup bonus. Thanks for your time and have a great day! David in USA. **************** This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to: remove-mail@usa.net with the word "remove" in the subject line. From rem-conf Fri Oct 06 06:42:01 2000 From rem-conf-request@es.net Fri Oct 06 06:42:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXkf-0006BK-00; Fri, 6 Oct 2000 06:41:29 -0700 Received: from lmail.actcom.co.il [192.114.47.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXkd-0006AY-00; Fri, 6 Oct 2000 06:41:28 -0700 Received: from zvil (i1-28.j1.actcom.co.il [192.115.22.190]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA00334; Fri, 6 Oct 2000 15:41:23 +0200 Received: by localhost with Microsoft MAPI; Fri, 6 Oct 2000 15:41:12 +0200 Message-ID: <01C02FAB.DAA91100.zvil@csi.com> From: Zvi Lifshitz To: "'Dave Singer'" , Colin Perkins Cc: "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Date: Fri, 6 Oct 2000 15:41:10 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 [Dave Singer:] I personally have little trouble with progressing the framework, and Kikuchi, and Carsten, and Flexmux-in-RTP, with them all fitting into the same framework. But that was not the US NB position. [Reply:] I know at least one other NB which supports exactly that ;-) z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 From rem-conf Fri Oct 06 06:47:04 2000 From rem-conf-request@es.net Fri Oct 06 06:47:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXpD-0006xj-00; Fri, 6 Oct 2000 06:46:11 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXpB-0006wb-00; Fri, 6 Oct 2000 06:46:10 -0700 Received: from zvil (i1-28.j1.actcom.co.il [192.115.22.190]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA01271; Fri, 6 Oct 2000 15:46:16 +0200 Received: by localhost with Microsoft MAPI; Fri, 6 Oct 2000 15:46:04 +0200 Message-ID: <01C02FAC.89272BE0.zvil@csi.com> From: Zvi Lifshitz To: "'Dave Singer'" , "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: what Mime type for MP4 files? Date: Fri, 6 Oct 2000 15:46:03 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 [Dave Singer:] I strongly prefer video. [Reply:] So do I. Unless there is some MPEG-J stream there that operates the toaster or something. [Original message:] >I prefer video, as it warns the terminal that a >presentation is coming, it's parallel to MPEG, and I'm concerned that >"application" may be treated more circumspectly by security software. >But the Beijing MPEG meeting preferred application. Without knowing why I cannot comment, but historically such formats have gone under video. I expect there to be pushback if application is attempted. [Reply:] The main reason was your were not there to explain. I don't remember this as a big issue and therefore assume we have chances to convince them this time. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 From rem-conf Fri Oct 06 06:50:16 2000 From rem-conf-request@es.net Fri Oct 06 06:50:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hXs2-0007iu-00; Fri, 6 Oct 2000 06:49:06 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hXrz-0007h7-00; Fri, 6 Oct 2000 06:49:03 -0700 Received: from zvil (i1-28.j1.actcom.co.il [192.115.22.190]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA01747; Fri, 6 Oct 2000 15:49:05 +0200 Received: by localhost with Microsoft MAPI; Fri, 6 Oct 2000 15:48:54 +0200 Message-ID: <01C02FAC.EE2ED1A0.zvil@csi.com> From: Zvi Lifshitz To: "'Mikael Bourges-Sevenier'" , Dave Singer , "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: what Mime type for MP4 files? Date: Fri, 6 Oct 2000 15:48:53 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 All these streams still create an audio/visual presentation, which is what meant by 'video' mime type. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: Mikael Bourges-Sevenier [SMTP:mikael@ivast.com] Sent: Friday, October 06, 2000 1:42 AM To: Dave Singer; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: what Mime type for MP4 files? Even if historically MPEG is more concerned with video, MPEG-4 deals with so many different kinds of streams that I would prefer application/x-mp4 or x-mpeg4. In general as the BIFS stream defines a scene I would view it as a special kind of application. Mikael Bourges-Sevenier iVAST Inc. > -----Original Message----- > From: owner-4on2andIP-sys@advent.ee.columbia.edu > [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave > Singer > Sent: Thursday, October 05, 2000 3:56 PM > To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: what Mime type for MP4 files? > > > a reply from the gurus at the IETF about the (e.g. HTTP) mime type > for MP4 files... > > >The top-level questions for MPEG are: > >a) do we belong under video, or application, for general MPEG-4 > >sessions? > > I strongly prefer video. > > >I prefer video, as it warns the terminal that a > >presentation is coming, it's parallel to MPEG, and I'm concerned that > >"application" may be treated more circumspectly by security software. > >But the Beijing MPEG meeting preferred application. > > Without knowing why I cannot comment, but historically such formats have > gone under video. I expect there to be pushback if application is > attempted. > > >b) A taste question. Is the /mpeg4 to match the name of the standard > >(my preference, along with Steve Casner), or /mp4 to match the file > >format name? > > I personally prefer the former, but as you say, it is solely a matter of > taste. > > >c) I'm fairly sure that we should say a lot more about security, as > >we allow embedded URLs, and have a Java layer that can deliver > >"applets". What sort of analysis is needed here? > > Basically, you need to note the issues. If I were you I'd take a look > at existing registrations of similar things and add what you need. > -- > David Singer > Apple Computer/QuickTime > From rem-conf Fri Oct 06 07:44:59 2000 From rem-conf-request@es.net Fri Oct 06 07:44:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hYj4-0002wT-00; Fri, 6 Oct 2000 07:43:54 -0700 Received: from mgw-x1.nokia.com [131.228.20.21] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hYj3-0002wJ-00; Fri, 6 Oct 2000 07:43:53 -0700 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e96EhTK00601; Fri, 6 Oct 2000 17:43:30 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Fri, 6 Oct 2000 09:43:28 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B8E1@daeis05nok> From: zhigang.liu@nokia.com To: csp@isi.edu, lazzaro@CS.Berkeley.EDU Cc: micke@CS.Arizona.EDU, xieqb@cig.mot.com, krister.svanbro@lu.erisoft.se, magnus.westerlund@era.ericsson.se, micke@optima.CS.Arizona.EDU, Qiaobing_Xie-QXIE1@email.mot.com, rem-conf@es.net Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Date: Fri, 6 Oct 2000 09:39:28 -0500 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 > >[1] 1 bit in the AMR payload design signify "radio-friendly" or > > "landline-friendly" packetizations. > > Why waste a bit in the payload? Just use a different RTP payload type > number..... > > I strongly recommend we don't go down this road. > > Colin That's the way to go. This remind me the situation of G723.1 ... Zhigang From rem-conf Fri Oct 06 07:45:05 2000 From rem-conf-request@es.net Fri Oct 06 07:45:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hYiS-0002vn-00; Fri, 6 Oct 2000 07:43:16 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hYiQ-0002vd-00; Fri, 6 Oct 2000 07:43:15 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id KAA01293; Fri, 6 Oct 2000 10:17:13 -0400 Message-Id: <200010061417.KAA01293@purple.east.isi.edu> To: Pierre Clement cc: jan.vandermeer@philips.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from Pierre Clement of "Fri, 06 Oct 2000 15:10:53 +0200." <39DDCF5D.30C2FA98@thomcast.thomson-csf.com> Date: Fri, 06 Oct 2000 10:17:13 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Pierre Clement writes: >Dear Jan, > >In case the mux code table change in the course of a flexmux stream, it is true >that an in band signaling can be usefull to tell the deflexmuxer when to take >the change into account. > >I guess it is also possible to do it by out of band mean, and among others >thanks to SAP/SDP. The Message Identifier Hash for SAP to announce a change in a >MuxCodeTable and a "t= " line in SDP to announce when the change should be put >in place in the deflexmuxer can be linked with the RTP time stamp of the RTP >packets containing the flexmux stream. When thinking of the jitter introduced by >the underlying network, one implementer would have to be careful about the >proper time to send the updated MuxCodeTable via SAP/SDP. > >In this issue, my feeling is that the configuration stage should be dissociated >from the maintenance stage. SAP/SDP could be used for the configuration stage of >the deflexmuxer whereas in band signalling can be thought of for maintenance >(i.e change in the flight) of the MuxCodeTable. Yes - SAP can't be used for the maintainance stage, because it is too slow (one announcement every tens of _minutes_). Colin From rem-conf Fri Oct 06 07:45:07 2000 From rem-conf-request@es.net Fri Oct 06 07:45:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hYie-0002w3-00; Fri, 6 Oct 2000 07:43:28 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hYic-0002vr-00; Fri, 6 Oct 2000 07:43:27 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id KAA01338; Fri, 6 Oct 2000 10:21:24 -0400 Message-Id: <200010061421.KAA01338@purple.east.isi.edu> To: Yoshihiro Kikuchi cc: "philippe.gentric" , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Yoshihiro Kikuchi of "Fri, 06 Oct 2000 20:08:19 +0900." <085201c02f85$bc4d1ce0$cc51c485@eel.rdc.toshiba.co.jp> Date: Fri, 06 Oct 2000 10:21:24 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Yoshihiro Kikuchi writes: ... >For detailed definition, I don't think there is no problem to change >profile-level-id to required parameter. Maybe we can remove the default >value by this. However, since config is defined that this parameter shall >not be used for the capability exchange, and actually config is not to >indicate the capability but coder configuration, there is a problem to >change it as required. How about changing the first sentence of config as >follows? > >"config: This parameter SHALL be used to indicate the configuration of the >corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the >codec capability in the capability exchange procedure. ......" > >Since the parameter config is added by requests to keep interlocking with >32x-based systems, I would like to hear if this change matches the request. >I would also like to hear from IETF experts if it is usual in IETF world to >add this kind of parameter as required. RTP payload formats typically don't specify how the negotiation is done in so much detail, rather they leave it up to the definition of the setup protocol (e.g. H.323 may not use this, but what if a SIP or RTSP based system want's to?) Colin From rem-conf Fri Oct 06 07:56:56 2000 From rem-conf-request@es.net Fri Oct 06 07:56:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hYtx-00059K-00; Fri, 6 Oct 2000 07:55:09 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hYtw-000596-00; Fri, 6 Oct 2000 07:55:08 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA04545; Fri, 6 Oct 2000 16:55:05 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma004543; Fri, 6 Oct 00 16:55:05 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA26288; Fri, 6 Oct 2000 16:55:04 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA01338; Fri, 6 Oct 2000 16:55:04 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014650733; Fri, 6 Oct 2000 16:56:08 +0200 To: , Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014650733000002L932*@MHS> Date: Fri, 6 Oct 2000 16:56:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/06/00 17:53:27" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, Zvi, all, Colin wrote : >>Perhaps an a=3Dx-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main rea= son to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system serv= ices (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a= length unknown by now. In such cases the length byte provides a future proof solution for addi= ng additional information using the same payload type. Assuming of course = that the receiver is capable to parse the length byte while skipping the par= t of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one i= s not backward compatible. Existing receivers will not be capable to receive = the new payload format. Kind regards, Jan = From rem-conf Fri Oct 06 08:07:14 2000 From rem-conf-request@es.net Fri Oct 06 08:07:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hZ4h-0006V7-00; Fri, 6 Oct 2000 08:06:15 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hZ4e-0006Uv-00; Fri, 6 Oct 2000 08:06:12 -0700 Received: from zvil (i1-28.j1.actcom.co.il [192.115.22.190]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id RAA17377; Fri, 6 Oct 2000 17:06:16 +0200 Received: by localhost with Microsoft MAPI; Fri, 6 Oct 2000 17:06:04 +0200 Message-ID: <01C02FB7.B63DD4C0.zvil@csi.com> From: Zvi Lifshitz To: "'jan.vandermeer@philips.com'" , "csp@isi.edu" Cc: "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Date: Fri, 6 Oct 2000 17:06:03 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 Jan, I'm in favor of a length byte. In the Generic payload format. All I said is that signaling whether the use of extra SL info (the Generic format) or not (Kikuchi-san proposal) can be done through payload type. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 4:56 PM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=x-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main reason to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system services (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a length unknown by now. In such cases the length byte provides a future proof solution for adding additional information using the same payload type. Assuming of course that the receiver is capable to parse the length byte while skipping the part of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one is not backward compatible. Existing receivers will not be capable to receive the new payload format. Kind regards, Jan From rem-conf Fri Oct 06 08:28:09 2000 From rem-conf-request@es.net Fri Oct 06 08:28:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hZOc-00001r-00; Fri, 6 Oct 2000 08:26:50 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hZOb-00001Z-00; Fri, 6 Oct 2000 08:26:49 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA15283; Fri, 6 Oct 2000 17:26:47 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma015279; Fri, 6 Oct 00 17:26:47 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA10349; Fri, 6 Oct 2000 17:26:46 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA11068; Fri, 6 Oct 2000 17:26:46 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014651648; Fri, 6 Oct 2000 17:27:50 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014651648000002L982*@MHS> Date: Fri, 6 Oct 2000 17:27:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/06/00 18:25:07" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Zvi, Thanks. So we agree for at least 50 %. Now the remainder. Signaling the= presence of the length byte by an attribute on SDP level allows the byt= e to be present or not. As long as you don't need the byte, don't burn the overhead. Regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: vrijdag, 06 oktober, 2000 17:09 To: csp@isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Jan, I'm in favor of a length byte. In the Generic payload format. All = I said is that signaling whether the use of extra SL info (the Generic format) or not (Kikuchi-san proposal) can be done through payload type.= z soon the whole world will STREAM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 4:56 PM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=3Dx-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main rea= son to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system serv= ices (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a= length unknown by now. In such cases the length byte provides a future proof solution for addi= ng additional information using the same payload type. Assuming of course = that the receiver is capable to parse the length byte while skipping the par= t of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one i= s not backward compatible. Existing receivers will not be capable to receive = the new payload format. Kind regards, Jan = From rem-conf Fri Oct 06 09:33:56 2000 From rem-conf-request@es.net Fri Oct 06 09:33:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13haOb-0002fq-00; Fri, 6 Oct 2000 09:30:53 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13haOa-0002fg-00; Fri, 6 Oct 2000 09:30:52 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA29660; Fri, 6 Oct 2000 18:30:49 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma029658; Fri, 6 Oct 00 18:30:49 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA29676; Fri, 6 Oct 2000 18:30:49 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA24233; Fri, 6 Oct 2000 18:30:48 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900012584649; Fri, 6 Oct 2000 18:37:37 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Message-ID: <0056900012584649000002L092*@MHS> Date: Fri, 6 Oct 2000 18:37:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/06/00 18:36:50" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list kiku@eel.rdc.toshiba.co.jp wrote: > Dear Philippe and all, > > > I would like to know why the presence of configuration information = in the > SDP is > > OPTIONAL. > > > > I would think much preferable if the profile-level-id and config fi= elds > would be > > REQUIRED. > > > I'm wondering if it is better to change profile-level-id and config a= s > mandate, although reasons are much different from Philippe's. > > > The reasons being that: > > > > - it is only a few bytes anyway > > > No. It is at least tens of bytes and may go up to a few hundred. It i= s not > huge (sufficiently small compared to a VOP size) but not so very smal= l. > > > - a decoder implementation would always > > have the possibility to be initialized using the information in the= SDP, > > which is easier for many implementation because parsing the video > > syntax requires a video decoder and when you instanciate > > a video decoder it is VERY handy to already have the configuration = ! > > > I don't think out-of-band transport of configuration information will= always > save the codec load. It much depends on the implementation. But decod= ers > optimized for out-of-band may be relaxed. > > > - it would help a receiver discover that it cannot decode a given s= tream > > (without having to request and start receiving the actual stream an= d parse > it) > > and that may be the key reason: in all modes of delivery this > > would solve a "security" issue: > > > > A malignant (or stupid) user of a non-capable decoder could generat= e > > a lot of traffic by requesting repeatedly streams that cannot be de= coded, > > which the decoder could discover "at once" by parsing the SDP, > > if the SDP would always contain the config info... > > > > - it would save (a little) bandwidth since frequent repetition of V= OL in > the > > stream is > > required only for clients who do not use SDP info, you could then > > have streams that actually do not repeat the VOL, or only rarely. > > > I'm not sure how much it is, but it may be save a little. > > Maybe, another good reason for changing config to mandate is an error= > resiliency. I think in most cases repetition of VOL header inside vid= eo > stream work properly, but not 100% guaranty. For error-prone environm= ent > such as mobile, it should at least be recommended to use config in SD= P which > is delivered through reliable channel (by TCP/IP?). > yes ! > > For detailed definition, I don't think there is no problem to change > profile-level-id to required parameter. Maybe we can remove the defau= lt > value by this. However, since config is defined that this parameter s= hall > not be used for the capability exchange, and actually config is not t= o > indicate the capability but coder configuration, there is a problem t= o > change it as required. How about changing the first sentence of confi= g as > follows? > > "config: This parameter SHALL be used to indicate the configuration o= f the > corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indica= te the > codec capability in the capability exchange procedure. ......" > > Since the parameter config is added by requests to keep interlocking = with > 32x-based systems, I would like to hear if this change matches the re= quest. > Well what I would like is to be sure when I get a SDP file to be able to correctly initialize my decoders ***************************** Also, I reiter my question about B frames. Regards, -- Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com = From rem-conf Fri Oct 06 09:43:20 2000 From rem-conf-request@es.net Fri Oct 06 09:43:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13haZq-0003hb-00; Fri, 6 Oct 2000 09:42:30 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13haZp-0003df-00; Fri, 6 Oct 2000 09:42:29 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <41BTBCG9>; Fri, 6 Oct 2000 10:41:32 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA81E9FB@el-postino.s-vision.com> From: Kris Huber To: jan.vandermeer@philips.com, zvil@csi.com, csp@isi.edu Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Date: Fri, 6 Oct 2000 10:41:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Jan, For devices that (for whatever reason) must use the Kikuchi-san payload type, and never upgrade to a new payload type, then perhaps a possibility you haven't considered is placing future configuration information in the user_data field of the visual streams. This field is present in the visual object sequence (VOS) header, the visual object (VO) header, the visual object layer (VOL) header, and in the group of VOP (GOV) header. It is not in the VOP header, so to accommodate a decoding timestamp, for example, you'd need to send a list of DTS's in the GOV header user data, for the VOPs that follow. OK it's a messy and ugly solution (especially if you put audio-related information in there)! But it's already carried in MPEG-4 and (unwittingly?) in the Kikuchi-san draft payload format. Perhaps MPEG-4 user_data was accepted with "configuration future-proofing" in mind (I became involved with MPEG after it was already there, so I don't know the history). As for using user_data, Annex D of the systems spec. gives a registration procedure for "the private data format identifiers" and "the IPMP system type values". I'm not sure if user_data is included in the meaning of "private data format", however, or if you just use it and build decoders that try to figure out what portion of it is yours. As for contacting the registration authority, D.3 says "To Be Determined". Whatever the organization, it is to report its activities to JTC 1, ITTF (probably "Internet Theory Task Force") and SC 29 secretariat. Note that since visual information consumes much more bandwidth than audio, there is not so much wasted bandwidth associated with duplication of audio broadcast services due to a need to support an old payload format as there is when duplication of video broadcast service is required to prevent device obsolescence. Of course the whole analysis of bandwidth wastage depends on numbers of non-upgradeable devices, but I understand there are applications that would include a large number of MPEG-2 devices in the count, so device or bandwidth wastage without information backward-compatibility could be significant. I'd appreciate clarification of user_data usage conventions by anyone, please (no, no, don't just say it shouldn't be used! I know it's messy and goes against certain design principles!) But I think it makes some kludges possible that could prove very valuable in some cases. Not everything of value is pretty. And note that the burden of parsing and using the user_data fields is primarily on those who wish to use it. The burden on everyone else is to carry and skip it. If it prevents needless replication of high-bandwidth services for a significant period of time, it is a small price to pay. Of course if it gets too large, it is a more significant price to pay in bandwidth, but that is certainly not a problem at the present time. Regards, Kris -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 8:56 AM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=x-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main reason to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system services (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a length unknown by now. In such cases the length byte provides a future proof solution for adding additional information using the same payload type. Assuming of course that the receiver is capable to parse the length byte while skipping the part of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one is not backward compatible. Existing receivers will not be capable to receive the new payload format. Kind regards, Jan From rem-conf Fri Oct 06 10:19:49 2000 From rem-conf-request@es.net Fri Oct 06 10:19:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hb8x-0005OF-00; Fri, 6 Oct 2000 10:18:47 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hb8v-0005Nk-00; Fri, 6 Oct 2000 10:18:45 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA24869 for ; Fri, 6 Oct 2000 10:18:44 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 6 Oct 2000 10:18:44 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA02368; Fri, 6 Oct 2000 10:18:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <0056890014641266000002L962*@MHS> References: <0056890014641266000002L962*@MHS> Date: Fri, 6 Oct 2000 10:18:06 -0700 To: jan.vandermeer@philips.com From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: pierre.clement@thomcast.thomson-csf.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 1:08 PM +0200 10/6/00, jan.vandermeer@philips.com wrote: >Pierre, > >Possibly a misunderstanding from my side. I thought that the MuxCode table >may change in the course of a stream. If yes, then it needs to be signaled >where in the FlexMux stream the new table starts to apply. For this purpose >carriage of the table within the FlexMux stream would be useful. However, >probably the MuxCode table is intended to apply to any FlexMux packet in >MuxCode mode throughout the entire FlexMux stream. Is this right ? > >Regards, > >Jan My understanding is that the multiplex nature of the stream does not change, and that therefore reliable up-front signalling is best. If this ins't true, the flexmux packet format may need some way to update the muxcodetable, but I hope that isn't true, because of reliability concerns. > >-----Original Message----- >From: pierre.clement@thomcast.thomson-csf.com >[mailto:pierre.clement@thomcast.thomson-csf.com] >Sent: vrijdag, 06 oktober, 2000 12:05 >To: singer@apple.com >Cc: olivier.avaro@francetelecom.fr; Jan vanderMeer; >dominique.curet@francetelecom.fr; 4on2andIP-sys@advent.ee.columbia.edu; >rem-conf@es.net; dominique.curet@rd.francetelecom.fr >Subject: Re: Types of MPEG-4 streams over IP > > > >Dear all, > >To announce the MuxCodeTable in a multicast scenario, it is possible to sen= d >it periodically thanks to SAP/SDP. Among others, SAP is used to transmit >periodically the SDP file as described in Dave's proposal. > >Dave explicitely mentionned the use of a URL in his proposal; it may be >usefull to also mention the fact that the MuxCodeTable can be also directly >conveyed in a SDP file in its binary format. > >Pierre > > > >Dave Singer a =E9crit : > >> >> >Dave said that :"The MuxCodeTable needs to be delivered out-of-band". >> >**it certainly needs to be delivered. >> > >> >Pierre showed how it is possible to deliver it, accurately in time, by >> >out of band means >> > >> >**But is 'out of band' compatible with a multicast or broadcast scenari= o. >> >**So, I think agree with Jan that an inband means is necessary. >> >> of course it is. my framework proposal showed how. in a multicast >> or broadcast, there is always some information that is given to the >> terminal to enable it to open the streams. in IETF world, that is an >> SDP file. I showed how to put the IOD and the flexmux info into the > > SDP file. > > -- > > David Singer > > Apple Computer/QuickTime -- David Singer Apple Computer/QuickTime From rem-conf Fri Oct 06 10:19:50 2000 From rem-conf-request@es.net Fri Oct 06 10:19:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hb8w-0005O4-00; Fri, 6 Oct 2000 10:18:46 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hb8v-0005Ni-00; Fri, 6 Oct 2000 10:18:45 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA24848 for ; Fri, 6 Oct 2000 10:18:43 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 6 Oct 2000 10:18:42 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id KAA02357; Fri, 6 Oct 2000 10:18:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <39DDA066.C21995B7@thomcast.thomson-csf.com> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> <39DDA066.C21995B7@thomcast.thomson-csf.com> Date: Fri, 6 Oct 2000 10:16:40 -0700 To: Pierre Clement From: Dave Singer Subject: Re: Types of MPEG-4 streams over IP Cc: CURET Dominique FTRD/DMI/REN , rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, "'Olivier Avaro'" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:50 AM +0200 10/6/00, Pierre Clement wrote: >Dear all, > >To announce the MuxCodeTable in a multicast scenario, it is possible to sen= d >it periodically thanks to SAP/SDP. Among others, SAP is used to transmit >periodically the SDP file as described in Dave's proposal. > >Dave explicitely mentionned the use of a URL in his proposal; it may be >usefull to also mention the fact that the MuxCodeTable can be also directly >conveyed in a SDP file in its binary format. > >Pierre Yes, exactly. I believe that the muxcodetable will often be small enough that a data: URL will be usable. > > >Dave Singer a =E9crit : > >> >> >Dave said that :"The MuxCodeTable needs to be delivered out-of-band". >> >**it certainly needs to be delivered. >> > >> >Pierre showed how it is possible to deliver it, accurately in time, by >> >out of band means >> > >> >**But is 'out of band' compatible with a multicast or broadcast scenari= o. >> >**So, I think agree with Jan that an inband means is necessary. >> >> of course it is. my framework proposal showed how. in a multicast >> or broadcast, there is always some information that is given to the >> terminal to enable it to open the streams. in IETF world, that is an >> SDP file. I showed how to put the IOD and the flexmux info into the > > SDP file. > > -- > > David Singer > > Apple Computer/QuickTime -- David Singer Apple Computer/QuickTime From rem-conf Fri Oct 06 10:59:43 2000 From rem-conf-request@es.net Fri Oct 06 10:59:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hbjy-0000My-00; Fri, 6 Oct 2000 10:57:02 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hbjx-0000LU-00; Fri, 6 Oct 2000 10:57:01 -0700 Received: from vaiostw.cs.tu-berlin.de (130-149-145-207.dialup.cs.tu-berlin.de [130.149.145.207]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id TAA02857; Fri, 6 Oct 2000 19:52:03 +0200 (MET DST) Message-Id: <5.0.0.25.2.20001005232618.02ebb6d0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Oct 2000 23:26:48 +0200 To: Colin Perkins From: Stephan Wenger Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Cc: Qunshan_Gu@pictel.com, "Yoshihiro Kikuchi" , "Stephan Wenger" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> In-Reply-To: <200010051937.PAA05032@purple.east.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >What about... > "When the short video header mode is used, the RTP payload format > for H.263 SHOULD be used (the format defined in RFC 2429 is > RECOMMENDED, but the RFC 2190 format MAY be used for compatibility > with older implementations)." Fine with me. Stephan From rem-conf Fri Oct 06 10:59:45 2000 From rem-conf-request@es.net Fri Oct 06 10:59:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hbjk-0000MZ-00; Fri, 6 Oct 2000 10:56:48 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hbjj-0000LU-00; Fri, 6 Oct 2000 10:56:47 -0700 Received: from vaiostw.cs.tu-berlin.de (130-149-145-207.dialup.cs.tu-berlin.de [130.149.145.207]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id TAA02824; Fri, 6 Oct 2000 19:51:48 +0200 (MET DST) Message-Id: <5.0.0.25.2.20001005073353.02f44d60@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Oct 2000 07:35:26 +0200 To: "Yoshihiro Kikuchi" From: Stephan Wenger Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Cc: "Stephan Wenger" , "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" In-Reply-To: <046501c02e85$e2994f00$cc51c485@eel.rdc.toshiba.co.jp> References: <200010040444.AAA09294@purple.east.isi.edu> <5.0.0.25.2.20001004173727.02f62990@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You really don't need to, because RFC2429 is quite verbose in that regard. At 01:36 PM 10/5/2000 +0900, Yoshihiro Kikuchi wrote: >[...] and not to add the detailed >timestamp definition of the short video header mode. You really don't need to, because RFC2429 is quite verbose in that regard (as is RFC2190 if we put that in as well) . Stephan From rem-conf Fri Oct 06 10:59:45 2000 From rem-conf-request@es.net Fri Oct 06 10:59:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hbjR-0000Lf-00; Fri, 6 Oct 2000 10:56:29 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hbjQ-0000LU-00; Fri, 6 Oct 2000 10:56:28 -0700 Received: from vaiostw.cs.tu-berlin.de (130-149-145-207.dialup.cs.tu-berlin.de [130.149.145.207]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id TAA02840; Fri, 6 Oct 2000 19:51:55 +0200 (MET DST) Message-Id: <5.0.0.25.2.20001005193923.02f48eb0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Oct 2000 19:53:07 +0200 To: SIGNES Julien / ENVIVIO From: Stephan Wenger Subject: RE: Types of MPEG-4 streams over IP Cc: "'Y. Matsui'" , 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net In-Reply-To: <337055FBC675D311A85D00508B5A9C4F355324@u-mail.rd.francetel ecom.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_280664==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_280664==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Julien, Group, >I agree in general they should be fully reliable channels carrying >those,as well as BIFS comands. However, note that a lot of >streaming those days is actually done by RTP over TCP. This is interesting. I'm not aware of any commercial system doing such a thing. I know that telephony people discuss the use of RTP over TCP on managed IP networks for conversational applications, but that is probably not what you are referring to? I'm also aware of UDP/RTP streaming techniques that use a TCP channel for repair, (and feedback to report errors). But again, that is not what I would understand as RTP over TCP. So can you please come up with an example and/or references? Thanks in advance. Also, using TCP as the transport does not automatically render a reliable RTP channel, at least not under real-time constraints. There is still a good chance that packets that finally arrive at the receiver will be thrown out because they do not fall into the jitter tolerance window of the playout buffer. (This is true for all re-transmission based protocols). You simply can't guaranty that all packets arrive in time unless you have finally received all packets. Stephan --=====================_280664==_.ALT Content-Type: text/html; charset="us-ascii" Julien, Group,


I agree in general they should be fully reliable channels carrying
those,as well as BIFS comands. However, note that a lot of
streaming those days is actually done by RTP over TCP.

This is interesting.  I'm not aware of any commercial system doing
such a thing.  I know that telephony people discuss the use of
RTP over TCP on managed IP networks for conversational
applications, but that is probably not what you are referring to?
I'm also aware of UDP/RTP streaming techniques that use a TCP
channel for repair, (and feedback to report errors).  But again, that
is not what I would understand as RTP over TCP.  So can you
please come up with an example and/or references?  Thanks in
advance.

Also, using TCP as the transport does not automatically render
a reliable RTP channel, at least not under real-time constraints. 
There is still a good chance that packets that finally arrive at the
receiver will be thrown out because they do not fall into the jitter
tolerance window of the playout buffer.  (This is true for all
re-transmission based protocols).  You simply can't guaranty that
all packets arrive in time unless you have finally received all packets.

Stephan


--=====================_280664==_.ALT-- From rem-conf Fri Oct 06 13:25:54 2000 From rem-conf-request@es.net Fri Oct 06 13:25:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13he0X-0007dT-00; Fri, 6 Oct 2000 13:22:17 -0700 Received: from motgate2.mot.com [136.182.1.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13he0R-0007ct-00; Fri, 6 Oct 2000 13:22:16 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA14774; Fri, 6 Oct 2000 13:21:09 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA03360; Fri, 6 Oct 2000 13:21:09 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id PAA02906; Fri, 6 Oct 2000 15:21:05 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id PAA26594; Fri, 6 Oct 2000 15:21:04 -0500 (CDT) Message-Id: <200010062021.PAA26594@agevole.cig.mot.com> Date: Fri, 06 Oct 2000 15:21:39 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Qiaobing Xie , Mikael Degermark , Krister Svanbro , Magnus Westerlund , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> <200010052313.QAA05736@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Mikael, my comments below... Cheers, -Qiaobing Mikael Degermark wrote: ...snip.... > >In my view, AMR is a general purpose codec and a good addition to the > >long list of codecs (eg, G711, G726, ...) currently used in many VoIP > >applications. To have a radio link in the path is just one of the use > >cases. Another thing is, even if you have a mobile unit (as your > >analysis goes below) at one end of the IP connection, you probably will > >still have a lot more ordinary wireline links to go through end-to-end. > >It is definitely desirable to make the payload format as radio-friendly > >as possible, but this should be done without compromising the "normal" > >link performance too much. > > The normal link performance will be improved by having smaller payloads, right? > So what you must be arguing for here cannot really have much to do with > link performance. It is not just the size of the payload, it has something to do with the selection of the error handling/recovering strategy. For example, based on the link error characteristcs and transmission style, you may choose to make the payload itself small and less error tolerant but rely on outside mechanisms such as some FEC mechanisms to control the error, or you may choose to have a bigger paylaod with more sophisticated built-in error recover machanism. I don't think there is a universal strategy which works equally well to all link types :-) ...snip... > >advantage gained by octet alignment in upper layer protocols is > >important and the AMR payload design is no exception if we are designing > >it for general purpose VoIP applications. > > I guess the real issue is not what layer the processing is done at, but rather > if it is done by a general-purpose processor or by a more specialized processor. > Would the call-center scenario you described above use general-purpose processors > to do the transcoding or would more specialized hardware be deployed? This has something to do with the way layered protocols are implemented and optimized. The lower you are in the protocol stack, the more you will be willing to pay for the extra effort doing optimization, because the lower layers tend to be more heavily shared in most systems. The upper layers are usually more application-specific and their optimization becomes less cost-effective in most cases. > > Cheers, > > Micke From rem-conf Fri Oct 06 14:01:00 2000 From rem-conf-request@es.net Fri Oct 06 14:01:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13heYy-0001oV-00; Fri, 6 Oct 2000 13:57:52 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13heYx-0001oL-00; Fri, 6 Oct 2000 13:57:51 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id NAA19783; Fri, 6 Oct 2000 13:36:18 -0700 Message-Id: <3.0.3.32.20001005093000.00a9bd70@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 05 Oct 2000 09:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/11 The Making of GUI Bloopers -- Jeff Johnson, UI Wizards, Inc. 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 The Making of GUI Bloopers Wednesday October 11, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Jeff Johnson UI Wizards, Inc. Jeff Johnson, user-interface consultant and author of the new book "GUI Bloopers: DON'Ts and DOs for Software Developers and Web Designers" (Morgan-Kaufmann), will describe why he began collecting GUI design bloopers several years ago, why he decided to publish them in a book, how the bloopers are organized and presented, and how the book was usability tested. His talk will be illustrated with many examples of bloopers. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Fri Oct 06 14:55:32 2000 From rem-conf-request@es.net Fri Oct 06 14:55:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hfQT-0004MT-00; Fri, 6 Oct 2000 14:53:09 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hfQR-0004MJ-00; Fri, 6 Oct 2000 14:53:08 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id OAA06179; Fri, 6 Oct 2000 14:53:06 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id OAA10257; Fri, 6 Oct 2000 14:53:03 -0700 (MST) Message-Id: <200010062153.OAA10257@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 06 Oct 2000 23:54:58 +0200 To: Qiaobing Xie From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Mikael Degermark , Qiaobing Xie , Mikael Degermark , Krister Svanbro , Magnus Westerlund , rem-conf@es.net In-Reply-To: <200010062021.PAA26594@agevole.cig.mot.com> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> <200010052313.QAA05736@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Qiaobing, I didn't realize that you were mostly talking about the error resilience properties. I thought you were mostly arguing for a more CPU friendly packetization format. Seems that the latter issue has been resolved in favor of non-byte aligned if I correctly understand the performance measurements put forward by Ericsson people concerning the relative costs of encoding/decoding and packetization. Seems like a no-brainer to me. Coding/decoding is so much more expensive than packetization that optimizing the latter to save on processing is pointless. This also makes it meaningless to have a bit distinguishing the two formats as have been proposed. But your argument against the amr-00 proposal not really about packetization efficiency, if I understand your latest letter correctly, but instead about error resiliency. Isn't that correct? If correct, we should stop arguing about packetization efficiency and instead talk about error resiliency. (see also a comment below) Micke At 03:21 PM 10/6/00 -0500, Qiaobing Xie wrote: >Hi, Mikael, > >my comments below... > >Cheers, >-Qiaobing > >Mikael Degermark wrote: >...snip.... >> >In my view, AMR is a general purpose codec and a good addition to the >> >long list of codecs (eg, G711, G726, ...) currently used in many VoIP >> >applications. To have a radio link in the path is just one of the use >> >cases. Another thing is, even if you have a mobile unit (as your >> >analysis goes below) at one end of the IP connection, you probably will >> >still have a lot more ordinary wireline links to go through end-to-end. >> >It is definitely desirable to make the payload format as radio-friendly >> >as possible, but this should be done without compromising the "normal" >> >link performance too much. >> >> The normal link performance will be improved by having smaller payloads, right? >> So what you must be arguing for here cannot really have much to do with >> link performance. > >It is not just the size of the payload, it has something to do with the >selection of the error handling/recovering strategy. For example, based >on the link error characteristcs and transmission style, you may choose >to make the payload itself small and less error tolerant but rely on >outside mechanisms such as some FEC mechanisms to control the error, or >you may choose to have a bigger paylaod with more sophisticated built-in >error recover machanism. I don't think there is a universal strategy >which works equally well to all link types :-) > >...snip... >> >advantage gained by octet alignment in upper layer protocols is >> >important and the AMR payload design is no exception if we are designing >> >it for general purpose VoIP applications. >> >> I guess the real issue is not what layer the processing is done at, but rather >> if it is done by a general-purpose processor or by a more specialized processor. >> Would the call-center scenario you described above use general-purpose processors >> to do the transcoding or would more specialized hardware be deployed? > >This has something to do with the way layered protocols are implemented >and optimized. The lower you are in the protocol stack, the more you >will be willing to pay for the extra effort doing optimization, because >the lower layers tend to be more heavily shared in most systems. The >upper layers are usually more application-specific and their >optimization becomes less cost-effective in most cases. It is important to make higher layers efficient when they consume a large fraction of the total processing time. In the amr case, it is important to optimize the amr codec. It is less important to optimize the packetization process, since it consumes so little of the processing time. So although the above paragraph generally is true, amr over RTP is a counterexample to the principle stated there. Cheers, Micke From rem-conf Fri Oct 06 23:28:40 2000 From rem-conf-request@es.net Fri Oct 06 23:28:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hnLY-0001NC-00; Fri, 6 Oct 2000 23:20:36 -0700 Received: from mail0.yrp.nttdocomo.co.jp [202.245.184.18] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hnLV-0001Mv-00; Fri, 6 Oct 2000 23:20:34 -0700 Received: from spg.yrp.nttdocomo.co.jp (spg.yrp.nttdocomo.co.jp [172.21.48.130]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id PAA27136; Sat, 7 Oct 2000 15:20:24 +0900 (JST) Message-Id: <4.2.0.58.J.20001007134735.00b23af0@spg.yrp.nttdocomo.co.jp> X-Sender: kawahara@spg.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 07 Oct 2000 14:27:44 +0900 To: Colin Perkins , Yoshihiro Kikuchi From: Toshiro Kawahara Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Cc: "philippe.gentric" , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> In-Reply-To: <200010061421.KAA01338@purple.east.isi.edu> References: <085201c02f85$bc4d1ce0$cc51c485@eel.rdc.toshiba.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, At 10:21 00/10/06 -0400, Colin Perkins wrote: >--> Yoshihiro Kikuchi writes: >... >>For detailed definition, I don't think there is no problem to change >>profile-level-id to required parameter. Maybe we can remove the default >>value by this. However, since config is defined that this parameter shall >>not be used for the capability exchange, and actually config is not to >>indicate the capability but coder configuration, there is a problem to >>change it as required. How about changing the first sentence of config as >>follows? >> >>"config: This parameter SHALL be used to indicate the configuration of the >>corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the >>codec capability in the capability exchange procedure. ......" >> >>Since the parameter config is added by requests to keep interlocking with >>32x-based systems, I would like to hear if this change matches the request. >>I would also like to hear from IETF experts if it is usual in IETF world to >>add this kind of parameter as required. I'm one of the proponenst of this parameter, and this change matches our intention. 3G-324M, which is a 3GPP version of H.324/M terminal specification, mandates the equivalent parameter in OpenLogicalChannel signaling, and to make the interworking with this terminal, this change is really beneficial. I strongly support this idea. >RTP payload formats typically don't specify how the negotiation is done >in so much detail, rather they leave it up to the definition of the setup >protocol (e.g. H.323 may not use this, but what if a SIP or RTSP based >system want's to?) I understand your concern. The mandatory/optional definition should be in a proper place to avoid inconsistency between specifications or not to limit the function of other protocol unnecessarily. However, I believe the proposed revised definition is not such kind of definition. It don't define the way of negotiation, but provides a clarification of the parameter (for what purpose it SHALL or SHALL NOT be used). "SHALL/SHALL NOT" type of definition might look too strong for such generic definition, but I believe this is a straightforward translation of the situation. Regards, Toshiro --- Toshiro Kawahara NTT DoCoMo, Inc. Multimedia Laboratories, Multimedia Signal Processing Laboratory TEL: +81 468 40 3518 FAX: +81 468 40 3788 $B2O86(B $BIRO/(B (in Japanese) From rem-conf Sat Oct 07 04:26:05 2000 From rem-conf-request@es.net Sat Oct 07 04:26:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hs4A-0001E0-00; Sat, 7 Oct 2000 04:22:58 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hs49-0001Dq-00; Sat, 7 Oct 2000 04:22:57 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id UAA00094; Sat, 7 Oct 2000 20:22:52 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id UAA25687; Sat, 7 Oct 2000 20:22:52 +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 UAA01316; Sat, 7 Oct 2000 20:22:51 +0900 (JST) Received: from ave (kwa0115.mobile.toshiba.co.jp [133.120.199.31]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id UAA63613; Sat, 7 Oct 2000 20:22:49 +0900 (JST) Message-ID: <01b801c03050$f97fe7c0$1fc77885@ave> From: "Yoshihiro Kikuchi" To: "Colin Perkins" , "Toshiro Kawahara" Cc: "philippe.gentric" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <085201c02f85$bc4d1ce0$cc51c485@eel.rdc.toshiba.co.jp> <4.2.0.58.J.20001007134735.00b23af0@spg.yrp.nttdocomo.co.jp> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Sat, 7 Oct 2000 20:23:08 +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 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin, Kawahara-san, Philippe, and all, > >>Since the parameter config is added by requests to keep interlocking with > >>32x-based systems, I would like to hear if this change matches the request. > >>I would also like to hear from IETF experts if it is usual in IETF world to > >>add this kind of parameter as required. > > I'm one of the proponenst of this parameter, and this > change matches our intention. 3G-324M, which is a 3GPP > version of H.324/M terminal specification, mandates the > equivalent parameter in OpenLogicalChannel signaling, and > to make the interworking with this terminal, this change > is really beneficial. I strongly support this idea. > I'm happy to hear that it meets your requirement. And I hope it also matches the desire of Philippe bellow because the definition explicitly says that config SHALL be used to indicate the codec configuration. > Well what I would like is to be sure when I get a SDP > file to be able to correctly initialize my decoders > >RTP payload formats typically don't specify how the negotiation is done > >in so much detail, rather they leave it up to the definition of the setup > >protocol (e.g. H.323 may not use this, but what if a SIP or RTSP based > >system want's to?) > > I understand your concern. The mandatory/optional definition > should be in a proper place to avoid inconsistency between > specifications or not to limit the function of other protocol > unnecessarily. However, I believe the proposed revised > definition is not such kind of definition. It don't define > the way of negotiation, but provides a clarification of > the parameter (for what purpose it SHALL or SHALL NOT be > used). "SHALL/SHALL NOT" type of definition might look too > strong for such generic definition, but I believe this > is a straightforward translation of the situation. > I completely agree with this. Maybe it is not appropriate to have a description in the payload format document about one specific framework, such as how to use OpenLogicalChannel of H.245. However, I think indicating capable codec and payload format at an negotiation stage is more general not only for H.323. For example, OPTIONS or INVITE is used to exchange the capability in SIP. I tried to describe the definition as general as possible, but I appreciate suggestions for better wording. Anyway, I think it is better that the definition will be not too much concise so that we don't leave ambiguity. Best regards, Yoshihiro ---- 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 1267 From rem-conf Sat Oct 07 04:26:05 2000 From rem-conf-request@es.net Sat Oct 07 04:26:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hs3J-0001DK-00; Sat, 7 Oct 2000 04:22:05 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hs3F-0001D8-00; Sat, 7 Oct 2000 04:22:02 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id UAA00039; Sat, 7 Oct 2000 20:21:55 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id UAA25620; Sat, 7 Oct 2000 20:21:54 +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 UAA17599; Sat, 7 Oct 2000 20:21:54 +0900 (JST) Received: from ave (kwa0115.mobile.toshiba.co.jp [133.120.199.31]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id UAA63594; Sat, 7 Oct 2000 20:21:51 +0900 (JST) Message-ID: <01b001c03050$d71701a0$1fc77885@ave> From: "Yoshihiro Kikuchi" To: "Colin Perkins" Cc: "philippe.gentric" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <200010061421.KAA01338@purple.east.isi.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Sat, 7 Oct 2000 20:22:05 +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 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin, > >For detailed definition, I don't think there is no problem to change > >profile-level-id to required parameter. Maybe we can remove the default > >value by this. However, since config is defined that this parameter shall > >not be used for the capability exchange, and actually config is not to > >indicate the capability but coder configuration, there is a problem to > >change it as required. How about changing the first sentence of config as > >follows? > > > >"config: This parameter SHALL be used to indicate the configuration of the > >corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the > >codec capability in the capability exchange procedure. ......" > > > >Since the parameter config is added by requests to keep interlocking with > >32x-based systems, I would like to hear if this change matches the request. > >I would also like to hear from IETF experts if it is usual in IETF world to > >add this kind of parameter as required. > > RTP payload formats typically don't specify how the negotiation is done > in so much detail, rather they leave it up to the definition of the setup > protocol (e.g. H.323 may not use this, but what if a SIP or RTSP based > system want's to?) > Thank you for your suggestion. Am I correct that REQUIRED parameter of MIME/SDP means that it is present every time when MIME type is used? If it is correct, we should be much care for the selection of REQUIRED so that the unnecessary parameters are associated to MIME type evey time. By this meaning, "config" is not appropriate to be REQUIRED. For example, when indicating codec capability from client to sever at the negotiation stage, it is enough to use MIME (sub)type (and profile@level if necessary) indicating MPEG-4 Visual capability plus this payload format. On the other hands, I'm afraid that putting the parameter to OPTIONAL without any detailed definition will make misunderstanding and confusion on the usage of the parameter. To avoid both these two's above, I think it is appropriate to keep "config" as OPTIONAL, but describe the meaning and usage of the parameter as much while keeping the generality as much as possible, although it may be a little detailed. Is this a proper way of the definition? Best regards, Yoshihiro ---- 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 1267 From rem-conf Sat Oct 07 12:40:21 2000 From rem-conf-request@es.net Sat Oct 07 12:40:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hzfn-0006ZA-00; Sat, 7 Oct 2000 12:30:19 -0700 Received: from mail.exitexchange.com [63.105.23.16] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13hzfl-0006Y6-00; Sat, 7 Oct 2000 12:30:17 -0700 Received: from www.exitexchange.com (www.exitexchange.com [63.105.23.15]) by mail.exitexchange.com (8.9.3/8.9.3) with ESMTP id MAA20054 for ; Sat, 7 Oct 2000 12:30:20 -0700 Date: Sat, 7 Oct 2000 12:30:20 -0700 Message-Id: <200010071930.MAA20054@mail.exitexchange.com> Subject: Registration of domain with ExitExchange.com To: rem-conf@es.net Reply-To: Information From: Registration Information X-Mailer: Mail::Mailer[v1.19] Net::SMTP[v2.15] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here's how to register, ExitExchange.com is the fastest way to increase traffic to your website. Every time someone leaves a website, ExitExchange sends you new traffic. More effective than banners, ExitExchange actually brings real traffic right to your front door. Whether you're a large corporation or just a single homepage, there has never been an easier way to promote your website. Experience the explosive growth you've been dreaming of for your website with an instant 40-50 % increase in traffic. Put the power of the ExitExchange Network to work for you and start counting the hits immediately. Ohh...and did we mention it's absolutely FREE! http://www.ExitExchange.com Try our online Demo! Sincerely, ExitExchange Registration Services mailto:info@exitexchange.com "Get Big. Real Big. Really Fast" Company Info: ExitExchange 921 SW Washington Suite 224 Portland, OR 97205 (503)241-8510 Unsub Info: Simply reply with "unsubscribe" or "remove" in either the subject or body. or Go to http://www.exitexchange.com/unsub and enter your email address. We apologize for any inconvenience. Your address will be removed instantly. From rem-conf Sat Oct 07 13:18:54 2000 From rem-conf-request@es.net Sat Oct 07 13:18:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13i0PX-0000jg-00; Sat, 7 Oct 2000 13:17:35 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13i0PV-0000j1-00; Sat, 7 Oct 2000 13:17:34 -0700 Received: from zvil (i0-21.j3.actcom.co.il [192.115.22.243]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA04919; Sat, 7 Oct 2000 22:17:34 +0200 Received: by localhost with Microsoft MAPI; Sat, 7 Oct 2000 22:17:23 +0200 Message-ID: <01C030AC.5E240160.zvil@csi.com> From: Zvi Lifshitz To: "'Dave Singer'" , Pierre Clement Cc: CURET Dominique FTRD/DMI/REN , rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, CURET Dominique FTRD/DMI , "jan.vandermeer@philips.com" , "'Olivier Avaro'" Subject: RE: Types of MPEG-4 streams over IP Date: Sat, 7 Oct 2000 22:17:22 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 [Dave Singer:] I believe that the muxcodetable will often be small enough that a data: URL will be usable. [Reply:] Recalling Jan remarks about muxcodetable, I think he was right. Since the table can change on the fly, affecting subsequent FlexMux PDUs, it may be necessary to send it in band. So the question is, do we need to have also an out-of-band MuxCodeTable signaling? IMO not. Just to make sure, we are not talking about SMT, which should always be carried out of band, right? z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 From rem-conf Sat Oct 07 13:26:32 2000 From rem-conf-request@es.net Sat Oct 07 13:26:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13i0Xb-0001iF-00; Sat, 7 Oct 2000 13:25:55 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13i0XY-0001hx-00; Sat, 7 Oct 2000 13:25:52 -0700 Received: from zvil (i0-21.j3.actcom.co.il [192.115.22.243]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA06092; Sat, 7 Oct 2000 22:25:58 +0200 Received: by localhost with Microsoft MAPI; Sat, 7 Oct 2000 22:25:48 +0200 Message-ID: <01C030AD.8B096CA0.zvil@csi.com> From: Zvi Lifshitz To: "'Dave Singer'" , "jan.vandermeer@philips.com" Cc: "pierre.clement@thomcast.thomson-csf.com" , "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Date: Sat, 7 Oct 2000 22:25:47 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 [Dave Singer:] My understanding is that the multiplex nature of the stream does not change, and that therefore reliable up-front signalling is best. If this ins't true, the flexmux packet format may need some way to update the muxcodetable, but I hope that isn't true, because of reliability concerns. [Reply:] The problem is, it may very well change (as it happens in H.223). Reliability is indeed a concern. So whether MCT is signaled in-band or out-of-band it seems we must use MCT version number byte in each RTP packet. If we have this, we may achieve in-band reliability by repeating the MCT every x packets (also necessary for multicast). z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 From rem-conf Sat Oct 07 13:38:29 2000 From rem-conf-request@es.net Sat Oct 07 13:38:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13i0iA-0002fl-00; Sat, 7 Oct 2000 13:36:50 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13i0i8-0002fW-00; Sat, 7 Oct 2000 13:36:49 -0700 Received: from zvil (i0-21.j3.actcom.co.il [192.115.22.243]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA07718; Sat, 7 Oct 2000 22:37:00 +0200 Received: by localhost with Microsoft MAPI; Sat, 7 Oct 2000 22:36:50 +0200 Message-ID: <01C030AF.15461B60.zvil@csi.com> From: Zvi Lifshitz To: "'jan.vandermeer@philips.com'" Cc: "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Date: Sat, 7 Oct 2000 22:36:48 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 OK, Jan. I see. So we are actually talking about either signaling the presence of the byte somewhere inside the SDP description, or having two payload types (extra to the Kikuchi-san proposal), one with one without. I would prefer the second, but certainly would not be orthodox about it. Would follow IETF gurus if they have any recommendation. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 5:28 PM To: zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Zvi, Thanks. So we agree for at least 50 %. Now the remainder. Signaling the presence of the length byte by an attribute on SDP level allows the byte to be present or not. As long as you don't need the byte, don't burn the overhead. Regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: vrijdag, 06 oktober, 2000 17:09 To: csp@isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Jan, I'm in favor of a length byte. In the Generic payload format. All I said is that signaling whether the use of extra SL info (the Generic format) or not (Kikuchi-san proposal) can be done through payload type. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 4:56 PM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=x-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main reason to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system services (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a length unknown by now. In such cases the length byte provides a future proof solution for adding additional information using the same payload type. Assuming of course that the receiver is capable to parse the length byte while skipping the part of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one is not backward compatible. Existing receivers will not be capable to receive the new payload format. Kind regards, Jan From rem-conf Sat Oct 07 13:59:02 2000 From rem-conf-request@es.net Sat Oct 07 13:59:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13i0wx-0003ro-00; Sat, 7 Oct 2000 13:52:07 -0700 Received: from pc76111.chiaphua.com (D2NTSRV.chiaphua-hq) [202.76.76.111] by mail1.es.net with esmtp (Exim 1.81 #2) id 13i0wv-0003re-00; Sat, 7 Oct 2000 13:52:05 -0700 Received: from el06-24-131-156-224.ce.mediaone.net by D2NTSRV.chiaphua-hq with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id KLPLJDRP; Sun, 8 Oct 2000 04:59:49 +0800 DATE: 07 Oct 00 5:31:47 PM FROM: yZ58KUFbu@eagle.seed.net.tw Message-ID: TO: janee96q14@easynet.co.uk SUBJECT: Reach Your Target Market On The Internet Guaranteed! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Targeted Email Advertising Be Serious When Online Marketing or Don’t Even Bother. It is a True Fact that: Targeted direct e-mail campaigns are the fastest way to gain cash flow and customer awareness when you start up a business online. As you might already know, website recipricals - links, search engine listings and online promotions can take weeks if not months to take effect. Targeted e-mailing on the other hand has immediate results and can achieve immediate cash flow. Everyone on the Internet has e-mail access. The most beneficial aspect of targeted direct e-mailing is you can test ads within a matter of days and know if the campaign is successful within a week. There is NO other advertising medium on the web that will get you results this quick and easy. With the technology that now exists allows our company to target by geographical location, area code, City, state, country, occupation, and descriptive key words we use to define your market. When looking at the bigger picture here you can see why so many people turn to email campaigns. You can reach the right market for a 1/5 the of the cost compared to sending it through the normal postal service. Just remember that over 94% of all companies online are losing money. You ever wonder why? With US you will receive: A customized professional campaign for your business. Highly targeted extraction capabilities if needed. Email Delivery system Free consulting, that’s right free. The online going rate for this alone is over $150 hr. Take advantage of our Fall Special! Prices start at $1500 and up for targeted. General mailings at $450. Use your resources online and have us promote your company’s product or service. Call now , ***** 708 401 1688 or email vx151z@yemenmail.com***** ******************************************************************* You received this message because you visited one of our web sites or requested information. To be removed please send an email to: jaqrv19@yemenmail.com From rem-conf Sun Oct 08 21:47:02 2000 From rem-conf-request@es.net Sun Oct 08 21:47:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iUeG-0002vl-00; Sun, 8 Oct 2000 21:34:48 -0700 Received: from (www.chinaren-inc.com) [202.106.187.208] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iUeD-0002un-00; Sun, 8 Oct 2000 21:34:46 -0700 Received: from pavilion (mig-fl29c-127.rasserver.net [207.221.69.127]) by www.chinaren-inc.com (8.9.3/8.8.7) with SMTP id MAA11941; Mon, 9 Oct 2000 12:32:40 +0800 Date: Mon, 9 Oct 2000 12:32:40 +0800 From: rsb@docsj.de Message-Id: <200010090432.MAA11941@www.chinaren-inc.com> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From rem-conf Sun Oct 08 22:37:08 2000 From rem-conf-request@es.net Sun Oct 08 22:37:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iVZk-0005GP-00; Sun, 8 Oct 2000 22:34:12 -0700 Received: from md4.vsnl.net.in [202.54.6.60] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iVZi-0005GB-00; Sun, 8 Oct 2000 22:34:11 -0700 Received: from netlab.hcltech.com ([203.199.224.196]) by md4.vsnl.net.in (8.9.3/8.9.3) with ESMTP id LAA25864 for ; Mon, 9 Oct 2000 11:09:02 +0530 (IST) Received: from netlab.hcltech.com (ranga [192.168.201.48]) by netlab.hcltech.com (8.9.3/8.9.3) with ESMTP id LAA32451 for ; Mon, 9 Oct 2000 11:06:20 +0530 Message-ID: <39E156EF.5E25766F@netlab.hcltech.com> Date: Mon, 09 Oct 2000 10:56:07 +0530 From: Ranga Rao Ravuri Organization: HCL Technologies Ltd. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: At last, HERBAL V the all natural alternative! References: <200010090432.MAA11941@www.chinaren-inc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by md4.vsnl.net.in id LAA25864 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all/list administrator Can any one take steps to stop spam in this mailing lists. Thanks Ranga Rao Ravuri rsb@docsj.de wrote: >=20 > Herbal V: An Incredible All-Natural Healthy Alternative >=20 > Herbal V is the All Natural Approach to Male Virility, > Vitality and Pleasure. >=20 > Available N o w ! >=20 > Welcome to the New Sexual Revolution. >=20 > It's the all natural male potency and pleasure pill that men > everywhere are buzzing about. Herbal V is safe, natural and > specifically formulated to help support male sexual function > and pleasure. You just take two easy-to-swallow tablets > one hour before sex. And there's more great news - you can > get Herbal V for less than $1 a pill. >=20 > Amazing word of mouth praise on Herbal V has been spreading > like wildfire-already over 1,500,000 men have chosen > Herbal V. Since it is 100% natural you will never have > to worry about safety. Try doctor-recommended Herbal V > today and have the greatest night of your life! >=20 > Herbal V... Bringing Back the Magic! >=20 > 1,585,000 men can't be wrong. To date over 1 million men > have tried the super supplement Herbal V. > Here is why: >=20 > No Doctor Visit Required > Available Over the Counter > Not a Drug > 100% Natural > Safe, No Worries > Highest Quality Pharmaceutical-Grade Pure Nutriceuticals > Guaranteed Potency & Purity >=20 > Be a Real Man Again! >=20 > Questions and Answers >=20 > What is Herbal V? >=20 > Herbal V is a proprietary blend that was specifically > developed as a safe alternative for men who prefer > an all-natural approach to address impotence and boost > sexual performance. This amazing formula first became > popular with Hollywood insiders and the wealthy elite. > They were maximizing their sex lives, long before it > was available to the general public. >=20 > How does Herbal V work? >=20 > Developed by a team whose goal was to create the perfect > all-natural aphrodisiac. Herbal V is the result of that > remarkable effort. The Herbal V formula contains a precise > blend of cutting edge pro-sexual nutrients from around > the world that provide nutritional support, making it > possible for a man to have a pleasurable sexual experience. >=20 > What can Herbal V do for me? >=20 > Herbal V helps support male sexual function and > pleasure in a safe and natural manner. Simply put, > it can make your sex life incredible. >=20 > Is Herbal V Safe? >=20 > One of the great things about Herbal V is that it is > not a drug. It is an incredible herbal dietary supplement > that provides nutritional support for male sexual function > and pleasure. One of the most comforting features of > Herbal V is that you never have to worry about safety. >=20 > Herbal V: Safe - Natural - Exciting >=20 > Many have speculated that because Herbal V is so > popular with men, it must contain prescription drugs > or chemical components. Herbal V does not contain any > elements or traces of any prescription drug. Herbal V > is made using the world's most technologically advanced > state-of-the-art cold processing equipment to ensure > maximum purity. Herbal V has been independently analyzed > by the nation's premier testing facility to ensure purity, > quality and to end the rumors that, because it is so > popular, it must somehow be chemical. It is not. > Herbal V is natural - just as it says on the label. > Herbal V is simply fantastic! >=20 > Herbal V: Ingredients >=20 > Yohimbe, saw palmetto, avena sativa, androstenedione, > guarana, taurine, siberian ginseng, tribulus terrestris. > Tribulus Terrestis is certified to enhanced testosterone > levels by increasing Luteinzing hormone (LH) levels. > Androstenedione which is a precursor to testosterone > unlocks bound testosterone and makes it biologically > active again quickly. This means a dramatic surge in > desire. Avena Sativa Stimulates the neurotransmitter > pleasure centers to maximum capacity. This greatly > intensifies pleasure. >=20 > Just listen to what Herbal V has done for the sex lives > of people like you! >=20 > =93On a scale of 1 to 10, it's a 15. Electrifying. It's like > a wonder pill!=94 > =97 Justin Q B., New Haven, Texas >=20 > =93I haven't had sexual relations in 11 years. Then with > Herbal V it was... wow! It works again!=94 > =97 Sid R., Lakeland, Florida >=20 > =93I had sex four times in one night. It made me feel > like a 19-year-old again.=94 > =97 Chip S, Beech Mountain, North Carolina >=20 > =93Herbal V has turned my husband into a Sexual Superman! > I like the fact that it's all natural and has no > side effects. It's bringing back the good old days.=94 > =97 Jennifer B, Beverly Hills, California >=20 > The above testimonials are from product literature, > and we have not independently verified them. > However, the following testimonial is from a "senior" > gentleman who has purchased his second bottle of > Herbal V. When we heard his words with our own ears, > we asked his permission to print them here. >=20 > =93Man! I'm wild as I can be! I feel like I'm 25 years old again! > I'm not believing this!=94 > =97 Mr. Murphy, age 64, Lampart, IL. >=20 > Risk Free: Double Your Money Back Guarantee >=20 > If Herbal V does not give the desired results as stated > above, simply return the unused portion for a > double-your money back refund. No questions asked ! >=20 > Order Now: Safe, Fast, Secure, Private >=20 > Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is > available only through this special promotional offer. > Herbal V arrives in plain packaging for your privacy. > Any and all information is kept strictly confidential. >=20 > Payment Methods >=20 > You may FAX or Postal Mail Checks, MasterCard, Visa, > & American Express.payments. Money Orders > are accepted only by Postal Mail. >=20 > Each bottle of Herbal V contains 30 tablets, approximately > a 1 month supply. >=20 > Step 1: Place a check by your desired quanity. >=20 > ______ 1 Bottle of Herbal V $24 >=20 > ______ 2 Bottles of Herbal V $44 >=20 > ______ 3 Bottles of Herbal V $59 >=20 > Please add $6 shipping and handling for any size order. > [ Total cost including shipping & handling, > 1 bottle=3D$30, 2 bottles=3D$50, 3 bottles=3D$65 ] >=20 > International Orders > Please add $16 shipping and handling for any size order. > [ Total cost including shipping & handling, > 1 bottle=3D$40, 2 bottles=3D$60, 3 bottles=3D$75 ] >=20 > Step 2: Place a check by your desired payment method > and complete fields if necessary. >=20 > _____Check or CHECK-BY-FAX [details below] >=20 > _____Money Order >=20 > _____American Express > Account Number__________________ Exp____/____ >=20 > _____Visa > Account Number__________________ Exp____/____ >=20 > _____MasterCard > Account Number__________________ Exp____/____ >=20 > Please make your check or money order payable to > "Lion Sciences National". >=20 >=20 > Step 3: Please complete and print the following fields clearly. >=20 > Name ___________________________________________________ >=20 > Address _________________________________________________ >=20 > City ____________________________________________________ >=20 > State ___________________________________________________ >=20 > Zip _____________________________________________________ >=20 > E-mail __________________________________________________ >=20 > Signature _________________________________________________ > [ required for check and credit card orders] >=20 > Toll Free FAX Order Line: 1-800-940-6590 > If faxing in your order, please state whether you require > a fax, email, or no confirmation at all. > Allow up to one day for confirmation, if requested. > FAX orders are processed immediately. >=20 > Or, print & mail to: LSN > 3502 N. Powerline Rd. #525 > Pompano Beach, FL 33069 >=20 > ______________________________________________________ >=20 > *CHECK BY FAX ORDERS: Complete the check as normal. Tape > the check in the area below. Below the check, clearly write > the check number, all numbers at the bottom of the check, > & your name. Tape the check below and fax the check to the > toll free FAX number above. Void the check. Our merchant > will electronically debit your account for the amount of > the check; your reference number for this transaction will > be your check number. Nothing could be safer & easier ! >=20 > TAPE CHECK BELOW >=20 > _________________________________________________________= ____ >=20 > This is a one time mailing: Removal is automatic and no further > contact is necessary. Please Note: Herbal V is not intended to > diagnose, treat, cure or prevent any disease. As individuals differ, > so will results. Herbal V helps provide herbal and nutritional support > for male sexual performance. The FDA has not evaluated these > statements. For details about our double your money back guarantee, > please write to the above address, attention consumer affairs > department; enclose a self addressed stamped envelope for this and any > requested contact information. > Thank You. From rem-conf Mon Oct 09 01:40:42 2000 From rem-conf-request@es.net Mon Oct 09 01:40:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iYHI-0002UV-00; Mon, 9 Oct 2000 01:27:20 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iYHG-0002U3-00; Mon, 9 Oct 2000 01:27:18 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e998RFt06185 for ; Mon, 9 Oct 2000 10:27:16 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA07324 for ; Mon, 9 Oct 2000 11:27:14 +0300 (EET DST) Message-ID: <39E18160.CFEEC12F@lmf.ericsson.se> Date: Mon, 09 Oct 2000 11:27:12 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP sent to different ports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The draft http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt was presented in the last IETF in the MMUSIC working group meeting. It describe certain situations when it might be desirable to send a single RTP flow to different port numbers depending on the codec used. For instance, I begin sending PCM u-law to the remote port number 20000. Then, I change codec and I begin sending GSM. I send the RTP now to port 20002 instead. http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt contains some slides showing scenarios where this is useful. For instance, if I have two RTP libraries developed by third parties I will install the one supporting PCM in port number 20000 and the one supporting GSM in port number 20002. When the remote party sends me RTP, I want them to send the RTP to different ports depending on the codec they use at every moment. When celullar access is used, it is also necessary to configure radio bearers depending on the codec used. Besides these two, there are many other scenarios where this is needed. People in MMUSIC and SIP WGs think that there might be problems with some RTP implementations if RTP packets are sent to different ports in the middle of a session. RTCP is also a concern. Could you please help indentify all the possible issues? Thanks a lot, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From rem-conf Mon Oct 09 03:50:35 2000 From rem-conf-request@es.net Mon Oct 09 03:50:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iaS7-0007fK-00; Mon, 9 Oct 2000 03:46:39 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13iaS6-0007f4-00; Mon, 9 Oct 2000 03:46:38 -0700 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 9 Oct 2000 11:46:32 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Gonzalo Camarillo cc: rem-conf@es.net Subject: Re: RTP sent to different ports In-reply-to: Your message of "Mon, 09 Oct 2000 11:27:12 +0300." <39E18160.CFEEC12F@lmf.ericsson.se> Date: Mon, 09 Oct 2000 11:46:31 +0100 Message-ID: <642.971088391@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <39E18160.CFEEC12F@lmf.ericsson.se>Gonzalo Camarillo writes: > Hi, > > The draft > http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt > was presented in the last IETF in the MMUSIC working group meeting. > > It describe certain situations when it might be desirable to send a > single RTP flow to different port numbers depending on the codec used. > > For instance, I begin sending PCM u-law to the remote port number 20000. > Then, I change codec and I begin sending GSM. I send the RTP now to port > 20002 instead. > > http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt > contains some slides showing scenarios where this is useful. > > For instance, if I have two RTP libraries developed by third parties I > will install the one supporting PCM in port number 20000 and the one > supporting GSM in port number 20002. When the remote party sends me RTP, > I want them to send the RTP to different ports depending on the codec > they use at every moment. This doesn't read like a very plausible example. A good library will separate packet processing from media packetization and both from media decoding, ie apple quicktime, the lucent stack, the ucl stack. Payload identifiers suffices. It'd be difficult to engineer a properly functioning RTCP component in such a system. > When celullar access is used, it is also necessary to configure radio > bearers depending on the codec used. Is the intent to hash the TFT fields into some type of pre-configured mobile channels because there is latency associated with the configuration? Is the TFT spec set in stone so there is no way payload inspectino could be used? If this is not the case then there are several options compatible with the existing RTP base: 1) At the present time it's possible to have an educated guess at the content of an RTP audio packet using knowledge of codec frame sizes and interpacket gaps. The worst case scenario is a few packets that do not enjoy the benefits of codec-specific FEC / concealment at the link layer at the start of a transmission. In the long run this may not be a reliable strategy as more codecs and data-rates come into use. 2) Depending on the relative costs another approach would be to inspect the payload of the first packet, and cache (src,dst,packet size). When the packet size changes or the cache state times out another packet inspection is required. 3) It seems obvious, but if there is any form of RTP header compression, then it should be straightforward to the payload information. > Besides these two, there are many other scenarios where this is needed. > > People in MMUSIC and SIP WGs think that there might be problems with > some RTP implementations if RTP packets are sent to different ports in > the middle of a session. RTCP is also a concern. It would be interesting to know what the cost of inspecting the RTP payload on per packet basis would be and what the latencies are for configuring the channels. Kind Regards - Orion From rem-conf Mon Oct 09 04:44:26 2000 From rem-conf-request@es.net Mon Oct 09 04:44:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ibKr-0002U0-00; Mon, 9 Oct 2000 04:43:13 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ibKp-0002Tp-00; Mon, 9 Oct 2000 04:43:11 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA01470; Mon, 9 Oct 2000 07:43:00 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39E1AF45.23258399@cs.columbia.edu> Date: Mon, 09 Oct 2000 07:43:01 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ranga Rao Ravuri CC: rem-conf@es.net Subject: Spam filter [Was: Re: At last, HERBAL V the all natural alternative!] References: <200010090432.MAA11941@www.chinaren-inc.com> <39E156EF.5E25766F@netlab.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ranga Rao Ravuri wrote: > > Hi all/list administrator > Can any one take steps to stop spam in this mailing lists. > Thanks I have not seen evidence that there is a list administrator for this list, so I doubt that your request will have much effect. Your request has been made numerous times, to no avail. It might be worthwhile exploring moving this list to a host that has the ability and interest to provide list maintenance and spam filtering. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Oct 09 04:50:46 2000 From rem-conf-request@es.net Mon Oct 09 04:50:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ibQb-00036B-00; Mon, 9 Oct 2000 04:49:09 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ibQY-00035V-00; Mon, 9 Oct 2000 04:49:06 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA01703; Mon, 9 Oct 2000 07:49:03 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39E1B0B0.AE92B5CF@cs.columbia.edu> Date: Mon, 09 Oct 2000 07:49:04 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: <39E18160.CFEEC12F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If data is going to two ports, we have two different sessions. That's what we have SIP (and SAP, RTSP, etc.) for, to allow mid-session changes of transport destinations. For example, SIP re-INVITE will handle this just fine. Among other things, adding this complexity will make firewalls much more difficult. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Oct 09 06:18:11 2000 From rem-conf-request@es.net Mon Oct 09 06:18:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13icmi-0006Mo-00; Mon, 9 Oct 2000 06:16:04 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13icmf-0006Me-00; Mon, 9 Oct 2000 06:16:02 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA15479; Mon, 9 Oct 2000 15:15:53 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma015477; Mon, 9 Oct 00 15:15:53 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA19027; Mon, 9 Oct 2000 15:15:52 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA04954; Mon, 9 Oct 2000 15:15:52 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014686045; Mon, 9 Oct 2000 15:16:56 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014686045000002L952*@MHS> Date: Mon, 9 Oct 2000 15:16:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/09/00 16:14:20" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Kris, You wrote: >I'd appreciate clarification of user_data usage conventions by anyone,= >please (no, no, don't just say it shouldn't be used! I know it's mess= y and >goes against certain design principles!) Well, my MPEG history started with a very memorable meeting in Kurihama= , back in November '89. By that time, user data was not invented yet. I a= m not sure who introduced user data, but it already exists in MPEG-1 video. A= s far as I know, it is used (if at all) for associating certain data to a vid= eo frame, e.g. closed captioning or subtitles, in particular in ATSC. Thou= gh it can be used for multiplexing with any other data (such as audio), I am = not aware of any such usage. User data could be the solution for people who= don't like MPEG systems, but I spent some very enjoyable years there, s= o I really love MPEG systems ! Coming back to your suggestion, it may in principle work in cases where= video is used. In other cases you need to initiate a video session with= only user data. May work too. However, to accommodate different RTP packet "frequencies" several inventions have to be made to associate the user = data to the correct SL header. As you say, very messy indeed; just by think= ing of such solution I already get a headache. And all of that to avoid the= simple solution of flagging a length byte by an SDP attribute. No, I th= ink dirty solutions should only be considered if there are no clean ones. Kind regards, Jan -----Original Message----- From: khuber@sorensonlabs.com [mailto:khuber@sorensonlabs.com] Sent: vrijdag, 06 oktober, 2000 18:44 To: csp@isi.edu; zvil@csi.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Hello Jan, For devices that (for whatever reason) must use the Kikuchi-san payload= type, and never upgrade to a new payload type, then perhaps a possibili= ty you haven't considered is placing future configuration information in t= he user_data field of the visual streams. This field is present in the vi= sual object sequence (VOS) header, the visual object (VO) header, the visual= object layer (VOL) header, and in the group of VOP (GOV) header. It is= not in the VOP header, so to accommodate a decoding timestamp, for example,= you'd need to send a list of DTS's in the GOV header user data, for the= VOPs that follow. OK it's a messy and ugly solution (especially if you put audio-related information in there)! But it's already carried in MPEG-4 and (unwittingly?) in the Kikuchi-san draft payload format. Perhaps MPEG-4= user_data was accepted with "configuration future-proofing" in mind (I became involved with MPEG after it was already there, so I don't know t= he history). As for using user_data, Annex D of the systems spec. gives a registrati= on procedure for "the private data format identifiers" and "the IPMP syste= m type values". I'm not sure if user_data is included in the meaning of "private data format", however, or if you just use it and build decoder= s that try to figure out what portion of it is yours. As for contacting = the registration authority, D.3 says "To Be Determined". Whatever the organization, it is to report its activities to JTC 1, ITTF (probably "Internet Theory Task Force") and SC 29 secretariat. Note that since visual information consumes much more bandwidth than au= dio, there is not so much wasted bandwidth associated with duplication of au= dio broadcast services due to a need to support an old payload format as th= ere is when duplication of video broadcast service is required to prevent d= evice obsolescence. Of course the whole analysis of bandwidth wastage depend= s on numbers of non-upgradeable devices, but I understand there are applicat= ions that would include a large number of MPEG-2 devices in the count, so de= vice or bandwidth wastage without information backward-compatibility could b= e significant. I'd appreciate clarification of user_data usage conventions by anyone, please (no, no, don't just say it shouldn't be used! I know it's messy= and goes against certain design principles!) But I think it makes some klu= dges possible that could prove very valuable in some cases. Not everything = of value is pretty. And note that the burden of parsing and using the user_data fields is primarily on those who wish to use it. The burden = on everyone else is to carry and skip it. If it prevents needless replica= tion of high-bandwidth services for a significant period of time, it is a sm= all price to pay. Of course if it gets too large, it is a more significant= price to pay in bandwidth, but that is certainly not a problem at the present time. Regards, Kris -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 8:56 AM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=3Dx-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main rea= son to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system serv= ices (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a= length unknown by now. In such cases the length byte provides a future proof solution for addi= ng additional information using the same payload type. Assuming of course = that the receiver is capable to parse the length byte while skipping the par= t of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one i= s not backward compatible. Existing receivers will not be capable to receive = the new payload format. Kind regards, Jan = From rem-conf Mon Oct 09 08:00:33 2000 From rem-conf-request@es.net Mon Oct 09 08:00:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ieO3-00049D-00; Mon, 9 Oct 2000 07:58:43 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ieO2-000493-00; Mon, 9 Oct 2000 07:58:42 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id XAA06499; Mon, 9 Oct 2000 23:58:34 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id XAA19752; Mon, 9 Oct 2000 23:58:34 +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 XAA20737; Mon, 9 Oct 2000 23:58:33 +0900 (JST) Received: from ave (kwa0111.mobile.toshiba.co.jp [133.120.199.27]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id XAA19934; Mon, 9 Oct 2000 23:58:31 +0900 (JST) Message-ID: <027101c03201$70acc1e0$1fc77885@ave> From: "Yoshihiro Kikuchi" To: "Colin Perkins" , "Stephan Wenger" Cc: , "Stephan Wenger" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <5.0.0.25.2.20001005232618.02ebb6d0@mail.cs.tu-berlin.de> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Mon, 9 Oct 2000 23:58:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, > > >What about... > > "When the short video header mode is used, the RTP payload format > > for H.263 SHOULD be used (the format defined in RFC 2429 is > > RECOMMENDED, but the RFC 2190 format MAY be used for compatibility > > with older implementations)." > > Fine with me. > > Stephan > > I will incorporate the sentence above to the last text of the Internet-Draft. regards, Yoshihiro ---- 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 1267 From rem-conf Mon Oct 09 08:00:34 2000 From rem-conf-request@es.net Mon Oct 09 08:00:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ieNf-00048E-00; Mon, 9 Oct 2000 07:58:19 -0700 Received: from (airsec.fr) [195.115.23.186] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ieNS-000450-00; Mon, 9 Oct 2000 07:58:06 -0700 Received: from 209.179.193.21 - 209.179.193.21 by airsec.fr with Microsoft SMTPSVC(5.5.1775.675.6); Mon, 9 Oct 2000 16:47:27 +0200 Message-ID: <000000c0017a$00005291$000064da@209.179.193.21> To: From: saperl@earthlink.com Subject: Fast Easy Cash 25818 Date: Mon, 09 Oct 2000 07:55:19 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE Mortgage Quote

 HOMEOWNERS

 Do you want to pay off your credit card debt,
 refinance your existing mortgage, or take
 out additional cash for any purpose?

 WE SPECIALIZE IN FAST AND EASY APPROVALS

 * Borrow money even if you are in chapter 13 bankruptcy
  or save your home if you are facing foreclosure.
 * Pay off tax liens, judgments, or collection accounts.
 * Consolidate debts, pay bills.
 * Make home improvements, or even take that dream vacation.

 WE CAN GET YOU THE LOAN YOU NEED REGARDLESS OF YOUR CREDIT.

 * Good or Bad Credit OK * Self Employed OK
 * Prior Bankruptcy OK * Credit Problems OK

 Whatever your lifestyle needs. APPLY NOW! We can help.

 * WE FUND THE LOANS THAT OTHER LENDERS TURN DOWN!

 FOR A FAST, FREE LOAN QUOTE, FILL OUT THE FORM BELOW.



Our 60 second application

Fill= out this short form to receive your free information.
 All Questions Must Be Answered. Type NA To Those That Do Not Apply To You



.
First Name
Last Name
Co-Applicant's Name
City
State (abbreviation)
Street Address
Zip
Work Phone 000-000-0000
Home Phone 000-000-0000
Type of House Owned
Current Value
Purchase Price
First Mortgage Balance
Interest Rate
Fixed or Adjustable?
Monthly Payment
Behind on Payments?
How Would Your Rate Your Credit?
Place of Employment
Years There
Yearly Income
Best Time to Call
Type of Loan Desired
Email Address



If you received this in error or would like to be
removed from our list, PLEASE CLICK HERE

 

 

 

 

 

From rem-conf Mon Oct 09 08:16:31 2000 From rem-conf-request@es.net Mon Oct 09 08:16:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ieeO-0006aK-00; Mon, 9 Oct 2000 08:15:36 -0700 Received: from (purple.east.isi.edu) [38.218.19.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ieeN-0006a9-00; Mon, 9 Oct 2000 08:15:36 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA02162; Mon, 9 Oct 2000 11:16:41 -0400 Message-Id: <200010091516.LAA02162@purple.east.isi.edu> To: Gonzalo Camarillo cc: rem-conf@es.net Subject: Re: RTP sent to different ports In-Reply-To: Message from Gonzalo Camarillo of "Mon, 09 Oct 2000 11:27:12 +0300." <39E18160.CFEEC12F@lmf.ericsson.se> Date: Mon, 09 Oct 2000 11:16:41 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Gonzalo Camarillo writes: >Hi, > >The draft >http://search.ietf.org/internet-drafts/draft-camarillo-sip-sdp-00.txt >was presented in the last IETF in the MMUSIC working group meeting. > >It describe certain situations when it might be desirable to send a >single RTP flow to different port numbers depending on the codec used. > >For instance, I begin sending PCM u-law to the remote port number 20000. >Then, I change codec and I begin sending GSM. I send the RTP now to port >20002 instead. > >http://www2.ietf.org/proceedings/00jul/slides/mmusic-sdp-media-alignment.ppt >contains some slides showing scenarios where this is useful. > >For instance, if I have two RTP libraries developed by third parties I >will install the one supporting PCM in port number 20000 and the one >supporting GSM in port number 20002. When the remote party sends me RTP, >I want them to send the RTP to different ports depending on the codec >they use at every moment. This seems like a mistake, and poor application design. It also makes the job of firewalls even harder. >When celullar access is used, it is also necessary to configure radio >bearers depending on the codec used. Which would seem to be a job for the call setup protocol, hence signal two RTP sessions (rather than trying to split a single session in an odd manner). >Besides these two, there are many other scenarios where this is needed. > >People in MMUSIC and SIP WGs think that there might be problems with >some RTP implementations if RTP packets are sent to different ports in >the middle of a session. RTCP is also a concern. > >Could you please help indentify all the possible issues? Where does the RTCP traffic go? If you send it to two separate ports also, then you have two RTP sessions: no protocol change needed, just signal this in an appropriate manner. If sent to a single port, you'll likely confuse existing implementations which monitor traffic sent to a single port. Colin From rem-conf Mon Oct 09 08:18:45 2000 From rem-conf-request@es.net Mon Oct 09 08:18:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iegr-0006xY-00; Mon, 9 Oct 2000 08:18:09 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iegq-0006wr-00; Mon, 9 Oct 2000 08:18:08 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id AAA08402; Tue, 10 Oct 2000 00:18:03 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id AAA21737; Tue, 10 Oct 2000 00:18:02 +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 AAA21033; Tue, 10 Oct 2000 00:18:02 +0900 (JST) Received: from ave (kwa0111.mobile.toshiba.co.jp [133.120.199.27]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id AAA20504; Tue, 10 Oct 2000 00:17:58 +0900 (JST) Message-ID: <03eb01c03204$2876b4a0$1fc77885@ave> From: "Yoshihiro Kikuchi" To: "Yoshihiro Kikuchi" , "Colin Perkins" , "Toshiro Kawahara" Cc: "philippe.gentric" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <085201c02f85$bc4d1ce0$cc51c485@eel.rdc.toshiba.co.jp> <4.2.0.58.J.20001007134735.00b23af0@spg.yrp.nttdocomo.co.jp> <01b801c03050$f97fe7c0$1fc77885@ave> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 10 Oct 2000 00:18:18 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, If there is no problem, I will reflect the following change on the MIME/SDP parameter "config" to the last text of Internet-Draft to meet the requests. > "config: This parameter SHALL be used to indicate the configuration of the > corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the > codec capability in the capability exchange procedure. ......" Best regards, Yoshihiro ----- Original Message ----- From: Yoshihiro Kikuchi To: Colin Perkins ; Toshiro Kawahara Cc: philippe.gentric ; IETF AVT ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; Yoshihiro Kikuchi Sent: Saturday, October 07, 2000 8:23 PM Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > Dear Colin, Kawahara-san, Philippe, and all, > > > >>Since the parameter config is added by requests to keep interlocking > with > > >>32x-based systems, I would like to hear if this change matches the > request. > > >>I would also like to hear from IETF experts if it is usual in IETF world > to > > >>add this kind of parameter as required. > > > > I'm one of the proponenst of this parameter, and this > > change matches our intention. 3G-324M, which is a 3GPP > > version of H.324/M terminal specification, mandates the > > equivalent parameter in OpenLogicalChannel signaling, and > > to make the interworking with this terminal, this change > > is really beneficial. I strongly support this idea. > > > I'm happy to hear that it meets your requirement. > > And I hope it also matches the desire of Philippe bellow because the > definition explicitly says that config SHALL be used to indicate the codec > configuration. > > > Well what I would like is to be sure when I get a SDP > > file to be able to correctly initialize my decoders > > > >RTP payload formats typically don't specify how the negotiation is done > > >in so much detail, rather they leave it up to the definition of the setup > > >protocol (e.g. H.323 may not use this, but what if a SIP or RTSP based > > >system want's to?) > > > > I understand your concern. The mandatory/optional definition > > should be in a proper place to avoid inconsistency between > > specifications or not to limit the function of other protocol > > unnecessarily. However, I believe the proposed revised > > definition is not such kind of definition. It don't define > > the way of negotiation, but provides a clarification of > > the parameter (for what purpose it SHALL or SHALL NOT be > > used). "SHALL/SHALL NOT" type of definition might look too > > strong for such generic definition, but I believe this > > is a straightforward translation of the situation. > > > I completely agree with this. > > Maybe it is not appropriate to have a description in the payload format > document about one specific framework, such as how to use OpenLogicalChannel > of H.245. However, I think indicating capable codec and payload format at an > negotiation stage is more general not only for H.323. For example, OPTIONS > or INVITE is used to exchange the capability in SIP. > > I tried to describe the definition as general as possible, but I appreciate > suggestions for better wording. Anyway, I think it is better that the > definition will be not too much concise so that we don't leave ambiguity. > > Best regards, > Yoshihiro > > ---- > 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 1267 > > > > > From rem-conf Mon Oct 09 08:37:12 2000 From rem-conf-request@es.net Mon Oct 09 08:37:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ieyh-00017s-00; Mon, 9 Oct 2000 08:36:35 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ieyg-00017h-00; Mon, 9 Oct 2000 08:36:34 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e99FaSt09714; Mon, 9 Oct 2000 17:36:29 +0200 (MEST) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA09405; Mon, 9 Oct 2000 18:36:26 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id SAA05619; Mon, 9 Oct 2000 18:36:23 +0300 (EETDST) Message-ID: <39E1E5E5.6C938FAB@lmf.ericsson.se> Date: Mon, 09 Oct 2000 18:36:05 +0300 From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Orion Hodson CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: <642.971088391@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, > > For instance, if I have two RTP libraries developed by third parties I > > will install the one supporting PCM in port number 20000 and the one > > supporting GSM in port number 20002. When the remote party sends me RTP, > > I want them to send the RTP to different ports depending on the codec > > they use at every moment. > > This doesn't read like a very plausible example. A good library will > separate packet processing from media packetization and both from > media decoding, ie apple quicktime, the lucent stack, the ucl stack. > Payload identifiers suffices. It'd be difficult to engineer a > properly functioning RTCP component in such a system. Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd party developed RTP library is just one among many examples. There are other scenarios where this feature might be useful. For instance, when the DTMF tones have to be received in a different device than the voice. I'd like to know if RCTP is really an unsolvable issue. I am not fully aware of all the problems related to RCTP we might have when using two different port numbers. > > When celullar access is used, it is also necessary to configure radio > > bearers depending on the codec used. > > Is the intent to hash the TFT fields into some type of pre-configured > mobile channels because there is latency associated with the > configuration? Is the TFT spec set in stone so there is no way > payload inspectino could be used? Well, this is another example where this mechanism might be needed. The TFT (Traffic Flow Template) sends the incoming IP packets (IP packets >from the network to the UMTS terminal) to the proper radio bearer (PDP context). Since the TFT examines all the incoming IP packets - not just RTP packets - it seems complicated to inspect the RTP payload type. All the incoming UDP packets might have to be examined further to look for an RTP header. If we can send different RTP payloads to different ports the packets can be routed to the proper radio bearer that implements the proper UEP (Unequal Error Protection), for instance. Anyway, I would not like to go deep into details that are 3GPP specific. This can be seen as a general QoS problem, where the packets will get a different treatment depending on the destination UDP port number. > It would be interesting to know what the cost of inspecting the RTP > payload on per packet basis would be and what the latencies are for > configuring the channels. I do not have exact figures, but the cost of inspecting the payload of every IP packet entering the access network seems high. About configuring channels, it is a too slow process to be performed in "real-time". Thanks for the feedback, Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From rem-conf Mon Oct 09 08:44:22 2000 From rem-conf-request@es.net Mon Oct 09 08:44:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13if5S-00026c-00; Mon, 9 Oct 2000 08:43:34 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13if5R-00026N-00; Mon, 9 Oct 2000 08:43:33 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e99FhLt12676; Mon, 9 Oct 2000 17:43:21 +0200 (MEST) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA09763; Mon, 9 Oct 2000 18:43:20 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id SAA06354; Mon, 9 Oct 2000 18:43:19 +0300 (EETDST) Message-ID: <39E1E785.9DFE602B@lmf.ericsson.se> Date: Mon, 09 Oct 2000 18:43:01 +0300 From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: <39E18160.CFEEC12F@lmf.ericsson.se> <39E1B0B0.AE92B5CF@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 Hi, Yes, SIP re-INVITE solves this issue when we can wait 1.5 RTT. I am more looking into the scenario where we change dynamically the codec without application layer signalling - SIP - involved. In a cellular environment, for instance, handling a SIP re-INVITE might take time, since new radio bearers have to be configured. About the firewalls, I agree that this adds complexity. Thanks a lot for your feedback, Best regards, Gonzalo Henning Schulzrinne wrote: > > If data is going to two ports, we have two different sessions. That's > what we have SIP (and SAP, RTSP, etc.) for, to allow mid-session changes > of transport destinations. For example, SIP re-INVITE will handle this > just fine. Among other things, adding this complexity will make > firewalls much more difficult. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From rem-conf Mon Oct 09 08:48:17 2000 From rem-conf-request@es.net Mon Oct 09 08:48:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13if9f-0002hg-00; Mon, 9 Oct 2000 08:47:55 -0700 Received: from (purple.east.isi.edu) [38.218.19.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13if9e-0002hS-00; Mon, 9 Oct 2000 08:47:54 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA02518; Mon, 9 Oct 2000 11:48:51 -0400 Message-Id: <200010091548.LAA02518@purple.east.isi.edu> To: Stephan Wenger cc: SIGNES Julien / ENVIVIO , "'Y. Matsui'" , 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from Stephan Wenger of "Thu, 05 Oct 2000 19:53:07 +0200." <5.0.0.25.2.20001005193923.02f48eb0@mail.cs.tu-berlin.de> Date: Mon, 09 Oct 2000 11:48:51 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephan Wenger writes: >Julien, Group, > > >>I agree in general they should be fully reliable channels carrying >>those,as well as BIFS comands. However, note that a lot of >>streaming those days is actually done by RTP over TCP. > >This is interesting. I'm not aware of any commercial system doing >such a thing. I know that telephony people discuss the use of >RTP over TCP on managed IP networks for conversational >applications, but that is probably not what you are referring to? >I'm also aware of UDP/RTP streaming techniques that use a TCP >channel for repair, (and feedback to report errors). But again, that >is not what I would understand as RTP over TCP. So can you >please come up with an example and/or references? Thanks in >advance. And if you do, please let me know also - this is one of the missing entries in the RTP interoperability matrix which is holding up the move of RTP to draft standard. >Also, using TCP as the transport does not automatically render >a reliable RTP channel, at least not under real-time constraints. >There is still a good chance that packets that finally arrive at the >receiver will be thrown out because they do not fall into the jitter >tolerance window of the playout buffer. (This is true for all >re-transmission based protocols). You simply can't guaranty that >all packets arrive in time unless you have finally received all packets. Right - which is why reliable multicast is in a separate working group, which has very different concerns to AVT. Once again, I'd urge those looking for a reliable transfer protocol to use either TCP or one of the reliable multicast protocols under development in RMT. RTP is not the right protocol for reliable transport. Colin From rem-conf Mon Oct 09 08:51:40 2000 From rem-conf-request@es.net Mon Oct 09 08:51:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ifCw-0003W9-00; Mon, 9 Oct 2000 08:51:18 -0700 Received: from (purple.east.isi.edu) [38.218.19.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ifCu-0003U1-00; Mon, 9 Oct 2000 08:51:16 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA02536; Mon, 9 Oct 2000 11:52:06 -0400 Message-Id: <200010091552.LAA02536@purple.east.isi.edu> To: jan.vandermeer@philips.com cc: zvil , rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from jan.vandermeer@philips.com of "Fri, 06 Oct 2000 17:27:50 +0200." <0056890014651648000002L982*@MHS> Date: Mon, 09 Oct 2000 11:52:06 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> jan.vandermeer@philips.com writes: >Thanks. So we agree for at least 50 %. Now the remainder. Signaling the >presence of the length byte by an attribute on SDP level allows the byte to >be present or not. As long as you don't need the byte, don't burn the >overhead. How do you propose to do this in a manner which is not equivalent to defining two payload formats? I think we are in need of a concrete proposal here, since I don't understand what you're driving towards... Colin From rem-conf Mon Oct 09 09:05:14 2000 From rem-conf-request@es.net Mon Oct 09 09:05:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ifMP-00056W-00; Mon, 9 Oct 2000 09:01:05 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ifMO-00056L-00; Mon, 9 Oct 2000 09:01:04 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA14936; Mon, 9 Oct 2000 12:00:19 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39E1EB94.5033F153@cs.columbia.edu> Date: Mon, 09 Oct 2000 12:00:20 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Orion Hodson , rem-conf@es.net Subject: Re: RTP sent to different ports References: <642.971088391@cs.ucl.ac.uk> <39E1E5E5.6C938FAB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gonzalo Camarillo wrote: > > > Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd > party developed RTP library is just one among many examples. There are > other scenarios where this feature might be useful. For instance, when > the DTMF tones have to be received in a different device than the voice. That is solvable in a far cleaner manner by having two voice sessions, one for regular audio and one for DTMF. The same applies to other scenarios. To the end system, this is just like mixing several sources. Implementing this gets you mixing and conferencing for free, so this is a Good Thing. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Oct 09 09:59:27 2000 From rem-conf-request@es.net Mon Oct 09 09:59:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13igFg-0000fa-00; Mon, 9 Oct 2000 09:58:12 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13igFf-0000YL-00; Mon, 9 Oct 2000 09:58:11 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <41BTBD8N>; Mon, 9 Oct 2000 10:57:15 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA81EAEE@el-postino.s-vision.com> From: Kris Huber To: jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Date: Mon, 9 Oct 2000 10:57:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Jan, > Coming back to your suggestion, it may in principle work in cases where > video is used. That's what I thought. Thanks for the additional clarifications and user_data examples. Like you, I don't like headaches. However, I'm afraid that sometimes the headache is inevitable and a kludgey solution designed for a relatively short-term and specific situation can sometimes be the less painful one. I don't know that this is the case in this situation, as I am not very expert in the systems and applications of concern. But I feel good about having the user_data option available for this and other purposes. Even if seldom used it is a mechanism that preserves the MPEG-1, -2 & -4 implementer's freedom to compensate, at least to a limited extent, for perceived deficiencies in the specifications agreed upon by the groups (even the groups outside of MPEG). I do wish you well in your effort to define a better solution than the insertion of an adaptation header into user_data, which brings with it the associated complexities and uncertainties of identifying that adaptation header and isolating it from other user_data. >No, I think >dirty solutions should only be considered if there are no clean ones. I agree. Best regards, Kris -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Monday, October 09, 2000 7:17 AM To: khuber@sorensonlabs.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Hello Kris, You wrote: >I'd appreciate clarification of user_data usage conventions by anyone, >please (no, no, don't just say it shouldn't be used! I know it's messy and >goes against certain design principles!) Well, my MPEG history started with a very memorable meeting in Kurihama, back in November '89. By that time, user data was not invented yet. I am not sure who introduced user data, but it already exists in MPEG-1 video. As far as I know, it is used (if at all) for associating certain data to a video frame, e.g. closed captioning or subtitles, in particular in ATSC. Though it can be used for multiplexing with any other data (such as audio), I am not aware of any such usage. User data could be the solution for people who don't like MPEG systems, but I spent some very enjoyable years there, so I really love MPEG systems ! Coming back to your suggestion, it may in principle work in cases where video is used. In other cases you need to initiate a video session with only user data. May work too. However, to accommodate different RTP packet "frequencies" several inventions have to be made to associate the user data to the correct SL header. As you say, very messy indeed; just by thinking of such solution I already get a headache. And all of that to avoid the simple solution of flagging a length byte by an SDP attribute. No, I think dirty solutions should only be considered if there are no clean ones. Kind regards, Jan -----Original Message----- From: khuber@sorensonlabs.com [mailto:khuber@sorensonlabs.com] Sent: vrijdag, 06 oktober, 2000 18:44 To: csp@isi.edu; zvil@csi.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Hello Jan, For devices that (for whatever reason) must use the Kikuchi-san payload type, and never upgrade to a new payload type, then perhaps a possibility you haven't considered is placing future configuration information in the user_data field of the visual streams. This field is present in the visual object sequence (VOS) header, the visual object (VO) header, the visual object layer (VOL) header, and in the group of VOP (GOV) header. It is not in the VOP header, so to accommodate a decoding timestamp, for example, you'd need to send a list of DTS's in the GOV header user data, for the VOPs that follow. OK it's a messy and ugly solution (especially if you put audio-related information in there)! But it's already carried in MPEG-4 and (unwittingly?) in the Kikuchi-san draft payload format. Perhaps MPEG-4 user_data was accepted with "configuration future-proofing" in mind (I became involved with MPEG after it was already there, so I don't know the history). As for using user_data, Annex D of the systems spec. gives a registration procedure for "the private data format identifiers" and "the IPMP system type values". I'm not sure if user_data is included in the meaning of "private data format", however, or if you just use it and build decoders that try to figure out what portion of it is yours. As for contacting the registration authority, D.3 says "To Be Determined". Whatever the organization, it is to report its activities to JTC 1, ITTF (probably "Internet Theory Task Force") and SC 29 secretariat. Note that since visual information consumes much more bandwidth than audio, there is not so much wasted bandwidth associated with duplication of audio broadcast services due to a need to support an old payload format as there is when duplication of video broadcast service is required to prevent device obsolescence. Of course the whole analysis of bandwidth wastage depends on numbers of non-upgradeable devices, but I understand there are applications that would include a large number of MPEG-2 devices in the count, so device or bandwidth wastage without information backward-compatibility could be significant. I'd appreciate clarification of user_data usage conventions by anyone, please (no, no, don't just say it shouldn't be used! I know it's messy and goes against certain design principles!) But I think it makes some kludges possible that could prove very valuable in some cases. Not everything of value is pretty. And note that the burden of parsing and using the user_data fields is primarily on those who wish to use it. The burden on everyone else is to carry and skip it. If it prevents needless replication of high-bandwidth services for a significant period of time, it is a small price to pay. Of course if it gets too large, it is a more significant price to pay in bandwidth, but that is certainly not a problem at the present time. Regards, Kris -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Friday, October 06, 2000 8:56 AM To: zvil@csi.com; csp@isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Colin, Zvi, all, Colin wrote : >>Perhaps an a=x-mpeg4-sl-header-length: >>attribute on any RTP stream carrying MPEG4 content should be >>permitted, and required if byte count is non-zero (with zero being >>the default)? >In which case, signal using the payload type field... And Zvi wrote almost the same : >Or just have a new payload type which is just a different (and more >common) way of signaling. There are several arguments for introducing a length byte. The main reason to introduce such field is that it creates headroom for fully backward compatible extensions. Specifically in two cases: a) when applications want to add an SL header to non-MPEG-4 system services (for reasons discussed in earlier threads); b) when the SL header is extended in future with additional fields of a length unknown by now. In such cases the length byte provides a future proof solution for adding additional information using the same payload type. Assuming of course that the receiver is capable to parse the length byte while skipping the part of the subsequent field that the receiver does not understand. Using another payload type does also provide a solution, but this one is not backward compatible. Existing receivers will not be capable to receive the new payload format. Kind regards, Jan From rem-conf Mon Oct 09 10:10:19 2000 From rem-conf-request@es.net Mon Oct 09 10:10:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13igQ3-0001n4-00; Mon, 9 Oct 2000 10:08:55 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13igQ2-0001mu-00; Mon, 9 Oct 2000 10:08:54 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 9 Oct 2000 18:08:44 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Gonzalo Camarillo cc: rem-conf@es.net Subject: Re: RTP sent to different ports In-reply-to: Your message of "Mon, 09 Oct 2000 18:36:05 +0300." <39E1E5E5.6C938FAB@lmf.ericsson.se> Date: Mon, 09 Oct 2000 18:08:42 +0100 Message-ID: <9636.971111322@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <39E1E5E5.6C938FAB@lmf.ericsson.se>Gonzalo Camarillo writes: > I'd like to know if RCTP is really an unsolvable issue. I am not fully > aware of all the problems related to RCTP we might have when using two > different port numbers. Each RTP session has an associated participant database with SDES and reporting information. If there are two RTP ports and these are associated with two differnt sessions, then a back door mechanism will be necessary to share information to have RTCP perform properly, i.e. correct reception report intervals and information conveyed. If there are two ports and one session, then most out-of-the-box RTP libraries/applications don't support this currently. > If we can send different RTP payloads to different ports the packets can > be routed to the proper radio bearer that implements the proper UEP > (Unequal Error Protection), for instance. The issue of RTP header extensions should at least be considered when using UEP because the extensions occur before the RTP data. A wired-wireless UEP enabled gateway will have to inspect every RTP header to make sure it selects the right point to start the UEP operation (or to discard those packets). From thereon, the incremental cost of looking at the payload at the start of UEP processing is going to be small. > Anyway, I would not like to go deep into details that are 3GPP specific. > This can be seen as a general QoS problem, where the packets will get a > different treatment depending on the destination UDP port number. Out of general interest, how might your multi-port proposal relate to the current AMR RTP payload proposal (also for 3GPP)? This uses a fixed RTP payload id and a field inside the codec payload to indicate the frame type (and size) present, plus signalling info. This would require codec payload inspection to have UEP applied, unless the gateway has an AMR specific path. Kind Regards - Orion. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street, London, WC1E 6BT, UK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Mon Oct 09 10:51:33 2000 From rem-conf-request@es.net Mon Oct 09 10:51:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ih2p-0004YX-00; Mon, 9 Oct 2000 10:48:59 -0700 Received: from mailhost.talarian.com (phobos.talarian.com) [207.5.32.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ih2o-0004Wj-00; Mon, 9 Oct 2000 10:48:58 -0700 Received: from VAIO (ta037.talarian.com [204.147.187.37]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA09955; Mon, 9 Oct 2000 10:47:12 -0700 (PDT) From: "Phil Farrar" To: "Henning Schulzrinne" Cc: "Phil Farrar" , "Gonzalo Camarillo" , Subject: RE: RTP sent to different ports Date: Mon, 9 Oct 2000 12:37:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <39E1B0B0.AE92B5CF@cs.columbia.edu> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Where is a good discussion of SIP? Thank You, Phil. > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > Henning Schulzrinne > Sent: Monday, October 09, 2000 6:49 AM > To: Gonzalo Camarillo > Cc: rem-conf@es.net > Subject: Re: RTP sent to different ports > > > If data is going to two ports, we have two different sessions. That's > what we have SIP (and SAP, RTSP, etc.) for, to allow mid-session changes > of transport destinations. For example, SIP re-INVITE will handle this > just fine. Among other things, adding this complexity will make > firewalls much more difficult. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > From rem-conf Mon Oct 09 11:29:25 2000 From rem-conf-request@es.net Mon Oct 09 11:29:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iheD-0006xX-00; Mon, 9 Oct 2000 11:27:37 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iheB-0006wl-00; Mon, 9 Oct 2000 11:27:36 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e99IRMt20291; Mon, 9 Oct 2000 20:27:23 +0200 (MEST) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id VAA15036; Mon, 9 Oct 2000 21:27:22 +0300 (EET DST) Received: from lmf.ericsson.se (E0080C77A56E4.lmf.ericsson.se [131.160.105.66]) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id VAA19697; Mon, 9 Oct 2000 21:27:13 +0300 (EETDST) Message-ID: <39E20DE1.37AC7C61@lmf.ericsson.se> Date: Mon, 09 Oct 2000 21:26:41 +0300 From: Gonzalo Camarillo Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Phil Farrar CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Check the SIP WG web page: http://www.ietf.org/html.charters/sip-charter.html To Subscribe: sip-request@lists.bell-labs.com In Body: subscribe Gonzalo Phil Farrar wrote: > > Where is a good discussion of SIP? > > Thank You, > > Phil. > > > -----Original Message----- > > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > > Henning Schulzrinne > > Sent: Monday, October 09, 2000 6:49 AM > > To: Gonzalo Camarillo > > Cc: rem-conf@es.net > > Subject: Re: RTP sent to different ports > > > > > > If data is going to two ports, we have two different sessions. That's > > what we have SIP (and SAP, RTSP, etc.) for, to allow mid-session changes > > of transport destinations. For example, SIP re-INVITE will handle this > > just fine. Among other things, adding this complexity will make > > firewalls much more difficult. > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 31 18 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From rem-conf Mon Oct 09 11:43:01 2000 From rem-conf-request@es.net Mon Oct 09 11:43:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ihs1-0000Sh-00; Mon, 9 Oct 2000 11:41:53 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ihs0-0000SV-00; Mon, 9 Oct 2000 11:41:52 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA00162; Mon, 9 Oct 2000 14:37:54 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39E21082.E3FA1AED@cs.columbia.edu> Date: Mon, 09 Oct 2000 14:37:54 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Phil Farrar CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Phil Farrar wrote: > > Where is a good discussion of SIP? http://www.cs.columbia.edu/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Oct 10 04:39:34 2000 From rem-conf-request@es.net Tue Oct 10 04:39:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ixcJ-0007DV-00; Tue, 10 Oct 2000 04:30:43 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ixcI-0007DH-00; Tue, 10 Oct 2000 04:30:42 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9ABUbt04681; Tue, 10 Oct 2000 13:30:38 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA03913; Tue, 10 Oct 2000 14:30:34 +0300 (EET DST) Message-ID: <39E2FDD1.3B34141A@lmf.ericsson.se> Date: Tue, 10 Oct 2000 14:30:25 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Orion Hodson CC: rem-conf@es.net Subject: Re: RTP sent to different ports References: <9636.971111322@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Orion Hodson wrote: > > Anyway, I would not like to go deep into details that are 3GPP specific. > > This can be seen as a general QoS problem, where the packets will get a > > different treatment depending on the destination UDP port number. > > Out of general interest, how might your multi-port proposal relate to > the current AMR RTP payload proposal (also for 3GPP)? This uses a > fixed RTP payload id and a field inside the codec payload to indicate > the frame type (and size) present, plus signalling info. This would > require codec payload inspection to have UEP applied, unless the > gateway has an AMR specific path. I think this is too specific to 3GPP, but here is the reason: The TFT is implemented in the GGSN. The TFT includes UDP port number, but does not include RTP payload type. Therefore, the GGSN will choose a GTP tunnel based on the destination UDP port number of the packet, not on the RTP payload type. The GTP tunnel is related to a specific radio bearer. Therefore, this packet has been asigned already a readio bearer. The GTP tunnel will go to the SGSN. The SGSN need to add the Iu header to the packet. This header contains UEP info. Then, the RNS will perform the actual UEP based on this info and any kind of header compression. Thus, it does not really matter to us whether the SGSN has to examine the payload or not. The GGSN has assigned previously the radio bearer. Actually, the GTP tunnel has been configured from the terminal with the codec information. Anyway, establishing several media streams solves the problem. Best regards, Thanks, Gonzalo > > Kind Regards > - Orion. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Networked Multimedia Research Group Tel: ++(0)171 419 3704 > Department of Computer Science Fax: ++(0)171 419 1397 > University College London, Gower Street, London, WC1E 6BT, UK > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From rem-conf Tue Oct 10 04:50:35 2000 From rem-conf-request@es.net Tue Oct 10 04:50:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ixuR-0000St-00; Tue, 10 Oct 2000 04:49:27 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ixuQ-0000SL-00; Tue, 10 Oct 2000 04:49:26 -0700 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9ABnMt20519; Tue, 10 Oct 2000 13:49:23 +0200 (MEST) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.148]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA05697; Tue, 10 Oct 2000 14:49:21 +0300 (EET DST) Message-ID: <39E30238.768B1EF9@lmf.ericsson.se> Date: Tue, 10 Oct 2000 14:49:12 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Orion Hodson , rem-conf@es.net Subject: Re: RTP sent to different ports References: <642.971088391@cs.ucl.ac.uk> <39E1E5E5.6C938FAB@lmf.ericsson.se> <39E1EB94.5033F153@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 Hi, Henning Schulzrinne wrote: > > Gonzalo Camarillo wrote: > > > > > > > Yes, that is one of the concerns people have - RTCP. Anyway, this 3rd > > party developed RTP library is just one among many examples. There are > > other scenarios where this feature might be useful. For instance, when > > the DTMF tones have to be received in a different device than the voice. > > That is solvable in a far cleaner manner by having two voice sessions, > one for regular audio and one for DTMF. The same applies to other > scenarios. To the end system, this is just like mixing several sources. > Implementing this gets you mixing and conferencing for free, so this is > a Good Thing. I am happy with this solution. However, I would like to signal it properly to the other end. That is, I receive the following description (in an INVITE for instance). v=0 o=John 289085535 289085535 IN IP4 first.example.com t=0 0 c=IN IP4 111.111.111.111 m=audio 20000 RTP/AVP 0 m=audio 20002 RTP/AVP 8 This means that I will receive two media streams. The first one on port number 20000 will use PCM u-law. The second one will arrive on port number 20002 and will be using PCM A-law. Actually I might receive media from both media streams simultaneously. One of the media streams might contain the voice of the singer and the other the background (public, guitars, ...) of the concert. I would like to differentiate this case from the following one. Now I want to have a conversation with somebody. I want just to transmit my voice. However, sometimes I will use PCM u-law and others PCM A-law. The receiver wants to receive (due to any reason) different codecs on different port numbers. As we have discussed previously in this thread, we will establish two media streams. But I want the receiver to know that I will never transmit simultaneouly in both media streams. I will transmit using one OR the other. I would like my session description to look like: v=0 o=John 289085535 289085535 IN IP4 first.example.com t=0 0 c=IN IP4 111.111.111.111 m=audio 20000 RTP/AVP 0 a=fid:1 m=audio 20002 RTP/AVP 8 a=fid:1 If an implementation does not understand the fid attribute it will try to mix the audio streams. Since one is "empty" all the time, doing this is not really a big deal. Thus, backwards compatibility is not a concern. Do you have any concerns with this approach? RTP and RTCP remain untouched. Actually, this discussion began being very much RTP related, but now we are moving to MMUSIC or SIP probably... Best regards, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From rem-conf Tue Oct 10 05:42:27 2000 From rem-conf-request@es.net Tue Oct 10 05:42:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iyi9-0002r7-00; Tue, 10 Oct 2000 05:40:49 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iyi5-0002p0-00; Tue, 10 Oct 2000 05:40:46 -0700 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G2700MDFRODD8@ss3000e.cselt.it> for rem-conf@es.net; Tue, 10 Oct 2000 14:21:49 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 14:25:27 +0200 Content-return: allowed Date: Tue, 10 Oct 2000 14:22:31 +0200 From: Franceschini Guido Subject: RE: what Mime type for MP4 files? To: Mikael Bourges-Sevenier , 'Dave Singer' Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <85077463E51D6A498C453073E167794039BD90@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I understand the concerns against 'application', but I mantain that 'video' is not appropriate either. IMHO we should select a name which is neutral to both audio and video, since MPEG-4 Systems is neutral. If 'application' is not good, what about a new one ('multimedia') ? Guido > ---------- > From: Dave Singer[SMTP:singer@apple.com] > Sent: Friday, October 06, 2000 2:49 AM > To: Mikael Bourges-Sevenier > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: what Mime type for MP4 files? > > At 4:41 PM -0700 10/5/00, Mikael Bourges-Sevenier wrote: > >Even if historically MPEG is more concerned with video, MPEG-4 deals with > so > >many different kinds of streams that I would prefer application/x-mp4 or > >x-mpeg4. > >In general as the BIFS stream defines a scene I would view it as a > special > >kind of application. > > The problems are that many people see "application" as a potential > threat to their security, and try to block it. Another problem is > that the mime type is supposed to indicate the kind of behavior at > the client: video indicates a time-based visual presentation, > whereas application can be (and often is) anything at all. > > The behavior of Mpeg4 is basically intended to be visual, unless an > audio-only session is wanted (whereupon the mime type audio/mpeg4 > should be used). In the view of this expert on mime naming, visual > is much to be preferred (and I agree). > > By the way, we are asking for an official registration, and therefore > there will be no "x-" at all. > > >Mikael Bourges-Sevenier > >iVAST Inc. > > > >> -----Original Message----- > >> From: owner-4on2andIP-sys@advent.ee.columbia.edu > >> [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave > >> Singer > >> Sent: Thursday, October 05, 2000 3:56 PM > >> To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > >> Subject: what Mime type for MP4 files? > >> > >> > >> a reply from the gurus at the IETF about the (e.g. HTTP) mime type > >> for MP4 files... > >> > >> >The top-level questions for MPEG are: > >> >a) do we belong under video, or application, for general MPEG-4 > >> >sessions? > >> > >> I strongly prefer video. > >> > >> >I prefer video, as it warns the terminal that a > >> >presentation is coming, it's parallel to MPEG, and I'm concerned that > >> >"application" may be treated more circumspectly by security software. > >> >But the Beijing MPEG meeting preferred application. > >> > >> Without knowing why I cannot comment, but historically such formats > have > >> gone under video. I expect there to be pushback if application is > >> attempted. > >> > >> >b) A taste question. Is the /mpeg4 to match the name of the standard > >> >(my preference, along with Steve Casner), or /mp4 to match the file > >> >format name? > >> > >> I personally prefer the former, but as you say, it is solely a matter > of > >> taste. > >> > >> >c) I'm fairly sure that we should say a lot more about security, as > >> >we allow embedded URLs, and have a Java layer that can deliver > >> >"applets". What sort of analysis is needed here? > >> > >> Basically, you need to note the issues. If I were you I'd take a look > >> at existing registrations of similar things and add what you need. > > > -- > > > David Singer > > > Apple Computer/QuickTime > > > > > -- > David Singer > Apple Computer/QuickTime > From rem-conf Tue Oct 10 06:10:11 2000 From rem-conf-request@es.net Tue Oct 10 06:10:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13iz8x-0004Ox-00; Tue, 10 Oct 2000 06:08:31 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13iz8v-0004Ky-00; Tue, 10 Oct 2000 06:08:30 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 15:08:49 +0200 Message-ID: From: Zvi Lifshitz To: Franceschini Guido , Mikael Bourges-Sevenier , 'Dave Singer' Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: what Mime type for MP4 files? Date: Tue, 10 Oct 2000 15:08:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Guido, when talking about mime types you need to turn the switch in your MPEG head. "video" in mime types means an audio/visual presentation, and that's what you do in MPEG-4. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972(54)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 The MPEGathon Developers Seminar, Brussels Airport Novotel, Brussels, November 15th, 2000 -----Original Message----- From: Franceschini Guido [SMTP:Guido.Franceschini@cselt.it] Sent: Tuesday, October 10, 2000 2:23 PM To: Mikael Bourges-Sevenier; 'Dave Singer' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: what Mime type for MP4 files? I understand the concerns against 'application', but I mantain that 'video' is not appropriate either. IMHO we should select a name which is neutral to both audio and video, since MPEG-4 Systems is neutral. If 'application' is not good, what about a new one ('multimedia') ? Guido > ---------- > From: Dave Singer[SMTP:singer@apple.com] > Sent: Friday, October 06, 2000 2:49 AM > To: Mikael Bourges-Sevenier > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: what Mime type for MP4 files? > > At 4:41 PM -0700 10/5/00, Mikael Bourges-Sevenier wrote: > >Even if historically MPEG is more concerned with video, MPEG-4 deals with > so > >many different kinds of streams that I would prefer application/x-mp4 or > >x-mpeg4. > >In general as the BIFS stream defines a scene I would view it as a > special > >kind of application. > > The problems are that many people see "application" as a potential > threat to their security, and try to block it. Another problem is > that the mime type is supposed to indicate the kind of behavior at > the client: video indicates a time-based visual presentation, > whereas application can be (and often is) anything at all. > > The behavior of Mpeg4 is basically intended to be visual, unless an > audio-only session is wanted (whereupon the mime type audio/mpeg4 > should be used). In the view of this expert on mime naming, visual > is much to be preferred (and I agree). > > By the way, we are asking for an official registration, and therefore > there will be no "x-" at all. > > >Mikael Bourges-Sevenier > >iVAST Inc. > > > >> -----Original Message----- > >> From: owner-4on2andIP-sys@advent.ee.columbia.edu > >> [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave > >> Singer > >> Sent: Thursday, October 05, 2000 3:56 PM > >> To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > >> Subject: what Mime type for MP4 files? > >> > >> > >> a reply from the gurus at the IETF about the (e.g. HTTP) mime type > >> for MP4 files... > >> > >> >The top-level questions for MPEG are: > >> >a) do we belong under video, or application, for general MPEG-4 > >> >sessions? > >> > >> I strongly prefer video. > >> > >> >I prefer video, as it warns the terminal that a > >> >presentation is coming, it's parallel to MPEG, and I'm concerned that > >> >"application" may be treated more circumspectly by security software. > >> >But the Beijing MPEG meeting preferred application. > >> > >> Without knowing why I cannot comment, but historically such formats > have > >> gone under video. I expect there to be pushback if application is > >> attempted. > >> > >> >b) A taste question. Is the /mpeg4 to match the name of the standard > >> >(my preference, along with Steve Casner), or /mp4 to match the file > >> >format name? > >> > >> I personally prefer the former, but as you say, it is solely a matter > of > >> taste. > >> > >> >c) I'm fairly sure that we should say a lot more about security, as > >> >we allow embedded URLs, and have a Java layer that can deliver > >> >"applets". What sort of analysis is needed here? > >> > >> Basically, you need to note the issues. If I were you I'd take a look > >> at existing registrations of similar things and add what you need. > > > -- > > > David Singer > > > Apple Computer/QuickTime > > > > > -- > David Singer > Apple Computer/QuickTime > From rem-conf Tue Oct 10 06:39:15 2000 From rem-conf-request@es.net Tue Oct 10 06:39:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13izbN-0005uQ-00; Tue, 10 Oct 2000 06:37:53 -0700 Received: from (purple.east.isi.edu) [38.218.19.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13izbM-0005u4-00; Tue, 10 Oct 2000 06:37:52 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id JAA01852; Tue, 10 Oct 2000 09:38:49 -0400 Message-Id: <200010101338.JAA01852@purple.east.isi.edu> To: Franceschini Guido cc: Mikael Bourges-Sevenier , "'Dave Singer'" , rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu, mankin@isi.edu Subject: Re: what Mime type for MP4 files? In-Reply-To: Message from Franceschini Guido of "Tue, 10 Oct 2000 14:22:31 +0200." <85077463E51D6A498C453073E167794039BD90@exc2k02.cselt.it> Date: Tue, 10 Oct 2000 09:38:49 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Franceschini Guido writes: >I understand the concerns against 'application', but I mantain that >'video' is not appropriate either. IMHO we should select a name which is >neutral to both audio and video, since MPEG-4 Systems is neutral. If >'application' is not good, what about a new one ('multimedia') ? A new top level "multimedia" will not be assigned. The existing approach of registering both video/mp4 and audio/mp4 would seem to be appropriate. Colin From rem-conf Tue Oct 10 06:49:22 2000 From rem-conf-request@es.net Tue Oct 10 06:49:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13izkY-0006w2-00; Tue, 10 Oct 2000 06:47:22 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13izkW-0006rS-00; Tue, 10 Oct 2000 06:47:20 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39E21F7F0000F121 for rem-conf@es.net; Tue, 10 Oct 2000 15:43:31 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39E2A5830000EEE2 for rem-conf@es.net; Tue, 10 Oct 2000 15:42:23 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Tue, 10 Oct 2000 15:42:23 +0200 (Paris, Madrid (heure d'été)) X-Internal-ID: 39CA6F210000A767 Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Tue, 10 Oct 2000 15:47:41 +0200 Received: from thomcast.thomson-csf.com ([178.3.1.228]) by minos.snmrennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.62) with ESMTP id 405; Tue, 10 Oct 2000 15:31:44 +0200 Message-ID: <39E31D3D.E296A29A@thomcast.thomson-csf.com> Date: Tue, 10 Oct 2000 15:44:29 +0200 From: "Pierre Clement" X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Zvi Lifshitz CC: 'Dave Singer' , CURET Dominique FTRD/DMI/REN , rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> , CURET Dominique FTRD/DMI , "jan.vandermeer@philips.com" , 'Olivier Avaro' Subject: Re: Types of MPEG-4 streams over IP References: <01C030AC.5E240160.zvil@csi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Zvi, Dave and Jan, As far as the dynamic nature of the flexmux PDU and consequently, of the MuxCodeTable, is concerned, I guess there is nothing that precludes a change on the fly. Nevertheless, and from an implementation point of view, it is more manageable to stream flexmux whose multiplex nature does not change on the fly and to announce the flexmux configuration by up-front signalling. For me, this up-front signalling should me made of 1/ the Stream Map Table (i.e, which ES_ID(s) in which flexmux channel(s)) and 2/ the MuxCodeTable, to tell the deflexmuxer where to look at in the flexmux PDU to pickup in the right place the right FMC. Let's take the case of a unicast scenario where a player requires an additionnal ES which is not yet present in any of the incoming flexmux streams. That case implies to send 1/ an updaded version of the SMT so that the deflexmuxer knows where to look at to retrieve the new ES (i.e, in which flexmux channel), and 2/ an updated version of the MuxCodeTable (i.e, where to look at the FMC in the flexmux PDU). For this unicast scenario, both the SMT and the MuxCodeTable update may be sent thanks to an out-of band mean, like a SDP announcement in a RTSP message. For a multicast scenario, SAP/SDP may be used to send the upgrades of the SMT and/or MuxCodeTable, which is slow (see Colin's remark, one announcement every tens of minutes). But then, as Zvi said, SMT needs still to be sent by out-of band mean. In case in band signalling be used for the MuxCodeTable, that implies to strengthen reliability by cyclic retransmission, which would be detrimental for bandwidth. Furthermore and for an application where both the SMT and the MuxCodeTable would change, one should be carefull so that the upgraded SMT arrives at the deflexmuxer before the MuxCodeTable Update takes place in the flexmux stream. Pierre > [Dave Singer:] My understanding is that the multiplex nature of the stream does not change, and that therefore reliable up-front signalling is best. If this ins't true, the flexmux packet format may need some way to update the muxcodetable, but I hope that isn't true, because of reliability concerns. > > > [Zvi:] > > Recalling Jan remarks about muxcodetable, I think he was right. Since the > table can change on the fly, affecting subsequent FlexMux PDUs, it may be > necessary to send it in band. So the question is, do we need to have also > an out-of-band MuxCodeTable signaling? IMO not. > > Just to make sure, we are not talking about SMT, which should always be > carried out of band, right? > From rem-conf Tue Oct 10 07:55:35 2000 From rem-conf-request@es.net Tue Oct 10 07:55:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13j0mJ-0001wl-00; Tue, 10 Oct 2000 07:53:15 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13j0mI-0001wb-00; Tue, 10 Oct 2000 07:53:14 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id XAA09019 for ; Tue, 10 Oct 2000 23:53:12 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id XAA12760; Tue, 10 Oct 2000 23:53:12 +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 XAA24420; Tue, 10 Oct 2000 23:53:11 +0900 (JST) Received: from ave (kwa0111.mobile.toshiba.co.jp [133.120.199.27]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id XAA88132; Tue, 10 Oct 2000 23:53:09 +0900 (JST) Message-ID: <01b201c032c9$db1cffe0$1bc77885@ave> From: "Yoshihiro Kikuchi" To: "IETF AVT" Cc: "Yoshihiro Kikuchi" Subject: items to be reflected on the last I-D Date: Tue, 10 Oct 2000 23:53:29 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, Thank you very much for the comments on the MPEG-4 Audio/Visual RTP Internet-Draft. The following is the items to be reflected on the last text of the Internet-Draft that the authors are considering to reflect comments raised. 1) RTP payload format for the short video header. (section 3) "When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations)." 2) video MIME/SDP parameter "config" (section 5.1) "config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. ....................." 3) video timestamp (section 3.1) The authors got a suggestion to change video timestamp definition from "composition time" to an ordinary RTP timestamp definition (capture time). This change is necessary to align with other RTP payload formats than MPEG-4 video. Note that audio timestamp has already be changed to "capture time". The following is a definition the authors are considering: "Timestamp: The timestamp indicates the sampling instance of the VOP contained in the RTP packet. A constant offset, which is random, is added for security reasons. - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the timestamp of the next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the timestamp of the immediately preceding VOP in the coding order is used." And delete the definition of "RTP timestamps in RTCP SR packets". If there is no comment, the authors will provide the last I-D to complete the specification with reflecting these items. Best regards, Yoshihhiro Kikuchi and authos of the Internet-Draft ---- 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 1267 From rem-conf Tue Oct 10 09:18:58 2000 From rem-conf-request@es.net Tue Oct 10 09:18:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13j24n-000591-00; Tue, 10 Oct 2000 09:16:25 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13j24m-000580-00; Tue, 10 Oct 2000 09:16:24 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JV60R7CVKMEVTAGS@GI.COM> for rem-conf@es.net; Tue, 10 Oct 2000 09:15:16 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 09:14:40 -0400 Content-return: allowed Date: Tue, 10 Oct 2000 12:18:05 -0400 From: "Luthra, Ajay (SD-EX)" Subject: RE: items to be reflected on the last I-D To: 'Yoshihiro Kikuchi' , IETF AVT Message-id: <973597126BDDD11197AA00805FA7EBC903421762@ntas0026.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-2022-jp" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Kikuchi-san, This is to get a clarification. You state, " ... change video timestamp definition from "composition time" to an ordinary RTP timestamp definition (capture time) ". Does it mean removing the Composition TS and replacing it with Capture Time Stamp or re-defining Composition TS as Capture TS? As I understood, the suggestion is to replace Composition TS with Capture TS. Will this create more incompatibility with the current WG-11 effort of developing standards on how to carry different MPEG4 streams over RTP? Thanks. With regards, Ajay -----Original Message----- From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] Sent: Tuesday, October 10, 2000 7:53 AM To: IETF AVT Cc: Yoshihiro Kikuchi Subject: items to be reflected on the last I-D Dear all, Thank you very much for the comments on the MPEG-4 Audio/Visual RTP Internet-Draft. The following is the items to be reflected on the last text of the Internet-Draft that the authors are considering to reflect comments raised. 1) RTP payload format for the short video header. (section 3) "When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older implementations)." 2) video MIME/SDP parameter "config" (section 5.1) "config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. ....................." 3) video timestamp (section 3.1) The authors got a suggestion to change video timestamp definition from "composition time" to an ordinary RTP timestamp definition (capture time). This change is necessary to align with other RTP payload formats than MPEG-4 video. Note that audio timestamp has already be changed to "capture time". The following is a definition the authors are considering: "Timestamp: The timestamp indicates the sampling instance of the VOP contained in the RTP packet. A constant offset, which is random, is added for security reasons. - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the timestamp of the next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the timestamp of the immediately preceding VOP in the coding order is used." And delete the definition of "RTP timestamps in RTCP SR packets". If there is no comment, the authors will provide the last I-D to complete the specification with reflecting these items. Best regards, Yoshihhiro Kikuchi and authos of the Internet-Draft ---- 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 1267 From rem-conf Tue Oct 10 10:03:28 2000 From rem-conf-request@es.net Tue Oct 10 10:03:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13j2mz-0006qa-00; Tue, 10 Oct 2000 10:02:05 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13j2mx-0006qQ-00; Tue, 10 Oct 2000 10:02:04 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id CAA22822; Wed, 11 Oct 2000 02:02:01 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id CAA28251; Wed, 11 Oct 2000 02:02:01 +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 CAA06859; Wed, 11 Oct 2000 02:02:01 +0900 (JST) Received: from ave (kwa0111.mobile.toshiba.co.jp [133.120.199.27]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id CAA91850; Wed, 11 Oct 2000 02:01:58 +0900 (JST) Message-ID: <031801c032db$da397880$1bc77885@ave> From: "Yoshihiro Kikuchi" To: "Luthra, Ajay (SD-EX)" , "IETF AVT" Cc: "Yoshihiro Kikuchi" References: <973597126BDDD11197AA00805FA7EBC903421762@ntas0026.gi.com> Subject: Re: items to be reflected on the last I-D Date: Wed, 11 Oct 2000 02:02:18 +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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Ajay, I expect better explanations from IETF experts, but my understanding on this change is that it is necessary for the synchronization with other audio/video codecs than MPEG-4 using "capture time" in their RTP payload formats. Since it is an important role of this RTP payload format to align with non-MPEG-4 codecs, this change seems reasonable to me. Please note again that the audio timestamp has been changed to a capture timestamp. Best regards, Yoshihiro ----- Original Message ----- From: Luthra, Ajay (SD-EX) To: 'Yoshihiro Kikuchi' ; IETF AVT Sent: Wednesday, October 11, 2000 1:18 AM Subject: RE: items to be reflected on the last I-D > Kikuchi-san, > This is to get a clarification. You state, " ... change video timestamp > definition from > "composition time" to an ordinary RTP timestamp definition (capture time) ". > Does it mean removing the Composition TS and replacing it with Capture Time > Stamp or re-defining Composition TS as Capture TS? As I understood, the > suggestion is to replace Composition TS with Capture TS. Will this create > more incompatibility with the current WG-11 effort of developing standards > on how to carry different MPEG4 streams over RTP? Thanks. > > With regards, > Ajay > > -----Original Message----- > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 10, 2000 7:53 AM > To: IETF AVT > Cc: Yoshihiro Kikuchi > Subject: items to be reflected on the last I-D > > > Dear all, > > Thank you very much for the comments on the MPEG-4 Audio/Visual RTP > Internet-Draft. > > The following is the items to be reflected on the last text of the > Internet-Draft that the authors are considering to reflect comments raised. > > 1) RTP payload format for the short video header. (section 3) > "When the short video header mode is used, the RTP payload format > for H.263 SHOULD be used (the format defined in RFC 2429 is > RECOMMENDED, but the RFC 2190 format MAY be used for compatibility > with older implementations)." > > 2) video MIME/SDP parameter "config" (section 5.1) > "config: This parameter SHALL be used to indicate the configuration > of the corresponding MPEG-4 visual bitstream. It SHALL NOT be > used to indicate the codec capability in the capability exchange > procedure. > ....................." > > 3) video timestamp (section 3.1) > The authors got a suggestion to change video timestamp definition from > "composition time" to an ordinary RTP timestamp definition (capture time). > This change is necessary to align with other RTP payload formats than MPEG-4 > video. Note that audio timestamp has already be changed to "capture > time". The following is a definition the authors are considering: > "Timestamp: The timestamp indicates the sampling instance > of the VOP contained in the RTP packet. A constant offset, > which is random, is added for security reasons. > - When multiple VOPs are carried in the same RTP packet, the timestamp > indicates the earliest of the VOP times within the VOPs > carried in the RTP packet. Timestamp information of the rest of the > VOPs are derived from the timestamp fields in the VOP header > (modulo_time_base and vop_time_increment). > - If the RTP packet contains only configuration information and/or > Group_of_VideoObjectPlane() fields, the timestamp of the next > VOP in the coding order is used. > - If the RTP packet contains only visual_object_sequence_end_code > information, the timestamp of the immediately preceding VOP in > the coding order is used." > And delete the definition of "RTP timestamps in RTCP SR packets". > > > If there is no comment, the authors will provide the last I-D to complete > the specification with reflecting these items. > > Best regards, > Yoshihhiro Kikuchi > and authos of the Internet-Draft > > ---- > 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 1267 > > > From rem-conf Tue Oct 10 10:38:49 2000 From rem-conf-request@es.net Tue Oct 10 10:38:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13j3Kg-0000q6-00; Tue, 10 Oct 2000 10:36:54 -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 13j3Kf-0000pu-00; Tue, 10 Oct 2000 10:36:53 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 818681E06A; Tue, 10 Oct 2000 13:36:49 -0400 (EDT) Received: from armada1 ([135.207.129.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id NAA19292; Tue, 10 Oct 2000 13:36:47 -0400 (EDT) Message-ID: <001101c032e0$aa021460$6c81cf87@attnjs.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Yoshihiro Kikuchi" , "Luthra, Ajay (SD-EX)" , "IETF AVT" Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <973597126BDDD11197AA00805FA7EBC903421762@ntas0026.gi.com> <031801c032db$da397880$1bc77885@ave> Subject: Re: items to be reflected on the last I-D Date: Tue, 10 Oct 2000 13:36:15 -0400 Organization: AT&T Labs - Research 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't think that using the "capture time" or the "composition time" will make any difference on synchronization with other payloads as long as the timing relation reported in the RTCP sender reports gets established correctly. All RTP payload formats defined so far, except our MPEG-4 SL payload format, draft-ietf-avt-rtp-mpeg4-03, use the "capture time." So, choosing the "capture time" for MPEG4 ES payload formats will be consistent with this convention. The reason for using the "composition time" in the SL payload format is to eliminate the redundancy between the RTP and the SL headers. The draft explains how to establish the timing relations in the RTCP sender reports for synchronization with other payload formats under this choice. Clearly, the redundancy argument does not apply to the ES payload formats. ___________________________________________ M. Reha Civanlar AT&T Labs - Research A54D04, 200 Laurel Ave., Middletown, NJ 07748, USA Ph: +1 732 420 9170 civanlar@research.att.com http://www.research.att.com/info/mrc ----- Original Message ----- From: "Yoshihiro Kikuchi" To: "Luthra, Ajay (SD-EX)" ; "IETF AVT" Cc: "Yoshihiro Kikuchi" Sent: Tuesday, October 10, 2000 1:02 PM Subject: Re: items to be reflected on the last I-D > Dear Ajay, > > I expect better explanations from IETF experts, but my understanding on this > change is that it is necessary for the synchronization with other > audio/video codecs than MPEG-4 using "capture time" in their RTP payload > formats. Since it is an important role of this RTP payload format to align > with non-MPEG-4 codecs, this change seems reasonable to me. Please note > again that the audio timestamp has been changed to a capture timestamp. > > Best regards, > Yoshihiro > > ----- Original Message ----- > From: Luthra, Ajay (SD-EX) > To: 'Yoshihiro Kikuchi' ; IETF AVT > > Sent: Wednesday, October 11, 2000 1:18 AM > Subject: RE: items to be reflected on the last I-D > > > > Kikuchi-san, > > This is to get a clarification. You state, " ... change video timestamp > > definition from > > "composition time" to an ordinary RTP timestamp definition (capture time) > ". > > Does it mean removing the Composition TS and replacing it with Capture > Time > > Stamp or re-defining Composition TS as Capture TS? As I understood, the > > suggestion is to replace Composition TS with Capture TS. Will this create > > more incompatibility with the current WG-11 effort of developing standards > > on how to carry different MPEG4 streams over RTP? Thanks. > > > > With regards, > > Ajay > > > > -----Original Message----- > > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > > Sent: Tuesday, October 10, 2000 7:53 AM > > To: IETF AVT > > Cc: Yoshihiro Kikuchi > > Subject: items to be reflected on the last I-D > > > > > > Dear all, > > > > Thank you very much for the comments on the MPEG-4 Audio/Visual RTP > > Internet-Draft. > > > > The following is the items to be reflected on the last text of the > > Internet-Draft that the authors are considering to reflect comments > raised. > > > > 1) RTP payload format for the short video header. (section 3) > > "When the short video header mode is used, the RTP payload format > > for H.263 SHOULD be used (the format defined in RFC 2429 is > > RECOMMENDED, but the RFC 2190 format MAY be used for compatibility > > with older implementations)." > > > > 2) video MIME/SDP parameter "config" (section 5.1) > > "config: This parameter SHALL be used to indicate the configuration > > of the corresponding MPEG-4 visual bitstream. It SHALL NOT be > > used to indicate the codec capability in the capability exchange > > procedure. > > ....................." > > > > 3) video timestamp (section 3.1) > > The authors got a suggestion to change video timestamp definition from > > "composition time" to an ordinary RTP timestamp definition (capture time). > > This change is necessary to align with other RTP payload formats than > MPEG-4 > > video. Note that audio timestamp has already be changed to "capture > > time". The following is a definition the authors are considering: > > "Timestamp: The timestamp indicates the sampling instance > > of the VOP contained in the RTP packet. A constant offset, > > which is random, is added for security reasons. > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the VOP times within the VOPs > > carried in the RTP packet. Timestamp information of the rest of the > > VOPs are derived from the timestamp fields in the VOP header > > (modulo_time_base and vop_time_increment). > > - If the RTP packet contains only configuration information and/or > > Group_of_VideoObjectPlane() fields, the timestamp of the next > > VOP in the coding order is used. > > - If the RTP packet contains only visual_object_sequence_end_code > > information, the timestamp of the immediately preceding VOP in > > the coding order is used." > > And delete the definition of "RTP timestamps in RTCP SR packets". > > > > > > If there is no comment, the authors will provide the last I-D to complete > > the specification with reflecting these items. > > > > Best regards, > > Yoshihhiro Kikuchi > > and authos of the Internet-Draft > > > > ---- > > 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 1267 > > > > > > > > > > From rem-conf Tue Oct 10 13:33:57 2000 From rem-conf-request@es.net Tue Oct 10 13:33:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13j61a-0006qc-00; Tue, 10 Oct 2000 13:29:22 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13j61Z-0006qR-00; Tue, 10 Oct 2000 13:29:21 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id WAA02065; Tue, 10 Oct 2000 22:29:19 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma002063; Tue, 10 Oct 00 22:29:19 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id WAA06116; Tue, 10 Oct 2000 22:29:18 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id WAA00445; Tue, 10 Oct 2000 22:29:18 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014727710; Tue, 10 Oct 2000 22:31:11 +0200 To: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: Mime types for "generic MPEG" RTP payloads Message-ID: <0056890014727710000002L902*@MHS> Date: Tue, 10 Oct 2000 22:31:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/10/00 23:27:32" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, The Civanlar et al draft defines an RTP payload type for carriage of "generic MPEG-4 data" over RTP. When using this method, if I understand= it correctly, the RTP payload data is signaled as "generic MPEG-4 data" an= d a receiver has to go into the object descriptors to find out whether the = data represents for example MPEG-4 audio, video or graphics. Such method is clean from an MPEG-4 system point of view, but is not op= timal when compatibility with non-MPEG-4 system receivers is required. For example, consider a full fledge MPEG-4 system application that composes= several MPEG-4 audio, video and graphics streams within one beautiful presentation. Of course non-MPEG-4 system receivers are not capable to = show such presentation. Nevertheless it may be of interest to present a sing= le audio and a single video from such presentation on a non-MPEG-4 receive= r. However, the non-MPEG-4 receiver will not be capable to understand such= payload format. Therefore I have the following proposal. Rather than defining one "gene= ric MPEG-4" mime type, we specify elementary stream specific mime types wit= hin the RTP payload specification for "generic MEG-4 data" (note that the M= PEG-4 system signaling remains unchanged). For example : - MP4VIDEO for MPEG-4 video streams - MP4AUDIO for MPEG-4 audio streams - MP4BIFS for MPEG-4 graphics streams - MP4IPMP for MPEG-4 IPMP streams - MP4JAVA for MPEG-4 Java streams - MP4OD for MPEG-4 Object descriptor streams - MP4CR for MPEG-4 clock reference streams - MP4SCENE for MPEG-4 scene description streams - MP4OCI for MPEG-4 object content information streams - MP4FLEXMUX for MPEG-4 FlexMux streams The MPEG-4 system data should be in separate field preceded by the leng= th byte as discussed in an earlier thread. In this way non-MPEG-4 system receivers can skip the MPEG-4 system data without any MPEG-4 system knowledge. Signaling this byte by an SDP attribute will allow full compatible services, when appropriate. Any comment ? Kind regards, Jan ************************ Jan van der Meer Philips - Digital Networks Building OAN-4 P.O. Box 80002 5600 JB Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 Email jan.vandermeer@philips.com ************************ = From rem-conf Tue Oct 10 18:01:06 2000 From rem-conf-request@es.net Tue Oct 10 18:01:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jADr-0006jk-00; Tue, 10 Oct 2000 17:58:19 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13jADq-0006jS-00; Tue, 10 Oct 2000 17:58:18 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id RAA07708; Tue, 10 Oct 2000 17:40:35 -0700 Message-Id: <3.0.3.32.20001010093000.00aa1670@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 10 Oct 2000 09:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/11 The Making of GUI Bloopers -- Jeff Johnson, UI Wizards, Inc. 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 The Making of GUI Bloopers Wednesday October 11, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Jeff Johnson UI Wizards, Inc. Jeff Johnson, user-interface consultant and author of the new book "GUI Bloopers: DON'Ts and DOs for Software Developers and Web Designers" (Morgan-Kaufmann), will describe why he began collecting GUI design bloopers several years ago, why he decided to publish them in a book, how the bloopers are organized and presented, and how the book was usability tested. His talk will be illustrated with many examples of bloopers. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Oct 10 21:59:15 2000 From rem-conf-request@es.net Tue Oct 10 21:59:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jDv5-000460-00; Tue, 10 Oct 2000 21:55:11 -0700 Received: from (jtiempo.jardinesdeltiempo.com) [200.23.18.107] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jDuo-00044s-00; Tue, 10 Oct 2000 21:54:54 -0700 Received: from anthony (sdn-ar-001txmidlP247.dialsprint.net [206.133.91.137]) by jtiempo.jardinesdeltiempo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4TA4PGMC; Tue, 10 Oct 2000 23:52:17 -0600 To: ttrr@apexmail.com Bcc: reltrich@earthlink.net, reluctance@precludingc.net, reluctance@reptilian.com, reluctant33rpm@hotmail.com, reluctantl@hotmail.com, reluctantly@netcom.com, reluctg@reluctantgourmet.com, relumined@groose.com, relumined@theriodich.net, relves@island.net, relvin@concentric.net, relwam@wamplerrealty.com, relwell@cts.com, relwell@earthlink.com, relwilson@sterling.com, relwood@dechert.com, rely@gte.net, relyas@mediaone.net, relyc@hotmail.com, relyea@msn.com, relyea@prodigy.net, relyea@usa.net, relying@originals.com, relynch@msn.com, relyon@earthlink.com, relyons@mindspring.com, relyuc@worldnet.att.net, rem-conf-request@es.net, rem-conf@es.net, rem.abb@mailcity.com, rem.comnation@genie.c, rem44@prodigy.net, rem@att.net, rem@citlink.net, rem@classroom.net, rem@delphi.com, rem@design-deco.com, rem@dol.net, rem@end.of.the.world From: Subject: Investor and Stock Holder . . . .PLEASE READ TODAY, always picking winners content-length: 11215 Message-Id: Date: Tue, 10 Oct 2000 21:54:54 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list STOCK PROFILER FOR THURSDAY, OCTOBER 12, 2000 Early Release to Group Leaders, Newsletter Owners & Members Only! STRONG BUY RECOMMENDATION: CMEC COMMERCIAL CONCEPTS INC. CMEC Closed at .23 on Tuesday, October 10 Rumors of Huge News of Additional School Board and Hospital Contracts ! VOLUME ALERT - CMEC ACCUMULATION IS UNDERWAY CMEC INVESTMENT RELATIONS IS MAILING OUT SPECIAL I.R. PACKAGE TO THOUSANDS OF BROKERS PLUS STOCKHOLDERS, NEWSLETTERS, STOCK MAGAZINES AND INVESTMENT INSTITUTIONS. NEWS Released September 27 by CMEC CONFIRMS CONTRACTS with SCHOOL BOARDS, HOSPITALS, and MICRON COMPUTER Please post this message to all your Clubs and other sites... as well as send it to your email and icq lists...thanks...suzi.... 3 Stock Sites Pick This One For Big Rise Next Week, Plus 4 Other Big Groups Start Heavy Buying of This Stock as they feel it is VERY UNDERVALUED! Picked by: 3bagger Yankees in Four Hot Stocks Stock Profile THEIR TARGET FOR CMEC is $1.25 by October 31, 2000 STRONG BUY RECOMMENDATION CMEC Commercial Concepts Inc. CMEC Year High was $ 5.62 Website at: http://www.cmecut.com NewsReleases at: http://biz.yahoo.com/prnews/000907/ut_commerc.html ---------------------------------------- Wednesday September 27, 2:20 pm Eastern Time Press Release SOURCE: Commercial Concepts, Inc. Commercial Concepts Announces Successful Completion of Second Tranche of Funding SALT LAKE CITY, Sept. 27 /PRNewswire/ -- Commercial Concepts, Inc. (OTC Bulletin Board: CMEC - news; ``CCI'') announced today the successful funding of a $250,000, 6% convertible note due September 8, 2003 to a private investment group. This note is the second tranche of the previously announced $6.5 million dollar equity line of credit that has been secured by the Company. George Richards, President and CEO of Commercial Concepts, commented: ``This ongoing support allows us to concentrate on finalizing our product development and commercial rollout, thereby expediting revenue generation. This funding is a vote of confidence in the Company and its products from a sophisticated international investment organization.'' The Company has moved its Web site to LMKI, Inc., a DSL-based ISP. The Company's Web site (www.cmecut.com) and e-mail had been inoperative for approximately two weeks. The initial cause was a sustained service breakdown by the Company's previous internet service provider (ISP). The Company's e-mail and Web site are now fully functioning. Additionally, the Company has been made aware that some of its shareholders did not receive their proxy ballots with their copies of the annual report and annual shareholders meeting proxy statement. Because some mailings to shareholders were sent too late for full participation in the shareholders' meeting held September 5, 2000, the Company kept open until October 16, 2000 the tally for proxy votes. Unfortunately, the distribution agent for Commercial Concepts elected to withhold the proxy ballot and insert an ``Information Only'' notice in its place. Commercial Concepts, Inc., has notified the distribution agent of its error and a proxy ballot is being mailed to shareholders for their vote. Commercial Concepts, Inc. The Company's products and services are based on Internet-related database driven software. The three principal products include CCI Picture Base©, The Wave Network© and X-Card©. Picture Base is a patent pending medical imaging software that captures and stores a variety of images. The Wave Network is a customized screen saver that disseminates host information while generating revenues through local and national advertising. These revenues are shared between the host and the Company. The Company is targeting three distinct host markets: non-profit organizations (schools, charities, and community groups), corporations (that have large intra-company communication needs), and commercial (sports franchises, theme parks, fan clubs). X-Card is an affordable ``multi media brochure'' delivered on a shaped compact disc (CD). Additional information is available at www.cmecut.com. Those interested in receiving e-mails of future press releases can register on the Company's Web site. ------------------------------------- CATCH CMEC AT .23 AS CMEC "WAVE SCREENS" SOFTWARE MAY BE ON EVERY COMPUTER SCREEN IN EVERY SCHOOL AROUND THE WORLD AFTER THE NEWS THAT THE DAVIS COUNTY SCHOOL BOARD HAS APPROVED CMEC "WAVE SCREENS" FOR ALL THEIR SCHOOLS' COMPUTERS PLUS CMEC'S MEDICAL IMAGING SOFTWARE MAY BE IN EVERY HOSPITAL AND MEDICAL CENTRE AROUND THE WORLD AS NEWS OF THE HOSPITAL CONTRACTS REACH ALL THE ADMINISTRATORS OF ALL THE HOSPITALS AND CLINICS AROUND THE WORLD. THIS .25 STOCK WILL START TO SKYROCKET AS THESE NEWSRELEASES ARE STARTING TO BE COPIED AND NOTICED BY THE HEADS OF MOST OF THE MEDICAL AND EDUCATION FIELDS AROUND THE WORLD. CMEC'S most recent newsrelease is causing quite a flood of calls to CMEC offices for contract proposals from all over the world by Hospitals and School Boards. Strong Buy Recommendation CMEC otc-bb CMEC was at Year High of $ 5.62 before Product Line was changed from just Y2K Software! CMEC has Contracts with MICRON, HOSPITALS and School Boards. There are Hundreds of Thousands of School Boards Around the World With Tens of Millions of Computers that are Immediate Potential Clients FOR CMEC "Wave Screens" This Product Alone Could Mean Hundreds of Millions in Revenue For CMEC Now that Davis County Utah School Board has approved CMEC "WAVE SCREENS" FIRST MAJOR CONTRACT!! ------------------------ DAVIS COUNTY SCHOOL BOARD IN UTAH APPROVES CMEC "WAVE SCREENS" CONTRACT FOR APPROX. 30,000 SCREENS! --------------------------------------------- Thursday September 7, 8:31 am Eastern Time Press Release SOURCE: Commercial Concepts, Inc. Commercial Concepts Receives Davis County School District's Approval on Contract for Wave Screens Board of Education Approves Screen Saver for Use in Schools SALT LAKE CITY, Sept. 7 /PRNewswire/ -- Commercial Concepts, Inc. (OTC BB: CMEC) today announced approval by the Board of Education of the Davis County School District of a standardized contract for the use of Wave Screens in each of the 74 schools in its district. Davis County Schools is the third largest school district in the State of Utah, with more than 58,000 students. The approval calls for a five-year contract, with a non-compete agreement and it includes a 50-50 revenue sharing agreement for local and national advertising. George Richards, President and CEO of Commercial Concepts, commented, ``This approval allows us to aggressively roll out the Wave Screen Program in Northern Utah. Davis County will be the role model for our National Campaign.'' As was previously announced, Micron Commercial Computer Systems, a subsidiary of Micron Electronics can provide hardware to the school district in exchange for a percentage of their advertising revenues. Commercial Concepts The Company's products and services are based on Internet-related database driven software. The three principal products include CCI Picture Base©, The Wave Network© and X-Card©. Picture Base is a patent pending medical imaging software that captures and stores a variety of images. The Wave Network is a customized screen saver that disseminates host information while generating revenues through local and national advertising. These revenues are shared between the host and the Company. The Company is targeting three distinct host markets: non-profit organizations (schools, charities, and community groups), corporations (that have large intra-company communication needs), and commercial (sports franchises, theme parks, fan clubs). X-Card is an affordable ``multimedia brochure'' delivered on a shaped compact disc (CD). Additional information is available at www.cmecut.com . Those interested in receiving e-mails of future press releases can register on the Company's Web site. This press release contains ``forward-looking statements'' within the meaning of Private Securities Litigation Reform Act of 1995, Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of the 1934. These forward-looking statements can be identified by the use of forward-looking terminology such as, ``This approval allows us to aggressively roll out the Wave Screen Program.'' Actual events or performance involve risks and uncertainties that could differ materially from those anticipated in such forward-looking statements. Factors that could cause actual results to differ materially from those projected in forward-looking statements include competition, the management of the Company's growth and the ability to deliver new products to market on time. Such forward-looking statements are subject to other risks and uncertainties, which are detailed in the Company's filings with the Securities and Exchange Commission. SOURCE: Commercial Concepts, Inc. -------------------------------------------------- CMEC "WAVE SCREEN" REVENUES ESTIMATE: 3200 in just 1 month from 3 schools. using those numbers for 74 schools I come up with $720,000 in revenue in just 1 yr for this account only on a 50/50 split. not bad numbers. Companies would pay BIG bucks to get their banner adds onto the screens in side of schools and also in large and small companies. 90 local advertisers and 90 national advertisers per screen (maximum capacity) Future Plans include *Shopping Program *Coupon Program -------------------------- DISCLAIMER: This is not a solicitation to buy or sell any stocks mentioned herein, and all information provided is believed to be accurate to the best of our knowledge. Stock Profiler staff & management may hold, buy or sell any of the securities mentioned herein. Always do your own research and consult an investment professional whenever buying stocks, securities or investments of any type. These are our stated opinions. Stock Profiler Staff and management may hold, buy and sell positions in some or all of the stocks mentioned in our newsletters. You have requested and have been added to our opt-in list for our newsletter. If this has reached you in error, please type in "remove Stock Profiler " in the subject and email to wwss1@excite.com and you will be removed from our list. For Free Trial or To Add any other of your other email addresses please send to wwss1@excite.com with the words "free trial to Stock Profiler " ---------------------------------------------------------------------------------------------------------------------------------------------------------------- UPDATE: PABN PAN AMERICAN BANK Best Penny Stock Buy at .009 STRONG BUY DVDT DIGITAL VIDEO DISPLAY TECH....STRONG BUY Closed at .25 Monday, October 9 Newsrelease of their $36 Million dollar contract. Rumors are out today of More Major News to be Released During the Week!! ----------- From rem-conf Wed Oct 11 03:03:12 2000 From rem-conf-request@es.net Wed Oct 11 03:03:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jIey-00044O-00; Wed, 11 Oct 2000 02:58:52 -0700 Received: from (990.net) [202.102.13.160] by mail1.es.net with smtp (Exim 1.81 #2) id 13jIem-00041G-00; Wed, 11 Oct 2000 02:58:41 -0700 Received: (fmail 6219 invoked by uid 1001); 11 Oct 2000 10:00:23 -0000 Date: 11 Oct 2000 10:00:23 -0000 Message-ID: <20001011100023.6218.fmail@990.net> Reply-To: myzhai@990.net From: myzhai@990.net To: rm@mash.CS.Berkeley.EDU Cc: rem-conf@es.net Subject: about layered video Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sir, I remmeber that someone ever wrote a paper about the perceptual quality causing by losses in the layered video through simulation or theory analysis. In detail, for example, in MPEG-2 the following frame IPBBPBBPBB conpose a GOP,if frame I losses,then the sequential PBBPBBPBB will be useless. and If frame P losses,the the following BB will be useless. so If loss rate is p,it will cause great quality degradation if frame I and P is lost. Who can provide me some infomation about where I can find the similar papers(better including concrete simulation results in these papers)? thx Zhao __________________________________________________ »¶Ó­Ê¹ÓýðÁêÈÈÏßÃâ·Ñµç×ÓÓʼþϵͳhttp://www.990.net From rem-conf Wed Oct 11 07:02:43 2000 From rem-conf-request@es.net Wed Oct 11 07:02:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jMK2-0003Wn-00; Wed, 11 Oct 2000 06:53:30 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jMK0-0003Wd-00; Wed, 11 Oct 2000 06:53:29 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA12908; Wed, 11 Oct 2000 15:53:27 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma012905; Wed, 11 Oct 00 15:53:27 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA22461; Wed, 11 Oct 2000 15:53:26 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA27394; Wed, 11 Oct 2000 15:53:25 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014757543; Wed, 11 Oct 2000 15:55:18 +0200 To: , <4on2andIP-sys@advent.ee.columbia.edu>, Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014757543000002L932*@MHS> Date: Wed, 11 Oct 2000 15:55:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/11/00 16:51:40" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, A late reply. You wrote : >Perhaps an a=3Dx-mpeg4-sl-header-length: >attribute on any RTP stream carrying MPEG4 content should be >permitted, and required if byte count is non-zero (with zero being >the default)? You are right. But this RTP attribute requires a field of constant leng= th for the SL header. As SL headers may vary in length, use of such attrib= ute would result in loss of efficiency. Therefore I proposed to define an a=3D that signa= ls the presence of a length byte preceding the SL header and indicating the le= ngth of the immediately following SL header. Kind regards, Jan -----Original Message----- From: singer@apple.com [mailto:singer@apple.com] Sent: donderdag, 05 oktober, 2000 18:46 To: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP At 5:45 PM +0200 10/5/00, jan.vandermeer@philips.com wrote: >Dave, > >You wrote : > >>What is wrong with Carsten et al.'s sync layer mapping into RTP > >Good question, as usual. Let me list a few issues : > >1) Substantial overhead for small access units; a solution is being >discussed for audio, but not yet for the other streams I listed; some = may >indeed deserve a more reliable transport method, but an RTP solution w= ill be >required too, I think. Perhaps use of FlexMux the only solution here. I agree. Allow flexmux, where this is a problem, but don't mandate it.= >2) Inclusion of a plain SL header with associated fields; I would pref= er to >start with a byte indicating the length of the subsequent field that >contains the SL header. Such field is easily decodable by non-MPEG-4 s= ystem >receivers, provides a future proof solution (in future more informatio= n may >be contained in the SL header with a length that is unknown by now), a= nd >creates room for fully compatible extensions. OK. This seems fine on the surface. >3) Little commonality with the Kikuchi-san drafts for audio and video.= >Perhaps it is possible to merge both solutions by extending the Kikuch= i-san >drafts with the option to carry an SL header (preceded by the above le= ngth >field), for example signaled by a new attribute "MPEG-4 SL header carr= ied" >at SDP level. Wasn't this where the whole flare-up started; proposing to add an optional SL-header to the Kikuchi proposal. Perhaps an a=3Dx-mpeg4-sl-header-length: attribute on any RTP stream carrying MPEG4 content should be permitted, and required if byte count is non-zero (with zero being the default)? This is just a question, as I realize there are still some messages I have not managed to read... >Kind regards, > >Jan > >>Can we assume that the following streams are probably most efficientl= y >>contained in a FlexMux stream, and consequently that is no need to sp= ecify >>use of RTP and SDP for those streams: >> >>- ObjectDescriptorStream >>- ClockReferenceStream >>- SceneDescriptionStream >>- MPEG-7Stream >>- IPMPStream >>- ObjectContentInfoStream >>- MPEGJStream > > >I would be strongly opposed to mandating the use of flexmux for any >stream. What is wrong with Carsten et al.'s sync layer mapping into >RTP? >-- >David Singer >Apple Computer/QuickTime -- David Singer Apple Computer/QuickTime = From rem-conf Wed Oct 11 08:42:13 2000 From rem-conf-request@es.net Wed Oct 11 08:42:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jNye-0006kl-00; Wed, 11 Oct 2000 08:39:32 -0700 Received: from www.psm.cz (inetsrv.psm.cz) [194.212.130.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jNyd-0006kW-00; Wed, 11 Oct 2000 08:39:31 -0700 Received: from mail.ticker-news.com (NTD128 [216.247.37.65]) by inetsrv.psm.cz with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 4RWJV7T4; Wed, 11 Oct 2000 17:36:27 +0200 To: X-References: 07CA09EB7, 0F6B9F997 MIME-Version: 1.0 Subject: {{{Company Profile}}} From: X-Accept-Language: en References: 04E40308A Message-ID: Date: Wed, 11 Oct 2000 11:34:39 X-Mailer: Mozilla 5.50 [en] (WinNT; A) X-Other-References: 04B1CC3FD Content-Type: text/html Sensitivity: Restricted Content-Transfer-Encoding: 7bit X-In-Response-To: 05C8ECBF6 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
Award-Winning Internet Privacy and Protection in an Easy to Use, Cost Effective Environment for Business and Consumers.

This company is involved in 3 complementary businesses, encompassing: Internet security software, ISP services, and instant messaging, electronic greeting services.

Communications security software utilizes powerful encryption technologies to secure the transmission of sensitive data over the Internet and across corporate networks. Advantages include voice email, a digital shredder, built-in file compressi
Recognition Gained. The software has received several positive reviews including a 5-Star rating on ZDNet and selected Editors Picks on popular industry publications. Comparisons with the largest and most noteworthy competitors were extr
Acquisition Strategy. This strategy involves 2 complementary areas.

1-To date, 5 ISP's in 4 major cities, which not only adds direct revenues, it provides direct marketing and distribution channel for software products.
2-An Instant Messaging/Greeting Card service, which adds complementary services, customers, visitors, and gives a foothold in international markets.

If you would like more information regarding this company and others like it please: [CLICK HERE]

The company is expanding this network to offer connectivity, privacy, and protection solutions coast to coast, as well as to the rest of the world.

The Market. The digital information protection business will be a US $50 billion industry within five years, and the Company&s software can be marketed to all segments of this market. The customer&s knowledge level is not a
Distribution. is currently available at more than 1000 secure websites. Marketing is also done on its own site, to its ISP client base, and through partnerships with content management and anti-virus solution providers.

Revenue Base. Annualized 1999 revenues totaled over $1 million.

Management Team. Collectively the top four executives represent over 50 years of related experience, key management is in place in technical and strategic growth, and a superior Advisory Board is in place.

Why? This company has: a superior, recognized product line, well established distribution channels, a revenue base, an acquisition-oriented growth model in complementary areas, and a quality team.

If you would like more information regarding this company and others like it please: [CLICK HERE]


REMOVE INSTRUCTIONS:
We apologize if you have received this in error. Simply [Click Here] and then click send

Disclaimer: This release may contain certain forward-looking statements reflecting the companies current expectations in its respective markets. Investors are cautioned that all forward-looking statements involve risks of course and uncertainties, inc















z1010 ##################################################################### Notice, incidentally, that the theory of syntactic features developed earlier cannot be arbitrary in the traditional practice of grammarians. With respect to specific goals, the characterization of critically co-optive criteria raises serious doubts about a corpus of utterance tokens upon which conformity has been defined by the paired utterance test. Based on integral subsystem considerations, my proposed independent structuralistic concept requires considerable systems analysis and trade-off studies to arrive at the anticipated epistemological repercussions. Interestingly enough, the systematic use of complex symbols presents extremely interesting challenges to all deeper structuralistic conceptualization. Specifically, my proposed independent structuralistic concept is necessary to impose an interpretation on irrelevant intervening contexts in selectional rules. ##################################################################### From rem-conf Wed Oct 11 12:38:43 2000 From rem-conf-request@es.net Wed Oct 11 12:38:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jRej-0005m4-00; Wed, 11 Oct 2000 12:35:13 -0700 Received: from mumble.cs.rpi.edu (cs.rpi.edu) [128.213.8.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jRei-0005lj-00; Wed, 11 Oct 2000 12:35:12 -0700 Received: from ephraim.cs.rpi.edu (glinert@ephraim.cs.rpi.edu [128.213.8.39]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA81568; Wed, 11 Oct 2000 15:34:50 -0400 (EDT) From: "Ephraim P. Glinert" Received: (from glinert@localhost) by ephraim.cs.rpi.edu (8.9.1/8.9.1) id PAA22463; Wed, 11 Oct 2000 15:34:47 -0400 (EDT) Date: Wed, 11 Oct 2000 15:34:47 -0400 (EDT) Message-Id: <200010111934.PAA22463@ephraim.cs.rpi.edu> To: end2end-interest@isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: Register Today For ASSETS'00! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ********* PLEASE DISTRIBUTE IN YOUR DEPT. OR ORGANIZATION! ********* Apologies if this reaches you in error or multiple times... ASSETS'2000, the 4th International ACM/SIGCAPH Conference on Assistive Technologies, will be held November 12-13, 2000, in Arlington, VA (a suburb of Washington DC, just minutes from Reagan National Airport). Don't miss this unique and exciting opportunity to participate in ACM's PREMIER CONFERENCE ON COMPUTER SCIENCE RESEARCH RELATED TO ASSISTIVE TECHNOLOGIES AND UNIVERSAL ACCESS, which is nevertheless a small and intimate event where meals are taken together and you have a chance to really talk to people. THIS YEAR'S CONFERENCE HOTEL is connected by sky-bridge to the National Science Foundation, so attendees can plan to take advantage of any free time to meet with NSF staff and learn about funding opportunities in their research areas (it is best to make an appointment before-hand). It is also located directly atop a Metro station, so sight-seeing in DC is easy. And if you ACT NOW there's still time to take advantage of DISCOUNTED EARLY REGISTRATION RATES for the conference! FOR MORE INFORMATION, please see: http://www.acm.org/sigs/conferences/assets00 We look forward to seeing you next month at ASSETS'2000! From rem-conf Wed Oct 11 13:50:21 2000 From rem-conf-request@es.net Wed Oct 11 13:50:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jSk9-0000Vs-00; Wed, 11 Oct 2000 13:44:53 -0700 Received: from (remotemail.WEBLICATIONS) [206.215.217.105] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jSk8-0000Ur-00; Wed, 11 Oct 2000 13:44:52 -0700 Received: from [63.22.138.65] (63.22.138.65) by remotemail.WEBLICATIONS (Worldmail 1.3.167); 11 Oct 2000 16:30:50 -0400 Received: from by datastre-5o7vdq with ESMTP; Wed, 11 Oct 2000 16:52:06 -0400 Message-ID: <00001fee07fb$0000634c$0000132b@> To: From: lyoung5775@earthlink.net Subject: This company plans to be in Wireless 4907 Date: Wed, 11 Oct 2000 16:51:56 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The stock GOLX has penetrated the Telecommunications a= nd Internet market of India. This newly trading Company is the world's fir= st digital conglomerate with its high-speed broadband network, it is the m= ost comprehensive set of services available on the Internet today. Find ou= t why Global Crossing, Seimans, Nokia, MCI Worldcom, Phillips, has an inte= rest in GOLX...

Come Learn More
http://www.golx3.com4.ws/golx/




You were se= nt this message because your address is in our subscriber database. If you= wish to be removed, please reply here; http://www.golx3.com4.ws/golx/response.html and we will rem= ove you from our subscriber list. From rem-conf Wed Oct 11 15:42:16 2000 From rem-conf-request@es.net Wed Oct 11 15:42:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jUTe-00047L-00; Wed, 11 Oct 2000 15:35:58 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13jUTa-00046s-00; Wed, 11 Oct 2000 15:35:55 -0700 Received: from host62-6-14-178.btinternet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 11 Oct 2000 23:35:36 +0100 Message-Id: <4.1.20001011213544.009d2c70@pop.cs.ucl.ac.uk> Message-Id: <4.1.20001011213544.009d2c70@pop.cs.ucl.ac.uk> Message-Id: <4.1.20001011213544.009d2c70@pop.cs.ucl.ac.uk> X-Sender: ucacfxa@pop.cs.ucl.ac.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 11 Oct 2000 22:12:48 +0100 To: farez@acm.org From: Farez Subject: Invitation to AMOC 2000 - 3 weeks to go! Cc: mobile-systems@cs.ucl.ac.uk, agents@mailserver-ng.cs.umbc.edu, rem-conf@es.net, havinga@cs.utwente.nl, oulusoy@cs.bilkent.edu.tr, helal@cise.ufl.edu, anan@master.cpe.ku.ac.th, b.du@qut.edu.au, habaebi@hotmail.com, borhan@eng.upm.edu.my, lala@asti.dost.gov.ph, hara@ise.eng.osaka-u.ac.jp, jiy@disys.korea.ac.kr, hwang@disys.korea.ac.kr, hara@ise.eng.osaka-u.ac.jp, sri@it.iitb.ernet.in, abhi@it.iitb.ernet.in, rvijay@it.iitb.ernet.in, xwang4@cs.gmu.edu, skjoo@network2.cs.usm.my, tcwan@cs.usm.my, rks@cs.usm.my, Rseptiaw@mail.bond.edu.au, pils@i4.informatik.rwth-aachen.de, jens.hartmann@ericsson.com, hhelin@cs.Helsinki.FI, jmgil@disys.korea.ac.kr, drine@cs.gmu.edu, mymobile@egroups.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Apologies for multiple receipt of this. Please pass on this invitation to those who may be interested. Regards, Farez ------------------------------------------------------------ Programme & Call for Participation AMOC 2000 FIRST ASIAN INTERNATIONAL MOBILE COMPUTING CONFERENCE 31 October - 3 November, 2000. Penang Parkroyal Resort, Penang, Malaysia Organised by University Malaya, Malaysia Sponsored by MRCB Multimedia with Multimedia Development Corporation, Malaysia In cooperation with ACM SIGMOBILE http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc 3 weeks to go! We are pleased to invite you to AMOC 2000, which will be held in Penang, Malaysia. Below is the preliminary programme. Registration forms and instructions are attached below the programme. Regards, Alfarez Abdul Rahman Dr. Mazliza Othman AMOC Co-chairs ---------------------------------------------------------- Programme (please see website for more detail) ---------------------------------------------------------- * 31 October, 2000 - Tutorial only 0900-1215: Tutorial: Mobile Ad-Hoc Wireless Networks Dr. Somprakash Bandyopadhyay PriceWaterhouseCoopers, India Dr. Krishna Paul, Cognizant Technology Solutions, India ========================================================== * 1 November, 2000 0900-0930: Registration 0930-0945: Opening speech Prof. Dr. Ir. Mashkuri Yaacob Deputy Vice Chancellor (Academic), University of Malaya 0945-1030: Guest Speaker Dr. Andreas Fasbender, Vice Director, Ericsson Application Research Asia Pacific, Ericsson Cyberlab, Singapore Topic: "Mobile Internet: What's in store for the end user?" 1030-1050: Break 1050-1135: Guest Speaker 2 (TBA) 1215-1400: Lunch 1400-1530: Session 1: Medium Access Energy-efficient TDMA Medium Access Control Protocol Scheduling Paul J.M. Havinga, Gerard J.M. Smith Dept. of Computer Science, University of Twente, NETHERLANDS Fault Detection and Recovery Algorithm for a Centralised Media Arbitration Scheme in Wireless Networks Anan Phonphoem, Aura Ganz University of Massachusetts, USA Adaptive Slot Assignment Algorithm for Improving the MAC Frame Access Delay of Wireless ATM Channel Mohamed Hadi Habaebi, Borhanuddin Mohd. Ali Unviversiti Putra Malaysia, MALAYSIA 1530-1545: Break 1545-1715: Session 2: Asymmetric Channels Incorporation of QoS and Mitigated TCP/IP over Satellite Links Swee Keong Joo, Tat Chee Wan School of Computer Science, U. of Science MALAYSIA Traffic Allocation in LEO Satellite Communication Graham McMahon, Stephen Sugden, Reza Septiawan School of IT Bond University, AUSTRALIA Mild Aggression: A New Approach for Improving TCP Performance in Asymmetric Networks Vijay T. Raisinghani, Abishek Patil, Sridhar Iyer KR School of Information Technology, Indian Institute of Technology, INDIA ========================================================== * 2 November, 2000 0900-1030: Session 3: Broadband and Multimedia Design and Characteristics of a Broadband Subcarrier Multiplexed 2.375 GHz Wireless Link Randy C. Barstan, Rolando C. Guevarra, Mia G. Antonio, Delfin J Sabido IX Advanced Science & Technology Institute, University of the Philippines Technology Park, PHILIPPINES An Efficient Scalable Image Coding for Multimedia Applications Mohd Al-zoubi, R. K. Subramanian School of Computer Sciences, USM, MALAYSIA A Framework for Live Video Delivery over GPRS Networks Bing Du, Anthony Maeder, Miles Moody Queensland University of Technology; Cooperative Research Center for Satellite Systems, AUSTRALIA. 1030-1045: Break 1045-1215: Session 4: Agent Technology Towards Mission Tamper-Resistant Mobile Agent-Based Electronic Commerce Xunhua Wang, Yih Huang, David Rine Dept. of Computer Science, George Mason University, USA Requirements for Disconnected Mobile Agents within Cellular Mobile Telecommunication Systems Carsten Pils, Jens Hartmann Informatik 4 (Communications Systems), Ericsson Eurolab Deutschland GmbH, GERMANY Software Agent Framework for Nomadic Computing Heikki Helin, Heimo Laamanen, Mikko Laukkanen Cellular Systems Development, FINLAND 1215-1400: Lunch 1400-1530: Open Forum Session 1530-1545: Break 1545-1700: Open Forum Session (continued) PM: Banquet ========================================================== * 3 November, 2000 0900-1030: Session 6: User Mobility Evaluation of Methods for Transmission of Location- Dependent Continuous Query Results Gokmen Gok, Ozgur Ulusoy Bilkent University, TURKEY User Mobility Simulation by Travelling Demand Model in Mobile Environments Joon-Min Gil, Chan Yeol Park, Youn-Hee Han, Chong-Sun Hwang Dept. of Computer Science & Engineering, Korea University, KOREA Mr. G: Mobile Routing Method for Group Migration Hiroaki Haginao, Takahiro Hara, Masahiko Tsukamoto, Shojiro Nishio Dept. of Information Systems Engineering; Graduate School of Engineering, Osaka University, JAPAN 1030-1045: Break 1045-1215: Session 5: Data Acccess, Display and Management A Remote WWW Display Environment using a Cellular Phone WWW Service Toshiaki Uemukai, Hiroaki Hagino, Takahiro Hara, Masahiko Tsukamoto, Shojiro Nishio Dept. of Information Systems Engineering; Graduate School of Engineering, Osaka University, JAPAN Increasing Transaction Autonomy Using Adaptive Broadcasting Schemes in Mobile DBMSs IlYoung Chung, Chong-Sun Hwang Dept. of Computer Science & Engineering, Korea University, KOREA 1215: Conference Close ------------------------------------------------------------------ AMOC 2000 1st Asian International Mobile Computing Conference 31 October - 3 November, 2000 Penang, Malaysia ============================ Conference Registration Form ============================ Your details ------------ Title: _______ Surname: ____________________________________ Other names: _______________________________________________ Designation: _______________________________________________ Company Name/ Institution: _________________________________ Address: ___________________________________________________ City: ____________________ Postcode: _______________________ State: ___________________ Country: ________________________ Office Telephone: __________________ Fax: __________________ E-mail address: ____________________________________________ Would you like to include your name in the list of attendees? _ YES _ NO Please specify if you have any special needs: ____________________________________________________________ Registration Fee (please tick as appropriate) --------------------------------------------- * You can pay in Malaysian Ringgit (RM) or US Dollars (USD) Students: _ RM 400 (USD 100) Others: _ RM 600 (USD 150) Note for student registrants: In order to qualify for the discounted conference fee, please ask your Head of Department to certify that you are a student here. Head of Department's name: __________________________________ Head of Department's signature: _____________________________ Lunch will be provided during the conference. Are you a vegetarian? _ YES _ NO ____________________________________________________________ Tutorial Registration --------------------- Will you be attending the tutorial "Mobile Ad Hoc Wireless Networks" on 31 October 2000. _ YES _ NO Registration for the tutorial costs RM 200 (USD 50). This price includes lunch and tutorial notes. Your signature: _____________________________ Date: ________ ____________________________________________________________ Payment ------- Please write amount: Conference registration: _________ Tutorial registration: _________ Total: _________ Please pay the total amount above in a crossed cheque / bank draft payable to 'BENDAHARI UNIVERSITI MALAYA' and mail it with this form to: Asian International Mobile Computing Conference Faculty of Computer Science & IT University of Malaya 50603 Kuala Lumpur Tel: +60-3-7969 6383 Malaysia Fax: +60-3-757 9249 (Attn. Mr Mustaffa Kamal) http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc Enquiries: amoc-registration@fsktm.um.edu.my ------------------------------------------------------------------ For hotel booking info, please see: http://www.fsktm.um.edu.my/amoc/amoc_accom.html http://www.cs.ucl.ac.uk/staff/F.Abdulrahman/amoc/amoc_accom.html Important: AMOC will coincide with the local holiday season, so please book your rooms ASAP. +44 7939 610241 www.cs.ucl.ac.uk/staff/F.AbdulRahman Department of Computer Science, University College London From rem-conf Thu Oct 12 03:47:15 2000 From rem-conf-request@es.net Thu Oct 12 03:47:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jfoK-0005pn-00; Thu, 12 Oct 2000 03:42:04 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13jfoH-0005pa-00; Thu, 12 Oct 2000 03:42:01 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 12 Oct 2000 11:41:19 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Gonzalo Camarillo cc: rem-conf@es.net Subject: Re: RTP sent to different ports In-reply-to: Your message of "Tue, 10 Oct 2000 14:49:12 +0300." <39E30238.768B1EF9@lmf.ericsson.se> Date: Thu, 12 Oct 2000 11:41:18 +0100 Message-ID: <3076.971347278@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gonzalo Camarillo writes: > > Now I want to have a conversation with somebody. I want just to transmit > my voice. However, sometimes I will use PCM u-law and others PCM A-law. > The receiver wants to receive (due to any reason) different codecs on > different port numbers. > > As we have discussed previously in this thread, we will establish two > media streams. But I want the receiver to know that I will never > transmit simultaneouly in both media streams. > > I will transmit using one OR the other. > > I would like my session description to look like: > > v=0 > o=John 289085535 289085535 IN IP4 first.example.com > t=0 0 > c=IN IP4 111.111.111.111 > m=audio 20000 RTP/AVP 0 > a=fid:1 > m=audio 20002 RTP/AVP 8 > a=fid:1 > > If an implementation does not understand the fid attribute it will try > to mix the audio streams. Since one is "empty" all the time, doing this > is not really a big deal. Thus, backwards compatibility is not a > concern. Backwards compatibility is hard to predict. How can we be sure the following won't happen? i) A separate audio application is launched for both audio streams. The first instance to receive audio locks the audio device so that any audio received by the second is discarded. ii) A single instance is launched because the parser chooses to observe a single audio stream instance. These both result in a receiver could be cut out of a conversation unexpectedly because of a codec change. > Do you have any concerns with this approach? My concerns are not with with SDP description per se, but with the motivation for using two ports for the same media session. It really would be better to modify TFT to be able to select the radio channel configs based on RTP payload identifier. There is no question of compatibility TFT can be modified. Is there a categorical statement on whether this is possible? Supposing TFT is immutable, there is also the issue of whether AMR will, for all practical purposes, be the only voice codec that is going to be used to communicate to 3GPP terminals. The AMR payload does not benefit from the multi-port approach. It's also not clear what the situation will be with music and video, applying UEP for some popular payload formats will be expensive for a gateway if the stream requires parsing and analyzing for each packet. That would DTMF as the compelling reason for this proposal, but that can use redundancy rather than UEP anyway (for the wired network this pretty much essential for DTMF applications). > RTP and RTCP remain untouched. It's just all the existing RTP applications and RTP supporting firewalls that need changing to provide a predictable behaviour with this proposal. The scale of 3GPP market might be sufficient market pressure to see the existing applications get modified quickly. - Orion From rem-conf Thu Oct 12 11:21:56 2000 From rem-conf-request@es.net Thu Oct 12 11:21:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jmr5-0003lC-00; Thu, 12 Oct 2000 11:13:23 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jmr4-0003kp-00; Thu, 12 Oct 2000 11:13:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00809; Tue, 10 Oct 2000 06:43:09 -0400 (EDT) Message-Id: <200010101043.GAA00809@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-xie-avt-et-rtp-amr-00.txt Date: Tue, 10 Oct 2000 06:41:47 -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. Title : Error Tolerant RTP Payload Format for AMR Author(s) : Q. Xie, S. Gupta Filename : draft-xie-avt-et-rtp-amr-00.txt Pages : 9 Date : 09-Oct-00 This document defines the RTP payload format for *error tolerant* delivery of Adaptive Multi-Rate (AMR) speech frames over an RTP session. The flexibility on bandwidth requirements and the tolerance to bit errors of AMR codes are not only beneficial for 'over-the-air' wireless links, but are also very desirable for any Voice-over-IP applications. The design is focused on how to best facilitate these features of AMR codec in an IP environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xie-avt-et-rtp-amr-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-xie-avt-et-rtp-amr-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-xie-avt-et-rtp-amr-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: <20001009132250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-xie-avt-et-rtp-amr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-xie-avt-et-rtp-amr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001009132250.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Oct 12 11:21:56 2000 From rem-conf-request@es.net Thu Oct 12 11:21:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jmr4-0003l5-00; Thu, 12 Oct 2000 11:13:22 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jmr3-0003kp-00; Thu, 12 Oct 2000 11:13: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 OAA10421; Tue, 10 Oct 2000 14:46:36 -0400 (EDT) Message-Id: <200010101846.OAA10421@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: Registration of parityfec MIME types to Proposed Standard Date: Tue, 10 Oct 2000 14:46:36 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved Registration of parityfec MIME types for publication as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The RTP payload format for generic forward error correction (RFC 2733) allows RTP participants to improve loss resiliency through the use of traditional parity based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. "The Registration of parityfec MIME types" document serves as the MIME type registration for these formats. Working Group Summary The working group supported advancing this document. Protocol Quality This document was reviewed for the IESG by Allison Mankin. Note to RFC Editor: Please modify draft-ietf-avt-fecmime-01.txt by replacing all four occurances of: Security considerations: none with: Security considerations: the same security considerations apply to these mime registrations as to the payloads for them, as detailed in RFC 2733. From rem-conf Thu Oct 12 14:43:56 2000 From rem-conf-request@es.net Thu Oct 12 14:43:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jq4e-0003HT-00; Thu, 12 Oct 2000 14:39:36 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13jq4b-0003HD-00; Thu, 12 Oct 2000 14:39:33 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id XAA07587; Thu, 12 Oct 2000 23:39:30 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma007585; Thu, 12 Oct 00 23:39:30 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id XAA00182; Thu, 12 Oct 2000 23:39:30 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id XAA09983; Thu, 12 Oct 2000 23:39:29 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014795482; Thu, 12 Oct 2000 23:41:21 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: Subject: Three documents Message-ID: <0056890014795482000002L922*@MHS> Date: Thu, 12 Oct 2000 23:41:21 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary=_0.0_=0056890014795482" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Boundary=_0.0_=0056890014795482 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/13/00 00:37:25" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all, Please find attached three input documents for the La Baule meeting. M6= 447 and M6448 are short documents; the first one is about MIME types for carriage of MPEG-4 streams in RTP, and the second one about carriage of= SL headers within RTP. The third one, M6449, contains a rough draft of a s= ingle specification for carriage of MPEG-4 streams over RTP. It includes majo= r parts of the drafts of Civanlar et al, Kikuchi-san et al and Roux et al= , while using the approach discussed in M6447 and M6448. Partly M6449 is in response to the question of Colin for a specific proposal. Hopefully it clarifies where "I am driving to", to use the wo= rds of Colin. More work is needed, but I hope that the basic concepts of M6= 449 can serve as a basis for further convergence. Please feel free to use i= t for more elaboration. After today I will not be able to further participate in the discussion= until La Baule, as I leave for a small but special vacation. For those = who guess right : indeed, indeed. See you in La Baule, where I will arrive on October 25 (Wednesday). Hav= e a good discussion and a very good start of the meeting. Kind regards, Jan ************************ Jan van der Meer Philips - Digital Networks Building OAN-4 P.O. Box 80002 5600 JB Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 Email jan.vandermeer@philips.com ************************ = --Boundary=_0.0_=0056890014795482 Content-Type: application/octet-stream; name=M6447.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=M6447.zip UEsDBBQAAAAIABaFSylxNbEvZhsAAACYAAAJAAAATTY0NDcuZG9j7D0LdFRVkvX6lx9N0gk/AY9X jQhCQgIBQgQkP0hyIN2bRGCUcex0vySN/bPf65AwQUcnM4s666o7Os7szhl00VXHHZH9jGeOs8rs jovOrLK66+oeZ49yzqKrnhlE/GLIVt33Xuf26375QEAdc3Oq3617b9WtW1W37n1NtR5+wfP6fY/P fQNMZR3Y4dRwHriENglho4EUATTrbaeGh4epaQPC8FT5UpV3HzgI10OeA01X/FTKsliwpXgGwHTo 3NG5Q12sLoaMkueYBRddBDCrVuJQXJQ5RizDw4Vj1o3ydf7Z64TUU6xbPWcIHG51jv2chs978Dlf aP+nWoBH0a2f0fHTfV6zFsCGz2vXarj4bMTnA/g8hvPcfYX2/A7OW4rtO+oBTiB+DQ7ah/jD2D4T MkuvaT5zGUs+4kvl9/oWN+vTzNdMb9CZn9R/M2TyMeO3Xw5wWIKMYrbTWHYX9U2F5LjVMSJPXwHA XVhfvxLnc2TSn24h+akY8x9wav73NHyy5s7lT0vmdTShDA/iswjpbjAz+9xKc2tHY1trbUezt7V2 E/O2baxtbW7nKNvgbWPtHbWtDbVtDXqbO21AGm0ja2hkrd62zbWbjMHN7d6lzY31rKWjvnJpe/2y 1Uu3bqysdNd7G5pbNzLvBrbZu4Vqvub6jivbGtsZzsVqr2xo9rqtaDf7GjdWVCzdvLKqapXbG1Bj nXKCLauoqHC73e2xZCIg1+T5ekLhUFxh9bGokoxgf2NYDqiJWDQUUNwdITWMY+r9iUTI3y2zWBdr 38R6ZH9QTihsZ0jtCUVZW4fPvTERS8Zr8tr7FVWOKO7apNoTS9SwvBZ/lPUi4Hi2WZYTOPHYzHA9 UZQgmAyooViUMBZM+LvUspCsdpX5e9WyhBovi8Tl7qqyiuXlap/KFnb2s/oQzhT2J5isMn94EfOz iIxiBFlIYcGQEkgqihxkaoypCX9UiccSOCw6IoIhgZ8LweL+/nDMHyxnW7GZYY+is1vCukIJRWXB ZDwcCvhVmYWiXbFExE/Csq5ELIKjZYEvUfrjcZw7FMXZA7FEQsbpo8FQtJtPpY/rCsnhoLIEBUAp e1AMYpOQI/5QlLpRXRl8Q9FAOBnknHmnJllnvyorxvi0tXTQMnD2ZFglYtNaaVYV5YsqIUXlDNL0 szAeU5RQZ7ifyZG42r+IdcXC4dhOnB2Vr4sW9weuQ/WnJmzC/l45sYSFyCZKTJxciUVknC0SR811 ohOq/SyeiHWG0YHKudG50oOxALplFMmRIJzkSiYb9siKFTVpBusorozW8qNvyeEwPXE5fkWJBUJo tSAtlNstGpCZomITnwabGO0bzjsc8mNTQg7IIVwFiVWvzxiWmdynyqgqVJfb3YF2TcjkDKSsRAyd gBgFso3myhBEpOUooe6oP8y1GJaj3ehxuvlSFh6xA2qb7NLgY35VTYQ6k6qsW9ZP9lAYd7KoGoom Zc4jqejbjRDFH5HTjd4fl9nOHjkqiJjpbP6EjJu4KxQlldJOQXvoknKvwdmT0euisZ1Rkg+f5Wxz LCHHuPGVZKDHGE3OaQhKKpL9Sj9TrgvF47QdMuZFZkG5NxRAh+bz9Ph7ZWTPTVRWxRQecBhNHJaD 3TJaqCNDhyPcArFkGN1V1vWtuS55xdo+PZ4o4TJtbJnGo2YNFxgJo+q6dKVz8f3Rfq5NRUXzR1gA g1s/LYTkq+JmIKcKdbERNqSraCxatktOxNhCrkte7ZSJkARGRftxlyxawnAebRukfB8dGPcD2lqL F7RG2rEqOaq+bJIrbd3lrFYRY23E349ROdFPu1CjWYJOwl2Em2pkiTu5wrRNy0djCKBhcldXKBCS o4F+TeMJGSeVszi25jNGoBlh7F+7xqzwrrC/e51mZc08Cl9FHGeXaY9SPErzojhtzKChNMFXoxQQ gxScjU7TpopEkA53K8YyLYjROEFdfDftDFHUoF6u0Vic9I+blNgb61e1DUqbxnSeUYCTFW03YT/y 97NujCLRjM1XztzuaeS16EN45CUTqb2qjeQRtVPGWMI3gUw+oLPqlEm6GjwxK1hmqczStixL23Kk rsSe5ayKrWAr2SpWzVazCbS5F5ed4Z97YMvaZQO+gW0DjNXXo0wDmwe4bL4OTcYBXVZFvj7JvSGa jNBtxigD/OYwCXIw66KG0AKqPxIfZcwAa+IOMMmiKP3RQA9dynZp1wyF397Ywvb2tvpFLBRETwxh PBjRB4kyCTLUiAwpmvHtS95sSFBvkkARKdA1F689wz/3AO2qYMLYw4xwn7YrmvSbCQazkJ9O2Ytp 6/D7z6Iz0QNLL5pzjeYa4ykDKQ4jC/DpcWChfixi3JODI6KbOejDJ1EUqzKmisbkUFNeXu716a9K WiQL8mCtl8lwz8xZN4S6KYBWsjJWGxUDqHGvK6tyu4VLt3Y3qsk4aYwTZcTvtONWu5xjrE52aqFI Fa694kWeDkLxlmHE87GPwHLW3KXLoi6xFISueyyGRyv3HK1Nu4lpJ592Vhg0oWj6W4HlCZi2Erw3 CCendknhXOiQlxORkIr3aLwAuPULc+o+rd3CgnhmBfVb3YgltBcLpsTlAAaMQPo9VLuOWdy/mdKD xzFd3+iNKC5HKegYKxrdeIbZRi4JqbctJaWxidoJF+4e+zuDqfJHVBwA9yDci/Aswm8QjiGc5wSo Q2hA6ELoQUg6tW/NpFwAG8IchPMQvjYN6RF+hPCMB+BfEeaUACxCKJwBUDRD+y755CcfAP0dh7eP vn707ZfxA14++vbR58eW8itZCr0tdvgThJ5ciDblOUq8LQA+BMQjiFNbgY5TPUd/Tl+Re1N9yxyj GRz1LfMBcvRWOz61OjbOJfsvRdiOoCD8QPeFxxCe1H3iOZNfLNR9o17wj26Tj+zIAbgO4TNxQeNE jovIHyyRoyKS9g9YacgrIvKyZU8a8h+WyIvjG/Zvlj3PWSKpYvdAZamESsxfAAUb1uKGk7R/aJPm AeB+s5faLyuV3M84QYo6tH+pCRYNA+RRl61wcMEs3rdgFth5Sz59StoY3lMwU+uRYPbZtr85Vvw1 CrkPYWYBwCyEbdNG4scP9RjyCsIcPIeuQtiLcARh8XSACMJjCO8hLC/EudL/2WiIPj796MTv3zn6 xmuv/vtvn33mn5/+5S/+4cBjjzyw9y/vufN7f3rz7j7Itc0Hl+fD4WGt1p6q3Z2q/Veqdt5HRq0z VduXqr2dqi352KiFU7VHqOZ0/RQfTtej+Jlr84DrHa31Xd5a/il9LuWfe0/S5338c/EQjZ6NfLEC ha46wtdCnpRPTuB01Q/p3F4d4rNh7b9TteeH+Qwv4CPf9dqwToktvxsm3v9DnzbEwW5Db1p6Lmz0 c4ShQtMm/1REPhCRd0TkrUlFrCVIQ9IiyxcZMRVpvrav7ZA3G5pKpRWl0qpSqbpUWt3gADGeGDEG 5or2uaIIYA/CcwjT8AxvRbjDM3Kmz8LzfHbJyNl+mXC+e4wz/sP33n3zyO9eeen53xz69S9HkfUr XwpdS44b+5r+ndjpKjvOowL/3P2+HgNueN+IKH+fqn2YqlWfMGq7UrUnUzXnB0ZtY6r2Z6naC1gr mSy7D4lLm1zkfRE5Nj7k/8Y37M3xIV+eQgeEi4cAfa9bxwOKFuBhMN8nwQX7Dy9l+19fe+H+3JyL EC6+Y6+zFOGS/WPOOFW+1KUYzod8dJuroZBnq1ApBVj/3rCNZ6O4oBVikIAI+CEMWkaLg7991IC0 XkK8BiiPpglkHBGEEEShGxhUwhJsqwS6sErgKpXWL4Ac0F9BoBrpiLYa6NZqpl2GrQXYixdUTigJ lG3o0RK+IbRlnXU5n3U59s3GcUicv8BWsMEJJfuOwYx9a2D9AhuuU+flbbHh25WNeDpG4VnFeVZx ng6Npz2dpz0LTyrVKLf1KlfxVeakVunSVulrcWjUa6B2/fHh+/CJERgakLoL6ZNoBRWpfVhPIHTz zzj0YNsGtFQUe8VyGdTxtV3GZajDEUHox7EdyK+Pj3Wh9DP29WFtJf6hvBJ9umETSqrwuer4rGGk UHXr5EGRdpmgBCpYCKe8EhRLC7HuxFHkKyHuLbngofBTWYqao4Wtg1OFpJF1fO2NXBsq9y+F+5mK 1JRzVkxUTq4YpM2BlbpeGqAeZVsmNQClqWWuhkEzaiCImKYHN5QQp8LBX9s8g5cPoU+ghtHOJEWb 1Mal6EBpO/nqvoF1kifMpbgQZui20Sx9Pb47TQfHXPvfOKpcB3O4drnFcDPkou5PFdZKndIGroM6 5OFHGQKInQ8z8f3sBL57lewD5LMa+eQLbAo039Fe6XGFJFsnX2G+STbDYrPwT9NPcbCO8w0i3yBq u76lmNjkVnOLJCTyPAfqLMZ1QrudzgFYUQqrSqG6FFY32NDjvS1OtI6TKKd16Bbq4J6xAfXRjdZP cOoymCNoxMwnUzu5Kc4+zvUuyWdpt3Z9X2i6nwnn0QrNUwgcl8FFfG8t41ao53tARR60A8juc0nS EnRr7tqa3bdAG0asA9IWromxvEfz9DkwT3/fLhyMOjyDd5003rtHYlIFXIV8fyVVcJv5uO1pNeIu s8F8Lr32hQ4VypbEl6yLqE6ZmEbGZQFwo/G3Z7qdURtts+mgp2Y6tLcqaqcva42X4HY8+69C+DHC Awi34bjbHaDdBxDuzAe4G6EEJ5iN0I8wgPAeMjmBsAsn2I3wM2T4OMKMItIsrXP+OIBKA84qS1pW 34sIx9BixxEeRCkeRziOryAnEO7Ad8wfIPwI4TGETlRDN8IphByUsB9hD8IphHyUcBpKV4HwIsKr blGyuROE4eEZXIstfHcy6NWfZPMEPjfjU6s14Lm2HfF+Xo/hTk5iXNM8Q+E9PoxfG3FPVHFsJT6r MKaXIy8aPfYcNWPOUYs4Rcc2bAvgs5fTWbUTFwXnIoxhaxefa0QuP/YGv8RyfZVtci7WPjXHuZxj DQxgzH8wcuz+4ULznwS7se+54CtyZmK8BDdg3z/Od1yare9G7Pv40vuXZ+v7FvYdrdrzVLa+m7Cv butd27L13Yx9N3945Klscn6b+h45ujpb3x7s+9kjB+7L1ncL9u2a2fNGtr6T2Ldj9jX7Mvu011sq 2fro0p3nkCDbGkqXvIg30TxHtvmKLnlJes1+YFa2vvedBx2PBr9/IBvPmsTbbonzzOybd96gx6rP 03+fJ//Y4S3Z+j752ndnWdHdu+qd2YUWfbf0lsy1oju4bsEFVn27rp/HXEO5f5Gt76319zArOf9q /qPMiudzu2dcbCVn7657LraiO3+guNRqviXS1aVWdDcl37rEqu/veo8u0NaXadtFF2xdlFt/KMv+ A9jxzX9ZtOzu/F9l67t028Nlat72EvNsNF/o6w9UWcny0toPVlj1zS69aaVV30+8u1Zb9dkvqbs8 7iluyba+I95r6qzW8JD/PxueLtq1O1vfL6rfb7Sa79WrVjZb2ej40vbmI01PHMvG8/5L3mx7oqL6 p9n67urwti+bd3xhNp6DF97fYSWLf93tW6xkuaL9lqut1n5k859fbeWfbZuPfsNqvh8rDwWsYsgf pA+6L8jaB/CT7u9ErOR81uGOW8n5vZZD11vJ+aTnRUXTWaYs7/i/2WcVs/6X+XZZrU/SnxkFb9uF g7k5nsF7T82kd5/cHBfF2vIxKPY6UxR7neOiqHakKKod46I4bEtRHLYJFLMzx0NBlnV4WyR8H5Mg thDJfn5sdNL0BU2INH1lEyJNX2IWUmvt9Egp0h5pXNpJpzBNxl9MLSd7GEm3aqQPS+nGs2enWIUr e3aIU6yyuew6hUHjzErTbvcM/u1nnKbd7nLqNOX860SdLicb3W1Il9TobrO7cgS6cv6FokGbl4V2 CGntnxl2zzPRlvMvD1P0BZn02tcGBn1BFvpycKbxSMvB4jzmoO+99anhtm4LHuX4rp/GR9zmnM+t yKdX4xPPdRWOwqecf3kp8vKYeFW5PIO//cTg5RmDVznk6l8wZ3qQnfOrQH84rPlDhc3FnU7/NiSL C9lTm6NiyNgcSDKWF1mQjceR7KmdfOiksZORdLy+ZE/FkGs/NXwBySfiThYsJupR9lQg/Phjw6OQ zek4lQWr0/UrjV081zN4x0eGXyG78bjW6HEtPTh5W1wY11xaXAtbBlF7lpCIJOTEi8Zw5YPoYFdo DnbQNkI0+kwZXinpg08zXp8BKUyIFJAUNNKyMxX4nJ1mZ0CqBaOJyEnlj1yfMCHSyVziJGtnlG1P gSY70dQdyOrQmroDTeQOlPUMyNNFGCfJWb8DZZBO7A6UcYWa+B0og8Xp3YEyrlKnfwfKYHVmd6CM K9WZ3IGmZ4lodZfB5IbSLx3pBDahFsnP3c516GRTO/crsnNPw7UMHxknySS41jSD9Gy4Vgb55+Za GWy+MK6Vwe7MX4zP1pVed7NMWk46dU+euieP5bdTHjTlQSKviXuQdkpaHaoW3+t9PuFy6qVw6mp5 Fl8KrePoWfhS1dqPR9lyE5fQOtLPwQjq0yjm2F0OMHQ0eqw/hN6Tq1EdcrhcIGp29Gj/NEamviHD LLlgtsno8f6JXIy1Wrx/Jc+Vn0HtSOeQJeLvz/cMbtM4rC9wTcvKwWnikhnzH5qW2j1F013TLbm4 zJwyov7e6Z7Bao1TX6GraFROORnczHH/9aLUHmoqdhWPyS0Xzujr9nMXifV/RZiKxFOReLQ4d1o3 mAl68BlEfPqP7lKWnUhGWUYiTlmGIk7ZgyJOGW4iTtmhIj5gwr9twk+acMpEE3HKPhNxyuATccoE FHHK9BLxm03895hwyrgSccoaFXHKDhNxyhIUccpWE3HKHhVxyoITccoaE3HK9BNxyhwTccpmFHFD /v32C2xk+ptM6/mWCb/RhN9gwnebcMpGFXHK0BRxyuYUccqMFHHKghVxysoTccpoFXHKnhRxykAV ccr4E3HKbBVx816xmXDKNBRxylQVccqKFHHK+BNxyvgVccqCFXHKuBRxykgWccrWFHHKBBZxym4W C2UmizhlC4o4ZVyKOGWRivjwOS602CL41hfk/x2wBj6/MjxcgAHfBbVQDx3QDFugEZjzApsLax3Y Vgvt2FKNLUV6Swwi/PeW9Ls1H//9gfEL0/XCKPoF32YcFcBnDDbwX6h1gwKl4Etxb4ZWhA64Flvc vKUf4siRZvWlaEqhB/tLhP4W5EgzNvDfCtLvJ0fG9uHYacLYTchtpHcP9nqEXvoFaDvWSE5ZGHcv jisUxmUb85BppivTZnoCe/NQT336n/ErDAmqUN+t4EVo5DXtT4JKxDqgDfk04jG+AXWwieterI89 Yni9t7aVVS2rYE0+tsmvyIkWWWUr2kOwfXtdY+umxqYty32V22P+KI6Jh1dAk28Fnl3mwVZMUsUB 9u/DdqnwIwpmefDDgqrcINDPprfZ6EeS22y2jCBnVa4tAeiaN/Y4sBNHetvBq+z6bbZt6EY2jg3f uLW5dau3TYtZfN7/b+/qWuMqwvBzzn5kozUshYSqTTgJaAttY5I1uEXaJmZjbDAfNEoKig1tEhNJ spIPqkghYEUvIyLmQmi8EAqCBK2lN2K880boTS+8kVz4A0QE6YVZ32feOd3NbjabjSCSzhNOZvac M2e+Z84z533nXebCw15TAK8nuzTPrT8HJ67ueMPL0RWPooGBebVd9lXJnHmMm9fbi8UjeAUwZT/0 lamS/wxa94Sr7+046PXN8goRHVuXOiyRz4eftB7qDa+wBLpgiqOvgYXj+/FILBrzI9EPiwrjhnWp 204NtQUpxkFxr4p7wcwfnD2ATnmOj1jM872auP+AWobREsv8NyIj7CwuS0hq+KeeNrE/Go/6RNnY u2XmmYbuIXGu04SpidT6fsyPlg3D2W3JhFOdO0010B5f8Qal+guYs9Aw49rU6gMX3kherptslHfv vvoVbzkuZVQb9WOJSFSLuyaRz5yGOJVL5QJomAHJaYA+cFeCKUkDKcHzcVNGKEJJGY3aOTici/n6 1SK9thsfHQHuSmRTJgmfvtY/efz1/smn5DgkeZXSlWtdj8E0bfbz95NHCx6unSpsLM1cQrgOh33h y/hGzS3ckgrraGMVPi61BfkP9BbW5z6h7SmXO2x/N5o9CuZtL3gTeX3gEXlXCKSF6e4gbOnsobp/ wAXptcP2CZW1Uivf4eCwHVs5jjKl8yfHmM0Pbvxxf2gq+dXHCZw49u0v0k2w7nHvDL2+Cm3na3Jw KPoJKpbC/S45Rv4Os/mE2XWPw3PC0xeIo54umqbts7hvBBe+xzzV95jxdMeLdzzd4eK6p7tfcNbg xLjq6ZC7Ji7VMG96mo7fJPIm6FHGJo/a48HAdJPNA+Q++knQi037QMLk75sLiv1M6xz3h55pzQy9 gqDSc1hG7R16H9M9MH1lPruQnVwMRrPz40G6tQ0TXXz+1tmLzJ/x1313eyW14Rn/r3/dvhb6N7ea aWUqYtNEl3MHXc4fpd9GHBwcHBwcHBwcHBwcHB5mlOP/POPf+/ne561PJj/5TPj/yftfc4E/VnRu XMhnYPk6eegUlKNTQIFrAFwj4BrAGpQb34SKmqxD+fMdKJffgHJiriHw4/9dKPenWQ4+2y/i+I1y 7GboF5gwHJirpxGbBrpc2zM8vD6BUHKpnNuU1DxVXk84lNTUNdmYjJVhhNx8FXk+HthzFFhgiLP2 N/1cA7k0fD5zqe/V85kHue0Wd1CO98z+cT0SMmO+MKZxCu1mX7mU8bXL+Q7xnZbfGbSJr838PWu+ JmfQKSFSeEF+XYODg4ODg4ODg4ODg4PDw4aQe5Kf8ts9OTsZrPleD/1OT15KTkweTk7Ob/Hk+OTt 5PRbuVyO3J22Feqh/J0c/whUnobKAJQwJBcnbydLpgB/AFpZURMYFIinUD0VBahMcgy0K0N9Fhjb NSfkOAnaIKFiDPAMaHcDxsIQ7XTQ5g+VKii/x/Q8Bxi7O1QsoYUiCrhTsvuMvX4O+n2d7JrKEz2g dRmg117/W46XrD88DiIoAZg11k56zd71tFlQDRoQ88JnmXWWWl1L2tDLNIeDsebvf6TcwuYXOEOZ hX5YMTmw/vI2bvaDOmm9hfmpHEJlTvwX1T8KWh8aL9nDf694Aj4ttaKa+ImWFnVjGDGxzhrpsHeN BZpJhBa38hZtyuG4xM8SZ9/da/xGWcbKuMVKcl5detISf7XlzzWvMH7P6jC8jSFpBW/tFmxHHJb4 OYZxzKqm/MOYNFba7FjEsOkLM7uGK0aD5KBS/sN2H7o73fNvUG35F4KJOahjm0NleFL7kUe0DRWP 3Zy/i2TUMtkrS7MTc4vmnWBghOfklOnM9LeG11vT+PP0N9u0EB3+j/gHUEsBAhQAFAAAAAgAFoVL KXE1sS9mGwAAAJgAAAkAAAAAAAAAAAAgALaBAAAAAE02NDQ3LmRvY1BLBQYAAAAAAQABADcAAACN GwAAAAA= --Boundary=_0.0_=0056890014795482 Content-Type: application/octet-stream; name=M6449.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=M6449.zip UEsDBBQAAAAIAO60TCmBk83k2FwAAACQAQAJAAAATTY0NDkuZG9j7FtLjCNJWvawu6CWJoEFdg+c QsVKW03brkfX9E7XMCtq69FTu10Pyu6eRU1LhDPDdnalMz0Zma5yq46c0AqEQEjcQIILQggOXFkW xIULe+DAEc5w4MB5m+//IyJftqvmpRVI5KjHZTsef/zP7//j9w//+cv/9id//Yv/3mo832x9ofWj N/daP1n57Cfw7x/cm59ttf4RL2/h34/evHlDH/0A//4e/978//N/5vnPP/tB66PWvS9CbD/3/UKy ePDJgz9ttX66NXg1eJU9yB60Fp57X/xqa+2/Wq2v7r3F/x788eKY6vPmzc/c+bd7XvL/Z19qFa/V v1e9/kJlhd/+0t2vb+P1D/H6L5XP/+lVq/UXUOu/tKr/aV+f+MZijn3zvvp6jtc/wuvNF1qtr4zM 6+9h36/h81nUav039n8Vt1p/hfd/g8+/0lp83Lndfs3nLvpoXXr+/GvmtcnP5rrN+W5e85W+/9u3 F9dpvr+SrdYP32otPE053SX3Kr/pITp+50slPe/+cqv1/Kdard990Wr9xhI9+rQP0U+P2/8VXg/o j41//a3v7fzdW81zRD8Pr/rlVus/frPV+l7rf8tzfNo/vDjd6x+fne49FWcXT/ZOj3v8VhydXYhe f+/0YO/iwH7m1QbU5h6Kg0NxenZxsvfUDT7unW0cH+6Lb/f3tzZ6+9uPNz58srXl7Z8dHJ8+EWdH 4uTsOf11frzff3Zx2BPYS+w9Ozg+81bNPTk/fLK5uXHyaGfnsXfmZ8lApWJ7c3PT87xekqe+2r13 Pg6jcKrFfhLrfILvDyPlZ2kSh772+mEW0Zg0mSZaBSJI5TATwyQVvkzTUI6USIaCtunsCJ2lSk60 SGZY5aJ/7j1Jk3y6e68315maaG8vz8ZJuivufVvGYoZ/AcadKJWCmk+5A04eg9Yg97MwiT3vCPOy VMZ6mqTZLROFVvhLRnY7PVV+OAx9SatoMZYzJQZKxWLKa6ugLXTuj4XUYtfjKZ1QZcOOnGWdNJt2 JlM12uko3dnc6WbXID9NJuI74SXmhB2Nk6pMyOi91VM3H/I8M3E/BHMimdZnpSPf51k8Yxip60l+ 3dncLDe8SPJrM6frnQ1eQYrhrOCeCLXIEiFHqcJnsZgoCCPQC5z+/ZGKVRr6Dc79QYV1eZjJQaR4 qhS5ppngzFUY8CvkqEN83xUkHZGNsXOQ+NCtGLQJHcYjTK6xnIibOg3IxjIDeSrTOEkkUvVRHqaK Zi9Su0q8MrbrhLGfpFAGmSksJ+J8QiaAmX4yMUvysFLiQaj9XBMdCdGuhJrIkKgYklkkqRZ5nOGD OLnqij6+X3qeqxCU+0mcyRCslq9A9lSmdAASFC3LQtWCaMAEbCcHoL4tBjnUMZko4Y9lPFLaLDVQ IlYqIO5AhkGQKq3LI0xkoBy5JaFtISdJPNKwA3wBwjECU6agcACTz+bgus6V7oo9AUMdja0xgDms 7LcIahYSKaHZUSs2PtAYGZ6QvHklywDNwwZSQ6uSPIvCGOeE9tGWhR0qjIx4ZKpAAZ1WDPOU3juZ YJOu532LthFhRqTAYU1kGr7G2DE+LPgKeWojTjowa1XB+GxMFmDZz0yHTVe9CGjRfgoexSOekEzp U9CY66rOOa8GvzkzQtTeE7IdjIQ+Yq085fGkj1M5jxIZkP5OZObRR1kIIetMTuB7wcmL/v656F1g pH9Jqr9uXUFsfQETfN87yaMsnML4ibr1uruwQ/pL/N/zUOeGLraT9QUHdcvcvTwIk084lTXOLaAi tl6ZzstVdEZqDWWGZgdqCJUIlu9+hLOewK+VM8PJNIJCOpmy1zNSvwpJqzIykNDKDMqaGf0E745P DkU2n5KRjEIsaFR6HQtiTwnvZCnViw7cHrJ3cG4d3ko+eN6BM6MVzu5jBzchoJcqjeHTD+MReATH DLH3pb4UiHS+EuVDgxlgHPbFwcXeUV/c8mDwUYjALlYGJBsFXHyxkz7+88kGe96S8WQk59Zujthu mHPO/Ay3ls4sHuCx/rMeYaf+B8c9cXJ4ckbj+7WQhL8hPcfpjpEeBZCQDXOYG1fOphuD56RlFJmw ELtCzZgBcuxZR7i1yWZ/tL+9uf2oWxWjWRz7wTNcJeklSdPRwUuQv1kpc5IaS339+LB/dL8NJ8hL SXL1RC/eulVHBL3g2sUp9N/EOLZJrGG+QtCY4xQ6Ie+awd3l2TKa4EcbxK88kLHBcupMRmFgQcJE XoeTfMKxJbwWiEvZWGMdIpsIgRfIpwGCNJBWqqaRZMyFqclAJ5HC52Iwt16lQhzJaY5lyJfirMeZ kZmcEpiAfdHRE/bbBcHCUawpVCLYQKRYAdoFRsNhEIBMhB8y19TE7gkGxjRljThEWoENRhSEu2tG oZSIQs1G7+dpSmrVZJEvKUQK6fuK4QXCgBDjLJvubmxcXV11yQi7STraoD82tsKgIwfko3ywHCbY 3Kahr72xDBABD4CUKPiH6hNsqHlud5xNABxvtSfz7Fm6Fk3JRk6GWvWQx3pQIHPSMWPHWAISSAhO QPyEJuk7mH7XGTqZJ0Tl0/oIl3EgU+v5XdKDpUkHwBwsRNMJP0iEX4iTFEzPoW0qA/qQFMo6MxMM ab8ujJYBCBbQKp2F4FUJcKByDCZTwoYxopRPGlJxQlXSiYQyfs1YaUq9A8gqglI0b/N3Fk/QFhN5 iY1DkpCDz6SGoNwfUyr2WrktmUvsgoxmwvyjDmMJ/obCG5noIuhgNA0VcdFnXgrBhnjilQUKA/gS G454r7txUFdw7oVx0zwlyEVDJrBEB6Ps8MrKcAKJRUeMedrNPIwYXwhjaJevcG2sJKWQwAJRwBZ9 peCrJYVvOWLIwf44zSNGueTs7tphOUbQNqEodgcO6Bbqv4CQpc0bM+fSmb8bz7FLIkqQY72tc8nM aYup74r7RI5Tf8tYGZB5J75dDJTYL1gXSz3cd1kDnR3ONSRfFxhDAXqKaBlyGybJMBkHkVSLLF+n +IEkAu/ZIcHAkaJ1KEz+KniNjYxz37BCk5z6k2LSYwoB+k5Hs+p5cU7Iaeul97bnME+nxDwfCzfY lc58cMQWRITY6op6OUF8Iie02gWRd1nthFwiRXbKsJEG2O8TzuNNlkoshcxgu5QZUv5FyWBcG69B oiLHNVHSoBJpPzO+mW0YC73Yevli++WLhy9f7Lys5WxWmRWDImLli3deLvHlVW9XcSQ1X27tvOtC l/GhBugUfr4qm8qsii9FCh/lgdo1kSmEIdv0dbmDrPkt4yMrzlDbVbDMCaZRqCypD1QUwljmYqrS Au4hX+RMlRI0NzlkM0KGWJlMBrTUJTuCSH2wfMBrsO5MbDIHtgUdbfyolSqikUETcD6wUYZGbiVe oCQL0SO8Rn5viZsRbUhJjVzKoNAWKvO7xbyGK2V2RzIzRtq/O+31Fl2fjTC6sIXbl2C1X6JDtwUj lxuZ0kttPWtK2qRW4JZ1p8TKqaQCkAkU2FZTpYoIrEZJDDU1PnEFQMqImUtXZpIFU8DaYYQ09jKc Tg1AcGJzuafTQkPTZZxcRSoYKWtjVQatTLVvP7pgwuC6JRSMtQz6YnUrtWpPKywnSOdT2hMy3rZ6 YkoXJCJb0akAOpuYEa8v1ZxCAOLs2smzXn+tbV7F6Rn/fXH4a8+OLw4P6O/eB3tPnxZ/mBG8Dj44 e/bUjqG/ytn7Zycnh6cHvABW3vv1NZPTrJ2dm4L5miOOVyrriamyVYSQItw05VwBEMBBUT4UcrHO 9tbWY/HiGy85Bj3sFiHClmRY50cL9Zs7cnXwagS+x7TJUTiiGVvYYFMsPltLPtte8tlDzN7CNw/F jnhHPBLfEO+Kx+ITfOY96HzG/7yb5+9v35zffPdGiP190HRzcsO0nduqwo2lVauPckqgXF3VPTdc v/gc6BCrH1J9Lp/dMuZGfMAQ8XMmpYw6BvJpvkoR673exf59AecCm4LbKPlBpHwONOxWF6TiKqft 5DodBfsNCuoYa9d78P5n/M+76T0V4yAVkYpH8DSC3p8zfre8FuszCXOhDOaXyGIG80zp+5+FD6L+ GOW6TTU+znNTrFAewLmEdaIZvjocUVly5Qp2+OdIyqrnThbducJut9t1rtSGvYCBqn0+D/Vc3NW5 RNERe3El1auCPgdq4JOBv2mM1aMjDrym2rorPCecPiVn6+f9+/iQfLaL3wxyDEBGAk2SIxi3WHw2 2Z0ssEt5kTFMKDqzOZlKHkGhE5leklKf3KdgjD2faRdguGq9evIt22Pdw+tMxZrrz991Sx/YJQfz Ep2kyTCMGKoFmNVzDvfUONxdJCy+uRyzJbLYxCwl/XGV4Roj2pS6MNRq8xgQmqcEpKmECILbFjwI IJMA8HQmoxzA5djksE1fTzABeenM1eEBkMg1sOy4vtHki5xOI8ordjnUNk/SXK66pR1ikJhNqbGX PRpObXVZMlzmSr49QjIcakp6G2ewC9ItUUQ3aVze23rUITEYx2YqNCe9b2nBMAdQPwupdENQAxKJ LMBscMvgRi5CLoiFRWIA2yIpZvbC2QBn8jTmm9vXKk2Kg5jh9TXe36SNKQPLCQoZ1SxSDOIM5M1X wsX6EHkYBwzfmX2UAGElwspBDmnZkkaTrPZShbCQjqHYap00a2lVXHQh6bS1smGYUm0zJvM4BqSa TK3xGHO6oqtBU44vD8AGb2Ab7WaWsMWa2A4KLbSFObSX8Z4FPKCKzySp6V8pB1tpwmGgIh09DoeZ q2vpfGDWK0YVt0hZciUJMWec/I7COLalAfrADO6KD4nQPKaN3JIVu2U4Difg84WvSUJSKllqp4A0 oUgzSlEB2w/D0YFN+pOUbuP7BWQyrrOEUFYLlLYXplyp5O+5Cg9YrYtyGn3qCc6s4qTjxmNUoCj5 x07FPkY8SE645mSvr9kJce3eq9vOMp/U9cSzmG20dNdk8DHdJHeSYWfAVwhU7DCyBaVJlFfVtnJK zWk1aKAqBBy4hHWUpvd4U1x+8Bo7wshud21LvVrPLF2ap40MFY4SY3pMSsOXec6wwqFjNtv60rl1 t/Vwm7PERb9FixdHdzpuz8/OxNuL7C28uU2XMxlGprOjYgE+K1JuL0spyb6b0XSlwzf4JjXzKc+c 4626nnK9MaIAZ+oQ3OuwIEs7kZPSAa2V8cVLYVlX45BSdShXnBQproS1wXfcxrZJkqpVbCNDq9e5 YG+0/MCFXzglX+oVEsV0GmylVwjf3gZVfCd1eBT9CZXhVDVWszDJdd3TktZSrm+Uygkyk5eYLkfU YCL1akWzslmgYzWf6CDkYaq0VRyuKe4QUYxn2g2PFb4uQ4GRO1dOpauKShElPlJsHy+XrpZRRMWK 56NKDuZlxPheOAmpwwFaAdkFUcWNNqIQV5WakYODsgsSzQjSXsm7qjW2DeM5qvzYQ0Vz8R9b0OBI ipMo0j1ZnGMZs44iOSKAigS0TUUDmknZaHE7k1pzXlKbEVvvvvuYCs32YKbVqV1cHw1g/mQsh71a art+2Ds+QGpJW9G+xVmrF3jkuw+oaGbvuCkO1lPYXT6TkbNfxWCVMcZdu0ugihwX5G5rjDAP5CAy qqP5ggoh3/8V02iho46Z2RmCg99kr1/o3CpCQs2gitNU2+bm4jdNsWPBXE6+3ZFCBOGALsXhfssA tqhce24BzKNAYVcJOaOZhBmZpHC+sBobLfClan2wOk72xwsIjBi7Okyaa4x4kdcGXCxaoovUBloW l5CJVV54Qj1NYvZIdgPrrctLxS7lebwvnIUp69eHNomxXqa+iggSpT0KCw5OI3U1HHK2xKAJb4oz 3ycuulS9a0sTuoKuq+HFzQZII6I9mx7ggIT7KdHTE5yAmLHAPd80/HJbZBJ3qH46wsdliySLvW1U wJULOGa6GBQipUi53moOruJqema3yYz+dLic0mCdjbddoxN0idP0eNWDy+BVrvkehOr0BbuLwzai B7EdQWOkbPsGW7nMxp2T/jNgVBtKlBtTCQeLSCBVrLzAOlBnDI7knEROsbB+12yACeMfgxzg68KU QBWc446pbxQ4aWnjX7W9YKFxzvP2fChwUNFnuyJ9MgH8jtrVTy0ec1mpuxpxN4f1vblFeGxvFiym 2O/3zOwruhpmKbAhm0bUhZqOuW7i8ZJhyzQq1SO0uTkLuLrpQBH1ZRbHd9EMgfsLR7HQms4S+Xlk sj5n+6e1ocWVrMU+jDIscqRegFGiKpZf5QSrh70ENMdxu0HGdDHRgBgcsRi0YlKYkC+mUgHRMYhC PebKhHM7HGVcSHM8LpIQaXhomeMijjsYsdKcgKkyzSAlp6Fj73RFtUcUwS6k/fgSkMgqym6KG2pZ VcN4lkQzGsS2UHEB9vq57ZmmbNOpRThaxnN6lWKorsQ4j4OUXX71Oo/TfYRsGhZ7FKEQlOlSiwRa 3Z4sRUZXcq5N8JZ+RpRSxwZhRVObiAOPK94IKPTebsmhASaGMUYQrm1BlxWH+oE92pH7U6COeTqh YgnnPI4iGcCWyu5QYAl8S/0tpIw4xjTPNpCv4MVBLPa/QFfk8CqusDNNQs5VbAO3us6oKhLNvXE4 MirY7Aqi/hyYMN0/EicnoSEJZ6Rv4HtNaYa6jaxDaAvVHXXFUHJrkozDiSVbprBihD/dtg6SVb2g QRANnnXRjni++k2oKWTGcFyr4vjt2h19eXdpu/NJEyZVtdP+WE0sOLGXnlpF9icJg7zE8K4B/LCn XcvX1zV3/U7y69qawq7p+gW5q9slI67pCGDLtBYUjszd6TU8eqV8y4XnI9drbhvRa51Bq2u8SVy/ yLW/y6j0PjzqVlp+yhvEekc2DVvoPqmPpARd2C4PG/SLThTG9GyTMcxxqKjzROldI2Q3Wg2pgQ3e Z/4efyFUmibUraDDyH7s2A0Xl7K2UeQZy6myjgAZOnHdLPieaSh4sQ3YfkzN/nz/LM3vQLhFhUGE VVry0R7UIkkNIP3OYMoO08n/ZEDtqseZcc31xehCSWVzTPM8WwogtZbUGzVy3p+kP8qh9sAxReVB RpNEZ+aknSE1/uPzSTIII+W5qoK9M6+yhJA03xN/SN+Q38bhXcBd0lzGeiiLjqtZ4/Le82qXBZUL 9jZ1iPtKLIi60O46CzwvGYqSBaZuU0AM9qQUlxGiqT0GRyWkBPqRdpjeZNKr2gHMNbtccqriJ09r RR/7jDvYTGyCMMcEjkvPTUBb8e9migklPFhzdltrz+2KMxBEXDUYmyBZm2CKogIXMkBKWJDocmmn QSOt50switg7SmVg++/iBcU2aSz+B1ZCnqUhMMBoMMRKtJajNn7DRKSQTyKWUzUHlkeXVFniWbfC ekJhhHqeSw2h+g6lrwTVlIyZRbrZrYjwTvc9GWh/7RxZ40BUw4h9EzYQPYxB1VSIlLe/VFfLaqx2 6gK5VQpjlFg+PzvnihTjO88zOQjigvHndUCWxyFyuWjeyEFpCUYsIIHA6XJJFwZDekUCLao0mM/H 4n4sTmI4QaALC8+jzNO1uvApTNcZ7Wl/c8TRJQZV9JkLc2yjhWdjBZ7aaXYts5HBPwwCgTFy38iz CPFcpybbYDLa5lRLOG2yZSqpx8SX2CCZ4kaGT1jhsoV8V+7mjMjinIiKCUSX8UisHvR95Vcuxkxc M1YtAbWOp6CZWQ0OJjaHSCLunP2gu/1oS7jUY2tjm++ShkMbsUHmWEUujSYVmtHPNoEouUvGpcAE cvOpvfax54kSgmPthoujAqiMqC4IOdyp3kP+mjclEuw2blt2YSwFqs2aElBuf8EHVmwcn5euvtIk TN6QVdF96XnrYMP2ww0TICzJ2xv9numdu8/uIlWgBl/GCaMpWeW2KRF4Hv8couHy6+evdp4ZRMLS fdTdNjniuS2mFhdw9emV0OI68eyPT8r+zWpNthmr6quRzVC65dEt/YqNSB+sgw/4RwbR3DRwZ+Na H51X/gornhc6Sicw3Kr3bLNJzk0Rh7pdh3Zfj/tl5XVRIDWpoGm6BAn71UuJjcOFS3bKhIsw6vxW /SYjNL/oMT7XQnSXH9tjMX7ksxF2sxnxQlLeFesawIJEtyXWeny7Rf5Ir9F5XH/w1s7O40edbYJL Lx5T1+3/tHcmgFUV5wKem431yqKiIuoVERNNIoGwKgoEEJAlEkRBNF6SC1xNcmNuwqbWDRW1+tz3 vbTu1rVqX1uXuq/UVqtV69LWWu2iolZF5X3/zJztLllAxac5+nEz55yZM2eWf+af+WeOKU2tRGrG +Hm+Om5mnt1JsLC2Pcw4d7KXFLkppcOGDos0iwTCM1WEkl0+XMdLqyXhyEA7XRdIyqne8wfqCGTr aMtDwq7xo+lya9t5W5aslYWMzE6sDGgjWl+pmmrW6M6eU1VZHDbi1TEWdW+ODDSJE4xJs2PEb4ZV s6afzZbhZIo8aXjp0CIjP614TS6RTDUtjy2U/lJTnFqwHcVBR4IIhfUsjJQrb2ZSUkkk6TBHY5B+ zFIZ85g9uUKX9niDayRsrzideMc4fkTpsNKUSugK9mxrH8LhdPOYMa45k86KuDOn5prsSpFyTWVM 4U7VOTJIKWOBIMqI9qo7RG7YTv2hTNIVWtFAy19jNNt4szs4b4ZVTBuhm6T02T/TIJUPL5bSY4Sv JE3QFsfMYdebcwvtgmAzvSl9GJnltT0SnRV10aTuuoSdhqmQ7NBdBE9QFpkRGFpeOxMRbKxFrHtD aKbd92SEDsEUm4yRKjMZ7E6Om/gbfVOkqrQXrrCUzAjOXMuyFq1/JseEwyV6tU3UFl+jnEUa66Ky stpRCkzzg7elicZqCaratcuQQWhrrkX3zVjkl+2Zfl+1b5KXBiZBp7GIx7SYwmICoFOsB8aW+seN li1J6CEV7SU4dU8la6lLmAeJOmmD0d1B33ybeftqEVESoN5KojqxqFovojG7G1TK+xYW2TogqVsi 0xJaKkRNTdFGwXo1oUmqYpO77vr8pF1NJ2vSncX5yxJ2DZwJt9gdhPOyQ3sPlK5UswknD52QxCxF h1cqsWyzbKU0P76i5UbCBh3sdceiTTJQ7S48SouWb42RPNaEYZ8b9gZDnWfq2NpJBd9Qr7uwX9ef 7E1YVK8AsjFtOwvTpmIDSakDaaAXEXb0E3O3N//hyO52xdoo6dWm7lQ7E1LVKEa60LnJ675Nq7EL TK41ijm+jhYRdcJpLbYi9ctLI5MDOkTrnT7CHO8qHdIibVy3TQfkiPhN6rnpkJwGa1M6b8bC398W G//e6Jvpx5pRDmeQP6B/ldoUKiwrCj4ttXS2o1DqgMxKBmm9jDCxo7xpM/X+BrNQZqs88zYJRjc/ Jh2LJAWDd7h6qrVskEQ0Q+G8Z0tjozPvpGPkqEjuqw4tkiIvLV+iyajzjlYWWy5SLlC3dQzTujiB V+XNPFuB1mImA2cicnwxiph156aFa6OiSSY3xRbTA3K7IXqSLdmc+T2HFVHwbXzcBSamY1MnTZ9Z PkUj1RTVq8QSi3wyIOkGU14UmbMs4aaVlsHeVKOvYukAa+OL9FrxZn9YEo6jW0i6B0WNNC3u1Lse NTfT6PSbEjVxPW9lBh0kGDOIkm5nFyn0DEqNnHdbB988l13WJAGliDxb1oq9nIwtr4k1mvD1lE6g ETL97LC/SbANRsr7xW1B8E3ZmuEM/1CFJPNwya0Mo4cRbwFQm3lnZZTJP7vnzko7WZYpTP9Ucdy/ qssk0CZNG4+XMAIPtbpJu0qfO7iji44v8cyojC8WOgZOKpq6NFvGlCRBxajATJppCegOGAWiJV3A eFJGhaXX5RQNrfGlNNiF0g+PNeukIFFWNNRUm/5rtQ3AKXFzZ02XcLx5/bKiYqvTBIaTjKFuphgR af3mZhGaNSPR2oR02JzOWSBFZf7InYvQhgS6NNgm2K3PU2IyJuPocaJEmPWiJa3I/0LbWhmp71mk T7HmI85QRMTeEXZWJkT1Aj15Net1uohle7XIPrc9/YsSXZqDwpX6LytQRUl3hZ8zv5A29mB7KYWt NWOJ1MYl/Z5iG47Or2qtR1RLxa/WSnK18cptkRmx5BLj0wQ8mdbQcRf5XimQ8fbJhTZ0fdINUwSS MYexcZAeXnWgHAaD9t5jcWJhtW4QC831qnaPwriDME73QbynKWCtd2xTM8vfWFldPhJJTwxt/ezb VSE4Pp1aabz6Vmz7P44SJY+p1gPY1c2kWEuTZKOOlx7al/DDWVIzIsu39QUdGV0cC4vc4YfhpZFJ y7U9gW6+nCHE7H1M+6oVCb2wtsmZtFgUlTkzEbepo41Z5vZE0jnjtIHJvdZnDc1be7OAEk5HJgKz zgNKQHoqcCMn2qRABHqlkVlGkLZjrivNs1VZZb4r0o7pLvGfdcYrJeSaprje/CY451VeWh5xIuKf 7JJtUnTqZZ3qEjMYM9Pln+ZKTw6njthVYkNlSG6ZdFe9wudvOz37IDMLnXBbUucFwmlvwAPieicD G6hTs41C7mv4bd2z6xHMnjm2XkvJzD63659walVm0Hfwm27ZOEszJM2oFgWtNUeFc6tczUGGYdut hxT71NH0p/haNHMxS6tWOHeWK4joBzhRMX19Y2LUnFaw9CyYbx5EipRbMz2DSR1G1nTzVq25Qi1L 0+pJs2I9YGYmprOklISTKbHE4a2mlzHL2liznv3PUjykotG/qlkSM7bYcX8JGzZUrykLrPbw64h2 OXubL+T2pxfq3I82GBGSUqrTxzoylkodUqBkTm22Go4dA3PCLYwWmc6fz7LVPkDMNJyMM6MqKZ1x b5TJp7m3Iy5eYfKskFutWE4iIkf1MKTsz6DH9gutyZuccFsQuxxZGz34zRd9r+LOHbf+2Hq9TUSL XesnA45WHDkTxcVtBOBUuox22RLQfrPm2iE0ciIiG4jyBkVmmtsMprsztHXOfKtuqI0aIkGk2WGI ii2qou5123x2S1eNLV2tFCxnJk3nufaVve9J/ItkXygn9zPIPHlFm3/tF2m6wHoGqWIB2RyzPYjZ ZsLX6VI5c/akh2taEDRbTc30qJPyy7RJkWNLn4yMNGUnMAnszxZd6913tSN/zqSHfjd3gDVlZFev Rqbt0605meDmR22W/NDD20bNEsU8Vc3ySoKpXXZGxDesG3GnwcyJEpml150d5xEtDaRf3QpbEp0F WAQu/SNrJI28q/V3EZ3q6NmYxExexZOmggbXAcaas+ibXBziUzo9jVNCiTWYe5Y4Wr6e0PDr0W5X mxSgLyvbc7g6sh6Bc0YTUqWkry9u1OcaMyoly0gcL5JQxW5Nb/a2FzKdFJvfZm61NmiOOGVSRaFt b93V3xJKBbcWBSVaBoXeRKw0MjPd7kB3rZyFIQ0xaZxQEd1SFGu7FAXNf/zP1TMTvhEYT76kFqk5 rRUJnXOuOYnkfnRpilmN6e55ldcbLdErqWzhlICC5dNfOPUOxFPQkpZKRyXebHrN5IYroJ0CL+GY Qu/1mxfGTP/aHRRLS4iUQpFZwkqwpp8tc9r10TrfxFgwRM/6xyuTTqsQbP38AsspYmZ2P1ZrRhuN 5uUkj69ahyNW6tWmpmWWhHQLzqI2Ck7bw046gdo5tuQfWEobGJKApHpaI8L2jba1NXakJ1Htuzk6 XmD7RTMCZaebOLEovjxWa4qOyR37pJTCn2mUzVg7+Hsb6daMjomDm7SZC7mn3Orc1vqtp9hm1DLj 7tBmihCW4q63nXQVyZLGJr1bQcPSOH9o4WpsVOPNjkG0nUFrTCScZTMRU9AivtpkxxMirn43rA39 jsCXxBfGrfWYLmeOYmqqPeqDUzTTZsrc6SmdT24F9oVfbHo+0qct1mJBt2uJZvMu/j5cayJJNGCz a66VKU6FS1XCA90EW7SyvaBpBgqHWXVKt801QaPBVuSzt5jHeddip7Z4A0uZx96MBa9dqWT7X7ZC 1sdra+tMI5eh/zXHFTGOiLeJa/QTs6LDGa2SQHxdv6FFkdqWmGNjFTW21fYh6alYITvWe5LN67Sa 0Rpn7ICuEhnsrGenqmSQ3WYeVL+SngFdFth9VKK/kDpjrTpTpai/nfBGsuN6OaperDIzKusqit2p EW374JfbunlKygJweYod8XcnNiLGTGmojqnc52SEY8rg1CJJYt1oR001lDACInio86QsIUhauWMv cuxRoo/MP6YlQA/U2y7prb/mVpmfWfIjgjtyjBvWMaZsZf5p7xPbd1+J79jD1Y5bjaYZ3qjU6dTO OEd8RztfICVimT0F7nLvjRglzH0J0UOOCQzKaM0qPe7GEUk7skQ589Nbfz3raP2qq7e4ryByKCXl I/5cSruaLV/klEzo60uZrw4tau2lO/gi7Qqkvefcnnhrb97ec62lkJNEGdPFf25YR9Kqvec2sgy5 viOm15laeGQMybb4vsITON3BUhNIlkh1dfWmxdv17Q1mlwRmUbx2oK2ZlCwRaSMKAUeazJ6sByNp 7BcRF18KTo/6TrdexHQ5tP2JYEJ659slLJ1Itu9F2s6WTAG1UroWppUuL3EypUzHKiA5PbdSips/ hZyTGymqOvCCOjC3ux0sgb7ep78wmt5b2poAHVKwXI7MvJAx8HkYuSvbOkZzY1zvNxBb5ipLUevf WEFH7HYWzTLFJeYysqoxHPbsb8w2f64/v+GBt3wwaQwM9KrUmHxIKZ6sl3cMh5ti1sZGfJk9uZO6 RiYTKFsEMT2xrMTt/wdi7r582PsKT6Rw+vg5M4rsCjC7fN4O3/ti6W3a7w1Sh8NmsZHzMK3ymr3B zThko7sBm+mNNqRPQ+pXkhjYhZmB+Lq551hnuwaA7kI9vx2g0w91jACtTb8J0dnkX8rBZK+sjE/L A2tf5CZt0pw2yheOphYba6OdupmolwbYrrMzOaLVOq/z7C4qNJ5kXVms2F02pfvoerRHlI84SkPc TOnpobio3TJcgqw9Iqr3cXd1d6MvO1EShdlbrmRLd/Bt3FEIGcNzBrS06qKHFMJhd0wBtaxqfLWZ L6oWU2unT+68o4QkA6HRyOK6xELaAruNYMLUkrBxF9tF/3Fdwhoi7pdLxK330ZIc0+qUTVC7CCOh vywhwyf10ZqmhP2omBsJb5vztAEXZ1o5GN9wON6wqM4Wb7360yvfzrfyfAaNNk0I2li8SjI1LJHn pS36st/EsBYuklEpCWd3IDjS1jL95a5wOPBa5vsFel2GWT7frHeT4A7ZP86aDASD1RJB7zJVZ+fG vbE6udIc9ybf9aBbowydSARNuthhGVlQ12AMZgOKv45p1nV6ttlcFFjdFjap5ivMC8VYTS+zr/UL al00S7VgtovGgjI9VUSn2mts/LIxHV6whXAX76d8LkyvldXj2nbYQ6QVUtMnZXVAmSWtt5VFka55 hww/1DPH98k939N0aLqS+KVcYFTQv7hXAjJfhHOX9Jvv2Jk0yvAM36qBqLf7mCPqZ7Qsn+Tu6WU/ QCj7IenQ/Ma5PiGmv8AnduXyoaPUYLShdcROMkkIOiTXHjmjbbc7GJRu1p1ir536sIyG22YqW282 RRRkT42Mft046U07vJk8492JjNnRw8xxOCtfI84oiBn/8osLM5HiiTbveakbTNW3LDemfpWmgddB BaeJvWrUbLeMd2xqs2wp6Qw3poY9xl0F5W5H4yzyKc4UV5M2Nka6PMjjnK1XiZsYCQxsScaqorIL lBQ0PA/URV2sIR1PzW0ZSxhDQdsG1EtXR28gMtAN07zGQLvwnaBSH2oWLbmLSpYtiTUvsdI8JRBX Vscb3Ii5Oxjqgq1bbbtdkDMWZffi0ddLTbdyWIroaGu1m/O9uK9pyVuq9PFXnUUdXPQmgX1t6950 aM7aN4llG8vf3ExLLX0LpW8rdna6i2yKYStr5dKNPXw2Ho6cyigCrBWVXmrnaOZaNDak3mqzvjzr mpfMbdbUlA4wEZeNeOQdUuMi8xnBTbCd3ZN1SK4JeVrUnAw7UvdjdR891mC/mWKTxme6rQNLTypt CdTsmWpLt9g2N367b8ew3Eyo67Dc770mnM13dLzjznakmQWMtZn21i2Y/JGNtBpllb3TC3JnRtxZ kaBxjmnrdRM4xqa5qLMDbYUQqeR0Rmt8axyc+uI0HMXZIhTsiwWmZ5ylFN420WJ/4W+59ayNlX/6 y7r+BjU1CtLtdLecSr3o9BLqk7G6pbFkymoEL9Ipq2sypbyVzclU8ViceiLYcDv7JDqC0VeEAiY2 6U2oEQu+ahQelaKZt/H1VR3AHP+nVyWY0ZnV+5Tvr2q/3i4BwatSN9u3R0Cko2vNfDsEmE8+uo+2 iWZ9mA4MjYdbDOTeSSm74Qc+zxz1LaWpTd+CXqZgd9Nzm2bLWlf3spO+5qzIU+erIL6PprmxrJC7 tKhwvEcKJ1fMNoZo7qCEye1mWfvRHNwCLGUhZLBLllJ+3Fk6OxFszBn1gEe8Nuau+tLttS1xwZWt zoRg1P/9N1+O18bcfblQ73RpkpSw7bV+Bf/K5WRdfPESKQveKI6bvjyrSSwkWsxMatzu0u4YHXrz 1o6Ng9t5E99Gn6qNJxtlzzT91BIt3OXR/s6r75uEuh2X1Ep56Wa7tW+z7G+iQ9E7vxQabVa2mDNd LGPo5UzHR44QJbPJaCU2te1qaAlfB9MUXyTp6W3452mnnuWtY3NqusBztFWO3oMsqIp5FuZJ/yyq Z2vfoEcrdPxtaTQ+G0UDazIf8LbKhHjMWIvGROznOnxFxJGgVsfWpqnOrjnBQEqD3/pw2zS3vjVE 0vcaDQaRdFMhkroHsJxL2QfYSUInDBkNaIjVmfV57pCAf1Pg9J5XodmWYmJlkffoqW6Nkl6WREK2 2dPjSHYAyGxU7HUPzfiMGULRzV3SluCAybpsveEa8Fc2xROy4f1Aa8Hl23Rba1ppkq5Yj7uk513S fJnRa1EcI0NfJtrUWOLYXrUWEf9HLqzU8bYh9xLJ35tJjZCX+Jm3bpUwMi7DK4xRLsyGs7aJd3oM KY8osqZlrS7aM8qC+yFwb0jYDGqkfmHcrngMDBmYdRAUG/3pOPu6yZpEoydSAp/Ck12mw2VDSrN8 T9Q/mOI81unkZ/kAqc9Heouuq0BqSx0xn4t0N4JI3TjW1/Gz+9NKlq4wrxSIXMQ7dPSM2NWRbJAi Yc4mWxb6TslXvSPegvDUcAKHMV/wHTMqy+dOnThploTgH0/K4t8qIv4ThDD+wIlTdQj7NUUb6bE6 O9ZHCidMnVyFkIrX+77tlCkOcp8EMLVyRmVbMdDirSlR550gAPGoM9Wk5rTo0mj2cPQgqv+YUTlt /Fy94NTO/dd6G7NnCCWD//JZE8W77nz4eh4Zo9C8sDZ4Au8Vs8V7Ver3QzMF4JuucL1XVUyaOckX /wo7LO3bZcgXVMb4V0z1S8BW8yBTDk6ePungGQce7Eor8zUprbA4OxJpizr9DT+t9UTMutHZzkiR 78Yxsk+2UfhmpW1WlLQeZdZqjOkPeRsZxZPOhmR2xwLd/3B628ZE2r+PR9hKxqwf2HCWfOvT3gCJ 1xK5z3a0fZGQ7j4sxdk+gMIRKRw9ZP8pK4ucSJspDZuguhhH/SO8xc5+RjruFeNn+gZcnDc28zor 3OHZiDP24DZTJgp29b8NX6ZQtN2ojEoUel0Fs9ex/dyp/siWsbVyVjDOyLCv/piUVPElt//rjlH/ ZvZpaZyyoMoOG2baoF9PdwW+L+aMsw8jkpXmm14ldbRpdSXx2jGR8TLOqS2FXVUg6s94m/DWo5b2 4eni293+IiCvS/1zdEsDG836l2PNEbEfjuxXUibPybRRmfttYC/h/Ftx2YE/krDRmWCLLbdzMbrN NroLmd3SaDZLrpWZaf9ok4lk2Gkn/G9oXrBG7xripoaz+XXqlqkySlwTjuj5q0bdnKVXhbRq4Jhh ulHT9SKcXjHKIoVVesdvJ4J7msiVebUkMC8aqCH+JA8mclnkkLKytCQOh/3Dr3FvB2vTEso8iPkC hVUX7T5uvnePyOi+nr9tVyq4ZoJpuRgOZ8/GLDJkGAJkpv3ytZ0naiXNwmZoJF1gBnY1Cg532zoR /I5DsPyLQA3sDeLsHJeyZxNJ53/t7AnhvXagbs0N1q24nadeElsezV6hZaKhpll64812rbQMei3X g/X2hVPLdtalkdFA6aJU1NTpFQxmGbxvFbyvhvvWwJfLMvi29iH0BnXcsZxA/I1KN6NqQokdlYgm 48GZo7hvP6psT8k2e0S4jmf7fTh5dptx9s/spJR/90lu6xPNVMwyrMfJWOQCZaDYsX8QuazjWy1G RNVLFy6tTtTUtDRGne2I67Q+nuGqNoPQW/YUh72vSSyV3n7cGc8xM9atRlgrKtHU7TydHrC3VUKr ZaSoNbH2dZT2sK/Bd0YYgm+le4Vp81cpJT+cIliHmY8JVaSHlK0whze9NOtt+TtcjqeaPNVTJvpU cVh/caXE/8UVXSbchV3F1m7fKHBZYuJ989KnoGdIWhKEnm6z/QxKsVHQ9d9he7t7n+8r3ZkmUOMN dkBFJmwLa2xBCPsnR3UXzeSlN82XvvGn3bslrRPj64CnlUq8mOXTYyLR9vWmTHNqVROt9+pGzPYr szbatmylNFie/YQ8QbfRzc4+gk774yz6MB9JpImyvWWncaqL18ebU1sgMxphQ9L56bbbAxtTOpID dQ94odlx33zWSued7kE7PcWoM7HmdhY5nNxqpZ/szAS3UlmdpJNnul+4c4eKY8665KB1gpZFTve4 HIkUN4ZITmB213W7XW6wv0FU7a6astBO9kjyFdFaX4dBzyk5pmTEKV5XF7e7U2r/ZWV68M/qhxlH Z+Tp7uCMGXHxKX/e+hLJyUXBT0XZL4+EJ/pUaBmPStRQTApl0LFYfwZt6LChI4uDG33qVEhEAg93 P1wjMR5YP3ag04CZcZkGZ2Y96NMZngl4jo5tam4k3m4QsQZrzZceim9fXilQA92Q0kOxMyXclTUI nWEDU2Njz3pfawt4z7RFcFodCHzWhyAX1TcTsTq9VYlTI9O6gU2+Klca8T1yoBEqA32PzBh+4Pty HYywFKXAVseLEzZ8G93Ut2g9/jq8QL10tndqMh+y0OanujolY6ll2GmZtXlENG24zzSSxW4ymvaM bodu6rWNZqw+TrHW+oKELY1DnbWXcp811lRfsdFMlgYLiBYKJaYnU+K2Eb5YDrTyzUk3K7kGRkyc 3LQLplpHX9fKW987d/Rt7fBEtlcuG4rEcT52W2Ent8xYbzjsH3v21o8HjVL8LVT6ALQea6HK68bN GWlxHlcTeJxe09yS9BR6PWkQDM1r8kQNNs1c1O6ormdi3PW3rhxyvlCkO4k1S+KxpaYJRMI0rdD1 ojQywS64dlsqv9GSNIthO/0QT/siW9wzLZJvLTUnSmKy0NUL3c7RhD27m4TTi693Ml0/U9sdyHSb Voz1O9XFa1Jm7JYlwolGJ8VK7Z77TpR0MfGZemg7ez2zLdZCOhUbZGauoaQFV0K+CuF05sPOvJ+e m9VxazG9Fa34yZjDcrlbmiRnJs776pTkrEnBaLgx0WwygoLRwI9McMleTfEaY+GovzBQNqzUGwfW TewhZYemjUpMnji1ymkAreV3ZGZiaUyPwJWNHj1Kexya6nFowKPVONL9DUv1Nyzgz3TL0r2Vp3ob YbxNjNXF9UdCtK2okVVT7fqBuF5ZO1mqoMzWFgeD1TMelOxIVc2SlrqV1HLZPrsimmyQCd3JTTGx BqjB17RoTWJhMqH7LWP0FpCepYTbjuth3RhvLBt8R8b7rPcj7jdOZVJQ4tbUQD5Okh3OYma/tDnR 5JHSp62JydMaWkTbI4ojTBRHEEUqS1O0Vsds/xjdwoR8LVaeqVdwN5gN5ikOU23TEHbHsLWVih57 SdpuRlnZ6GKxJqNPxENGmoeMPDQyrzSyf/xIFIB4cWSO7DRRTwNSLM+e3HJkS0N0MQ7umRFtTrbE 5V2miId6/UnodKu5NIvhPd0NFd2xY7OkXX9lbbHUSQm0tim6qLkkHmteVBJd2lxC16LEfCo1liwZ MrS0eXkzadRStyIydMiQISbuow6NTBD5RH1JyrAIkd8/0SQrJiaWRg7S0ntOi8wJG0NRt0Majuj1 xVYayCsUDpxTwe/AonbFrblGYkcsdKRMitpYhVXn0Xl0Hp1H5/E9OvKUuhAuhifgKXgfSvOVOgjm wdlwLlwFV8OuPZWqhwY4ZGelFsDkXZT69WClfgNPwk4lSkVg4p5K7b5GqT1g/WcfK/nvQ/XuG6++ +6p643n1/Kvq1efVq21H84d8bDlrWq6qnKbUAfwu6aoapnTL62J/uab0Ndz1uOXcFsO7nlAxbVvn VpVXMW2AUl3s2Vx+zd+c7C/5vycsgCRcZMvCz+FXtkw8mVIuxtqycbCvfJyTUkbyCpT6wv8S7XR8 6Hf8J6vjbb/jzayOl/yOF7NeCTj+kNXxfPtue8bv+K3f8YBKO3L5f1Cu6raNmjIoNHxQaOSg0KhB odET8xSJ2H2w6jF5rFKhEHBzaHulumoPuw8KhR/NV6GGPF2D+9b23qBUN7mU02vV4H762uB+JvSc 7vJvyNyjr/TY2lwJqX7fZP7vCy1wA+zZRakhcCKRPAlegi2J2E6wH5wAa+AN2L6HUofBr0EhY3aB QT2DcucyeBy+hN3pmh4EB8M8mA/nwnlwPvwWvsp+rP/04//8/fU/PvfY/ff8/LqrLr/knMBV1aug /LMNG7qOVd1C3SUT8guG484vGMG/vQrmybWJco2Ic+/lrrubdq933V21e5/PHXcX7V7hugu0+27X na/dL7nuPO3uu95x52r3GNedo92TXbfEtXvBCY6beL+4XuL9R/1v0VcbNuSEQqO/zXz61F/wszs+ 3lTHv79bjuwR/UfWK39vnyPtCA3wy40CLSu0a6IjaXznxiP/21t/HobwFkqVw3D4ETwE+b14DMyE C+CPsFVvpbaGmXA0HAP3w1vwF/grfOmPdafj23N4B2VF7fBN5O0WfZBEMBsugT/BgL5KReF6uAHC W3EfHAhXwt9gj62VGg8ToAImwiSYDP8D58Cf4BV4Ff4N/4FR/YgzPAbdt1FqBIyEY+FH8Ft4GNS2 vDRMglPgCrgS3oa/Q/ftlOoBT/anvYMPYB3sRbN7MjwKj8Of4BUYTALuBjH4KfwdSnZQKgH3wuew 947EAR6AnJ14JzgdnoatI9Q7uARegR12Nv3pLO3U13pIAUD+126u/NosZf+z9t32Pa//uQNUr1UD Qqb+b466871O30BX5qP2Od7/Wh2BoE1un2V/l6v8AfQOQj0mTzDyf8A3LctkbOBo+AA+hPX+uGV3 BGrqD9QRUHjfbZ9DH/l9VNmgkM71DHqlzndbGtT2mfJo6kClpsFxcPxAM7azZFel4rt6YzwDCukr wrOwpog2C57eXalle5hxn53hEXjUjgENH4JeCAeXoT8OVWofOAFOhGvKlboW7oA74TMYMxwZBL+F 0AjiAKfDc/AmvAVFI5UaOkqpYTAP5kMd1MO40YQN/4b3YdQY3PAIhPdSai5cBC/CTXsrdTN8AuPG KnUqPAv99iFt4Hg4EZ6AXvviFy6H12G3cehAUA2Hw3lwATxQQR8KqifSjkINXAyXwptwzCTqEmwx mWfCBFgNT0/ucPv/Rdu3pB+5OQN0+7858vtzf2HdGMcn7XME/AQGltoZwMY4vsH3CTja2Rh4td1p A6pyffJhwOaqf9/rPsB32eEduv+3uWRhZ1Z8N/K/I+1SeD+l5sCV8A4MnYI+AGfC72AdjJxKGHAD /BPKp9EvhHmwGk6H30/rzIrN5vAOnf9fd77usL9Si+FGuBk+hr2nI0fgArgI3oDdZqBbwLFwHDwM j8IWM5U6EK6Et2GPWeghsAzuh9xK+itwFCThPggdoFQFnAznw4VwK3wEg2crNR3OhT/BTlXIKFgJ l8LLMGAOz4FSOApuhT/DG/AWbHOgUtvBofBT+DeUzFXqCLgR1sHeByk1C2bDeXA73AkfwZbzSCt4 CracT1rD0XAsPAa9D1GqCi6BVw755sZ/vvAdTv9vc+VZZ1X8btT/zVV/OrPiu5H/37QsG7hAqSPh VngZXlnwXUiE7IN039vs1rrfkpAe/1M9JlfY8b9sedTnUNp2uAr+BqWHKRWHI+F2+BjGVKMPwCPQ 83DKC1wEP4fb4TMYE1XqJHgKei8kTLgW3oF3oawGWQIPQkEt7QScDS/BjjGeC0NgKKyEk+BkeAa2 XER4sBCuhw9gxGL6KfAwhJcoVQnnw1PwLHwE/eP0bWERLIHL4FkIHUG/BkbA4XA63AV/hjdglyPx AzfAP+HfsFcd/R94AQbWKzUIDofL4VXYtoHnQRRqIAbXw3tQmkBeQhJ+A90aqU/w5bdwUCDoAaja zZXX37d69v/G4R1a/m+ueteZFd+N/N9cMvD7lqwbM8GzmfKfnsAWqyq/MvnfnvboKrgG3oPPYD3s fBR5DeUwHJbDg9ClSakZcD68AjlJpfJgGpwHryW/54m97rvlsEe+5Pl2X/RadWMokP8Dvon83a2Z 8y1K7Q/nwO+h/1L8wAXwGDwB4WVKzYU18E/YazltDDwD3VZwDRbCLfAhfAT7rlRqFTwHOxyt1AFQ BavhdPgD7HyMUglYDivhUeh5LHoszISj4Vh4DLb6EbIKbob/wAcw9jieAU/COvgY9jleqVPgPLgA HoXH4E+QcwKVCvaD1XAXfA77nsj7wDOw9Unov7AG3oWyVXS+IAY3wvtQfrKyfb/13+ShtOWP6f/V bI782pjq207Hf9vn+I5V0m++/us6/7MvdJ33y4IBm6v+rPfHrtPx7TnM4ZSHHb5JWXYEHAm3wt/g bSg+RammU76G9/gGhcj32uFaBJj8byuf7pa8gu6nKtUDZsEF8Au4B9bDHqu5H0rgUKiGm+E1+LOc P02pRrgD1kH56Uo1w53wIZSfgRvuhfvgb/A25P0YYQU7wk4Qh7vgM6g4U6kz4Wq4Bn4CE89SahKc AdeLccPZ6CpwE3wAw89BL4UDIO9cnn0+4VyEP4jDEXAynAKXwxXwNxhyMXIQroU18CK8BJFLlKqH C+FieBFegs9hPexzKf1pSMJNcAt8AOug/DJ0LEhCCzwEf4d3Luvo/M8X7TpSb3PmfzZXHn9b3fGv V4n4XtR/f19gh2+zvm2yzG9n7+7jjXBkD+0Dv+O99jkCfjbZkT3orEe+yeNeq0bmmJF/fl25v90X bhno/23Lwa8319rpCFjSfsccgczd5Dd1Dief/X19yf8ujrshr8+qJ75U23e0bdr1cqUGw1FwH3S7 Ar0PDoIr4F0ovlKpqTANFsFiuBXeheKr8HvV969b/fU6vlH575cDO3ydeXonfAFdryYMmA2Xwf3w ADwHa6HrNVyHcTAelsFyuBOeg7VQcC3XoAmScBP8EV6C8E9od2AhnAfnw1r4CorWePsN+Ka71q8P zH4FXYFD/RAOd/xnxObKt83f//uBOrxD9//arENZA9oYx+eq89j8R65ZCa77AxE1oDKkdrpt7Z6R 294Yu/NtXbsMhF3Ovjp/EOx6W9uhdR7/n4++agfVXYXUIaqXyrHnBiHiP9iQI7+qQM1UCdWk6lVU 1eGWe/L0TjNjVGhcCPcYJZs/TFEx7qhVcdWgFquIKlPFnCtTsmFJSBUMCo0brLoouwWNGqVytN9R SnYtSfU7lLM9uJo7KKQ9hnw+Z6tcfH7Ib6anDtNPHca1bSjleO4+OKfH5Hy15Zr31VZr9lbjBufw njasWdNy1AFAWHmthFmuwyzXYeaZMHODYeZmCFOOUapLK285Ur9lF/ctC8xbVk7LM773VuPHfbjh Gn6V6qcm4nsR/lvIhWZ8V/J3EyzW/zaqJZybTE41cNV/7K4m6HfbXcdhAnfUqhXcO4fwlut7C4j9 VmuW89cINULiGxpBjoXVdGKa1M+aoJ9ah49mmzvdVG9jRtZTnlGovpoVUn1Dhfydz11SVuK6tHRV fUTUlA0i5eTF9tF35vAr7z5Jp0azLl9JXc6a8a3UFpRKfOXrhMFvFzXCpstEVUEMh4YmclfvDG8T UVNJgVpcJh3CaksJqdeqR3L6rNrrS8oEKUw+Syxmh2brWMwhtgv121Xzt8SnTsdiZ7WVzRuT00ep 8KNbqLz+udfllRc82EWnrs4xKkNX0v6rWeNDC0OTdRpMIIwocajBtYPaWvWt/WiDosQowhlNON19 wfQwZcds38QbStwW6jfsnhI3J8f68Z9Jn761E3S4tYRbS2pXTOsrwXQdpUNpCknJy1MVOp3knfoq WQ+qhg9SIwepUYPU6Ik5lPhZ0/LJnXzx2XOOzaE5umRMJj0Wk/tN2neJ2taXIqnhpKdOVzfkSh3q uaHKrPlWZeuFSfut1XbyhqmP8IU4VA3UdWuozoUKXQeaCUNqgOR7f4nplhRrXbRNvs9Vs/FzR2iu Tom2So8p6duq7e1+S0ZnPne9s++SJ5OGqPmE+1BoiM6zSp338jb+WpajBujY5+pNvORIXiMlRVbr 7a02cMhOTNLjOlDpTNM7KMnuLLJDg6zSl5XaslpTVuzJqi1ZuSPW+2LBLVa8Yskn1lxi0SNWHTKz K7N7MsMjo7wy0iejPaLxS69fen7yPEmNg2EeHAIEow6FajgcorAQakHyZhEsAR6jjoAjoR4k3RNw FDTJ+4G8+VJYZt9JdhuRFcey6kQsT8X6QGYgRAuVuBzEbfPhMJC6sxhEjnAbpdAcMcpBPcwnfQ6D RlgB58PloHfIgqN6KLUS3tmCdIMJvZSaDl1Jzx6wfkulNkDL1kodB42k8UrYsb9SA+FqWAMFpHs3 aNhJqWPgfngG/gPrYFqE9IOf8173waPwB7h+oFK/hHKaUQqyaoRVcB3cJL+7KvW/UDBYqf5wBdwO z8Ff4OXdlPoXvIZY/Q8UFBE32Bl2hVIYClUwF86C8+ASuBLuhnvhCXga/gXvw1KaghUwZQ/8wSGQ gNnFpHmxWcX7OFSVkh/wHPwertpTqWvhZXgNllPcj4b5NLeHwhJIwM40lYUwbbhSM2E+HAYlI2hh YDVC6SL4O7wLu4/mGhwBDXAlXAN3wN3wArwE0+loVEIdJGAxdWAprKaBPAc+gM/hgX3M6sSn4T0Y ti/PhUqYAwlogdHjlBoLR42nnMLb8A/4DL6Euyco9RhUVJAWUActsALOhYfhMTiQejgPnoa1sPck zsGpcDo8Be/CEMr8MDgWToHr4Xb43X5ch/KpPAdehtfgT9TtP8P2+yu1E3wBG+CB6eTRdLMi52P4 EtQM6inUwh4zSXu4GG6HR+AFeB2+ADULKQW9oT+MhUqogRY4Ey6E2ciVA2E1XA63w2/hSXgZeh6A nIbjYRWcfYBZPdKNpqMvfA5fQD6yqSucAtfBQQic5TCUyj4cTkb4rIatEEAlsDsCoAQqkQ8xaIIW +DO8CWMRUONgbwTUATAPFsCx1cZC+RP4DAYfTlrATQivW+E+eBp6IsS2gL6wNQyEfeBOuBvug1/B I/A0vAgfwokIvtVwLlwCwxYbq9d9YTIcCrXQYC1hfwyXwkEIy8PgSGiC4+AUOBuuhJvgDrgfHoVG BGsSlsIKWAknwZlwNpwDl8IauAMegidgLsK4Gh6CR+BleBPegn/AOvgceiCw+8Kz8Dv4E7x+pLHk XHekEbhdoA/sBCVQDvvAJPg3/BduRuD/Au5E6N8PwxDS46GOBmAl/BZ+B7+iMXgEetMg9IcBNArF UANNsBZeh54I+O3hGDgDLoOb4L/QhUakEEbCoVAP91rLpOfhLfgSetLQxGnv6+BncDf0WoHchDEw FRphBVwGN8IL8Fc4cCVyHE6Di+EzyKX9zD2G9IIBsAeUwN5wzbFK3QADfkTcIOc4emLw0+Op23AL 3Aevn0D8YL8TkYWwFv4Ct5+k1F3wCe3f51BPG52EV+DPsM3ppBdcQrt9JRxwJmUJnoHnof//0LeE JmiBkrPJH5gGNbD8HGQQvAPvwRja/rHwb/gIdj+POggTzydd4CV4Ay65gOfBq/A6zLmQ58J8OBTO gnPgKXgW1sJL0O8i0hmmwSyYBwvgMIjB7XAP/AFehj4X844wHw6HZXAsnA+XwD6XINbgXLgUboE7 oYz+yzh4+3LkJux0hVK7XGFGqw+Bs+BceBHehL/AP2DklaQBHAMnwaVwJTwID8OnoOgX9YVt4Ub4 OfwF3oGSq6WnOaCTTjrpZCOQY0NIVl4hseEiWIsK+Efo1V2p7bqbPVanwcPwJGzbw+yzWglVcBFc Bi/Dm/AgGuKbMEc0K7gMroRX4a+wI5rPblADR8JBaD4L4Gr4Cfwd/gElfeihwqVwHYzpS88XjoeT oCea0rYwdSukMpwO50DJNmgisBrOht3Qh/eG/8BHcMZ2SHQoQJPaGs6Ai+CSAUr9Gpp2oDWGM+As +BJydqQlhkPhNDgH9kbTmgS/QaN6ArrvQpygEuZCXzSq7WEeVMOFcCk8g4b1O3gGzecFGIOmUwEr 4RgYjsYzCrZEwxkMv0azeQw+Q7P5EsaU0ULCsbAafguPQggtvAAmwzSohhY4Hc6B5+AFKEIj2hPu RiP6XxiHJjQZToTT4Rl4AUahGe0LJ8IqeASeh/BI3g3mwjy4CK6FF+EvsDMa1G7wPLw0yuy7UwGn wo/hWfgD9ENj2g4WwEJ4Ap6DXmhQ/fYye8AcApfDNfA6bIDd0Kh2h0Fj6f3AEdAI26BZ9Ycz4Eyf tiV7wvSDg2A+3Aq3QxhNqxesgxDaVTGMhEfgKdgCTasPNMAyeB7+CFuiYe0A8+FQq4U1wr9gHYwU jQvOhcvgRXgNXp9o9jOZhOY1F06Ak+ED+AJGo3ntBS/CaxBBAxsJR0AD/Aneg4lTyF84Hc6FJjSz ldAHzWxLOBgOg2tgDfwD3ocP4VNYicZ2AjwEj0IB2loPmA6VUA0x+BXcD3locN1hMsyC1XCO1erK 4Bq4w2pzfxVND03tAKu9LYZz4CJ4Fd6GndDUCqEZVlot7m6rxT0L16Ox3QEfwCcwZDa9RKiHlXAL /AI+ga9g3yriDhfClXA13AAfwSfwKXwOzWh+R8N8NL7FVvv7MTwLa6EfGuC20B8GzjVa4aGwCk6B J+EF2BINcXuYC1G4HH4Gf4Z3YFc0xxK4He6BJ+FZeAv+CjugUZbCAlgI70Ae2mUZlMM4mABN0Ax3 wb3wKWyAsWicU+AkOA0eh2ehFxroVnApXAX3wi/hCyg4FH8wGU6B0+BZeB62PIx6CAtgIfwUrodf wC/hA1gH5Wiwe8HD8Ax0Q5PtBdNhHpwHF8Ar8BrsHKWMwFr4PfRD090OHoVn4CP4BEbX8L5wHJwE j8FT0LuW+6EK5sNFcDnkoPl2sVpyIdwAt1qt+NWY0YYvhllounOs9tsMU9FkZ1ot98IlRlu9MW60 0M/gQzTN/x5ptMxtfFrl8nrqCzwIz8AMNMzZ8Aq8BdPQNGfBeXAJvAZvwW5onqXQBMvgl3A/5KCB 9oT9oRLOgQvh9/Aa9Ecz3QVicKRPSz0ajofr4CbYBw11fAZtdR5Uw23wvz5tdQJMhVOXmnU0jpYa WUY6wiA00z2hCZbCE/CUT1t9Ep6FGrTQxfBzuMOnlY6DyXAqnAXPwB/hNDTTs+FJeAmmoaEeAGfA nfAl5KCtFsMoWA1nwlp4EWagwR4Mh8NCuA5uhn/BB1CORjvap92ug89gJBruXnA73AN7ouGWwb3w G/gKctB2Z8MhcDFcBl9B/ireD+5YZdYO5KMNj4JDYAVcAc/B67AeBqIdV8DhcBpcDY9arbnLqcgE mA2Hw3FwDbwGf4UP4SvosxrZAANhMNTBUrgH7oMpp1Fm4Fy4AP5wurFj7ocmHoGr4dozjN3sv2DR j5VKwE1wG3wA6+DJs2gbIYFG3gyz0cQPhEvgFngF3oRFaORNPu28HM18BJwPl8EV8BN4Fz6A4Wjq I+E4OBHWwE0+LX5XNPciaIKVF3ha/VI09WVwG9wOn8B/YTQa+RhYDivgMXgO3oN/QhEa+e5WS18O v4EnYQs08t4wHw6Ba2EN/AfWWW19DNwKd8O78F8ovkypYXDUZcbG8E74FXwBBWj1s2E+XAZr4G40 +GfhE/gKiq402nwFHAW3wIuwH5r6TKiFU0ChtW9/taO99++kk0466eT/HRs2bKXEemCatqyIqKX2 V+brm/idwa/5a6IaoxbgXqH/Tqga1aLq7ax+Ul+pVJPUfqpElWvXCH7L1WhVSlhyd9vPGNPmM8bj FsuW2Zyr4Xep9pftvISS5FniinB2kX6WF68oV2s749UZr854ddb570S8KtQxGzZs+Fn9+9du6JX6 X0gdy7Una1+KbeilUo6Q+hHXfjEgb7dM147j2qe7XTss07XjufZ2+er7M107gWsTDjr34EzXTuTa iZ+8dX+meJ4k1258e3Sma6u5duuNd1yT6dppXFu59ZI3M11bz7UjtjlsTfo1pT/iJ0emazmc75YX UpneYVDx86oPVzM977YFZaHu76+dm+la711/H3o1945+ma79c7t78h46/fD5meKyLv/BvJtrz78j U1zGNL0bDum4pF/bfrtVfbJd67Pimj4mnunXPpt3Sr9s/lYsztkmm7+LR763Ta8s/k5bumX/bGHu tGjsDtnS88F9Bu+Uzd/Ko7aPFHzZ9bxM194Zd2EkWzwvH3BzJFuYTx671S7Z3mHpygt3yeZvh2P6 Dsr2vOLQIYOy+Tuh5Z1ds12bNr9s8Psf5AzPlC53Ln17sHn39GtFOx1U1LXi8QyyQKkjjn64aOgF 3R/KdG23g28oae62YMvUmEhc4of+tDxbPH8/9uPh2a5tM+iEEdmuXTVr5ehs13J3nbBX8YO/+Xmm eL4167AJ2d5h5ZyyiaWXff6P9GshdX30hYkP9F55bCZ/vxy1blK2uLw8f8TUbHn74Z5VU9+acu/7 mcL8Xd766dnCvHbXv8++d8iomzL5O3fOrKqh239YmMnfqp2vnZMtzOg+Z83NFs99q047JFuavTXj fw7JVuZnz3i7OtvzrkheX5Ot3v4n9PHinTJeU+qqxSfXZ4vnE3nhxmzx/PG0x4/KFs9f9Xk+adIs PS7vRY9enk1+/i1SuTLb+4Xsb9rRW6leq7p26bPq4q+2Fvvjrl0KpL0obcPH1fmuj6vz2+VjVJ7r Y1Reu3yszXF9rM3x+dgm/X5td5v6HrOmhdQBkCjE2z3vt+41+EId8hp8sw55Db5iBq/ZU2dJyPW6 JNSu1An6SHlYD31jtofdgNeDjNcbQsHMy83sY2SOLAPXPkbmFORaH46f/Ix+qnL7rLrlC+2nKrcg 3/oppQPj+uuSyd8Z+Gsx/s7ILeji81eqcn1+u2Xw+yV+c79w8r1bit9Slef33yPdvzHdd/z3yOC/ VOUHwginhbEtZe+dz51iG84SRqkqCIbjr+Y6nNMJZ6kJp7GrfF8zazilqktKWH1Swiov6LPq6c+c sPq0EVap6moXeaWXoFwd3hDKw1pTHobkFOhCJytUTBQye5HKMeRLp3Lgpa1SlMVbewpSrluTH1/v 1GS8trcs5boy5PDPnbKA944UpyxBdLRE5bqC8NNPnRJFMBtTqLIEtbHlygTX2LXPqrP/65QrgmtP 0WpdrgWF06xpBci1AiPX6rIK0dwMIhEvUoiL9L+ZnpfFUwjlv/XS/yBlcl9TJh/M8Z7TeuTe4DkR 85w3Qk6VySZ1jZeDc1wvB3egyjyQ61aZB3I7VmWkwD7uyr8OV5ltC1zv2xZsXJX5tItbZT7tsvFV 5qVubjl/qdumVZnK7m5Qld03vcoM6elWmSE9O1JlshetNBnpFK2N7D1sglfVIa8Kr0rZOrf5npq9 p/Q1d8s2SnxtwvOMXOnIy8nx7efft5oJqkNev85X3ASvebZJ8h+m1EzJdRuJKbmmkShUbTdHGQub iJrMnjoVh2zNVqfi0BHFIWNT1c1GoZ1evnHFIc1rx3pBaXpHx3tBaUFsXC8oTf/Y+F5QWlCb1gtK 00M2RXHYIoNEm7C7+nol8P87rx2ohD5JnpetGjZ4ykhDejXMy1YN/+kpI//MrIzkZauGb3nKyFvZ lZG8bNWw0VNGGltXRvKyVcNFXd1Cv6hrm9UwL1s1XOBpEAu6t6sa5mWrhu96Qb3bfmUkL1s1fMNT Rt5otzLy7Un4POutU8L/QCS8HNmHajIUrbaGajKWRqdYtdPL11Aaezpev4nSmOZ9s5XGtGC+M6Ux LbhNH6j8ppRMW8zS/WqvnSpYehnuVMG+tnLbWfg6C58/rI0rfE5q+Y/cDIUv8TWMcaoOeQ1I2s6h is6O7Dc4VJFdjn5XphU6HsPskn5bJGil8bFtbkGectKodVn/OKWnq/H1eF5BgfKnbOvS/gEk0/Iv nWzpqlLzpHV5fy+a/TtG3r/UraB7mu+8YAgZJP5taOIHmxDG9SjomTGE/JRQ0mX+9T3d2tN7i4It soZSkBpSmtS/eos+q0aZkJb3Kujdakhd0kJLlftv9Hbr0JS+BX3bDK2r2qS5o29PEtspsU5J3CmJ W5NzG9WD6WAJ3gSJP5HbxNDa700MRv1uMUL3u8W43O8WI2e/WxYr+N3HpLhPSnGvT3GLwbHfLYbE frcYcfvdYgzud4vRrt99Ykr4q1PcYjzrd8tiBL9bDH39bjEU97vF8NjvlkUJfrcYNPvdYgDsd4ux t98tRsB+txi0+91O/Atjz+dI1p+Q8j7Hp7iPS3H/KMV9bIpbFjL43WLA73eLsb/fLcbxfrcsrvC7 xcDa75YFD363GND73bJAwe8W422/WxY++N2pdSV1gluMxv1uWcjgd4vxu98txtt+tywk8btlkYTf LYb1frcsgvG7xSjf75ZFJH63LLbxH7Lgxe8Ww2+/W4zn/W5ZSOB3i1G+3y0LdvxuWeDid8uCAr9b Fur43bJIw++WxSx+94Zv+ZCX6a2O/9af2/GjQn1Xjg0betAUFajxqkLNUVPVXDVJXbzo+ZwC/prD ufGqijO3caa3PZNQ9XpjfdmgvFIv7nM+JXCv7y7Zqn0Gd9Xwm1CT9Vbki1VSDVKPu6FPVTNhjnqJ M2F9ZoVqJER5aqXrZ5B6g+tb+q5PI0R54kS9KbxslO/d+z739vTdO53QvKtq8fM5fXxXZav/Kv6S eMZ89/Xmvl6++zLdE1kcfNKBgScN4Wo30mm5/c9Z3hlS5aT3TDULJum/zH8hVYZrjppNOJPoYEwm DabrtPf/3fYdG8bNGj8zMrRk6KjI9Ggy1jQt1hwZXhVXCxZMiDXUxZYsHdZYtiARbRg6dFRj3XA1 fuKsCZMqq8rVlMrA/XtCZMbBkcoqlTk835GXm3e+eidnp2UicbupS3sM61qr5FMZB+fIxvgH56Tr c5kOUbAeQA94fDtPcjudmNSjW+HF133xqyee3urULl63Wf8rrpCazSMfcj3WZgjBOfKpAUJISVuX Tsh3LfXX0Hl8nQeysSXZnKiPNEYXxyJlbXvIcJw9weA//KEOzeytjaOtUIdl9tbGkSlU7+ise511 79s7Ouue/8g9PqROyFea3ioSkrJ9gh3UcX5zetub97ha0WWhHo1Telhmv35nUwVycgpy8/Pyc3Lz Tk3RPa6yv/KdH9khIakidAJiahm/s3UXSzpYSg0nnByVnx/KCXUpyHHHhZzHynG8/FNFJ6ReLcRn Ha5hg/XTexTk5ciR9enj6ZzFlfme1r7DtZ8uud1ycvJz8rL6kQ5gi/Zndn8wsVaqrODs0ExEgG/Y K9TVxNfG1gSYPKz3wi0W7YDivN/WZ4eOLyCNuuXl5HfNzTMyo0tX7+WMj5INwzZElPEzgzeNqP2U fKFpCXEQfX6vAp1GKuVIS6ODbDfV6a6K7jSQLtV4tXpbpdbysCU6CnctnHbKdbFppxy+YNqiHdUo zs9HLYqcLGJO9KE8dVLvAT7JGAqIyp1F4q5SncdGHT8teKDLXeouMmzoEMnC7XQDQqukjvlJW37b Pkx52rChr3Xvor/X1GRrweLAPiPeLi2yC0mzki9PRaljSX3PUlv6Z1ODK21obe+Q0vYdP9zjqw2Z 1yBIvXrj5Ks+/GzWkt43ndNV7bHbnS9TNNRdIfl2lrl+sTJ5ezVI9XtaGROsl5T+spX6SMk3xMzN IpJ6hkyXJxIyo/x727CmhOS7WXRaQmataWNIacOqY0JKj1GvDsk34ZQ6n18ZaL48ZMTMGn5l64ib QyYef+XhOyr9/UJVEW1qiksblVgUmVE5ab+S8kiyuSkWrU9GEktjTZHZcyr1vVp+cK/8LaNK06IN kaVQyz0zYrEmhT/vvoZI6t8S34ZEU320rnTirDkq0lY4kk7Dhpj7JO4z4jVNiWRiUXPkoERTbWRU 6RCVHCfhV1bMm8WP/nvbG2IXD3sgpP9e/vGtReX27yf3Tf6Yv3NtnORXZKb8itxsXye08+g8Oo/O o/PoPDqPzqPz6Dw6j86j8/ghHNn0fzmT88IzL1xeun3v8y5C/y/+7FYZhctPOSc6e8Tq66KDLlFG RxeLGhkDkDECGQO4Whm9+HplbKNuU0Z3vlcZXf4BZfThx5V831yptcro/jKWIGHnpOj4YvFQuSRe F29MRioSDcmWehTtSXWxmuamREO8JilfKxf9V0YM5VfiLr8yniW/ZVt3VY6pXbbfHXubd5LnzYjX xyLNKxpjyciiRFPKkILq2dvETu6Ut50Tb66LKUcvv1h5unjEnhMLG/Gxj3XL3zIGUl05dWL1fgdO nei+7Xh+5bO9R6tyNVJV4HOinngexRuW6X15h+m/yjg/lL9G456ohvDXEP1fuTYymKiG42OYmoDr WNV5dB6dR+fReXQenUfn0Xl0Hp1H59F5/NAOR/cU/VTm7kVnFw1W5utlrl7m6UUvFZ1Y9HDRyWUu XnR80dtFp5c5fNHd5ftcWyujv4uOv60yNiSyemV7GKCM3i5asqw4icDOSqyBxCbEzNvLyhZZ3bAb mO0Oldod9oBiJVq9rORSak8QewQxlxPjNjFFk1VAsvJFdOuRMApkJdQYkBUZe8NYZXTufZWZWxft WmzRZGmAjBHIypHJsB9MAVmJMg32B1nFMUMZbVzm5sUC5QCQ1VCyAkRWFR0IsrrlIDgY5sF8kBUz C+BQOAxkBc7hEIWFIBZVYnMTg0UgK5xkLEXMTo+AI0HsxWQljFioJZQZY5GVSWK/IlZVzdACS0Fs w2QV1VcbNmyQ1WNHwzEguv+P4DhlzLNOgBPhJGXMp06GU+BUWA2nwelwBvwYzoSz4H/gbDgHzoXz 4Hy4AC6Ei5QZ97gELoXL4HK4Aq5Uxq7targGrgUxM1oDP4WfwXXKjBXdADfCTXAz3AK3ws+VGUOS 97uD3zvhLrgbfgH3KDO2JNd/ye//wq/g1/AbuF+ZMSe5/qXlYet2+CEcYvUoVn0RSn6DtrdaoTpy 9FP5IScskSEF3cxY4gPmslQldfjWO+64R/kDocja11eJvcqjypoGKqm/c6gDCynbMbUxxxZIL//7 tO1D6TfsnzB/H8TbN1HzUr+b1d6jv8oJiczsyPPlGPi++c1HcrTYpT2S9lN5+iIdJznTTP1P6Pqe 7Sjk+ZLiIrvb+/zb5R9rp5mf9uYdi88ont/R9L9P/rHPD9mlTY1I1IVa0nXs6MvzpQ2TNqsj6e88 yTxVvn/WjDxPWEve9h/9VKjN8ueUe+c30z2bcnQ0/f2HROaHIus6j/QjRO7ndjdlKFV2S/8txT5x YqKmpT7W0Kz7hDOq5ByndGWWv0ud66Wj1Eej7wgsm+48vovH/wFQSwECFAAUAAAACADutEwpgZPN 5NhcAAAAkAEACQAAAAAAAAABACAAtoEAAAAATTY0NDkuZG9jUEsFBgAAAAABAAEANwAAAP9cAAAA AA== --Boundary=_0.0_=0056890014795482 Content-Type: application/octet-stream; name=M6448.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=M6448.zip UEsDBBQAAAAIAKS7TCkTIRKX3SAAAAC0AAAJAAAATTY0NDguZG9j7FwNcFzVdb4rrX7tZ1myLRvb lIcRRnKklbRey5JAtiWtZK9iaWVJ/knCT552n6Rn7e5b73srWcQkOBgCpEwzQAnT0mlMnQIZ2lDa SdqGKT8hDiXlZ/gbOkNbByYeAiX8xJQaitXv3Pve7tvVrg2e8jfVFd++vffce+6555x77rlvvDz9 VOWxw3+z8tcsq2xihezUbBkrdrS5gJ12ZTFju622U7Ozs9Q0AszOly9U+c8fPsz2sTI3TFf1YMqy KGg5sJKxRWx07+he80vml9icUuauZmtaGavudHEcqJ7bx1lmZyvO+N0ul/HPqSKWejq/53sudXC4 sejMz4V43oZnvaP9uW2M3Qu3fsGqn+1zRydjBXgOd4q68zmI51/geaCQsfN6xPNPMW8N2q/uY+wE 5je3M3YE9QfRvozNLVNZ82WXM8lHfKnEysQzW5/ZfLPH2+Oyn0R/xjWXT3b94GbGnnaxOSXbTmey u1PfVEiOf3Kn5alfxNhxhLG322Dvornjz7aQ/FTs+R8pEv537O/eNG7xPeTKXsfdJYwdxXo/3MTY oTncPqsSGBjpGRroHAkEBzq3y8GhrZ0DgWFelXuDQ/LwSOeAv3PIb7VJGR0yxvbI/h55IDjU37nd 7hwYDjYGerrlvpHu5sbhbm9b4+6tzc1Sd9AfGNgqB3vl/uAu+jYY6B7ZOdQzLGMuuXOnPxCU8o3t H+zZ2tTU2N/i87VKwZCpj6oJ2dvU1CRJ0rCeTITU9rLBCS2ixQ25W48ZySjoPRE1ZCb0mBYypBHN jKBPvxZVZXMmrhrymJ6QQ0oioSnjqqyPyTRFg082zISqRA1Zi8lDI4PS1oSejLeXDc8Ypho1pM6k OaEn2uWyPiUmTwFhzNOvqgnI8bF5Y7UxyBdOhkxNj0nSyIQqd2vgGlESsmrKSkQOJ5Qxs0FTzbEG ZcpsSJjxhmhcHfc1NK33mPtNTD+mxTChwjnKcWUmoithLsUcIdaMqzE1oYVsacKKqayR9SmsAGM9 8u4JNSYnDS02LpsTmiFHVaw1XI+KmsGcxsmgG9p4TImoYVkx8vBWYiDKCTWkajTLBDqaujyuQwF4 El99dC9shGUYoYQWN/UE74E1hWU9acrTE5ABI6krnzahxhOqocZMoWN1vxKNR1R7ViUZ1vR6eUoL q7oM8nhCiU/A+h44STI0Ya2IZA9FVKhsLKFHSXW2ebiR5bgO8UhhU5o6XS+PQg6MiOloi5taFFaZ Jk2F9GhcMbVROJ05I09r5gT6xBoyedlrN4hFQt2X1BJq2CP3pmWvB6OYoZEfKfJYMhKRx6DTcTVL KCUej2ghhRwF2lBMPr1uwPSGCv4QKpcOyAC2ElLeR6LCA/WYKo+qStLUMKtsqZVP4JGDY+CfTBjq aZekJFSulpASV0ZhBVjOmNCnZYN0nclwgISEFSOqAVWYclSZweSkZOhaRVeTRltjoAjyQnDki7Hc yGoSC+OWmzMP1uT0N66nsK4K4xnJeFxPmJl69cjb9GmSTbi5Y7UpLtMabEIMIK9jpckYTGaYJBuX 45bMHXBrarvAT6OK6ZFHoB09MqWKzRVP6GAUrSdliCpZM0yhgdPDeggxLMbVIja5ZT/ZiKshbQwT RTPjTWaM8cyJR5l0SRpSrK3FoxhmoI1PTpG1l9ekJ5ojLVmcizMjw7Qkr5KYOZ2glu9lhxS7q7Ai SZsWIh1PPHIghiEJUwslKUS2Y42Dvl0Bf0/QuULhIfY60YMfLc4ewq1SmkCXrkDvsLNH9qahPoHB /kFnH153Munr3NXp7NCnTClOBkG/kxrMDn0ZvLqHnH1DET00CZccw1aJhVQn0+HunoGeDAOHoLkU W9Knk2+wO+DsbMVfhCCTnE2LCW91jsKg3u09e/p37nEO7I2o+/uT+9O8A6kRYt9ZwQ6ChPQwuRba ThNMxP6ziMPb5QlVoZCIeJKMhGnrabS1DRXmV0ycbZqK5jgND8MPR2f48IgaG0cYHp1Bj1piEk5Y bXV0SDk3GWUSG7lD8e02jXh0ulAXwiYxJrW4U0qrEz+XyK/pwFJiM1nkyZg+zQO6Rx7mB2bqfOVi WpIP+wehIDOh4bRB2Ou4RJzyRqRBKKJhLKKMb0JGYOhzlyFClBKJIPaSifgpYh9PiFaGmpjSQip0 zA8uHCXggLTAVBElgjwKOA0PQ5E42xEWI5LUs18JmRFsai2q0aazDu4va5OIeppIUzzyUG+3yFU4 0UgtlAf4sIYtmUwfUVE1rKU2Bq2CprMsXUsu1vkVeXOd3MClNZKaSTG3QSzeCjftkuLhU/nJvdQE cr4xbTxjGXYmg4AW4tSONbAJItR+uV2u5QfIZMYi6qRRwRPqGdPo9EFsj5AW+Bqs4FQboxkikRlh RM2QrXgWCPrrJMnOSMgOPBAhSEU7REjytTVvbGr0UuRr7Nw1KLe1SqGOAPLpQZ/s9fo8hPWelsZm 74ZWSelAshdV4u1trTJFuYae4ca2Jsp4lY6xqIl2W84GLmODFu5ovliylkodm5q7AOvbhqY28a1J lGZKnlt9vqbeTm+rt9sLcqe3uTdzATxO8gWIiOlr865vSovfkk/8liaH+C0kfmfD9s6R/kavz7mA llwrkEc1k7Z4Rwv1vVgOWQd8B30Xi2tr9npbvFwXkqGLcJP32NdoNeIkhZFE0PWnY25Y+I/Y4Cbt I5gqZtKJRuYXZMoR55xvkrTu4xZJsrINWRuDxBmpCyXH2Bo6kk5DntGTYlOPwzWzzisuV9Ypx9v4 gAkFGcZAkAc0bFWKPtj1GhIUwWRct05hq5WzQZKrhpSkYeUmtIssx+bnIjEP+hHje6awIad1ygtB CykGz+CMkBLhWZEtTEp6LkxMzyGM3XVUjei0S0VQMZRo6kqgmiHZ4/FwP+QWJa4xFWHPTngpkxg3 sJcDMrINkeLhwEGKQgFwhgSdNLAlGyiiId9HjikCk+0xXNm00ChCLK2Esp9U1iL0ZUlDKkhTQ/YV gxNpBn4ZUbAwu/+cGdPqSVqZU1SZ5NLWRpMRU4s7FCgCn6XWurNyND+pniIgnG0sAb2SNlJZZa11 sRQdrCslXS6bmuhaWWcHPNU6zPnSrLTOmVnYsVuE1WjSMEWUtofzdfcMB/w4fhGyO8REKq47suIZ 9YS4ccgCqX6wAn039bgICnA8e+JabEacQGrYmUXyqNsgj2YwSdEhuhHS49y4CjyEjroUQwwLnXlY 2nKSNK7TfTiCPZmk25y9Yc7GQM3iqBmn1wvWQYktJqKu5Zi1dC1CCmxSgpOkOVW6qfFtd36d5PDf bE7kqTnd1+m2OPt77b01rdJ9j2dUPLeADDEVFznc1sjMwhKp/AQngtIhC1tyGdrFbEF/hyzj8BLT UK3ZtyF9ovCYR2kJUkc7FcgIgVosFEnCvWSvFQc/3kSn69rq7OqVJMnrobVSIz864hElJE4JEW9w UmQdFAk9olr+Tm9qxNHPnV3JpyfkoNgcFNj1GOKRV9CRhtn9ySw8GcLFyoME0XL0dJqNvU9hT9hG RDWx/ZAQr5kmy1Huiuca611GSr8Zik2nQmM6ZYlUw27gRKeOg/52UuvFcvY+bRYPr3islyREqARP XnEkT9F5iVnQa9rO1mmuUXLUiDKj2jcbscvq7dAuSQNdFBRsDzaVceH/tv5SuSHpiZ9HuKRQui9e /aBCWsT2O5sAuTP9oourWImJ40qRa1VaUZLneDhpZmyd1mUotdF5zxoV2ThkrSc3D6ROvrz5Bi0J dH6+2m2BXFkIacbKCkTIS4jE1KQzgr8oc56otUadeGNAHM9CL6QZeg+Jq6aOiXiiwHVEgWiSa4r7 Ml8fvQUxsq5DBq2fJwCKeHlhKZUvlKtMks78dnq+zJf5Ml/my3yZL/NlvsyX+TJf5sv/WXEzdhtw O/DPwK+At4DaIsZ2AMPAIeA64BbgVuCVMsZc5YwdBX4JLFjA2EJgENgB3AH8GXACeBcoWwR+i8S/ J/zg5LuM/t5hrx176bWXXkj9vfbSmWX9f14WDPYxNlHKYtvK3CXWc0kQbVZ7FHVqW7Sh9GB33wq7 K3N3961mrMRqLcRTfEfjKrJ/I3ApYADft3zhx8ADlk88nuUXGy3fGHL4x7VZPvJmMWP/4xT+I1be cVbezFs57qxk/OPljMqLzsoLeSkZlefyVp75aN2ecFZ+7qw8xOaUQvxXU8jKlrNtNa4NNa6NNa7W Gleb382gxPK1bEFvBzabS/xDa9cqxkr5gHU1LuloEXPF3HwHV4UXz2KfEamg4tDaak5bWy24F5TT p0v04ZQFywTFxao/Sfu/Bbxclo4XBY6Y8VtH3GhyxI59jvhx1BFD1i3MUNuH9PH+eyd+99vjrxz7 t+efeerxRx/46Y/vuvNPbr7p2qv2x9MdK4ovPzk7W7qFlbnKoTpWWlDJiq9AEyg3pSglvOdPUvVi u+dPRc+XU5Qi3rPgfbvutnsWvs97XpCiFPKeW1P1ArvnNtFzb4pCpi0v/kO7LnrdRL2Kind8MDtb VDyEz4riOD5LO+wRRcX7OC10ij7D/PPBWfQoWM6KH8IX8Hxi1hqB3k/OUo+n6LMAdVZYAG9a90nY aRDYAZQuSsf+OuDhRR85DLz30bqdcFbeyFv5PHfLv7jXnZUMhWRQMip2IQcp5pGCx5AtrLCSNde4 0jHFijurzmSvZRWM7Qb2AJNABPgOcBj4GfAisGIxY+cA9UAD0At8HTgA/BJ4DOiuZMwPTAHTgK+K sQ3Aa8DrwPYljPUD9wJ/BfwHcAwwl2I+4HrgCcC9DGOBDUA/MABcDTwCuKuxK4BNwGZgLzAJ3AXc DTwLnAJm6XcKyxnrADYBdwP3AAtWwM+BTcBm4BBwLXAD8C/AE8CTADsHCgZ+AxwHViKvWQWsBr6x UuQ57514+3cZh9SnUCqK+96zIwRFm6LiL79He77gJH0WnqQYUpeKZPyfx+/8rGz8oVPw+cqnV0kX ihHnflb7bd4Unw/7fxKxb17NX4hC9l8qs9WDLnbefU83yvcd6zj/vtKSNcAF3/tBUQ1w4X1n5DJf vtClip3LyuEKX2MV/NeKVGoY2/L2bAH/NWIxG2A6S7AoU1iEiV80uvmbhnbm2uJCvZ3R7yi3MRU9 wkxjMTbOZNbM6tHWzOjC6mLFNa4ta1kJs15BsFZWwMe2Mrq1Zo/1onUBqLig8oEux8ghVoiR7+CZ a9b1fNb1jI6bQpq1fG3Bgt4ituTIW2zpkUvYlrUFWKfFK9hXwHYA4OU+DU8f5+njPN2CZ2Emz8Ic PKm0spLTrHIjX2VJapXFYpWDfYVi9CWsc8s7s4fxZLim+zF6DOOTsIKJ0YP4ngDG+WecTaCtF5aK geos61gXX9s6LkMXeoTZDPqOgN9+3rcY0i89sh/fWlgLyetqgcUkth2SGnyuLj5rBCNMyzplbLG4 SPBbeS07FXSxKlctvhehF/mKxr2llFXSNaO5BpqjhW3iPQvwpLX3cG2Y3L8M7mcmRtNvjqtoVBFX DMaWsBZLL37WDQm9Lj+jnynPXY3MAtBAGDWhB4ktIU4Vh35RUHno4g/hE9Aw7ExSDLmGuBQjkHaU r+4KfCd5IlyK89lSyzbC0vuYdHQRc68svMvtK364hGuXWwyboRS6PxXsdI26erkOusBDgQwh1M5l y1hV+MQsg8cg4B5pA59yB5sFwnfE6zuskGQb5Sssz5LNtlg1/oR+qsJdnG8YfMPQdndfFbEpbeVc Ei7yPDfr5nqiNVUxes/ENtSwjTWstYa1+Qvg8cE+sg7f1QtHLAuNcM/ohT7GYf0EH93AVjg0ks1n rnZKU5wHOdebXYN57TZs7Quh+2VIM7DC7CkcHL1sDd9bXm6Fbr4HTPCgHUB2X0mSLoFbc9cWdt/F hjDmftcurokzeY/w9BVslfW+reJQzF156OYP7Pdu6ZjUxL4Kvo+4mrjNBrntaTXOXVbAVnPpixAe irh26NfyxYwHB/5/TbB/cc9/w+4Wb9DodkYZOmVpRKPfgeMrJWFYIb2+FX3pFk/0ai6xKLfjfP8B 0A1jbAV+U8rYq8Af4eJ3M/AH5fBxYA1wERAEhoCbgO8BjwHPA28AJ4Ai6y3QELATiAAGcDVwDfAd 4LtAA2TxAZuBLoBiRB+wEbfITUAAN8XtwCSgAweB64BbgO9bN8lfAS8CLwEVuEkuAYK4Qe4GLgNU 4O+Bh4CjwJPAK9Yt823gJHA+9NYEtAGXAGOABiSh4BngHuBeYCeUugf4ZjV50uoccOdp/zRBRUIE rAX+AZ7xC6AMVqkF7gAOA49a7+xWwAqrgD3AFZalopaFrgcOA3cCPwMeAF4E/h04B1aSFwoLeizL bQW+DijkYcBVwGPA48Ab8M43gSCsOgScAopgMRNIAjcC3wWeAp4GimHFEmAD0AZcA1wHPAL8HNgM q20BJoEEcDdwD/As8BxQCOuVA/dY7xAWwnoSsBnwAzcANy61LbnSgtvx/bPG7OxSHgH7+Okgsynr STEngWc/nuKbH3nVpajP8O86TpIkzlURmQxOGcT5uRUx2cdrLXj6EEw84EW9Px9ztJ9xjk7UKQMY QlsIzyk+Ll87cTEwF9VktI7xudJyKaCGv8Byzdt9Xr+fX/1uZgeQp/xl9K07Zyuy/1zsKtAeD7+o zv2f+bjYN0H7yWr3Rblo3wLtvy+6c30u2tWgHfdd/2Au2kHQunbfvCcX7dugffu/Xn4wl5zXEO1H x9ty0a4H7a9/dP/hXLQbQLty2cSvc9E+AG3v8suPzKWJ1yxUctHooljmdrFca6ipfwa3pzJ3rvnu u7TZVf7W07ty0RZf+KzrpcL7q3PRfl/0sPve8K3355qvPfGa5OLzzaWtOudQZT5a5czhSiHLXNrJ r1xXnW/czHjB8nzjbt/4+vKKPONumFqyMh/PhzetPS8f7cp9q+TiD0tvyUV7dcttcj5Z7lh9r5yP 5+NXLb0gn5xTV952Qb5x5x6oqsk3X73razX5xh1MvnphPtrfTh1fK9Y31+515+2uK+1+LMe+ZWzv Nx6t8/5x+SO5aBftuafBLLt0SfZsNJ922Q99+WR5tuPdDfloy2sOtuSj/XnwyrZ8tMILuy6OV1b1 5Vrfy8HLu/Kt4W7lef9Di6+8KhftH1t/35Nvvn/9aksgn43eaRwOvPy/7V19bBTHFX+7d7e+w8ac SaFOE8glCo3zwcVfiIuqBhtsPlyMHc4BS0EFYw7syva52Ca0aVraOE2aRK3bVAqKWmFFqgqiVKhN W/7IH07VP4yUVm7USPSPSqhqWqT+URS1KgTI9f1mds9z+3EfNjZU7LPGu293fm9m5968mzf3Zmfr uctuMv8YvLbdS+Zba/6x81xt4rQb7gddHcn6ez6qccON3/9Wl5fMnie/u8urnhuS33nGq13+2v69 Z7x0d2f73/d6lffjkZO9XnbpX9p/Dt3neo/oxKEXB73qeT64dNirnq+1TX/Zq57vVL0/ItvMWZd/ 9jx31MvWfRjr/KrX82nm0UHwRcfDZVXjxz9ZgTmAcJkB+x0vgJgMZRGToaIQiWAWkQgWhZjRs4gZ XUF82pmfyl2eo6NNo6c4pWsY9pvL+aG5D1QSNPfJSoLmPqIL1Lt1+rQstE8rqnVyEbbCykVGr8JO MXS3hJ7Scj+8gDtiPT/Z+RsCsV43AibCwoRcMclA1fiZ6wKTDBghExPnAUUWV+aGe5VxYxL3asAo U3BxCijYiAv2BmMD163PPWLDxtnRVvDlTrycPrPw5S74OIVyZOSsEBQyqln3Ln1sqe1SDxlxMnLl qN1cyHmF5RyRcobDxrI8cuLstufKqrLJajSqxt+7asmqKiArTmHzhxanBgWEvFrWhxmpD7W6IZQO s8SyCu4QdI7aG1bnYEghLfKAFaNIgWxPnr5m9WSGFqtLgawN2fexpQsML0WdPESUqlGBrCG8csXS KBYzF6XyEDVXvZLihsNV4xP/tfSKxRWjWvntWq5x6mgz2K4Z0q4NeBrRgItJZAiU+GHx3608D5DG Tm9+7X+XdXKD1Ml39dly8lfOociamXmOJn4eUCoJSgwlMhvm1pW6aN+d84BK01dKPUGL/1EsantS SdCb+Yg3uXXyGBmYNXeQP+Ly+or0R1yljLhcvz4iZhWKhCz4iMsBLW3E5RiwlT7icoiY24jLMXCb +4jLIWp+Iy7HAG4+I65KF4u28RG6uab0/w5aQieUlnzxem7QhPk99w7puXNQLUtHioTcBNWqsKAL oVoO+C1TLYeY20a1HOLm74Yv1JDeVDMnVkD9cbI/Tl5AvfWVz1c+VdbclM9qLZXyzA08PB+NpZKg OZbW9yf9UekC+pPednQB5mO99ThPlyu9ht6WvpotaKdEVAeMIFltlN/WT7P2hCVqOmgYpLZsfms/ xZbp6A3rYwmT/TPJb+/PhdnWSnt/IWIscaCDuRJcLP7ZJVXj3VJCU7lR4SohZJPitPknK7K9J1pp VHpKMeySHFZ/srJqPCElHV1mRPNKKnNIs9v9i9FsH9q63FheUFqY5jVTv3iW2PwBwrfEviXOZ+fm NIIpUYPnYfGbOBtCBVUYwqFUHqGSKo8QSJVHmJ7KIzRW5b9m41+w8ddsPMLpVB5hciqPMESVRzij yiMkTeW/ZZP/so1HaJjKIyxW5RHGpvIIdVR5hNWpPMJjVR7heiqP8DaVR7iiyiPETeURkqnyVv1r T3fr+Oi/aXueYzb+Gzb+6zb+eRuPkFqVR5ipyiMkVeUR3qnyCPNVeYQPqjzCclUeIaAqjzBalUdo osojPFfl7X1Ft/EIiVR5hNuqPEI7VR6hiSqPkGaVRyivyiNsVOURcq3yCDlVeYQzqzxCu1VC6LXK I6xR5REaqvIIhVV5hJyqPMLDVR6h1iqfWWRCZaJ07DbcHHoD3WrKZMr5K8OgZtpEXbSNdlErTf6s Wzf4rIuvNVOSr5zjK1HzSpoGxRJrLFXtFEs+rEXlU0ouLNpt51y9fEzTZrEo9RCN0IM0k5W+jXZw 6qKLfGWpuPIVGmaJKLUzi3mQLvH9u5T7bSwRJbaI5cFYMj2b9wrnrVDybmdps3fDZ7r1KuUuFn0n +Qz1TCn5qjnfMiWfW56aM7klPZ1TUoLvRridjpp/1uIajRq5vXdQB6dWcSb/NKpjrot2spxWHghs 5jbYLtpePS+cI9PU0bwjVr+2PhHb3jOSOtyWGo2tS/bTnj0bU0MDqb4jDcN1e9I9Q/X1ieGBddTc 0rGxtTPZSFs7c/I/zinW3h3rTJK7PIWCgeAP6ZJ+37OwjBF6s7whfIDw0gR8W+j83+l3uREcISyo nb571sJagw07RWqO//T6O+ff+9RLZbPDW/EfnEY7ucjfZoEHXCRYFOIegKQRvpOcSVPu2Y8y+XQz KZPZNDYymh6MDWO74LrCABea2CiTSqrUendYASoktcEdVoDcpM6S3/f8vrd45Pc9lbRjmngxBdJw 9H29QqvQcA6yjnrUzIy3aexDP2oiMX2yZeUEdwFdNwKhYEgPBF+y+QgnzCPe+IJ1syMU40FAip7l 404xxMIAi2gdy9EpFNJ0rczQs/M3VrGgY/iX5EHIIO1nJN570/BZUXq5EdRBnqU38+Csn+SbleqM CW0Hd2FlekkLy/LM0qSQkS9G91ceXMUO6pYVE9oxg58xEtRD4UBQ9vmy8GzlJGJtpiETI4lp55rG aAvhXTt9XDb85g3rRG3LAhFdD+lBz9pi6DkmaixXI8v2IvqcIdqIbORoo93mMNUarsLHeYCHVM30 cjXRDJfaJx5hzZ62g39JtX17Hx/D9BhfaWKT9spyaWIxw/JC9CFFuJZjKu+HxR0nn+ZEPzGmyt6m t/kDq6/FR3i3+ALB+2Z+l+PiF6KaJW5XpWJlMstNfhXro+x/MdZHOYxHTzxIaXO9++xK+Zh4GxXe RNTDCMs/LrxWvnCOO5k+yaA/2SdQZG+6+OKJj6529EVPfz9Mjz70yz+zQtBZDe9OkvePk/xEJzmh 002TDJD6E5GwBpdJvOFIvNUYhiysyYHOvZqcg0+Yslo0vDeJ7bcm1zkNaCTCno5qJGaQxzW8E4y/ KviIaWC82QjGZZKPWJp8UpP1+BsXvppkyrvpPd9dbT4DcT6cY76nrWcodoQT9uBrT6UOE2Oy+fi6 /Rx1lbtAx1s6uihWSA7qmCCJvUvUsfdweiR9cDS2O334QCwRr6W1TZAfnliDdhPn1adSxxumNHFe +atfT1jnR3rTrzdOiR8xUCccYSVxhKUsbtjpk08++eSTTz755JNPPvnk051CXv4/rugf/P6DH8Xv ib7+Bvv/j139OWIaQrZrB9j5jJn+OvzQPpI+OuJdMAeAOQL4spMkfeOTJCOXzpL0n8+R9OWnSPrE mEPARNMMSd//AknZus3HX8Wps69/oH94JLYpPTQyNsjOdutAqnf0cHqov3cEb6uGD4x5Qhwj5hGz WDjWrQiTFQjndVwdlc9UeD6hIiprh5x42q7+0YEUWb75cZr1x2PmNcS/APGkyeMccyB7O7e17N3y 9LaW7NM283EHp+eokdbTJka2iJ+bE/yEdeIdjQ3irI6v1/PZE8y3UC2f1Yq/RhFa0ELrGNFAG5l7 nnzyySeffPLJJ5988sknn3y608jyPeGf4rd7+OzwYMXv9ST9Zvil8Inhh8Mnx2/x8PHht8Onx2/4 8N2xtwl2KDK3+yRzu0iydiq6lzDfkMnAS8Z6kBhhly3EABFhfQXWaGDdCdYmwW/HfmJYB/MIp0c5 IRII64CwXvBxwr5LJHaYQ0gbAtCwRgfrUuBbrye5tRLWKWGHOqyXwE5qnyfpcyPwv4mkd40ItE0k 64Z1HdjDawunrZywTqSN0xfM++0kvfEOTp2cniIS+8Ylzfs3OO0yz610OxNi3dJit6tWsXcE9oIo hVZSSLNkQYeMiJxLmpK3N4vz1/7wIeIW9l2oH0XMQjeZAWGEz292j7O5UCVrr/o8hRFy7qi6XZ7v FpFGBxx7aBRLnyEdu2pTKeWDHkjIY4g1Z8xc0IG2xw5kMvoJV2Z3NPOiGi4fLY6+W2z5Ym2SGZ0X cjx5afVJcPmltr9Yq2SWr5kLWoa5R+2nL+WDudJyLh82DDarlPa3SpKlYi+UUe7PaTN+s3haSVpB /bP03jq65ZkPldr+KqEyt7uN8mnhSONPP7BE6pDdduP72xaj1pLuHRtMDY2KMUF7Etf4kujMOI9b 9+MJ+vcTv8hZ1OrT7Uj/A1BLAQIUABQAAAAIAKS7TCkTIRKX3SAAAAC0AAAJAAAAAAAAAAAAIAC2 gQAAAABNNjQ0OC5kb2NQSwUGAAAAAAEAAQA3AAAABCEAAAAA --Boundary=_0.0_=0056890014795482-- From rem-conf Fri Oct 13 00:40:17 2000 From rem-conf-request@es.net Fri Oct 13 00:40:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13jzKl-0000Nf-00; Fri, 13 Oct 2000 00:32:51 -0700 Received: from (baosoft.com) [202.101.38.219] by mail1.es.net with smtp (Exim 1.81 #2) id 13jzKf-0000N7-00; Fri, 13 Oct 2000 00:32:46 -0700 Received: from _[18.76.61.112]_by by baosoft.com (SMI-8.6/SMI-SVR4) id PAA03954; Fri, 13 Oct 2000 15:32:39 +0800 From: HOTSTOCKS@aba.com Message-Id: <200010130732.PAA03954@baosoft.com> Received: from [220.138.102.151] by _[18.76.61.112]_by with SMTP id A52C2E6 Fri, 13 Oct 2000 03:13:43 PDT To: rem-conf@es.net Subject: DNAP - THE NEXT $50 BIOTECH STOCK? Mime-Version: 1.0 Content-Type: text/plain, charset="iso-8859-1" Date: Fri, 13 Oct 2000 03:31:00 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list WE THINK SO !! Dnaprint (DNAP) is an emerging biotech company and is trading under $1 !!! 1) CEO (Dr. Tony Frudakis) Lead scientist for Corixa starts his own company a few months ago 2) Company is formed by a reverse merger of a pinksheet company 3) DNAP has already completed the accounting to get off the pinksheets and should be listed on the OTCBB soon. 4) Dr. Frudakis was responsible for a patent that sold for $54,000,000 to Smith Kline Beecham while he was at Corixa. 5) Corixa's stock has gone from 14 Cents a few years ago to 50 Dollars today. 6) According to the Barron's article (9/25/00 pg 52), Dnaprint is in the late stages of forming strategic alliances with major companies. MAJOR WEB PAGES RELATED TO DNAP dnap http://www.dnaprint.com/ orchid biosciences inc http://www.orchidbio.com/ INVEST IN DNAP email for free investment package= hresources@dnaprint.com or call 1-877-362-3453(toll free) investment club web page=http://clubs.yahoo.com/clubs/dnaprintgenomicsinvestors investors report= http://www.companyreporter.com/index.php?u=companies.php great dnap investor links: http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=22034 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23118 http://cbs.marketwatch.com/news/current/molinski.htx?source=htx/http2_mw =invest in biotech http://www.loonycat.com/Genomics.htm =the human genome investors portal clearstation rates danp http://www.clearstation.com/cgi-bin/details?Event=peek&Symbol=DNAP&Refer=http://www.purepennies.com/ purepenny&3bagger rate dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132938 Pennystockprofits assess dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=15730 tipreporter rates dnap http://www.tipreporter.com/search.php?search=dnap dnap on stocktribes hotlist for 21 weeks http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24335 analysts tips and reports on dnap http://www.tipreporter.com/search.php?search=dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=15730 why is dnap unique in the bio tech sector?? http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=22654 NEWSLINKS GENERAL FOR DNAP dnap company news http://www.bell2bell.newsalert.com/bin/digest?Symbol=DNAP& =bell2bell news http://quicken.excite.com/investments/quotes/?s=DNAP&t=0 =excite news http://biz.yahoo.com/n/D/DNAP.html =yahoo news dnap in barrons http://www.sockthestocks.com/profiles/dnapbarrons.htm bioinform news service http://www.bioinform.com/ online journal of bioinformatics http://www.cpb.uokhsc.edu/ojvr/xmlpaper.html#Sites UPCOMING EVENTS RELATED TO DNAP bio partnering Europe- London England-16-17 oct 2000 http://www.biopartnering.com/bpe/index.html structural genomics conference-yokohama,japan,2-5nov2000 http://icsg2000.riken.go.jp/ TECHNICAL SITES RELATED TO DNAP dnap patents http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21559 dnap is about pharmacogentics http://www.nigms.nih.gov/funding/medforyou.html stem cell research http://www.stemcellresearchnews.com/index.html personalized medicine no longer science fiction http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=25033 safe drugs that fit like a glove http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=11203 NEW STAFF ARRIVING AT DNAP SARASOTA dr. ramin mirashemi, a new dnap addition—check this track record!!!!!!!!!!!! http://www.google.com/search?q=Ramin+Mirhashemi&hl=en&lr=&safe=off&start=0&sa=N dr.jose arena joins dnap scientific advisory board 03 oct 2000 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23532 scientific advisory board makeup http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24575 DNAP COMPARED TO ITS TECHNICAL EQUALS, AND RIVALS: genomica(gnom)nasdq-ipo29sept00($19)now$22 http://www.bell2bell.newsalert.com/bin/story?StoryId=CoDqtWbWbtKvgmda1&FQ=genomica&HdlFmt=simple&Title=Headlines%20for%3A%20genomica informax(inunx)nasdq-ipo-03oct00($16)now$23 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23532 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23552 incite genomics(incy)nasdq $37 http://quicken.excite.com/investments/news/?symbol=INCY genentech(dna)($172)-2for1split 5 oct00-263million share float---dnap float = 269 million http://www.bell2bell.newsalert.com/bin/digest?Symbol=DNA& DNAP IN EUROPE http://www.8ung.at/zockstocks http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21485 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24168 WHERE IS DNAP LOCATED—HOW DO YOU GET THERE? great air fare rates round trip to sarasota http://leisure.travelocity.com/RealDeals/Details/0,2941,TRAVELOCITY_AIR_449,00.html dnaps new upscale digs in swinging sarasota, fla http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21059 motel shopper link for sunny sarasota area http://www.roomsaver.com/roomsaver/city/index.html?state=FL&city=Sarasota location map of coconut ave digs http://maps.yahoo.com/py/maps.py?BFCat=&Pyt=Tmap&newFL=Use+Address+Below&addr=900+COCONUT+AVE&csz=SARASOTA%2CFLORIDA%2C+34234&country=us&Get%A0Map=Get+Map avis rent a car sarasota http://www.avis.com/cgi-bin/maps_and_directions/driving_maps/us_locations/mqinterconnect INTELLIGENT ADVICE OR BIASED ROT?KNOW THE DIFFERENCE OR HOW TO USE THESE MESSAGE BOARDS email suspected lying-sham efforts,etc to your federal govt(it,s called the sec) at enforcement@sec.gov http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132869 get the mob out of microcaps http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132789 crush naked shorting –stop being screwed without even knowing it—read me http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132581 suspicious sounding codswallop?? ask them to take the universal basher quiz!!!! http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132816 dnap has unusually good promise—accounting for the sad fact that were in “basher heaven”-read me http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132818 sec offers tips on how to avoid scams on the internet—good article http://www.sec.gov/consumer/cyberfr.htm CONTENTS 1.BACKGROUND 2.FOUNDERS 3.PRODUCTS&SERVICES 1.BACKGROUND DNAPrint genomics is a young e-biotech company based in southwest Florida. We are developing an informatics platform system that will provide dynamic solutions for disease gene discovery, genetic predisposition and genetic analysis testing. Our work has real-life application to the germinating field of Personalized Medicine and will help lay the foundation for a brand-new area of medical research called Phenomics. The PhenomeSM platform system that we are developing will help identify an individual predisposed to develop cancer before the onset of illness so that lifestyles can be altered and/or preventative measures taken. It will be used to identify individuals who are incompatible with certain drug treatments before the drugs are prescribed and damage is done. It will be used to tease out important genetic determinants associated with complex genetic diseases, so that drugs can be developed to target these genes. Our aim is ambitious. By partnering our platform with biotech/pharma, we will participate in the downstream profits generated from pharmaceutical products our platform has enabled. By marketing our platform directly to the public, we intend to make comprehensive genotype screening solutions accessible to people all over the world via the internet. Our system will enable a more holistic approach to using genomics information to improve peoples lives. The patient of the future will have more information and power than ever imagined. The human genome project, the internet and recent technological advancements all contribute to make this possible, and we intend to take advantage of these synergies to become the primary conduit for the generation and distribution of personalized genetic information. The Market Pharmacogenomics is currently a 1 billion dollar industry and is projected to be a 10 billion dollar industry by the end of 2003. Several billions of dollars have been spent on the human genome project so far, and an equal amount will likely be spent trying to understand what all of the genomics information means (i.e. bioinformatics, proteomics and phenomics). Genomics is a multi billion dollar industry world-wide and the market for personalized medicine is expected to exceed $25 billion dollars by 2010. Recently congress has approved a $2.3 billion increase in NIH funding to a total of $18 billion dollars for the year 2000. 2.FOUNDERS Tony Frudakis, Ph.D.(tfrudakis@dnaprint.com) Chief Executive Officer, President and Laboratory Director. Dr. Tony Frudakis is a Phi Beta Kappa, Magna Cumme Laude graduate of the University of California system. He received his doctorate degree in molecular and cell biology from the University of California Berkeley and has 14 total years of experience as a molecular biologist. Dr. Frudakis' technical experience encompass a range of areas within biology, including the molecular biology of eukaryotic transcriptional regulation, the creation and study of transgenic animals, the development of novel nucleic acid isolation techniques and gene discovery protocols, bioinformatics processing and anatomical gene expression profiling. At Corixa Corporation in Seattle, WA he developed several new techniques for RNA fingerprinting, managed and executed high-throughput gene discovery programs for various cancers and was instrumental in the companies early success in attracting R and D partners. Founding GAFF biologic in 1998, Dr. Frudakis established a good reputation for high quality DNA sequencing and library construction/screening services, until its evolution into the DNAPrint Genomics that exists today. In all, his work has resulted in a patent portfolio for over 350 unique genes and 2 products George Frudakis(gfrudakis@dnaprint.com) Vice President of Business Affairs. George Frudakis has vast experience with start-up company development. He started and developed a successful multi-component company called GAFF group, which today enjoys over 15 million dollars annually in revenue. During his life’s work as an entrepreneur and businessman, George has learned how to run and successfully manage the financial and operational aspects of both small and large companies alike. He is a graduate from the California State University at Long Beach in California. Myung Ho Kim, Ph.D. Mathematics(mkim@dnaprint.com) Director of Informatics and Lead Mathemetician. Myung recieved his Ph.D. in Mathematics from the University of Michigan in Ann Arbor in 1988 and M.S. in Mathematics from The Ohio State University in Columbus Ohio. Most recently, Myung worked on the Ant World Server project supported by DARPA (Defense Advanced Research Progect Agency) and implemented Kolmogorov-Smirnov tests, linear/nonlinear regression, nonparametric analysis and modeling to a TREC 6 (Text Retrieval Conference) project using SAS, C/C++ and Perl languages. Prior to this, Myung simulated mathematical modeling for breast tumors and implemented/developed various image processing algorithms. He has served as an Honorary research Fellow in the Department of Mathematics and Information Science at the University of Auckland, New Zealand and a Visiting Research Scholor in the Department of Mathematics at the University of California at Santa Cruz in California. Prior to coming to the United States, Myung held the position of Assistant Professor in the Department of Mathematics at Sungkyunkwan University in Soel Korea. Venkateswarlu Kondragunta, Ph.D. (vkondragunta@dnaprint.com) Director of Biostatistics. Dr. Kondragunta obtained his Ph.D. in Statistics from the University of Madras, Madras, India. He most recently served as a Postdoctoral Fellow at the Schoolof Public Health, University of Texas, Houston, TX under the tutelage of Dr. Ranajit Chakraborty, one of the most famous and accomplished genetic mathematicians in the world. His research interests include variance components, linear regression models, general linear models, design and analysis, discriminant analysis, principal component analysis and statistical genetics. He has taught courses in Variance Components, Design and Analysis of Experiments and Linear Regression Models and Probability Theory at Concordia University in Montreal, Canada. Dr. Kondragunta is an accomplished programmer and has amassed considerable experience with implementing statistical genetic ideas into C++, S-plus, FORTRAN (7 years experience) and JAVA code. His most recent work used the REG, ANOVA, GLM, VARCOMP, CANDISC, CLUSTER, DISCRIM, FACTOR, PRINCOMP and LOGISTIC tools in the SAS computing environment on real and simulated data sets. A partial list of publications for Dr. Kondragunta include: Chaubey, Y.P. and K.Venkateswarlu. A numerical study of some robust estimators of variance components in one-way model. International Indian Statistical Association Conference proceedings, October 10-11, 1998, McMaster University, Hamilton, Canada. Venkateswarlu, K. K.N.Ponnuswamy, and M.R.Srinivasan. Estimation of variance components based on diallel model. Mathematical Biosciences, V-150, 105-112. Venkateswarlu, K, and K.N.Ponnuswamy. Estimation of variance components based on bio-model of diallel crosses (balanced). Communications in Statistics (Theory & Methods), Vol-27, 139-152. Venkateswarlu, K. Estimation of variance components based on diallel model involving maternal and maternal interaction effects. Biometrical Journal, Vol-39, 287-295. 3.PRODUCTS&SERVICES see dnap web page for a complete description of products & services http://www.dnaprint.com/ SNiPdocTM High-throughput SNP profiling-To help us with our bottom line, we provide contract SNP profiling services to the drug development community. We call this service our SNiPdocTM service, and it is targeted towards pharmaceutical companies. Many pharmaceutical companies are seeking to enter into the field of Pharmacogenomics. This new field of study could have a dramatic impact on overall health care costs in the future. Furthermore, by having access to pharmacogenomics data, pharmaceutical companies can focus their clinical trials on segments of the population that are genetically receptive to the treatment. Experimental drugs can be targeted to individuals of a particular genotype, and genetic variations shown to underlie a poor-response to a trial drug could be used as a basis for eliminating the non-responding segment of the trial population from the study. In this way, pharmaceutical companies can reduce drug trial failures and the costs associated with them. Contracting this work out to service providers is a viable option for many smaller pharmaceutical companies who do not have the volume of work necessary to justify the price of the equipment and expertise. At DNAPrint Genomics, we offer multiple patient – multiple SNP sampling matricies designed on a custom, semi-custom or predefined basis. We can use our proprietary PhenomixM databases of medically relevant SNPs (numbering in the thousands of SNPs at present), or design chips for your application de-novo. We will work with your scientists to develop the experiments from beginning to end, that suit your needs, and we can handle your project from blood/tissue or DNA starting points. Data handling will be customized for each client; data can be deposited in our secure SNP relational databases system offering you the option of accessing your data over the internet. Alternatively, we can burn and hand-delivered CDs to Raging Bull Advertisements Looking for ORACLE E-BUSINESS SOLUTIONS? See Blasters and Disasters, Free! M4Logic All Your Accounts in One Place -- Free & Easy! From rem-conf Fri Oct 13 03:38:50 2000 From rem-conf-request@es.net Fri Oct 13 03:38:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13k2A3-00065l-00; Fri, 13 Oct 2000 03:33:59 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13k2A0-00065X-00; Fri, 13 Oct 2000 03:33:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02078; Fri, 13 Oct 2000 06:33:55 -0400 (EDT) Message-Id: <200010131033.GAA02078@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-es-05.txt Date: Fri, 13 Oct 2000 06:33:55 -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 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata Filename : draft-ietf-avt-rtp-mpeg4-es-05.txt Pages : 18 Date : 12-Oct-00 This document describes RTP payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for MIME type registrations and the use of SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-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-mpeg4-es-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-mpeg4-es-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: <20001012120848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001012120848.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Oct 13 08:51:34 2000 From rem-conf-request@es.net Fri Oct 13 08:51:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13k71l-0002dz-00; Fri, 13 Oct 2000 08:45:45 -0700 Received: from chocorua.east.isi.edu (purple.east.isi.edu) [38.218.19.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13k71k-0002dp-00; Fri, 13 Oct 2000 08:45:44 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id JAA04752; Fri, 13 Oct 2000 09:42:06 -0400 Message-Id: <200010131342.JAA04752@purple.east.isi.edu> To: jan.vandermeer@philips.com cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, rem-conf Subject: Re: Three documents In-Reply-To: Message from jan.vandermeer@philips.com of "Thu, 12 Oct 2000 23:41:21 +0200." <0056890014795482000002L922*@MHS> Date: Fri, 13 Oct 2000 09:42:05 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jan, all, --> jan.vandermeer@philips.com writes: >Please find attached three input documents for the La Baule meeting. M6447 >and M6448 are short documents; the first one is about MIME types for >carriage of MPEG-4 streams in RTP, and the second one about carriage of SL >headers within RTP. The third one, M6449, contains a rough draft of a single >specification for carriage of MPEG-4 streams over RTP. It includes major >parts of the drafts of Civanlar et al, Kikuchi-san et al and Roux et al, >while using the approach discussed in M6447 and M6448. > >Partly M6449 is in response to the question of Colin for a specific >proposal. Hopefully it clarifies where "I am driving to", to use the words >of Colin. More work is needed, but I hope that the basic concepts of M6449 >can serve as a basis for further convergence. Please feel free to use it for >more elaboration. A few comments.... The proposal in M6447 is identical in effect to defining two RTP payload formats, one with the length byte and one without. Saying m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4SL/90000 a=fmtp:96 MPEG4-SL-length-present=1 is the same as m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4SL-length/90000 and has exactly the same interoperability issues. If a length field is needed it will have to be mandatory, else you have potential problems. As an aside - are SL headers not self-describing? I was assuming that a terminal could parse them and decide when they were complete - is there no header extension bit? Regarding M6449: please submit this as an internet-draft! It gets very confusing otherwise... Colin From rem-conf Fri Oct 13 10:55:34 2000 From rem-conf-request@es.net Fri Oct 13 10:55:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13k8y9-0005W7-00; Fri, 13 Oct 2000 10:50:09 -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 13k8y7-0005Vp-00; Fri, 13 Oct 2000 10:50:07 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id E5A431E008; Fri, 13 Oct 2000 13:50:02 -0400 (EDT) Received: from vtpc3 (vtpc3 [135.207.133.223]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id NAA14293; Fri, 13 Oct 2000 13:50:00 -0400 (EDT) Message-ID: <018b01c0353e$64d59fa0$df85cf87@vtpc3> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: , "Colin Perkins" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "rem-conf" References: <200010131342.JAA04752@purple.east.isi.edu> Subject: Re: Three documents Date: Fri, 13 Oct 2000 13:52:45 -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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ----- Original Message ----- From: "Colin Perkins" > The proposal in M6447 is identical in effect to defining two RTP payload > formats, one with the length byte and one without. Saying > > m=audio 49230 RTP/AVP 96 > a=rtpmap:96 MP4SL/90000 > a=fmtp:96 MPEG4-SL-length-present=1 > > is the same as > > m=audio 49230 RTP/AVP 96 > a=rtpmap:96 MP4SL-length/90000 > > and has exactly the same interoperability issues. If a length field is > needed it will have to be mandatory, else you have potential problems. I completely agree with Colin. If the consensus is that such a length field is necessary, it should be mandatory and we can simply add it to the SL payload format. However, so far, I am not sure if such a consensus exists. I hope, this issue can be resolved in the MPEG meeting. M. Reha Civanlar From rem-conf Fri Oct 13 12:44:59 2000 From rem-conf-request@es.net Fri Oct 13 12:44:58 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13kAa6-0007VV-00; Fri, 13 Oct 2000 12:33:26 -0700 Received: from [202.54.13.177] (helo=mlcor00106.microland.co.in) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 13kAa3-0007Ux-00; Fri, 13 Oct 2000 12:33:25 -0700 Received: from g1ZX86hmc (2cust234.tnt2.league-city.tx.da.uu.net [63.28.252.234]) by mlcor00106.microland.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4Z6KWZDX; Sat, 14 Oct 2000 01:11:34 +0530 DATE: 13 Oct 00 2:23:02 PM FROM: B37ujpd4D@spammit.com Message-ID: <5hNaDR8o8250a88ip3> SUBJECT: Cut the carbs and lose the fat Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It's a scientific fact: High-carbohydrate diets simply don't work. When you consume extra carbohydrates and sugars, they simply turn into fat. But now, a scientific breakthrough has shown that the real secret to losing fat is to cut your intake of carbohydrates and sugars. It's no wonder that low-carbohydrate diet plans have become so incredibly popular these days. Our product is the first scientifically designed, all-natural, stimulant-free dietary supplement that helps you cut the carbs and lose the fat. It's As Easy As 1, 2, 3! This supplement helps to: 1. Turn carbohydrates into energy instead of fat. 2. Burn stored fat while promoting lean muscle. 3. Reduce cravings for carbohydrates and sugars. For a link to our website with full details and online ordering mailto:nocarbs@123india.com?subject=moreinfo Our product also presents an excellent opportunity for marketers and people in the MLM line of business.Please ask for marketing info if you are interseted This is a one time mailing, no need to ask to be removed From rem-conf Sat Oct 14 09:25:19 2000 From rem-conf-request@es.net Sat Oct 14 09:25:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13kTz0-00014f-00; Sat, 14 Oct 2000 09:16:26 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13kTwZ-0000xW-00; Sat, 14 Oct 2000 09:14:00 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id LAA06676 for ; Sat, 14 Oct 2000 11:59:16 -0400 Message-Id: <200010141559.LAA06676@purple.east.isi.edu> To: rem-conf@es.net Subject: AVT minutes from Pittsburgh Date: Sat, 14 Oct 2000 11:59:16 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached are the minutes from the Pittsburgh AVT meeting. Colin ------------------------------------------------------------------------------ Minutes of the Audio/Video Transport working group Reported by Colin Perkins and Stephen Casner. The audio/video transport working group met twice at the 48th IETF in Pittsburgh. In the first session we discussed IP encapsulation, header compression, RTCP extensions, forward error correction, and MP3 audio. The second session was for discussion of the payload formats for AMR, SMPTE 292M, DSR, SONET over IP, and MPEG-4. The meeting opened with an introduction and status update by Steve Casner. A number of drafts have been published as RFCs since the last meeting: - RFC 2793: RTP payload for text conversation - RFC 2833: RTP payload for DTMF and other tones - RFC 2862: RTP payload for real-time pointers The RTP MIB, MIME type registration for the parity FEC payload format, and the payload formats for DV audio and video are awaiting publication. The payload format for G.722.1 is in working group last call, comments are solicited. The working group last call on the revised RTP specification and audio/video profile completed in November 1999, with an agreed set of edits. These edits have now been completed. However, the issue of congestion control was raised: other protocols are required to have congestion control, why not RTP? Following on from discussion in Adelaide, a number of changes have been made to the RTP specification and profile to address this concern: the RTP specification has text to note that congestion control is required, but that the requirements are different to TCP and are somewhat context dependent, the details of the required congestion control SHOULD be specified in profiles. The audio/video profile has text from Mark Handley which notes that: - If on a network with QoS support, monitor to ensure service was received - If on a best-effort network, monitor loss and reduce the transmission rate or stop if average throughput is greater than what TCP would get Comments on whether the text in the drafts is sufficient, acceptable and appropriate are solicited. There were several comments from meeting participants. Some felt this text was not specific enough, especially for the multicast case, while others felt it was too early to specify the details of what could be done without further experimentation. Perhaps that means this text is vague to the appropriate degree? In discussion on the mailing list shortly after the meeting, the primary concern was that the user may want an RTP stream to get more than its share of the bandwidth of a narrow link near the user. It is expected that QoS support should be used in that case so that appropriate service can be requested, as in the first case listed above. The revised profile also includes changes received from the ITU for G.729 (new annexes), G.723.1 (diagrams). The latest revisions are available as draft-ietf-avt-rtp-new-08.txt and draft-ietf-avt-profile-new-09.txt. The chairs also noted that we have still to complete the RTP interoperability statement. A number of contact people were noted, and a meeting was arranged between the sessions to discuss this subject, and to assign work items (see below). Help from all implementors would be appreciated. The current drafts are draft-ietf-avt-rtp-interop-03.txt and draft-ietf-avt-profile-interop-01.txt. There are also a number of drafts which accompany the RTP specification: - The draft-ietf-avt-rtptest-03.txt on RTP/RTCP testing strategies is unchanged from the previous meeting. It is intended for informational. - The draft-ietf-avt-rtcp-bw-01.txt on RTCP bandwidth modifiers is also unchanged. It is intended to be a proposed standard. - The specification of the comfort noise payload is believed ready for working group last call. - The MIME type registration for the codecs referenced by the A/V profile (draft-ietf- avt-rtp-mime-03.txt) has been modified to add optional parameters for G.723.1 and G.729. H263++ has been added with `profile' and `level'. This draft is also intended for proposed standard. These drafts are believed to be complete. Anyone who has concerns about these drafts is urged to send comments to the mailing list. Stephan Wenger made a brief presentation on the applicability of RFC 2429 to the next revision of H.263 -- known as H.263++ -- which is in progress. This revision adds a number of annexes to H.263: - Annex U: enhanced reference picture selection - Annex V: data partitioning - Annex W: enhanced supplementary information - Appendix II on profiles and levels Of these, annex U does not affect the RTP packetization. Annex V does not affect the packetization so long as each slice is split into a minimum of two RTP packets (header plus motion vectors, and up to 8 bits of the DCT info in one packet; rest of the DCT in another). Annex W has many new features, the only one relevant to the RTP packetization being header repetition. This can be supported by including the repeated header in the current picture header, so long as the header is smaller than the maximum size imposed by RFC 2429. The appendix on profiles and levels is intended to ensure interoperability without very extensive capability negotiation, these profile and levels are referenced by MIME parameters. In summary, no technical changes are required to RFC 2429 to support H.263++ although some additional explanatory text on how to use the new features may be useful. It was suggested that this text could be added in an appendix to the payload format spec; Stephan said this would be done for the next meeting. Steve Casner noted that MIME subtype video/h263-2000 was added to the draft-ietf-avt-rtp-mime-03.txt spec for H.263++, so there are two MIME subtypes referencing RFC 2429, but this does not introduce an incompatibility since old implementations would not understand the new annexes. Tmima Koren presented enhancements to IP/UDP/RTP Header Compression (draft-ietf-avt-crtp-enhance-00.txt). There are three drafts which depend on these enhancements, two presented in AVT and a third on voice over MPLS. The change since the previous meeting is an additional section on bandwidth efficiency. Feedback is solicited on whether all, some, or none of these enhancements should be included in a revision of RFC 2508 for Draft Standard, especially from implementors of 2508 as to whether they would plan to implement these enhancements. Tmima also presented IP/UDP/RTP Header Compression over AAL2 (draft-buffam-avt-crtp-over-aal2-00.txt). This is an alternative to the CRTP/PPP/PPPMUX/AAL5 multiplex (draft-ietf-avt-tcrtp-01.txt) which AVT working group has agreed upon as the recommendation for multiplexing of RTP streams. The AAL2 method has comparable overheads for small voice packets but is more robust to cell loss. This is outside the scope of the AVT working group since what is required is a new ATM AAL2 SCCS identifier, but was presented here so the WG would be aware of this work. There was a comment that this falls into ITU-T Study Group 13 Question 5. A second comment was that this scheme would work for other RTP header compression schemes, such as ROCCO. Mooi Chuah presented a Light Weight IP Encapsulation (LIPE) Scheme (draft-chuah-avt-lipe-01.txt). This is another multiplexing proposal aimed at reducing the bandwidth used and processing load (compared with the header compression/tunneling in the TCRTP framework) at the expense of reduced functionality. Although presented as a means of transporting voice frames, this work is actually a general purpose layer 2 multiplex based on a new transport protocol as an alternative to RTP. This is outside the scope of the AVT working group charter, so it would require a new charter or new working group. There was a comment that introducing a new transport protocol, with a new IP protocol number, is a step that must considered carefully. Timur Friedman presented some RTCP reporting extensions (draft-friedman-avt-rtcp-report-extns-01.txt). These allow reporting of considerably more detailed statistics than the standard SR/RR packets: loss bitmaps (RLE encoded), receiver timestamp, and delay since last receiver report. These last two allow receivers to calculate the round trip time to senders -- it was suggested that allowing receivers to send SR packets with the packet and octet count fields set to zero would have similar effect. The major open issue is the use extended SR/RR blocks (the current approach) compared to the definition of new packet types. The authors are of the opinion that defining new RTCP packet types would be cleaner, and the consensus of the room agreed with them. The next section of the meeting was devoted to discussion of RTCP backchannel proposals. Colin Perkins introduced this by noting the issues to be considered during the presentations: - Restrict to unicast? Or allow limited multicast? - How is the timing of RTCP handled? How does this affect existing applications? - Are backchannel messages sent in compound RTCP packets or not? How does this affect the system? - Should backchannel packets be sent to the same port as normal RTCP? - Use multiple RTCP packet types or one plus subtypes? - Congestion control? - Can repair data packets be distinguished from normal packets? Does it matter? - Should we define one or many new profiles? Can we merge these drafts? The first RTCP backchannel proposal (draft-ietf-avt-rtprx-00.txt) was an RTP profile for RTCP-based retransmission request for unicast sessions presented by Koichi Yano. The changes made since the previous meeting include additions to the NACK packet format: - some payload specific fields which give flexibility for different deployment, but a default format is specified. - R-bit (Request bit) is for congestion control. It allows the receiver to give feedback on packet loss via a NACK, but by setting this bit to zero the sender does not retransmit the lost packet (and hence does not use bottleneck bandwidth). There are also a number of changes to the sender and receiver behavior: - A receiver should send NACKs for all lost packets (using the R bit to prevent retransmission, if necessary) - The loss fraction in receiver reports should take into account only original data loss - Senders should send retransmissions as soon as possible after a NACK is received - Calculation of metrics for congestion control is to be based on fine grained RTCP feedback, but no specific scheme is proposed. Finally, a brief explanation of the changes needed to SDP and discussion of deployment with existing payload types was made. There have been no changes to the RTCP interval recommendation. A number of issues were raised for discussion: On congestion control it was noted that although the draft describes how to calculate metrics like loss or RTT, it does not propose and particular scheme, should it? The author observed that it may not be possible to specify a single scheme because congestion control is dependent upon the payload and the environment. Also, are NACKs sufficient or might extended RR packets be needed also? RR is needed for sender RTT calculation, so rather than duplicating this functionality in the NACK packet, the author prefers to use both NACK and RR. What about use of this format for other purposes (FIR, NEWPRED)? The requirements for the RTCP interval should be similar, but should a new RTCP (sub-)type be defined? Should this profile be more general? This is to be resolved in discussions among the authors of these drafts. It was asked if the authors had considered including information in the NACK packets to indicate the length of time for which a retransmission is useful? Yes, but the desire to keep the protocol simple was thought to outweigh the advantages of this (and Dave Singer noted that so long as the server is consistent, the receiver can figure out if the retransmission will be received in time and use the R bit appropriately). How big a fraction of the RTP bandwidth is used with small packets? The authors discuss use with 1 kByte packets, but audio packets are a lot smaller than this. The fraction would be higher with small packets, but Steve Casner noted that it may be acceptable (in a unicast scenario) to use more control bandwidth if that is the appropriate balance for the application. He also noted that we would like to have a single profile for retransmission, with multiple payload formats as needed. That profile should at least be able to specify the RTCP timing in common for all the payload formats, and if possible, common congestion control mechanisms as well, though perhaps with different RTT calculation methods. The profile may support multicast as well as unicast. Koichi countered that we know how to do unicast now, but multicast is not so clear, so it may have to be addressed later. Roger Kermode noted that this work, and that in the other RTCP backchannel proposals, overlaps with that being done in the reliable multicast transport (RMT) working group and that coordination between the groups would be beneficial. The AVT chairs agree, and urge the authors of the backchannel drafts to study the work ongoing in RMT. The next presentation (draft-miyazaki-avt-rtp-selret-01.txt) was by Carsten Burmeister: an RTP Payload Format for Multiple Selective Retransmissions. It was noted that there patent applications exist which may pertain to this draft - an IPR statement has been received, and will be lodged on the IETF web site in the usual manner. This proposal is a payload format which would fit well with the profile specified in the previous proposal. This work allows for multiple and selective retransmissions in an attempt to solve the following problems: how does the receiver know if a lost packet should be retransmitted (since not all packets are of equal importance)? How does the receiver detect a lost retransmitted packet? To solve these problems, the concept of a second sequence number (SSN) is introduced. At the sender each packet is marked with an SSN-indicator and SSN. If the packet is `important' and should be retransmitted if lost, the SSN-indicator is set to one and the SSN is incremented; otherwise the SSN-indicator is set to zero and the previous value of the SSN is included in the packet. On reception, the receiver compares the SSN in the packet with the stored value from the previous packet: if it is the same, nothing important has been lost. If it equals the previous value plus one, and the SSN-indicator is one, an important packet has been received correctly. If it equals the previous value plus one, and the SSN-indicator is zero, an important packet - with SSN equal to that in the just received packet - was lost and a retransmission request should be made. The claimed advantages of this approach are selective retransmission (only important packets are retransmitted) and support for multiple retransmissions (retransmitted packets get a new SSN value, the receiver is able to detect lost retransmissions). It was asked what happens if the NACK packet is lost, is there a timeout to retransmit it? No, if the receiver gets other packets with a SSN, it knows the packet is still lost and can retransmit the NACK. How about using ACK which is more reliable if the error rate is high. Yes, but ACK takes more bandwidth. Stephan Wenger noted that there are only two priority groups here, and it is not easily enhanced to more than two groups. Maybe more than two levels are needed? The authors believe there are only two meaningful priorities: retransmit or don't. Steve Casner said that if there are several packets lost and a limited retransmission budget it may make sense to choose to send the most important vs. medium importance packets. He also noted that it may be possible to achieve the same effect using layering by sending "important" packets on a different port, with a separate sequence number space, and that this might avoid the need for the second sequence number. Next, Stephan Wenger presented RTCP-based feedback for predictive video coding (draft-wenger-avt-rtcp-feedback-00.txt). This draft discusses why feedback is needed for predictive video coding, and how to provide feedback in a timely manner for both multicast and unicast sessions. The motivation for support of multicast and unicast together is to avoid specialized solutions wherever possible, and to provide a solution which degrades smoothly as the number of members increases. This is "the RTP way". The draft defines a number of feedback message types: picture loss indication, slice loss indication and reference picture selection indication. The choice of when to send feedback is based on: - avoiding a single receiver which can monopolize the mechanism - avoid increasing the overall RTCP bandwidth - avoid feedback implosion - allow timely feedback if possible - support multicast (with graceful degradation as group size increases) The result is a formula which allows for sending after a random interval which is a function of the group size, retaining timely feedback for unicast sessions. Feedback requests inhibit other receivers, preventing implosion. There are several open issues on which comments from the WG are solicited: Do we want to use feedback suppression, as in SRM, or do we want feedback from multiple receivers to know how bad the loss problem is? The spec currently defines feedback only for video, but it should work for other media as well, should we do that? The proposal currently specifies that the feedback message is always combined with RTCP RR; should we do that? Or should the RTCP bandwidth budget be split between the two, maybe 50/50? Steve Casner asked if the needed RTT calculation is possible with the delay mechanisms available? Yes, pretty sure this is true. It was asked if the draft assumes real time encoding, rather than streaming >from a file where the buffer can be bigger? Yes, this is mostly intended for real-time. Henning Schulzrinne noted that may be quite useful for one of the recurring discussions in the SIP working group regarding DTMF tones, where there are different perceptions on whether FEC or retransmission is appropriate. analysis to see which is better. Does this assume only one packet loss per interval since the second packet cannot be NACKed? Yes. Jörg Ott replied that in unicast multiple NACKs are allowed still keeping within the bandwidth limit, but in multicast they are not. That is the tradeoff for scaling, and another receiver will likely send the needed NACK anyway. Simulations showed this works well unless the loss is as high as 10%, and congestion control rules may say you should cease transmission above that point. Finally in this section of the meeting, was a presentation by Shigeru Fukunaga on low delay RTCP for backward messages (draft-fukunaga-low-delay-rtcp-00.txt). This is the RTCP format for NEWPRED backchannel messages which was extracted from draft-ietf-avt-rtp-mpeg4-es-02.txt. The main features are as follows: - supports unicast sessions only - LD_RTCP is sent as soon as possible (without delay, even if this means violating the standard RTCP timing rules) - LD_RTCP packets are not included in the calculation of the send time for other RTCP packets - only LD_RTCP packets are included in one compound LD_RTCP packet (how does this affect compatibility? This rule is different from that for other packet types) - congestion control (actually rate control) since total amount of traffic is constrained to under 5% of RTP rate A number of issues were noted for discussion: the features of this proposal are similar to Koichi Yano's proposal - e.g. low delay, unicast - and it is possible to use that proposal as a profile of low delay RTCP after some modifications (define NEWPRED RTCP under RTP-RX profile). What about Stephan Wenger's proposal? Not considered low enough delay which is very important for the performance of NEWPRED; does not use ACK messages; and multicast may not be useful for NEWPRED. Stephan disputes the claim that very low delay is required, and reminded the list that he had recently sent a spreadsheet to the mailing list with his analysis. For a codec running at 10 frames per second, an extra 100ms delay only increases the size of the refresh frame from 2x to 2.5x the normal frame size. Steve Casner pointed out this disagreement will not be settled in the AVT meeting; the answer must come from those doing the video compression work, which may mean from another body. If there is no single answer, it may mean we have to specify multiple mechanisms. The chairs asked the authors of the RTCP backchannel drafts to consider if they could be merged into a single specification or at least a common framework/profile that can work for all these schemes, since there is believed to be much overlap between the proposals. This needs to be done soon because of timing constraints for working with other bodies, so the authors were requested to meet later in the day and report back in the second AVT session. The authors agreed to discuss this in a separate meeting, and report back to the second session of the AVT meeting (see below). Ron Frederick commented that it should at least be possible to agree on a common RTCP NACK/ACK packet format, possibly for either unicast or multicast. Ross Finlayson presented a more loss-tolerant RTP payload format for MP3 audio (draft-ietf-avt-rtp-mp3-02.txt). This format is a data preserving rearrangement of MP3 frames which removes backpointers making the result more loss tolerant, and optionally provides for interleaving. Changes since the previous draft are that each ADU is not preceeded by a descriptor giving its length, and the packing is no longer compatible with RFC 2250, since the 11 bit syncword is used for interleaving. It was already the case that a 2250 receiver could not process the MP3 payload format without the ADUs being rearranged, so all that is given up by this change is some potential for code re-use. The interleaving scheme provides for an explicit description of the ADU order, with an interleave index and cycle count. This differs >from the general interleaving proposal submitted on the mailing list by Orion Hodson, which is not specific to a particular codec and gives an algorithmic description of the interleaving. There was some discussion over the merits of a general purpose interleaving format vs inclusion into particular formats. Ross claims that explicit interleaving is a benefit for MP3 because of the variable frame rate and variable number of frames per packet. He would also like to avoid a dependency on progress of Orion's proposal. Feedback on this would be appreciated. Future steps include an update of the implementation to use the new ADU descriptor (and an open source code release), plus further tests of the interleaving. Ross has submitted a minor revision to the draft to change the number of bits in the interleave field. This payload format is thought to be ready for working group last call once the draft gets posted. The second session started with a discussion of unequal error protection and FEC which was held over from the previous day due to lack of time. The first presentation was by Adam Li on an RTP Payload Format for Generic FEC with Uneven Level Protection (draft-li-ulp-00.txt). It was noted that data in multimedia packets is not all of the same importance, and with some common encodings, the most important data is at the beginning of a packet. Hence this draft proposes a scheme for protecting just that data, and for layered protection (where the data earlier in the packet has more protection than that later), which is derived from the RFC 2733 parity FEC format. It was asked how format independent this payload format is? The encoder needs to know the format of the media stream, the decoder does not, and it can be used for any format with the required properties. Jonathan Rosenberg asked a similar question: how useful is this? He is not so sure that many codecs have the most important information at the start of the packet (e.g. H.263 has the data spread throughout, although the H.263++ extensions change this). Defining a new generic payload format may not be worthwhile if it is just applicable to H.263++. Reha Civanlar suggested layered coding; both techniques require partitioning of the data, but layered coding allows differential network QoS as well. Concern was raised that there may be IPR issue with this work - clarification is sought. Bernhard Wimmer presented draft-lnt-avt-uxp-00.txt, an RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams. The aims of this work are similar to those of the previous, except that an interleaved Reed-Solomon encoding is adopted (rather than parity FEC). Ron Frederick asked how much knowledge of the encoding scheme needs to be transmitted? How does one signal the amount of redundancy used per row? They have defined a scheme to signal how much redundancy is transmitted in each row. It is dynamic >from frame to frame. Dave Singer asked about the effects of this encoding on congestion control: when multimedia data is a significant fraction of the traffic, increasing the bandwidth for redundancy coding just causes more loss. Has there been an analysis of what would happen if there were many streams using this scheme and filling a link? No. Colin Perkins pointed out that we in AVT need to address congestion control. Over and above the basic requirements on RTP, this payload format has a feedback channel which adds data in the presence of congestion. Allison Mankin said an option might be that this is dependent upon using Endpoint Congestion Management (ECM WG). Since this draft was not offered in accordance with section 10 of RFC 2026, the chairs declined to progress it in the working group at this time. The authors were requested to clarify the IPR issues. Wimmer said a clarification would be sent to the mailing list. The next area of discussion was the RTP payload format for the AMR speech codec. This was opened by discussion of the liaison statement received from ETSI SMG2 (now part of 3GPP) delivered by Peter Barany. The liaison statement raises a number of procedural questions for the group: - Is the schedule for completion of the AMR payload format sufficient to meet the ETSI standardization deadline (December 2000)? Yes, we believe so. - How does the AVT working group plan to interface to ETSI? By members of AVT attending ETSI meetings, and vice-versa. In addition, concern was expressed that the proposed payload format may not be able to deal gracefully with a feature of the AMR codec, where frames which have bit errors (for example, due to poor wireless reception) are marked as damaged, but still transported. There are two aspects to this latter question: can damaged frames be delivered to an application, and can those frames be marked during later transit? The first issue is not one the AVT working group can resolve, and is rather for the lower layer protocol stack designers (e.g. the recent UDP-Lite proposal); the second can be solved by use of a `damaged frame' bit in the RTP payload header which is set when the payload contains errors (there are cross layer issues to resolve, since this bit must be set in transit, but again these are outside the scope of the AVT working group). Allison Mankin said that the UDP-Lite proposal did not get much support from link layer folks, but maybe now this is evidence of a link that would support it. Allison suggested approaching the transport area directors about following up on this, probably not in AVT but possibly. Ron Frederick noted that RTP translators and mixers would have to be aware of this `damaged frame' bit also, and that the interactions here are unclear (e.g. when mixing erroneous and non-erroneous data). It was also noted that AMR includes the existing GSM FR/EFR codecs as a subset, and the `damaged frame' indicator is needed there also, which may be an issue. Would these need to have revised payload formats which are indicated by dynamic payload types. Following this introduction we had presentations on the two proposed payload formats for AMR. First was draft-sjoberg-avt-rtp-amr-01.txt presented by Johan Sjöberg. This draft is a merger of the Ericsson and Nokia drafts from the last meeting. The main open issue among the authors is that this format currently supports 4 different Comfort Noise types. We probably want to reduce this to just the one AMR-specific CN format, and switch payload types if other CN formats are needed. Steve Casner endorsed this approach. The second payload format is draft-fingscheidt-avt-rtp-amr-00.txt together with a companion document that defines the MIME type for storage and RTP transport, which were presented by Bernhard Wimmer. This format provides for redundancy and parity FEC via a novel scheme. It was asked why existing standards (e.g. RFC 2198) could not be used. The claim is that the additional overhead of these more general purpose schemes is not acceptable. The issue is one of efficiency versus generality, and it is unclear if the trade- off selected for this draft is appropriate. In addition, the format defines its own frame type field: is was suggested that using RTP payload types here would be more appropriate. Henning Schulzrinne asked about IPR for this codec and availability of reference code. The code is downloadable from 3GPP, both fixed point and soon floating point. Bernhard did not know the IPR status. The chairs noted that these two payload formats need to be merged into a single proposal. This is the primary gating item for meeting the short timeline that was requested. Bernhard said the authors had a discussion before the meeting and should have a solution soon. Ladan Gharai presented an RTP Payload Format for SMPTE 292M video (draft-ietf-avt-smpte292-video-00.txt). This is the serial digital interface used for uncompressed HDTV at a data rate of 1.485 Gb/s with source formats of SMPTE 260M, 295M, 274M and 296M. The payload format is relatively simple, although the high data rate makes for a couple of unusual features: the RTP sequence number is extended to 26 bits in the payload header, to give a wrap- around time of ~170 seconds (a 16 bit sequence number wraps in less than 1 second). Also, unlike other video formats, this one uses a 10MHz timestamp to allow for precise timing reconstruction of the serial bitstream. Steve Casner asked if the format really needs the extended sequence number, since this may cause confusion with respect to the extended sequence number in RTCP. It may be that a one second wraparound time is not an issue, since the network can't buffer that many packets, or it may be feasible to infer the sequence number epoch from the timestamp. David Richardson noted that, whilst that may be so, the larger space may be needed to reference frames in other packets for error correction or retransmission, or for references between layers in layered coding. This is an area they are still working on. Ladan also presented an AC3 audio payload format, draft-gharai-ac3-01.txt. AC3 is the audio format used with HDTV. There was not much change to this draft since it was last presented. The authors are seeking comments, but there are no specific open design issues. Jeff Meunier presented draft-meunier-avt-rtp-dsr-00.txt, an RTP Payload Format for transport of ETSI ES 201 108 Distributed Speech Recognition streams. This is similar to sending compressed audio except that not all of the information required for playback is included, just what is necessary for speech recognition processing. Being new to RTP, the author solicited guidance on use of header compression, SDP/SIP usage and gotchas, robustness to packet loss and error concealment (in particular considerations for RTP over IP vs mobile IP), and packetization. In particular, the author is seeking public domain RTP implementations to help them get started. It was noted that maybe we don't need to send the multiframe header which is defined in this draft, since it is currently constant. Rather, it may be possible to omit it from the stream and send the data out of band. There was no out-of-band channel when the ETSI spec was being written (for non-RTP channels). If you gateway to a non-RTP channel, the gateway would need to re-insert this info in-band. A second version of the ETSI standard may have time-changing parameters in this header. Steve Casner noted that the current draft seems reasonable, but asked if the bandwidth savings (compared to using a normal codec) is worthwhile. Yes, in particular within a wireless environment, because this encoding is 4.8kbps vs 32kbps needed to do this with a normal audio codec of sufficient quality. The saved bandwidth is needed for other data exchange in parallel with the speech recognition. It was asked how much support there is from speech recognition vendors to use this common format. They tend to be very guarded about their implementations, and they don't care much about interoperation. This proposal has gotten some support, but it is a chicken-and-egg problem between handset providers and application providers. There is agreement on this algorithm as the front-end. The next presentation was preliminary work on an RTP Payload Format (http://www.tcb.net/plip/draft-white-sonet-format-rtp-00.txt) to carry SONET traffic. The motivation is to provide transport of legacy SONET data on IP networks where the lower layers do not support SONET, such as IP over photon or 10 gigabit ethernet. Although somewhat outside the traditional focus of the AVT working group, this appears to be a sensible application of RTP, in some ways related to the multiplexing proposals we have received in the past which seek to emulate a T1 circuit. The authors want to take advantage of the timing and sequencing functions of RTP in addition to more advanced functions like generic FEC. There may have been some confusion about the sequence number cycling back to 1 for the first packet of each frame, but it was explained that the sequence number must increment continuously across frame boundaries. Ron Frederick explained why the M bit marks the last rather than the first packet of a frame for video, and that this choice might be helpful for similar reasons with this format. It was also asked to what extent does this format will preserve SONET SLA characteristics? It is not intended that SONET error recovery mechanisms will be supported. Only the SONET payload will be carried in RTP, and the overhead would be recreated at the far end. IP error recovery mechanisms (e.g., re-routing) would be used instead. It was also noted that a similar technique could be used to support transport of ATM over RTP, should the need arise. The final area for discussion in the meeting was a framework document for the transport of MPEG-4 on IP (draft-singer-mpeg4-ip-00.txt), presented by Dave Singer. This is intended to provide a common framework for transport of any part - or all - of the MPEG-4 system on IP networks, to agree on that which can be agreed on, collect ideas and current practise, and is intended to be non-controversial. It refers to existing drafts and specifications only, explaining how they can be combined and what options exist. In terms of RTP payload formats for MPEG-4, the framework document suggests that one, simple, base-level scheme ought to be available which can transport any MPEG-4 stream (possibly non-optimally). Any receiver ought to be able to receive this format, and it's good if senders can be persuaded to send it. However, the draft also endorses the development of other formats which can be optimized for particular media types. MPEG are working on the development of a generic format, to be based on draft-ietf-avt-rtp-mpeg4-03.txt, and we have a media specific format in draft-ietf-avt-rtp-mpeg4-es-02.txt being developed in the IETF. Steve Casner noted that the chairs endorse this basic approach, and the consensus of the meeting was also that this was valid (although it was noted that some in the MPEG community would prefer a single format only). Several MPEG committee members were present. Zvi Lifshitz said he/they would take this approach back to MPEG to seek agreement. The timetable is an MPEG-over-IP Ad Hoc group meeting in September and a full MPEG committee meeting in October. Guido Franceschini asked if we could resolve the choice between "application" and "video" MIME type for MPEG-4. Some people felt that video is appropriate because MPEG-4 is used primarily for visual presentations, but others counter that MPEG-4 can carry active content such as Java. Discussion continues on the mailing list. Allison Mankin noted that this generality has caused considerable concern in the IESG regarding security due to the ability of MPEG-4 to transport active content (Java, ECMAscript, etc) and other potentially dangerous media. This aspect of any MPEG-4 payload format(s) will be reviewed thoroughly. In particular, in the view of the Area Directors the current Security Concerns section of the generic format (draft-ietf-avt-rtp-mpeg4-03.txt) is not sufficient. Allison asked that the next versions of the drafts posted for the WG have enhanced security sections so they may be reviewed. Colin asked for comments on all the drafts, both complaints and statements of support so we know which direction to take. The discussion on RTCP backchannel messages in the first day's meeting led to a separate meeting of the authors of those drafts, to consider how they could be merged. Jörg Ott presented a summary of these discussions. It was agreed that there is a good set of aggregate functionality in these documents, but the authors couldn't agree on what should be in the baseline document. The major issue is whether to include support for multicast. Some desire two drafts: one purely for unicast, one which also supports multicast. It was noted that timing is important due to market pressure, and multicast is perceived by some to take longer consideration. Steve Casner noted that the chairs do not want to make an assumption that this will be two drafts >from the start, we want to try to make a single document which supports both multicast and unicast. The authors agreed to try to merge the drafts, with a target completion date of December 2000 (last call after next IETF meeting). Colin Perkins presented a summary of the discussions on completing the RTP interoperability matrix, which occurred between the two sessions. It is believed that we now have a good handle on the RTP protocol interoperability statement, with a number of implementors volunteering to provide input. We are less advanced with the profile interoperability statement, although some progress was also made there. Of particular importance is that implementors of the more advanced audio and video payload formats provide test results, since this is an area where we are short of data. The meeting concluded with a recap of the action items and a call for acceptance of new work items. Those present agreed to that all of the following list of payload format proposals should be accepted as AVT work items and be resubmitted as AVT drafts: multiple selective retransmission, generic FEC with ULP, AC3 audio, DSR and SONET. Confirmation of this agreement must come from the mailing list, so anyone who believes any of these proposals are not appropriate for AVT work items is requested to comment on the mailing list. From rem-conf Sun Oct 15 22:37:51 2000 From rem-conf-request@es.net Sun Oct 15 22:37:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13l2ln-0002Xo-00; Sun, 15 Oct 2000 22:25:07 -0700 Received: from admin.englishharbour.com (PUSHING.ecexchange.com) [207.245.62.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13l2lk-0002Xc-00; Sun, 15 Oct 2000 22:25:04 -0700 Received: from EYEFX1 (196.40.42.250) by PUSHING.ecexchange.com (Worldmail 1.3.167); 16 Oct 2000 01:05:38 -0400 To: Email Address Owners From: mmcdonald@123go.com Subject: Top 5 Web Sites Date: Sun, 15 Oct 2000 22:50:44 -0600 Message-Id: <36814.951900092593900.24672@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Top 5 Internet Sites

TOP 5 Internet Web Sites

1. $1000.00 Weekly Give Away, Gaming Newsletters, Bad Bets section, Chat, Handy Caper's, Sportsbooks, Online Casinos & more.http://www.top100gamingsites.com

 2. Computer Systems, Desktops, Notebooks, Mac, Still photo, Webcams, Accessories, Cameras Software, Memory, Storage, & more. http://shopper.cnet.com/

3.  Cracks, Patches, Free Software, Free MP3's, Free Movies, Learn how to hack, Underground webmasters Search Engine http://www.astalavista.box.sk
 
4.  Cheap Long Distance Calling Rates Cheapest International calling plans available, Pre Paid International Calling Cards and much more http://www.callmaster.com
 
5. Cool Flash Animated Sites, Free games, Make your own Music, Online Greeting Cards The Best Sites on the Net are Found at  http://www.shockwave.com
 From rem-conf Mon Oct 16 04:51:49 2000 From rem-conf-request@es.net Mon Oct 16 04:51:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13l8kS-0005hx-00; Mon, 16 Oct 2000 04:48:08 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13l8kQ-0005hl-00; Mon, 16 Oct 2000 04:48:07 -0700 Received: from young ([150.183.107.207]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000101620475565:40396 ; Mon, 16 Oct 2000 20:47:55 +0900 Message-ID: <023901c03766$347a3530$cf6bb796@techway.co.kr> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: Subject: AHG meeting announcement Date: Mon, 16 Oct 2000 20:42:46 +0900 Organization: MP4CAST MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-16 08:47:56 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-16 08:48:13 PM, Serialize complete at 2000-10-16 08:48:13 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBhbGwsDQoNCkFzIGl0IGlzIHBsYW5uZWQsIHdlIHdpbGwgaGF2ZSBhIG1lZXRpbmcgb24g U2F0dXJkYXkgYmVmb3JlIExhIEJhdWxlIG1lZXRpbmcuIE1lZXRpbmcgd2lsbCBzdGFydCBhdCAx OjAwIHBtLiBUaGVyZSBpcyBubyAgY2xlYXIgbWVldGluZyBwbGFuIGZvciBTdW5kYXkgeWV0LiBC dXQgaXQgd2lsbCBiZSBkZWNpZGVkIG9uIHNpdGUgdG8gZXh0ZW5kIHRoZSBtZWV0aW5nIHRvIFN1 ZGF5LiBEZXRhaWxlZCBhZ2VuZGEgd2lsbCBiZSBwb3N0ZWQgc29vbiB3aXRoIHRoZSBBSEcgcmVw b3J0LiBQbGVhc2UgbGV0IG1lIGtub3cgd2hvIGlzIHByZXBhcmluZyB3aGF0IGNvbnRyaWJ1dGlv biBmb3IgdGhlIG5leHQgbWVldGluZy4NCg0KU2luY2VyZWx5LA0KWW91bmcuDQo= From rem-conf Mon Oct 16 05:10:43 2000 From rem-conf-request@es.net Mon Oct 16 05:10:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13l957-000700-00; Mon, 16 Oct 2000 05:09:29 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 13l954-0006zP-00; Mon, 16 Oct 2000 05:09:26 -0700 Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de with SMTP id OAA22680; Mon, 16 Oct 2000 14:08:54 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" To: "Young-Kwon LIM" , <4on2andIP-sys@advent.ee.columbia.edu> Cc: Subject: RE: AHG meeting announcement Date: Mon, 16 Oct 2000 14:28:15 +0200 Message-ID: <00d501c0376c$8ea186c0$aa1e4581@ksat10.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <023901c03766$347a3530$cf6bb796@techway.co.kr> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks, will replay tomorrow; will be there. Regards Paul Christ > -----Original Message----- > From: Young-Kwon LIM [mailto:young@techway.co.kr] > Sent: Montag, 16. Oktober 2000 13:43 > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: AHG meeting announcement > > > Dear all, > > As it is planned, we will have a meeting on Saturday before La > Baule meeting. Meeting will start at 1:00 pm. There is no clear > meeting plan for Sunday yet. But it will be decided on site to > extend the meeting to Suday. Detailed agenda will be posted soon > with the AHG report. Please let me know who is preparing what > contribution for the next meeting. > > Sincerely, > Young. > From rem-conf Mon Oct 16 06:25:37 2000 From rem-conf-request@es.net Mon Oct 16 06:25:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lAEv-0001wh-00; Mon, 16 Oct 2000 06:23:41 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13lAEk-0001vr-00; Mon, 16 Oct 2000 06:23:31 -0700 Received: from zvil (i0-29.j3.actcom.co.il [192.115.22.251]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA10054; Mon, 16 Oct 2000 15:23:40 +0200 Received: by localhost with Microsoft MAPI; Mon, 16 Oct 2000 15:23:13 +0200 Message-ID: <01C03784.FFB77DC0.zvil@csi.com> From: Zvi Lifshitz To: "'Young-Kwon LIM'" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "rem-conf@es.net" Subject: RE: AHG meeting announcement Date: Mon, 16 Oct 2000 15:23:12 +0200 Organization: Optibase Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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 Since I'll not be on Saturday I add my voice to extending the meeting into Sunday. I may supply a contribution. Thanks, z -----Original Message----- From: Young-Kwon LIM [SMTP:young@techway.co.kr] Sent: Monday, October 16, 2000 1:43 PM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: AHG meeting announcement Dear all, As it is planned, we will have a meeting on Saturday before La Baule meeting. Meeting will start at 1:00 pm. There is no clear meeting plan for Sunday yet. But it will be decided on site to extend the meeting to Suday. Detailed agenda will be posted soon with the AHG report. Please let me know who is preparing what contribution for the next meeting. Sincerely, Young. From rem-conf Mon Oct 16 09:14:08 2000 From rem-conf-request@es.net Mon Oct 16 09:14:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lCe9-0005CJ-00; Mon, 16 Oct 2000 08:57:53 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lCe7-0005Bz-00; Mon, 16 Oct 2000 08:57:52 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JVEDUAB0QSEVW8MX@GI.COM> for rem-conf@es.net; Mon, 16 Oct 2000 08:56:42 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Oct 2000 08:54:02 -0400 Content-return: allowed Date: Mon, 16 Oct 2000 11:57:43 -0400 From: "Narasimhan, Sam (SD-EX)" Subject: RE: AHG meeting announcement To: 'Young-Kwon LIM' , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Message-id: <973597126BDDD11197AA00805FA7EBC9034239FE@ntas0026.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="KS_C_5601-1987" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I will attend the meeting. Can you let us know where will the meeting be held - is it at a hotel or in the convention center. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Monday, October 16, 2000 4:43 AM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: AHG meeting announcement Dear all, As it is planned, we will have a meeting on Saturday before La Baule meeting. Meeting will start at 1:00 pm. There is no clear meeting plan for Sunday yet. But it will be decided on site to extend the meeting to Suday. Detailed agenda will be posted soon with the AHG report. Please let me know who is preparing what contribution for the next meeting. Sincerely, Young. From rem-conf Mon Oct 16 09:57:11 2000 From rem-conf-request@es.net Mon Oct 16 09:57:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lDXN-0006Y8-00; Mon, 16 Oct 2000 09:54:57 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lDXM-0006Xs-00; Mon, 16 Oct 2000 09:54:56 -0700 Received: from young ([150.183.107.207]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000101701051688:40566 ; Tue, 17 Oct 2000 01:05:16 +0900 Message-ID: <041901c0378a$27c39ec0$cf6bb796@techway.co.kr> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: "Narasimhan, Sam \(SD-EX\)" , <4on2andIP-sys@advent.ee.columbia.edu> Cc: References: <973597126BDDD11197AA00805FA7EBC9034239FE@ntas0026.gi.com> Subject: Re: AHG meeting announcement Date: Tue, 17 Oct 2000 01:00:07 +0900 Organization: MP4CAST MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-17 01:05:17 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-17 01:55:03 AM, Serialize complete at 2000-10-17 01:55:03 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBTYW0sDQoNCg0KPiANCj4gIEkgd2lsbCBhdHRlbmQgdGhlIG1lZXRpbmcuIENhbiB5b3Ug bGV0IHVzIGtub3cNCj4gd2hlcmUgd2lsbCB0aGUgbWVldGluZyBiZSBoZWxkIC0gaXMgaXQgYXQg YSBob3RlbCBvcg0KPiBpbiB0aGUgY29udmVudGlvbiBjZW50ZXIuDQo+IA0KDQpJIGRpZG4ndCBn ZXQgYW55IGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwbGFjZSB5ZXQuIA0KRG9taW5p cXVlLCBpcyBpdCBmaXhlZD8NCg0KU2luY2VyZWx5LA0KWW91bmcuDQo= From rem-conf Mon Oct 16 09:59:24 2000 From rem-conf-request@es.net Mon Oct 16 09:59:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lDaW-0006fT-00; Mon, 16 Oct 2000 09:58:12 -0700 Received: from p-mail2.rd.francetelecom.fr (p-mail2.cnet.fr) [193.49.124.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13lDaV-0006YY-00; Mon, 16 Oct 2000 09:58:11 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <453L3BXA>; Mon, 16 Oct 2000 18:55:02 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B6ADCD8@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: "'Narasimhan, Sam (SD-EX)'" , 'Young-Kwon LIM' , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: RE: AHG meeting announcement Date: Mon, 16 Oct 2000 18:56:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list at Atlantia, CORMORANS room _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel=20 > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ -----Message d'origine----- De: Narasimhan, Sam (SD-EX) [mailto:SNarasimhan@gi.com] Date: lundi 16 octobre 2000 17:58 =C0: 'Young-Kwon LIM'; 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Objet: RE: AHG meeting announcement I will attend the meeting. Can you let us know where will the meeting be held - is it at a hotel or in the convention center. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Monday, October 16, 2000 4:43 AM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: AHG meeting announcement Dear all, As it is planned, we will have a meeting on Saturday before La Baule meeting. Meeting will start at 1:00 pm. There is no clear meeting plan = for Sunday yet. But it will be decided on site to extend the meeting to = Suday. Detailed agenda will be posted soon with the AHG report. Please let me = know who is preparing what contribution for the next meeting. Sincerely, Young. From rem-conf Mon Oct 16 10:24:22 2000 From rem-conf-request@es.net Mon Oct 16 10:24:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lDxL-0000ZU-00; Mon, 16 Oct 2000 10:21:47 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lDxJ-0000ZK-00; Mon, 16 Oct 2000 10:21:45 -0700 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA00023 for ; Mon, 16 Oct 2000 10:21:43 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Mon, 16 Oct 2000 09:50:11 -0700 Received: from [64.164.234.115] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id JAA23631; Mon, 16 Oct 2000 09:50:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <01C03784.FFB77DC0.zvil@csi.com> References: <01C03784.FFB77DC0.zvil@csi.com> Date: Mon, 16 Oct 2000 09:45:19 -0700 To: "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> From: Dave Singer Subject: RE: AHG meeting announcement Cc: "'Young-Kwon LIM'" , "rem-conf@es.net" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 3:23 PM +0200 10/16/00, Zvi Lifshitz wrote: >Since I'll not be on Saturday I add my voice to extending the meeting into >Sunday. I may supply a contribution. > >Thanks, > >z I also cannot arrive until late Saturday, expecting a one-day ad-hoc on Sunday, so some meeting that day would be good. > > >-----Original Message----- >From: Young-Kwon LIM [SMTP:young@techway.co.kr] >Sent: Monday, October 16, 2000 1:43 PM >To: 4on2andIP-sys@advent.ee.columbia.edu >Cc: rem-conf@es.net >Subject: AHG meeting announcement > > >Dear all, > >As it is planned, we will have a meeting on Saturday before La Baule >meeting. Meeting will start at 1:00 pm. There is no clear meeting plan for >Sunday yet. But it will be decided on site to extend the meeting to Suday. >Detailed agenda will be posted soon with the AHG report. Please let me know >who is preparing what contribution for the next meeting. > >Sincerely, >Young. -- David Singer Apple Computer/QuickTime From rem-conf Mon Oct 16 14:32:24 2000 From rem-conf-request@es.net Mon Oct 16 14:32:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lHkf-0004Bt-00; Mon, 16 Oct 2000 14:24:57 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13lHke-0004BJ-00; Mon, 16 Oct 2000 14:24:56 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id OAA31669; Mon, 16 Oct 2000 14:13:07 -0700 Message-Id: <3.0.3.32.20001016141547.00aa1100@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 16 Oct 2000 14:15:47 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/18 DTV Application Software Environment and Interactive TV Platforms - Aninda DasGupta, Philips Consumer Electronics 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 DTV Application Software Environment and Interactive TV Platforms October 18, 2000, 1:10-2:30 p.m. Fujitsu Seminar Room (405 Soda Hall) Aninda DasGupta Philips Consumer Electronics Digital television systems are capable of delivering rich media services to viewers. With the use of Web and Java content, program producers are creating exciting interactive television content, and service providers are launching data broadcast services, over terrestrial, cable and satellite networks. In this talk we will briefly take a look at the evolution of interactive TV solutions. You will then be introduced to the DTV Application Software Environment (DASE), which is a proposed middleware standard that provides platform independence for all applications to run uniformly over all brands and models of DTV receivers. If time permits, some demonstrations will be shown. The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Mon Oct 16 22:07:49 2000 From rem-conf-request@es.net Mon Oct 16 22:07:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lOs8-0002Uz-00; Mon, 16 Oct 2000 22:01:08 -0700 Received: from mail2.microsoft.com [131.107.3.124] by mail1.es.net with smtp (Exim 1.81 #2) id 13lOs7-0002Rq-00; Mon, 16 Oct 2000 22:01:07 -0700 Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Oct 2000 21:59:44 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <45JMG0BX>; Mon, 16 Oct 2000 21:59:44 -0700 Message-ID: <33D69E5EAD06364FB98F3562E62ACE890D96C7@red-msg-02.redmond.corp.microsoft.com> From: Gary Sullivan To: "'rem-conf@es.net'" , "'itu-adv-video@standard.pictel.com'" Cc: "Joerg Ott (E-mail)" , "Stephan Wenger (TUB) (E-mail)" , "Stephen Casner (IETF) (E-mail)" , "Simao Campos (Comsat) (E-mail)" , "'fabio.bigi@itu.int'" Subject: Collaborative Letter from ITU-T Advanced Video Coding Experts Gro up Date: Mon, 16 Oct 2000 21:56:51 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The following collaborative letter was drafted by the ITU-T Advanced Video Coding Experts Group at its last meeting (Late August). I am sending it to the rem-conf group reflector as a means of informally conveying the contents to the relevant IETF working group. Attached is the draft document that is referred to in the letter. I can be contacted for any further information regarding the contents of this letter or regarding other issues relating to the work of the ITU-T Advanced Video Coding Experts Group: Document: Q15-K-56 (24 Aug. 2000) Question: Q.15/SG16 Source: ITU-T Advanced Video Coding Experts Group Gary Sullivan, Q.15/SG16 Rapporteur Microsoft Corp., One Microsoft Way, Redmond, WA 98053 Tel: +1 (425) 703-5308 Fax: +1 (425) 936-7329 Email: Gary.Sullivan@itu.int Title: Collaborative Letter to IETF AVT and MMUSIC Working Groups on Profile and Level definitions for ITU-T H.263 Standard Video Codec We are writing this collaborative letter to inform you of the current status of work in the ITU-T Advanced Video Coding Experts Group (ITU-T Q.15/SG16) on video codec design for IP-network applications. In an effort to provide configurations of video coding features that are customized to specific key applications and to simplify capability negotiation, we have drafted a new annex for Recommendation H.263 which defines specific normative "profiles" and "levels" of decoder capabilities. These profiles and levels will be defined in a normative manner particularly suitable for use in simplified capability exchange scenarios, specifically including SIP. Our plan for the development of this new Annex (draft attached) is to achieve preliminary ("determination") approval at the November, 2000 meeting of ITU-T Study Group 16, and then to achieve final ("decision") approval a few months later. This new annex is intended to replace the current informative definitions in H.263 Appendix II. The draft annex includes definition of a "Conversational Internet" profile designed specifically to address real-time conversational services on IP networks. Also included is a "High Latency" profile designed for non-conversational services which should also be suitable for many IP network applications. -- END -- begin 600 q15k51r3.zip M4$L#!!0````(`#>N4"F"SB^A\$@```"Z`0`,````<3$U:S4QHJG15=]L=`YEQ_(A[XL1M=[>=2`ATZ]:I MKAO?NK=R']U=)D@(L6;!H"`0BR"!A)@-K"/$0T(LF14!5F3#`LV6$0L4\_W_ M?\ZYY];#;L?.9$8S)=FWJ^J><_[G]S_.N?6=?_FY__RSO_G%CQLSKU<:7VA\ M\G"U\27OL^?Q[]_LFY]M-/X#E^?P[Y.'#Q_21_^*?Q_AW\,?OWYH7M_]BW]H M7%2K7VPT_O?G_\YI%B]\\HW[C<9/-_KO]-\Y_.KA5QMSK]4O?K71_L=&X^)[ M\N^?AO+Y@_E;^?7PX<\\]F_[BOG_T6K#7?V_EUU?\&;X]9^2ZY=>F;_NX/H* MKBU>J^W_UM-'X'JY_\O5&@YC^:UPOX?K?7Y?O%UU[7V@T?NE*H_%= MO/_)JXT&IFA\>"(>\[/\Q/O]*8_YE^?Z= MJPN^;,S3:>^SUX_-NO_U3;G.RM..LR_[_GLG(A<[;O9*\__Y\_/SS+[_T*QO M7W;\D[XL/Q]Z_'1^HIKOA;U&XP+T^]NPSLYS\WQ^VM1J^?E]7+^,J_K3 M/_[V_US\^^?(GOYJL[*[%U]K-'X/ZW_["+8R,\^+<(`OPV@V&F)_]/IGW/<= M7-]\3][_Y0W8[//5>[N^Y?,]\/.[N'Z"ZV\T'N\OSS?^'?_O'ARJMCK0L0[3 M\;A,HC`HHC3)U7X1)(,@&T0/^`.UK\,BS=;V#PZOOJU>NW/K<$]U+ZQ='AP' M2:@'ZFXTT*FZD@ZBY$A=.YWHK,C5:UE:3M3Z[5+G/$=WN[GVF[.OM6NQ/M9) M,5)O:%U@^"6UEV9%C.5;ZE:FC]*DI0[W+[=4K]?N;:G+Y5&9%WBWL;&Q>Z>,HI^4VFVO7HU@GP5A?4N]VM^]O=[/-SB`-UU[3 MBNC8,HOK1R[I>[:GVKM]U4%S2]8VH*#M14IQ7S[VP\(NOK*P<1$4, M=BXGB3Y5;ZFK60!2[^@A3(#$[Z1O]8'O\C(N5E;V2C":8R@/65F94V5-K6MF M@;6]+!U"#;FB.6]"UW&NKNIAE$0DLK6W.MW5W:3(TD$9\@?W(MA",=+J.,@B M74Q5.E3IA+X*8C5.!S33,7@/^K%648);HQPTDOUJF"S=V%)1H?!IF)5AA%'% M*"A4CJ4SO)ED>JBS#$9+DRF,ZT>)L?IAFF$M+=I4?:T&1*B&^O)49A%*VCH9 MB>$7.AMC.'@ZB>)8C8)CK0(UBHY&6"CM!_THCH2',(5`1,1%JG00CE0*-C-5 MYO19GHZURJ=)$9QBX0+STH()2^)\/\AU#$(ZY]4!L1NP;#%C$40@.U!QE!>T M2,7<4`=%F=7Y:ZF3481U`WR>%Q`.W3&`$$'0^8G1TWF:)R\G,.JBH]1NH:%RDJMD']&@C&L&.@#IC/H_$$MC#60<+WPD3" M+.J35+%(`@@IHD`$C_G#8"):B63F`/>'L(1,K?>G*I_H,!I.Z69#%]LM,^!Q MU6S1QT2&3D(`1'#$DH:K*V,:#$M&"3EI'-9D>&>1VU7%Z&`-$7`+J[(T8:90 MBL[8%L6$W(*&.^TTG&M@;3B":R8D;!!91&$9!UD\5<$$7$"B`#M99S``.6QP M(3`:UJ/N:[XMMM#?61,M>%XKZF.S,0ZA("H2YC"-X_2$[;?LAW%0YF;(`;EG MKN#=_/:M3L^H%]XBUA*Q]0F?QV`8I(OP(Y$/ST`#R9,+;^0@&L+&-9D9N7\$ M>X3#G&@MSL)R9=VSS^4Z+,F*[(*Y8`;&1`5\0`=C$+9OC)+,(9D:;9-5D8WD MWI=P\`7=!`-2(U$0`T5V?TT"[-`'"'#%ASF+P"* MC@`&ITR_6T:9.(`^!3#E#CUIFC@:1X69>1('!*+E!'X3).Q+(/]K;,X1]$OH M,@?2)#.VA>B!'I@U(U;K?:T)E0#%)H3,84D=2BP>1NR@SK'DPYF8DX_2,A[4 MO=AP9!6".8Q_S3E52R&FC!RF$VQ`[B&A5^6O*A^3(HP!S#/.8J(%C9S8^A`^ MR;A>-1%"&6-4Z_:/C>;:HAM:Q&]TE`3,2.[&;;1('-8F0;*.F.`*;JTAV?$4 M*@V:BUX@LV_9B/6'%=Y.G?#KT1IV^ZU7W>WL/ZP/=@8)B(L'BIZ3=%95G#"8 M(,ZH@Y&6:,_W*$%(QY32#'A($HL#6M(-@R+EWNJ-SF9OPZ6XPV$41M##5-T% MN41,#R(.[Y\@9VY?P;18W7`]IY&N:.3L$ZJ%$R[38/P6EN2<=!*%RF5=!N%U)30*,B8/<'<-RR04P[",&@2M,5O/ M)>E#`-U`'1LM+#&]=0&)`2`S26%+21B7D"TGO:#WL*7N( M+/.94,M6?FFMVUQU]=?NFP=W+EM;6I?4>[>IWE>'>85YC"B0$82J

QPX`=28@#>>?$BK]/JD)[2@T+U4P/K!O]8OBYY@P=`/N0(@4M),=N.6SA_"<&M MR(+0Q!X,VOG@HP]V%#-9BZXF_0L)RIT"2A%EX!(04%069"A3,KV($/SNS2NJ ML-:49B8JI'W.M"A3/4J0X(0!QAI%<)C$EW.J@-BNNQP9>4K.862QQCG\L04. M7$DD+C,!A%!RZN7T:[WFZE7-3--8U,A4;!BC^289S:LZ#$IK.+I&-41H0^F[ MI3B6SPA'^7$PI3@)FF,*T19B!M6:0UZS99B3=Q+83^#NP&$P002(,F%Z*?L' M'*5H&[TPVXDZYL9#K7E1U60=99@"+3#0G"U,\H):EN8'#),SS1$+CD0H*"TY M;3%>*5]ZX&(4&:?IQ"0G?+ND0T%NQC%4T6>RJ)&TF8T*$1"'XM74+,9%0*X> MI]FT*7"'2NR$Y+W(I?UB#-\12W/2JY$`6>55XN3,;,_X-6@D4;5\[Z2RT)B= MA:@R:X]3KI"/N6'4!AWM"DD<\A+]M@+HIR6UFBB,P#LG:5SI0>9BO-!);FI[ MA@$(3!`85@F@SQB=C"#F?4D0Z'&PHQ=HG4METSD8@4Y2@K,5`1%!NXK)%L." M:`J%'8G;%$5U`@8:3`U`'F7CM`["53J6G-$EMG&`PGZ21@D'BQ-QK_M&WO-> M+(;-``3<6:1%$BO7\'7UDZ]`GRV)03I!]B!B630'$4M1CTHVU`L%@(':+`@2 MR1*Z0'N92YIRHN.8F"OSUO*;GP#--INKUTNDS7O&G*YG6C_07-(9_F)US:O) M=Q-V#(GB@@\WJ^KU@YN=K>8'[W]`]C+$M&UKI4.9%J18P)^(D)T<6\:DN/:4 M9'*F0``H6M7D13KA[V#R20Z=$4^)/JF"ZC!+QXJ54!:P&A@511V;&`ON#:(< MX#(UMN)E9")O,,#ZAE50B]6BB1E%*R)BMH<$N33(+0W/(BJ]2$L:**.8W:J< MF`X7U:`S8SMK6\W5-^!^7,7?+LDR'M1D?4`!YJ!*1RQ^4/EW6I!##-35*P?P M%>N^!6HG))/G-`U,<2)H55-\B?9Q`/P^DXQ&.($=$`ZA?4&`8 M97"IXB2M2NR`,BL#.*3J&&6K$:31H)]Q4'A#$H'H!QU#M12;:]+Z6C[CZ7$: M#!C4-16_2=6+2C3HS71;!M92+G8F7PC2E,B)9!,SPK#,;'8%)\FJIA^<$^4S M;&U:!0=/$$YM\,`I-,><,/;CPR+F7`V$]9&?4YL<9$!BQ#K?F M&=/97+7U4_?,!5E/"K*S#EQ6>/4>4W@]HGSQP_59"Q4Q9*].05UV87-997(F M/*34)YG::.C*:NN_;LRQM*3JB="[NI%SE>!#)@*($2T(L*@:[<3Y9D''=0)&]`_,BC@\X,?,*!"*QZKQY)L[B&:0:&<`H/:'LRL9.&L1-:QU& M1@$+\478-]M&DME)KPT6`!4$]>3*:%'J,:HCJB2X'J%ARS?#9(3(N[6U$O0F9P!0B$ M-Q](A!1&.1_$Y">6N($^CJ@^_-'L..UK7:73O/'3@YWJL>J>H?.P='"/$_W] MF'8%]JNMRS<(T:"(1]C@/O,^K-S6AC MA*M`1NS5I>3Z`#IG$'YJ8NP*UC%-*-%*;-;+$%PS!F]TJ@'DC\A[QQH?0N7YG_^P<>#Y058D3"PL^ M1[SAQ)-QF$!N7TR75/\V"!R,'M&OM`FJ\2*S;;>44-/`;`D=$AC&B+LQ6TYE M!T=R*,4&-\IVH=885:Q\#;\W8B$^#B?L4XRHEO`71*M_9H$Y,H`S_B"3XRWWUR9/8( M-S3F\]KU[8#.;F@ZH%%(P/)R86HYC#,YCM%[=`"/ M@I=MR-W0`2'Q'63D8B-/U)N[Y^':O3(#E M6T9"CZ_'H920$TMZ=3A%A8'416PI",8+ZQ>21/2HXT1-^@` M/^+1-FLPCZK8@ZAG'+0/1[6?7&?*TN'9XB*MI)KUU,YUN/"LG9!2VE15",G/TP@Y2(##YR$,R=W3>.!%S@\ MW%6_ILYWSUO>KI+7FC]1W^;<@;7G+JT%S=5'[PO]"O&VUF^NQFERI&>Z M'M6N`!^*$7:$M[PR04F`D:\,IMYA'I/',61:]NWVH0=R750$>/ MR._N44>9=V%80ZZ#I\S6Z-S>GM=;6LAN=1#/G2PESCU^8[-1$@VGKH7N' M9;31PJ`![6-TP83.I&=42'"TQ_S,:-);A@ZECBURM?"=''95Q$M*4E M?:L*VW,YDL5$2B+%K2.;S[3-T=@*T0R6\$G"=_FTH)W,5%;(\]J6W3O0%IW^ MM$F+9=J+^H>=K:"=%Y&BS1,8[6^N]>T]7UN^U)T=ZT!P+8R M,6-,5+!Y)'#!`!N/,!D$SZ-/1XA4195OP0;]LY/\>95_/5VOZVGSB>W/,I_X MT6AVN?Z6M87O4Y^KVO/E$^BQ#HZIZ&$:+#_5KDK;[=5HVV4(4P@FB#F4D_G2 MS7#.=CIL"^Y9O*0Z1&J%'_?`/F4/C,!Z9R%8T]&J>;2^N!RM_0'+X/KBLX%K M29Q.V@:C:\?!&7>\+DMD:1L8G\GYL;//MUQZ%O!&2\Z+:2:2L808]'8K.5R/ M=#R`T@;NH<3KF+6WM=%F%LE`>CL[\F;/IBM+NP;=[K*V@>EKR1,Z)C$/$E\C MH@N73TO?0'KB\Z45/_+`7$M>+JHP>V4OKW*%?Q,61V*8,]P=+`EH?M6$D^;UD+W/`O=ZVPW38B.[.BA M-]H&@TVJB>&2$MT+)*=-HZC(Z[6,I`$`0[SZODP36U:V`6?GR7/#6)O M?JQ_7;HM=`[,U,-RTB\OYLEE3JPVUT5A=,.6*B>5D%$GIR=)3>A-J>)8_H%L MK@(*QVEI6SM^J/4"-F'4[!EXFM^>L9(C"^Q2'C'\>= M.*Z.+F9I>30"85NSYUPG&(003B=0D;,UN0_TJH>\!U:X^T`+]]2BR.>69^VW M.MW./!@3KO"S8C,U2_7$:E626KCH1P-8E'G&HU)N58O.I#$S;4NWL?!(9#1E M4R$E$Q^%HP#!)]$(5XH0>5$[N7*D[;^%5T)!5FZV- M#,PC&.N>O?Q=6$DC#G:V"6U,]EA[N-!%%(I5FZMV7@EW4J-9JD,YC)1)HAOI M?.V`GFG+.:S*X\_V5(GT!VR*4WNBU=AP7DF*WAB:6(*F3,S-KQ',AN#UVU=V MK[<4_[?%_W3!"#I5_?V=M[6HE!/L0IK=,A]\#]HOO8&0V;Q0RG*%.'-G9]?[MV3E1I>?%\LD[:]<>AR@A\KIT/*,/OOTE2N?KW\ZA M','1IO11%DQ&@OZYO4_FJI?@STK]I)MQI3J\\-]+4-4Y(UDCA02BDY.8D>:CCK)W.."LAKTO MK1X\LZM746K6CY88>2V$+%0Y+7&QM_$1*L@9;NHVZ*#3C;<6SZ7`4XMXB3T^ M0L#S9FH'C0+^!8G%TK5Z8"D[9;!=/8G$*>E[%G:U[%<@7/MZSJ#JSLB'U-[O;AV62Z5*&5ZHV.3!#]H5?-6YVM5?/# M1YA\SVNZ7'%/;*WMTQ:CQ73[_!\,&5:UW]S#G%QGW)A.Z*"YM&^J M@L&D4[(+;]F@/3CJ`"SX#9:NDWA%WIZ-1!N8@DM&M46_%I14WVR30.F+'5[E M#,1PUTW.^P^$&M+:F4J>R/^A%+8DMZ$YUP/A5-_]NHS]82/)07=,-T`G76E+*7IJ;+-TR=9U*;.].S=2ZEG)CC3/)I+OQ94LI62 M9*^4N/K%WJ[TG(SD)+^48*2HQRE*DEYX/0U)=GIW'8%.]-6?JQ#)KM#(JI3: ML^KDJ-Z=5SGVE,RZ%X3:$Z]W*$;J4D]/04A)5E.7;'>D9I[2]*59Z4OS2I_9 MN^EI"V35XDUOGUREP^A3CK,BJPEFX[STNB:8)-14\A5[QSLA,O)FIJ4'5R-2 MTI(3DBD32K*]0TV,2KM:)[4 M7-8#K2V7,ZQG>31+SO03:9EJR689SY.>S:F9M61SE&4L M.).,1VQE7E]AO%C,;0D9+[Q,*I\U45\!/G"RM;[`FE:5S_=-UE\:5B8M4LVA M.;5D+45+U=*T="U#R]2T-#D]FVW/,]1G63D%ANF9D%=:4%S10ROR^>CG9?B< MEZ<;V`4N`SM/GQ;.*\TKR/,;2EZVO&/.J'F6OGQ[AEQ_A_U3K!M2^J.D,IN, M5[T6SYJMN=V@1&>VM0S46L*GK[>V\M+]L*FFC?;Z<':RW6ZM&LWI[NPN=2P7 MD,H9:G,98+8]7[X=P+TNU7M9OOZ.`",V'@&[PW4XNV?;1TZSEB!,#CH\W>5G MV\OU]PV8RYL&S"#@*Z0Y:SX$I_@M2$S.1FNS?)8URM+G7CKG)RL*$E.R[25! M/"^L)U-)ZN!L>^G`/@724IVIQ&2(C,<,_?Y"OKYJ)6_ZC!G6^D)]V9_QKAYK M(8<<#>H/;)G#1?V6G_'*KAY*L$.SE1<13;MJ1I4K#T9[)DH;EJV^X,-\Y,_7 M6Z'K=K.Y]F5FMN]J$N,:U#[+K\NS9F:%^5=HKHTJ+ZDME,#KC*RP_0==5EYK MR+YK>Y0035>4F)H=^&D(_;4FKM9(?_^(H75WOA75GC_4=3== MN79QMGVHL1IYDM^B,SR[YM6IINVGY[]:-O3;>W;7S<`$]RW"'MFNW;WMYJIR1(G*"!F&?!Y>#I5= MQOC(*R?1ORK>RK+EHAK7*NCRR1?KQ660V1TK/BGD`V1]E6\LN7JRL7Y*ON), M\5(AVWT_3R?Z5O&1?JIX4$/[!^SG>YUH7-HK9'MY:=EQA5C3.F0EA6;H`RM* MRXN/+_R!KM`KKIGNVO:]PBC:2+\/TSUC!K6I5EI4*&>7ZM(=78)$4-GV[,7V5%+1Y]OVNQ MR4R/:4I]&M&U;,"XOV+N-*<[$Z,6%_F<+7MXCV<[W&$8=<'U((#1\TFE6VM< MK&!=DT8N.]`]K5=BF6ZM#2'%JZ M0\MPT#!7S?:R035]]B#!F9&>X$Q-[:'IDCX.R\P\#BE*R4'=EM3T_UF1Y@BF MQN.8WK['M6*RR(JK-?M)FAS)29&N03CFMI]=UN`T*DH:Z'Z.^_>Y* M8A`A`ZG2[^5$3I]AW-UU72A=N1!^S/%LI'M<$>694,QECT#-W*HU8',(=WP! MD\U!!:`]6+D&JI=.BU2F3=,FFG<*M$'(.E:"O]2-4;+&F,YX\0A98/H M@CG+',[)@,Q3LO0!3:(]K0_^52%=%5(\#Z4&EKBF*NJ7'UA:>D75[,*)>@SL MCF2/""1GJO[3G,EU%IV$G!496-;CDE]66NYG#MG]>(YFMZ>Y0\U`:9:46<.A M*'-^6G:<$Z^U)[O+O%2K6>0CS54Y1G3.O,",TGM"87D&9=AY$^7JM89S(?JU MDHK\\JRHH=/<=_#E6>;:-M>]IFFSKI@X63I^,SF%6@#M,^M)C M\Y+Z/4"7)^O"KK9,7M@]V9P8I?_*2U:TO6!H4?[P`<7Y=ONXGO;B_++!^04E M9<4#*NPQUH^_3)(_7.*4/P'3IFEIU<63L^S1]M(!@_/M,1,3Y(_/M,F"B<:7:/[/;LP(1RP`E9"9!,AHN`L6`+/PA;8 M"MM@#^R%ON%"7`!C8#XLA@&10EP"*UL)L1U^CA9B/_P"T3%"K(X5XDU8!^W. M%F)$G!!E,!*N@L>,BYHE0OL/3 M(^:-9SNR7T];R;`0,0):.H:U%GG#V@IKAV@?$C$O]#*IK/`(FWID9(2MC7'` M:V^$Z]SF'B&UX)H>.X9:^L^%_X`%9CGX$@Y`MBQ`A$=JB^+GSHQ^;+=K&VX9.D;^&V=3GD!@HY.%VEH^0!Z:* MB,T.$7+_,2WN2+P(GQGGO=G!O=G1O9FZ M.5S8FH5.%54'0H5H)N/51-CL'>:ZXBJ:2_VOI0CE7B[$T:/>EVQT9[(+L=E" M9'T^%WK!-7`[5,,^.`S+^X>Z3UBBGAVDD+\ST!%O=XF_6C).A-U_;%K8BS'C M8V5-V1KFZBY]RZS1LGSCZFT]]W5P7=71]]=GC6NIE:B MAC9A6EB@E-YC]]YU@FV"T*2.>]%W]X8TR`XW^G;9KX^%BY3^_65"R:5Y6PIM M:$[VJC%9TE\1/(YX>E.%AU7A(55X,*#P7ZKP9U6X.S@A6$=B0^-#FW43D041 MHBH^5+:4[)!;-GI.6SO]QX_/DCMM7EJ.>6P/9]@:B(YK*H5G23VZ[#9\_@NZ MMA!B-BQO9=AOTF:3=MK['>C=.@KQ2"?#/KL5$K'#IIMVF;3%=D*O!"$^Z.&E M>+49$%^JPA>JL#7@$8]S-@4GO*<*089VPA==I0J!0S-=\XZR5+58&!O::N&N M(Q/XKN1;EC)-/](DWA8>;]/+7T>S_*%4]@I;J%#*9/.0`.'H)33450)$2/1C M?2FA??4RW5;J2=K*TC[.ZR/$C;`3VWAHDF$3WPFYM!6P+/]A$C.%2*'.A`[2(AA<%A-=V#A%U78%]!;8.'' M@$*0%]T5T-L)1_2$$_>U\.?"0LQR$"[,0J.7F$Y6Z5#:+EEJK)(DXN381NHT M`UT.@`?A&W@\R]!MZ[Z&;MN"'>Z#'^'R'$/7SZ'GY9"&KN^`_NC[.KA>T?OD M$HY!X0@A*J!-F1"=H'\YY0PZ50C1'8Z"-E*(]%'$!\;")'@8'H'!YPLQ!!Z$ M_X8WX!T('\UYL`2>A=`+2"(4P0UP#]P+?X87X"UX'PY#U!@A6D)?R('!4`0S M8";<#$_#!V/DKW$?01>'Q0%]RY2.(![0=QN?:IUJY?O(MU]]OEG^?;1A]5?? M+O\6L,;3Y4@L1LB18$M&96Y1C@>C/$0MS9"L@PJ9__+4#?L'$(=7DH^5!(W2TB;XO=NAN" MWEJCLQSTU1X]_0JCT]#:LG\.:"P6Q4\JIR'X-$C>`@>K:Y' MT&M5(7``=1%>4H475>$9X>DTYNYK;5U$C6UQ"Z6]]]+00,5)?%<`OUT";MC;<%XJXN@.C1>,.6+$&MK MF]SG72;;2YV$0P0T@^9CC#91MH7](!?ZPP`8"'DP"/*A8(S17LIV\BJX&F;# M=7`#S(&Y,!\6CC':TCJI3VT/&H#ZU#Z\_J.S:Y)2FDQ=?QUA;?U_N+4E9_1\ M]2]ULA$^A(_@8_@$-L&GL`6VP1>P'>QCA>@,7>!NT`VZ0P+T@)Y0!,4P M'$J@=&Q#R*]JQRFK?74J34N#\A:DH#I=Z]\TM[;^*2<4??3_@:E_J=N]IGZE M[GI#H:G#43`6;H0YL`CNAU?A-5@/;\,&>!<@=.Z`M7P2RX"1;`0E@*_X!5L!KV MPJ_P&[2:0**A(PR%!W6PU;8!AD7"I$)`Z$`!L/!/0=W[MG^V:8] MVS\XR/?:/6NW;Y+2)FO7&_*?+GVVW6"3[M/ZTR7]WQNHQ#3CHM-==AM&FF&Z MJ59BF-P(:`.V=9]M&(VF[5>+;5@DZ^0(*(-RJ("1ILZEKF^">;``;H9;X7:X M$^Z&>\WR8)6%Y;`"5L(J6`UK8-U8HYR<>/5M8)V!.J]1_]%1G5[KOV]I;7V+ M\>E;_ZVZ*^OKI_`9;(&ML`T^AR]@.WPYUJC3LAXG0A(XP`G)D`*ID`;I9EV7 M=7P$E$,%'!ZGQ+!:C6Z]"+O'*9U!_4=GUY-!>0LLF+K>V];:^HDVPT?K^I'= MK84P$3Z"C\>=[.)>_6!0WDY;8Y!9WZ:%ZG0M[X^SMO;%"C_U7^IDTSBC M?Y7]:CQTA6Z0`#VA%_2!1'"8?:_LL*&D_50-^^!GV`\'I"[A%S@$A\<;-I:TKUI#-,1`&V@+[2!VPBG-K^H? M@O)VVDK3W*"\G5Q!=;K6C\5;6[]U$7[T+W5R-L29=K&TB8=!(11!,0R'$BB% M$5!FVLW25EX!*V$5O`&KX4U8`VOAK0F&/2UMZ/,NK%%].P(=J1_U?=*P&H-= M047'U'637M96:`]KR]9=^-&_U$D69$-?R(%^D`O]88`Y]ID#-\%F)CNITK3=-LK:T/L*/ M_N5X]D93OU)W=\)=L-K4XWOP`6R$;^$[^!D.2%U"="7M/'0".W2&=,B``3`( M+H`Q<#G,@9=@+6R$#R&VBC8(S@4'..$ZN!YNAEOA87@:GH=])7M M)8^:_SYT_XGMGSZH?\BX9L8]%7U,WM:X?^,]>`\X)K?NPU@K`7WOV*CC?G7$ M;\P!6#,&@>\!17O$R-SG$1OS0CFR3KX#&^!=4]]2Q]_##[`;?H2?8`_LA6K8 M9Y8#J?LVT!;:25W"V1`'[:$#=*PTRD>P5;>!&?7JF*S^H[/K+E&CT^MZBS1K M*RK%VHIT"M_Z'R?U(NMJ)IP'69`-?2$'^D$N]*\TZK.LQV-A/$R`2I@(DV`* M7`*751IU7=;SE^$5>+72Z[Y@X"5"IU#X0=5EO<3`0_CF$J57J$L`/D[7=/1Y MUE:K#.&C\W"AK/^)DWIY#9;#"E@%JV%-I=%&RW8Y#MI#!^@(G>`3`?%E2=[,I0/5O)P`;05-Q6W]%1G5X"VN586VVRA9_^ M7^ID8971S\H^]A%X%/X&C\'C\`0\"4_!WZN,?ECVP3_#?C@@]0J'X##\"D?@ MMRJCGY9]=#X43/16WW\J0@-07U&#*DV[!AU_=$Q==\RSMMH/L+;.SA5^]"]U M,AB&P%`8!H50#,--VTK:53?#+7`KW`:WPQUP)]P%=YNVU[WP%_@4$B\R;+%3 MF$?51X+R=MI*D"IXK&+9K@J;`PJ?B$#.UD5=D=I<7]/1-%:DQ8N,>)$9+\X; M%"*&Q.NZ=J_Y*IC2>;`P]7].OO#5?ZS4SQR8!POA5K@#[H9%L/BBFI;PG%RA MT9U"URR6*GKTA"W_[B`(04*:XOG:N-.^=B\=:O?2L78OYMIP8:X-#Y%Z7P9KX"/8`3_",3AK$G8>)$+N MI+K5:75.-EAO@<]I=$$[+=:SI?=?9YO)N9!ML`N^A:;HN1GT@)[0'T9"^&2" MA`S(A`NA$A;!??`RO`+;X!C$3!$B&1;#\W#.Q=B!D`]3+A7BXDN-Y\[>@0WP M3_@7_`*'Y".-E]/E@081T!2:P=D0!PYP0C;TA1SH#X<)3+7 MD+CGKE)R%1UWG1KN3D)C^_^':/^EWB^!!;`0GH%5\#'\`+NA+?6Y'21`/A3` M=+@2YL%#\#^P'MZ&K9-/G\WXNQ'JV_FOLVVV*FUVUYV*_\;Z_X>H_U+O-OKG M4&@"$1`)+2!ZRAE=(_Y8SG^=U:2.+5NMZQ&;VW]C_?]#U'^I]UPH@@O@8I@% M"^!/C?7_S'$!ZO^?E#%:5T?C_$]-^\[$^B_UOAH^A!WP$QR%LQBG=[JXL?Z? M,2Y`_9!26P!&(O%2(=C#YT@8W\JX7H<$Y_W4V1NK+FH_MJOKO&"`IT'KRX18SQA]%U`X7-5\'@W MP\$L1M4ZSK>IL6Q0?4M.;)"+T]P-1*_6E`LWD6_Z$]5J) MC2&M%CI^F\!W)=\BHI>(<41T*[6)>G#3;K`N8LJ0^.AZU(: M]J5+;;%0:S0;W>_-;8-!M?JJQ6U\^[MK#[WZ?JN[YHN_B\*G(N4PLAW(IQ`' MBRHQX]_LW0E\%$6^P/%_3R87"20A!PF!$$X!-4(($*XP@$"XPXV`$"#A4.20 M*R!'@"!XH"SX?.(^\6*%?;OZ7-=%%EA`1#ETGZCKA:OR\?E-[L[JE_UETT>:2]2)%$]+G9YS(*KJ;+A4TKY_]]5:PO0J'IDU M7[51S5=M7/-5?:>^J_]/B0#OPV(F2H3)7;C0G8IK-,K5#`K]U+$7Z#$R7R86&\X;"6.<"+$01Y1KBD")*B95" M*:6$$G-ZIAF2+>TI)YOE42V,Y.VG##5W6<<61N<61GX+H\O53G&UHF0C3LRO M+VDD@PH;"35QN%2)0VU+S#5+=%@EGA:;$@U*K".>+TM))U^$6=XX1E^WV\B@QG3784D!A$11FE3!4(B7X'E!?^]J*-2+,ZB9O+V(G M%`76S%FHYFMTEU?(\57E%=J6U\FL491-C2(I)%ZL+RZVODMXL$2;)0VV+:FS M65*T34E1E)0@WB\L=G\Q\6")"5%:/FMDL09'IGJ!T6;[(NI8D9.FOO@FES)4 M:;FVI:FO2XTAG:)949-G$M)J( M;`KYU<]Y,I.T?IPG[JG'O(\KI`E;/LNS.I,\6RXEETA=SCES!K]3B0>;&@YS M[6P5CX:UMBIO+N5YUDX,6+N5M'$])$E&*]:.,VLT@W6SB8U%G*U3W?E$S7,K9?A_:W-M0,9HHOM\Q1YD1TLWDE7.,: M!"E7G9DIMF5'6W&;SB58BHB&-8;+W(;=?LPU]UYZD+TG,L9L^4/&&$J(X4C. M(D(6<>1*J6=S\N9)AOM:85/%SHZ4[?/MFU_LWJ/%E!L?4*Y_^QL&W:\IVT\X M[`JWKDL%,IQC_H1YS.W;WL$\[IG5*FC%3(E9PT-&"?FCS7B;;I8Q5Z:1KYTT M$L\EG>OI#N?!A(H=SJ2*:[X)+&T2Z<6DIYBE#AOHD.&@EXNAEXN9;D;!R\9T M<_^J>%9GGFK[8K-_ZRR-Q:_Q!WE4=1I%U2KOZ3$H3X6`9SMY;.9^R!*K!0O.6S5><%YD(OM@/E>*B>2J1XS.,\_;.>:5+S!2FW*=LNGD5'VM MOC3=,.O4R%NG2>X8F$1Z'9O257Q=QG'B^`G M(?4=UU%^_;!7$>M<:$T[.!<\TYQ6W[LGS&E/.3?B_8YGL7DR4/-=NZ,[NRTI`'EFTUUQ!>.;RO MU+((OV5.OV61?LNB_)9%^RV+\5L66[6,QP&J,8*K9/^6(N>XM_^@0*1P"+W+ M:'J.R5:M1=1?/X8\1;?CD`V\CI"N_.Z47-(CY3@I4?)=A)H4NI6HWM3S4'\L M],1\K%5;P[OX$O'DK8MZ(+RD&9KC^&^NN;$9(@\V MI-59(NN1DRTR%[_%PX3T^[B\AOX)*0QV5K*W9P:W42R=S*W('9W(1LP7]U%00GN"T_V9=E_5FG4.3X`)'202*W#K*.6/VA+!LFDEDD\@W&C1#9/Y+V MCK:.YF`LQTJ48PTJ<#,VX%;B+?NB/!5B(Q2C#,BS'2I1C#2JP#B?P M$E[&*_@+7L7K>!-OX6V\@^RQ7//0#,W1`BW1"I>A-=J@+09C"(9B&(HP'",P M$J,P&F.P$JNP&FNQ#NMQ"V[#1MR)3=B#O=B'_3B`@SB$PW@.1W$,K^%UO($W M<1)OX:]X&^_@79S"E>.(6UR%=FB/7'1`'CJB$SJC",,Q$J,P!N,P'A,Q"<68 M@B4HPS++^#/^#]\A+_C8WR"3W$:9W`6G^%S MI$QD/R$-#9".##1$)AJA,;+0&?GH@J[HAN[H@0+TA`N],!X3<"TFH1A348+I MF(GK<#V>PF[\$7NP%_NP'P=Q"(?Q+#*NI6[(1",T1A::(!M-T0S-<1.68P56 M8A7*L1IKL!856(<'\"`>PL/8CD>P`SOQ:_PG?H//\#F^P)?X![[&.7R#;_$= MSN/J25PWT0_]48@!&(A!&(*A&(8*K,/-6(\-N`6WXC;`N5X`\UB4`D8A"'!"0C!;GHB<&X M!C.P"&NQ&5OP>QS"2SB%3W$>]?B3(@M-T!>C4(RYN`F/8A^.XMPTZSN64]$? M8S`56_`0'L.WB'-_YVHIIF,&YJ`^?ZX>QK/HP9U9+_S:VJ0JR;E_/-J^*_,57UOV*U)T:VH/2FZ%;4G1;>B]J3H5M2>%-V*VI.B6U%[4G0K:D^* M;D7M2=&MJ#TINA6U)T6WHO:DZ%;4GA3=BMJ3HEM1>U)T*VI/RD^U%?;_]Y<> MD!*?';B.2C'\4NS^QS"]%J78'\':5$/=KI]>2NT_.KJ&/SQ%GX.U)Z6F?5Q@ M2IUJ?5P=FSZN:AU%I23ZI=PK/H]RMQH]EOI8KA*<(E_GB;PX7J3_9)&3TT1< MUXLYVK<`?4"E9)1[W6:1(N?4J)PZY&DC,O!JZU/[3O*O4Y^(=W_:?-1$D5?P MY+7LN4DB72C[&+**1?9@K?KT[U3KD[9;L`,]2T1&XV2I2"62IXOD8C-^CZP9 M(GU1.DMDQBRKGOE4JRNZH3MZB#5:R85>Z"WF6'CI*VHD.&U$(09@H*A1RB)# M1(U+%QF&(@P7->)49"3<@V%D+,:!I@K-%)HH-$]HGM`\H6E2#+6/>E*O+OSZ M&(?U)$X;UABLY'$IE:FWL_,D&VKTHZJUIX9J#Y-1%HMU9)(;IU3^6WER4_-G M$_6SLK*QJ%'$DVF!&L.-,D=/=F"9^M>.]#R. M=`>?97GDZ$):/DO;\2K7;YDJJ0O/^>9R_V4=S*4=J(4JN8OMLLYF&1ULEZGZ MY_*Z^K(\\U_H-N2%:$.'$&VPKTM'<^^U"]$&NWIZVM`Q1!LZAZAG7HAZVF_/ MJF?[$/6TJXNGGIU"U#,_Q+[N&*(-G4*TP6Y[GC;8MZ^SNXS@;;"+,ZL-JM1/ M.?,4-:XP^,!@UWM".&NL73"]SM*6XU$FO/I$=85T41)WW%"EJ^+0:74DQ MPD54XD2-OE?GM4@],<>72B*2Q)JI(UG4'!_4!VEH`/5ISPPT1"8:B7C;NMD1 MW(SHX);$V1O@"L[=5O.*JJZB`VG@*`R@(:/Q%8UQT)C96(P,&M4<"30J`_MQ M%&-H8#'68B-B:&P2QF:3CANQ''?A/GR&QN1D],UYH+O(J-K8B M#_YRF![OTT5]C"YT+=U10MT`H]A%Y)4[XL%6(9_I\>] M?ZK5JW9UCT%1QS":"(TFBGZ:HLT857<%\\0:O_R"6&.,]SBM<<:]W&.-GT`& M\7N].X8GX*XK1'Z)O7@:CW'\?Z=P7`^C#QWX4+148WK[6^-8[W`?T\78Y3Z6 M2>YC&<=Q:C#!&DOUA7LL56JQ-9:J8[$U/BK+/29JB7LXQ2"]/ ML\8?-2FQQA[-+K'&'>TNL<8<-<43>+(T\!AWO4BJCH&Z5OP5;^,TSL#@NA5A M6#-P16,E%\95J'!;CQ9QUGCM7CYCMO=ULGSLMH3;UC(LQ8K.UK'Z)-\:DZT\ MX=:><[1[@35&NP!)0RV9W/I=A5MQ&S;B3AS!,;R-L2.L<=DMW6.LU7AH-6YX MC'M,L-*'X]O7?8ZNF&"-SUP_P1J?J<9=JG%Y5ZICSW%-Q0S,P4$-8O$2',F'S6#S6+2YM#W]R'2)GK7\"R?R#U!._/?9/,.9K+, MY\Z@(\]%HF;%4G-#3#'GH9CH7G(]VK,DES0U-]!TUFDO.>ZY1WY^=>B@ZZ#K MH.MP"=4A3GZ1>IML^FC;.Y4)@?\296?L!YGCW]LWI3)!`AZ&5+0\TVS>WO<^ MLEOV==IO6Y2WN.N3ZF72D^<-SRO[Y9Z6=LL>F7^ZL&VS;??9U67&\B:#AZZ\ M\5&[9>_._&K<0[?7-^S*?'U"Q93X?D_>;YN^B]SXJ M.VR7SW"W,_`1D:[F"503$MUS/E7--G7"$65-1'3/^;FM1?V1U\;,YBROGEG, MS`]$>C,_$$GF!R)59@>Y;CR>1\/-G:9E38VI:G>7.6IY&S/,W*&1VVMD49WMH699"S*,.J M;8RGMB[_G)GJ9:+*F6DD5?SO^4D\%_.L(B!'(LQU0H5/N^_\PZ?==^[P"9=Y MIN%MXDR#S#,-=^P9WDQ&Q`5F5>NK9GJR1]IF#UKM2'?V''%4%1%]045$^Q2A M]D!5,;$VQ>0[DRJ.?F,6D^^DF'QG,:\I)C:@F!QQ^A85=P%%Q=D4E6/.UUE5 M7-UJQ:F3N_B<_\E=?([BZ@8I+L>V'#;RU_;`!.3]L M$-!]!XT$^WLYJR<.7=NP-W)!:QOV1B[H-L/>R`7-&?9&+FAMP][(!=UFV!NY MH#G#WL@%K6VH&SE]9Z6[K9H4>1'OK-Q%2^!#_^'Y,_S#4U^O]/6J)D5>[.O5 M][BY"G>;K6^N+K6;*_7!%?76K_@\U-O+=J\W3=^:H`I6;\_Z+E=O*_N^5F_[ M^KY6;TG[OE9O;?L^U-O+OJ_56\.^K]5;S+ZOU5O`OJ\K?1[_01VSQ7TE=57M M$?4(_>Y?98T>?I<@OX>UK#[G7ZPS`YE("/*[)T_-UJXOP9;XEUG3;=>\CNJC M%C_6%/'JO^OU].=Z^G,]_;F>_EQ/?ZZG/Z_I].<_9+IS-=5YD^+J4YS[3FVN MIC)74Y=?K*G*BZ=9TY.K:]IQ]=$PST?`U,>.'8;E;L/_ M]3:CZG>[--_?55[C;>LNR;>,<.RVH=?5Z^IU];IZW9_'NH']S@\I\U)<1[5? M/=13I:MNN6%^(%[9%Z'>'[%>JT=/][,:0&,^U!C"TVKON=3;!:J`:!DMZOL[ MYXCZ;L\Y9FK5-[=YUE+/%&/^]/]=_97>/TV]9^1P1$5$.B,=$<[URR2;Y')/ M.>XBS._1NT%*9<'_MW=UOU%44?S,TFUI):3Q`8-&&$+D0^A*B=76&"QI2UD1 MJK9`?,*UN\@V;;?=;IM60-%:1:,(@N!'%510`Q45\!M-1065H(CV@?#"`W^` M,9K(@];?[Y[9;>W2ST13]?Z2W]R[,SOW8W;NG3UGSCE7N#YI!/6Y/66J?;<+NE#MOD!O8ID1M+)RV(,V)?9G=4J MK;+)6;2`?F]3A?K!J>"6ZN'.[0\=,/VU\@35@G[5N!49'".,QE++3K1&UR4W@+@IB#*V4/&Q=686[DBM?QI#G M?=JWEG$9KH2NSILP8ZT<.=['#9C,.^]8I'LKB>*AC%O\%_-%+WU)? MVG[.3><[=O]\L6)=[H%M$V7>[,-G&43@B*-^I3S^K.CXV`-R4/PH.HV=%_57 M_4W49]7X98F^\^$LRQ6$^;+M9J^LI8[ZLH8=]6=M<-2G=8.CXW&SH[ZM.Y#R MO56GHP^&O8[ZMW8YVHX+&5P57.1:,%BU,J_*714-1V)N22PG>?T1G,,\ZRH/Q=O:8FL3[NI8/.P6!19(63'+OOMZ MZJ[%Y#V8_)GU+2>OZ'9,_OC^K;_>V&W>V+(-3/G<89)PY_X!]E-E=3TZG3,P8.931 M6T5U`0^+Z@*>$-4%[!"-3=4I&HMJKZC,3^TH9?HCHG+Q4=%X55^(ELV8.]0) M^`;(^JI#C:FL.U]E7I;%=*Z74@_(=$].MB1-Z`9+I^5JF:/3(4S*U5:Q1>QE M5311&S%ULJRCTB>+N]Z^0M$SBKW/S+-_:VX/EJY9>EMPQ;+*5#\7(TUX);.< M?+DK55[_E-=Y.G@U2+UZ5!C++R8WI;1X@30M7C%R">P+&`VBZ@2GRZ4LR"TL M+"PL+"PL+"PL+"S^S4C*GDD3I+\[SC1E4TK)E#%=<(;0HDID)D@_OFN$EC,B ML\$YHC(\9?%Y8L1[R1.ZRXE<)[K,03ZX4#0>/OT("\`;1%<@H(Q=).D1_A=) M>I3_$ADZTO\R&3[:/V/P>_Y?(X[X'Q+J8'I[::I$NZ4(Z(5AE75@%*P1C>U/ MZ[4ZD+8W,5%=2R,8!YM$=03T36P!::E&'4P;>!^X7G1=@(W@_>`#H@9U#X(/ M@>VBNIH.\!'1-M'&[3'P<9!.D]3A/`EN`9\"MX+;P*?![:*ZG6?`G>`N4?N0 MY\#GP1=$=3XO@B^!NT7M1EX&7P%?%=4%[0-?`U\'WQ!=.V,_>$!4K_,F>!!\ M"WP;?`<\!!X6U1V]"[X'O@]^`'X(?@1^+*J'^03\5-2YL!O\##P&?BZJ:_I2 MM.\GD'X%?@U^`YX4U4&=\HY_A_0T^#UX!OQ!U/ZEQSO^N\>SWNG$[E=M%&/T/D'G!F4//Y&+4A[*DU(V_TF"P:MF`T]3\*KMB@^=4F0F=X M$-N\X7$E^L_YFO/V2.LG\HYIZC<:P3JC+^1O'T3M:TV;ZLPO$T5^*%N_.6.X M_L>Y\2Q[_6D]'UU["E$_GUNCJ?];;KSZ'6,_68>YM`)W0 Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: Subject: 4onIP AHG meeting on Saturday Date: Tue, 17 Oct 2000 19:24:06 +0900 Organization: MP4CAST MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-17 07:29:17 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-17 07:29:34 PM, Serialize complete at 2000-10-17 07:29:34 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBhbGwsDQoNCkkgZm91bmQgb3V0IHRoYXQgdGhlcmUgYXJlIG1hbnkgQUhHIG1lbWJlcnMg cmVsYXRpdmVseSBhY3RpdmUgc28gZmFyIGhhdmUgcHJvYmxlbSB0byBqb2luIFNhdHVyZGF5IEFI RyBtZWV0aW5nLiBTbywgSSdtIGNvbnNpZGVyaW5nIHRvIHBvc3Rwb25lIGl0IHRvIFN1bmRheS4g UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZXJlIGFyZSBhbnkgcGVvcGxlIGhhdmluZyBwcm9ibGVt IHRvIGpvaW4gdGhlIG1lZXRpbmcgaWYgd2UgaGF2ZSBhIG1lZXRpbmcgb25seSBvbiBTdW5kYXkg aW5zdGVhZCBvZiBTYXR1cmRheS4gSWYgSSBkaWRuJ3QgZ2V0IGVub3VnaCBzdXBwb3J0IGZyb20g bWVtYmVycyBJIGNhbiBub3QgY2hhbmdlIGFueXRoaW5nLiBQbGVhc2Ugc2hvdyB5b3VyIGhhbmRz Lg0KDQpTaW5jZXJlbHksDQpZb3VuZy4NCg== From rem-conf Tue Oct 17 07:12:09 2000 From rem-conf-request@es.net Tue Oct 17 07:12:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lXO1-0002BB-00; Tue, 17 Oct 2000 07:06:37 -0700 Received: from audrey.enst-bretagne.fr [192.108.115.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lXNx-00021D-00; Tue, 17 Oct 2000 07:06:33 -0700 Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9HE2Io13731; Tue, 17 Oct 2000 16:02:19 +0200 Received: from pchoukair (pchoukair.enst-bretagne.fr [192.44.75.57]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id PAA22577; Tue, 17 Oct 2000 15:59:08 +0200 (MET DST) From: ddma-announcement@enst-bretagne.fr Message-Id: <3.0.3.32.20001017155227.0097daf0@antares.enst-bretagne.fr> X-Sender: choukair@antares.enst-bretagne.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 17 Oct 2000 15:52:27 +0200 To: ddma-announcement@enst-bretagne.fr Subject: DDMA workshop CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_971783547==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_971783547==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague, You are invited to submit a paper to the International "Distributed Dynamic Multiservice Architectures" (DDMA) Workshop. This workshop is in conjunction with the 21st International Conference on Distributed Computing Systems (ICDCS2001), one of the major conferences in the Distributed Computing Systems Area. DDMA workshop covers aspects concerning adaptive architectures and service composition and management. The submission deadline is November 1st. Further details are at the web site http://ddma.enst-bretagne.fr/. A text version is also in attachment. The DDMA workshop will be held in Phoenix, Arizona; April 16-19, 2001. The proceedings of the workshop will be published by IEEE CS press. [We apologize if you receive multiple copies of this announcement] --=====================_971783547==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ddma-cfp.txt" Call for Papers International Workshop on Distributed Dynamic Multiservice Architectures http://ddma.enst-bretagne.fr/ in conjunction with ICDCS2001 sponsored by IEEE Computer Society April 16 =96 19, 2001 Phoenix, Arizona, USA The growing need to integrate new services while complying with the= requirements of end=20 users puts strong emphasis on the management and combination of future= services and the QoS=20 they should be able to provide and guarantee. Dynamic Multiservice= Architectures constitute a=20 challenging paradigm for distribution theory and practice due to their= unique requirements in terms=20 of adaptability, behavioural integration, separation of concerns, service= composition and service=20 management. In particular, the deployment of multimedia telecommunication= services is a highly=20 challenging area where those paradigms should apply because advanced= services require that the=20 user's profiles, preferences and context be taken into account. "Distributed= Dynamic=20 Multiservice Architectures" hence add a new dimension to distributed= computing to help the=20 composition and deployment of new services guaranteeing final user's= requirements. The goals of this workshop are to bring together users and researchers to= present their=20 recent work related to diverse aspects of dynamic multiservice= architectures, their fundamental=20 issues, their paradigms and some appropriate approaches and experiments. The= workshop will=20 thus present opportunities for discussing further evolutions and their= expected benefits. Scope of Workshop ----------------- The scope of this workshop encompasses but is not limited to : Evolution of distributed multiservice architectures Separation of aspects and composition of aspects. Methodological approaches for aspect oriented programming. Components as cornerstones for dynamic composition. Composition requirements for reflection. Auto-adaptive ad hoc architectures and protocols. Impact on the management and control Management of adaptive architectures Management and monitoring of composed services. Platforms, tools, languages, ...=20 Languages, tools and platforms for auto-adaptive systems. Environments for specification and design of dynamic architectures. Experience with design, implementation and use of auto-adaptive systems. Application to telecommunication services Open critical issues in terms of composition of services. Panorama of QoS integration approaches for multimedia telecom services. Paradigms and requirements for telecom services architectures. Architectures for 3rd generation multimedia services. Distribution protocols for telecom (WAP, CORBA, CAMEL, mobile agents). Submission Instructions and Workshop Format ------------------------------------------- Interested participants should submit a 4-8 pages position paper that= focuses on one of the=20 relevant topics or related issues. Papers will be reviewed by the program= committee. Electronic=20 submissions should be sent to zied.choukair@enst-bretagne.fr. Mail body= should include name,=20 address, affiliation and a brief biography along with paper's title and= abstract. The workshop will follow the following format: The morning and part of the= afternoon will=20 be dedicated to presentations and discussions of accepted proposals,= including demonstrations of=20 existing software. The afternoon session will end with an identification of= issues, followed by=20 discussion. The organisers will then elaborate a summary of the workshop= based upon a summary=20 of the papers and the major outlined points of the discussion. Program Committee Members : Mehmet Aksit, Twente University, NL Zi=E8d Choukair, ENST Bretagne, FR Jaime Delgado, Universitat Pompeu Fabra, ES Byung-Guk Kim, University of Massachusetts Lowell, USA Marwan Krunz, University of Arizona, USA Abdul H. Sadka, University of Surrey, GB Antonio Rito Silva, University of Lisbon, PT Timothy K. Shih, Tamkang University, TW Katsuya Tanaka, Tokyo Denki University, JP Important Dates : Paper submission due : Nov 1, 2000 Notification : Dec 30, 2000 Camera ready : Jan 20, 2001 Conference : April 16-19, 2001 Web Pages : Conference URL : http://cactus.eas.asu.edu/ICDCS2001/ --=====================_971783547==_-- From rem-conf Tue Oct 17 08:38:53 2000 From rem-conf-request@es.net Tue Oct 17 08:38:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lYnC-0005jW-00; Tue, 17 Oct 2000 08:36:42 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lYn8-0005iu-00; Tue, 17 Oct 2000 08:36: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 LAA14348; Tue, 17 Oct 2000 11:36:35 -0400 (EDT) Message-Id: <200010171536.LAA14348@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP payload format for MPEG-4 Audio/Visual streams to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 17 Oct 2000 11:36:35 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider RTP payload format for MPEG-4 Audio/Visual streams as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 31, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-05.txt From rem-conf Tue Oct 17 09:42:56 2000 From rem-conf-request@es.net Tue Oct 17 09:42:55 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13lZmf-0003wo-00; Tue, 17 Oct 2000 09:40:13 -0700 Received: from igate.nuera.com ([204.216.240.98] helo=sd_exchange.nuera.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 13lZmb-0003uk-00; Tue, 17 Oct 2000 09:40:11 -0700 Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Oct 2000 09:38:26 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FECC17CA@sd_exchange.nuera.com> From: "Bratakos, Maroula" To: "'rem-conf@es.net'" Subject: RTCP BYE Date: Tue, 17 Oct 2000 09:38:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list What is the role of the RTCP BYE when a control protocol, such as SIP, is being used to create and terminate sessions? Thanks in advance. Maroula Bratakos From rem-conf Tue Oct 17 10:57:19 2000 From rem-conf-request@es.net Tue Oct 17 10:57:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13laH2-0001I9-00; Tue, 17 Oct 2000 10:11:36 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 13laGz-0001Gq-00; Tue, 17 Oct 2000 10:11:33 -0700 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id RAA21040; Tue, 17 Oct 2000 17:12:30 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 17 Oct 2000 17:11:15 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id <4YTTGZW7>; Tue, 17 Oct 2000 10:11:14 -0700 Message-ID: From: "Mozumder, Monir" To: "'Bratakos, Maroula'" , "'rem-conf@es.net'" Subject: RE: RTCP BYE Date: Tue, 17 Oct 2000 10:11:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Maroula, I think (correct me if wrong) the answer lies in layering principles. SIP sits in upper layer which uses the service of RTP. When SIP sends terminating commands, it will direct RTP to send RTCP BYE, which will ultimately indicate the other SIP side RTP(s) to notify their respective user-SIPs as termination indications. Thanks, -Monir Trillium Digital Systems -an Intel Company. -----Original Message----- From: Bratakos, Maroula [mailto:mbratakos@nuera.com] Sent: Tuesday, October 17, 2000 9:38 AM To: 'rem-conf@es.net' Subject: RTCP BYE What is the role of the RTCP BYE when a control protocol, such as SIP, is being used to create and terminate sessions? Thanks in advance. Maroula Bratakos From rem-conf Tue Oct 17 14:22:47 2000 From rem-conf-request@es.net Tue Oct 17 14:22:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13le98-0001hQ-00; Tue, 17 Oct 2000 14:19:42 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13lbhl-0003rP-00; Tue, 17 Oct 2000 11:43:17 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id LAA04278; Tue, 17 Oct 2000 11:33:34 -0700 Message-Id: <3.0.3.32.20001017113615.00ab49a0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Oct 2000 11:36:15 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/18 DTV Application Software Environment and Interactive TV Platforms - Aninda DasGupta, Philips Consumer Electronics 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 DTV Application Software Environment and Interactive TV Platforms October 18, 2000, 1:10-2:30 p.m. Fujitsu Seminar Room (405 Soda Hall) Aninda DasGupta Philips Consumer Electronics Digital television systems are capable of delivering rich media services to viewers. With the use of Web and Java content, program producers are creating exciting interactive television content, and service providers are launching data broadcast services, over terrestrial, cable and satellite networks. In this talk we will briefly take a look at the evolution of interactive TV solutions. You will then be introduced to the DTV Application Software Environment (DASE), which is a proposed middleware standard that provides platform independence for all applications to run uniformly over all brands and models of DTV receivers. If time permits, some demonstrations will be shown. The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Oct 17 14:28:51 2000 From rem-conf-request@es.net Tue Oct 17 14:28:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13leGm-0003C1-00; Tue, 17 Oct 2000 14:27:36 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ldIq-00013P-00; Tue, 17 Oct 2000 13:25:40 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA10878; Tue, 17 Oct 2000 13:25:38 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA14544; Tue, 17 Oct 2000 13:25:37 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id PAA08956; Tue, 17 Oct 2000 15:25:36 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id PAA23198; Tue, 17 Oct 2000 15:25:35 -0500 (CDT) Message-Id: <200010172025.PAA23198@agevole.cig.mot.com> Date: Tue, 17 Oct 2000 15:27:19 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Qiaobing Xie , Mikael Degermark , Krister Svanbro , Magnus Westerlund , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> <200010052313.QAA05736@baskerville.CS.Arizona.EDU> <200010062153.OAA10257@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mikael, Sorry for not responding to you sooner. Just got back from my mini vacation... See my comments below.. regards, -Qiaobing Mikael Degermark wrote: > > Hi Qiaobing, > > I didn't realize that you were mostly talking about the error resilience properties. > I thought you were mostly arguing for a more CPU friendly packetization format. Yes, error resilience is one of the key reasons people like AMR. I'd like to see the RTP payload design really taking advantage of this. The current avt-amr draft is not very effective on this aspect. For example, with the compound payload format defined in the current avt-amr draft, if one would use some partial transport checksum to cover the "robust sorted" most sensitive bits in the payload, then any bit error in that part of the payload will cause the whole packet being tossed by the transport layer. This doesn't sound right to me. CPU friendly of cause is always desirable to any protocol design. The bitwise sorting in the current avt-amr draft will be a waste of CPU unless the authors can show us clearly how that would benefit the general AMR over IP application. > Seems that the latter issue has been resolved in favor of non-byte aligned if I > correctly understand the performance measurements put forward by Ericsson people > concerning the relative costs of encoding/decoding and packetization. > > Seems like a no-brainer to me. Coding/decoding is so much more expensive > than packetization that optimizing the latter to save on processing is pointless. > This also makes it meaningless to have a bit distinguishing the two formats > as have been proposed. Comparing to an LPC-based voice coder such as AMR, nothing is more expensive CPU-wise. That's why DSPs were invented :-) One should keep in mind that the RTP payload frame formatting is merely an adaptation layer between the application and transport. > But your argument against the amr-00 proposal not really about packetization > efficiency, if I understand your latest letter correctly, but instead about > error resiliency. Isn't that correct? Yes, as I said, my main concern is error resilience. If certain complexity is what it takes to make the design error resilient, I will happily accept that. But I fail to see how the complex bit sorting can contribute to the error resilience of the design. In the contrary, I think it is harmful to the error resilience. > If correct, we should stop arguing about packetization efficiency and instead > talk about error resiliency. > > (see also a comment below) > > Micke > From rem-conf Wed Oct 18 00:08:32 2000 From rem-conf-request@es.net Wed Oct 18 00:08:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lnFE-0000vs-00; Wed, 18 Oct 2000 00:02:36 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lnFC-0000vG-00; Wed, 18 Oct 2000 00:02:34 -0700 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e9I72Rt16672 for ; Wed, 18 Oct 2000 09:02:28 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Oct 18 08:55:46 2000 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4Y4FCGA6>; Wed, 18 Oct 2000 09:00:53 +0200 Message-ID: From: "Gert Olsson (ECS)" To: "'rem-conf@es.net'" Subject: RE: RTCP BYE Date: Wed, 18 Oct 2000 09:02:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list .. and an RTCP BYE is also required when an SSRC identifier collision has been detected. __________________________________________________________________| Gert Olsson Ericsson Mobile Communications AB, SE-221 83 Lund, Sweden -----Original Message----- From: Mozumder, Monir [mailto:m_mozumder@trillium.com] Sent: den 17 oktober 2000 19:11 To: 'Bratakos, Maroula'; 'rem-conf@es.net' Subject: RE: RTCP BYE Hi Maroula, I think (correct me if wrong) the answer lies in layering principles. SIP sits in upper layer which uses the service of RTP. When SIP sends terminating commands, it will direct RTP to send RTCP BYE, which will ultimately indicate the other SIP side RTP(s) to notify their respective user-SIPs as termination indications. Thanks, -Monir Trillium Digital Systems -an Intel Company. -----Original Message----- From: Bratakos, Maroula [mailto:mbratakos@nuera.com] Sent: Tuesday, October 17, 2000 9:38 AM To: 'rem-conf@es.net' Subject: RTCP BYE What is the role of the RTCP BYE when a control protocol, such as SIP, is being used to create and terminate sessions? Thanks in advance. Maroula Bratakos From rem-conf Wed Oct 18 00:23:19 2000 From rem-conf-request@es.net Wed Oct 18 00:23:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lnX2-00027c-00; Wed, 18 Oct 2000 00:21:00 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lnX1-00027Q-00; Wed, 18 Oct 2000 00:20:59 -0700 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA23342; Wed, 18 Oct 2000 03:23:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2XR87>; Wed, 18 Oct 2000 03:17:06 -0400 Message-ID: From: Jonathan Rosenberg To: "Bratakos, Maroula" , "'rem-conf@es.net'" Subject: RE: RTCP BYE Date: Wed, 18 Oct 2000 03:17:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RTCP BYE is better in loosely coupled sessions, typically large multicast ones, where there isn't even a SIP relationship between all the participants. RTCP BYE scales up very well to groups with thousands or millions of members, whereas SIP BYE would not. SIP BYE is, not surprisingly, better for tightly coupled sessions. It is reliable (RTCP BYE is not), faster (RTCP intervals are several seconds), can be authenticated, and can be seen by proxies and other sip devices on the session establishment path that need to see them. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Bratakos, Maroula [mailto:mbratakos@nuera.com] > Sent: Tuesday, October 17, 2000 12:38 PM > To: 'rem-conf@es.net' > Subject: RTCP BYE > > > What is the role of the RTCP BYE when a control protocol, > such as SIP, is > being used to create and terminate sessions? > > Thanks in advance. > Maroula Bratakos > From rem-conf Wed Oct 18 07:23:36 2000 From rem-conf-request@es.net Wed Oct 18 07:23:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ltuQ-0000Fa-00; Wed, 18 Oct 2000 07:09:34 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ltuO-0000ES-00; Wed, 18 Oct 2000 07:09:32 -0700 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G2M009GQPSHYV@ss3000e.cselt.it> for rem-conf@es.net; Wed, 18 Oct 2000 16:05:06 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <47JRM46Y>; Wed, 18 Oct 2000 16:08:45 +0200 Content-return: allowed Date: Wed, 18 Oct 2000 16:06:07 +0200 From: Franceschini Guido Subject: RE: 4onIP AHG meeting on Saturday To: 'Young-Kwon LIM' , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Message-id: <85077463E51D6A498C453073E167794039BDBA@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I will be there on Sunday, not on Saturday. Thus, I support changing the meeting date. Guido -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Tuesday, October 17, 2000 12:24 PM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: 4onIP AHG meeting on Saturday Dear all, I found out that there are many AHG members relatively active so far have problem to join Saturday AHG meeting. So, I'm considering to postpone it to Sunday. Please let me know if there are any people having problem to join the meeting if we have a meeting only on Sunday instead of Saturday. If I didn't get enough support from members I can not change anything. Please show your hands. Sincerely, Young. From rem-conf Wed Oct 18 11:00:01 2000 From rem-conf-request@es.net Wed Oct 18 11:00:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13lxNz-0006rr-00; Wed, 18 Oct 2000 10:52:19 -0700 Received: from (cpa.com.cn) [202.106.68.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 13lxNT-0006qi-00; Wed, 18 Oct 2000 10:52:16 -0700 Received: from cx14231-d by cpa.com.cn (8.9.3+Sun/SMI-SVR4) id UAA12352; Wed, 18 Oct 2000 20:00:17 +0800 (CST) Date: Wed, 18 Oct 2000 20:00:17 +0800 (CST) From: mike2112@arabia.com Message-Id: <200010181200.UAA12352@cpa.com.cn> To: Subject: ADV: Search Engine Registration MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Removal instructions below I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377 From rem-conf Wed Oct 18 15:38:32 2000 From rem-conf-request@es.net Wed Oct 18 15:38:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13m1ly-0006wQ-00; Wed, 18 Oct 2000 15:33:22 -0700 Received: from speechbot.crl.dec.com [192.58.206.75] by mail1.es.net with esmtp (Exim 1.81 #2) id 13m1lx-0006wG-00; Wed, 18 Oct 2000 15:33:22 -0700 Received: by speechbot.crl.dec.com id SAA0000011393; Wed, 18 Oct 2000 18:33:23 -0400 (EDT) Date: Wed, 18 Oct 2000 18:33:23 -0400 (EDT) From: Message-Id: <200010182233.SAA0000011393@speechbot.crl.dec.com> To: frank65_8@norcol.ac.uk Subject: Hi, this is for you..... MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend: Do you need a change in your life? Do you remember when the entire world seemed like it was yours for the taking? Do you remember a time when all of your hopes and dreams seemed like they were attainable? First of all, let's be honest. You are not going to earn $50,000 in 20 days. It just isn't going to happen. Anyone who tells you that you can, is not being truthful. But, let me tell you about a plan that can possibly make all your dreams come true...keep reading! ******************************************************************** I would like to tell you about a plan that has changed my life. Take a calculator and figure in the worst possible scenario. Decide for yourself. If you decide that you want to take control of your life and move forward...that is your decision. ******************************************************************** Here's the step by step plan summary. 1)You order the 4 reports listed below ($5 each). They come to you by email. 2)Save a copy of this entire letter and put your name at report #1. Move all other names down. (You will be removing the person at the level 4) 3)Use any of the hundreds of bulk email services out there. 4)Orders will come right to your door. Simply email them the report they ordered.Isn't that about as easy as it gets??? ******************************************************************** Your cost to participate in this program is practically nothing (surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! The primary method of building your downline is bulk email. Let's say that you decide to start small, just to see how it goes. Let's assume that you and all those involved email out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out more than 2,000 programs. With a 0.5% response, that is only 10 orders for Report #1. Those 10 respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order 20,000. The 0.5% response rate to that is 1,000 orders for Report #3. Those 1,000 send out 2,000 each for a total of 2,000,000. The 0.5% response rate is 10,000 orders for report #4. That is 10,000 $5 bills for you. CASH!!! ********************************************************************* Your total income in this example is: $50+ $500+ $5000+ $50,000 for a total of $55,550!!! ********************************************************************* REMEMBER FRIEND. THIS IS ASSUMING 1,990 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 EVEN HALF MAILED OUT 100,000 INSTEAD OF 2,000. Believe, most people will do just that, and more!!! Friend, you do the math. You look at the opportunity, if you decide that you would like to participate in this program, the decision is yours. Recently, the Federal Trade Commission has tried to stop chain letters which promise you will make tons of money by participating. Such chain letters are NOT legal because of this reason. This new program complies with all the rules. To be legal, a chain letter must offer a product and must not promise you will get rich by taking part. If you look at the program, do the math and decide that you will make money, it is your opinion. No such claim is here. However, I do strongly encourage you to do the calculations. Figure out the worst possible response and see how it calculates. Your orders come right to your door and you send your reports via email. You are not involved in personal selling. You do it privately in your own home, store, or office. This is the EASIEST plan anywhere. It is simply order filling by email. Order the four 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 EMAIL ADDRESS, and YOUR NAME AND RETURN ADDRESS (in case there's a problem). MAKE SURE YOUR RETURN ADDRESS IS ON THE ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands while you sleep. Remember that 50,000+ new people are joining the Internet every month. By the way, there are over 50 million email addresses with millions more joining the Internet each year, so we don't worry about "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How often have you received the same pizza flyers on your door. Then, one day you are hungry for pizza and immediately recall the flyer. Same thing with this letter. I received this letter many times- then one day I decided it was time to try it. This program will not require you to come into contact with people or take any telephone calls. Just follow the instructions. There is no guarantee either stated or implied that anyone participating in this program will earn $50,000+. (You must include that statement to make this legal.) ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. ********************************************************************** Get started TODAY!! Notes- ALWAYS SEND $5 CASH (US CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number and name of the report you are ordering, (b) your e-mail address, and (c) your name and postal address. REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: S. STARK P.O. BOX 61009 HOUSTON, TEXAS 77208-1009 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: WAYNE ELLIOTT 11918 SE DIVISION #358 PORTLAND, OR 97266 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: RYAN ROMNEY P.O. BOX 540421 NORTH SALT LAKE, UT 84054-0421 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: RUSSELL OLSEN 5409 YARMOUTH AVE #3 ENCINO, CA 91316 ******************************************************************** This ad is being sent in compliance with Senate Bill 1618, Title 3, section 301, paragraph (a)(2)(C). Further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to this e-mail address with the words "remove" in the subject line. ******************************************************************** From rem-conf Thu Oct 19 14:21:50 2000 From rem-conf-request@es.net Thu Oct 19 14:21:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13mMuL-0002eN-00; Thu, 19 Oct 2000 14:07:25 -0700 Received: from netsys.kaist.ac.kr [143.248.148.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13mMuJ-0002eC-00; Thu, 19 Oct 2000 14:07:24 -0700 Received: from engr.UVic.CA (comm.engr.UVic.CA [142.104.96.5]) by netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id FAA27263 for ; Fri, 20 Oct 2000 05:03:54 +0900 From: agullive@engr.uvic.ca Received: from golay.UVic.CA (golay [142.104.115.120]) by engr.UVic.CA (8.11.1/8.11.1-Engr.UVic.CA-H) with ESMTP id e9JL1LJ13810 for ; Thu, 19 Oct 2000 14:01:21 -0700 (PDT) Received: (from agullive@localhost) by golay.UVic.CA (8.9.3+Sun/8.9.3) id OAA00683 for pv_99@netsys.kaist.ac.kr; Thu, 19 Oct 2000 14:03:18 -0700 (PDT) Date: Thu, 19 Oct 2000 14:03:18 -0700 (PDT) Message-Id: <200010192103.OAA00683@golay.UVic.CA> To: pv_99@netsys.kaist.ac.kr Subject: IEEE PACRIM 2001 CALL FOR PAPERS X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list **************** CALL FOR PAPERS *************** 2001 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM'01) August 26-28, 2001, Victoria, B.C., Canada Sponsored by IEEE Canada (Region 7) & IEEE Victoria Section Co-sponsored by the University of Victoria Established in 1987, Pacific Rim Conference is the premier IEEE biennial event in the Pacific Northwest. It is our pleasure to invite you to participate in this event. The scope of PACRIM'01 encompasses but is not limited to: Mobile and Personal Communications Computer Architecture Coding, Modulation and Spread Spectrum Parallel and Distributed Computing ATM Networks Internet Applications Multimedia Communications Neural Networks and Genetic Algorithms Optoelectronic Systems and Devices Hardware/Software Codesign Broadband Satellite Communications Database and Knowledge-Based Systems DSP Applications in Telecommunication Adaptive Filters and Algorithms Image and Video Processing Wavelets and Filter Banks Digital Filters VLSI Speech and Audio Processing Nonlinear Signals and Systems DEADLINES 1000 word summary: March 1, 2001 Acceptance/Rejection: April 1, 2001 Camera Ready Copy: May 1, 2001 Please submit your summary General enquires on PACRIM'01 (by March 1, 2001) to the can be addressed to either of the Technical Program Chair: General Co-Chairs: Dr. Panajotis Agathoklis Dr. Aaron Gulliver or Dr. Kin Li Dept. of Electrical & Computer Eng. Dept. of Electrical & Computer Eng. University of Victoria University of Victoria P.O. Box 3055, STN CSC P.O. Box 3055, STN CSC Victoria, BC, Canada V8W 3P6 Victoria, BC, Canada V8W 3P6 Fax: +1-250-721-6052 Fax: +1-250-721-6052 Email: pan@ece.uvic.ca Email: agullive@ece.uvic.ca or kinli@ece.uvic.ca Accepted papers will be published by the IEEE in the Conference Proceedings. They will be available for worldwide post conference sales from the IEEE. Further information on the conference may be found on the Website: http://www.citr.ece.uvic.ca/pacrim01/ ------------------------------------------------------------------------ We apologize if you have received this notice more than once. ------------------------------------------------------------------------ From rem-conf Tue Oct 24 03:03:59 2000 From rem-conf-request@es.net Tue Oct 24 03:03:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13o0kA-0007CD-00; Tue, 24 Oct 2000 02:51:42 -0700 Received: from audrey.enst-bretagne.fr [192.108.115.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13o0k8-00078Y-00; Tue, 24 Oct 2000 02:51:41 -0700 Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9O9eXo18691; Tue, 24 Oct 2000 11:40:37 +0200 Received: from pchoukair (pchoukair.enst-bretagne.fr [192.44.75.57]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id LAA28370; Tue, 24 Oct 2000 11:37:48 +0200 (MET DST) From: ddma-announcement@enst-bretagne.fr Message-Id: <3.0.3.32.20001024113123.00a4c980@antares.enst-bretagne.fr> X-Sender: choukair@antares.enst-bretagne.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 24 Oct 2000 11:31:23 +0200 To: ddma-announcement@enst-bretagne.fr Subject: One week left: DDMA workshop CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_972372683==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_972372683==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague, You are invited to submit a paper to the International "Distributed Dynamic Multiservice Architectures" (DDMA) Workshop. This workshop is in conjunction with the 21st International Conference on Distributed Computing Systems (ICDCS2001), one of the major conferences in the Distributed Computing Systems Area. DDMA workshop covers aspects concerning adaptive architectures and service composition and management. The submission deadline is November 1st. Further details are at the web site http://ddma.enst-bretagne.fr/. A text version is also in attachment. The DDMA workshop will be held in Phoenix, Arizona; April 16-19, 2001. The proceedings of the workshop will be published by IEEE CS press. [We apologize if you receive multiple copies of this announcement] --=====================_972372683==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ddma-cfp.txt" Call for Papers International Workshop on Distributed Dynamic Multiservice Architectures http://ddma.enst-bretagne.fr/ in conjunction with ICDCS2001 sponsored by IEEE Computer Society April 16 =96 19, 2001 Phoenix, Arizona, USA The growing need to integrate new services while complying with the= requirements of end=20 users puts strong emphasis on the management and combination of future= services and the QoS=20 they should be able to provide and guarantee. Dynamic Multiservice= Architectures constitute a=20 challenging paradigm for distribution theory and practice due to their= unique requirements in terms=20 of adaptability, behavioural integration, separation of concerns, service= composition and service=20 management. In particular, the deployment of multimedia telecommunication= services is a highly=20 challenging area where those paradigms should apply because advanced= services require that the=20 user's profiles, preferences and context be taken into account. "Distributed= Dynamic=20 Multiservice Architectures" hence add a new dimension to distributed= computing to help the=20 composition and deployment of new services guaranteeing final user's= requirements. The goals of this workshop are to bring together users and researchers to= present their=20 recent work related to diverse aspects of dynamic multiservice= architectures, their fundamental=20 issues, their paradigms and some appropriate approaches and experiments. The= workshop will=20 thus present opportunities for discussing further evolutions and their= expected benefits. Scope of Workshop ----------------- The scope of this workshop encompasses but is not limited to : Evolution of distributed multiservice architectures Separation of aspects and composition of aspects. Methodological approaches for aspect oriented programming. Components as cornerstones for dynamic composition. Composition requirements for reflection. Auto-adaptive ad hoc architectures and protocols. Impact on the management and control Management of adaptive architectures Management and monitoring of composed services. Platforms, tools, languages, ...=20 Languages, tools and platforms for auto-adaptive systems. Environments for specification and design of dynamic architectures. Experience with design, implementation and use of auto-adaptive systems. Application to telecommunication services Open critical issues in terms of composition of services. Panorama of QoS integration approaches for multimedia telecom services. Paradigms and requirements for telecom services architectures. Architectures for 3rd generation multimedia services. Distribution protocols for telecom (WAP, CORBA, CAMEL, mobile agents). Submission Instructions and Workshop Format ------------------------------------------- Interested participants should submit a 4-8 pages position paper that= focuses on one of the=20 relevant topics or related issues. Papers will be reviewed by the program= committee. Electronic=20 submissions should be sent to zied.choukair@enst-bretagne.fr. Mail body= should include name,=20 address, affiliation and a brief biography along with paper's title and= abstract. The workshop will follow the following format: The morning and part of the= afternoon will=20 be dedicated to presentations and discussions of accepted proposals,= including demonstrations of=20 existing software. The afternoon session will end with an identification of= issues, followed by=20 discussion. The organisers will then elaborate a summary of the workshop= based upon a summary=20 of the papers and the major outlined points of the discussion. Program Committee Members : Mehmet Aksit, Twente University, NL Zi=E8d Choukair, ENST Bretagne, FR Jaime Delgado, Universitat Pompeu Fabra, ES Byung-Guk Kim, University of Massachusetts Lowell, USA Marwan Krunz, University of Arizona, USA Abdul H. Sadka, University of Surrey, GB Antonio Rito Silva, University of Lisbon, PT Timothy K. Shih, Tamkang University, TW Katsuya Tanaka, Tokyo Denki University, JP Important Dates : Paper submission due : Nov 1, 2000 Notification : Dec 30, 2000 Camera ready : Jan 20, 2001 Conference : April 16-19, 2001 Web Pages : Conference URL : http://cactus.eas.asu.edu/ICDCS2001/ --=====================_972372683==_-- From rem-conf Tue Oct 24 11:49:59 2000 From rem-conf-request@es.net Tue Oct 24 11:49:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13o94F-0005pq-00; Tue, 24 Oct 2000 11:44:59 -0700 Received: from ece.wpi.edu [130.215.16.20] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13o94E-0005pg-00; Tue, 24 Oct 2000 11:44:58 -0700 Received: from abhijit (abhijit.WPI.EDU [130.215.17.99]) by ece.WPI.EDU (8.9.3/8.6) with SMTP id OAA26694; Tue, 24 Oct 2000 14:44:50 -0400 (EDT) Message-ID: <004701c03deb$289cafa0$6dfda8c0@wpi.edu> From: "Abhijit Pandey" To: "Gert Olsson \(ECS\)" , References: Subject: Adaptive Buffer info needed Date: Tue, 24 Oct 2000 14:49:37 -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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could anybody let me know where I could information about adaptive jitter buffer? How to implement it and its effects on voice quality. Thanks, Abhijit Pandey From rem-conf Tue Oct 24 12:13:11 2000 From rem-conf-request@es.net Tue Oct 24 12:13:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13o9U8-0006v0-00; Tue, 24 Oct 2000 12:11:44 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13o9U7-0006uq-00; Tue, 24 Oct 2000 12:11:43 -0700 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA17581; Tue, 24 Oct 2000 15:13:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <4WS2X6S8>; Tue, 24 Oct 2000 15:07:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Abhijit Pandey'" , "Gert Olsson (ECS)" , rem-conf@es.net Subject: RE: Adaptive Buffer info needed Date: Tue, 24 Oct 2000 15:07:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here are pointers to a few papers: Jonathan Rosenberg, Lili Qiu and Henning Schulzrinne, "Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000. Abstract: Transport of real time voice traffic on the Internet is difficult for two reasons - network loss and network jitter. There has been substantial research in developing protocols and algorithms to combat these problems. Network loss is handled primarily through a variety of different forward error correction (FEC) algorithms and local repair operations at the receiver. Jitter has been compensated for by means of adaptive playout buffer algorithms at the receiver. Traditionally, these two mechanisms have been investigated in isolation. In this paper, we show the interactions between adaptive playout buffer algorithms and FEC, and demonstrate the need for coupling. We propose a number of novel playout buffer algorithms which provide this coupling, and demonstrate their effectiveness through simulations based on both network models and real network traces. Sue B. Moon, Jim Kurose and Don Towsley, "Packet audio playout delay adjustment algorithms: performance bounds and algorithms," Department of Computer Science, University of Massachusetts at Amherst, Amherst, Massachusetts, Aug. 1995. Abstract: In packet audio applications, packets are buffered at a receiving site and their playout delayed in order to compensate for variable network delays. In this paper, we consider the problem of adaptively adjusting the playout delay in order to keep this delay as small as possible, while at the same time not incurring too many ``losses'' due to the arrival of packets at the receiver after their playout time has already passed. The contributions of this paper are twofold. First, given a trace of packet audio receptions at a receiver, we present efficient algorithms for computing upper and lower bounds on the optimum (minimum) average playout delay for a given number of packet losses (due to late arrivals) at the receiver for that trace. These bounds, which we show to be tight for the range of loss and delay values of interest, are of particular importance as they provide a bound on the achievable performance of any playout delay adjustment algorithm. Second, we present a new adaptive delay adjustment algorithm that tracks the network delay of recently received packets and efficiently maintains delay percentile information. This information, together with a ``delay spike'' detection algorithm based on (but extending) our earlier work is used to dynamically adjust talkspurt playout delay. We show that this algorithm outperforms existing delay adjustment algorithms over a number of measured audio delay traces and performs close to the theoretical optimum over a range of parameter values of interest. Keywords: packet audio; playout delay; multimedia; packet loss; dynamic programming; computer networks Ramachandran Ramjee, Jim Kurose, Don Towsley and Henning Schulzrinne, "Adaptive playout mechanisms for packetized audio applications in wide-area networks," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Toronto, Canada), pp. 680-688, Jun. 1994. Abstract: Recent interest in supporting packet-audio applications over wide area networks has been fueled by the availability of low-cost, toll-quality workstation audio and the demonstration that limited amounts of interactive audio can be supported by today's Internet. In such applications, received audio packets are buffered, and their playout delayed, at the destination host in order to compensate for the variable network delays. In this paper we investigate the performance of four different algorithms for adaptively adjusting the playout delay of audio packets in an interactive packet-audio terminal application, in the face of such varying network delays. We evaluate the playout algorithms using experimentally-obtained delay measurements of audio traffic between several different Internet sites. Our results indicate that an adaptive algorithm which explicitly adjusts to the sharp, spike-like increases in packet delay which we observed in our traces can achieve a lower rate of lost packets for both a given average playout delay and a given maximum buffer size. Keywords: packet voice; packet audio; delay adaptation; internet; IP; UDP; estimation --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Abhijit Pandey [mailto:abhijit@ece.WPI.EDU] > Sent: Tuesday, October 24, 2000 2:50 PM > To: Gert Olsson (ECS); rem-conf@es.net > Subject: Adaptive Buffer info needed > > > Could anybody let me know where I could information about > adaptive jitter > buffer? > How to implement it and its effects on voice quality. > Thanks, > Abhijit Pandey > > From rem-conf Tue Oct 24 12:13:11 2000 From rem-conf-request@es.net Tue Oct 24 12:13:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13o9Uk-0006vy-00; Tue, 24 Oct 2000 12:12:22 -0700 Received: from neko.cts.com [209.68.192.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 13o9Uf-0006ve-00; Tue, 24 Oct 2000 12:12:21 -0700 Received: from viao.tbt.com ([198.68.174.132]) by neko.cts.com (8.9.3/8.9.3) with ESMTP id MAA15586 for ; Tue, 24 Oct 2000 12:11:58 -0700 (PDT) Message-Id: <5.0.0.25.2.20001024120410.053587d0@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 24 Oct 2000 12:07:21 -0700 To: rem-conf@es.net From: "Michael A. Dolan" Subject: SMPTE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FYI, I called a couple of ID's to the attention of a relevant working group in SMPTE. I think it would be valuable to establish some form of communication between this WG and SMPTE as things continue to merge. Specifically, I called their attention to the following drafts: > http://search.ietf.org/internet-drafts/draft-gharai-hdtv-video-00.txt > > >http://search.ietf.org/internet-drafts/draft-ietf-avt-smpte292-video-00.txt > > http://search.ietf.org/internet-drafts/draft-ietf-avt-dv-video-03.txt FYI, Mike ------------------------------------------------------ Michael A. Dolan, Representing DIRECTV, (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 From rem-conf Tue Oct 24 12:39:04 2000 From rem-conf-request@es.net Tue Oct 24 12:39:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13o9th-0000ui-00; Tue, 24 Oct 2000 12:38:09 -0700 Received: from lennier.cc.vt.edu [198.82.161.193] by mail1.es.net with esmtp (Exim 1.81 #2) id 13o9tg-0000uV-00; Tue, 24 Oct 2000 12:38:08 -0700 Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190]) by lennier.cc.vt.edu (8.11.0/8.11.0) with ESMTP id e9OJc2t400953; Tue, 24 Oct 2000 15:38:03 -0400 (EDT) Received: from [128.173.12.30] by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0G2Y0087L97CYR@gkar.cc.vt.edu>; Tue, 24 Oct 2000 15:38:01 -0400 (EDT) Date: Tue, 24 Oct 2000 15:43:43 -0400 From: blue@vt.edu (leslie michelle lipscomb) Subject: Re: Adaptive Buffer info needed X-Sender: blue@mail.vt.edu To: Abhijit Pandey Cc: rem-conf@es.net Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I was just testing h.323 with two vendor's systems and experienced video= jitter from one, and was informed by the technical rep that some systems= include packet buffering as a feature and some do not handle it at all --= appearantly it may be a proprietary addition and not standards-based. ------ >Could anybody let me know where I could information about adaptive jitter >buffer? >How to implement it and its effects on voice quality. >Thanks, >Abhijit Pandey -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Interoperability Lab - ISB208 Communications Network Services Andrews Information Systems Building 1700 Pratt Drive, CRC, Blacksburg, VA 24061-0506 phone : 540/231/2361 email : interop-lab@vt.edu -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D- From rem-conf Tue Oct 24 13:06:28 2000 From rem-conf-request@es.net Tue Oct 24 13:06:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oAJL-0001yB-00; Tue, 24 Oct 2000 13:04:39 -0700 Received: from nmh.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oAJJ-0001y1-00; Tue, 24 Oct 2000 13:04:37 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.149.220]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e9OK4Vt10764; Tue, 24 Oct 2000 22:04:31 +0200 (MEST) From: "Dr. Carsten Bormann" To: "leslie michelle lipscomb" , "Abhijit Pandey" Cc: Subject: RE: Adaptive Buffer info needed Date: Tue, 24 Oct 2000 22:04:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I was just testing h.323 with two vendor's systems and > experienced video jitter from one, and was informed by the > technical rep that some systems include packet buffering as a > feature and some do not handle it at all -- appearantly it may be > a proprietary addition and not standards-based. Of course, whether you play the video stream correctly, distort or discard it, or replace it by images of hopping monkeys is a "quality of implementation issue". On the other hand, RFC1889 would certainly not go to the length of creating all that mechanism if there wasn't an expectation that a receiver is going to use the information... You need to tell that technical rep that playing the video correctly is certainly more standards-based and less proprietary than showing hopping monkeys. Oh, and name that vendor, please. I would like to take this opportunity to open a round of vendor bashing on negligent RTP implementations. Apart from simply not implementing RTP playout (see above), many implementations seem to skip sending RTCP or implement it in non-conforming ways. This hurts interoperability surprisingly little because very few implementers care about what they receive in RTCP. I know that some streaming applications at least use the RTCP receiver reports to find out whether the recipient is still there and listening. Any other positive news on this front? While vendor bashing may not be on the charter of this list, it does help creating interoperability if you know how a standard is being used. Gruesse, Carsten From rem-conf Tue Oct 24 13:24:50 2000 From rem-conf-request@es.net Tue Oct 24 13:24:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oAbp-0002uv-00; Tue, 24 Oct 2000 13:23:45 -0700 Received: from hafez.east.isi.edu [38.218.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oAbn-0002ul-00; Tue, 24 Oct 2000 13:23:44 -0700 Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id e9OKNcQ27581; Tue, 24 Oct 2000 16:23:38 -0400 Message-Id: <200010242023.e9OKNcQ27581@hafez.east.isi.edu> To: "Dr. Carsten Bormann" cc: leslie michelle lipscomb , Abhijit Pandey , rem-conf Subject: Re: Adaptive Buffer info needed In-Reply-To: Your message of "Tue, 24 Oct 2000 22:04:30 +0200." Date: Tue, 24 Oct 2000 16:23:38 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "Dr. Carsten Bormann" writes: >> I was just testing h.323 with two vendor's systems and >> experienced video jitter from one, and was informed by the >> technical rep that some systems include packet buffering as a >> feature and some do not handle it at all -- appearantly it may be >> a proprietary addition and not standards-based. > >Of course, whether you play the video stream correctly, distort or discard >it, or replace it by images of hopping monkeys is a "quality of >implementation issue". >On the other hand, RFC1889 would certainly not go to the length of creating >all that mechanism if there wasn't an expectation that a receiver is going >to use the information... >You need to tell that technical rep that playing the video correctly is >certainly more standards-based and less proprietary than showing hopping >monkeys. > >Oh, and name that vendor, please. > >I would like to take this opportunity to open a round of vendor bashing on >negligent RTP implementations. > >Apart from simply not implementing RTP playout (see above), many >implementations seem to skip sending RTCP or implement it in non-conforming >ways. This hurts interoperability surprisingly little because very few >implementers care about what they receive in RTCP. I know that some >streaming applications at least use the RTCP receiver reports to find out >whether the recipient is still there and listening. Any other positive >news on this front? They certainly need to implement RTCP if they want lip-sync, and a number of products do that. There are also implementations which refuse to play-out the media until they receive a correct RTCP packet from a source. As the author of one of those, I find it sad that we get complaints after every SIP bakeoff, due to lack of interoperability with the implementations which just don't implement RTCP. And, of course, implementations which don't care about sending RTP on even numbered UDP ports are kind-of annoying... >While vendor bashing may not be on the charter of this list, it does help >creating interoperability if you know how a standard is being used. Cheers, Colin From rem-conf Tue Oct 24 13:31:44 2000 From rem-conf-request@es.net Tue Oct 24 13:31:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oAjB-0003ge-00; Tue, 24 Oct 2000 13:31:21 -0700 Received: from mailgate.pit.comms.marconi.com [169.144.68.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oAjA-0003Zg-00; Tue, 24 Oct 2000 13:31:20 -0700 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21829; Tue, 24 Oct 2000 16:30:16 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08802; Tue, 24 Oct 2000 16:30:02 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVKMLT>; Tue, 24 Oct 2000 16:29:56 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Colin Perkins'" , "Dr. Carsten Bormann" Cc: leslie michelle lipscomb , Abhijit Pandey , rem-conf Subject: RE: Adaptive Buffer info needed Date: Tue, 24 Oct 2000 16:30:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Care to name one or more implementations you find exemplary in this regard to use as an interwork reference? Brian > -----Original Message----- > From: Colin Perkins [mailto:csp@east.isi.edu] > Sent: Tuesday, October 24, 2000 4:24 PM > To: Dr. Carsten Bormann > Cc: leslie michelle lipscomb; Abhijit Pandey; rem-conf > Subject: Re: Adaptive Buffer info needed > > > --> "Dr. Carsten Bormann" writes: > >> I was just testing h.323 with two vendor's systems and > >> experienced video jitter from one, and was informed by the > >> technical rep that some systems include packet buffering as a > >> feature and some do not handle it at all -- appearantly it may be > >> a proprietary addition and not standards-based. > > > >Of course, whether you play the video stream correctly, > distort or discard > >it, or replace it by images of hopping monkeys is a "quality of > >implementation issue". > >On the other hand, RFC1889 would certainly not go to the > length of creating > >all that mechanism if there wasn't an expectation that a > receiver is going > >to use the information... > >You need to tell that technical rep that playing the video > correctly is > >certainly more standards-based and less proprietary than > showing hopping > >monkeys. > > > >Oh, and name that vendor, please. > > > >I would like to take this opportunity to open a round of > vendor bashing on > >negligent RTP implementations. > > > >Apart from simply not implementing RTP playout (see above), many > >implementations seem to skip sending RTCP or implement it in > non-conforming > >ways. This hurts interoperability surprisingly little > because very few > >implementers care about what they receive in RTCP. I know that some > >streaming applications at least use the RTCP receiver > reports to find out > >whether the recipient is still there and listening. Any > other positive > >news on this front? > > They certainly need to implement RTCP if they want lip-sync, > and a number > of products do that. > > There are also implementations which refuse to play-out the > media until > they receive a correct RTCP packet from a source. As the > author of one of > those, I find it sad that we get complaints after every SIP > bakeoff, due to > lack of interoperability with the implementations which just > don't implement > RTCP. > > And, of course, implementations which don't care about > sending RTP on even > numbered UDP ports are kind-of annoying... > > >While vendor bashing may not be on the charter of this list, > it does help > >creating interoperability if you know how a standard is being used. > > Cheers, > Colin > From rem-conf Tue Oct 24 14:01:53 2000 From rem-conf-request@es.net Tue Oct 24 14:01:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oBBg-0004i6-00; Tue, 24 Oct 2000 14:00:48 -0700 Received: from hafez.east.isi.edu [38.218.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oBBf-0004hw-00; Tue, 24 Oct 2000 14:00:47 -0700 Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id e9OL0bV01055; Tue, 24 Oct 2000 17:00:37 -0400 Message-Id: <200010242100.e9OL0bV01055@hafez.east.isi.edu> To: "Rosen, Brian" cc: "Dr. Carsten Bormann" , leslie michelle lipscomb , Abhijit Pandey , rem-conf Subject: Re: Adaptive Buffer info needed In-Reply-To: Your message of "Tue, 24 Oct 2000 16:30:00 EDT." <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 24 Oct 2000 17:00:37 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "Rosen, Brian" writes: >Care to name one or more implementations you find exemplary in this >regard to use as an interwork reference? The mbone tools (rat, vat, vic) include pretty reasonable open-source implementations of RTP. I'm not sure it's appropriate for me to name commercial implementations I like/dislike, but if someone who isn't a working group chair wishes to do so....... I'd also like to draw attention to draft-ietf-avt-rtptest-03.txt and solicit comments on that draft (which we hope to make an informational RFC eventually). Colin [with the disclaimer that I wrote the RTP stack in rat] From rem-conf Tue Oct 24 16:00:54 2000 From rem-conf-request@es.net Tue Oct 24 16:00:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oD1W-0006dP-00; Tue, 24 Oct 2000 15:58:26 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oD1U-0006dF-00; Tue, 24 Oct 2000 15:58:24 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA02384 for ; Tue, 24 Oct 2000 15:58:22 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 24 Oct 2000 15:58:22 -0700 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id PAA21001; Tue, 24 Oct 2000 15:58:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi .com> References: <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi .com> Date: Tue, 24 Oct 2000 16:01:27 -0700 To: "Rosen, Brian" From: Kevin Marks Subject: RE: Adaptive Buffer info needed Cc: rem-conf Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 4:30 PM -0400 10/24/00, Rosen, Brian wrote: >Care to name one or more implementations you find exemplary in this >regard to use as an interwork reference? If you are doing interoperability tests on RTP implementations, do take a look at the current Public Previews of QuickTime 5 Client and QuickTime Streaming Server 3.0 http://www.apple.com/quicktime/preview/ From rem-conf Tue Oct 24 16:32:36 2000 From rem-conf-request@es.net Tue Oct 24 16:32:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oDXn-0007eK-00; Tue, 24 Oct 2000 16:31:47 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oDXl-0007eA-00; Tue, 24 Oct 2000 16:31:45 -0700 Received: from colleen.dev.prognet.com ([172.23.100.21]) by prognet.com (8.9.2/8.9.0) with SMTP id QAA22658; Tue, 24 Oct 2000 16:31:55 -0700 (PDT) Message-Id: <3.0.5.32.20001024163811.008bdba0@mail.prognet.com> X-Sender: colleeng@mail.prognet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Oct 2000 16:38:11 -0700 To: Kevin Marks , "Rosen, Brian" From: =?iso-8859-1?Q?=22Colleen_Moffitt_=28ne=E9_Gehrt=29=22?= Subject: RE: Adaptive Buffer info needed Cc: rem-conf In-Reply-To: References: < <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi .com> <4FBEA8857476D311A03300204840E1CF01A6E8B2@whq-msgusr-02.pit.comms.marconi .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list For your RTP interop tests the latest preview version of the RealServer can be found at: http://www.realnetworks.com/products/servers/server8.html?src=noref,rnhmpg_1 02300,rnhmsi,srvrmn_081800 At 04:01 PM 10/24/00 -0700, Kevin Marks wrote: >At 4:30 PM -0400 10/24/00, Rosen, Brian wrote: >>Care to name one or more implementations you find exemplary in this >>regard to use as an interwork reference? > >If you are doing interoperability tests on RTP implementations, do >take a look at the current Public Previews of QuickTime 5 Client and >QuickTime Streaming Server 3.0 > >http://www.apple.com/quicktime/preview/ > > From rem-conf Tue Oct 24 22:29:42 2000 From rem-conf-request@es.net Tue Oct 24 22:29:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oJ4v-0002vI-00; Tue, 24 Oct 2000 22:26:21 -0700 Received: from (baosoft.com) [202.101.38.219] by mail1.es.net with smtp (Exim 1.81 #2) id 13oJ4u-0002v8-00; Tue, 24 Oct 2000 22:26:20 -0700 Received: from _[227.51.139.97]_by by baosoft.com (SMI-8.6/SMI-SVR4) id NAA24912; Wed, 25 Oct 2000 13:25:38 +0800 From: Ted@money.com Message-Id: <200010250525.NAA24912@baosoft.com> Received: from [36.242.90.237] by _[227.51.139.97]_by with SMTP id A119C10E6 Wed, 25 Oct 2000 01:06:21 PDT To: rem-conf@es.net Subject: Search Engine Optimization Kit -2000 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Wed, 25 Oct 2000 01:23:38 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

Learn how to achieve Top 10 positions in search engines.

No hype ... no gimmicks ... just the facts ... and only $59!

Hello Friend,

My name is Jerry Perrich and I created the The Search Engine Optimization Kit-2000 to help you achieve high positions in search engines. This unique Kit includes:
  • Detailed information on how to obtain high positions in search engines,

  • Step-by-step instructions on techniques to use to make your web pages very "search-engine-friendly",

  • Special tools and resources to create your pages and monitor their positions in search engines, and

  • Ongoing support by email and phone.

Click here to receive Free Information about Search Engines and the Kit, or call direct to 937.885.7732 (US). We will send it to you promptly by email.

Thank you for your time and best wishes in your endeavors.

Dr. Jerry R. Perrich, Director
The Internet Marketing Institute, Inc.
Helping You Be Successful Online
937.885.7732


PS - Please consider forwarding this email to any business associates or friends who may benefit from it.

REMOVAL INSTRUCTIONS
Per federal legislation, you can be removed from this mailing list at no cost to you by simply clicking here Remove Please. You will be promptly removed. Please note that interfering with this federally approved method of removal will deny others the opportunity to be removed.
From rem-conf Wed Oct 25 06:12:26 2000 From rem-conf-request@es.net Wed Oct 25 06:12:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oQCa-0007Hf-00; Wed, 25 Oct 2000 06:02:44 -0700 Received: from mail.curia.eu.int (curia.eu.int) [158.169.105.53] by mail1.es.net with smtp (Exim 1.81 #2) id 13oQCY-0007HT-00; Wed, 25 Oct 2000 06:02:42 -0700 Received: from CJE-Message_Server by curia.eu.int with Novell_GroupWise; Wed, 25 Oct 2000 15:00:27 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Wed, 25 Oct 2000 15:00:23 +0100 From: "Zacharias Bilalis" To: Subject: Could you please inicate me how I can become a member of your list? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could you please inicate me how I can become a member of your list? Thank you in advance Cordialement / Best Regards Zacharias Bilalis Division Informatique Cour de Justice des CE Tel: +352 4303 3106 Fax: +352 4303 3200 From rem-conf Wed Oct 25 12:18:25 2000 From rem-conf-request@es.net Wed Oct 25 12:18:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oVzY-0003IX-00; Wed, 25 Oct 2000 12:13:40 -0700 Received: from chi6-1.relay.mail.uu.net [199.171.54.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oVzX-0003IN-00; Wed, 25 Oct 2000 12:13:39 -0700 Received: from 21rst-century.com by chi6sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjmlw15627; Wed, 25 Oct 2000 19:13:34 GMT Message-ID: <39F73055.31737D6F@21rst-century.com> Date: Wed, 25 Oct 2000 15:11:16 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: rem-conf@es.net, ipng@sunroof.eng.sun.com Subject: Multicast RTP in IPv6 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello; I hesitate to send to two lists at once, but both seem relevant. My apologies for duplicates. Does anyone know what the status of RTP/RTCP is in IPv6? I know that v6 is "born multicast enabled", but what is going to be required to actually use it with streaming audio / video ? This is going to be a major application with 3G wireless devices using IPv6, and we would like to start work on v6 compliant software. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Wed Oct 25 13:03:03 2000 From rem-conf-request@es.net Wed Oct 25 13:03:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oWhI-0004TQ-00; Wed, 25 Oct 2000 12:58:52 -0700 Received: from hafez.east.isi.edu [38.218.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13oWhH-0004TG-00; Wed, 25 Oct 2000 12:58:51 -0700 Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id e9PJwf604773; Wed, 25 Oct 2000 15:58:41 -0400 Message-Id: <200010251958.e9PJwf604773@hafez.east.isi.edu> To: tme@21rst-century.com cc: rem-conf@es.net, ipng@sunroof.eng.sun.com Subject: Re: Multicast RTP in IPv6 In-Reply-To: Your message of "Wed, 25 Oct 2000 15:11:16 EDT." <39F73055.31737D6F@21rst-century.com> Date: Wed, 25 Oct 2000 15:58:41 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Marshall Eubanks writes: >Does anyone know what the status of RTP/RTCP is in IPv6? I know that >v6 is "born multicast enabled", but what is going to be required to >actually use it with streaming audio / video ? This is going to be a major >application with 3G wireless devices using IPv6, and we would like to start work on v6 >compliant software. No changes are required to RTP/RTCP to support IPv6, and there are a number of applications which support it already. See http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/ for one open source implementation, there are others. Colin From rem-conf Thu Oct 26 02:00:42 2000 From rem-conf-request@es.net Thu Oct 26 02:00:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13oiq5-0002Ej-00; Thu, 26 Oct 2000 01:56:45 -0700 Received: from faithfunds.com (server1.faithfunds.com) [209.61.157.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13oiq4-0002EO-00; Thu, 26 Oct 2000 01:56:44 -0700 Received: (from nobody@localhost) by server1.faithfunds.com (8.9.3/8.9.3) id DAA16775; Thu, 26 Oct 2000 03:56:58 -0500 Date: Thu, 26 Oct 2000 03:56:58 -0500 Message-Id: <200010260856.DAA16775@server1.faithfunds.com> To: rem-conf@es.net From: jordan@controlmultimedia.com Subject: FAITHFUNDS....A Place to Give, A Place to Share, A Place to Call Home X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FAITHFUNDS....A Place to Give, A Place to Share, A Place to Call Home Would you like to know how to reach over 765 millions viewersFaithfunds is designed to assist Christians in locating products and services in their community and nationwide. We also provide a Shop-to-Donate section so that local Chapters can benefit from having their Congregation shop online. How does this help you? You will find that Faithfunds is the premier place to get up-to-date news, weather and sports, shop for Christian products, browse through Church directories nationwide and send Children's E-Cards during those special occasions. Faithfunds is the premier place to sell your Christian products on the web. Your site can be listed in this directory for premium placement so that you can sell your books, jewelry and accessories. Our demographic is geared toward people just like you -- interested in Christian products! And now we've merged with InfoSpace so that our Reach is even greater! Faithfunds REACH Faithfunds Directory powered by InfoSpace and its network of over 3,100 affiliates guarantees the widest reach. Ranked 20th overall among sites on the Web and #1 among directory services, receiving more than 765 million impressions per month with more than 29 million unique visits. ADVERTISING OPTIONS Faithfunds offers advertisers and vendors an ideal medium to cost-effectively target and reach their audience. Whether your primary goal is to drive traffic to your Web site, heighten brand awareness, or generate e-commerce transactions, we will help you reach your goals. YOUR OPTIONS INCLUDE You can start your national advertising campaign and reach over 765 million viewers for as little as $1,200 per year!!! Christian Directory (MONTHLY RATES) I. SILVER PACKAGE: Features: Bold, Enlarged Font, URL link & Email Link Listings: a. City: $5 b. Multi-City: $15 c. State: $25 d. Multi-State: $60 e. National: $100 II. GOLD PACKAGE Features: Bold, Enlarged Font, URL link & Email Link PLUS Ad Link (any graphic) or Page Express Listings: a. City: $15 b. Multi-City: $25 c. State: $100 d. Multi-State: $250 e. National: $500 III. PLATINUM PACKAGE Features: Gold Package PLUS Category Sponsorship Listings: a. City: $25 b. Multi-City: $75 c. State: $250 d. Multi-State: $750 e. National: $2,000 Please note that these are introductory prices for the Faithfunds launch. Please call us now before the Holiday Season begins! May God Bless You, The Faithfunds Family http://www.faithfunds.com From rem-conf Thu Oct 26 09:37:26 2000 From rem-conf-request@es.net Thu Oct 26 09:37:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13opmc-0006Yw-00; Thu, 26 Oct 2000 09:21:38 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13opmb-0006Vh-00; Thu, 26 Oct 2000 09:21:37 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39F5632500033037 for rem-conf@es.net; Thu, 26 Oct 2000 18:19:11 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39F3CF3C00057902 for rem-conf@es.net; Thu, 26 Oct 2000 18:15:30 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Thu, 26 Oct 2000 18:15:30 +0200 (Paris, Madrid (heure d'été)) X-Internal-ID: 39F3DA8A00002CC6 Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Thu, 26 Oct 2000 18:22:12 +0200 Received: from thomcast.thomson-csf.com ([178.3.1.89]) by minos.snmrennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.62) with ESMTP id 101; Thu, 26 Oct 2000 18:05:16 +0200 Message-ID: <39F8678C.E4F749F0@thomcast.thomson-csf.com> Date: Thu, 26 Oct 2000 18:19:08 +0100 From: "Marc Le Naour" X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf CC: Nathalie Cabel Subject: UNICODE RTSP syntax and binary data Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, In RFC 2326 it's defined the RTSP messages are a text-based and RTSP protocol uses the ISO 10646 character set in UTF-8 encoding. Parsing a RTSP message including multiple packets of binary data (binary content, data url, ...) is quite difficult : the parser has to track characters delimitaions or string delimitation for each packets before the next character packets .... This implies an indirect access to the informations in the RTSP messages ... To avoid this problem it would be interesting to enforced a pair length for each binary packet included in a RTSP message with a parity byte .... This solution would allow quick and easy jumping over non-interesting header field ... Marc From rem-conf Thu Oct 26 12:07:43 2000 From rem-conf-request@es.net Thu Oct 26 12:07:43 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13osJA-0006uN-00; Thu, 26 Oct 2000 12:03:24 -0700 Received: from 1cust149.tnt5.phoenix2.az.da.uu.net ([63.16.193.149] helo=Pbedboy.com) by mail2.es.net with smtp (Exim 1.92 #1) id 13osJ5-0006pz-00; Thu, 26 Oct 2000 12:03:20 -0700 To: Targeted-Search-Engine@25centspervisitor.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Date: Thu, 26 Oct 2000 11:15:21 -0700 From: searchenginemechanic@excite.com Message-Id: Subject: FWD: info on Targeted Search Engine Traffic for $0.25 per visitor!!! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Guaranteed Traffic from major Search Engines When using a search engine, if you don ’t find what you ’re looking for in the first 10 to 30 matches what do you do? Well, most people go to the next search engine and try again. If your site is not coming up in the first 10 to 30 matches of a search, then you ’re losing business! IT ’S THAT SIMPLE! Improving search engine traffic means: MORE HITS MORE BUSINESS MORE SUCCESS The most important advertising dollar you spend should be for search engine traffic. WHY? The top three reasons are: 1. Approximately 95% of all Internet users start with a search engine query. 2. Anyone who comes to your site from a major search engine is 100 times more likely to become a customer because they were specifically looking for your product, goods, or services. 3. Search engine traffic gives you substantially more for your advertising dollar than banners. We guarantee traffic generated from the.following.search engines: Yahoo, HotBot, Excite, Alta Vista, Lycos, Infoseek, MSN, Netscape, AOL Search, InfoSeek/Go Network,Direct Hit,Fast/Alltheweb,Goto,Iwon and NBCi. Your initial payment covers setup expenses including: domain name registration, web page construction, Dir. reviews, DNS setup, etc. Plus, you'll get 2,000 unique visits to your web site. You'll have 24 hour access to a our web-based interface allowing you to see all your traffic, what search engine the visitor used to reach you, and even the terms they used to search for you. The cost to start getting targeted traffic to YOUR web site is: $500.00 this equals out to be 2,000 target visitors to YOUR web site, A mere twenty five cents ($0.25) Per unique targeted visitor. The cost per visitor will never go up. After the 2,000 visitors you simply pre-pay for more target visitors. We Look forward to working with you! ------------------------------------------------------------------------------------------------------------- To get the ball rolling fax the following request to 1.208-445-2319 This Form MUST be completely filled out!. Note... Do Not provide any payment information at this time! ------------------------------------------------------------------------------------------------------------- Company: Address: State: City: Zip: Contact Name: Contact Telephone: Contact Fax: Contact E-mail Address: Website Address: A few of your top Keywords: __ Yes, I want to start this service asap, please contact me today! __ Yes, I want to start this service please contact me __Mon__Tue__Wed__Thur__Fri between these hours__________________________________________________! Questions: ------------------------------------------------------------------------------------------------------------------- Remove: searchenginemechanic@excite.com ------------------------------------------------------------------------------------------------------------------- From rem-conf Fri Oct 27 07:58:56 2000 From rem-conf-request@es.net Fri Oct 27 07:58:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13pArm-0002s2-00; Fri, 27 Oct 2000 07:52:22 -0700 Received: from (jk-notes6.jk-computer.de) [194.162.208.60] by mail1.es.net with smtp (Exim 1.81 #2) id 13pArU-0002oX-00; Fri, 27 Oct 2000 07:52:04 -0700 Received: from localhost ([4.48.80.221]) by jk-notes6.jk-computer.de (Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) with SMTP id 41256985.0057C219; Fri, 27 Oct 2000 16:58:35 +0100 Message-ID: <00001587132f$0000428f$00001ff7@localhost> To: From: lexx@cairomail.com Subject: tbeltz@erols.com Date: Wed, 25 Oct 2000 21:11:44 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Outlook Express 4.77.210.1 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

7 DAY SPECIAL
Buy Two Get One Free
LibidoMagic is 100% Herbal, No Prescription Needed
IT IS NOT A DRUG
Stimulate Sexual Energy
No negative side effects! Guarantee to perform, or your money back!
 Increase Your Desire and Performance
Inject Passion, Stamina and Virility into your Sex Life!<= FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR: #fffff= f" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">
LibidoMagic is a 100% natural blend of herbs which causes no= side effects,
it helps to rejuvenate and enhance, the sexual performance of Men a= nd Women.
Increase Your Desire, Experience all Natural Sexual Ecstasy
add Romance and Passion to your life.
Ingredients in LibidoMagic are known to assist prostate health.
FIRM, POWERFUL, LONG LASTING ERECTIONS!
ORDER NOW!
CREDIT CARD ORDERS CALL 954-974-9903
LibidoMagic only $49.99 Per Bottle of Sixty Capsules +$7.00= S/H.
Two bottles for $80.00 Third Free!
To Order By Mail See End of Message.
Women
 LibidoMagic is formulated to enhan= ce your sexual experience naturally.
The active ingredient in LibidoMagic has been known
to be a natural sexual enhancer.
Increase in energy and well being, relief of many PMS
and menopausal symptoms in women,
which is why multiple orgasms will be experienced. It helps
to enhance sexual sensations, Longer more Enjoyable SEX! Order This Fabulous Product Today!
LibidoMagic out performs, and the price beats TV advert= ised competition!
GO AHEAD, ORDER NOW! MONEY BACK GUARANTEE!
CREDIT CARD ORDERS
Call 954-974-9903
 LibidoMagic!
To Fax an Order only the number is 310-358-7317
No Credit Card? No Problem
Make Check or Money Order payable to VNR
and mail to:
VNR
PO BOX 590953
FT. LAUDERDALE
FL. 33359

We do wait until personal checks clear our bank, before mailing your= order
For Fax Orders, please print and fax the following to:
310-358-7317
Name_________________________________________________

Address_______________________________________________

City_______________________State_______Zip______________

Phone#__________________Email Address__________________

CreditCard____________________________MC/ V/ AMEX

Card Number___________________________________________

Expiration Date_______________

I wish to order_____Bottle(s)

Signature____________________________Date___________

To be remove send message to sender with only remove in subject line.<= /FONT>







From rem-conf Sun Oct 29 08:55:30 2000 From rem-conf-request@es.net Sun Oct 29 08:55:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13pvTW-0003IY-00; Sun, 29 Oct 2000 08:38:26 -0800 Received: from (baosoft.com) [202.101.38.219] by mail1.es.net with smtp (Exim 1.81 #2) id 13pvTU-0003I3-00; Sun, 29 Oct 2000 08:38:24 -0800 Received: from _[66.149.149.239]_by by baosoft.com (SMI-8.6/SMI-SVR4) id TAB00284; Mon, 23 Oct 2000 19:43:17 +0800 From: Ads@hunt.com Message-Id: <200010231143.TAB00284@baosoft.com> Received: from [68.58.77.29] by _[66.149.149.239]_by with SMTP id A104C27E7 Mon, 23 Oct 2000 07:23:49 PDT To: rem-conf@es.net Subject: Bulk Email Your Business & Grow Mime-Version: 1.0 Content-Type: text/plain, charset="iso-8859-1" Date: Mon, 23 Oct 2000 07:41:06 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list WE THINK SO !! Dnaprint (DNAP) is an emerging biotech company and is trading under $1 !!! 1) CEO (Dr. Tony Frudakis) Lead scientist for Corixa starts his own company a few months ago 2) Company is formed by a reverse merger of a pinksheet company 3) DNAP has already completed the accounting to get off the pinksheets and should be listed on the OTCBB soon. 4) Dr. Frudakis was responsible for a patent that sold for $54,000,000 to Smith Kline Beecham while he was at Corixa. 5) Corixa's stock has gone from 14 Cents a few years ago to 50 Dollars today. 6) According to the Barron's article (9/25/00 pg 52), Dnaprint is in the late stages of forming strategic alliances with major companies. MAJOR WEB PAGES RELATED TO DNAP dnap http://www.dnaprint.com/ orchid biosciences inc http://www.orchidbio.com/ INVEST IN DNAP email for free investment package= hresources@dnaprint.com or call 1-877-362-3453(toll free) investment club web page=http://clubs.yahoo.com/clubs/dnaprintgenomicsinvestors investors report= http://www.companyreporter.com/index.php?u=companies.php great dnap investor links: http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=22034 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23118 http://cbs.marketwatch.com/news/current/molinski.htx?source=htx/http2_mw =invest in biotech http://www.loonycat.com/Genomics.htm =the human genome investors portal clearstation rates danp http://www.clearstation.com/cgi-bin/details?Event=peek&Symbol=DNAP&Refer=http://www.purepennies.com/ purepenny&3bagger rate dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132938 Pennystockprofits assess dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=15730 tipreporter rates dnap http://www.tipreporter.com/search.php?search=dnap dnap on stocktribes hotlist for 21 weeks http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24335 analysts tips and reports on dnap http://www.tipreporter.com/search.php?search=dnap http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=15730 why is dnap unique in the bio tech sector?? http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=22654 NEWSLINKS GENERAL FOR DNAP dnap company news http://www.bell2bell.newsalert.com/bin/digest?Symbol=DNAP& =bell2bell news http://quicken.excite.com/investments/quotes/?s=DNAP&t=0 =excite news http://biz.yahoo.com/n/D/DNAP.html =yahoo news dnap in barrons http://www.sockthestocks.com/profiles/dnapbarrons.htm bioinform news service http://www.bioinform.com/ online journal of bioinformatics http://www.cpb.uokhsc.edu/ojvr/xmlpaper.html#Sites UPCOMING EVENTS RELATED TO DNAP bio partnering Europe- London England-16-17 oct 2000 http://www.biopartnering.com/bpe/index.html structural genomics conference-yokohama,japan,2-5nov2000 http://icsg2000.riken.go.jp/ TECHNICAL SITES RELATED TO DNAP dnap patents http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21559 dnap is about pharmacogentics http://www.nigms.nih.gov/funding/medforyou.html stem cell research http://www.stemcellresearchnews.com/index.html personalized medicine no longer science fiction http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=25033 safe drugs that fit like a glove http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=11203 NEW STAFF ARRIVING AT DNAP SARASOTA dr. ramin mirashemi, a new dnap addition—check this track record!!!!!!!!!!!! http://www.google.com/search?q=Ramin+Mirhashemi&hl=en&lr=&safe=off&start=0&sa=N dr.jose arena joins dnap scientific advisory board 03 oct 2000 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23532 scientific advisory board makeup http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24575 DNAP COMPARED TO ITS TECHNICAL EQUALS, AND RIVALS: genomica(gnom)nasdq-ipo29sept00($19)now$22 http://www.bell2bell.newsalert.com/bin/story?StoryId=CoDqtWbWbtKvgmda1&FQ=genomica&HdlFmt=simple&Title=Headlines%20for%3A%20genomica informax(inunx)nasdq-ipo-03oct00($16)now$23 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23532 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=23552 incite genomics(incy)nasdq $37 http://quicken.excite.com/investments/news/?symbol=INCY genentech(dna)($172)-2for1split 5 oct00-263million share float---dnap float = 269 million http://www.bell2bell.newsalert.com/bin/digest?Symbol=DNA& DNAP IN EUROPE http://www.8ung.at/zockstocks http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21485 http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=24168 WHERE IS DNAP LOCATED—HOW DO YOU GET THERE? great air fare rates round trip to sarasota http://leisure.travelocity.com/RealDeals/Details/0,2941,TRAVELOCITY_AIR_449,00.html dnaps new upscale digs in swinging sarasota, fla http://www.ragingbull.altavista.com/mboard/boards.cgi?board=DNAP&read=21059 motel shopper link for sunny sarasota area http://www.roomsaver.com/roomsaver/city/index.html?state=FL&city=Sarasota location map of coconut ave digs http://maps.yahoo.com/py/maps.py?BFCat=&Pyt=Tmap&newFL=Use+Address+Below&addr=900+COCONUT+AVE&csz=SARASOTA%2CFLORIDA%2C+34234&country=us&Get%A0Map=Get+Map avis rent a car sarasota http://www.avis.com/cgi-bin/maps_and_directions/driving_maps/us_locations/mqinterconnect INTELLIGENT ADVICE OR BIASED ROT?KNOW THE DIFFERENCE OR HOW TO USE THESE MESSAGE BOARDS email suspected lying-sham efforts,etc to your federal govt(it,s called the sec) at enforcement@sec.gov http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132869 get the mob out of microcaps http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132789 crush naked shorting –stop being screwed without even knowing it—read me http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132581 suspicious sounding codswallop?? ask them to take the universal basher quiz!!!! http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132816 dnap has unusually good promise—accounting for the sad fact that were in “basher heaven”-read me http://www.ragingbull.altavista.com/mboard/boards.cgi?board=PCBM&read=132818 sec offers tips on how to avoid scams on the internet—good article http://www.sec.gov/consumer/cyberfr.htm CONTENTS 1.BACKGROUND 2.FOUNDERS 3.PRODUCTS&SERVICES 1.BACKGROUND DNAPrint genomics is a young e-biotech company based in southwest Florida. We are developing an informatics platform system that will provide dynamic solutions for disease gene discovery, genetic predisposition and genetic analysis testing. Our work has real-life application to the germinating field of Personalized Medicine and will help lay the foundation for a brand-new area of medical research called Phenomics. The PhenomeSM platform system that we are developing will help identify an individual predisposed to develop cancer before the onset of illness so that lifestyles can be altered and/or preventative measures taken. It will be used to identify individuals who are incompatible with certain drug treatments before the drugs are prescribed and damage is done. It will be used to tease out important genetic determinants associated with complex genetic diseases, so that drugs can be developed to target these genes. Our aim is ambitious. By partnering our platform with biotech/pharma, we will participate in the downstream profits generated from pharmaceutical products our platform has enabled. By marketing our platform directly to the public, we intend to make comprehensive genotype screening solutions accessible to people all over the world via the internet. Our system will enable a more holistic approach to using genomics information to improve peoples lives. The patient of the future will have more information and power than ever imagined. The human genome project, the internet and recent technological advancements all contribute to make this possible, and we intend to take advantage of these synergies to become the primary conduit for the generation and distribution of personalized genetic information. The Market Pharmacogenomics is currently a 1 billion dollar industry and is projected to be a 10 billion dollar industry by the end of 2003. Several billions of dollars have been spent on the human genome project so far, and an equal amount will likely be spent trying to understand what all of the genomics information means (i.e. bioinformatics, proteomics and phenomics). Genomics is a multi billion dollar industry world-wide and the market for personalized medicine is expected to exceed $25 billion dollars by 2010. Recently congress has approved a $2.3 billion increase in NIH funding to a total of $18 billion dollars for the year 2000. 2.FOUNDERS Tony Frudakis, Ph.D.(tfrudakis@dnaprint.com) Chief Executive Officer, President and Laboratory Director. Dr. Tony Frudakis is a Phi Beta Kappa, Magna Cumme Laude graduate of the University of California system. He received his doctorate degree in molecular and cell biology from the University of California Berkeley and has 14 total years of experience as a molecular biologist. Dr. Frudakis' technical experience encompass a range of areas within biology, including the molecular biology of eukaryotic transcriptional regulation, the creation and study of transgenic animals, the development of novel nucleic acid isolation techniques and gene discovery protocols, bioinformatics processing and anatomical gene expression profiling. At Corixa Corporation in Seattle, WA he developed several new techniques for RNA fingerprinting, managed and executed high-throughput gene discovery programs for various cancers and was instrumental in the companies early success in attracting R and D partners. Founding GAFF biologic in 1998, Dr. Frudakis established a good reputation for high quality DNA sequencing and library construction/screening services, until its evolution into the DNAPrint Genomics that exists today. In all, his work has resulted in a patent portfolio for over 350 unique genes and 2 products George Frudakis(gfrudakis@dnaprint.com) Vice President of Business Affairs. George Frudakis has vast experience with start-up company development. He started and developed a successful multi-component company called GAFF group, which today enjoys over 15 million dollars annually in revenue. During his life’s work as an entrepreneur and businessman, George has learned how to run and successfully manage the financial and operational aspects of both small and large companies alike. He is a graduate from the California State University at Long Beach in California. Myung Ho Kim, Ph.D. Mathematics(mkim@dnaprint.com) Director of Informatics and Lead Mathemetician. Myung recieved his Ph.D. in Mathematics from the University of Michigan in Ann Arbor in 1988 and M.S. in Mathematics from The Ohio State University in Columbus Ohio. Most recently, Myung worked on the Ant World Server project supported by DARPA (Defense Advanced Research Progect Agency) and implemented Kolmogorov-Smirnov tests, linear/nonlinear regression, nonparametric analysis and modeling to a TREC 6 (Text Retrieval Conference) project using SAS, C/C++ and Perl languages. Prior to this, Myung simulated mathematical modeling for breast tumors and implemented/developed various image processing algorithms. He has served as an Honorary research Fellow in the Department of Mathematics and Information Science at the University of Auckland, New Zealand and a Visiting Research Scholor in the Department of Mathematics at the University of California at Santa Cruz in California. Prior to coming to the United States, Myung held the position of Assistant Professor in the Department of Mathematics at Sungkyunkwan University in Soel Korea. Venkateswarlu Kondragunta, Ph.D. (vkondragunta@dnaprint.com) Director of Biostatistics. Dr. Kondragunta obtained his Ph.D. in Statistics from the University of Madras, Madras, India. He most recently served as a Postdoctoral Fellow at the Schoolof Public Health, University of Texas, Houston, TX under the tutelage of Dr. Ranajit Chakraborty, one of the most famous and accomplished genetic mathematicians in the world. His research interests include variance components, linear regression models, general linear models, design and analysis, discriminant analysis, principal component analysis and statistical genetics. He has taught courses in Variance Components, Design and Analysis of Experiments and Linear Regression Models and Probability Theory at Concordia University in Montreal, Canada. Dr. Kondragunta is an accomplished programmer and has amassed considerable experience with implementing statistical genetic ideas into C++, S-plus, FORTRAN (7 years experience) and JAVA code. His most recent work used the REG, ANOVA, GLM, VARCOMP, CANDISC, CLUSTER, DISCRIM, FACTOR, PRINCOMP and LOGISTIC tools in the SAS computing environment on real and simulated data sets. A partial list of publications for Dr. Kondragunta include: Chaubey, Y.P. and K.Venkateswarlu. A numerical study of some robust estimators of variance components in one-way model. International Indian Statistical Association Conference proceedings, October 10-11, 1998, McMaster University, Hamilton, Canada. Venkateswarlu, K. K.N.Ponnuswamy, and M.R.Srinivasan. Estimation of variance components based on diallel model. Mathematical Biosciences, V-150, 105-112. Venkateswarlu, K, and K.N.Ponnuswamy. Estimation of variance components based on bio-model of diallel crosses (balanced). Communications in Statistics (Theory & Methods), Vol-27, 139-152. Venkateswarlu, K. Estimation of variance components based on diallel model involving maternal and maternal interaction effects. Biometrical Journal, Vol-39, 287-295. 3.PRODUCTS&SERVICES see dnap web page for a complete description of products & services http://www.dnaprint.com/ SNiPdocTM High-throughput SNP profiling-To help us with our bottom line, we provide contract SNP profiling services to the drug development community. We call this service our SNiPdocTM service, and it is targeted towards pharmaceutical companies. Many pharmaceutical companies are seeking to enter into the field of Pharmacogenomics. This new field of study could have a dramatic impact on overall health care costs in the future. Furthermore, by having access to pharmacogenomics data, pharmaceutical companies can focus their clinical trials on segments of the population that are genetically receptive to the treatment. Experimental drugs can be targeted to individuals of a particular genotype, and genetic variations shown to underlie a poor-response to a trial drug could be used as a basis for eliminating the non-responding segment of the trial population from the study. In this way, pharmaceutical companies can reduce drug trial failures and the costs associated with them. Contracting this work out to service providers is a viable option for many smaller pharmaceutical companies who do not have the volume of work necessary to justify the price of the equipment and expertise. At DNAPrint Genomics, we offer multiple patient – multiple SNP sampling matricies designed on a custom, semi-custom or predefined basis. We can use our proprietary PhenomixM databases of medically relevant SNPs (numbering in the thousands of SNPs at present), or design chips for your application de-novo. We will work with your scientists to develop the experiments from beginning to end, that suit your needs, and we can handle your project from blood/tissue or DNA starting points. Data handling will be customized for each client; data can be deposited in our secure SNP relational databases system offering you the option of accessing your data over the internet. Alternatively, we can burn and hand-delivered CDs to Raging Bull Advertisements Looking for ORACLE E-BUSINESS SOLUTIONS? See Blasters and Disasters, Free! M4Logic All Your Accounts in One Place -- Free & Easy! From rem-conf Sun Oct 29 12:40:20 2000 From rem-conf-request@es.net Sun Oct 29 12:40:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13pzAa-0005sy-00; Sun, 29 Oct 2000 12:35:08 -0800 Received: from tisch.mail.mindspring.net [207.69.200.157] by mail1.es.net with esmtp (Exim 1.81 #2) id 13pzAX-0005sL-00; Sun, 29 Oct 2000 12:35:05 -0800 Received: from pornthief.com (sdn-ar-004flmiamP123.dialsprint.net [168.191.253.187]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id PAA01592; Sun, 29 Oct 2000 15:34:54 -0500 (EST) From: Subject: http://www.pornthief.com Date: Sun, 29 Oct 2000 20:34:36 Message-Id: <701.379388.291804@pornthief.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It's about time you stop spending money on Porn sites that are rubbish..... one subscription is enough if it's from Pornthief.com http://www.pornthief.com Because you only need one subscription to have access to hundreds of sites WE HAVE THE SEXIEST GUYS AND GALS ON THE 'NET! VOTED BEST NEW PORN SITE OCTOBER 2000 Net Sex Magazine Visit now! http://www.pornthief.com and get ready for the best sex site youve seen so far.....money back guarantee!!!!!!!!!! From rem-conf Sun Oct 29 17:47:28 2000 From rem-conf-request@es.net Sun Oct 29 17:47:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13q3zi-00015v-00; Sun, 29 Oct 2000 17:44:14 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13q3zh-00015l-00; Sun, 29 Oct 2000 17:44:13 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA06953; Sun, 29 Oct 2000 20:24:33 -0500 Message-Id: <200010300124.UAA06953@purple.east.isi.edu> To: rem-conf@es.net Subject: AVT at IETF 49 cc: casner@acm.org Date: Sun, 29 Oct 2000 20:24:33 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The preliminary agenda for the 49th IETF has AVT scheduled for two slots: Wednesday 15:30-17:30 and Thursday 13:00-15:00 (these are subject to change, of course). Anyone wanting agenda time in the AVT meeting should contact me and Steve, and we'll put a draft together. Cheers, Colin From rem-conf Mon Oct 30 12:22:20 2000 From rem-conf-request@es.net Mon Oct 30 12:22:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qLIX-0003Wp-00; Mon, 30 Oct 2000 12:12:49 -0800 Received: from neko.cts.com [209.68.192.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qLIU-0003Wf-00; Mon, 30 Oct 2000 12:12:47 -0800 Received: from viao.tbt.com ([198.68.174.132]) by neko.cts.com (8.9.3/8.9.3) with ESMTP id MAA25470 for ; Mon, 30 Oct 2000 12:12:37 -0800 (PST) Message-Id: <5.0.0.25.2.20001030113741.05078c80@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 11:41:05 -0800 To: rem-conf@es.net (IETF AVT WG) From: "Michael A. Dolan" Subject: RTP content type questions/comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am new to this WG, but understand MPEG and am active in SMPTE and ATSC standards efforts. So in that context, I have some questions on the IETF AVT WG ID (draft-ietf-avt-profile-09) related to the supported RTP content types and the meaning of the names: 1. Regarding "video/mp2t": The document says "either audio or video". Since a transport stream is usually both, what does this mean exactly? Do you mean that these are really elementary streams just encapsulated in 188-byte transport packets, or do you mean a real transport stream constrained only by 13818-1? 2. If the former in (2), then how does one carry a "real" transport stream? 3. If the latter in (2), then does this stream have to strictly adhere to 13818-1? No mention of this is made, and if it is truly a 13818-1 transport stream, then without some PSI tables, one cannot unwrap the elementary streams from the transport, or even know what they are. 4. Either way, what elementary stream types are supported? 13818-1 is basically open ended on stream types. So this applies to both mp2t and mp2p. As written, the document is unbounded. One might infer that the stream types are bounded by the elementary streams enumerated either in this document or in RFC 2250, but this is not stated. 5. Any reason not to include AC-3 (analogous to 13818-3)? This is the broadcast audio standard in the US, and is starting to creep into some European digital systems. FYI, an ID was recently submitted by Dolby to register the content type, "audio/ac3". The reason I care is that these content types need to coexist in the SMPTE and ATSC system environments so they can be re-used there with the same meaning. Thanks, Mike ------------------------------------------------------ Michael A. Dolan, Representing DIRECTV, (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 From rem-conf Mon Oct 30 16:10:26 2000 From rem-conf-request@es.net Mon Oct 30 16:10:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qOux-00066Z-00; Mon, 30 Oct 2000 16:04:43 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qOuv-00066P-00; Mon, 30 Oct 2000 16:04:41 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA24225; Mon, 30 Oct 2000 17:04:38 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA07070; Mon, 30 Oct 2000 17:04:37 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id SAA26194; Mon, 30 Oct 2000 18:04:37 -0600 (CST) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id SAA04386; Mon, 30 Oct 2000 18:04:36 -0600 (CST) Message-Id: <200010310004.SAA04386@agevole.cig.mot.com> Date: Mon, 30 Oct 2000 18:07:27 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: AVT List CC: lln@cdt.luth.se, Allison Mankin Subject: optional CRC field in AMR payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, all, I'd like to get your opinion on whether an 8 bit optional CRC field is useful in the AMR payload design. The coauthors of the two RTP AMR payload drafts (draft-xie-avt-et-rtp-amr-00.txt and draft-ietf-avt-rtp-amr-01.txt) have been having an off-line discussion on this topic. Opinion #1: since the transport layer and link layer of Internet are currently bit-error intolerant (they have their own CRC or checksum to filter out any bad data packet before it can reach the RTP receiver), a CRC field in AMR payload won't add any value to the design and therefore should not be included. Opinion #2: bit error-tolerant to speech data is one big advantage of AMR codec, we should not *design out* this feature when we define the AMR payload simply because the current transport and link layer are not ready for error-tolerant data transfer. There have already been talks about the idea of error-tolerant data transfer support at the transport and link layers and some initial work has already started (see Pittsburgh AVT meeting minutes and UDP-Lite draft). We should be forward-looking and include an optional CRC field in the AMR payload, especially when the size cost of adding this optional CRC field is only 1 bit. And my opinion is of cause Opinion #2 :-) regards, -Qiaobing From rem-conf Mon Oct 30 23:48:27 2000 From rem-conf-request@es.net Mon Oct 30 23:48:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qW49-0001hI-00; Mon, 30 Oct 2000 23:42:41 -0800 Received: from nmh.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qW47-0001h8-00; Mon, 30 Oct 2000 23:42:39 -0800 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e9V7gYt23437; Tue, 31 Oct 2000 08:42:34 +0100 (MET) From: "Dr. Carsten Bormann" To: "Qiaobing Xie" , "AVT List" Cc: , "Allison Mankin" Subject: RE: optional CRC field in AMR payload Date: Tue, 31 Oct 2000 08:42:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200010310004.SAA04386@agevole.cig.mot.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There have already been talks > about the idea of error-tolerant data transfer support at the transport > and link layers and some initial work has already started (see > Pittsburgh AVT meeting minutes and UDP-Lite draft). Another data point: The ROHC working group is trying hard to make header compression tolerant not only of packet losses but also of residual bit errors handed up from the link layer. Together with IPv4's ability to switch off the UDP checksum, we already have some support from the transport layer (and by the nature of ROHC, we are adding protection to the RTP header, in some modes only by reducing its cross-section, in others also by adding a 3-bit or larger CRC). Work is needed for IPv6, though. Gruesse, Carsten From rem-conf Tue Oct 31 04:21:55 2000 From rem-conf-request@es.net Tue Oct 31 04:21:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qaKc-0004Ka-00; Tue, 31 Oct 2000 04:15:58 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qaKa-0004KQ-00; Tue, 31 Oct 2000 04:15:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23064; Tue, 31 Oct 2000 07:15:55 -0500 (EST) Message-Id: <200010311215.HAA23064@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-xie-avt-et-rtp-amr-01.txt Date: Tue, 31 Oct 2000 07:15:54 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Error Tolerant RTP Payload Format for AMR Author(s) : Q. Xie, S. Gupta Filename : draft-xie-avt-et-rtp-amr-01.txt Pages : Date : 30-Oct-00 This document defines the RTP payload format for *error tolerant* delivery of Adaptive Multi-Rate (AMR) speech frames over an RTP session. The flexibility on bandwidth requirements and the tolerance to bit errors of AMR codes are not only beneficial for 'over-the-air' wireless links, but are also very desirable for any Voice-over-IP applications. The design is focused on how to best facilitate these features of AMR codec in an IP environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xie-avt-et-rtp-amr-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-xie-avt-et-rtp-amr-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-xie-avt-et-rtp-amr-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: <20001030080904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-xie-avt-et-rtp-amr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-xie-avt-et-rtp-amr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001030080904.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Oct 31 06:37:57 2000 From rem-conf-request@es.net Tue Oct 31 06:37:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qcV8-0006CY-00; Tue, 31 Oct 2000 06:34:58 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qcV6-0006CM-00; Tue, 31 Oct 2000 06:34:56 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA04081; Tue, 31 Oct 2000 09:34:34 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <39FED87B.606A7D99@cs.columbia.edu> Date: Tue, 31 Oct 2000 09:34:35 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Subject: Call for Papers: Network and Operating Systems Support for Digital Audio and Video (NOSSDAV) 2001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:;:; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) Sponsored by the Association for Computing Machinery In cooperation with USENIX, ACM SIGCOMM, ACM SIGMM, ACM SIGOPS Technically cosponsored by IEEE Communications Society June 25-27, 2001 Danfords on the Sound, Port Jefferson, New York http://www.nossdav.org/2001 CALL FOR PAPERS The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) will bring together participants from academia and industry to present and discuss new ideas and future directions in networking and operating system support for multimedia. Exponential improvements in networking bandwidth, cost, and ubiquity coupled with the growing availability and use of streaming media content pose new networking and operating system research opportunities and challenges at the global systems level. We solicit papers in current or emerging areas including but not limited to ubiquitous multimedia services, broadband streaming media content distribution, webcasting, end-to-end resource management, real-time interactive streaming audio services, internet telephony, interactive network games, wireless multimedia systems, and multimedia information appliances and consumer devices. The workshop particularly encourages submission of papers describing implementations, measurements and field experience. To ensure a productive workshop environment, attendance will be limited to about 70 participants who are active in the field. Each potential participant should submit a position paper or extended abstract that identifies new problems and explains why they are important, challenges conventional wisdom, advocates a specific solution, and/or reports on actual experience with real systems. Papers will be subject to a normal review process and are restricted to five pages. Participants will be invited based on the originality, technical merit and topical relevance of their submissions, as well as the likelihood that the ideas expressed in their submissions will lead to insightful technical discussions at the workshop. Papers submitted to NOSSDAV must not have been published or submitted elsewhere. Please do not submit abbreviated versions of journal or conference papers. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. All submissions must be made through the web. For detailed guidelines for submission, please refer to the workshop web site at http://www.nossdav.org/2001. Important Dates: ================ Submission Deadline for Papers: February 15, 2001 Acceptance Notification: April 2, 2001 Camera Ready Deadline: May 15, 2001 Workshop: June 25-27, 2001 NOSSDAV 2001 Organizing Committee: ================================= Chairs: Jason Nieh, Columbia University Henning Schulzrinne, Columbia University Peter Danzig, Akamai Christophe Diot, Sprint Advanced Technology Labs Wu-chi Feng, Ohio State University Anoop Gupta, Microsoft Research Chuck Kalmanek, AT&T Research Duane Northcutt, Sun Microsystems Larry Peterson, Princeton University Larry Rowe, University of California, Berkeley Doug Shepherd, Lancaster University -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Oct 31 14:00:33 2000 From rem-conf-request@es.net Tue Oct 31 14:00:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qiFF-0001ef-00; Tue, 31 Oct 2000 12:42:57 -0800 Received: from pop.gmx.net (mail.gmx.net) [194.221.183.20] by mail1.es.net with smtp (Exim 1.81 #2) id 13qiFE-0001eP-00; Tue, 31 Oct 2000 12:42:56 -0800 Received: (qmail 31769 invoked by uid 0); 31 Oct 2000 20:41:52 -0000 Received: from dialin-port5362.access.nacamar.de (HELO f5q6i7) (62.27.221.241) by mail.gmx.net with SMTP; 31 Oct 2000 20:41:52 -0000 From: "Joe Simple" To: Subject: Date: Tue, 31 Oct 2000 21:37:18 -0800 Message-ID: <000301c043c5$cc6d3020$f1dd1b3e@f5q6i7> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >subscribe avt jose.rey@gmx.de From rem-conf Tue Oct 31 23:18:58 2000 From rem-conf-request@es.net Tue Oct 31 23:18:56 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13qs1Q-0002cg-00; Tue, 31 Oct 2000 23:09:20 -0800 Received: from [198.211.237.63] (helo=unknown) by mail2.es.net with smtp (Exim 1.92 #1) id 13qs1N-0002cW-00; Tue, 31 Oct 2000 23:09:17 -0800 From: Subject: toner cartridges Date: Tue, 31 Oct 2000 10:32:33 Message-Id: <262.485804.888453@> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Your Toner Cartidge Discount Depot Special savings on Laser Printer and Fax Toner Cartridges. Savings on Canon Personal Copier Cartridges. Cartridges offered are Hewlett Packard,Canon,Lexmark,Apple and Epson compatible products. For more Information please call: 1-888-248-2015 For E-mail removal please call: 1-888-248-4930 From rem-conf Tue Oct 31 23:46:41 2000 From rem-conf-request@es.net Tue Oct 31 23:46:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13qsXT-0007XE-00; Tue, 31 Oct 2000 23:42:27 -0800 Received: from server07.selangor.gov.my (sukgate.selangor.gov.my) [192.228.219.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13qsXQ-0007X4-00; Tue, 31 Oct 2000 23:42:25 -0800 Received: from 0TeE8066f (63.50.202.158 [63.50.202.158]) by sukgate.selangor.gov.my with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VYV9JLJM; Wed, 1 Nov 2000 15:41:38 +0800 DATE: 01 Nov 00 3:40:42 AM FROM: e846xi95N@mail.com Reply-to: websiteonly756@mail.com Message-ID: TO: ldCalls4less4@excite.com SUBJECT: Your Long Distance Bill Is Incorrect..... X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Best Long Distance Deal In America! $49.95 A Month Flat Rate! Info? Click This link: http://3506561042/%6C%64%34%6C%65%73s%37%30%30%30 For service Call: 1-800-394-9907 Now Looking For Reps! Earn over $5000.00 a month from your home, no experience needed. Call: 1-800-394-9907