From rem-conf Fri Sep 01 11:14:54 2000 From rem-conf-request@es.net Fri Sep 01 11:14:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UvDp-0007n6-00; Fri, 1 Sep 2000 11:07:25 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13UvDo-0007mv-00; Fri, 1 Sep 2000 11:07:24 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 1 Sep 2000 13:05:23 UT Subject: Re: Fwd: Re: Define a unicast RTP session. To: Jonathan Rosenberg Cc: "Strahm, Bill" , Mark Baugher , rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Fri, 1 Sep 2000 13:02:41 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 09/01/2000 02:07:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The literal understanding of the section 3 definition includes the observation that the definition is singular, thus saying "For each participant, _the_ session . . .". It does not say "For each participant, _a_ session . . .". Subtle, but unambiguous. So the session (not necessarily the destination address) is common to all, regardless of the caste. Further proof: section 7.1, paragraph 1. There, clouds are equated to sessions, and a unicast cloud is defined by a pair of unicast addresses. It requires no interpretation to call those destination addresses. Therefore a unicast session is defined by two destination addresses (where the destination port is still common). This causes no problems for the MIB. I see this might not be true for SDP. Perhaps you could elaborate. Here's my contribution: I agree with you that, under RFC 1889, an SDP invite and its OK will create two sessions if the destination ports differ. But if they don't (can this be done predictably?), there should be (is) one session. Later drafts of RFC 1889 do specify that the destination ports in a session may differ, and thus might eventually cause trouble for SIP/SDP if its notion of a session changes, if there's not trouble now. Then it might become difficult for SIP/SDP to correlate the two directions of flow (is this necessary?). Anyway, this came after the definition of SDP (RFC 2327), so was not there to muddy the waters when the SDP authors were considering the nature of a session. Bidirectional unicast sessions could have been explicitly permitted from the beginning. Vince Virgilio Jonathan Rosenberg on 09/01/2000 12:40:49 AM To: "Strahm, Bill" cc: "'Vincent_Virgilio@nmss.com'" , Mark Baugher , rem-conf@es.net Subject: Re: Fwd: Re: Define a unicast RTP session. "Strahm, Bill" wrote: > > I think I'll step in as another one of the RTP MIB authors who had to > wrangle with this issue... > > We took the definition from 1889 quite literally From section 3 > > RTP session: The association among a set of participants > communicating with RTP. For each participant, the session is > defined by a particular pair of destination transport addresses > (one network address plus a port pair for RTP and RTCP). The > destination transport address pair may be common for all > participants, as in the case of IP multicast, or may be > different for each, as in the case of individual unicast network > addresses plus a common port pair. In a multimedia session, > each medium is carried in a separate RTP session with its own > RTCP packets. The multiple RTP sessions are distinguished by > different port number pairs and/or different multicast > addresses. > > Therefore in the case of unicast there ARE two sessions, because there are > two different destination transport addresses. Did we get it right, I hope > so (we are on track to have an RFC issued). This was my understanding, and is exactly the reason I claimed it was two in the first place. Also, if one assumes that a single m line in SDP means one session, then with SIPs usage of SDP we also get two sessions - thats because one SDP is sent in the INVITE (indicating the receive port pairs of the caller), and another, different SDP in the 200 OK (indicating the receive port pairs of the callee). This is what I meant by mentioning that the annexes in SIP should be checked for more info. -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: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Fri Sep 01 20:20:06 2000 From rem-conf-request@es.net Fri Sep 01 20:20:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13V3eS-0004sD-00; Fri, 1 Sep 2000 20:07:28 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13V3eQ-0004s3-00; Fri, 1 Sep 2000 20:07:26 -0700 Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA11209; Fri, 1 Sep 2000 23:09:07 -0400 (EDT) Message-ID: <39B06EAE.2C414FB9@dynamicsoft.com> Date: Fri, 01 Sep 2000 23:06:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vincent_Virgilio@nmss.com CC: "Strahm, Bill" , Mark Baugher , rem-conf@es.net Subject: Re: Fwd: Re: Define a unicast RTP session. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vincent_Virgilio@nmss.com wrote: > > I agree with you that, under RFC 1889, an SDP invite and its OK will create > two sessions if the destination ports differ. But if they don't (can this > be done predictably?), there should be (is) one session. Later drafts of > RFC 1889 do specify that the destination ports in a session may differ, and > thus might eventually cause trouble for SIP/SDP if its notion of a session > changes, if there's not trouble now. There is no trouble now. Whether you call it one or two sessions in any case seems completely academic. The operation in either case, as I can tell, is the same. > Then it might become difficult for > SIP/SDP to correlate the two directions of flow (is this necessary?). Sorry? How do you arrive at this conclusion? As the caller, I choose the ports I will receive media on, and I am told the ports to send media two. They are correlated since they are part of the same SIP call. Its been working in SIP devices for a while. -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: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Sat Sep 02 23:20:50 2000 From rem-conf-request@es.net Sat Sep 02 23:20:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13VSuc-0001dq-00; Sat, 2 Sep 2000 23:05:50 -0700 Received: from (teda.com) [202.99.100.34] by mail1.es.net with smtp (Exim 1.81 #2) id 13VSuZ-0001df-00; Sat, 2 Sep 2000 23:05:48 -0700 Received: from 34789ruidf345 by teda.com (SMI-8.6/SMI-SVR4) id NAA01541; Sun, 3 Sep 2000 13:57:52 +0800 Date: Sun, 3 Sep 2000 13:57:52 +0800 From: mike898@yybecker234.mx Message-Id: <200009030557.NAA01541@teda.com> To: Subject: ADV: High Search Engine Placement 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 Sun Sep 03 14:55:34 2000 From rem-conf-request@es.net Sun Sep 03 14:55:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Vhba-0001V0-00; Sun, 3 Sep 2000 14:47:10 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13VhbY-0001Uk-00; Sun, 3 Sep 2000 14:47:09 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 3 Sep 2000 22:47:05 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: ++UK (0)20 7679 3704 To: rem-conf@es.net Subject: A/V Congestion Control Date: Sun, 03 Sep 2000 22:47:03 +0100 Message-ID: <6888.968017623@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With the addition of the congestion control to the RTP draft I was wondering if anyone in the group has references or pointers on work examining subjective and/or objective performance of adaptive coding schemes? i.e. the effects, real or simulated, from an end-user perspective. Any pointers would be welcome. cheers - Orion. From rem-conf Sun Sep 03 16:51:24 2000 From rem-conf-request@es.net Sun Sep 03 16:51:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13VjTH-0003Ge-00; Sun, 3 Sep 2000 16:46:43 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13VjTG-0003GU-00; Sun, 3 Sep 2000 16:46:42 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Sep 2000 00:46:39 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: rem-conf@es.net Subject: Re: A/V Congestion Control In-reply-to: Your message of "Sun, 03 Sep 2000 22:47:03 +0100" References: <6888.968017623@cs.ucl.ac.uk> Date: Mon, 04 Sep 2000 00:46:38 +0100 Message-ID: <7400.968024798@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Orion Hodson wrote: > With the addition of the congestion control to the RTP draft I was > wondering if anyone in the group has references or pointers on work > examining subjective and/or objective performance of adaptive coding > schemes? i.e. the effects, real or simulated, from an end-user > perspective. Any pointers would be welcome. It's been bought to my attention that this question is a too vague, that was the intention, but I clearly went too far. I'm interested in work assessing the subjective, or objective, quality at the receiver when the encoder has multiple operational modes (and/or bit-rates) with a modulation mechanism that controls the encoder. As an example, consider MPEG-4 audio. It includes several distinct families of audio encoder operating at different data rates and over different signal bandwidths. An application might adapt the mean data rate in response to a congestion indicator. You might (reasonably) expect transitions between encoder family to be harder to conceal than small differences in mean data rate by the encoder. This type of information might influence an adaptation algorithm. Is there work that other members of the group are aware of that quantifies those types of transitions by subjective or objective assessment? - Orion. From rem-conf Sun Sep 03 18:23:56 2000 From rem-conf-request@es.net Sun Sep 03 18:23:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13VksB-0004hX-00; Sun, 3 Sep 2000 18:16:31 -0700 Received: from relay.tyrc.edu.tw (asusan.tyc.edu.tw) [163.28.49.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Vks9-0004hN-00; Sun, 3 Sep 2000 18:16:29 -0700 Received: from fs.ccit.edu.tw (fs.ccit.edu.tw [140.132.3.210]) by asusan.tyc.edu.tw (8.9.3/8.9.3) with ESMTP id JAA48129 for ; Mon, 4 Sep 2000 09:18:01 +0800 (CST) (envelope-from tonywu@ccit.edu.tw) Received: from cc05.ccit.edu.tw (cc05.ccit.edu.tw [140.132.3.205]) by fs.ccit.edu.tw (8.9.3/8.9.3) with ESMTP id JAA16589 for ; Mon, 4 Sep 2000 09:15:46 +0800 (CST) Received: from ccit.edu.tw (off101.cs.ccit.edu.tw [140.132.36.101]) by cc05.ccit.edu.tw (8.9.3/8.9.3) with ESMTP id JAA03222 for ; Mon, 4 Sep 2000 09:16:25 +0800 (CST) Message-ID: <39B2F646.A3286483@ccit.edu.tw> Date: Mon, 04 Sep 2000 09:09:26 +0800 From: tonywu X-Mailer: Mozilla 4.72 [en]C-CCK-MCD (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list subscribe From rem-conf Sun Sep 03 21:52:29 2000 From rem-conf-request@es.net Sun Sep 03 21:52:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Vo2o-00077h-00; Sun, 3 Sep 2000 21:39:42 -0700 Received: from (union.mobiletone.com) [205.219.91.37] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 13Vo2n-00077W-00; Sun, 3 Sep 2000 21:39:41 -0700 Received: (qmail 649 invoked by uid 514); 4 Sep 2000 03:12:16 -0000 Date: 4 Sep 2000 03:12:16 -0000 Message-ID: <20000904031216.648.qmail@union.mobiletone.com> From: "Traderfirst Webmaster" To: "rem-conf@es.net" Subject: Electronics Parts B2B Portal (Celebrating TraderFirst Official Launch with Lucky Draw Campaign) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list English: http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=en Traditional Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=big5 Simplified Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=gb Dear Valued Customer, (New B2B Electronic Asia Portal) * We are pleased to inform you that TraderFirst.com (www.traderfirst.com) will be officially launched on September 6th, 2000. We dedicate in providing first class services and products to our customers. * Company Introduction: Traderfirst.com is a leading Internet business-to-business (B2B) exchange and application service provider (ASP) mainly for electronics parts and semiconductor industry in Asia. We are providing a Chinese and English Internet platform for customers to bridge their business worldwide efficiently. TraderFirst.com philosophy is simple: we care the CUSTOMERS, SERVICES, & QUALITY. * WANNA! HK$20,000.00 CASH Lucky Draw Program: For the first 200 "Gold Members only" In order to celebrate the official launch, we set up a HK$20,000 cash lucky draw program* for one lucky winner, plus 10 special prizes. Please visit www.traderfirst.com now & get more business opportunities. * "Gold member" registration site: www.traderfirst.com. Please register today and don't lose the chance to win the HK$ 20,000.00 CASH! Thank you of your kind attention. If you have any question, please feel free to contact at 852-24050498 or e-mail to customer@traderfirst.com Yours faithfully, Marketing Department, TraderFirst.com Ltd (www.traderfirst.com) N.B: * All employees of TraderFirst.com and their affiliates are not allowed to participate. This program is for worldwide customers. It is subject to change. All rights are reserved by TraderFirst.com. If you do not wish to receive any promotional materials from us, please send e-mail to info@traderfirst.com. From rem-conf Mon Sep 04 07:27:14 2000 From rem-conf-request@es.net Mon Sep 04 07:27:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Vx5Z-0005Do-00; Mon, 4 Sep 2000 07:19:09 -0700 Received: from olymp.informatik.uni-bonn.de (mailhost.informatik.uni-bonn.de) [131.220.4.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Vx5X-0005D1-00; Mon, 4 Sep 2000 07:19:07 -0700 Received: from cs.uni-bonn.de (ottawa.informatik.uni-bonn.de [131.220.6.144]) by mailhost.informatik.uni-bonn.de (Postfix) with ESMTP id 9383462FC; Mon, 4 Sep 2000 16:18:58 +0200 (MET DST) Message-ID: <39B3AF8D.204F0D4B@cs.uni-bonn.de> Date: Mon, 04 Sep 2000 16:19:58 +0200 From: Peter Martini Organization: University of Bonn, Institute of Computer Science IV X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Martini Subject: LCN 2000 (Tampa, Fl, Nov. 8-10) - call for participation Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Please, accept our apologies for multiple copies of this message.) =========================================================================== *** PRELIMINARY PROGRAM AND CALL FOR PARTICIPATION *** LCN 2000 The 25th Annual IEEE Conference on Local Computer Networks November 8 - 10, 2000 Embassy Suites USF, Tampa, Florida http://www.ieeelcn.org Sponsored by the IEEE Computer Society with support from GTE Data Services, Paradyne Corporation, and the University of South Florida College of Engineering. The IEEE LCN conference is the premier conference on leading edge and practical computer networking. LCN 2000 will have three tutorials, two keynote addresses, three panels, and 105 papers (72 full and 33 short) in six sessions and four tracks. Full papers are 10 pages and 20 minutes presentation, short papers are 2 pages and 10 minutes. The preliminary program is below. CONFERENCE PRE-REGISTRATION: The conference fees include a copy of the proceedings, four breaks, two luncheons, and the Thursday evening dinner. The pre-registration deadline is October 31, 2000. IEEE member Non-member Student Conference $495 $610 $300 Tutorial #1 $645 $745 $645 Tutorial #2 $350 $500 $350 Tutorial #3 $350 $500 $350 Online registration is at http://www.ieeelcn.org/lcn25registration.html. Contact Ken Christensen at christen@csee.usf.edu for additional information. HOTEL PRE-REGISTRATION: Hotel registration is through the USF Embassy Suites (rooms are $114 US per night). See http://www.ieeelcn.org or call the hotel at 1 813-977-7066. The hotel pre-registration deadline is October 15, 2000. **************************************************************** Wednesday - November 8, 2000 **************************************************************** 9:00 - 5:00: Tutorial #1: Security Topics and Techniques (Gary Kessler, Champlain College) 9:00- 12:30: Tutorial #2: Virtual Private Networks (Dr. Tim Strayer, BBN Technologies and Dr. Ruixi Yuan, GTE Internetworking) 12:30 - 1:30: Lunch 1:30: - 5:00: Tutorial #3: Managing Internet Quality of Service (QoS) (Dr. Sanjay Jha, University of New South Wales) **************************************************************** Thursday - November 9, 2000 **************************************************************** 7:30 - 8:30: Registration 8:30 - 9:00: Opening and welcome session 9:00 - 10:00: Keynote address #1 - IPsec: How and Why (Dr. Stephen Kent, BBN) 10:00 - 10:30: Best paper presentation Anonymization Services for IP Multicast (full) C. Grosch 10:30 - 11:00: Coffee break 11:00 - 12:00: Panel #1 - Security (chair: Gary Kessler) 12:00 - 1:20: Lunch (sponsored by USF College of Engineering) 1:20 - 2:20: Panel #2 - Home access methods 2:20 - 2:40: Short break 2:40 - 4:00: Session #1 (Tracks A, B, C, and D) >>> Track A - Wireless LANs Transmission Power Control for Multiple Access Wireless Packet Networks (full) J. Monks A Novel Approach to ARQ Error Control Mechanisms for Wireless LANs Communications (full) N. T. Almeida, S. A. Abrantes Wireless Packet Scheduling with Signal-to-Noise Ratio Monitoring (full) H. Aida, Y. Tamura, Y. Tobe, H. Tokuda Comparison of TCP Reno and Vegas in Wireless Mobile Ad Hoc Networks (short) S. Xu, T. Saadawi, M. Lee Adaptive Approaches to Enhance Throughput of IEEE 802.11 Wireless LAN with Different Channel Quality (short) S. Ci, H. Sharif >>> Track B - Differentiated Services and QoS 1 Layered Network QoS Signalling - Motivation, Implementation & Measurements (full) J. Schmitt, M. Karsten, R. Steinmetz Class-Based QoS Control Scheme by Flow Management in the Internet Router (full) K. Minami, H. Tode, K. Murakami An Analysis of Resource Scheduling with Prioritization for QoS in LANs (full) D. H. Summerville, L. Edmunds Adaptive Bandwidth Reservation Mechanism Using Mobility Probability in Mobile Multimedia Computing Environment (full) C. H. Choi, M. I. Kim, T. J. Kim, S. J. Kim >>> Track C - Network security 1 Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA) (full) R. Ramanujan, A. Ahamad, J. Bonney, R. Hagelstrom, K. Thurber Network Security(Security in Large Networks) (full) M. Singh, S. Singh IGMPv3-Based Method for Avoiding DoS Attacks in Multicast-Enabled Networks (short) A. F. Gomez-Skarmeta, A. L. M. Martinez, P. M. R. Martinez Distributed Weakness in Virtual Private Networks (short) S. Patton, D. Doss, W. Yurcik >>> Track D - Reliability and fault-tolerance Algorithms for Minimal Cutsets Enumeration of Networks by Graph Search and Branch Addition (full) H. Suh, C. Chang Provisioning Multilayer Restoration for Convergence (full) J. Kroculick, C. Hood Fault-Tolerant Ethernet Middleware for IP-Based Process Control Networks (full) S. Song, J. Huang, P. Kappler, R. Freimark, T. Kozlik Simulative Reliability Analysis of SCI Ring-Based Topologies (full) M. Sarwar, A. George, D. Collins 4:00 - 4:30: Cookie break 4:30 - 5:50: Session #2 (Tracks A, B, C, and D) >>> Track A - Wireless LANs / Mobile IP Mobile Stations Localization in a WLAN (full) F. Peyrard, C. Soutou, J. J. Mercier Handoff Support for Mobilty with IP over Bluetooth (full) S. Baatz, M. Frank, R. Gpffarth, D. Kassatkine, P. Martini , M. Schetelig, A. Vilavaara A Portable Mobile IP Implementation (full) H. Haverinen, A. Kuikka, T.Maattanen Security of Routing Cache Updates in Cellular IP (short) S. Baatz, W. Hansmann, J. Tlle Location of Mobile Stations in a Wireless LAN (short) E. Llusca, T. Val, C. Normand, J. Mercier >>> Track B - Differentiated services and QoS 2 A Core-Stateless Buffer Management Mechanism for Differentiated Services Internet (full) Y. T. Hou, D. Wu, Z.-L. Zhang, T. Chujo Co-operation and Comparison of DiffServ and IntServ: Performance Measurements (full) J. Harju, P. Kivimaki An Optimal Bandwidth Allocation Scheme and Real- Time Performance Analysis for LTPB Network (full) Z. Qiang, L. Zhiqiang, L. Qiao, X. Huagang Programmable Resource Control in Global Active IP Networks (short) H. Guo, T. Becker On Integrating Differentiated Services and UMTS Networks(short) J. Diederich, T. Lohmar, M. Zitterbart, R. Keller >>> Track C - Network security 2 Multi-Dimensional Prefix Matching Using Line Search (full) M. Waldvogel On Key Distribution In Secure Multicasting (full) K.-P. Wu, F. Lai, C.-K. Tseng Group Management Strategies for Secure Multicasting on Active Virtual Private Networks (full) C. Labonte, S. Srinivas Open Source Versus Commercial Firewalls: Functional Comparison (short) S. Patton, D. Doss, W. Yurcik A Virtual Private Network Deployment Framework (short) S. Patton, B. Smith, D. Doss, W. Yurcik >>> Track D - Resource control Efficient Congestion Avoidance Mechanism (full) A. Dracinschi, S. Fdida Quality of Service using Traffic Engineering over MPLS: An Analysis (full) P. Bhaniramka, W. Sun, R. Jain DSRED: A New Queue Management Scheme for Next Generation Networks (full) B. Zheng, M. Atiquzzaman Achieving Moderate Fairness for UDP Flows by Path-Status Classifcation (full) Y. Tobe, Y. Tamura, A. Molano, S. Ghosh, H. Tokuda 5:50 - 7:00: Social hour 7:00: Dinner **************************************************************** Friday - November 10, 2000 **************************************************************** 7:30 - 8:30: Registration 8:30 - 9:30: Keynote address #2 - The Care and Feeding of Network Interfaces (Denton Gentry, Sun Microsystems) 9:30 - 9:40: Short break 9:40 - 10:40: Panel #3 - Multicast 10:40 - 11:10: Coffee break 11:10 - 12:30: Session #3 (Tracks A, B, C, and D) >>> Track A - Wireless / cellular networks Indoor Location Technique for 2G and 3G Cellular/PCS Networks (full) D.J. Shyy, B. Rohani Real Time Multicast in Wireless Networks (full) A. Benslimane DRiVE-ing to the Internet: Dynamic Radio for IP Services in Vehicular Environments (full) L. Xu, R. Tonjes, T. Paila, W. Hansmann, M. Frank, M. Albrecht iNetwork - a GSM Compliant IP-Based Communication Platform (short) C. W. Cheng, W. C. Liu, C. G. Chung Optimization Paging Cost by Dynamic Cell Grouping in Mobile Network (short) G. Y. Lee, Y. Lee >>> Track B - Differentiated services and QoS 3 Performance Measurements and Analysis of TCP Flows in a Differentiated Services WAN (full) J. Harju, Y. Koucheryavy, J. Laine, S. Saaristo, K. Kilkki, J. Ruutu, H. Waris, J. Forsten, J. Oinonen Proportional Packet Loss Differentiation and Buffer Management for Differentiated Services in the Internet (full) M. Markaki, M. P. Saltouros, I. S. Venieris End-to-end QoS Management for Delay-Sensative Scalable Multimedia Streams over DiffServ (full) M. Albrecht, M. Koster, P. Martini, M. Frank Integrated Service Mappings on Differentiated Service PHB :Guaranteed Service to Expedited Forwarding (short) B. Budiardjo, B. Nazief, D. Hartanto Intra-domain Bandwidth Management in Differentiated Services Network (short) S. Jha, M. Hassan, P. Nanda >>> Track C - Video communications Index Control and Bandwidth Distribution for Layered Video Stream Transmission on the Internet (full) C. Zhiyong, L. Zhang Joint Synchronization between Live and Stored Media in Multicast Communications (full) Y. Ishibashi, S. Tasaka, I. Miyamoto A Comparative Survey of Sychronization Algorithms for Continuous Media in Network Envirionments (full) Y. Ishibashi, S. Tasaka An Adaptive Dynamic Congestion Control of Compressed Video Traffic over ATM Networks (short) G. Sisodia, L. Guan, S. De, M. Dowlatshahi The Performance of Ethernet Under a Combined Data/Real-Time Traffic (short) M. A. Aboelaze, A. Elnagar >>> Track D - Multicast 1 A New Paradigm for Multipoint-to-Multipoint Communication Using XTP (full) G. Ramasivan, J. W. Atwood Multicast Routing Based on Ant-Algorithm For Delay-Bounded and Load-Balancing (full) L. Guoying, L. Zemin Systematic Testing of Protocol Robustness: Case Studies on Mobile IP and MARS (full) S. Begum, M. Sharma, S. Gupta, A. Helmy Optimal Placement of Multicast Nodes in All-Optical Networks (short) M. Ali, J. Deogun 12:30 - 1:50: Lunch 1:50 - 3:10: Session #4 (Tracks A, B, C, and D) >>> Track A - Wireless networks Interesting Optimization Problems in the Planning of Microwave Transmission Networks (full) S. Puthenpura Satellite over Satellite (SOS) Network: A Novel Concept of Hierarchical Architecture and Routing in Satellite Network (full) J. W. Lee, T. W. Kim, D. W. Kim The Effect of GA Parameters on PCS Network Planning (full) J. Li, Y. L. Guan, B. H. Soong Auto-Configuration of Wireless Cell-site (short) S. Djoko, H. Lee, K. Basu Experiment with the Validation of WAP Systems (short) O. Kone, A. R. Cavalli >>> Track B - TCP and other protocols 1 TCP Tunnels: Avoiding Congestion Collapse (full) B. P. Lee, R. K. Balan, L. Jacob, W. K. G. Seah, A. L. Ananda The Performance of TCP over ATM on Lossy ADSL Networks (full) G. Lu, R. Simmonds, X. Zhonge, B. Unger, C. Williamson Analytical Modeling and Performance Evaluation of the HIPERLAN CAC Layer Protocol for Real-Time Traffic (full) C. Coutras, P.-J. Wan, O. Frieder Simple Reliable Multicast for Parallel Processing in Extended LANs (short) J. Mulik, Y. Shi, P. Conrad TCP Performance of DMT-based ADSL System (short) X. He >>> Track C - Network management A Methodology for Performance Management of Networks (full) A. B. Drago, A. S. Garcia, M. E. Monteiro Switching Theory Approach to Alarm Correlation in Network Management (full) E. Aboelela, C. Douligeris Comparisons of Different Approaches for Capacity Management in ATM Networks (full) S. O. Larsson Open Network Platform for Multiprotocol Communication (short) D. Jozic, T.Osmanlic, D. Huljenic, V. Sinkovic Investigation of SNMP Impact on a Target Device (short) N. Matsushita >>> Track D - Multicast 2 Tree-Based Reliable Multicast in Combined Fixed/Mobile IP Networks (full) W. Yoon, D. Lee, C. Yu An Architecture for Seamless Access to Multicast Content (full) P. Liefooghe Multi-Cores Uni-Directional Shared Trees Multicast Routing Protocol (short) M. Yulu, C. Shiduan Delay Analysis for Multicast Switch under Burst and Poisson Traffic (short) C. Khemapatapan, P. Prapinmongkolkarn, S. Theerawoot Optical QoS in Multicast Wavelength-Routed Networks Part I -PowerConsiderations (short) M. Ali, J. Deogun 3:10 - 3:40: Cookie break 3:40 - 4:40: Session #5 (Tracks A, B, C, and D) >>> Track A - Virtual networks Performance Impact of Data Compression on Virtual Private Network Transactions (full) McGregor Implementation of a Bandwidth Broker for Dynamic End-to-End Resource Reservation in Outsourced Virtual Private Networks (full) I. Khalil, T. Braun Inter Bridge VLAN Registration Protocol for IP Subnet VLAN (short) C. Kok, M. SalimBeg, N. Gehlot Performance Evaluation of Software Virtual Private Networks (VPN) (short) C. Pena, J. Evans >>> Track B - TCP and other protocols 2 TCP Models in Simple Cases (full) T. Elteto, P. Benko TCP Performance over Heterogeneous Networks (full) M. Arpaci, H. Uzunalioglu, J. A. Copeland Effects of Competing Traffic on the Performance of TCP/IP over Asymmetric Links (short) K. Phanse, L. A. DaSilva, K. Kidambi On Some Metrics of TCP (short) A. Trinh, T. Eteto, L. Gyorfi >>> Track C - Optical networks Performance of Multihop Networks using Optical Buffering and Deflection Routing (full) A. G. Fayoumi, A. Jayasumana, J. Sauer Practical Traffic Grooming Scheme for Single-Hub SONET/WDM Rings (full) X.-Y. Li, L. Liu, P.-J. Wan, O. Frieder A Route Design Algorithm for Multiple-Encoding Optical CDM Switching Network (full) H. Tode, Z. Tianwei, S. Nishi, K. Murakami >>> Track D - Routing A Qos Routing Algorithm Based on Ant Algorithm (full) Z. Subing, L. Zemin Hierarchial Qos Routing in Delay-Bandwidth Sensitive Networks (full) K.-S. Lui, K. Nahrstedt, S. Chen IP Route Lookups as String Matching (full) A. Donnelly, T. Deegan 4:40 - 4:50: Short break 4:50 - 5:50: Session #6 (Tracks A, B, C, and D) >>> Track A - ATM Delay Estimation and Control of Available Bit Rate (ABR) Sources (full) P. Zhou, C. Thompson Link-based Performance Monitoring of ATM Networks (full) B. Thurm, H. R. Wiltfang Measurement of ATM Frame Latency (full) A. Durresi, R. Jain, G. Babic ATM Network Connection Management Using Mobile Agents (short) S. Lazar, S. Kodeswaran, R. Varadharaj, D. Sidhu >>> Track B - Load balancing and caching A Distributed Internet Caching System (full) T. Tay, Y. Feng, M. Wijeysundera Load-Balanced Routing and Scheduling for Real-Time Traffic in Packet-Switched Networks (full) S. Bak, A. Cheng, J. Cobb, E. Leiss Performance Evaluation of New Methods of Automatic Redirection for Load Balancing of Apache Servers Distributed in the Internet (full) K. Suryanarayanan, K. Christensen >>> Track C - Traffic characterization Generalized Autoregressive Moving Average Modeling of the Bellcore Data (full) R. Ramachandran, V. R. Bhethanabotla High-Speed Calculation Method of the Hurst Parameter Based on Real Traffic (full) T. Hagiwara, H. Doi, H. Tode, H. Ikeda The Dependence of Internet User Traffic Characteristics on Access Speed (full) N. Vicari, S. Khler, J. Charzinski Nonlinear Time Series Model for VBR Video Traffic (full) J. L. Davis, K. Chandra, C. Thompson >>> Track D - High-speed switching and routing Scheduling Algorithms for A High-Speed Switch Supporting Real-Time Periodic Traffic Sources (full) J. Liu, L. Xia, R. Tsang, A. Pavan, D. H. C. Du IP Forwarding Engine with VC Merging in MPLS System (full) S. Kang, Y.-K. Lee High-Speed IP Forwarding Mechanism for an MPOA-Based Switched Router (short) J. A. Jun, H. C. Kim, K.-H. Lee, D. K. Sung A New Route Selection Approach Using Scaling Techniques: An Application to Hierarchical QoS-Based Routing (short) M. P. Saltouros, M. E. Markaki, A. K. Taskaris, M. E. Theologou, and I. S. Venieris ******************************************************************************* -- _____________________________________________________________________ Prof. Dr. Peter Martini University of Bonn Tel.: +49-228-73-4334 Institute of Computer Science IV Fax: +49-228-73-4571 Roemerstr. 164 E-mail: martini@cs.uni-bonn.de D-53117 Bonn, Germany http: www.cs.uni-bonn.de/IV/ From rem-conf Mon Sep 04 09:09:02 2000 From rem-conf-request@es.net Mon Sep 04 09:09:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Vylu-0006zc-00; Mon, 4 Sep 2000 09:06:58 -0700 Received: from mail.cox.smu.edu (amex.cox.smu.edu) [129.119.81.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Vylr-0006zQ-00; Mon, 4 Sep 2000 09:06:55 -0700 Received: from ci39026-a.mail.cox.smu.edu (ci39026-a.nash1.tn.home.com [24.15.71.131]) by amex.cox.smu.edu (8.9.3/8.9.3) with ESMTP id JAA03885; Mon, 4 Sep 2000 09:39:46 -0500 Message-Id: <4.3.0.20000904072143.00d72700@ctrvax.vanderbilt.edu> X-Sender: gavishb@mail.cox.smu.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 04 Sep 2000 07:48:17 -0500 To: (Recipient list suppressed) From: Bezalel Gavish Subject: 9th International Conference on Telecommunication Systems Conference - CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_247764807==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_247764807==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is a call for papers for the conference which will be held in Dallas on March 15-18, 2001. I will appreciate it very much if you will bring it to the attention of interested parties. Sincerely yours, Bezalel --=====================_247764807==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="TSM_CFPs 20011.txt" C A L L for P A P E R S 9th International Conference on Telecommunication Systems, Modeling and Analysis March 15-18, 2001 Dallas, Texas USA Sponsors: American Telecommunication Systems Management Association British Telecommunications plc Edwin L. Cox School of Business, Southern Methodist University IFIP WG 7.3 "Computer system modeling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems The University of Texas at Dallas The 9th International Conference on Telecommunication Systems - Modeling and Analysis will be held in Dallas, Texas, on March 15-18, 2001. The conference will build on the tradition of the earlier conferences. The general idea is to encourage informal interaction and exchanges of ideas by limiting the number of participants, concentrating on a few topics, and by presenting new problems and problem areas. The objective is to advance the state of the modeling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. Papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. Abstracts and papers should be submitted directly to a Program Committee member who will handle its review. It is expected that this will expedite the paper review process. Social and cultural activities will be included in the 2001 agenda. The conference will be held at the Edwin L. Cox School of Business, at Southern Methodist University, near Downtown Dallas. Listed below are some of the potential segments: -- Configuration of ATM Networks -- DSL and Cable Based Systems -- Internet and its Impact on Commerce -- Internet and Intranet -- Mobility and Nomadicity -- Multimedia modeling and analysis -- Pricing and Economic Analysis of Internet and E-commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low and Medium Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modeling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Network Reliability, Availability and Survivability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact -- Standards The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is, whenever possible, to limit the number of parallel sessions to three. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, and to enable participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the Downtown area. Members of the Program Committee include: Marco Ajmone Marsan, Politecnico di Torino, Italy Kemal Altinkemer, Purdue University, USA Suk-Gwon Chang, Hanyang University, Republic of Korea Jerome Chifflet, France Telecom, France Imrich Chlamtac, University of Texas at Dallas, USA Laurie G. Cuthbert, Queen Mary & Westfield College, UK Lou Dellaverson, Motorola, Radio Research Lab, USA Piet Demeester, University of Ghent - IMEC, Belgium Armin Eberlein, University of Calgary, Canada Mark Epstein, Qualcomm, Inc., USA Romano Fantacci, Universita di Firenze, Italy Bezalel Gavish (Chairman), Southern Methodist University, USA Luis Gouveia, Universidade de Lisboa, Portugal Horst W. Hamacher, University of Kaiserslautern, Germany Richard J. Harris, Royal Melbourne Institute of Technology, Australia Frank Huebner, Concert Technologies, USA Mladen Kos, University of Zagreb, Croatia Joakim Kalvenes, Southern Methodist University, USA Konosuke Kawashima, NTT Advanced Technology Corp., JAPAN Hans Kruse, Ohio University, USA Lorne G. Mason, Nanyang Technological University, Singapore Nikos E. Mastorakis, Hellenic Naval Academy, Greece Armin R. Mikler, University of North Texas, USA Sverrir Olafsson, BT Laboratories, UK June S. Park, The University of Iowa, USA Hasan Pirkul, The University of Texas at Dallas, USA Guy Pujolle, University of Versailles, France Dimitrios N. Serpanos, University of Patras, Greece Yutaka Takahashi, Kyoto University, Japan J. L. van den Berg, KPN Research, The Netherlands Stefan Voss, University of Braunschweig, Germany Lipo Wang, Nanyang Technological University, Singapore Lars C. Wolf, Darmstadt University of Technology, Germany Bill Yurcik, Illinois State University, USA Due to the limit on the number of participants, early conference registration is recommended. To ensure your participation, please use the following steps: 1. Send to a Program Committee member, by October 30, 2000, a paper (electronic submissions are preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one contribution is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts and papers. If you would like to organize a panel on a specific subject, please send the proposal to Bezalel Gavish. 2. Use the form at the end of this message to pre-register for the conference. Let us also know if you would like to have a formal duty during the conference such as: Session Chair, or Discussant. 3. You will be notified by December 15, 2000, which abstract(s)/paper(s) have been selected for the conference. Detailed instructions on how to prepare camera-ready copies will be sent to authors of accepted presentations. February 1, 2001, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. 4. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" journal. If you do not wish for your paper to be submitted for publication consideration in the "Telecommunication Systems" journal, please specify it in the cover letter of your submission. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Professor Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to a Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ----------------------------------------------------------------------- Cut Here ----------------------------------------------------------------------- Ninth International Conference on Telecommunication Systems Modeling and Analysis REGISTRATION FORM Dates: March 15, 2001 (afternoon) to March 18, 2001 Date: ______________ Name: ________________________________________ Title: _____________________ Affiliation: ____________________________________________________________ Address: ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Phone: ____________________________ FAX: ____________________ E-mail: ____________________________________________________________________ Potential Title of Paper(s): _______________________________________________ ____________________________________________________________________________ I would like to Volunteer as Comments A Session Chair: Yes No ____________________________________ A Discussant: Yes No ____________________________________ Organize a Session: Yes No ____________________________________ ____________________________________ REGISTRATION RATES and DEADLINES: (Included in the registration fee are: Conference proceedings, a reception, two dinners, two lunches, coffee breaks, and cultural events.) Last Applicable Academic Industry Corporate Date Rate Rate Rate --------------- -------- -------- -------- 1. Pre-registration Until Dec. 31, 2000 $ 430 $ 600 $1,500 2. Registration Until Feb. 1, 2001 $ 530 $ 750 $1,500 3. On Site Registration After Feb. 1, 2001 $ 630 $ 850 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association". Please mark an "X" in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I do not wish to become an ATSMA member. Mail your registration form and check to: Ms. Dru Lundeng ATSMA, Inc. Edwin L. Cox School of Business Southern Methodist University P.O. Box 750333 Dallas, TX 75252, USA Checks should be made payable to: ATSMA, Inc., Ninth Telecommunication Conference Refund Policy: Half refund, for requests received by January 15, 2001. No refund after January 15, 2001. --=====================_247764807==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Professor Bezalel Gavish Eugene J. and Ruth F. Constantin Distinguished Chair in Business Chairman of the ITOM Department Edwin L. Cox School of Business Southern Methodist University P.O. Box 750333 Dallas, TX 75275-0333 E-mail: gavishb@mail.cox.smu.edu Tel: Office (214) 768-8258 FAX (214) 768-8812 Assistant (214) 768-8256 Home (615) 370-0813 --=====================_247764807==_-- From rem-conf Tue Sep 05 09:53:36 2000 From rem-conf-request@es.net Tue Sep 05 09:53:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WLmy-0005qu-00; Tue, 5 Sep 2000 09:41:36 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13WLmx-0005qj-00; Tue, 5 Sep 2000 09:41:35 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 5 Sep 2000 11:39:33 UT Subject: Re: Fwd: Re: Define a unicast RTP session. To: Jonathan Rosenberg Cc: "Strahm, Bill" , Mark Baugher , rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Tue, 5 Sep 2000 11:40:55 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 09/05/2000 12:41:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Jonathan, Whether there are one or two sessions is not completely academic, which is close to the subject of this thread. The point becomes concrete under operation of the RTP MIB. I think the SIP folks would populate the MIB session table differently than the H-media folks. The former would put two entries in the table where the latter would put one. Vince Virgilio Jonathan Rosenberg on 09/01/2000 10:06:22 PM To: Vincent_Virgilio@nmss.com cc: "Strahm, Bill" , Mark Baugher , rem-conf@es.net Subject: Re: Fwd: Re: Define a unicast RTP session. Vincent_Virgilio@nmss.com wrote: > > I agree with you that, under RFC 1889, an SDP invite and its OK will create > two sessions if the destination ports differ. But if they don't (can this > be done predictably?), there should be (is) one session. Later drafts of > RFC 1889 do specify that the destination ports in a session may differ, and > thus might eventually cause trouble for SIP/SDP if its notion of a session > changes, if there's not trouble now. There is no trouble now. Whether you call it one or two sessions in any case seems completely academic. The operation in either case, as I can tell, is the same. > Then it might become difficult for > SIP/SDP to correlate the two directions of flow (is this necessary?). Sorry? How do you arrive at this conclusion? As the caller, I choose the ports I will receive media on, and I am told the ports to send media two. They are correlated since they are part of the same SIP call. Its been working in SIP devices for a while. -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: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Sep 05 14:28:14 2000 From rem-conf-request@es.net Tue Sep 05 14:28:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WQBI-0001q3-00; Tue, 5 Sep 2000 14:23:00 -0700 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WQBH-0001ok-00; Tue, 5 Sep 2000 14:22:59 -0700 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id OAA24461 for ; Tue, 5 Sep 2000 14:21:57 -0700 (MST) Posted-Date: Tue, 5 Sep 2000 14:21:57 -0700 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id OAA12931 for ; Tue, 5 Sep 2000 14:21:18 -0700 (MST) Received: from agcs.com ([130.131.26.31]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAAE03; Tue, 5 Sep 2000 14:21:44 -0700 Message-ID: <39B563EB.E7999097@agcs.com> Date: Tue, 05 Sep 2000 14:21:48 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: rem-conf Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Flemming, Thanks for the heads-up. The implementation note conflicts with what is stated in RFC 2833, by the way. RFC 2833 says the following: Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL. I guess I'm wondering why the implementation notes say that the 0 thru 15 numbers MUST be declared when the RFC says declaring them is optional. Also, for my information, do the implementation notes override the contents of the RFC? Regards, Rex Coldren Flemming Andreasen wrote: > Folks > > Just wanted to draw all RFC 2833 interested parties to the following > implementation note (http://www.cs.columbia.edu/~hgs/rtp/payload.html): > > "Implementations can support events 0 through 15 (DTMF) by simply > ignoring the packets, but MUST declare all event numbers that are > meaningful to it in the fmtp parameter, including 0 through 15." > > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems From rem-conf Tue Sep 05 15:28:17 2000 From rem-conf-request@es.net Tue Sep 05 15:28:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WR9R-0003TC-00; Tue, 5 Sep 2000 15:25:09 -0700 Received: from mailman.cisco.com [171.68.225.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WR9Q-0003Rb-00; Tue, 5 Sep 2000 15:25:08 -0700 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA09327; Tue, 5 Sep 2000 15:23:25 -0700 (PDT) Message-ID: <39B57367.1FCB5071@cisco.com> Date: Tue, 05 Sep 2000 18:27:51 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: rem-conf , Henning Schulzrinne Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> <39B563EB.E7999097@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Rex Coldren wrote: > Flemming, > Thanks for the heads-up. The implementation note conflicts with what > is stated in RFC 2833, by the way. I guess that depends on how you interpret the words. > RFC 2833 says the following: > > Since all implementations MUST be able to receive events 0 through > 15, listing these events in the a=fmtp line is OPTIONAL. > > I guess I'm wondering why the implementation notes say that the 0 thru > 15 numbers MUST be declared when the RFC says declaring them is > optional. I should probably let Henning answer, but the idea is to not require all RFC 2833 implementations to implement DTMF support. The reason is, that RFC 2833 is a general and very useful mechanism, and requiring all use of it to include support for DTMF is overly restrictive. The note provides a way out of that and I believe will be included in RFC 2833 when it progresses to Draft Standard. > Also, for my information, do the implementation notes override > the contents of the RFC? They clarify them at least. -- Flemming > > > Regards, > Rex Coldren > > Flemming Andreasen wrote: > > > Folks > > > > Just wanted to draw all RFC 2833 interested parties to the following > > implementation note (http://www.cs.columbia.edu/~hgs/rtp/payload.html): > > > > "Implementations can support events 0 through 15 (DTMF) by simply > > ignoring the packets, but MUST declare all event numbers that are > > meaningful to it in the fmtp parameter, including 0 through 15." > > > > Thanks > > > > Flemming > > > > -- > > Flemming Andreasen > > Cisco Systems -- Flemming Andreasen Cisco Systems From rem-conf Tue Sep 05 17:30:11 2000 From rem-conf-request@es.net Tue Sep 05 17:30:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WT3n-0005Zg-00; Tue, 5 Sep 2000 17:27:27 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WT3l-0005ZW-00; Tue, 5 Sep 2000 17:27:25 -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 UAA10514; Tue, 5 Sep 2000 20:27:16 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39B58F64.EE30FEAF@cs.columbia.edu> Date: Tue, 05 Sep 2000 20:27:16 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: coldrenr@agcs.com, rem-conf Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> <39B563EB.E7999097@agcs.com> <39B57367.1FCB5071@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Flemming Andreasen wrote: > > Rex Coldren wrote: > > > Flemming, > > Thanks for the heads-up. The implementation note conflicts with what > > is stated in RFC 2833, by the way. > > I guess that depends on how you interpret the words. > > > RFC 2833 says the following: > > > > Since all implementations MUST be able to receive events 0 through > > 15, listing these events in the a=fmtp line is OPTIONAL. > > > > I guess I'm wondering why the implementation notes say that the 0 thru > > 15 numbers MUST be declared when the RFC says declaring them is > > optional. > > I should probably let Henning answer, but the idea is to not require all RFC > 2833 implementations to implement DTMF support. The reason is, that RFC 2833 > is a general and very useful mechanism, and requiring all use of it to > include support for DTMF is overly restrictive. The note provides a way out > of that and I believe will be included in RFC 2833 when it progresses to > Draft Standard. It is also backward compatible for now, in that declaring support is currently redundant. Practically speaking, with DTMF, support is also a rather vague term. Support could mean anything short of core dumping. If the other side silently swallows type 0-15, is that support? Presumably, this would only occur in real systems if DTMF doesn't make sense. Maybe it would be helpful is somebody could provide examples of RFC 2833 systems that would have no use for DTMF. If you're building a system that logically should support DTMF, but doesn't, having the protocol police chase after you is probably not your major concern. > > > Also, for my information, do the implementation notes override > > the contents of the RFC? > > They clarify them at least. No, they obviously don't override the RFC. However, RFC 2026 says A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Thus, implementors can't completely rely on every word staying the same. The implementation note is meant to tell implementors "indicate DTMF support now explicitly as it will prevent problems later". A typical way of resolving this would be to ask around, at Draft time, whether any known implementation is having problems with that change. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Sep 05 19:29:07 2000 From rem-conf-request@es.net Tue Sep 05 19:29:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WUtt-0007LX-00; Tue, 5 Sep 2000 19:25:21 -0700 Received: from mcigate1.mci.mei.co.jp [210.146.208.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WUtr-0007LJ-00; Tue, 5 Sep 2000 19:25:19 -0700 Received: from postman.mci.mei.co.jp (postman.mci.mei.co.jp [133.185.181.250]) by mcigate1.mci.mei.co.jp (/) with SMTP id LAA23647; Wed, 6 Sep 2000 11:24:11 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.9.1/3.7Wpl2:mcihub1:99092810) id LAA24202; Wed, 6 Sep 2000 11:24:10 +0900 (JST) Received: from Henry4 by gaugin.telecom.mci.mei.co.jp (8.9.1/3.7W-TELECOM) with SMTP id LAA21360; Wed, 6 Sep 2000 11:23:22 +0900 (JST) Message-ID: <00f001c017a9$28852460$a3d2b785@telecom.mci.mei.co.jp> From: "Koji Imura" To: , "Colin Perkins" Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <200008251549.QAA01356@purple.cs.ucl.ac.uk> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Wed, 6 Sep 2000 11:21:24 +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, I reviewed the draft and had a question. In the section 3.1, there is a description about the marker bit and time stamp for the MPEG-4 visual. According to this description, it is possible to include some VOPs in one RTP packet. In such a case, the only time stamp for first VOP is included in the RTP header, but there is no time information for rest of VOPs in the same RTP packet. The temporal interval between VOPs is variable in MPEG-4 visual So it is difficult to estimate the time stamp of the other VOPs. If there is a system that presentation/composition time is decided by the RTP time stamp, how do the system estimate the time stamp of rest of the VOPs? Best Regards, Koji -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Koji Imura(Koji.Imura@yrp.mci.mei.co.jp) Matsushita Communication Industrial Phone:+81-468-40-5684 Fax: +81-468-40-5184 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----- Original Message ----- From: Colin Perkins To: Cc: <4on2andIP-sys@advent.ee.columbia.edu> Sent: Saturday, August 26, 2000 12:49 AM Subject: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > To the IETF AVT working group and the ad-hoc group on transport of MPEG4-on-IP: > > The IETF Audio/Video Transport working group has received a request to publish > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-03.txt > the "RTP payload format for MPEG-4 Audio/Visual streams" as a proposed standard. > > Accordingly, this message starts a two week working group last call for comments > on this draft. All comments should be sent to the AVT working group mailing list > by 8th September 2000. At this time we will make our decision > whether or not to request IESG approval for publication, based on the consensus > of replies. > > We particularly value input from the MPEG committee as to technical correctness > and the appropriate nature of this specification. It is our intent that this > payload format is complementary to the ongoing work in MPEG defining a general > framework for transport of the MPEG-4 Systems environment. If this intent is not > reflected in the draft, we value comment with detailed and specific suggestions > for change. > > Note that we had originally planned to issue this working group last call after > the forthcoming MPEG meeting. However, time constraints imposed by the ITU-T > schedule for publication of the next version of H.323 require that we issue this > last call early. We hope that this will not cause undue problems, and look forward > to your input. > > Thanks, > Colin Perkins (IETF AVT co-chair) > > From rem-conf Tue Sep 05 19:41:11 2000 From rem-conf-request@es.net Tue Sep 05 19:41:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WV70-0000BQ-00; Tue, 5 Sep 2000 19:38:54 -0700 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WV6y-0000Am-00; Tue, 5 Sep 2000 19:38:52 -0700 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id TAA08061 for ; Tue, 5 Sep 2000 19:37:51 -0700 (MST) Posted-Date: Tue, 5 Sep 2000 19:37:51 -0700 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id TAA25740 for ; Tue, 5 Sep 2000 19:37:13 -0700 (MST) Received: from agcs.com ([130.131.56.30]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA4BDB; Tue, 5 Sep 2000 19:37:37 -0700 Message-ID: <39B5ADED.7B2DC541@agcs.com> Date: Tue, 05 Sep 2000 19:37:34 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Flemming Andreasen , rem-conf Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> <39B563EB.E7999097@agcs.com> <39B57367.1FCB5071@cisco.com> <39B58F64.EE30FEAF@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 Flemming, Henning, I agree with both of you. DTMF support should not be required. Realistically, there will likely be zero implementations that will implement all of the possible combinations of events and tones. So how do we deal with trying to push RFC 2833 toward Draft Standard when none of the implementations support the full set of capabilities? Do the IETF rules for deprecating options require that all of the interoperable implementations support option sets that are a union or an intersection of working options of the common group (forgive my ignorance of the rules; RFC 2026 didn't help me much here)? I am hoping that a simple intersecting set is the answer. Otherwise RFC 2833 will disintegrate. Thoughts? . Cheers, Rex Coldren Henning Schulzrinne wrote: > Flemming Andreasen wrote: > > > > Rex Coldren wrote: > > > > > Flemming, > > > Thanks for the heads-up. The implementation note conflicts with what > > > is stated in RFC 2833, by the way. > > > > I guess that depends on how you interpret the words. > > > > > RFC 2833 says the following: > > > > > > Since all implementations MUST be able to receive events 0 through > > > 15, listing these events in the a=fmtp line is OPTIONAL. > > > > > > I guess I'm wondering why the implementation notes say that the 0 thru > > > 15 numbers MUST be declared when the RFC says declaring them is > > > optional. > > > > I should probably let Henning answer, but the idea is to not require all RFC > > 2833 implementations to implement DTMF support. The reason is, that RFC 2833 > > is a general and very useful mechanism, and requiring all use of it to > > include support for DTMF is overly restrictive. The note provides a way out > > of that and I believe will be included in RFC 2833 when it progresses to > > Draft Standard. > > It is also backward compatible for now, in that declaring support is > currently redundant. > > Practically speaking, with DTMF, support is also a rather vague term. > Support could mean anything short of core dumping. If the other side > silently swallows type 0-15, is that support? Presumably, this would > only occur in real systems if DTMF doesn't make sense. Maybe it would be > helpful is somebody could provide examples of RFC 2833 systems that > would have no use for DTMF. If you're building a system that logically > should support DTMF, but doesn't, having the protocol police chase after > you is probably not your major concern. > > > > > > Also, for my information, do the implementation notes override > > > the contents of the RFC? > > > > They clarify them at least. > > No, they obviously don't override the RFC. However, RFC 2026 says > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Thus, implementors can't completely rely on every word staying the same. > The implementation note is meant to tell implementors "indicate DTMF > support now explicitly as it will prevent problems later". > > A typical way of resolving this would be to ask around, at Draft time, > whether any known implementation is having problems with that change. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Sep 05 19:59:38 2000 From rem-conf-request@es.net Tue Sep 05 19:59:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WVPm-0001U8-00; Tue, 5 Sep 2000 19:58:18 -0700 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WVPk-0001Rf-00; Tue, 5 Sep 2000 19:58:16 -0700 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id TAA08875 for ; Tue, 5 Sep 2000 19:57:15 -0700 (MST) Posted-Date: Tue, 5 Sep 2000 19:57:15 -0700 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id TAA26497 for ; Tue, 5 Sep 2000 19:56:37 -0700 (MST) Received: from agcs.com ([130.131.56.30]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA4E0E; Tue, 5 Sep 2000 19:57:01 -0700 Message-ID: <39B5B278.A59520E4@agcs.com> Date: Tue, 05 Sep 2000 19:56:56 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne , Flemming Andreasen , rem-conf Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> <39B563EB.E7999097@agcs.com> <39B57367.1FCB5071@cisco.com> <39B58F64.EE30FEAF@cs.columbia.edu> <39B5ADED.7B2DC541@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ooops. I meant that I hope the union of options is what is required. Sorry for the slip... Rex Coldren wrote: > Flemming, Henning, > > I agree with both of you. DTMF support should not be required. Realistically, > there will likely be zero implementations that will implement all of the possible > combinations of events and tones. So how do we deal with trying to push RFC > 2833 toward Draft Standard when none of the implementations support the full > set of capabilities? Do the IETF rules for deprecating options require that all of > the interoperable implementations support option sets that are a union or an > intersection of working options of the common group (forgive my ignorance of > the rules; RFC 2026 didn't help me much here)? I am hoping that a simple > intersecting set is the answer. Otherwise RFC 2833 will disintegrate. Thoughts? > . > Cheers, > Rex Coldren > > Henning Schulzrinne wrote: > > > Flemming Andreasen wrote: > > > > > > Rex Coldren wrote: > > > > > > > Flemming, > > > > Thanks for the heads-up. The implementation note conflicts with what > > > > is stated in RFC 2833, by the way. > > > > > > I guess that depends on how you interpret the words. > > > > > > > RFC 2833 says the following: > > > > > > > > Since all implementations MUST be able to receive events 0 through > > > > 15, listing these events in the a=fmtp line is OPTIONAL. > > > > > > > > I guess I'm wondering why the implementation notes say that the 0 thru > > > > 15 numbers MUST be declared when the RFC says declaring them is > > > > optional. > > > > > > I should probably let Henning answer, but the idea is to not require all RFC > > > 2833 implementations to implement DTMF support. The reason is, that RFC 2833 > > > is a general and very useful mechanism, and requiring all use of it to > > > include support for DTMF is overly restrictive. The note provides a way out > > > of that and I believe will be included in RFC 2833 when it progresses to > > > Draft Standard. > > > > It is also backward compatible for now, in that declaring support is > > currently redundant. > > > > Practically speaking, with DTMF, support is also a rather vague term. > > Support could mean anything short of core dumping. If the other side > > silently swallows type 0-15, is that support? Presumably, this would > > only occur in real systems if DTMF doesn't make sense. Maybe it would be > > helpful is somebody could provide examples of RFC 2833 systems that > > would have no use for DTMF. If you're building a system that logically > > should support DTMF, but doesn't, having the protocol police chase after > > you is probably not your major concern. > > > > > > > > > Also, for my information, do the implementation notes override > > > > the contents of the RFC? > > > > > > They clarify them at least. > > > > No, they obviously don't override the RFC. However, RFC 2026 says > > > > A Proposed Standard specification is generally stable, has resolved > > known design choices, is believed to be well-understood, has received > > significant community review, and appears to enjoy enough community > > interest to be considered valuable. However, further experience > > might result in a change or even retraction of the specification > > before it advances. > > > > Thus, implementors can't completely rely on every word staying the same. > > The implementation note is meant to tell implementors "indicate DTMF > > support now explicitly as it will prevent problems later". > > > > A typical way of resolving this would be to ask around, at Draft time, > > whether any known implementation is having problems with that change. > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Sep 06 04:39:56 2000 From rem-conf-request@es.net Wed Sep 06 04:39:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WdTR-0007GT-00; Wed, 6 Sep 2000 04:34:37 -0700 Received: from utrhcs.cs.utwente.nl [130.89.10.247] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WdTP-0007GJ-00; Wed, 6 Sep 2000 04:34:35 -0700 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id NAA22066; Wed, 6 Sep 2000 13:34:23 +0200 (MET DST) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id NAA01061; Wed, 6 Sep 2000 13:28:40 +0200 (MET DST) Message-ID: <39B62A68.7197AF8B@cs.utwente.nl> Date: Wed, 06 Sep 2000 13:28:40 +0200 From: Clever Ricardo Guareis de Farias Organization: CTIT - Centre for Telematics and Information Technology X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: IDMS 2000: Call for Posters and Demonstrators Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Our apologies if you receive multiple copies of this Call] Call for Posters and Demonstrators IDMS 2000 7th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services CTIT/Univ. of Twente, Enschede, the Netherlands October 17-20, 2000 http://www.ctit.utwente.nl/Docs/news/idms_2000.htm In cooperation with ACM SIGCOMM and SIGMM Sponsored by KPN Research, Lucent Technologies and Philips The goal of the IDMS series of workshops is to bring together researchers, developers, and practitioners from academia and industry; and to provide a forum for discussion, presentation, and exploration of technologies and advances in the broad field of interactive distributed multimedia systems and telecommunication services. Topics covered in IDMS workshops range from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. IDMS 2000 consists of a full day of tutorials, a three days technical program, and demonstrations during the workshop. For the latter, we solicit proposals for posters and demonstrators associated with the scope of the workshop. Posters and demo's offer oppertunities to researchers and developers to present and discuss their work in progress and practical results through more informal interaction. Posters and demo's will be selected based on their suitability for the workshop and their technical feasibility. Posters should be presentable on 1 or 2 A0 sheets; demo proposals should indicate which technical infrastructure facilities are required. Selected posters and demo's will be announced on the IDMS website, together with short descriptions, if provided. Proposals can be sent to: Richard Bults, bults@ctit.utwente.nl Deadline for receipt of proposals: October 2nd, 2000 From rem-conf Wed Sep 06 08:39:03 2000 From rem-conf-request@es.net Wed Sep 06 08:39:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WhCu-0002tV-00; Wed, 6 Sep 2000 08:33:48 -0700 Received: from atlas.globe.nl [194.151.120.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WhCf-0002sJ-00; Wed, 6 Sep 2000 08:33:33 -0700 Received: from medi.nl (isdn.medi.nl [194.151.120.180]) by atlas.globe.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SMNBZCPV; Wed, 6 Sep 2000 17:32:03 +0200 Received: from gnr.net by medi.nl (Lotus SMTP MTA v1.05 (274.9 11-27-1996)) with SMTP id C1256952.0056981D; Sun, 6 Sep 1970 17:46:15 +0200 To: jo333_4@lawerence-lca.co.uk Bcc: relph@sgi.com, relsqi@klvwinvazrpq.yu, rem-conf-request@es.net, rem-conf@es.net, rem@cocc.edu, remail@avignon.hypereality.co.uk, remail@c2.org, remail@entropy.linet.org, remail@extropia.wimsey.com, remail@magusnet.com, remail@tamaix.tamu.edu, remail@tamsum.tamu.edu From: Subject: Inspired Internet Business Opportunity! content-length: 21121 Message-Id: Date: Wed, 6 Sep 2000 08:33:33 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Greetings, Have you ever asked yourself, "If only I could find an easier way to make a higher income" and "If I had more money, I could spend more time with my family, and less time at work" and "I sure could use more money so I could pay off my bills once and for all" and "I would love to get involved in a business which will generate money while I am at work." Please, please, print this off and read thoroughly. Be sure you don't miss any of the points outlined. Then put it down and read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don't believe this program will work for you, send it to 10-20 of your closest friends (in which you deeply trust), ask them what they think? This really works! Have faith, don't miss this opportunity, get involved also, it will work for you as it does for us!!! Read On!!!!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program in the USA recently dedicated 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 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 have been truly remarkable. So many people are now participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, it has been very exciting. You will understand only if you get involved! The Entire Plan is Here Below..... ****Print This Now for Future Reference**** Read it often to fully understand how simple and easy it works!!! If you would like to make at least... $50,000 US in less than 90 Days! If not, forward this to someone who would like to make this kind of money........ It works (like designed) but only for those who follow it to the letter!! Please read this program... Then read it again!!$$$$$$$$$$$$$$$$$ This is a Legitimate, Legal, Money Making Opportunity!! It does not require you to come into contact with people or make or take any telephone calls. Just follow the instructions and you will make money. This simplified E-mail marketing program works perfectly 100% EVERY TIME!!! Hello, my name is Johnathon Rourke, I'm from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some considerable thought and study to it. Two years ago, the Corporation I worked 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 more against my home to support my family and struggling business. At that moment something significant happened in my life. I am writing this reference to share the experience in hope that this could change your life... Forever!!! Financially $$$$!!! In mid-December, I received this program in my E-mail. Six months 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 worked. As 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 MACHINE I could start immediately without any debt. 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 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 for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. 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 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 had received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car! Please take your time to read this plan, 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 0f 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 costor no 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, Johnathan 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 was not 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 tellyou what happened to the employment rate.... because many of you know fromfirst hand experience. There were more failures and bankruptcies than everbefore.. The middle class was vanishing. Those who knew what they were doinginvested wisely and moved up. Those who did not, including those who never had anything to save or to 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 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 customersyou 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 DO IT !!!! BEFORE YOU delete this program from your in box, 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 doubt 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 DOLLARS $$$$$ 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 care-fully. This is not a chain letter, but a perfectly legal money making business. 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order filling by E-mail. The product is informational and instructional material; keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information high-way, the wave of the future! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 US each). They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report#1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major searchengines to locate hundreds of bulk email service companies (search for "bulk email") and have them send 25,000 - 50,000 e-mail for you about $49 +. (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn't this about as easy as it gets?. By the way there are over 50 MILLION email addresses with millions more joining the Internet each year so don't worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio and TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for a pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP # 1 ORDER THE FOUR REPORTS 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 US 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! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000's of people who will order them from you. STEP # 2 ADD YOUR MAILING ADDRESS TO THIS LETTER A. Look below for the listing of the four reports. B. After you've ordered the four reports delete the name and address under REPORT # 4. This person has made it through the cycle. C. Move the name and address under REPORT # 3 down to REPORT # 4. D. Move the name and address under REPORT # 2 down to REPORT # 3. E. Move the name and address under REPORT # 1 down to REPORT # 2. F. Insert your name and address in the REPORT # 1 position Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY. STEP # 3 SAVE THIS ON COMPUTER Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire E-mail to send by E-mail to prospects. Report # 1 will tell you how to download bulk e-mail software and e-mail addresses so you can send it out to thousands of people while you sleep! Remember that 50,000 + new people are joining the internet every month.Your cost to participate in this is practically nothing (surely you can afford $20 US and initial bulk mailing cost). You obviously already have a computer and 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 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 hundreds of thousands of programs instead of 2,000 (why stop at 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% respond 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% respond to that is 10,000 orders for... REPORT # 4. That's 10,000 $5 US 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 2,000 people you email to will do absolutely nothing and trash this program! Dare to think for a moment what would happen if everyone, or half sent out 100,000 programs instead of 2,000, believe me, many people will do just that and more! METHOD # 2: Placing free Ads on the Internet. Advertising on the Internet is very, very inexpensive, as there are HUNDREDS of FREE places to advertise. Lets 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 in your organization gets only 10 downline members, just look at how this small number accumulates to achieve the STAGGERING results below... 1st Level-- Your first 10 send you $5 = $50 2nd Level-- 10 Members from those 10 ($5X100) = $500 3rd Level-- 10 Members from those 100 ($5X1000) = $5,000 4th Level-- 10 Members from those 1,000 ($5X10,000) = $50,000 $$$$$$$ THIS TOTALS = $55,550 $$$$$$$ AMAZING ISN'T IT?? 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 and many will continue to work this program, WITH YOUR NAME ON THEM FOR YEARS!! THINK ABOUT IT! People are going to get details about this plan from you 'or' someone else...the question is... Don't you want your name to be on the Emails they will send out?? *** DON'T MISS OUT!!! *** JUST TRY IT ONCE!!! *** SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!! ALWAYS PROVIDE SAME-DAY SERVICE ON ORDERS! This will guarantee that the Email THEY send out with your name and address on it will be prompt because they can't advertise until they receive the REPORT! GET STARTED TO-DAY: PLACE YOUR ORDER FOR THE FOUR REPORTS...NOW!! NOTE ALWAYS SEND $5 CASH (US CURRENCY) FOR EACH REPORT. CHEQUES ARE 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 FROM... CAROL ANDERSON 5451 PLEASANT VIEW LANE FREELAND, WA 98249 USA. PLEASE NOTE...I and every member below will work for you also. Try us! REPORT # 2 "The Insider's Guide to Sending Bulk email. ORDER FROM... HARRY FERNTHEIL 5626 WOODRIDGE STREET HUNTSVILLE, AL 35802 USA. REPORT # 3 "The Secrets to Multilevel Marketing on the Internet". ORDER FROM... JOCA VAN DEN BOS 1191 PUKAKI STREET ROTORUA, 3201 NEW ZEALAND. REPORT # 4 "How to become a Millionaire Utilizing the Power of Multilevel Marketing and the Internet". ORDER FROM... LANCE DENTON 100 WILDWOOD RD. ROCKPORT, TX 78382 USA. *******TIPS FOR SUCCESS******* TREAT THIS AS YOUR BUSINESS!! Be prompt, professional, follow the directions accurately. Send for the four reports 'IMMEDIATELY' so you 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!! If you follow the instructions exactly-results WILL FOLLOW. $$$$. ******* 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 weeks later you should receive at least 100 or more 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, 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. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again!! THERE IS NO LIMIT TO THE INCOME YOU WILL GENERATE FROM THIS BUSINESS! Before you make your decision as to weather or not to participate in this program. Please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?? If the answer is no, then please look at the following facts about this super simple MLM program: 1~ No face to face selling, No meetings, No Inventory, No telephone calls, No big cost to start, Nothing to learn, No skills needed! (Surely you know how to send an e-mail?). 2~ No equipment to buy- you already have a computer and Internet connection- so you have everything you need to fill orders! 3~ You are selling a PRODUCT which does NOT COST YOU ANYTHING TO PRODUCE OR SHIP! E-mailing copies of the Reports is FREE! 4~ All of your customers pay you in CASH! This program will change your LIFE FOREVER! Look at the potential for you to be able to quit your job, and live the life of LUXURY that you could only dream about before! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely business, from home with no overhead! $$$ FINALLY MAKE SOME DREAMS COME TRUE !! $$$ ACT NOW!! Take your first step towards achieving financial independence. Order the REPORTS and follow the PROGRAM outlined above. SUCCESS WILL BE YOUR REWARD !!! 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 local office of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via the telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated or 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. Under Bill 1618 TITLE III. This is a ONE TIME ONLY e-mail transmission. No request for removal is necessary. From rem-conf Wed Sep 06 10:07:55 2000 From rem-conf-request@es.net Wed Sep 06 10:07:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WiXB-0004z6-00; Wed, 6 Sep 2000 09:58:49 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WiXA-0004yw-00; Wed, 6 Sep 2000 09:58:48 -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 MAA00617; Wed, 6 Sep 2000 12:58:33 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39B677B8.80AE4F9B@cs.columbia.edu> Date: Wed, 06 Sep 2000 12:58:32 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: Flemming Andreasen , rem-conf Subject: Re: Optional DTMF support in RFC 2833 References: <39A2C95B.290E8189@cisco.com> <39B563EB.E7999097@agcs.com> <39B57367.1FCB5071@cisco.com> <39B58F64.EE30FEAF@cs.columbia.edu> <39B5ADED.7B2DC541@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Rex Coldren wrote: > > Flemming, Henning, > > I agree with both of you. DTMF support should not be required. Realistically, > there will likely be zero implementations that will implement all of the possible > combinations of events and tones. So how do we deal with trying to push RFC > 2833 toward Draft Standard when none of the implementations support the full > set of capabilities? Do the IETF rules for deprecating options require that all of > the interoperable implementations support option sets that are a union or an > intersection of working options of the common group (forgive my ignorance of > the rules; RFC 2026 didn't help me much here)? I am hoping that a simple > intersecting set is the answer. Otherwise RFC 2833 will disintegrate. Thoughts? > . Any one feature (or event, for 2833) will need to be supported by two independent implementations. It is not necessary that two implementations support all events. In the case of simple constants such as the events, it's also not exactly clear that it makes sense to remove one event that currently may not have two implementations. After all, somebody could just go right back to IANA and register that number. (With IANA, there is no two-implementations requirement.) Thus, I'd suggest that we find a volunteer with active implementation interest in RFC 2833 to gather implementation reports on features and events. This list (and the list of implementations) does not have to be public, in case that's a concern. After that's done, we can take a look at the problem cases of events that have zero or one implementations and see whether this is a matter of "useful, but just not there yet" or "not that useful after all". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Sep 06 10:27:39 2000 From rem-conf-request@es.net Wed Sep 06 10:27:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WiwN-00065H-00; Wed, 6 Sep 2000 10:24:51 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WiwL-000657-00; Wed, 6 Sep 2000 10:24:50 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA15412; Wed, 6 Sep 2000 13:25:08 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA05511; Wed, 6 Sep 2000 22:24:46 +0500 Message-Id: <200009061724.WAA05511@hafez.east.isi.edu> To: coldrenr@agcs.com cc: Henning Schulzrinne , Flemming Andreasen , rem-conf Subject: Re: Optional DTMF support in RFC 2833 In-Reply-To: Your message of "Tue, 05 Sep 2000 19:37:34 PDT." <39B5ADED.7B2DC541@agcs.com> Date: Wed, 06 Sep 2000 13:24:46 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Rex Coldren writes: >Flemming, Henning, > >I agree with both of you. DTMF support should not be required. Realistically, >there will likely be zero implementations that will implement all of the possible >combinations of events and tones. So how do we deal with trying to push RFC >2833 toward Draft Standard when none of the implementations support the full >set of capabilities? Do the IETF rules for deprecating options require that all of >the interoperable implementations support option sets that are a union or an >intersection of working options of the common group (forgive my ignorance of >the rules; RFC 2026 didn't help me much here)? I am hoping that a simple >intersecting set is the answer. Otherwise RFC 2833 will disintegrate. Thoughts? The rules require that at least two independent interoperable implementations exist for each feature. There is no requirement that a particular implementation support every feature, so long as each feature is supported by some implementations. Colin From rem-conf Wed Sep 06 10:29:05 2000 From rem-conf-request@es.net Wed Sep 06 10:29:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WiyS-00066M-00; Wed, 6 Sep 2000 10:27:00 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WiyQ-00066C-00; Wed, 6 Sep 2000 10:26:58 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA15448; Wed, 6 Sep 2000 13:27:17 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA05566; Wed, 6 Sep 2000 22:26:55 +0500 Message-Id: <200009061726.WAA05566@hafez.east.isi.edu> To: Henning Schulzrinne cc: coldrenr@agcs.com, Flemming Andreasen , rem-conf Subject: Re: Optional DTMF support in RFC 2833 In-Reply-To: Your message of "Wed, 06 Sep 2000 12:58:32 EDT." <39B677B8.80AE4F9B@cs.columbia.edu> Date: Wed, 06 Sep 2000 13:26:55 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >Rex Coldren wrote: >> >> Flemming, Henning, >> >> I agree with both of you. DTMF support should not be required. Realistically, >> there will likely be zero implementations that will implement all of the possible >> combinations of events and tones. So how do we deal with trying to push RFC >> 2833 toward Draft Standard when none of the implementations support the full >> set of capabilities? Do the IETF rules for deprecating options require that all of >> the interoperable implementations support option sets that are a union or an >> intersection of working options of the common group (forgive my ignorance of >> the rules; RFC 2026 didn't help me much here)? I am hoping that a simple >> intersecting set is the answer. Otherwise RFC 2833 will disintegrate. Thoughts? >> . > >Any one feature (or event, for 2833) will need to be supported by two >independent implementations. It is not necessary that two >implementations support all events. In the case of simple constants such >as the events, it's also not exactly clear that it makes sense to remove >one event that currently may not have two implementations. After all, >somebody could just go right back to IANA and register that number. >(With IANA, there is no two-implementations requirement.) > >Thus, I'd suggest that we find a volunteer with active implementation >interest in RFC 2833 to gather implementation reports on features and >events. This list (and the list of implementations) does not have to be >public, in case that's a concern. > >After that's done, we can take a look at the problem cases of events >that have zero or one implementations and see whether this is a matter >of "useful, but just not there yet" or "not that useful after all". Although note that this can't go to draft standard until RTP goes to draft, which means we need to complete the RTP interop first..... Colin From rem-conf Wed Sep 06 20:13:26 2000 From rem-conf-request@es.net Wed Sep 06 20:13:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ws1N-0006xi-00; Wed, 6 Sep 2000 20:06:37 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13Ws1J-0006xF-00; Wed, 6 Sep 2000 20:06:33 -0700 Received: from host212-140-107-168.btinternet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 7 Sep 2000 04:06:22 +0100 Message-Id: <4.1.20000907034422.009995e0@pop.cs.ucl.ac.uk> Message-Id: <4.1.20000907034422.009995e0@pop.cs.ucl.ac.uk> X-Sender: ucacfxa@pop.cs.ucl.ac.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 07 Sep 2000 03:52:33 +0100 To: mobile-systems@cs.ucl.ac.uk, 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, agents@mailserver-ng.cs.umbc.edu, mymobile@egroups.com From: Farez Subject: AMOC 2000 Programme and Call for Participation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please accept our apologies if you have received multiple copies of this. Farez ------------------------------------------------------------ Preliminary Programme & Call for Participation AMOC 2000 FIRST ASIAN INTERNATIONAL MOBILE COMPUTING CONFERENCE 31 October - 3 November, 2000. Penang, Malaysia Organised by University Malaya, Malaysia In cooperation with ACM SIGMOBILE With support from MRCB Multimedia, Malaysia http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc 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 ---------------------------------------------------------- Preliminary Programme (please see website for more detail) ---------------------------------------------------------- * 31 October, 2000 - Tutorials only 0900-1215: Half-Day Tutorial 1: Mobile Ad-Hoc Wireless Networks Dr. Somprakash Bandyopadhyay PriceWaterhouseCoopers, India Dr. Krishna Paul, Cognizant Technology Solutions, India 1215-1400: Lunch 1400-1715: Half-Day Tutorial 2: Java based Mobile Computing -- JINI, Mobile Objects and Agents Dr. Omer F. Rana, University of Wales, Cardiff, Wales ................................................ 0900-1715: Full Day Tutorial (to be confirmed) Client/Server Computing in Wireless and Mobile Environments Prof. Abdelsalam Helal, University of Florida, USA ========================================================== * 1 November, 2000 0900-1215: Registration Welcome Reception Guest Speakers 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 MediaArbitration 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, Unversity 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 Univesity, 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 5: Data Acccess, Display and Management A Three-tier Architecture for Ubiquitous Data Access Abdelsalam Helal, Joachim Hammer, Jinsuo Zhang, Abhinav Khushraj University of Florida, USA 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 1030-1045: Break 1045-1215: 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 1215: Conference Close ------------------------------------------------------------------ AMOC 2000 1st Asian International Mobile Computing Conference 31 October - 3 November, 2000 Penang, Malaysia * Registration deadline: 30 September, 2000 ============================ 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 or USD 100 Others: _ RM 600 or 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 is provided and a banquet will be held on 2 November. (You do not need to pay extra for the banquet and lunches. The banquet may be cancelled if there is less than a minimum number of attendees agree to turn up.) Will you be attending the banquet? _ YES _ NO Are you a vegetarian? _ YES _ NO Your signature: _____________________________ Date: ________ Payment Method -------------- Please make your 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 ------------------------------------------------------------------ AMOC 2000 1st Asian International Mobile Computing Conference 31 October - 3 November, 2000 Penang, Malaysia * Registration deadline: 30 September, 2000 ========================== Tutorial Registration Form ========================== Your details ------------ Title: _______ Surname: ____________________________________ Other names: _______________________________________________ Designation: _______________________________________________ Company Name/ Institution: _________________________________ Address: ___________________________________________________ City: ____________________ Postcode: _______________________ State: ___________________ Country: ________________________ Office Telephone: __________________ Fax: __________________ E-mail address: ____________________________________________ Registration Fee (please tick as appropriate) ------------------------------------------------ * Price includes lunch and tutorial notes. * You can pay in Malaysian Ringgit (RM) or US Dollars (USD) 1. Client/Server Computing in Mobile and Wireless Environments (Full Day) _ RM 250 or USD 65 2. Mobile Ad Hoc Wireless Networks (Half Day - AM) _ RM 200 or USD 50 3. Java Based Mobile Computing -- JINI, Mobile Objects and Agents (Half Day - PM) _ RM 200 or USD 50 Are you a vegetarian? _ YES _ NO Would you like to include your name in the list of attendees? _ YES _ NO Please specify if you have any special needs: ____________________________________________________________ Your signature: _____________________________ Date: ________ Payment Method -------------- Please make your 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 ------------------------------------------------------------------ AMOC 2000 1st Asian International Mobile Computing Conference 31 October - 3 November, 2000 Penang, Malaysia * Booking deadline: 1 October, 2000 ======================================= Room Booking at Penang Parkroyal Resort ======================================= Your details ------------ Title: _______ Surname: ____________________________________ Other names: _______________________________________________ Designation: _______________________________________________ Company Name/ Institution: _________________________________ Address: ___________________________________________________ City: ____________________ Postcode: _______________________ State: ___________________ Country: ________________________ Office Telephone: __________________ Fax: __________________ E-mail address: ____________________________________________ Booking Details --------------- Booking is from: _____________ to ______________ (__ nights) Arrival date: ______________________________________________ Number of rooms: ___________________________________________ _ Single _ Double A confirmed booking must be guaranteed either with credit card details or one night pre-payment. Payment Method -------------- The room rate is RM200 per night. If paying by a cheque/bank draft, pelase make it payable to PENANG PARKROYAL RESORT. _ Cheque/bank draft enclosed Credit card _ Visa _ MasterCard _ American Express Credit Card #: ____________________________________________ Expiry date: ______________________________________________ Signature: ________________________________________________ Date: _____________________________________________________ ----------------------------------------------------------- Please mail/fax 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 ------------------------------------------------------------- Hotel booking info (not part of form above): AMOC 2000 will be held at the Penang Parkroyal Resort in Penang Malaysia. AMOC participants will have the special rate of RM200 per night. All cheques / bank draft must be made payable to PENANG PARKROYAL RESORT. Hotel bookings for Parkroyal Resort must be made through University Malaya (details are at the bottom of the form). Please do not book through Parkroyal itself or a travel agent as this may not entitle you to the special conference rate. For more information about the hotel, please see their website (http://www.sphc.com.au/), or contact them directly using the contact details below. Please remember to book through the AMOC organisers to get the special conference rate. Penang Parkroyal Resort Batu Ferringhi Beach, Batu Ferringhi Penang 11100, Malaysia. Phone: (604) 8811133 Fax: (604) 8812233 Email: inqppr@sphc.com.my There are alternative hotels and other types of accommodation along the Baru Ferringhi beach where AMOC will be located. For a list of hotels you can try the HotelStreet website (http://www.hotelstreet.com.my/hotellist.asp?sCity=Penang) (they also support online reservations) or consult your travel agent. When using the website, please search for hotels in Penang and choose those that are located in Batu Ferringhi or Tanjung Bungah areas. Be sure to enquire their distance from AMOC's location as some of them may not be in convenient walking distance. Participants are adviced to book their accommodations early as AMOC will coincide with the local school holiday season. This means that hotels are likely to be fully booked. +44 7939 610241 www.cs.ucl.ac.uk/staff/F.AbdulRahman Department of Computer Science, University College London From rem-conf Wed Sep 06 22:47:24 2000 From rem-conf-request@es.net Wed Sep 06 22:47:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WuRd-0001r6-00; Wed, 6 Sep 2000 22:41:53 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WuRX-0001qp-00; Wed, 6 Sep 2000 22:41:49 -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 OAA06917; Thu, 7 Sep 2000 14:40:32 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA11734; Thu, 7 Sep 2000 14:40:32 +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 OAA18849; Thu, 7 Sep 2000 14:40:31 +0900 (JST) Received: from default (kddpar0121.mobile.toshiba.co.jp [10.1.15.40]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id OAA37872; Thu, 7 Sep 2000 14:40:26 +0900 (JST) Message-ID: <027e01c0188e$25b4c340$280f010a@default> From: "Yoshihiro Kikuchi" To: "Koji Imura" , "IETF AVT" , "Colin Perkins" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <200008251549.QAA01356@purple.cs.ucl.ac.uk> <00f001c017a9$28852460$a3d2b785@telecom.mci.mei.co.jp> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Thu, 7 Sep 2000 14:40:29 +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 Imura-san, Thank you very much for the comment. > I reviewed the draft and had a question. > In the section 3.1, there is a description about the marker bit and > time stamp for the MPEG-4 visual. > According to this description, it is possible to include some VOPs > in one RTP packet. > In such a case, the only time stamp for first VOP is included in the > RTP header, but there is no time information for rest of VOPs in the > same RTP packet. > The temporal interval between VOPs is variable in MPEG-4 visual > So it is difficult to estimate the time stamp of the other VOPs. > > If there is a system that presentation/composition time is decided > by the RTP time stamp, how do the system estimate the time stamp > of rest of the VOPs? > Since MPEG-4 Video stream contains timing information in the VOP header fields (modulo_time_base and vop_time_increment), the timestamp can be derived from these fields inside the RTP payload. It would be better to add a description to clarify this. How about adding the following description in the timestamp definition in section 3.1? - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the composition time within the VOPs carried in the RTP packet. Timestamp information of the rest of VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment).? 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 Sep 07 00:47:37 2000 From rem-conf-request@es.net Thu Sep 07 00:47:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WwLS-0003zF-00; Thu, 7 Sep 2000 00:43:38 -0700 Received: from mailgw3.netvision.net.il [194.90.1.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WwLQ-0003z5-00; Thu, 7 Sep 2000 00:43:36 -0700 Received: from ismailout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by mailgw3.netvision.net.il (8.9.3/8.9.3) with ESMTP id KAA03510 for ; Thu, 7 Sep 2000 10:42:53 +0300 (IDT) Received: from ismaildev.icomverse.com ([190.190.110.5]) by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e877hUq09669 for ; Thu, 7 Sep 2000 10:43:30 +0300 Received: by ismaildev.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:42:42 +0300 Message-ID: <91ECD6906EC7D211B27100204840464702F7469B@ismaildev.icomverse.com> From: "Guler, Amos" To: "'rem-conf@es.net'" Subject: Question: packing several frames in a single RTP packet Date: Thu, 7 Sep 2000 10:42:41 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-8-i" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all, (I hope I am sending this to the correct mailing list. If not, please accept my apology and advise me of the correct one) In the new draft "RTP Profile for Audio and Video Conferences with Minimal Control" (http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt) that is supposed to replace RFC-1890, it says (in section 4.4, Guidelines for Frame-Based Audio Encodings): "The receiver can tell the number of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audio frame size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime." My question concerns the last statement: suppose, for example, that the frame sizes are 5 and 7 octets, which are relatively prime, and the receiver gets a 35-octet packet. How can he/she tell whether the packet contains five 7-octet frames or seven 5-octet frames? Amos Guler ==================== Amos Guler Comverse Network Systems Ltd. amos_guler@icomverse.com http://www.comverse.com From rem-conf Thu Sep 07 01:39:28 2000 From rem-conf-request@es.net Thu Sep 07 01:39:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13WxB9-0005Y9-00; Thu, 7 Sep 2000 01:37:03 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13WxB7-0005Xl-00; Thu, 7 Sep 2000 01:37:01 -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 <0G0I00M2DCHURT@ss3000e.cselt.it> for rem-conf@es.net; Thu, 7 Sep 2000 10:20:19 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Thu, 07 Sep 2000 10:22:35 +0200 Content-return: allowed Date: Thu, 07 Sep 2000 10:20:19 +0200 From: Franceschini Guido Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt To: Koji Imura , IETF AVT , Colin Perkins , 'Yoshihiro Kikuchi' , Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <85077463E51D6A498C453073E1677940034E9C@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 Dear Kikuchi-Sun, > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Thursday, September 07, 2000 7:40 AM > To: Koji Imura; IETF AVT; Colin Perkins > Cc: 4on2andIP-sys; Yoshihiro Kikuchi > Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > > Dear Imura-san, > > Thank you very much for the comment. > > > I reviewed the draft and had a question. > > In the section 3.1, there is a description about the marker bit and > > time stamp for the MPEG-4 visual. > > According to this description, it is possible to include some VOPs > > in one RTP packet. > > In such a case, the only time stamp for first VOP is included in the > > RTP header, but there is no time information for rest of VOPs in the > > same RTP packet. > > The temporal interval between VOPs is variable in MPEG-4 visual > > So it is difficult to estimate the time stamp of the other VOPs. > > > > If there is a system that presentation/composition time is decided > > by the RTP time stamp, how do the system estimate the time stamp > > of rest of the VOPs? > > > Since MPEG-4 Video stream contains timing information in the VOP header > fields (modulo_time_base and vop_time_increment), the timestamp can be > derived from these fields inside the RTP payload. > > It would be better to add a description to clarify this. How about adding > the following description in the timestamp definition in section 3.1? > > - When multiple VOPs are carried in the same RTP packet, the timestamp > indicates the earliest of the composition time within the VOPs carried in > the RTP packet. Timestamp information of the rest of VOPs are derived from > the timestamp fields in the VOP header (modulo_time_base and > vop_time_increment).? > Are you sure you want to possibly indicate the CTS of the second VOP in a packet ? This seems to me quite difficult to manage I would better do either of the following: - always indicate the CTS of the first VOP in the packet, even if the second VOP will be presented first - disallow concatenation of VOPs whose decoding order differs from the composition order I am also doubtful about allowing variable frame rate videos to take advantage of such concatenation of VOPs in the same RTP packet. IMHO it would be safer to add some more constraints in the specification (i.e. prohibit VOP concatenation in case of variable frame rates), instead of adding the complexity of extracting TS information through cooperation of different layers. In other words: VOP concatenation has pros and cons. Pros: optimizes bandwidth consuption Cons: deteriorates packet loss resilience; increases implementation complexity. I therefore deduce that VOP concatenation is nice but not that wonderful, and I would suggest to allow VOP concatenation only when this is trivial and does not require significant complexity in the receivers implementations. Bye Guido > 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 Sep 07 02:11:06 2000 From rem-conf-request@es.net Thu Sep 07 02:11:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Wxg4-0006k3-00; Thu, 7 Sep 2000 02:09:00 -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 13Wxg2-0006hz-00; Thu, 7 Sep 2000 02:08:58 -0700 Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id SAA11068; Thu, 7 Sep 2000 18:07:46 +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, 7 Sep 00 18:07:42 +0900 Received: by dragon.drl.mei.co.jp (8.9.3/5.9:4.9:drl-mx-com:20000202) id SAA13981; Thu, 7 Sep 2000 18:06:45 +0900 (JST) Message-ID: <03c801c018aa$f01ccc60$446bb684@drl.mei.co.jp> From: "Y. Matsui" To: "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "'Yoshihiro Kikuchi'" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Thu, 7 Sep 2000 18:06:39 +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, Kikuchi-san and all, I agree on Guido's opinion that concatenation of VOPs is allowed only when constant frame rate, that is defined when the fixed_vop_rate field of the VOL header is set to 1. Best regards, Yoshinori Matsui Matsushita Electric Industrial Co., LTD. ----- Original Message ----- From: Franceschini Guido To: Koji Imura ; IETF AVT ; Colin Perkins ; 'Yoshihiro Kikuchi' ; Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Sent: Thursday, September 07, 2000 5:20 PM Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > Dear Kikuchi-Sun, > > > ---------- > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > Sent: Thursday, September 07, 2000 7:40 AM > > To: Koji Imura; IETF AVT; Colin Perkins > > Cc: 4on2andIP-sys; Yoshihiro Kikuchi > > Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > > > > Dear Imura-san, > > > > Thank you very much for the comment. > > > > > I reviewed the draft and had a question. > > > In the section 3.1, there is a description about the marker bit and > > > time stamp for the MPEG-4 visual. > > > According to this description, it is possible to include some VOPs > > > in one RTP packet. > > > In such a case, the only time stamp for first VOP is included in the > > > RTP header, but there is no time information for rest of VOPs in the > > > same RTP packet. > > > The temporal interval between VOPs is variable in MPEG-4 visual > > > So it is difficult to estimate the time stamp of the other VOPs. > > > > > > If there is a system that presentation/composition time is decided > > > by the RTP time stamp, how do the system estimate the time stamp > > > of rest of the VOPs? > > > > > Since MPEG-4 Video stream contains timing information in the VOP header > > fields (modulo_time_base and vop_time_increment), the timestamp can be > > derived from these fields inside the RTP payload. > > > > It would be better to add a description to clarify this. How about adding > > the following description in the timestamp definition in section 3.1? > > > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the composition time within the VOPs carried in > > the RTP packet. Timestamp information of the rest of VOPs are derived from > > the timestamp fields in the VOP header (modulo_time_base and > > vop_time_increment).? > > > Are you sure you want to possibly indicate the CTS of the second VOP in a > packet ? > This seems to me quite difficult to manage > I would better do either of the following: > - always indicate the CTS of the first VOP in the packet, even if the second > VOP will be presented first > - disallow concatenation of VOPs whose decoding order differs from the > composition order > > I am also doubtful about allowing variable frame rate videos to take > advantage of such concatenation of VOPs in the same RTP packet. > IMHO it would be safer to add some more constraints in the specification > (i.e. prohibit VOP concatenation in case of variable frame rates), instead > of adding the complexity of extracting TS information through cooperation of > different layers. > In other words: VOP concatenation has pros and cons. > Pros: optimizes bandwidth consuption > Cons: deteriorates packet loss resilience; increases implementation > complexity. > I therefore deduce that VOP concatenation is nice but not that wonderful, > and I would suggest to allow VOP concatenation only when this is trivial and > does not require significant complexity in the receivers implementations. > > Bye > Guido > > > > 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 Sep 07 02:30:02 2000 From rem-conf-request@es.net Thu Sep 07 02:30:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Wxy1-0007nd-00; Thu, 7 Sep 2000 02:27:33 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Wxy0-0007mx-00; Thu, 7 Sep 2000 02:27:33 -0700 Received: from Young ([195.232.61.1]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000090718283067:22325 ; Thu, 7 Sep 2000 18:28:30 +0900 Message-ID: <007c01c018ad$cfc532b0$013de8c3@Young> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: Cc: <4on2andIP-sys@advent.ee.columbia.edu> Subject: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 7 Sep 2000 18:19:41 +0900 Organization: TechWay 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-09-07 06:28:32 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-07 06:28:36 PM, Serialize complete at 2000-09-07 06:28:36 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 RGVhciBDb2xsaW4gYW5kIEFWVCB3b3JraW5nIGdyb3VwIG1lbWJlcnMsDQoNClllc3RlcmRheSAy MCBNUEVHIGV4cGVydHMgaGFkIGFuIEFIRyBtZWV0aW5nIGF0IFBhcmlzLiBXZSBkaXNjdXNzZWQg dGhlIHRlY2huaWNhbCBwcm9ibGVtcyBhbmQgdGhlIHNvbHV0aW9ucyBpbiB0ZXJtcyBvZiBiYXNp YyBpbnRlcm9wZXJhYmlsaXRpZXMgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgZm9ybSB0aGUgb25n b2luZyB3b3JrIHRvIGRldmVsb3Agb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIGNhcnJpYWdlIG9mIE1Q RUctNCBjb250ZW50IG92ZXIgSVAuIEJhc2VkIG9uIHRoZSBjb25zZW5zdXMgb2YgdGhlIEFIRyBt ZW1iZXJzLCB3ZSB3b3VsZCBsaWtlIHRvIG1ha2UgdHdvIGNvbW1lbnRzIHRvIHBvc3NpYmx5IGVu c3VyZSB0aGUgYmFzaWMgaW50ZXJvcGVyYWJpbGl0aWVzIGJldHdlZW4gdGhlIHBheWxvYWQgZm9y bWF0IG9mIHRoaXMgZHJhZnQgYW5kIHRoZSBnZW5lcmljIHBheWxvYWQgZm9yYW10IHVuZGVyIGRl dmVsb3BtZW50Lg0KDQoxLiAgV2Ugc3VnZ2VzdCB0byBoYXZlIGEgcm9vbSBmb3IgZnV0dXJlIGV4 dGVuc2lvbiBvZiBSVFAgaGVhZGVyIChlLmcuIG9uZSBieXRlIG9mIHBheWxvYWQgaGVhZGVyIGF0 IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBheWxvYWQgcGFydCkgdG8gbWFrZSB0aGUgZGV2aWNlcyBp bXBsZW1lbnRpbmcgdGhpcyBkcmFmdCBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIGJpdHN0cmVhbSBi YXNlZCBvbiB0aGUgZ2VuZXJpYyBmb3JtYXQgdW5kZXIgZGV2ZWxvcG1lbnQuIEZvciBleGFtcGxl LCBpdCBpcyBwb3NzaWJsZSB0byB1c2UgdGhlIHJlc2VydmVkIGJ5dGUgdG8gc3BlY2lmeSB0aGUg bGVuZ3RoIG9mIHRoZSBwYXlsb2FkIGhlYWRlciBvZiBnZW5lcmljIHBheWxvYWQgZm9ybWF0LiBU aGVuIHRoZSBkZXZpY2UgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQgY2FuIHBsYXkgdGhlIGJpdHN0 cmVhbSBvZiBnZW5lcmljIHBheWxvYWQgZm9ybWF0IGJ5IHNpbXBseSBza2lwcGluZyB0aG9zZSBi eXRlcy4NCg0KMi4gV2UgcmVxdWVzdCB0byBjbGFyaWZ5IHRoZSB1c2FnZSBvZiBMQVRNLiBJdCB3 YXMgcmVjb2duaXplZCBkdXJpbmcgdGhlIG1lZXRpbmcgdGhhdCB0aGVyZSBzZWVtcyBubyByZWFz b24gdG8gdXNlIG11bHRpcGxleGluZyBmZWF0dXJlIG9mIExBVE0gZm9yIHRoZSBwdXJwb3NlIG9m IHRoaXMgZHJhZnQuIEluIGFkZGl0aW9uLCBsaW1pdGluZyB0aGUgdXNhZ2Ugb2YgTEFUTSB0byBj YXJyeSBjb25maWd1YXRpb24gaW5mb3JtYXRpb24gYW5kIGNvbmNhdGVuYXRpb24gb2YgYXVkaW8g ZnJhbWVzIGlzIGRlc2lyYWJsZSB0byBtYWtlIHRoaXMgZHJhZnQgbW9yZSBjb21wYXRpYmxlIHRv IHRoZSBnZW5lcmljIHBheWxvYWQgZm9ybWF0IHVuZGVyIGRldmVsb3BtZW50Lg0KDQpTaW5jZXJl bHksDQoNCllvdW5nLUt3b24gTElNDQpDby1jaGFpcg0KQUhHIG9uIE1QRUctNCBjb250ZW50IG9u IElQIG5ldHdvcmsNCg== From rem-conf Thu Sep 07 07:21:15 2000 From rem-conf-request@es.net Thu Sep 07 07:21:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13X2SO-0004HB-00; Thu, 7 Sep 2000 07:15:12 -0700 Received: from smtp1.cluster.oleane.net [195.25.12.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 13X2SM-0004H1-00; Thu, 7 Sep 2000 07:15:11 -0700 Received: from oleane (dyn-1-2-213.Vin.dialup.oleane.fr [194.2.4.213]) by smtp1.cluster.oleane.net with SMTP id QAA05688 for ; Thu, 7 Sep 2000 16:15:25 +0200 (CEST) Message-ID: <00e601c018d5$f501a400$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: Upper Side Conferences Date: Thu, 7 Sep 2000 16:14:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01C018E6.B7CA3140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00E3_01C018E6.B7CA3140 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 International SIP 2001 (second edition) Implementing H.323 MGC 2000 (second edition) =20 Three conferences organised by Upper Side gathering the most eminent = specialists in VoIP technologies. =20 Get more details at: http://www.upperside.fr/index.html ------=_NextPart_000_00E3_01C018E6.B7CA3140 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
International SIP = 2001 (second=20 edition)
Implementing = H.323
MGC 2000 (second=20 edition)
 
Three conferences organised by Upper = Side=20 gathering the most eminent specialists in VoIP = technologies.
 
Get more details at:
http://www.upperside.fr/index= .html
 
 
------=_NextPart_000_00E3_01C018E6.B7CA3140-- From rem-conf Thu Sep 07 08:20:43 2000 From rem-conf-request@es.net Thu Sep 07 08:20:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13X3Pd-00064O-00; Thu, 7 Sep 2000 08:16:25 -0700 Received: from (notes.hgiga.com) [210.241.239.250] by mail1.es.net with esmtp (Exim 1.81 #2) id 13X3Pc-00064E-00; Thu, 7 Sep 2000 08:16:24 -0700 Received: from 210.241.239.250 ([206.170.29.31]) by notes.hgiga.com (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000090721535999:177 ; Thu, 7 Sep 2000 21:53:59 +0800 To: mirandalou33@msn.com Message-ID: <654326426482.LOP89725@rly-t49524.ferry.co.jp> Date: Thu, 07 Sep 00 06:18:22 EST From: thomasjoe@ferry.co.jp Subject: E-Commerce Solution + NO Set Up Fees!! Reply-To: thomasjoe@ferry.co.jp X-PMFLAGS: Mozilla 4.5 [en] C-CCK-MCD {U S WEST.net} {Win95} X-UIDL: f8465346d728fj89ol20b0e653db875 X-MIMETrack: Itemize by SMTP Server on ns1/hgiga(Release 5.0.2a (Intl)|23 November 1999) at 2000/09/07 09:54:00 PM, Serialize by Router on ns1/hgiga(Release 5.0.2a (Intl)|23 November 1999) at 2000/09/07 11:10:33 PM, Serialize complete at 2000/09/07 11:10:33 PM MIME-Version: 1.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Complete E-COMMERCE solutions to accept VISA, MasterCard, American Express, Discover and Checks for your website, online store, traditional storefront or home based business. WE OFFER -Bank-approved merchant accounts -Real-time, online payment transactions -Shopping carts -Terminals & printers -95% approval rate -Fast 5 - 7 day setup A TURNKEY E-COMMERCE SOLUTION FOR -Internet Storefront Businesses -Mail Order and Phone Order -Start-up Businesses -Traditional Retail Stores -Home based Businesses Good Credit / Bad Credit / No Credit **** NO PROBLEM **** ------FREE SET-UP------FREE SET-UP------FREE SET-UP---------- While OTHERS Charge You From $200 TO $350 To Get Set Up WE CHARGE ZERO FOR SETUP FEES!!! Limited Time Offer So Take Advantage NOW!!! Secure transactions are authorized in true real-time immediately upon submitting orders right on your website. You can process transactions right over the Internet without the need for separate transaction terminal or processing software. Dedicated data line for fast, 3-5 second transactions. No installation required! Quick and easy account setup: 5 - 7 days. _____________________________________________ Full Service E-Commerce Provider who offers complete e-commerce solutions for thousands of businesses. FREE CONSULTATION WITH AN INDUSTRY EXPERT, NO OBLIGATION -LOWEST MONTHLY SERVICE FEES as low as 1.59% Banks can charge up to 5% or higher ------FREE SET-UP------FREE SET-UP------FREE SET-UP-------- The Time Is Right!!! Call Now!!! ------------------------------------------------------------- To have a CONSULTANT contact you, please call us toll free at: 1-888-248-4522 Please leave the following information. First & Last Name_______________________________ Phone________________________________________ Company Name________________________________ Product and/or Service__________________________ A merchant account CONSULTANT will contact you soon. ============================================== 1-888-248-4522 Here's what our customers say... Testimonial # 1 - I knew having a merchant account would increase my sales, But never thought it would be so great. In addition in being able to take major credit cards, I can also do real time credit card processing on the internet and receive orders while I am Sleeping. It's awesome! I encourage every serious business owner to get one. Thanks. M.B./MI Testimonial # 2 - " Being a home based business owner, no one would approve me, until this came my way. I am more than grateful. Within 10 days I had my merchant account set up. I am more than pleased with the 24 hr. customer service. My business has sky rocketed because I now can accept credit card orders. " Oscar/FL =================================================== This message was sent by an independent advertising company. To be removed please send an email to: angela99@nycmail.com and put REMOVE in the subject line. Thank you! We apologize for any inconvenience. From rem-conf Thu Sep 07 09:35:54 2000 From rem-conf-request@es.net Thu Sep 07 09:35:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13X4Y9-0000Y8-00; Thu, 7 Sep 2000 09:29:17 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13X4Y7-0000Xy-00; Thu, 7 Sep 2000 09:29:15 -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 JAA25389; Thu, 7 Sep 2000 09:19:51 -0700 Message-Id: <3.0.3.32.20000907092120.00b10160@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 07 Sep 2000 09:21:20 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 9/13 Making Interactive Workspaces Real -- Armando Fox, Computer Science Department, Stanford University Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gumby.cs.berkeley.edu id JAA25389 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Making Interactive Workspaces Real Wednesday September 13, 2000,=20 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall)=20 Armando Fox=20 Computer Science Department, Stanford University The Stanford Interactive Workspaces project is developing the computing foundations for bringing reality to ubiquitous computing. A diverse collection of faculty and students from the areas of graphics, human-computer interaction (HCI),networking,ubiquitous computing,and databases, we are looking at new types of human/machine interaction including multimodal input, heterogeneous device integration from wall-sized displays to handheld information appliances, and the "invisibl= e" software infrastructure required to support them. In the same way that today=92s standard operating systems make it feasible to write single-workstation software that uses multiple devices and networked resources,we are constructing a higher level operating system for the wor= ld of ubiquitous computing. We combine research on infrastructure (ways of flexibly configuring and connecting devices, processes,and communication links)with research on HCI (ways of interacting with heterogeneous changi= ng collections of devices with multiple modalities). I will describe our progress on the software infrastructure, including applications running i= n our deployed iRoom that do in fact integrate a variety of devices.=20 --------------- The seminar is broadcast live on the Internet Mbone and as a Real Network= s 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:=20 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 t= he announcement you may be able to receive the session by manually configuri= ng the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center=20 From rem-conf Thu Sep 07 18:29:16 2000 From rem-conf-request@es.net Thu Sep 07 18:29:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XCmR-00077N-00; Thu, 7 Sep 2000 18:16:35 -0700 Received: from omega.cisco.com [171.69.63.141] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XCmQ-00075m-00; Thu, 7 Sep 2000 18:16:34 -0700 Received: from tmima-nt.cisco.com (dhcp-171-70-57-27.cisco.com [171.70.57.27]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA22285; Thu, 7 Sep 2000 18:08:41 -0700 (PDT) Message-Id: <4.3.1.2.20000907161936.029ba8e0@omega.cisco.com> X-Sender: tmima@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 07 Sep 2000 18:03:29 -0700 To: Andy Valencia , "W. Mark Townsley" From: Tmima Koren Subject: 0 byte L2TPHC header and implied PPPMUX Cc: brucet@cisco.com, dwing@cisco.com, Stephen Casner , l2tp@diameter.org, rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I suggest a few minor changes to the L2TPHC draft draft-ietf-l2tpext-l2tphc-02.txt to improve bandwidth utilization in special cases. When the L2TPHC header is 1 byte long, actually only 1 bit is significant: the P (Priority) bit. If all the packets in the tunnel will have the same priority, the L2TPHC byte is redundant. We could add to the L2TPHC AVP one more byte (byte 9) We really need only 2 flag bits: flag 1: value 1 means: L2TPHC byte will be omitted value 0 means: L2TPHC byte is there, get P (Priority) from the L2TPHC byte flag 2: value 1 means all packets have implied P=1 value 0 means all packets have implied P=0 consult flag 2 only when flag 1 is 1 If the packet in the L2TPHC tunnel is always PPPMUX, there is another useful flag: flag 3: value 1 means 'PPPMUX only' value 0 means: any PPP packet When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can be omitted PPP packets that have a different priority or that are not PPPMUX can still be sent in the tunnel using the UDP/L2TP format, same as the L2TP control packets TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: the tunneling overhead will be reduced by 2 bytes. Tmima From rem-conf Thu Sep 07 19:59:00 2000 From rem-conf-request@es.net Thu Sep 07 19:58:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XEJu-0000uD-00; Thu, 7 Sep 2000 19:55:14 -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 13XEJs-0000u3-00; Thu, 7 Sep 2000 19:55:12 -0700 Received: from i810 ([133.9.250.220]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id LAA04987; Fri, 8 Sep 2000 11:55:06 +0900 Message-ID: <00c901c0193f$e578b0e0$dcfa0985@katto.comm.waseda.ac.jp> From: "Jiro Katto" To: Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <007c01c018ad$cfc532b0$013de8c3@Young> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 8 Sep 2000 11:52:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 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 RGVhciBhbGwsIA0KDQpJIGFwcHJlY2lhdGUgdGhlIHByb2dyZXNzLiBKdXN0IGh1bXBsZSBjb21t ZW50cywgDQoNCj4gMS4gIFdlIHN1Z2dlc3QgdG8gaGF2ZSBhIHJvb20gZm9yIGZ1dHVyZSBleHRl bnNpb24gb2YgUlRQIGhlYWRlciAoZS5nLiBvbmUgYnl0ZSANCj4gb2YgcGF5bG9hZCBoZWFkZXIg YXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgcGF5bG9hZCBwYXJ0KSB0byBtYWtlIHRoZSBkZXZpY2Vz IA0KPiBpbXBsZW1lbnRpbmcgdGhpcyBkcmFmdCBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIGJpdHN0 cmVhbSBiYXNlZCBvbiB0aGUgZ2VuZXJpYyANCj4gZm9ybWF0IHVuZGVyIGRldmVsb3BtZW50LiBG b3IgZXhhbXBsZSwgaXQgaXMgcG9zc2libGUgdG8gdXNlIHRoZSByZXNlcnZlZCBieXRlIHRvIA0K PiBzcGVjaWZ5IHRoZSBsZW5ndGggb2YgdGhlIHBheWxvYWQgaGVhZGVyIG9mIGdlbmVyaWMgcGF5 bG9hZCBmb3JtYXQuIFRoZW4gdGhlIGRldmljZSANCj4gaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQg Y2FuIHBsYXkgdGhlIGJpdHN0cmVhbSBvZiBnZW5lcmljIHBheWxvYWQgZm9ybWF0IGJ5IHNpbXBs eSANCj4gc2tpcHBpbmcgdGhvc2UgYnl0ZXMuDQoNClRoaXMgbWF5IGJlIGdvb2QgY29tcHJvbWlz ZS4gQnV0LCB1c2FnZSBvZiBleHRlbnNpb24gYnl0ZSBpbiB0aGUgTVBFRy00IA0KcGF5bG9hZCBo ZWFkZXIsIGluc3RlYWQgb2YgZGVmaW5pbmcgYW5vdGhlciBwYXlsb2FkIGhlYWRlciwgc2VlbXMg dG8gY29uY2x1ZGUgDQp0aGF0IHRoZSAiZ2VuZXJpYyIgcGF5bG9hZCBmb3JtYXQgaXMgTVBFRy00 ICJzcGVjaWZpYy4iIExldCBtZSBjb25maXJtIHRoYXQNCiJnZW5lcmljIiBtZWFucyBNUEVHLTQg Z2VuZXJpYywgbm90IGFwcGxpZWQgdG8gb3RoZXIgY29kZWNzIG5vciBmdXR1cmUgb25lcy4gDQoN Ckkgc29tZXRpbWVzIGZlbHQsIGluIE1QRUcgd29ybGQsIGdlbmVyaWMgaXNzdWVzIGFuZCBNUEVH LTQgc3BlY2lmaWMgaXNzdWVzIA0Kd2VyZSBjb25mdXNlZC4gR2VuZXJpYyBmb3JtYXQgYW5kIGhh bmRsaW5nIG9mIG11bHRpcGxlIFZPUHMgYXJlIGV4YW1wbGVzLiANCldoZW4gZXhwZWN0ZWQsIHRo ZXkgc2hvdWxkIGJlIGV4cGFuZGVkIChhbmQgc2VwYXJhdGVkKSB0byBnZW5lcmFsIGNhc2VzLCAN CnNpbWlsYXIgdG8gdGhlIHByZXZpb3VzIFJUQ1AgZXh0ZW5zaW9uIGNhc2UsIGluIG15IGh1bWJs ZSBvcGluaW9uLg0KDQo+IDIuIFdlIHJlcXVlc3QgdG8gY2xhcmlmeSB0aGUgdXNhZ2Ugb2YgTEFU TS4gSXQgd2FzIHJlY29nbml6ZWQgZHVyaW5nIHRoZSBtZWV0aW5nIA0KPiB0aGF0IHRoZXJlIHNl ZW1zIG5vIHJlYXNvbiB0byB1c2UgbXVsdGlwbGV4aW5nIGZlYXR1cmUgb2YgTEFUTSBmb3IgdGhl IHB1cnBvc2UgDQo+IG9mIHRoaXMgZHJhZnQuIEluIGFkZGl0aW9uLCBsaW1pdGluZyB0aGUgdXNh Z2Ugb2YgTEFUTSB0byBjYXJyeSBjb25maWd1YXRpb24gaW5mb3JtYXRpb24gDQo+IGFuZCBjb25j YXRlbmF0aW9uIG9mIGF1ZGlvIGZyYW1lcyBpcyBkZXNpcmFibGUgdG8gbWFrZSB0aGlzIGRyYWZ0 IG1vcmUgY29tcGF0aWJsZSANCj4gdG8gdGhlIGdlbmVyaWMgcGF5bG9hZCBmb3JtYXQgdW5kZXIg ZGV2ZWxvcG1lbnQuDQoNCldpdGhvdXQgTEFUTSwgYSBwYXlsb2FkIGZvcm1hdCBmb3IgTVBFRy00 IEF1ZGlvIHdvdWxkIG5lZWQgbW9zdCBmaWVsZHMgDQppbiB0aGUgTEFUTSBoZWFkZXIgdG8gYmUg YWRkZWQgaW50byBpdC4gQWNjZXB0YW5jZSBvZiBMQVRNIHdpdGggcmVzdHJpY3Rpb24gDQpzZWVt cyBwcmFjdGljYWwgY29tcHJvbWlzZS4NCg0KQmVzdCByZWdhcmRzLCANCi0tDQpKaXJvIEthdHRv DQpXYXNlZGEgVW5pdmVyc2l0eQ0K From rem-conf Thu Sep 07 22:19:43 2000 From rem-conf-request@es.net Thu Sep 07 22:19:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XGVP-0002dP-00; Thu, 7 Sep 2000 22:15:15 -0700 Received: from ftp.virtualwave.com (waveserver.virtualwave.com) [207.112.51.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XGVN-0002dF-00; Thu, 7 Sep 2000 22:15:14 -0700 Received: from ERIC2000PRO by waveserver.virtualwave.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id SHFSNRQS; Fri, 8 Sep 2000 00:55:11 -0400 Received: from [78.25.246.94] by _[19.221.72.24]_by with SMTP id A20C4E3 Fri, 8 Sep 2000 00:25:33 PDT From: Subject: Dirt Cheap Web Hosting $6.95 per month!! No Gimmicks! Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Fri, 8 Sep 2000 00:42:50 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Web Hosting $6.95 per month!! No Gimmicks!
The first month is free - Follow the link for more information
Paying More Is Too Much!!

http://www.your-info.net/695/

$6.95 per month for a full service user friendly Web Host.
No Banner Ads - Plenty of disk space.

http://www.your-info.net/695/

You get:
30Mb Disk Space
2000Mb transfer per month
5 E-mail addresses with unlimited forwarding including a Catch All mailbox
Free Auto Responder for E-Mail
FrontPage Enabled if you want it -
FTP access 24 X 7
Free Graphical Statistics Server with real time "Who's On"
Your own CGI-bin - Password protected Control Panel - Forms to E-Mail - Page
Counters
Free Qualified Technical Support
99.9% up time
SQL 7 packages available
Additional drive space and mailboxes available
Plus many other extras

i1Internet $aver is a no hassle quality Web Host that believes that if you
pay more than $6.95 per month, you are paying TOO MUCH!! We offer you the
same EXTRAS as other sites charging three times more.

http://www.your-info.net/695/



To be removed from this mailing list, please go to:
http://www.your-info.net/response.html
From rem-conf Thu Sep 07 23:07:22 2000 From rem-conf-request@es.net Thu Sep 07 23:07:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XHFp-0003oC-00; Thu, 7 Sep 2000 23:03:13 -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 13XHFo-0003nq-00; Thu, 7 Sep 2000 23:03:12 -0700 Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id PAA13584; Fri, 8 Sep 2000 15:02:02 +0900 (JST) Received: from dragon.drl.mei.co.jp(132.182.104.28) by vsm.ctmo.mei.co.jp via smap (V2.0) id ; Fri, 8 Sep 00 15:01:59 +0900 Received: by dragon.drl.mei.co.jp (8.9.3/5.9:4.9:drl-mx-com:20000202) id PAA13784; Fri, 8 Sep 2000 15:01:01 +0900 (JST) Message-ID: <008901c0195a$27fcbdc0$446bb684@drl.mei.co.jp> From: "Y. Matsui" To: "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "'Yoshihiro Kikuchi'" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Fri, 8 Sep 2000 15:00:55 +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, Kikuchi-san, all, > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the composition time within the VOPs carried in > > the RTP packet. Timestamp information of the rest of VOPs are derived from > > the timestamp fields in the VOP header (modulo_time_base and > > vop_time_increment).? > > > Are you sure you want to possibly indicate the CTS of the second VOP in a > packet ? > This seems to me quite difficult to manage > I would better do either of the following: > - always indicate the CTS of the first VOP in the packet, even if the second > VOP will be presented first > - disallow concatenation of VOPs whose decoding order differs from the > composition order I would prefer the latter one. I think it should be added to the current draft-ietf-avt-rtp-mpeg4-es-03 document. > I am also doubtful about allowing variable frame rate videos to take > advantage of such concatenation of VOPs in the same RTP packet. > IMHO it would be safer to add some more constraints in the specification > (i.e. prohibit VOP concatenation in case of variable frame rates), instead > of adding the complexity of extracting TS information through cooperation of > different layers. > In other words: VOP concatenation has pros and cons. > Pros: optimizes bandwidth consuption > Cons: deteriorates packet loss resilience; increases implementation > complexity. > I therefore deduce that VOP concatenation is nice but not that wonderful, > and I would suggest to allow VOP concatenation only when this is trivial and > does not require significant complexity in the receivers implementations. How about the following change ? [Original sentense in 1.1 MPEG-4 Visual RTP Payload Format] The fragmentation rule recommends not to map more than one VOP in an RTP packet so that 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 a not coded VOP containing only VOP header or an arbitrary shaped VOP with a small number. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet when the VOP size is small. [My proposed modification] MPEG-4 video may generate VOPs of very small size, in cases with a not coded VOP containing only VOP header or an arbitrary shaped VOP with a small number. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet when the VOP size is small. However, for the variable frame rate video, the fragmentation rule recommends not to map more than one VOP in an RTP packet so that RTP timestamp uniquely indicates the VOP time framing. Is this sentense enough for prohibiting the mapping of the multiple VOPs in a packet when variable frame rate video ? If there is no any objections on above sentense, I would like to propose to change the current draft as this. Best regards, Yoshinori Matsui Matsushita Electric Industrial Co., LTD. From rem-conf Thu Sep 07 23:21:57 2000 From rem-conf-request@es.net Thu Sep 07 23:21:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XHWw-0004ku-00; Thu, 7 Sep 2000 23:20:54 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XHWu-0004kk-00; Thu, 7 Sep 2000 23:20:53 -0700 Received: from Young ([194.134.123.18]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000090815214499:43152 ; Fri, 8 Sep 2000 15:21:44 +0900 Message-ID: <012701c0195c$e286bae0$f47d86c2@Young> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: "Jiro Katto" , Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <007c01c018ad$cfc532b0$013de8c3@Young> <00c901c0193f$e578b0e0$dcfa0985@katto.comm.waseda.ac.jp> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 8 Sep 2000 15:20:24 +0900 Organization: TechWay 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-09-08 03:21:46 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-08 03:21:58 PM, Serialize complete at 2000-09-08 03:21:58 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 RGVhciBKaXJvLA0KDQo+IDEuICBXZSBzdWdnZXN0IHRvIGhhdmUgYSByb29tIGZvciBmdXR1cmUg ZXh0ZW5zaW9uIG9mIFJUUCBoZWFkZXIgKGUuZy4gb25lIGJ5dGUgDQo+IG9mIHBheWxvYWQgaGVh ZGVyIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBheWxvYWQgcGFydCkgdG8gbWFrZSB0aGUgZGV2 aWNlcyANCj4gaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQgaW50ZXJvcGVyYWJsZSB3aXRoIHRoZSBi aXRzdHJlYW0gYmFzZWQgb24gdGhlIGdlbmVyaWMgDQo+IGZvcm1hdCB1bmRlciBkZXZlbG9wbWVu dC4gRm9yIGV4YW1wbGUsIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSB0aGUgcmVzZXJ2ZWQgYnl0ZSB0 byANCj4gc3BlY2lmeSB0aGUgbGVuZ3RoIG9mIHRoZSBwYXlsb2FkIGhlYWRlciBvZiBnZW5lcmlj IHBheWxvYWQgZm9ybWF0LiBUaGVuIHRoZSBkZXZpY2UgDQo+IGltcGxlbWVudGluZyB0aGlzIGRy YWZ0IGNhbiBwbGF5IHRoZSBiaXRzdHJlYW0gb2YgZ2VuZXJpYyBwYXlsb2FkIGZvcm1hdCBieSBz aW1wbHkgDQo+IHNraXBwaW5nIHRob3NlIGJ5dGVzLg0KDQpUaGlzIG1heSBiZSBnb29kIGNvbXBy b21pc2UuIEJ1dCwgdXNhZ2Ugb2YgZXh0ZW5zaW9uIGJ5dGUgaW4gdGhlIE1QRUctNCANCnBheWxv YWQgaGVhZGVyLCBpbnN0ZWFkIG9mIGRlZmluaW5nIGFub3RoZXIgcGF5bG9hZCBoZWFkZXIsIHNl ZW1zIHRvIGNvbmNsdWRlIA0KdGhhdCB0aGUgImdlbmVyaWMiIHBheWxvYWQgZm9ybWF0IGlzIE1Q RUctNCAic3BlY2lmaWMuIiBMZXQgbWUgY29uZmlybSB0aGF0DQoiZ2VuZXJpYyIgbWVhbnMgTVBF Ry00IGdlbmVyaWMsIG5vdCBhcHBsaWVkIHRvIG90aGVyIGNvZGVjcyBub3IgZnV0dXJlIG9uZXMu IA0KDQoNCj09PiBZZXMsIHlvdSBhcmUgcmlnaHQuIFRoZSBBSEcgZ3JvdXAgaXMgd29ya2luZyBv biBNUEVHLTQgb3ZlciBJUC4NCg0KU2luY2VyZWx5LA0KWW91bmcuDQo= From rem-conf Thu Sep 07 23:22:03 2000 From rem-conf-request@es.net Thu Sep 07 23:22:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XHWA-0004ki-00; Thu, 7 Sep 2000 23:20:06 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XHW4-0004kW-00; Thu, 7 Sep 2000 23:20: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 PAA10973; Fri, 8 Sep 2000 15:17:59 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id PAA20473; Fri, 8 Sep 2000 15:18:00 +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 PAA09570; Fri, 8 Sep 2000 15:17:57 +0900 (JST) Received: from default (tky0517.mobile.toshiba.co.jp [133.120.192.164]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id PAA07441; Fri, 8 Sep 2000 15:17:53 +0900 (JST) Message-ID: <02f401c0195c$89eefb40$280f010a@default> From: "Yoshihiro Kikuchi" To: "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Fri, 8 Sep 2000 15:17:57 +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, Matsui-san, Imura-san, all, > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the composition time within the VOPs carried in > > the RTP packet. Timestamp information of the rest of VOPs are derived from > > the timestamp fields in the VOP header (modulo_time_base and > > vop_time_increment).? > > > Are you sure you want to possibly indicate the CTS of the second VOP in a > packet ? > This seems to me quite difficult to manage > I would better do either of the following: > - always indicate the CTS of the first VOP in the packet, even if the second > VOP will be presented first > - disallow concatenation of VOPs whose decoding order differs from the > composition order > I agree with Guido. I support the latter one becase it is a safer soluiton, if there is no objection. > In other words: VOP concatenation has pros and cons. > Pros: optimizes bandwidth consuption > Cons: deteriorates packet loss resilience; increases implementation > complexity. > I therefore deduce that VOP concatenation is nice but not that wonderful, Therefore, fragmentation rule (4) in section 3.2 is defined that multiple VOPs SHOULD NOT be concatenated. The concatenation is an exception rule only when VOP size is small. (4) Two or more 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 VOPs MAY be carried within one RTP packet if the size of the VOPs is small. > and I would suggest to allow VOP concatenation only when this is trivial and > does not require significant complexity in the receivers implementations. > The complexity may be huge if we need to check every RTP packets. However, because of the marker bit and fragmentation rule definitions, we need check only RTP packets satisfying the following both two conditions: - Marker bit equal to one, and (Because marker bit in section 3.1 is defined that it is set to one when multiple VOP is concatenated.) - The beginning of RTP payload is not a start code. (Because the fragmentation rule is defined that a start code is placed always at the beginning of RTP payload, if exists.) I would like to propose adding a note to describe this for clarify, so that implementer can avoid unnecessary operation. 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 Sep 08 00:10:35 2000 From rem-conf-request@es.net Fri Sep 08 00:10:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XIH6-0006sB-00; Fri, 8 Sep 2000 00:08:36 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XIH5-0006s1-00; Fri, 8 Sep 2000 00:08:35 -0700 Received: from Young ([194.134.125.239]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000090816093248:43168 ; Fri, 8 Sep 2000 16:09:32 +0900 Message-ID: <01b601c01963$8f9b9a10$f47d86c2@Young> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "'Yoshihiro Kikuchi'" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Fri, 8 Sep 2000 16:08:10 +0900 Organization: TechWay 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-09-08 04:09:34 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-08 04:09:40 PM, Serialize complete at 2000-09-08 04:09:40 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 RGVhciBHdWlkbyBhbmQgYWxsLA0KDQo+ID4gDQo+ID4gSXQgd291bGQgYmUgYmV0dGVyIHRvIGFk ZCBhIGRlc2NyaXB0aW9uIHRvIGNsYXJpZnkgdGhpcy4gSG93IGFib3V0IGFkZGluZw0KPiA+IHRo ZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gaW4gdGhlIHRpbWVzdGFtcCBkZWZpbml0aW9uIGluIHNl Y3Rpb24gMy4xPw0KPiA+IA0KPiA+IC0gV2hlbiBtdWx0aXBsZSBWT1BzIGFyZSBjYXJyaWVkIGlu IHRoZSBzYW1lIFJUUCBwYWNrZXQsIHRoZSB0aW1lc3RhbXANCj4gPiBpbmRpY2F0ZXMgdGhlIGVh cmxpZXN0IG9mIHRoZSBjb21wb3NpdGlvbiB0aW1lIHdpdGhpbiB0aGUgVk9QcyBjYXJyaWVkIGlu DQo+ID4gdGhlIFJUUCBwYWNrZXQuIFRpbWVzdGFtcCBpbmZvcm1hdGlvbiBvZiB0aGUgcmVzdCBv ZiBWT1BzIGFyZSBkZXJpdmVkIGZyb20NCj4gPiB0aGUgdGltZXN0YW1wIGZpZWxkcyBpbiB0aGUg Vk9QIGhlYWRlciAobW9kdWxvX3RpbWVfYmFzZSBhbmQNCj4gPiB2b3BfdGltZV9pbmNyZW1lbnQp Lj8NCj4gPiANCj4gQXJlIHlvdSBzdXJlIHlvdSB3YW50IHRvIHBvc3NpYmx5IGluZGljYXRlIHRo ZSBDVFMgb2YgdGhlIHNlY29uZCBWT1AgaW4gYQ0KPiBwYWNrZXQgPw0KPiBUaGlzIHNlZW1zIHRv IG1lIHF1aXRlIGRpZmZpY3VsdCB0byBtYW5hZ2UNCj4gSSB3b3VsZCBiZXR0ZXIgZG8gZWl0aGVy IG9mIHRoZSBmb2xsb3dpbmc6DQo+IC0gYWx3YXlzIGluZGljYXRlIHRoZSBDVFMgb2YgdGhlIGZp cnN0IFZPUCBpbiB0aGUgcGFja2V0LCBldmVuIGlmIHRoZSBzZWNvbmQNCj4gVk9QIHdpbGwgYmUg cHJlc2VudGVkIGZpcnN0DQo+IC0gZGlzYWxsb3cgY29uY2F0ZW5hdGlvbiBvZiBWT1BzIHdob3Nl IGRlY29kaW5nIG9yZGVyIGRpZmZlcnMgZnJvbSB0aGUNCj4gY29tcG9zaXRpb24gb3JkZXINCg0K Im1vZHVsb190aW1lX2Jhc2UiIGFuZCAidm9wX3RpbWVfaW5jcmVtZW50IiBhcmUgdGhlIHN5bnRh eCBlbGVtZW50cyBvZiBWT1AgaGVhZGVyIGludmVudGVkIGZvciB0aGUgcHVycG9zZSBvZiBjYXJy eWluZyByZWxhdGl2ZSB0aW1pbmcgaW5mb3JtYXRpb24uIFNvLCBJIGRvbid0IHNlZSBhbnkgcHJv YmxlbSB0byB1c2UgdGhvc2UgaW5mb3JtYXRpb24gdG8gY2FsY3V0ZSBDVFMuIFdoZW4gdGhlIHJl Y2VpdmVyIGdldCBhIFJUUCBwYWNrZXQgd2l0aCBtdWx0aXBsZSBWT1BzLCB0aGUgQ1RTIG9mIGZp cnN0IFZPUCBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBSVFAgdGltZSBzdG1hcCBhbmQgQ1RTIG9m IHN1Y2Nlc3NpdmUgVk9QcyBjYW4gYmUgY2FsY3VsYXRlZCBieSB1c2luZyB0aW1lIHN0YW1wIGFu ZCB0d28gc3ludGF4IGVsZW1lbnRzIGluIFZPUCBoZWFkZXIuIENhbGN1bGF0aW5nIHRpbWluZyBp bmZvcm1hdGlvbiBvZiBlYWNoIFZPUCBpcyBub3RoaW5nIG5ldyB0byB0aGUgZGVjb2Rlci4NCg0K PiANCj4gSSBhbSBhbHNvIGRvdWJ0ZnVsIGFib3V0IGFsbG93aW5nIHZhcmlhYmxlIGZyYW1lIHJh dGUgdmlkZW9zIHRvIHRha2UNCj4gYWR2YW50YWdlIG9mIHN1Y2ggY29uY2F0ZW5hdGlvbiBvZiBW T1BzIGluIHRoZSBzYW1lIFJUUCBwYWNrZXQuDQo+IElNSE8gaXQgd291bGQgYmUgc2FmZXIgdG8g YWRkIHNvbWUgbW9yZSBjb25zdHJhaW50cyBpbiB0aGUgc3BlY2lmaWNhdGlvbg0KPiAoaS5lLiBw cm9oaWJpdCBWT1AgY29uY2F0ZW5hdGlvbiBpbiBjYXNlIG9mIHZhcmlhYmxlIGZyYW1lIHJhdGVz KSwgaW5zdGVhZA0KPiBvZiBhZGRpbmcgdGhlIGNvbXBsZXhpdHkgb2YgZXh0cmFjdGluZyBUUyBp bmZvcm1hdGlvbiB0aHJvdWdoIGNvb3BlcmF0aW9uIG9mDQo+IGRpZmZlcmVudCBsYXllcnMuDQo+ IEluIG90aGVyIHdvcmRzOiBWT1AgY29uY2F0ZW5hdGlvbiBoYXMgcHJvcyBhbmQgY29ucy4NCj4g UHJvczogb3B0aW1pemVzIGJhbmR3aWR0aCBjb25zdXB0aW9uDQo+IENvbnM6IGRldGVyaW9yYXRl cyBwYWNrZXQgbG9zcyByZXNpbGllbmNlOyBpbmNyZWFzZXMgaW1wbGVtZW50YXRpb24NCj4gY29t cGxleGl0eS4NCj4gSSB0aGVyZWZvcmUgZGVkdWNlIHRoYXQgVk9QIGNvbmNhdGVuYXRpb24gaXMg bmljZSBidXQgbm90IHRoYXQgd29uZGVyZnVsLA0KPiBhbmQgSSB3b3VsZCBzdWdnZXN0IHRvIGFs bG93IFZPUCBjb25jYXRlbmF0aW9uIG9ubHkgd2hlbiB0aGlzIGlzIHRyaXZpYWwgYW5kDQo+IGRv ZXMgbm90IHJlcXVpcmUgc2lnbmlmaWNhbnQgY29tcGxleGl0eSBpbiB0aGUgcmVjZWl2ZXJzIGlt cGxlbWVudGF0aW9ucy4NCj4gDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYWRkaXRpb25hbCBj b21wbGV4aXR5LiBNUEVHLTQgdmlkZW8gZGVjb2RlciBhbHdheXMgY2FsY3VsYXRlIHRoZSB0aW1l IGRpZmZlcmVuY2Ugb2YgY3VycmVudCBWT1AgZnJvbSB0aGUgbGFzdCBvbmUuICBTbywgd2hlbiB0 aGUgZGVjb2RlciBwdXNoIHRoZSByZWNvbnN0cnVjdGVkIGRhdGEgdG8gY29tcG9zaXRpb24gYnVm ZmVyLCBpdCBjYW4gZWFzaWx5IHNlbmQgYSBwcmVzZW50YXRpb24gdGltZSBpbmZvcm1hdGlvbiB0 byB0aGUgY29tcG9zaXRvci4gSXQgaXMgbm90aGluZyB0byB0aGUgaW1wbGVtZW50YXRpb24uDQoN ClNpbmNlcmVseSwNCllvdW5nLg0K From rem-conf Fri Sep 08 01:30:38 2000 From rem-conf-request@es.net Fri Sep 08 01:30:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XJRe-0000d4-00; Fri, 8 Sep 2000 01:23:34 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XJRY-0000cu-00; Fri, 8 Sep 2000 01:23:30 -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 RAA03087; Fri, 8 Sep 2000 17:21:40 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id RAA14753; Fri, 8 Sep 2000 17:21:40 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id RAA05916; Fri, 8 Sep 2000 17:21:39 +0900 (JST) Received: from default (tky0529.mobile.toshiba.co.jp [133.120.192.176]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id RAA17322; Fri, 8 Sep 2000 17:21:37 +0900 (JST) Message-ID: <04a801c0196d$d2d9e980$280f010a@default> From: "Yoshihiro Kikuchi" To: "Young-Kwon LIM" , "Jiro Katto" , Cc: <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <007c01c018ad$cfc532b0$013de8c3@Young> <00c901c0193f$e578b0e0$dcfa0985@katto.comm.waseda.ac.jp> <012701c0195c$e286bae0$f47d86c2@Young> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 8 Sep 2000 17:21:42 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Katto-san, Young-Kwon, all, > > 1. We suggest to have a room for future extension of RTP header (e.g. one byte > > of payload header at the beginning of the payload part) to make the devices > > implementing this draft interoperable with the bitstream based on the generic > > format under development. For example, it is possible to use the reserved byte to > > specify the length of the payload header of generic payload format. Then the device > > implementing this draft can play the bitstream of generic payload format by simply > > skipping those bytes. > > This may be good compromise. But, usage of extension byte in the MPEG-4 > payload header, instead of defining another payload header, seems to conclude > that the "generic" payload format is MPEG-4 "specific." Let me confirm that > "generic" means MPEG-4 generic, not applied to other codecs nor future ones. > As clearly described in the introduction, the intention of the MPEG-4 Audio/Visual payload format includes that this payload format will be used in the existing frameworks (such as H.323) in an ordinary way, and can be handled in an unified way together with those formats defined for non-MPEG-4 codecs. This, of cource, does not exclude the use in the MPEG's 4-on-IP framework, but we must be care that any changes will not harm the original intention. > > ==> Yes, you are right. The AHG group is working on MPEG-4 over IP. > I understand the importance of interoperability, however, isn't it better to ask IETF experts if the specific proposal of adding a reserved byte in the RTP header is really a general way also for other frameworks? I believe this is the intention of the comment. Kind regards, Yoshihiro Kikuchi ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Fri Sep 08 01:49:11 2000 From rem-conf-request@es.net Fri Sep 08 01:49:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XJnY-0001gX-00; Fri, 8 Sep 2000 01:46:12 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XJnW-0001gL-00; Fri, 8 Sep 2000 01:46:10 -0700 Received: from Young ([194.134.8.57]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000090817461660:43217 ; Fri, 8 Sep 2000 17:46:16 +0900 Message-ID: <000b01c01971$129530e0$390886c2@Young> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: "Yoshihiro Kikuchi" , "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> <02f401c0195c$89eefb40$280f010a@default> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Fri, 8 Sep 2000 17:38:51 +0900 Organization: TechWay 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-09-08 05:46:18 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-08 05:47:16 PM, Serialize complete at 2000-09-08 05:47:16 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-2022-jp" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBLaWt1Y2hpLXNhbiwNCg0KPiANCj4gVGhlcmVmb3JlLCBmcmFnbWVudGF0aW9uIHJ1bGUg KDQpIGluIHNlY3Rpb24gMy4yIGlzIGRlZmluZWQgdGhhdCBtdWx0aXBsZQ0KPiBWT1BzIFNIT1VM RCBOT1QgYmUgY29uY2F0ZW5hdGVkLiBUaGUgY29uY2F0ZW5hdGlvbiBpcyBhbiBleGNlcHRpb24g cnVsZSBvbmx5DQo+IHdoZW4gVk9QIHNpemUgaXMgc21hbGwuDQo+IA0KPiAgICAoNCkgVHdvIG9y IG1vcmUgVk9QcyBTSE9VTEQgYmUgZnJhZ21lbnRlZCBpbnRvIGRpZmZlcmVudCBSVFAgcGFja2V0 cyBzbw0KPiAgICB0aGF0IG9uZSBSVFAgcGFja2V0IGNvbnNpc3RzIG9mIHRoZSBkYXRhIGJ5dGVz IGFzc29jaWF0ZWQgd2l0aCBhIHVuaXF1ZQ0KPiAgICBwcmVzZW50YXRpb24gdGltZSAodGhhdCBp cyBpbmRpY2F0ZWQgaW4gdGhlIHRpbWVzdGFtcCBmaWVsZCBpbiB0aGUgUlRQDQo+ICAgIHBhY2tl dCBoZWFkZXIpLCB3aXRoIHRoZSBleGNlcHRpb24gdGhhdCBtdWx0aXBsZSBWT1BzIE1BWSBiZSBj YXJyaWVkDQo+ICAgIHdpdGhpbiBvbmUgUlRQIHBhY2tldCBpZiB0aGUgc2l6ZSBvZiB0aGUgVk9Q cyBpcyBzbWFsbC4NCg0KSSdtIE9LIHdpdGggdGhpcyBiZWNhdXNlIHRoaXMgYWxsb3dzIGNvbmNh dGVuYXRpb24gb2YgVk9Qcy4gRm9yIG1vcmUgY2xhcmlmaWNhdGlvbiBJJ2QgbGlrZSB0byBhZGQg IldoZW4gbXVsdGlwbGUgVk9QcyBhcmUgY2FycmllZCBpbiBvbmUgUlRQIHBheWxvYWQsIHRoZSBw cmVzZW50YXRpb24gdGltZSBvZiB0aGUgVk9QcyBhZnRlciB0aGUgZmlyc3Qgb25lIG1heSBiZSBj YWxjdWxhdGVkIGJ5IHRoZSBkZWNvZGVyLiIgDQoNCkJUVywgd2hlcmUgaXMgYSBzZW50ZW5jZSBw cm9oaWJpdGluZyBjb25jYXRlbmF0aW9uIG9mIFZPUHMgd2l0aCBkaWZmZXJlbnQgZGVjb2Rpbmcg b3JkZXI/DQoNClNpbmNlcmVseSwNCllvdW5nLg0K From rem-conf Fri Sep 08 04:02:07 2000 From rem-conf-request@es.net Fri Sep 08 04:02:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XLrX-0003QH-00; Fri, 8 Sep 2000 03:58:27 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13XLrT-0003Q7-00; Fri, 8 Sep 2000 03:58:25 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-177.dialup.cs.tu-berlin.de [130.149.145.177]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id MAA15720; Fri, 8 Sep 2000 12:55:39 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000908123733.02d71890@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Sep 2000 12:55:27 +0200 To: "Young-Kwon LIM" From: Stephan Wenger Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Cc: , <4on2andIP-sys@advent.ee.columbia.edu> In-Reply-To: <007c01c018ad$cfc532b0$013de8c3@Young> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, >1. We suggest to have a room for future extension of RTP header (e.g. one >byte of payload header at the beginning of the payload part) to make the >devices implementing this draft interoperable with the bitstream based on >the generic format under development. For example, it is possible to use >the reserved byte to specify the length of the payload header of generic >payload format. Then the device implementing this draft can play the >bitstream of generic payload format by simply skipping those bytes. I'm not sure whether this is a good idea. We would waste one byte of payload (from RTP's point of view) for something which is probably not used by any systems currently under discussion or development. Regardless how the generic payload format of the future may look like, systems can be most easily designed to support both payload types. RTP's PT mechanism has enough numbering space to support both. Capability announcement/negotiation will be different and have to be redesigned anyway for anything more capable then what is currently in the MPEG-4 ES draft. Annoucing/Negotiating another PT for the new generic payload spec will not make a difference. When, in the future, a generic payload type would be available that includes a super set of functionality of the MPEG-4 ES payload format, then we could declare the MPEG-4 ES RFC as obsolete, thereby advising people to move over to the new, generic payload type. Or, it may also be possible to have two payload specs coexisting, one for simple audio/video ES packetization only, the other containing more (the rest of?) functionality of MPEG-4. This does not sound like a bad idea to me, because the necessary demands of functionality both from the network (in terms of QoS) and implementation efforts (single audio/visual ESs vs. system layer, flexmux, whatever...) are very different. Please let the header format as is -- no more changes, otherwise you can almost certainly forget the deadline you want to meet (mid November's SG16 meeting). Stephan From rem-conf Fri Sep 08 04:43:19 2000 From rem-conf-request@es.net Fri Sep 08 04:43:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XMTq-0004ax-00; Fri, 8 Sep 2000 04:38:02 -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 13XMTo-0004an-00; Fri, 8 Sep 2000 04:38:01 -0700 Received: from i810 ([133.9.250.220]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id UAA06131; Fri, 8 Sep 2000 20:37:31 +0900 Message-ID: <001d01c01988$e6cb3e60$dcfa0985@katto.comm.waseda.ac.jp> From: "Jiro Katto" To: "Yoshihiro Kikuchi" , "Young-Kwon LIM" , Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <007c01c018ad$cfc532b0$013de8c3@Young> <00c901c0193f$e578b0e0$dcfa0985@katto.comm.waseda.ac.jp> <012701c0195c$e286bae0$f47d86c2@Young> <04a801c0196d$d2d9e980$280f010a@default> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 8 Sep 2000 20:35:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 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 RGVhciBLaWt1Y2hpLXNhbiBhbmQgYWxsLCANCg0KPiA+IFRoaXMgbWF5IGJlIGdvb2QgY29tcHJv bWlzZS4gQnV0LCB1c2FnZSBvZiBleHRlbnNpb24gYnl0ZSBpbiB0aGUgTVBFRy00DQo+ID4gcGF5 bG9hZCBoZWFkZXIsIGluc3RlYWQgb2YgZGVmaW5pbmcgYW5vdGhlciBwYXlsb2FkIGhlYWRlciwg c2VlbXMgdG8NCj4gPiBjb25jbHVkZSB0aGF0IHRoZSAiZ2VuZXJpYyIgcGF5bG9hZCBmb3JtYXQg aXMgTVBFRy00ICJzcGVjaWZpYy4iIExldCBtZSANCj4gPiBjb25maXJtIHRoYXQgImdlbmVyaWMi IG1lYW5zIE1QRUctNCBnZW5lcmljLCBub3QgYXBwbGllZCB0byBvdGhlciBjb2RlY3MgDQo+ID4g bm9yIGZ1dHVyZSBvbmVzLg0KPiANCj4gQXMgY2xlYXJseSBkZXNjcmliZWQgaW4gdGhlIGludHJv ZHVjdGlvbiwgdGhlIGludGVudGlvbiBvZiB0aGUgTVBFRy00DQo+IEF1ZGlvL1Zpc3VhbCBwYXls b2FkIGZvcm1hdCBpbmNsdWRlcyB0aGF0IHRoaXMgcGF5bG9hZCBmb3JtYXQgd2lsbCBiZSB1c2Vk DQo+IGluIHRoZSBleGlzdGluZyBmcmFtZXdvcmtzIChzdWNoIGFzIEguMzIzKSBpbiBhbiBvcmRp bmFyeSB3YXksIGFuZCBjYW4gYmUNCj4gaGFuZGxlZCBpbiBhbiB1bmlmaWVkIHdheSB0b2dldGhl ciB3aXRoIHRob3NlIGZvcm1hdHMgZGVmaW5lZCBmb3Igbm9uLU1QRUctNA0KPiBjb2RlY3MuIFRo aXMsIG9mIGNvdXJjZSwgZG9lcyBub3QgZXhjbHVkZSB0aGUgdXNlIGluIHRoZSBNUEVHJ3MgNC1v bi1JUA0KPiBmcmFtZXdvcmssIGJ1dCB3ZSBtdXN0IGJlIGNhcmUgdGhhdCBhbnkgY2hhbmdlcyB3 aWxsIG5vdCBoYXJtIHRoZSBvcmlnaW5hbA0KPiBpbnRlbnRpb24uDQoNCkkganVzdCB3YW50ZWQg dG8ga25vdyB0aGUgYXJlYSB0aGF0IHRoZSB3b3JkICJnZW5lcmljIiBjb3ZlcnMuIA0KSSB0aG91 Z2h0IGl0IGlzIG9ic2N1cmUgYW5kLCB3aGVuIHVzZWQsIGl0IHNob3VsZCBiZSBhcHBsaWVkIHRv IGEgDQpiaWdnZXIgcGljdHVyZS4gDQoNCkkgdGhpbmsgYm90aCBvZiBjdXJyZW50IHR3byBmb3Jt YXRzIChFUy1zcGVjaWZpYyBhbmQgU0wtc3BlY2lmaWMpIA0KZG8gbm90IGJyZWFrIGV4aXN0aW5n IGZyYW1ld29ya3MgKGUuZywgSC4zMjMpIG5vciB0aGUgb3JpZ2luYWwgU0wtDQpsYXllciBjb25j ZXB0LiBUaGlzIGZhY3Qgc2hvdWxkIGJlIGtlcHQgaW4gZnV0dXJlLiBBIHNpbmdsZSBmb3JtYXQg DQpvciB0d28gZm9ybWF0cyBhcmUgbm90IG15IGludGVudGlvbi4NCg0KPiA+ID09PiBZZXMsIHlv dSBhcmUgcmlnaHQuIFRoZSBBSEcgZ3JvdXAgaXMgd29ya2luZyBvbiBNUEVHLTQgb3ZlciBJUC4N Cj4gDQo+IEkgdW5kZXJzdGFuZCB0aGUgaW1wb3J0YW5jZSBvZiBpbnRlcm9wZXJhYmlsaXR5LCBo b3dldmVyLCBpc24ndCBpdCBiZXR0ZXIgdG8NCj4gYXNrIElFVEYgZXhwZXJ0cyBpZiB0aGUgc3Bl Y2lmaWMgcHJvcG9zYWwgb2YgYWRkaW5nIGEgcmVzZXJ2ZWQgYnl0ZSBpbiB0aGUNCj4gUlRQIGhl YWRlciBpcyByZWFsbHkgYSBnZW5lcmFsIHdheSBhbHNvIGZvciBvdGhlciBmcmFtZXdvcmtzPw0K Pg0KPiBJIGJlbGlldmUgdGhpcyBpcyB0aGUgaW50ZW50aW9uIG9mIHRoZSBjb21tZW50Lg0KDQpZ ZXMsIHRoYXQgbXVzdCBiZS4gVGhhbmsgeW91IGZvciB5b3VyIHRyYW5zbGF0aW9uLg0KDQpCZXN0 IHJlZ2FyZHMsDQotLQ0KSmlybyBLYXR0bw0KV2FzZWRhIFVuaXZlcnNpdHkNCg== From rem-conf Fri Sep 08 05:41:36 2000 From rem-conf-request@es.net Fri Sep 08 05:41:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XNQL-0005yD-00; Fri, 8 Sep 2000 05:38:29 -0700 Received: from snipe.prod.itd.earthlink.net [207.217.120.62] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XNQH-0005xf-00; Fri, 8 Sep 2000 05:38:25 -0700 Received: from ryan (pool0049.cvx25-bradley.dialup.earthlink.net [209.179.216.49]) by snipe.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id FAA05950; Fri, 8 Sep 2000 05:36:34 -0700 (PDT) Date: Fri, 8 Sep 2000 05:36:34 -0700 (PDT) From: ryanben4@yahoo.com Message-Id: <200009081236.FAA05950@snipe.prod.itd.earthlink.net> To: ryanben4@yahoo.com Subject: Does your job pay you CASH? MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by snipe.prod.itd.earthlink.net id FAA05950 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As simple as this sounds, it works. And there is HUGE money in it! So far, I've made $835 in two weeks and it's not slowing down. If you are serious about making some extra money real fast legally and ethically, this is something you definitely want to read! This e-mail contains the ENTIRE PLAN of how YOU can make up to $50,000 or more in the next 90 days simply sending e-mail! Seem impossible? Just read on and see how real this is=85. It=92s YOUR turn!!! 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 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 have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more and more people try it out, it's been very exciting. You will understand once you try it yourself! ******THE ENTIRE PLAN IS HERE BELOW****** ***Print This Now For Future Reference*** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make up to $50,000 in less than 90 days, please read this program=85THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello =96 My name is Jonathan Rourke; I=92m from Rhode Island. In mid December, I received this program in my e-mail. Six months 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. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn=92t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and 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 I decided "WHY NOT!!! Initially I sent out 10,000 e-mails, so my only expense is my time. 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=92T, 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, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won=92t work if you don=92t 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=92t work and you=92ll 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 your want to start your own business, consider this a sigh. I DID!!! Sincerely, Jonathan 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=92t working. Finally, I figured it out. It wasn=92t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don=92t 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 know 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 you 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 retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY ASINSTRUCTED. 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=85 and your name will be on every one of them! Remember though, the more you send out, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. $$$IT WORKS!!!$$$ HERE=92S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. As with all multi-level business, 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material. Keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future!!! PLAN SUMMARY: 1.You order the 4 reports listed below ($5 each) They come to you by e-mail 2.Save a copy of this entire letter and put your name after Report #1 and move the other names down. 3.Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for "Bulk e-mail" and have them send 25,000 =96 50,000 e-mails for you.) 4.Orders will come to you by postal mail- simply e-mail them the Report they ordered. Let me ask you =96 isn=92t this about as easy as it gets? By the way there are over 100 MILLION e-mail addresses with millions more joining the internet each year so don=92t worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter I received this letter many times =96 then one day I decided it was time to try it. YOU CAN START TODAY =96 JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can=92t sell them if you don=92t order them). =96 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! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000=92s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a.Look below for the listing of the four reports. b.After you=92ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c.Move the name and address under REPORT #3 down to REPORT #4. d.Move the name and address under REPORT #2 down to REPORT #3. e.Move the name and address under REPORT #1 down to REPORT #2. f.Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk e-mail software and e-mail addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let=92s say that you decide to start small, just to see how it goes, and we=92ll assume you and all those involved e-mail out only 2,000 programs each. Let=92s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will e-mail out hundreds of thousands of programs instead of 2,000 (Why stop at 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=92s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 +$5,00 + $50,000 for a total of $55,550!!! REMEMBER, 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 THAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000 Believe me, many people will do just that, and more! METHOD #2 =96 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let=92s 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. Look how this small number accumulates to achieve the STAGGERING results below: 1st level: your first 10 send you $5=85=85=85=85.$50 2nd level: 10 members from those 10 ($5 x 100)=85=85=85.$500 3rd level: 10 members from those 100 ($5 x 1,000)=85=85$5,000 4th level: 10 members from those 1,000 ($5 x 10,000)=85$50,000 $$$$$$$$$$$$THIS TOTALS------------$55,550$$$$$$$$$$$$$$ AMAZING ISN=92T IT? Remember, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100=92s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get e-mails about this plan from you or somebody else and many will work this plan- the question is =96 Don=92t you want your name to be on the e-mails they send out? ***DON=92T MISS OUT!!!***JUST TRY IT ONCE!!!*** ***SEE WHAT HAPPENS!!!***YOU=92LL BE AMAZED!!!*** 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=92t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Enclose the $5 with a sheet of paper including: a.the number & name of the report you are ordering. b.Your e-mail address, c.Your name & postal address. REPORT #1 "The Insider=92s Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM Ryan Doyle 3327 Boyce Ln. San Diego, CA 92105 REPORT #2 "The Insider=92s Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM Max Glinsky 3532 Governor Dr. La Jolla, CA 92122 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM Randy Catlett 817 W. Iola Pl. Broken Arrow, OK 74012 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM Vic Roberts HC 34 Box 2831 Wasilla, AK 99688 *************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- If you follow the instructions exactly =96 results WILL FOLLOW.$$$$ ***********YOUR SUCCESS GUIDELINES*************** Follow these guidelines to guarantee your success" If you don=92t 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=92t 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. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1.NO face to face selling, NO meetings, NO inventory, NO Telephone calls, NO big cost to start, Nothing to learn, NO skills needed! (Surely you know how to send e-mail?) 2.NO equipment to buy =96 you already have a computer and internet connection =96 so you have everything you need to fill orders! 3.You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (e-mailing copies of the reports is FREE!) 4.All of your customers pay you in CA$H! This program will change your LIFE FOREVER!!! Look at the potential for you to be able to work a super-high paying leisurely easy business from home! $$$$$$FINALLY MAKE SOME DREAMS COME TRUE!$$$$$ ACT NOW! Take your first step toward making some extra cash, or even achieving financial independence. Order the reports and follow the program outlined above=97SUCCESS will be your reward. See you at the top. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities 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. Under Bill s.1618 TITLE 111 passed by the 105th US Congress, this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From rem-conf Fri Sep 08 07:03:33 2000 From rem-conf-request@es.net Fri Sep 08 07:03:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XOgi-0007UX-00; Fri, 8 Sep 2000 06:59:28 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XOgg-0007UN-00; Fri, 8 Sep 2000 06:59:26 -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 WAA02834; Fri, 8 Sep 2000 22:58:53 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id WAA17441; Fri, 8 Sep 2000 22:58:53 +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 VAA29549; Fri, 8 Sep 2000 21:35:49 +0900 (JST) Received: from default (kwa0207.mobile.toshiba.co.jp [133.120.199.39]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id VAA31891; Fri, 8 Sep 2000 21:35:45 +0900 (JST) Message-ID: <00f701c01991$54a18e00$27c77885@default> From: "Yoshihiro Kikuchi" To: "Young-Kwon LIM" , "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "Varesio Andrea" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E1677940034E9C@exc2k02.cselt.it> <02f401c0195c$89eefb40$280f010a@default> <000b01c01971$129530e0$390886c2@Young> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Fri, 8 Sep 2000 21:35:51 +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 Young-Kwon, Guido, Matsui-san, Imura-san, all, Thank you very much for the comment. It seems to be better to list all description related the multiple VOPs concatenation in the "current" draft text posted on Sep. 5 here in this mail for the better understandings. 1. Introduction The fragmentation rule recommends not to map more than one VOP in an RTP packet so that 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 a not coded VOP containing only VOP header or an arbitrary shaped VOP with a small number. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet when the VOP size is small. 3.1 Use of RTP header fields for MPEG-4 Visual 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: - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the composition time within the VOPs carried in the RTP packet. 3.2 Fragmentation of MPEG-4 Visual bitstream (4) Two or more 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 VOPs MAY be carried within one RTP packet if the size of the VOPs is small. I think it is better to add cross-references (see section ..., definition of ....) for each description above in the draft so that every readers of the draft can understand this set of rule easily. Young-Kwon wrote: > I don't think there is additional complexity. MPEG-4 video decoder always calculate the time difference of current VOP from the last one. So, when the decoder push the reconstructed data to composition buffer, it can easily send a presentation time information to the compositor. It is nothing to the implementation. > I'm OK with this because this allows concatenation of VOPs. Oh, now there are agreements on the current description. As usual, if there is any other strong disagreements, we should stick with the current text. (except for editorial changes and clarifications) Please look not only sentences I posted but a set of rules. It is defined that multiple VOPs SHOULD NOT be concatenated so as not to force huge amout of complexity. The concatenation is an exception rule only when VOP size is small. >For more clarification I'd like to add "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." > Agreed. > BTW, where is a sentence prohibiting concatenation of VOPs with different decoding order? There is no sentence now in the draft but only in mails exchanged. Following is the list of proposed changes by mails on this issue for editorial update and clarifications but not technical. 1) Add cross-cross references to each descriptions. 2) Add the following sentence to the timestamp definition "Timestamp information of the rest of VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment)." 3) Add the following description as a note to fragmentation rule (4) "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 satisfying the following both two conditions: - Marker bit equal to one, and (Because marker bit in section 3.1 is defined that it is set to one when multiple VOP is concatenated.) - The beginning of RTP payload is not a start code. (Because the fragmentation rule is defined that a start code is placed always at the beginning of RTP payload, if exists.)" If there is no further objection, only changes reflected to the next version of I/D will be these descriptions for editorial update and clarifications. 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 Sep 08 07:06:24 2000 From rem-conf-request@es.net Fri Sep 08 07:06:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XOlh-00000h-00; Fri, 8 Sep 2000 07:04:37 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XOlf-00000S-00; Fri, 8 Sep 2000 07:04:35 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA01628; Fri, 8 Sep 2000 10:04:42 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id TAA22806; Fri, 8 Sep 2000 19:04:20 +0500 Message-Id: <200009081404.TAA22806@hafez.east.isi.edu> To: Young-Kwon LIM cc: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Thu, 07 Sep 2000 18:19:41 +0900." <007c01c018ad$cfc532b0$013de8c3@Young> Date: Fri, 08 Sep 2000 10:04:20 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Young-Kwon LIM writes: >Dear Collin and AVT working group members, > >Yesterday 20 MPEG experts had an AHG meeting at Paris. We discussed the >technical problems and the solutions in terms of basic interoperabilities >what we want to achieve form the ongoing work to develop overall framework >for carriage of MPEG-4 content over IP. Based on the consensus of the AHG >members, we would like to make two comments to possibly ensure the basic >interoperabilities between the payload format of this draft and the generic >payload foramt under development. > >1. We suggest to have a room for future extension of RTP header (e.g. one >byte of payload header at the beginning of the payload part) to make the >devices implementing this draft interoperable with the bitstream based on >the generic format under development. For example, it is possible to use >the reserved byte to specify the length of the payload header of generic >payload format. Then the device implementing this draft can play the >bitstream of generic payload format by simply skipping those bytes. I agree with the comment made by Stephan Wenger. The RTP payload type field is intended to differentiate formats, and I don't believe that this byte will sufficiently aid future interoperability to make its inclusion worthwhile. >2. We request to clarify the usage of LATM. It was recognized during the >meeting that there seems no reason to use multiplexing feature of LATM for >the purpose of this draft. In addition, limiting the usage of LATM to carry >configuation information and concatenation of audio frames is desirable to >make this draft more compatible to the generic payload format under >development. There is indeed no need for the multiplexing features of LATM. Is the gain of designing an alternative header worth it? We may simply specify that that feature of LATM should not be used? Colin From rem-conf Fri Sep 08 07:40:33 2000 From rem-conf-request@es.net Fri Sep 08 07:40:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XPFS-0001iW-00; Fri, 8 Sep 2000 07:35:22 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XPFQ-0001hw-00; Fri, 8 Sep 2000 07:35:20 -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 <0G0K005FHOG3SD@ss3000e.cselt.it> for rem-conf@es.net; Fri, 8 Sep 2000 16:33:40 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Fri, 08 Sep 2000 16:35:56 +0200 Content-return: allowed Date: Fri, 08 Sep 2000 16:33:42 +0200 From: Franceschini Guido Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt To: Young-Kwon LIM , Franceschini Guido , Koji Imura , IETF AVT , Colin Perkins , Varesio Andrea , 'Yoshihiro Kikuchi' Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <85077463E51D6A498C453073E1677940034EAC@exc2k02.cselt.it> 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 Some further comment below > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Friday, September 08, 2000 2:35 PM > To: Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF AVT; Colin > Perkins; Varesio Andrea > Cc: 4on2andIP-sys; Yoshihiro Kikuchi > Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > > Dear Young-Kwon, Guido, Matsui-san, Imura-san, all, > > Thank you very much for the comment. > > It seems to be better to list all description related the multiple VOPs > concatenation in the "current" draft text posted on Sep. 5 here in this > mail > for the better understandings. > > 1. Introduction > The fragmentation rule recommends not to map more than one VOP in an > RTP > packet so that 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 a not coded VOP containing only VOP header or an arbitrary > shaped VOP with a small number. To reduce the overhead for such cases, > the fragmentation rule permits concatenating multiple VOPs in an RTP > packet when the VOP size is small. Editorial: I don't think the last statement 'when the VOP size is small' is necessary/appropriate > 3.1 Use of RTP header fields for MPEG-4 Visual > 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: > - When multiple VOPs are carried in the same RTP packet, the timestamp > indicates the earliest of the composition time within the VOPs > carried > in the RTP packet. > > 3.2 Fragmentation of MPEG-4 Visual bitstream > (4) Two or more 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 VOPs MAY be carried > within one RTP packet if the size of the VOPs is small. Editorial: again, what is the meaning of 'small' ? Also, at the beginning, I would change to 'Different VOPs SHOULD be fragmented into different RTP packets' > I think it is better to add cross-references (see section ..., definition > of > ....) for each description above in the draft so that every readers of the > draft can understand this set of rule easily. > > Young-Kwon wrote: > > > I don't think there is additional complexity. MPEG-4 video decoder > always > calculate the time difference of current VOP from the last one. So, when > the decoder push the reconstructed data to composition buffer, it can > easily > send a presentation time information to the compositor. It is nothing to > the > implementation. > > > I'm OK with this because this allows concatenation of VOPs. > > Oh, now there are agreements on the current description. As usual, if > there > is any other strong disagreements, we should stick with the current text. > (except for editorial changes and clarifications) > > Please look not only sentences I posted but a set of rules. It is defined > that multiple VOPs SHOULD NOT be concatenated so as not to force huge > amout > of complexity. The concatenation is an exception rule only when VOP size > is > small. Just to make my point clear: either you quantify 'small', or you can at most say something like: "concatenation is allowed only when an integral number of VOPs fit into a single RTP packet" I would suggest to have some text clearly specifying under which circumstances VOP concatenation may occur: Some idea for this text: Concatenation is allowed only when the following conditions occur: - the result of concatenting N consecutive VOPs still fits into a single RTP packet - the presentation and decoding order of the VOPs is identical - ... > >For more clarification I'd like to add "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." > > > Agreed. > > > BTW, where is a sentence prohibiting concatenation of VOPs with > different > decoding order? > > There is no sentence now in the draft but only in mails exchanged. > > Following is the list of proposed changes by mails on this issue for > editorial update and clarifications but not technical. > > 1) Add cross-cross references to each descriptions. > 2) Add the following sentence to the timestamp definition > "Timestamp information of the rest of VOPs are derived from the > timestamp fields in the VOP header (modulo_time_base and > vop_time_increment)." > 3) Add the following description as a note to fragmentation rule (4) > "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 satisfying the > following both two conditions: > - Marker bit equal to one, and > (Because marker bit in section 3.1 is defined that it is set to one when > multiple VOP is concatenated.) > - The beginning of RTP payload is not a start code. > (Because the fragmentation rule is defined that a start code is placed > always at the beginning of RTP payload, if exists.)" I do not understand this second condition. I would have reversed it "The beginning of RTP payload corresponds to a start code" Bye Guido > If there is no further objection, only changes reflected to the next > version > of I/D will be these descriptions for editorial update and clarifications. > > > 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 Sep 08 10:33:54 2000 From rem-conf-request@es.net Fri Sep 08 10:33:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XS00-0005fy-00; Fri, 8 Sep 2000 10:31:36 -0700 Received: from meshsv501.tk.mesh.ad.jp [133.205.16.137] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XRzz-0005fn-00; Fri, 8 Sep 2000 10:31:35 -0700 Received: from saru (p716.asi.euronet.nl [194.134.124.208]) by meshsv501.tk.mesh.ad.jp (8.8.8+2.7Wbeta7/3.5Wpl7-98060115) with SMTP id CAA03305; Sat, 9 Sep 2000 02:31:18 +0900 (JST) Message-ID: <005801c019bc$65f56160$1b41fea9@saru> From: "Toshiyuki Nomura" To: "Young-Kwon LIM" , "Colin Perkins" Cc: "rem-conf" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> References: <200009081404.TAA22806@hafez.east.isi.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Sat, 9 Sep 2000 02:44:04 +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 Content-Length: 914 Lines: 28 Dear Colin and Young, > >2. We request to clarify the usage of LATM. It was recognized during the > >meeting that there seems no reason to use multiplexing feature of LATM for > >the purpose of this draft. In addition, limiting the usage of LATM to carry > >configuation information and concatenation of audio frames is desirable to > >make this draft more compatible to the generic payload format under > >development. > > There is indeed no need for the multiplexing features of LATM. Is the gain > of designing an alternative header worth it? We may simply specify that > that feature of LATM should not be used? I think the content of Comment 1 does not relate to Comment 2. Anyway, if I get the consensus from MPEG Audio experts, I'll modify Introduction of the I/D to specify that some features of LATM should not be used in RTP transmission. Best Regards, Toshiyuki Nomura, NEC --------------------- From rem-conf Fri Sep 08 13:08:42 2000 From rem-conf-request@es.net Fri Sep 08 13:08:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XUOn-0003sm-00; Fri, 8 Sep 2000 13:05:21 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XUOl-0003od-00; Fri, 8 Sep 2000 13:05:20 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 14:04:19 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA747644@el-postino.s-vision.com> From: Kris Huber To: Young-Kwon LIM , Franceschini Guido , Koji Imura , IETF AVT , Colin Perkins , 'Yoshihiro Kikuchi' , Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, garysull@microsoft.com Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP Date: Fri, 8 Sep 2000 14:04:15 -0600 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 Content-Length: 7516 Lines: 156 Dear Young and all, Unless "MAY" is changed to "SHOULD" in "When the short video header mode is used, the RTP payload format used MAY be that specified for H.263 in the relevant RFCs or in other relevant standards," I think additional modifications are necessary to accommodate MPEG-4 short header mode. This is because vop_time_increment_resolution, modulo_time_base, and time_code are not present in a short header elementary stream. Here is my proposed modification (new text is indicated by surrounding it by "<<" and ">>"). No deletions are required. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. A constant offset, which is random, is added for security reasons. The detailed definition of the timestamp is as follows: << - For a video object plane with short header, the timestamps (after the first random timestamp) are equal to the presentation time sequence associated with the semantics of the temporal_reference field. Specifically, each timestamp value SHALL be calculated by rounding the value of a precise clock that advances delta_time with each successive video object plane with short header. The time increment SHOULD be calculated as delta_time = (((temporal_reference + 256 - (temporal_reference of previous VOP) modulo 256) * 1001/30000) for each successive video object plane with short header. The RTP timestamp should be consistently rounded or truncated to the resolution of the RTP timestamp field.>> - <> for a video object plane, it is defined as vop_time_increment (in units of 1/vop_time_increment_resolution seconds) plus the cumulative number of whole seconds specified by modulo_time_base and, if present, time_code of Group_of_VideoObjectPlane() fields. - In the case of interlaced video, a VOP will consist of lines from two fields, and the timestamp will indicate the composition time of the first field. ( - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the composition time within the VOPs carried in the RTP packet.) Young-Kwon's proposed modification of the above bullet: - When multiple VOPs are carried in the same RTP packet, the timestamp indicates the earliest of the composition time<> within the VOPs carried in the RTP packet. Timestamp information of the rest of <> VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment)<<, or from the temporal_reference field in the case of short video header>>. - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the composition time of the next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the composition time of the immediately preceding VOP in the coding order is used. Perhaps someone knows better wording for the first bullet. I used SHALL in that paragraph to prevent accumulation of round-off error in the sequence of time stamps, and SHOULD to allow for other picture clock frequencies than the one specified in the MPEG-4 visual semantics. More detail about this difference in MPEG-4 short header and H.263 semantics follows: Quoting ISO/IEC 14496-2:1999, clause 6.3.5.2: "temporal reference: This is an 8-bit number which can have 256 possible values. It is formed by incrementing its value in the previously transmitted video_plane_with_short_header() by one plus the number of non-transmitted pictures (at 30000/1001 Hz) since the previously transmitted picture. The arithmetic is performed with only the eight LSBs." In contrast the TR field in the H.263 spec allows different clocks than 29.97 Hz: "the value of TR is formed by incrementing its value in the temporally-previous reference picture header by one plus the number of skipped or non-reference pictures at the picture clock frequency since the previously transmitted one. The interpretation of TR depends upon the active picture clock frequency. ..." Negotiation of the picture clock frequency is done by external means, I believe. I suspect that fixing the H.263 TR frequency in the MPEG-4 temporal_reference semantics causes problems particularly for use of short- header on 25 Hz material in Europe. As I noted in the first sentence, an alternative to describing how to compute timestamp in short header mode is simply to change MAY to SHOULD or SHALL regarding use of H.263 payload format for short header mode. Best regards, Kris Huber Sorenson Laboratories, Inc. -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Friday, September 08, 2000 1:08 AM To: Franceschini Guido; Koji Imura; IETF AVT; Colin Perkins; 'Yoshihiro Kikuchi'; Varesio Andrea Cc: 4on2andIP-sys Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Dear Guido and all, > > > > It would be better to add a description to clarify this. How about adding > > the following description in the timestamp definition in section 3.1? > > > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the composition time within the VOPs carried in > > the RTP packet. Timestamp information of the rest of VOPs are derived from > > the timestamp fields in the VOP header (modulo_time_base and > > vop_time_increment).? > > > Are you sure you want to possibly indicate the CTS of the second VOP in a > packet ? > This seems to me quite difficult to manage > I would better do either of the following: > - always indicate the CTS of the first VOP in the packet, even if the second > VOP will be presented first > - disallow concatenation of VOPs whose decoding order differs from the > composition order "modulo_time_base" and "vop_time_increment" are the syntax elements of VOP header invented for the purpose of carrying relative timing information. So, I don't see any problem to use those information to calcute CTS. When the receiver get a RTP packet with multiple VOPs, the CTS of first VOP can be derived from the RTP time stmap and CTS of successive VOPs can be calculated by using time stamp and two syntax elements in VOP header. Calculating timing information of each VOP is nothing new to the decoder. > > I am also doubtful about allowing variable frame rate videos to take > advantage of such concatenation of VOPs in the same RTP packet. > IMHO it would be safer to add some more constraints in the specification > (i.e. prohibit VOP concatenation in case of variable frame rates), instead > of adding the complexity of extracting TS information through cooperation of > different layers. > In other words: VOP concatenation has pros and cons. > Pros: optimizes bandwidth consuption > Cons: deteriorates packet loss resilience; increases implementation > complexity. > I therefore deduce that VOP concatenation is nice but not that wonderful, > and I would suggest to allow VOP concatenation only when this is trivial and > does not require significant complexity in the receivers implementations. > I don't think there is additional complexity. MPEG-4 video decoder always calculate the time difference of current VOP from the last one. So, when the decoder push the reconstructed data to composition buffer, it can easily send a presentation time information to the compositor. It is nothing to the implementation. Sincerely, Young. From rem-conf Fri Sep 08 14:53:55 2000 From rem-conf-request@es.net Fri Sep 08 14:53:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XW06-0005zT-00; Fri, 8 Sep 2000 14:47:58 -0700 Received: from mail3.microsoft.com [131.107.3.123] by mail1.es.net with smtp (Exim 1.81 #2) id 13XW04-0005zH-00; Fri, 8 Sep 2000 14:47:56 -0700 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Sep 2000 14:42:48 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Sep 2000 14:44:25 -0700 Message-ID: <6CEF693DEA38994786B8F1B115897A2E220FE8@red-msg-06.redmond.corp.microsoft.com> From: Gary Sullivan To: 'Kris Huber' , Young-Kwon LIM , Franceschini Guido , Koji Imura , IETF AVT , Colin Perkins , 'Yoshihiro Kikuchi' , Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP Date: Fri, 8 Sep 2000 14:44:15 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 11525 Lines: 302 Kris et al, A bit of H.263 explanation with a bit of a history lesson is spliced into Kris's quoted message below: +> -----Original Message----- +> From: Kris Huber [mailto:khuber@sorensonlabs.com] +> Sent: Friday, September 08, 2000 1:04 PM +> To: Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF +> AVT; Colin Perkins; 'Yoshihiro Kikuchi'; Varesio Andrea +> Cc: 4on2andIP-sys; Gary Sullivan +> Subject: RE: IETF AVT last call on +> draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP +> +> +> Dear Young and all, +> +> Unless "MAY" is changed to "SHOULD" in "When the short video +> header mode is +> used, the RTP payload format used MAY be that specified for +> H.263 in the +> relevant RFCs or in other relevant standards," I think additional +> modifications are necessary to accommodate MPEG-4 short +> header mode. This +> is because vop_time_increment_resolution, modulo_time_base, +> and time_code +> are not present in a short header elementary stream. Here +> is my proposed +> modification (new text is indicated by surrounding it by +> "<<" and ">>"). +> No deletions are required. +> +> Timestamp: The timestamp indicates the composition time, or the +> presentation time in a no-compositor decoder. A constant +> offset, which is +> random, is added for security reasons. The detailed +> definition of the +> timestamp is as follows: +> << - For a video object plane with short header, the +> timestamps (after the +> first random timestamp) are equal to the presentation time sequence +> associated with the semantics of the temporal_reference field. +> Specifically, each timestamp value SHALL be calculated by +> rounding the +> value of a precise clock that advances delta_time with each +> successive +> video object plane with short header. The time increment SHOULD be +> calculated as delta_time = (((temporal_reference + 256 - +> (temporal_reference of previous VOP) modulo 256) * +> 1001/30000) for each +> successive video object plane with short header. The RTP +> timestamp should +> be consistently rounded or truncated to the resolution of +> the RTP timestamp +> field.>> +> - <> for a video object plane, it is defined as +> vop_time_increment (in units +> of 1/vop_time_increment_resolution seconds) plus the +> cumulative number +> of whole seconds specified by modulo_time_base and, if present, +> time_code of Group_of_VideoObjectPlane() fields. +> - In the case of interlaced video, a VOP will consist of +> lines from two +> fields, and the timestamp will indicate the composition +> time of the +> first field. +> ( - When multiple VOPs are carried in the same RTP packet, +> the timestamp +> indicates the earliest of the composition time within +> the VOPs carried +> in the RTP packet.) +> Young-Kwon's proposed modification of the above bullet: +> - When multiple VOPs are carried in the same RTP packet, +> the timestamp +> indicates the earliest of the composition time<> +> within the VOPs +> carried in +> the RTP packet. Timestamp information of the rest of +> <> VOPs are +> derived from +> the timestamp fields in the VOP header (modulo_time_base and +> vop_time_increment)<<, or from the temporal_reference field +> in the case of short video header>>. +> - If the RTP packet contains only configuration information and/or +> Group_of_VideoObjectPlane() fields, the composition +> time of the next +> VOP in the coding order is used. +> - If the RTP packet contains only visual_object_sequence_end_code +> information, the composition time of the immediately +> preceding VOP in +> the coding order is used. +> +> Perhaps someone knows better wording for the first bullet. +> I used SHALL in +> that paragraph to prevent accumulation of round-off error in +> the sequence +> of time stamps, and SHOULD to allow for other picture clock +> frequencies +> than the one specified in the MPEG-4 visual semantics. More +> detail about +> this difference in MPEG-4 short header and H.263 semantics follows: +> +> Quoting ISO/IEC 14496-2:1999, clause 6.3.5.2: "temporal +> reference: This +> is an 8-bit number which can have 256 possible values. It +> is formed by +> incrementing its value in the previously transmitted +> video_plane_with_short_header() by one plus the number of +> non-transmitted +> pictures (at 30000/1001 Hz) since the previously transmitted +> picture. The +> arithmetic is performed with only the eight LSBs." +> +> In contrast the TR field in the H.263 spec allows different +> clocks than +> 29.97 Hz: "the value of TR is formed by incrementing its +> value in the +> temporally-previous reference picture header by one plus the +> number of +> skipped or non-reference pictures at the picture clock +> frequency since the +> previously transmitted one. The interpretation of TR +> depends upon the +> active picture clock frequency. ..." Negotiation of the +> picture clock +> frequency is done by external means, I believe. +> +> I suspect that fixing the H.263 TR frequency in the MPEG-4 +> temporal_reference semantics causes problems particularly +> for use of short- +> header on 25 Hz material in Europe. MPEG-4's short header mode corresponds with the H.263 "baseline" profile of operation. The baseline form only supports one picture clock frequency -- 30000/1001 Hz. The extra flexibility of supporting other picture clock frequencies is an optional feature that was added in version 2. MPEG-4 does not support compatibility for any optional H.263 optional features (even for the Advanced Prediction mode, which would have been a very easy one to specify since all the tools are in MPEG-4 in an identical form). It only supports the baseline form. The baseline form only has one picture clock frequency. So the MPEG-4 form of short header temporal reference corresponds to the old definition in H.263 version 1. The H.263 picture clock frequency is specified within the bitstream syntax. It is not something negotiated only externally. The standard picture clock frequency of 30000/1001 Hz is used unless the following is indicated: 1) Bits 6-8 of PTYPE are set to '111' (indicating that PLUSPTYPE is present), and 2) The UFEP parameter of PLUSPTYPE is '001' (indicating that OPPTYPE is present), and 2) Bit 4 of OPPTYPE is set to '1' In which case a "Custom Picture Clock Frequency Code (CPCFC)" is present that specifies the picture clock frequency. MPEG-4 does not allow bits 6-8 of PTYPE to be '111', so it does not allow its short header mode to use custom picture clock frequencies. The reason that 25 Hz was not originally supported in baseline mode is the famous/infamous "CIF compromise" originating in H.261 which created a picture size that favored the 625/50 world but used it with a picture clock frequency that favored the 525/60 world. This created a single video format for use world-wide so that videoconferencing systems made in all countries would be able to communicate with each other seamlessly. So the intent of the compromise was that there should not be separate flavors of H.261 or H.263 for the 50 Hz and 60 Hz worlds. Everyone should be able to communicate equally well with everyone. Today there is somewhat less concern over requiring a decoder to be able to rescale and retime video data than there was in the early '90s when that compromise was struck. So when H.263 went up for its second (H.263+) revision completed in Sept. '97, more flexible picture format support was added. Myself and Samson Cheung (then of Compression Labs, Inc.) were the primary contributors to adding that flexibility in the second version. +> +> As I noted in the first sentence, an alternative to describing how to +> compute timestamp in short header mode is simply to change +> MAY to SHOULD or +> SHALL regarding use of H.263 payload format for short header mode. Perhaps "SHALL" is the appropriate thing unless there is some alternative that also provides interoperability. It should probably also include something like "(e.g., RFC 2190 or RFC 2429)", as those are the two packetization formats that have been defined that can carry H.263 video. +> +> Best regards, +> Kris Huber +> Sorenson Laboratories, Inc. +> +> -----Original Message----- +> From: Young-Kwon LIM [mailto:young@techway.co.kr] +> Sent: Friday, September 08, 2000 1:08 AM +> To: Franceschini Guido; Koji Imura; IETF AVT; Colin Perkins; +> 'Yoshihiro +> Kikuchi'; Varesio Andrea +> Cc: 4on2andIP-sys +> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt +> +> +> Dear Guido and all, +> +> > > +> > > It would be better to add a description to clarify this. +> How about +> adding +> > > the following description in the timestamp definition in +> section 3.1? +> > > +> > > - When multiple VOPs are carried in the same RTP packet, +> the timestamp +> > > indicates the earliest of the composition time within +> the VOPs carried +> in +> > > the RTP packet. Timestamp information of the rest of +> VOPs are derived +> from +> > > the timestamp fields in the VOP header (modulo_time_base and +> > > vop_time_increment).? +> > > +> > Are you sure you want to possibly indicate the CTS of the +> second VOP in a +> > packet ? +> > This seems to me quite difficult to manage +> > I would better do either of the following: +> > - always indicate the CTS of the first VOP in the packet, +> even if the +> second +> > VOP will be presented first +> > - disallow concatenation of VOPs whose decoding order +> differs from the +> > composition order +> +> "modulo_time_base" and "vop_time_increment" are the syntax +> elements of VOP +> header invented for the purpose of carrying relative timing +> information. +> So, I don't see any problem to use those information to +> calcute CTS. When +> the receiver get a RTP packet with multiple VOPs, the CTS of +> first VOP can +> be derived from the RTP time stmap and CTS of successive VOPs can be +> calculated by using time stamp and two syntax elements in VOP header. +> Calculating timing information of each VOP is nothing new to +> the decoder. +> +> > +> > I am also doubtful about allowing variable frame rate +> videos to take +> > advantage of such concatenation of VOPs in the same RTP packet. +> > IMHO it would be safer to add some more constraints in the +> specification +> > (i.e. prohibit VOP concatenation in case of variable frame +> rates), instead +> > of adding the complexity of extracting TS information +> through cooperation +> of +> > different layers. +> > In other words: VOP concatenation has pros and cons. +> > Pros: optimizes bandwidth consuption +> > Cons: deteriorates packet loss resilience; increases implementation +> > complexity. +> > I therefore deduce that VOP concatenation is nice but not +> that wonderful, +> > and I would suggest to allow VOP concatenation only when +> this is trivial +> and +> > does not require significant complexity in the receivers +> implementations. +> > +> +> I don't think there is additional complexity. MPEG-4 video +> decoder always +> calculate the time difference of current VOP from the last +> one. So, when +> the decoder push the reconstructed data to composition buffer, it can +> easily send a presentation time information to the compositor. It is +> nothing to the implementation. +> +> Sincerely, +> Young. +> From rem-conf Fri Sep 08 22:16:44 2000 From rem-conf-request@es.net Fri Sep 08 22:16:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Xcr9-0001kT-00; Fri, 8 Sep 2000 22:07:11 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Xcr6-0001kD-00; Fri, 8 Sep 2000 22:07: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 OAA00512; Sat, 9 Sep 2000 14:06:17 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA12803; Sat, 9 Sep 2000 14:06:16 +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 OAA18183; Sat, 9 Sep 2000 14:06:16 +0900 (JST) Received: from default (kwa0211.mobile.toshiba.co.jp [133.120.199.43]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id OAA55674; Sat, 9 Sep 2000 14:06:10 +0900 (JST) Message-ID: <055501c01a1b$b0a7ccc0$27c77885@default> From: "Yoshihiro Kikuchi" To: "Gary Sullivan" , "'Kris Huber'" , "Young-Kwon LIM" , "Franceschini Guido" , "Koji Imura" , "IETF AVT" , "Colin Perkins" , "Varesio Andrea" Cc: "Yoshihiro Kikuchi" References: <6CEF693DEA38994786B8F1B115897A2E220FE8@red-msg-06.redmond.corp.microsoft.com> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP Date: Sat, 9 Sep 2000 14:06:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Length: 13400 Lines: 342 Dear Kris, Gary, all, I hope this message is not too late... Thank you Kris for your clarification. I will incorporate your proposed description for clarification in the Internet-Draft. > Perhaps "SHALL" is the appropriate thing unless there is some alternative > that also provides interoperability. I think "SHALL" is too strong because there are definitions related to short video header mode in other places of the Internet-Draft. The change may cause interoperability problem with other payload format. > It should probably also include something like "(e.g., RFC 2190 or RFC > 2429)", as > those are the two packetization formats that have been defined that can > carry > H.263 video. Thank you for your suggestion for your editorial update. Best regards, Yoshihiro ----- Original Message ----- From: Gary Sullivan To: 'Kris Huber' ; Young-Kwon LIM ; Franceschini Guido ; Koji Imura ; IETF AVT ; Colin Perkins ; 'Yoshihiro Kikuchi' ; Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Sent: Saturday, September 09, 2000 6:44 AM Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP > > Kris et al, > > A bit of H.263 explanation with a bit of a history lesson is > spliced into Kris's quoted message below: > > > +> -----Original Message----- > +> From: Kris Huber [mailto:khuber@sorensonlabs.com] > +> Sent: Friday, September 08, 2000 1:04 PM > +> To: Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF > +> AVT; Colin Perkins; 'Yoshihiro Kikuchi'; Varesio Andrea > +> Cc: 4on2andIP-sys; Gary Sullivan > +> Subject: RE: IETF AVT last call on > +> draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP > +> > +> > +> Dear Young and all, > +> > +> Unless "MAY" is changed to "SHOULD" in "When the short video > +> header mode is > +> used, the RTP payload format used MAY be that specified for > +> H.263 in the > +> relevant RFCs or in other relevant standards," I think additional > +> modifications are necessary to accommodate MPEG-4 short > +> header mode. This > +> is because vop_time_increment_resolution, modulo_time_base, > +> and time_code > +> are not present in a short header elementary stream. Here > +> is my proposed > +> modification (new text is indicated by surrounding it by > +> "<<" and ">>"). > +> No deletions are required. > +> > +> Timestamp: The timestamp indicates the composition time, or the > +> presentation time in a no-compositor decoder. A constant > +> offset, which is > +> random, is added for security reasons. The detailed > +> definition of the > +> timestamp is as follows: > +> << - For a video object plane with short header, the > +> timestamps (after the > +> first random timestamp) are equal to the presentation time sequence > +> associated with the semantics of the temporal_reference field. > +> Specifically, each timestamp value SHALL be calculated by > +> rounding the > +> value of a precise clock that advances delta_time with each > +> successive > +> video object plane with short header. The time increment SHOULD be > +> calculated as delta_time = (((temporal_reference + 256 - > +> (temporal_reference of previous VOP) modulo 256) * > +> 1001/30000) for each > +> successive video object plane with short header. The RTP > +> timestamp should > +> be consistently rounded or truncated to the resolution of > +> the RTP timestamp > +> field.>> > +> - <> for a video object plane, it is defined as > +> vop_time_increment (in units > +> of 1/vop_time_increment_resolution seconds) plus the > +> cumulative number > +> of whole seconds specified by modulo_time_base and, if present, > +> time_code of Group_of_VideoObjectPlane() fields. > +> - In the case of interlaced video, a VOP will consist of > +> lines from two > +> fields, and the timestamp will indicate the composition > +> time of the > +> first field. > +> ( - When multiple VOPs are carried in the same RTP packet, > +> the timestamp > +> indicates the earliest of the composition time within > +> the VOPs carried > +> in the RTP packet.) > +> Young-Kwon's proposed modification of the above bullet: > +> - When multiple VOPs are carried in the same RTP packet, > +> the timestamp > +> indicates the earliest of the composition time<> > +> within the VOPs > +> carried in > +> the RTP packet. Timestamp information of the rest of > +> <> VOPs are > +> derived from > +> the timestamp fields in the VOP header (modulo_time_base and > +> vop_time_increment)<<, or from the temporal_reference field > +> in the case of short video header>>. > +> - If the RTP packet contains only configuration information and/or > +> Group_of_VideoObjectPlane() fields, the composition > +> time of the next > +> VOP in the coding order is used. > +> - If the RTP packet contains only visual_object_sequence_end_code > +> information, the composition time of the immediately > +> preceding VOP in > +> the coding order is used. > +> > +> Perhaps someone knows better wording for the first bullet. > +> I used SHALL in > +> that paragraph to prevent accumulation of round-off error in > +> the sequence > +> of time stamps, and SHOULD to allow for other picture clock > +> frequencies > +> than the one specified in the MPEG-4 visual semantics. More > +> detail about > +> this difference in MPEG-4 short header and H.263 semantics follows: > +> > +> Quoting ISO/IEC 14496-2:1999, clause 6.3.5.2: "temporal > +> reference: This > +> is an 8-bit number which can have 256 possible values. It > +> is formed by > +> incrementing its value in the previously transmitted > +> video_plane_with_short_header() by one plus the number of > +> non-transmitted > +> pictures (at 30000/1001 Hz) since the previously transmitted > +> picture. The > +> arithmetic is performed with only the eight LSBs." > +> > +> In contrast the TR field in the H.263 spec allows different > +> clocks than > +> 29.97 Hz: "the value of TR is formed by incrementing its > +> value in the > +> temporally-previous reference picture header by one plus the > +> number of > +> skipped or non-reference pictures at the picture clock > +> frequency since the > +> previously transmitted one. The interpretation of TR > +> depends upon the > +> active picture clock frequency. ..." Negotiation of the > +> picture clock > +> frequency is done by external means, I believe. > +> > +> I suspect that fixing the H.263 TR frequency in the MPEG-4 > +> temporal_reference semantics causes problems particularly > +> for use of short- > +> header on 25 Hz material in Europe. > > > MPEG-4's short header mode corresponds with the H.263 "baseline" > profile of operation. The baseline form only supports one picture > clock frequency -- 30000/1001 Hz. The extra flexibility of > supporting other picture clock frequencies is an optional > feature that was added in version 2. MPEG-4 does not support > compatibility for any optional H.263 optional features (even for the > Advanced Prediction mode, which would have been a very easy one > to specify since all the tools are in MPEG-4 in an identical form). > It only supports the baseline form. The baseline form only has one > picture clock frequency. > > So the MPEG-4 form of short header temporal reference corresponds to > the old definition in H.263 version 1. > > The H.263 picture clock frequency is specified within the bitstream > syntax. It is not something negotiated only externally. The > standard picture clock frequency of 30000/1001 Hz is used unless > the following is indicated: > 1) Bits 6-8 of PTYPE are set to '111' (indicating that PLUSPTYPE > is present), and > 2) The UFEP parameter of PLUSPTYPE is '001' (indicating that OPPTYPE > is present), and > 2) Bit 4 of OPPTYPE is set to '1' > In which case a "Custom Picture Clock Frequency Code (CPCFC)" is > present that specifies the picture clock frequency. > > MPEG-4 does not allow bits 6-8 of PTYPE to be '111', so > it does not allow its short header mode to use custom picture > clock frequencies. > > The reason that 25 Hz was not originally supported in baseline mode > is the famous/infamous "CIF compromise" originating in H.261 which > created a picture size that favored the 625/50 world but used it > with a picture clock frequency that favored the 525/60 world. > This created a single video format for use world-wide so that > videoconferencing systems made in all countries would be able to > communicate with each other seamlessly. > > So the intent of the compromise was that there should not be > separate flavors of H.261 or H.263 for the 50 Hz and 60 Hz worlds. > Everyone should be able to communicate equally well with everyone. > > Today there is somewhat less concern over requiring a decoder to be > able to rescale and retime video data than there was in the early > '90s when that compromise was struck. So when H.263 went up for > its second (H.263+) revision completed in Sept. '97, more flexible > picture format support was added. Myself and Samson Cheung (then > of Compression Labs, Inc.) were the primary contributors to adding > that flexibility in the second version. > > > +> > +> As I noted in the first sentence, an alternative to describing how to > +> compute timestamp in short header mode is simply to change > +> MAY to SHOULD or > +> SHALL regarding use of H.263 payload format for short header mode. > > > Perhaps "SHALL" is the appropriate thing unless there is some alternative > that also provides interoperability. > > It should probably also include something like "(e.g., RFC 2190 or RFC > 2429)", as > those are the two packetization formats that have been defined that can > carry > H.263 video. > > > +> > +> Best regards, > +> Kris Huber > +> Sorenson Laboratories, Inc. > +> > +> -----Original Message----- > +> From: Young-Kwon LIM [mailto:young@techway.co.kr] > +> Sent: Friday, September 08, 2000 1:08 AM > +> To: Franceschini Guido; Koji Imura; IETF AVT; Colin Perkins; > +> 'Yoshihiro > +> Kikuchi'; Varesio Andrea > +> Cc: 4on2andIP-sys > +> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > +> > +> > +> Dear Guido and all, > +> > +> > > > +> > > It would be better to add a description to clarify this. > +> How about > +> adding > +> > > the following description in the timestamp definition in > +> section 3.1? > +> > > > +> > > - When multiple VOPs are carried in the same RTP packet, > +> the timestamp > +> > > indicates the earliest of the composition time within > +> the VOPs carried > +> in > +> > > the RTP packet. Timestamp information of the rest of > +> VOPs are derived > +> from > +> > > the timestamp fields in the VOP header (modulo_time_base and > +> > > vop_time_increment).? > +> > > > +> > Are you sure you want to possibly indicate the CTS of the > +> second VOP in a > +> > packet ? > +> > This seems to me quite difficult to manage > +> > I would better do either of the following: > +> > - always indicate the CTS of the first VOP in the packet, > +> even if the > +> second > +> > VOP will be presented first > +> > - disallow concatenation of VOPs whose decoding order > +> differs from the > +> > composition order > +> > +> "modulo_time_base" and "vop_time_increment" are the syntax > +> elements of VOP > +> header invented for the purpose of carrying relative timing > +> information. > +> So, I don't see any problem to use those information to > +> calcute CTS. When > +> the receiver get a RTP packet with multiple VOPs, the CTS of > +> first VOP can > +> be derived from the RTP time stmap and CTS of successive VOPs can be > +> calculated by using time stamp and two syntax elements in VOP header. > +> Calculating timing information of each VOP is nothing new to > +> the decoder. > +> > +> > > +> > I am also doubtful about allowing variable frame rate > +> videos to take > +> > advantage of such concatenation of VOPs in the same RTP packet. > +> > IMHO it would be safer to add some more constraints in the > +> specification > +> > (i.e. prohibit VOP concatenation in case of variable frame > +> rates), instead > +> > of adding the complexity of extracting TS information > +> through cooperation > +> of > +> > different layers. > +> > In other words: VOP concatenation has pros and cons. > +> > Pros: optimizes bandwidth consuption > +> > Cons: deteriorates packet loss resilience; increases implementation > +> > complexity. > +> > I therefore deduce that VOP concatenation is nice but not > +> that wonderful, > +> > and I would suggest to allow VOP concatenation only when > +> this is trivial > +> and > +> > does not require significant complexity in the receivers > +> implementations. > +> > > +> > +> I don't think there is additional complexity. MPEG-4 video > +> decoder always > +> calculate the time difference of current VOP from the last > +> one. So, when > +> the decoder push the reconstructed data to composition buffer, it can > +> easily send a presentation time information to the compositor. It is > +> nothing to the implementation. > +> > +> Sincerely, > +> Young. > +> > From rem-conf Sat Sep 09 04:15:37 2000 From rem-conf-request@es.net Sat Sep 09 04:15:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XiUK-00055q-00; Sat, 9 Sep 2000 04:08:00 -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 13XiUI-00055g-00; Sat, 9 Sep 2000 04:07:58 -0700 Received: from modern ([133.9.250.212]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id UAA08167; Sat, 9 Sep 2000 20:07:29 +0900 Message-ID: <01db01c01a4f$5e12c1c0$0300a8c0@katto.comm.waseda.ac.jp> From: "Jiro Katto" To: "Franceschini Guido" , "'Yoshihiro Kikuchi'" , "IETF AVT" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> References: <85077463E51D6A498C453073E1677940034EAC@exc2k02.cselt.it> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Sat, 9 Sep 2000 20:15: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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 7075 Lines: 203 Dear all, Current mechanism seems to have two problems: (1) When M-bit is 1, an RTP handler has to parse all the bits every time just to find VOP headers (no mechanisms to indicate the number of VOPs). (2) Encoder manufacturers may not precisely implement the two fields, modulo_ time_base and vop_time_increment, similar to MPEG-2 case. Therefore, I prefer just to say, "Two or more VOPs SHALL be fragmented into different RTP packets" in the current draft. This is simple and stable. An alternative, but may not be MPEG-4 specific, is to put the number of VOPs and time stamps into a payload header using header extension mechanism. Syntax will be type, length (= number of VOPs -1), time stamps and padding bytes, similar to other protocols' option fields. Time stamp can be shrinked to one byte by taking differences. Just a comment. Thanks. Best regards, -- Jiro Katto Waseda University Guido wrote: > Some further comment below > > > ---------- > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > Sent: Friday, September 08, 2000 2:35 PM > > To: Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF AVT; Colin > > Perkins; Varesio Andrea > > Cc: 4on2andIP-sys; Yoshihiro Kikuchi > > Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > > > > Dear Young-Kwon, Guido, Matsui-san, Imura-san, all, > > > > Thank you very much for the comment. > > > > It seems to be better to list all description related the multiple VOPs > > concatenation in the "current" draft text posted on Sep. 5 here in this > > mail > > for the better understandings. > > > > 1. Introduction > > The fragmentation rule recommends not to map more than one VOP in an > > RTP > > packet so that 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 a not coded VOP containing only VOP header or an arbitrary > > shaped VOP with a small number. To reduce the overhead for such cases, > > the fragmentation rule permits concatenating multiple VOPs in an RTP > > packet when the VOP size is small. > Editorial: I don't think the last statement 'when the VOP size is small' is > necessary/appropriate > > > 3.1 Use of RTP header fields for MPEG-4 Visual > > 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: > > - When multiple VOPs are carried in the same RTP packet, the timestamp > > indicates the earliest of the composition time within the VOPs > > carried > > in the RTP packet. > > > > 3.2 Fragmentation of MPEG-4 Visual bitstream > > (4) Two or more 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 VOPs MAY be carried > > within one RTP packet if the size of the VOPs is small. > Editorial: again, what is the meaning of 'small' ? Also, at the beginning, I > would change to 'Different VOPs SHOULD be fragmented into different RTP > packets' > > > > I think it is better to add cross-references (see section ..., definition > > of > > ....) for each description above in the draft so that every readers of the > > draft can understand this set of rule easily. > > > > Young-Kwon wrote: > > > > > I don't think there is additional complexity. MPEG-4 video decoder > > always > > calculate the time difference of current VOP from the last one. So, when > > the decoder push the reconstructed data to composition buffer, it can > > easily > > send a presentation time information to the compositor. It is nothing to > > the > > implementation. > > > > > I'm OK with this because this allows concatenation of VOPs. > > > > Oh, now there are agreements on the current description. As usual, if > > there > > is any other strong disagreements, we should stick with the current text. > > (except for editorial changes and clarifications) > > > > Please look not only sentences I posted but a set of rules. It is defined > > that multiple VOPs SHOULD NOT be concatenated so as not to force huge > > amout > > of complexity. The concatenation is an exception rule only when VOP size > > is > > small. > Just to make my point clear: either you quantify 'small', or you can at most > say something like: "concatenation is allowed only when an integral number > of VOPs fit into a single RTP packet" > I would suggest to have some text clearly specifying under which > circumstances VOP concatenation may occur: > Some idea for this text: > > Concatenation is allowed only when the following conditions occur: > - the result of concatenting N consecutive VOPs still fits into a single RTP > packet > - the presentation and decoding order of the VOPs is identical > - ... > > > >For more clarification I'd like to add "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." > > > > > Agreed. > > > > > BTW, where is a sentence prohibiting concatenation of VOPs with > > different > > decoding order? > > > > There is no sentence now in the draft but only in mails exchanged. > > > > Following is the list of proposed changes by mails on this issue for > > editorial update and clarifications but not technical. > > > > 1) Add cross-cross references to each descriptions. > > 2) Add the following sentence to the timestamp definition > > "Timestamp information of the rest of VOPs are derived from the > > timestamp fields in the VOP header (modulo_time_base and > > vop_time_increment)." > > 3) Add the following description as a note to fragmentation rule (4) > > "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 satisfying the > > following both two conditions: > > - Marker bit equal to one, and > > (Because marker bit in section 3.1 is defined that it is set to one when > > multiple VOP is concatenated.) > > - The beginning of RTP payload is not a start code. > > (Because the fragmentation rule is defined that a start code is placed > > always at the beginning of RTP payload, if exists.)" > I do not understand this second condition. I would have reversed it "The > beginning of RTP payload corresponds to a start code" > > Bye > Guido > > > > If there is no further objection, only changes reflected to the next > > version > > of I/D will be these descriptions for editorial update and clarifications. > > > > > > 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 Sep 09 04:36:29 2000 From rem-conf-request@es.net Sat Sep 09 04:36:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Xit3-00069s-00; Sat, 9 Sep 2000 04:33:33 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Xit0-00069i-00; Sat, 9 Sep 2000 04:33:30 -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 <0G0M00F1IAPSQS@ss3000e.cselt.it> for rem-conf@es.net; Sat, 9 Sep 2000 13:32:16 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Sat, 09 Sep 2000 13:34:31 +0200 Content-return: allowed Date: Sat, 09 Sep 2000 13:32:24 +0200 From: Chiariglione Leonardo Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header VOP To: 'Gary Sullivan' , 'Kris Huber' , Young-Kwon LIM , Franceschini Guido , Koji Imura , IETF AVT , Colin Perkins , 'Yoshihiro Kikuchi' , Varesio Andrea Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 13681 Lines: 356 >Today there is somewhat less concern over requiring a decoder to be >able to rescale and retime video data than there was in the early '>90s when that compromise was struck. Actually the "compromise" was reached at the Specialists Group on = Visual Telephony meeting of Torino in September 1985. At that meeting I was = the only one opposing CIF because I thought accommodating different video = format in the coded domain should have been a matter for the decoder to = handle. But the Specialists Group at that time was still dominated by people = focusing on the "encoder" instead of the "decoder". My position of that time was belatedly vindicated in 1990 when MPEG adopted SIF and later the = Constrained Parameter Set, the obvious thing to do when you work on the decoder. I = have to say that I did not play any role in defining CIF or CPS. Leonardo > -----Original Message----- > From: Gary Sullivan [mailto:garysull@microsoft.com] > Sent: venerd=EC 8 settembre 2000 23.44 > To: 'Kris Huber'; Young-Kwon LIM; Franceschini Guido; Koji Imura; = IETF > AVT; Colin Perkins; 'Yoshihiro Kikuchi'; Varesio Andrea > Cc: 4on2andIP-sys > Subject: RE: IETF AVT last call on=20 > draft-ietf-avt-rtp-mpeg4-es-03.txt - > ti mestamp of short header VOP >=20 >=20 >=20 > Kris et al, >=20 > A bit of H.263 explanation with a bit of a history lesson is > spliced into Kris's quoted message below: >=20 >=20 > +> -----Original Message----- > +> From: Kris Huber [mailto:khuber@sorensonlabs.com] > +> Sent: Friday, September 08, 2000 1:04 PM > +> To: Young-Kwon LIM; Franceschini Guido; Koji Imura; IETF=20 > +> AVT; Colin Perkins; 'Yoshihiro Kikuchi'; Varesio Andrea > +> Cc: 4on2andIP-sys; Gary Sullivan > +> Subject: RE: IETF AVT last call on=20 > +> draft-ietf-avt-rtp-mpeg4-es-03.txt - ti mestamp of short header = VOP > +>=20 > +>=20 > +> Dear Young and all, > +>=20 > +> Unless "MAY" is changed to "SHOULD" in "When the short video=20 > +> header mode is > +> used, the RTP payload format used MAY be that specified for=20 > +> H.263 in the > +> relevant RFCs or in other relevant standards," I think additional > +> modifications are necessary to accommodate MPEG-4 short=20 > +> header mode. This > +> is because vop_time_increment_resolution, modulo_time_base,=20 > +> and time_code > +> are not present in a short header elementary stream. Here=20 > +> is my proposed > +> modification (new text is indicated by surrounding it by=20 > +> "<<" and ">>"). > +> No deletions are required. > +>=20 > +> Timestamp: The timestamp indicates the composition time, or the > +> presentation time in a no-compositor decoder. A constant=20 > +> offset, which is > +> random, is added for security reasons. The detailed=20 > +> definition of the > +> timestamp is as follows: > +> << - For a video object plane with short header, the=20 > +> timestamps (after the > +> first random timestamp) are equal to the presentation time = sequence > +> associated with the semantics of the temporal_reference field. > +> Specifically, each timestamp value SHALL be calculated by=20 > +> rounding the > +> value of a precise clock that advances delta_time with each=20 > +> successive > +> video object plane with short header. The time increment SHOULD = be > +> calculated as delta_time =3D (((temporal_reference + 256 - > +> (temporal_reference of previous VOP) modulo 256) *=20 > +> 1001/30000) for each > +> successive video object plane with short header. The RTP=20 > +> timestamp should > +> be consistently rounded or truncated to the resolution of=20 > +> the RTP timestamp > +> field.>> > +> - <> for a video object plane, it is defined as > +> vop_time_increment (in units > +> of 1/vop_time_increment_resolution seconds) plus the=20 > +> cumulative number > +> of whole seconds specified by modulo_time_base and,=20 > if present, > +> time_code of Group_of_VideoObjectPlane() fields. =20 > +> - In the case of interlaced video, a VOP will consist of=20 > +> lines from two > +> fields, and the timestamp will indicate the composition=20 > +> time of the > +> first field. > +> ( - When multiple VOPs are carried in the same RTP packet,=20 > +> the timestamp > +> indicates the earliest of the composition time within=20 > +> the VOPs carried > +> in the RTP packet.) > +> Young-Kwon's proposed modification of the above bullet: > +> - When multiple VOPs are carried in the same RTP packet,=20 > +> the timestamp > +> indicates the earliest of the composition time<>=20 > +> within the VOPs > +> carried in > +> the RTP packet. Timestamp information of the rest of=20 > +> <> VOPs are > +> derived from > +> the timestamp fields in the VOP header (modulo_time_base and > +> vop_time_increment)<<, or from the temporal_reference field > +> in the case of short video header>>. > +> - If the RTP packet contains only configuration=20 > information and/or > +> Group_of_VideoObjectPlane() fields, the composition=20 > +> time of the next > +> VOP in the coding order is used. > +> - If the RTP packet contains only=20 > visual_object_sequence_end_code > +> information, the composition time of the immediately=20 > +> preceding VOP in > +> the coding order is used. > +>=20 > +> Perhaps someone knows better wording for the first bullet. =20 > +> I used SHALL in > +> that paragraph to prevent accumulation of round-off error in=20 > +> the sequence > +> of time stamps, and SHOULD to allow for other picture clock=20 > +> frequencies > +> than the one specified in the MPEG-4 visual semantics. More=20 > +> detail about > +> this difference in MPEG-4 short header and H.263 semantics = follows: > +>=20 > +> Quoting ISO/IEC 14496-2:1999, clause 6.3.5.2: "temporal=20 > +> reference: This > +> is an 8-bit number which can have 256 possible values. It=20 > +> is formed by > +> incrementing its value in the previously transmitted > +> video_plane_with_short_header() by one plus the number of=20 > +> non-transmitted > +> pictures (at 30000/1001 Hz) since the previously transmitted=20 > +> picture. The > +> arithmetic is performed with only the eight LSBs." > +>=20 > +> In contrast the TR field in the H.263 spec allows different=20 > +> clocks than > +> 29.97 Hz: "the value of TR is formed by incrementing its=20 > +> value in the > +> temporally-previous reference picture header by one plus the=20 > +> number of > +> skipped or non-reference pictures at the picture clock=20 > +> frequency since the > +> previously transmitted one. The interpretation of TR=20 > +> depends upon the > +> active picture clock frequency. ..." Negotiation of the=20 > +> picture clock > +> frequency is done by external means, I believe. > +>=20 > +> I suspect that fixing the H.263 TR frequency in the MPEG-4 > +> temporal_reference semantics causes problems particularly=20 > +> for use of short- > +> header on 25 Hz material in Europe. >=20 >=20 > MPEG-4's short header mode corresponds with the H.263 "baseline" > profile of operation. The baseline form only supports one picture > clock frequency -- 30000/1001 Hz. The extra flexibility of > supporting other picture clock frequencies is an optional > feature that was added in version 2. MPEG-4 does not support > compatibility for any optional H.263 optional features (even for the > Advanced Prediction mode, which would have been a very easy one > to specify since all the tools are in MPEG-4 in an identical form). > It only supports the baseline form. The baseline form only has one > picture clock frequency. >=20 > So the MPEG-4 form of short header temporal reference corresponds to > the old definition in H.263 version 1. >=20 > The H.263 picture clock frequency is specified within the bitstream > syntax. It is not something negotiated only externally. The > standard picture clock frequency of 30000/1001 Hz is used unless > the following is indicated: > 1) Bits 6-8 of PTYPE are set to '111' (indicating that PLUSPTYPE > is present), and > 2) The UFEP parameter of PLUSPTYPE is '001' (indicating that = OPPTYPE > is present), and > 2) Bit 4 of OPPTYPE is set to '1' > In which case a "Custom Picture Clock Frequency Code (CPCFC)" is > present that specifies the picture clock frequency. >=20 > MPEG-4 does not allow bits 6-8 of PTYPE to be '111', so > it does not allow its short header mode to use custom picture > clock frequencies. >=20 > The reason that 25 Hz was not originally supported in baseline mode > is the famous/infamous "CIF compromise" originating in H.261 which > created a picture size that favored the 625/50 world but used it > with a picture clock frequency that favored the 525/60 world. > This created a single video format for use world-wide so that > videoconferencing systems made in all countries would be able to > communicate with each other seamlessly. >=20 > So the intent of the compromise was that there should not be > separate flavors of H.261 or H.263 for the 50 Hz and 60 Hz worlds. > Everyone should be able to communicate equally well with everyone. >=20 > Today there is somewhat less concern over requiring a decoder to be > able to rescale and retime video data than there was in the early > '90s when that compromise was struck. So when H.263 went up for > its second (H.263+) revision completed in Sept. '97, more flexible > picture format support was added. Myself and Samson Cheung (then > of Compression Labs, Inc.) were the primary contributors to adding > that flexibility in the second version. >=20 >=20 > +>=20 > +> As I noted in the first sentence, an alternative to=20 > describing how to > +> compute timestamp in short header mode is simply to change=20 > +> MAY to SHOULD or > +> SHALL regarding use of H.263 payload format for short header mode. >=20 >=20 > Perhaps "SHALL" is the appropriate thing unless there is some=20 > alternative > that also provides interoperability. >=20 > It should probably also include something like "(e.g., RFC 2190 or = RFC > 2429)", as > those are the two packetization formats that have been=20 > defined that can > carry > H.263 video. >=20 >=20 > +>=20 > +> Best regards, > +> Kris Huber > +> Sorenson Laboratories, Inc. > +>=20 > +> -----Original Message----- > +> From: Young-Kwon LIM [mailto:young@techway.co.kr] > +> Sent: Friday, September 08, 2000 1:08 AM > +> To: Franceschini Guido; Koji Imura; IETF AVT; Colin Perkins;=20 > +> 'Yoshihiro > +> Kikuchi'; Varesio Andrea > +> Cc: 4on2andIP-sys > +> Subject: Re: IETF AVT last call on=20 > draft-ietf-avt-rtp-mpeg4-es-03.txt > +>=20 > +>=20 > +> Dear Guido and all, > +>=20 > +> > >=20 > +> > > It would be better to add a description to clarify this.=20 > +> How about > +> adding > +> > > the following description in the timestamp definition in=20 > +> section 3.1? > +> > >=20 > +> > > - When multiple VOPs are carried in the same RTP packet,=20 > +> the timestamp > +> > > indicates the earliest of the composition time within=20 > +> the VOPs carried > +> in > +> > > the RTP packet. Timestamp information of the rest of=20 > +> VOPs are derived > +> from > +> > > the timestamp fields in the VOP header (modulo_time_base and > +> > > vop_time_increment).? > +> > >=20 > +> > Are you sure you want to possibly indicate the CTS of the=20 > +> second VOP in a > +> > packet ? > +> > This seems to me quite difficult to manage > +> > I would better do either of the following: > +> > - always indicate the CTS of the first VOP in the packet,=20 > +> even if the > +> second > +> > VOP will be presented first > +> > - disallow concatenation of VOPs whose decoding order=20 > +> differs from the > +> > composition order > +>=20 > +> "modulo_time_base" and "vop_time_increment" are the syntax=20 > +> elements of VOP > +> header invented for the purpose of carrying relative timing=20 > +> information. > +> So, I don't see any problem to use those information to=20 > +> calcute CTS. When > +> the receiver get a RTP packet with multiple VOPs, the CTS of=20 > +> first VOP can > +> be derived from the RTP time stmap and CTS of successive=20 > VOPs can be > +> calculated by using time stamp and two syntax elements in=20 > VOP header. > +> Calculating timing information of each VOP is nothing new to=20 > +> the decoder. > +>=20 > +> >=20 > +> > I am also doubtful about allowing variable frame rate=20 > +> videos to take > +> > advantage of such concatenation of VOPs in the same RTP packet. > +> > IMHO it would be safer to add some more constraints in the=20 > +> specification > +> > (i.e. prohibit VOP concatenation in case of variable frame=20 > +> rates), instead > +> > of adding the complexity of extracting TS information=20 > +> through cooperation > +> of > +> > different layers. > +> > In other words: VOP concatenation has pros and cons. > +> > Pros: optimizes bandwidth consuption > +> > Cons: deteriorates packet loss resilience; increases=20 > implementation > +> > complexity. > +> > I therefore deduce that VOP concatenation is nice but not=20 > +> that wonderful, > +> > and I would suggest to allow VOP concatenation only when=20 > +> this is trivial > +> and > +> > does not require significant complexity in the receivers=20 > +> implementations. > +> >=20 > +>=20 > +> I don't think there is additional complexity. MPEG-4 video=20 > +> decoder always > +> calculate the time difference of current VOP from the last=20 > +> one. So, when > +> the decoder push the reconstructed data to composition=20 > buffer, it can > +> easily send a presentation time information to the=20 > compositor. It is > +> nothing to the implementation. > +>=20 > +> Sincerely, > +> Young. > +>=20 >=20 From rem-conf Sat Sep 09 20:36:08 2000 From rem-conf-request@es.net Sat Sep 09 20:36:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13XxoQ-00055h-00; Sat, 9 Sep 2000 20:29:46 -0700 Received: from (ems1.ptts0801.gov.tw) [210.241.32.157] by mail1.es.net with esmtp (Exim 1.81 #2) id 13XxoO-00055H-00; Sat, 9 Sep 2000 20:29:45 -0700 Received: from ems.ptts0801.gov.tw (NT1851 [192.168.5.253]) by ems1.ptts0801.gov.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SLYQ2673; Sat, 9 Sep 2000 02:29:56 +0800 Received: from 210.241.32.157 by ems.ptts0801.gov.tw (InterScan E-Mail VirusWall NT); Sat, 09 Sep 2000 02:26:23 +0800 To: Cad Cam-homea From: juioi@jjk.co.jp Subject: cad/cam information welcome Date: Sat, 09 Sep 2000 03:38:58 +0900 Message-Id: <36778.152062152774400.296715@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1375 Lines: 37 =================================== 2000.09.8 s:0001== ߂܂āAb`c^b`l\tglbg[Nł܂B ̃[̓}KWƂĊFɔ܂āA ȂÂ܂܍폜ĂB ͂߂܂āIICAD/CAM\tgEFA|͂܂őSECA D/CAM \tgpȂ邨qlɂ胊[YiuɃ\tg ĒĂ܂Bē{CAD/CAM[U[̊Flɂ킪 Ђ̃T[rXĂ炢Ǝv̓{ł̃T[rXJ n邱ƂƂȂ܂! CAD/CAM\tgEFA|͍A{ł̔̔ɌĂW 10܂ł̊ԂɊFlɂ悭CAD/CAM\tgEFA|pĂ ߂CAD\tgI[vLy[Ƃ܂Ē艿 XɊ܂BApII CAD/CAM\tgEFA|̈Ă\tg̓v̕Xgp Ă܂BƂĐSzKv͂܂IȂȂA qlɃ\tgwɓЃIWĩ}jAグ ܂BłAql̓\tgwꂽ̓\ gpĂ܂B z[y[WɂēЂ̈Ă\tgЉĂ܂A qlTɂȂĂ\tg‚Ȃꍇ͐A Ђ܂łCyɂ₢킹BłT܂B goFhttp://98.to/cadcamjp http://cadcamjp.iscool.net http://go.to/cadcamjp From rem-conf Sun Sep 10 00:09:53 2000 From rem-conf-request@es.net Sun Sep 10 00:09:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Y17p-0007To-00; Sun, 10 Sep 2000 00:02:01 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Y17n-0007SH-00; Sun, 10 Sep 2000 00:01: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 DAA09017; Sun, 10 Sep 2000 03:03:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Sep 2000 02:58:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'Guler, Amos'" , "'rem-conf@es.net'" Subject: RE: Question: packing several frames in a single RTP packet Date: Sun, 10 Sep 2000 02:58:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-8-i" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1670 Lines: 58 This may be of theoretical interest only. In practice, I think that all frame based codecs are either (1) the same frame length, (2) indicate within the frame itself what size or type it is, when the lengths are not the same. Its only for frames that have variable length AND don't indicate their length that you need worry about this. Does anyone know of any frame codecs which are a problem? -Jonathan R. Amos wrote: > -----Original Message----- > Hello all, > > (I hope I am sending this to the correct mailing list. If > not, please accept > my apology and advise me of the correct one) > > In the new draft "RTP Profile for Audio and Video Conferences > with Minimal > Control" > (http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-ne > w-09.txt) that > is supposed to replace RFC-1890, it says (in section 4.4, > Guidelines for > Frame-Based Audio Encodings): > > "The receiver can tell the number of frames contained in an > RTP packet, if > all the frames have the same length, by dividing the RTP > payload length by > the audio frame size which is defined as part of the > encoding. This does not > work when carrying frames of different sizes unless the frame > sizes are > relatively prime." > > My question concerns the last statement: suppose, for > example, that the > frame sizes are 5 and 7 octets, which are relatively prime, > and the receiver > gets a 35-octet packet. How can he/she tell whether the > packet contains five > 7-octet frames or seven 5-octet frames? > > > Amos Guler > > ==================== > Amos Guler > Comverse Network Systems Ltd. > amos_guler@icomverse.com > http://www.comverse.com > > > From rem-conf Sun Sep 10 01:38:43 2000 From rem-conf-request@es.net Sun Sep 10 01:38:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Y2Za-0001I3-00; Sun, 10 Sep 2000 01:34:46 -0700 Received: from (mail.b7.co.uk) [212.134.223.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Y2ZX-0001GU-00; Sun, 10 Sep 2000 01:34:44 -0700 Received: from dealersdirect.co.uk (pool-101.businessserve.com [212.135.90.101]) by mail.b7.co.uk (8.9.3/8.9.3) with SMTP id JAA20878; Sun, 10 Sep 2000 09:33:54 +0100 (BST) From: Subject: http://www.dealersdirect.co.uk UPDATE Date: Sun, 10 Sep 2000 04:35:11 Message-Id: <791.436092.347892@dealersdirect.co.uk> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.b7.co.uk id JAA20878 Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 5731 Lines: 153 DealersDirect.co.uk - the easy way to buy cars from abroad!!!</TIT= LE> <base target=3D"_blank"> </HEAD> <BODY bgColor=3D#000032 leftMargin=3D0 topMargin=3D0 MARGINHEIGHT=3D"0"=20 MARGINWIDTH=3D"0" text=3D"#FFFFFF"> <p align=3D"center"><a href=3D"http://www.dealersdirect.co.uk" ta= rget=3D"_blank"><img border=3D"0" src=3D"http://www.dealersdirect.co.uk/1= .jpg" alt=3D"http://www.dealersdirect.co.uk" width=3D"550" height=3D"130"= ></a></p> <p align=3D"center"><b><font face=3D"Arial">SAVE UP TO 50% OFF UK NEW CAR= PRICES</font></b></p> <p align=3D"center"><b><font face=3D"Arial">Update Newsletter 1st Septemb= er 2000</font></b></p> <p align=3D"center"><b><font face=3D"Arial">Headline</font></b></p> <p align=3D"center"><b><font face=3D"Arial">CAR MANUFACTURERS REDUCE CAR = PRICES IN THE UK, <a href=3D"http://www.dealersdirect.co.uk">DEALERSDIRECT.CO.UK</a= > DISCOVER CHEAPER MARKETS! THE DIFFERENCE IS STILL HUGE</font></b></p> <p align=3D"center"><b><font face=3D"Arial"><a href=3D"http://www.dealers= direct.co.uk" target=3D"_blank">DEALERSDIRECT.CO.UK</a> - WE BRING YOU THE NEWS OTHER IMPORTERS HIDE</font></b></p> <p align=3D"center"><b><font face=3D"Arial">STAY UP TO DATE IN TH= E CAR INDUSTRY WITH <a href=3D"http://www.dealersdirect.co.uk" target=3D= "_blank">DEALERSDIRECT.CO.UK</a></font></b></p> <div align=3D"center"> <center> <table border=3D"0" width=3D"89%"> <tr> <td width=3D"78%" align=3D"center" valign=3D"top"> <p align=3D"left"><font face=3D"Verdana">Since we last co= ntacted you, Dealersdirect.co.uk have made several improvements t= o our service.  We hear you, we have noted your comments a= nd suggestions and enhanced several key aspects of the Dealersdirect.co.uk website service. Some of the key enhancements:</font></p> <ul type=3D"circle"> <li> <p align=3D"left"><font face=3D"Verdana">Improved Cus= tomer Service</font></li> <li> <p align=3D"left"><font face=3D"Verdana">Increased Ma= nufacturer Choice</font></li> <li> <p align=3D"left"><font face=3D"Verdana">Faster Respo= nse Times</font></li> <li> <p align=3D"left"><font face=3D"Verdana">Updated Pric= elists</font></li> <li> <p align=3D"left"><font face=3D"Verdana">Added New Ma= rkets</font></li> </ul> <p align=3D"left"><font face=3D"Verdana">To handle volume= , we have employed more staff to ensure a fast response to your enq= uiry. Our Website Development Staff have introduced new feature= s to the service to keep you informed, with news updates added throughout the day.</font></p> <p align=3D"left"><font face=3D"Verdana">We plan to launc= h our service in another six markets before the end of the year= . Visit our website for further information.</font></p> <p align=3D"left"><font face=3D"Verdana">Follow the link = below to save up to 50%!!!</font></p> <p align=3D"center"><font face=3D"Verdana"><a href=3D"htt= p://www.dealersdirect.co.uk">http://www.dealersdirect.co.uk</a></font></p= > </tr> </table> </center> </div> <p align=3D"center"><b><font face=3D"Arial">thank you for your continued = patronage of Dealersdirect.co.uk</font></b></p> <p align=3D"center"><a href=3D"http://www.dealersdirect.co.uk/copyright.h= tml"><font face=3D"Verdana" size=3D"1">=A9 2000 <b><i>DealersDirect.co.uk Copyright notice</i></b></font></a></p> <p align=3D"center"><b><font face=3D"Verdana" size=3D"2">Email marketing provided by Mail Demon, Inc.</font></b></p> <p align=3D"center"><b><font face=3D"Verdana" size=3D"2">Although= we try very hard to avoid sending unrelated mail to people, it is not fo= ol-proof. <br> <br> We greatly regret that our e-mail campaign has inconvenienced you= . Please accept our sincere apology. Please use the address below to unsubscribe from all of our e-mail campaigns imm= ediately. If this problem persists even after you have unsubscribed, please contact us via our Web site.</font></b></p> <p><font face=3D"Verdana">We adhere to RESPONSIBLE Email Ethics if you wi= sh to be " removed " >from future mailings, please click below. This mailing is done by an inde= pendent marketing company, Mail Demon, Inc. <a href=3D"mailto:mailingdemon@totali= se.co.uk">mailingdemon@totalise.co.uk</a> We apologize if this message has reached you in error. Save the Planet, S= ave the Trees! Advertise via E-mail. No wasted paper!</font></p> <p align=3D"center"><font face=3D"Verdana"><!-- BEGIN FASTCOUNTER CODE --= > <a href=3D"http://member.bcentral.com/cgi-bin/fc/fastcounter-login?188680= 6" target=3D"_top"> <img border=3D"0" src=3D"http://fastcounter.bcentral.com/fastcounter?1886= 806+3773619"></a> <!-- END FASTCOUNTER CODE --> <br> <!-- BEGIN FASTCOUNTER LINK --> <font face=3D"arial" size=3D"1"> <a href=3D"http://fastcounter.bcentral.com/fc-join" target=3D"_top">FastC= ounter by bCentral</a> </font><br> </font> <!-- END FASTCOUNTER LINK --> </p> <p align=3D"center"> </p> <p align=3D"center"> </p> <p align=3D"center"> </p> </BODY></HTML> From rem-conf Sun Sep 10 02:56:09 2000 From rem-conf-request@es.net Sun Sep 10 02:56:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Y3lJ-00033H-00; Sun, 10 Sep 2000 02:50:57 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13Y3lH-00032W-00; Sun, 10 Sep 2000 02:50:55 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.04446-0@bells.cs.ucl.ac.uk>; Sun, 10 Sep 2000 10:50:22 +0100 From: Orion Hodson <O.Hodson@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> cc: "'Guler, Amos'" <Amos_Guler@icomverse.com>, "'rem-conf@es.net'" <rem-conf@es.net> Subject: Re: Question: packing several frames in a single RTP packet In-reply-to: Your message of "Sun, 10 Sep 2000 02:58:32 EDT." <B65B4F8437968F488A01A940B21982BF21FC33@DYN-EXCH-001.dynamicsoft.com> Date: Sun, 10 Sep 2000 10:50:22 +0100 Message-ID: <817.968579422@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 852 Lines: 18 <B65B4F8437968F488A01A940B21982BF21FC33@DYN-EXCH-001.dynamicsoft.com>Jonathan R osenberg writes: > This may be of theoretical interest only. In practice, I think that all > frame based codecs are either (1) the same frame length, (2) indicate within > the frame itself what size or type it is, when the lengths are not the same. > Its only for frames that have variable length AND don't indicate their > length that you need worry about this. Does anyone know of any frame codecs > which are a problem? VDVI is variable length and has no size indicator. Since it's a very low cost codec this isn't a major deal - it's 160 16-entry table searches per frame. It's slightly unusual because it is a sample based codec cast that's effectively cast into a frame based format for unambiguous decoding. I can't think of any other's off hand. - Orion. From rem-conf Mon Sep 11 14:33:15 2000 From rem-conf-request@es.net Mon Sep 11 14:33:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YKb4-0007G8-00; Sun, 10 Sep 2000 20:49:30 -0700 Received: from rly-ip02.mx.aol.com [152.163.225.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YKb0-0007FN-00; Sun, 10 Sep 2000 20:49:26 -0700 Received: from tot-wc.proxy.aol.com (tot-wc.proxy.aol.com [205.188.193.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id XAA28651; Sun, 10 Sep 2000 23:32:34 -0400 (EDT) From: gft6@aol.com Received: from 172.128.132.60 (AC80843C.ipt.aol.com [172.128.132.60]) by tot-wc.proxy.aol.com (8.10.0/8.10.0) with SMTP id e8B3WRG19923; Sun, 10 Sep 2000 23:32:29 -0400 (EDT) Message-Id: <200009110332.e8B3WRG19923@tot-wc.proxy.aol.com> To: sfv4@aol.com Subject: Accept Major Credit Cards...$100 Cash Back! ADV Date: Sun, 10 Sep 00 23:41:53 Eastern Daylight Time Reply-To: gft6@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 618 Lines: 27 This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; <HTML> <BODY> <FONT face="MS Sans Serif"> <FONT size=2> -98% OF OUR APPLICANTS ARE ACCEPTED<BR> -TERMINALS & PRINTERS OR PROCESS<BR> DIRECTLY THROUGH YOU WEBSITE OR P.C.<BR> -0 DOWN W/GOOD CREDIT,<BR> -NO APPLICATION FEE WITH THIS AD.<BR> -LOWEST RATES, LOW MONTHLY PAYMENTS<BR> -ASK ABOUT OUR $100 CASH BACK!!<BR> <BR> CALL NOW!! 800-487-9955<BR> <BR> Also, complete Virtual Storefront<BR> packages are available. You just add your product, service or idea.<BR> <BR> </FONT></FONT></BODY></HTML> From rem-conf Mon Sep 11 14:33:21 2000 From rem-conf-request@es.net Mon Sep 11 14:33:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YVPm-00053r-00; Mon, 11 Sep 2000 08:22:34 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YVPk-00053f-00; Mon, 11 Sep 2000 08:22:33 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA15879; Mon, 11 Sep 2000 11:22:48 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA08057; Mon, 11 Sep 2000 20:22:27 +0500 Message-Id: <200009111522.UAA08057@hafez.east.isi.edu> To: jan.vandermeer@philips.com cc: stewe@cs.tu-berlin.de, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Mon, 11 Sep 2000 13:03:46 +0200." <0056890013989833000002L932*@MHS> Date: Mon, 11 Sep 2000 11:22:27 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1366 Lines: 32 --> jan.vandermeer@philips.com writes: >Stephan, Colin, > >Stephan wrote: > >Regardless how the generic payload format of the future may look like, >systems can be most easily designed to support both payload types. > >True. But the issue is different. Mobile devices that are build to support >the current MPEG-4 ES draft will not be capable to decode RTP payloads with >the additional info flagged by the first byte in the payload. (Note that the >additional info would be needed by other applications that include usage of >the same stream) > >In the past of MPEG, the use of "reserved fields" proved extremely powerful. >To not allow them here would be a failure in my opinion. Of course it would >be best to avoid unnecessary overhead. Therefore it would be most attractive >if the inclusion of the additional field is indicated, for example by a flag >or by a parameter that goes with the payload type. I understand that in the >RTP header no such flag is available, but that the use of a parameter >associated with the payload type would be possible. Would that be a good way >to solve this ? In RTP, that parameter is the payload type field. I really don't understand why this additional field will add value. It allows for systems to skip data which they don't understand, how is this different from using the payload type for the same effect? Colin From rem-conf Mon Sep 11 14:33:43 2000 From rem-conf-request@es.net Mon Sep 11 14:33:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YRMO-0005r3-00; Mon, 11 Sep 2000 04:02:48 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YRMN-0005qt-00; Mon, 11 Sep 2000 04:02:47 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA03892; Mon, 11 Sep 2000 13:02:43 +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 xma003880; Mon, 11 Sep 00 13:02:43 +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 NAA28834; Mon, 11 Sep 2000 13:02:42 +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 NAA15541; Mon, 11 Sep 2000 13:02:42 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890013989833; Mon, 11 Sep 2000 13:03:46 +0200 To: <csp@east.isi.edu>, <stewe@cs.tu-berlin.de> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890013989833000002L932*@MHS> Date: Mon, 11 Sep 2000 13:03:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/11/00 13:01:20" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3668 Lines: 109 Stephan, Colin, Stephan wrote: Regardless how the generic payload format of the future may look like, systems can be most easily designed to support both payload types. True. But the issue is different. Mobile devices that are build to supp= ort the current MPEG-4 ES draft will not be capable to decode RTP payloads = with the additional info flagged by the first byte in the payload. (Note tha= t the additional info would be needed by other applications that include usag= e of the same stream) In the past of MPEG, the use of "reserved fields" proved extremely powe= rful. To not allow them here would be a failure in my opinion. Of course it w= ould be best to avoid unnecessary overhead. Therefore it would be most attra= ctive if the inclusion of the additional field is indicated, for example by a= flag or by a parameter that goes with the payload type. I understand that in= the RTP header no such flag is available, but that the use of a parameter associated with the payload type would be possible. Would that be a goo= d way to solve this ? 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 ************************ -----Original Message----- From: stewe@cs.tu-berlin.de [mailto:stewe@cs.tu-berlin.de] Sent: vrijdag, 08 september, 2000 13:05 To: young@techway.co.kr Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Folks, >1. We suggest to have a room for future extension of RTP header (e.g.= one >byte of payload header at the beginning of the payload part) to make t= he >devices implementing this draft interoperable with the bitstream based= on >the generic format under development. For example, it is possible to u= se >the reserved byte to specify the length of the payload header of gener= ic >payload format. Then the device implementing this draft can play the >bitstream of generic payload format by simply skipping those bytes. I'm not sure whether this is a good idea. We would waste one byte of payload (from RTP's point of view) for something which is probably not used by any systems currently under discussion or development. Regardless how the generic payload format of the future may look like, systems can be most easily designed to support both payload types. RTP's PT mechanism has enough numbering space to support both. Capability announcement/negotiation will be different and have to be redesigned anyway for anything more capable then what is currently in the MPEG-4 ES draft. Annoucing/Negotiating another PT for the new generic payload spec will not make a difference. When, in the future, a generic payload type would be available that includes a super set of functionality of the MPEG-4 ES payload format, then we could declare the MPEG-4 ES RFC as obsolete, thereby advising people to move over to the new, generic payload type. Or, it may also be possible to have two payload specs coexisting, one for simple audio/video ES packetization only, the other containing more (the rest of?) functionality of MPEG-4. This does not sound like a bad idea to me, because the necessary demands of functionality both from the network (in terms of QoS) and implementation efforts (single audio/visual ESs vs. system layer, flexmux, whatever...) are very different. Please let the header format as is -- no more changes, otherwise you can almost certainly forget the deadline you want to meet (mid November's SG16 meeting). Stephan = From rem-conf Mon Sep 11 14:34:52 2000 From rem-conf-request@es.net Mon Sep 11 14:34:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YRqE-00072W-00; Mon, 11 Sep 2000 04:33:38 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YRqC-00072M-00; Mon, 11 Sep 2000 04:33:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29187; Mon, 11 Sep 2000 07:33:35 -0400 (EDT) Message-Id: <200009111133.HAA29187@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG <iesg-secretary@ietf.org> SUBJECT: Last Call: RTP Payload Format for ITU-T Recommendation G.722.1 to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 11 Sep 2000 07:33:34 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 502 Lines: 15 The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload Format for ITU-T Recommendation G.722.1 <draft-ietf-avt-rtp-g7221-01.txt> 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 September 25, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-01.txt From rem-conf Mon Sep 11 14:35:20 2000 From rem-conf-request@es.net Mon Sep 11 14:35:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YTL8-0001lW-00; Mon, 11 Sep 2000 06:09:38 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13YTL4-0001lL-00; Mon, 11 Sep 2000 06:09:35 -0700 Received: from zvil (i0-30.j3.actcom.co.il [192.115.22.252]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id QAA06049; Mon, 11 Sep 2000 16:09:42 +0300 Received: by localhost with Microsoft MAPI; Mon, 11 Sep 2000 16:09:04 +0200 Message-ID: <01C01C0A.9B2DE1E0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu>, "stewe@cs.tu-berlin.de" <stewe@cs.tu-berlin.de> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Mon, 11 Sep 2000 16:09: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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4791 Lines: 128 Jan, all, The simplest solution IMO is, as I proposed in the previous message, to use the first byte of the payload in the Generic format to indicate the length of the following extra header. No change is needed to the ES format. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Monday, September 11, 2000 1:04 PM To: csp@east.isi.edu; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Colin, Stephan wrote: Regardless how the generic payload format of the future may look like, systems can be most easily designed to support both payload types. True. But the issue is different. Mobile devices that are build to support the current MPEG-4 ES draft will not be capable to decode RTP payloads with the additional info flagged by the first byte in the payload. (Note that the additional info would be needed by other applications that include usage of the same stream) In the past of MPEG, the use of "reserved fields" proved extremely powerful. To not allow them here would be a failure in my opinion. Of course it would be best to avoid unnecessary overhead. Therefore it would be most attractive if the inclusion of the additional field is indicated, for example by a flag or by a parameter that goes with the payload type. I understand that in the RTP header no such flag is available, but that the use of a parameter associated with the payload type would be possible. Would that be a good way to solve this ? 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 ************************ -----Original Message----- From: stewe@cs.tu-berlin.de [mailto:stewe@cs.tu-berlin.de] Sent: vrijdag, 08 september, 2000 13:05 To: young@techway.co.kr Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Folks, >1. We suggest to have a room for future extension of RTP header (e.g. one >byte of payload header at the beginning of the payload part) to make the >devices implementing this draft interoperable with the bitstream based on >the generic format under development. For example, it is possible to use >the reserved byte to specify the length of the payload header of generic >payload format. Then the device implementing this draft can play the >bitstream of generic payload format by simply skipping those bytes. I'm not sure whether this is a good idea. We would waste one byte of payload (from RTP's point of view) for something which is probably not used by any systems currently under discussion or development. Regardless how the generic payload format of the future may look like, systems can be most easily designed to support both payload types. RTP's PT mechanism has enough numbering space to support both. Capability announcement/negotiation will be different and have to be redesigned anyway for anything more capable then what is currently in the MPEG-4 ES draft. Annoucing/Negotiating another PT for the new generic payload spec will not make a difference. When, in the future, a generic payload type would be available that includes a super set of functionality of the MPEG-4 ES payload format, then we could declare the MPEG-4 ES RFC as obsolete, thereby advising people to move over to the new, generic payload type. Or, it may also be possible to have two payload specs coexisting, one for simple audio/video ES packetization only, the other containing more (the rest of?) functionality of MPEG-4. This does not sound like a bad idea to me, because the necessary demands of functionality both from the network (in terms of QoS) and implementation efforts (single audio/visual ESs vs. system layer, flexmux, whatever...) are very different. Please let the header format as is -- no more changes, otherwise you can almost certainly forget the deadline you want to meet (mid November's SG16 meeting). Stephan From rem-conf Mon Sep 11 14:36:01 2000 From rem-conf-request@es.net Mon Sep 11 14:36:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YVWr-0005VZ-00; Mon, 11 Sep 2000 08:29:53 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13YVWp-0005V9-00; Mon, 11 Sep 2000 08:29:52 -0700 Received: from zvil (i0-30.j3.actcom.co.il [192.115.22.252]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id SAA01177; Mon, 11 Sep 2000 18:29:59 +0300 Received: by localhost with Microsoft MAPI; Mon, 11 Sep 2000 18:29:15 +0200 Message-ID: <01C01C1E.30A218A0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Colin Perkins'" <csp@east.isi.edu>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "stewe@cs.tu-berlin.de" <stewe@cs.tu-berlin.de>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Mon, 11 Sep 2000 18:29:14 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2269 Lines: 55 Indeed. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Colin Perkins [SMTP:csp@east.isi.edu] Sent: Monday, September 11, 2000 5:22 PM To: jan.vandermeer@philips.com Cc: stewe@cs.tu-berlin.de; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> jan.vandermeer@philips.com writes: >Stephan, Colin, > >Stephan wrote: > >Regardless how the generic payload format of the future may look like, >systems can be most easily designed to support both payload types. > >True. But the issue is different. Mobile devices that are build to support >the current MPEG-4 ES draft will not be capable to decode RTP payloads with >the additional info flagged by the first byte in the payload. (Note that the >additional info would be needed by other applications that include usage of >the same stream) > >In the past of MPEG, the use of "reserved fields" proved extremely powerful. >To not allow them here would be a failure in my opinion. Of course it would >be best to avoid unnecessary overhead. Therefore it would be most attractive >if the inclusion of the additional field is indicated, for example by a flag >or by a parameter that goes with the payload type. I understand that in the >RTP header no such flag is available, but that the use of a parameter >associated with the payload type would be possible. Would that be a good way >to solve this ? In RTP, that parameter is the payload type field. I really don't understand why this additional field will add value. It allows for systems to skip data which they don't understand, how is this different from using the payload type for the same effect? Colin From rem-conf Mon Sep 11 14:36:44 2000 From rem-conf-request@es.net Mon Sep 11 14:36:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YW4Y-0007GN-00; Mon, 11 Sep 2000 09:04:42 -0700 Received: from shiva.sgic.fi (shiva.great.fi) [195.10.139.61] by mail1.es.net with smtp (Exim 1.81 #2) id 13YW4R-0007FU-00; Mon, 11 Sep 2000 09:04:35 -0700 Received: from sdn-ar-001tnknoxP064.dialsprint.net_[206.133.83.48] (sdn-ar-001tnknoxP064.dialsprint.net [206.133.83.48]) by shiva.great.fi (8.6.12/8.6.9) with SMTP id RAA24761; Mon, 11 Sep 2000 17:35:40 +0200 From: chocobo7@earthlink.net Received: from by sdn-ar-001tnknoxP064.dialsprint.net with ESMTP; Mon, 11 Sep 2000 11:38:17 -0400 Message-ID: <00005f1b009d$00000662$000079ae@> To: <Undisclosed.Recipients@shiva.great.fi> Subject: Fire Your Boss!! 31150 Date: Mon, 11 Sep 2000 11:38:17 -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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1896 Lines: 59 <HTML> <BODY> <FONT face=3D"MS Sans Serif"> <FONT size=3D2> <HTML><BR><BR> FOLLOW ME TO FINANCIAL FREEDOM!!<BR><BR> <BR><BR> I Am looking for people with good work ethic and extrordinary desire<BR><B= R> to earn at least $10,000 per month working from home!<BR><BR> <BR><BR> NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the <BR><BR> training and personal support you will need to ensure your success!<BR><BR= > <BR><BR> This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in<BR><BR> control of your time,your finances,and your life!<BR><BR> <BR><BR> If you've tried other opportunities in the past that have failed to <BR><B= R> live up their promises,<BR><BR> <BR><BR> THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!<BR><BR> <BR><BR> THIS IS NOT A GET RICH QUICK SCHEME!<BR><BR> <BR><BR> YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!<BR><BR> <BR><BR> CALL ONLY IF YOU ARE SERIOUS!<BR><BR> <BR><BR> 1-800-345-9708 <BR><BR> <BR><BR> DONT GO TO SLEEP WITHOUT LISTENING TO THIS!<BR><BR> <BR><BR> "ALL our dreams can come true- if we have the courage to persue them"<BR><= BR> -Walt Disney<BR><BR> <BR><BR> Please Leave Your Name And Number And Best Time To Call<BR><BR> <BR><BR> DO NOT RESPOND BY EMAIL<BR><BR> <BR><BR> ------------------------------------------------------------------------<B= R><BR> This message is sent in compliance of the new email bill section<BR><B= R> 301.PerSection<BR><BR> 301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal<BR>= <BR> requests.Just Put Remove<BR>mailto:bagboy@= burmesses.net<BR> ------------------------------------------------------------------------= </HTML><BR> <BR> </FONT></FONT> From rem-conf Mon Sep 11 14:37:05 2000 From rem-conf-request@es.net Mon Sep 11 14:37:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YWXU-00014I-00; Mon, 11 Sep 2000 09:34:36 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13YWXT-000147-00; Mon, 11 Sep 2000 09:34:35 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 11 Sep 2000 11:32:32 UT Subject: Re: Question: packing several frames in a single RTP packet To: Orion Hodson <O.Hodson@cs.ucl.ac.uk> Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, "'Guler, Amos'" <Amos_Guler@icomverse.com>, "'rem-conf@es.net'" <rem-conf@es.net> Bcc: From: Vincent_Virgilio@nmss.com Date: Mon, 11 Sep 2000 11:33:56 -0500 Message-ID: <OF2301DF41.50469773-ON86256957.00559D8B@nmss.com> X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 09/11/2000 12:34:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1602 Lines: 52 Later drafts of RFC 1890 resolve ambiguities even for variable frame length audio codecs without size indicators (which are not sample-based). For example, take G.729A/B. It has two types of frames, a 10 byte active, and a 2 byte Annex B comfort noise. The latest draft profile specifies that the payload must consist of zero or more active frames followed by zero or one comfort noise frame. Vince Virgilio Orion Hodson <O.Hodson@cs.ucl.ac.uk>@cs.ucl.ac.uk on 09/10/2000 04:50:22 AM Sent by: O.Hodson@cs.ucl.ac.uk To: Jonathan Rosenberg <jdrosen@dynamicsoft.com> cc: "'Guler, Amos'" <Amos_Guler@icomverse.com>, "'rem-conf@es.net'" <rem-conf@es.net> Subject: Re: Question: packing several frames in a single RTP packet <B65B4F8437968F488A01A940B21982BF21FC33@DYN-EXCH-001.dynamicsoft.com>Jonathan R osenberg writes: > This may be of theoretical interest only. In practice, I think that all > frame based codecs are either (1) the same frame length, (2) indicate within > the frame itself what size or type it is, when the lengths are not the same. > Its only for frames that have variable length AND don't indicate their > length that you need worry about this. Does anyone know of any frame codecs > which are a problem? VDVI is variable length and has no size indicator. Since it's a very low cost codec this isn't a major deal - it's 160 16-entry table searches per frame. It's slightly unusual because it is a sample based codec cast that's effectively cast into a frame based format for unambiguous decoding. I can't think of any other's off hand. - Orion. From rem-conf Mon Sep 11 14:37:18 2000 From rem-conf-request@es.net Mon Sep 11 14:37:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YWf2-0001eZ-00; Mon, 11 Sep 2000 09:42:24 -0700 Received: from dmzraw2.thmulti.com [141.11.234.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YWf1-0001a4-00; Mon, 11 Sep 2000 09:42:23 -0700 Received: from smtprelay.thmulti.com ([141.11.194.9]) by dmzraw2.thmulti.com (8.9.3/8.9.1) with ESMTP id SAA17107; Mon, 11 Sep 2000 18:40:42 +0200 (MET DST) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay.thmulti.com (8.9.3/8.9.1) with SMTP id SAA23133; Mon, 11 Sep 2000 18:40:39 +0200 (MET DST) Received: from 141.11.194.5 by parexch3.paris.thmulti.com (InterScan E-Mail VirusWall NT); Mon, 11 Sep 2000 18:37:42 +0200 (Romance Daylight Time) Received: by parexch3.thmulti.com with Internet Mail Service (5.5.2448.0) id <R88GH41F>; Mon, 11 Sep 2000 18:36:44 +0200 Message-ID: <2CEEE9E85750D2119F4000805F3172884C2CAF@hanexch1.hanover.thmulti.com> From: Herpel Carsten <HerpelC@thmulti.com> To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Mon, 11 Sep 2000 18:39:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2380 Lines: 58 Dear all, Jan: >True. But the issue is different. Mobile devices that are build to support >the current MPEG-4 ES draft will not be capable to decode RTP payloads with >the additional info flagged by the first byte in the payload. (Note that the >additional info would be needed by other applications that include usage of >the same stream) > >In the past of MPEG, the use of "reserved fields" proved extremely powerful. >To not allow them here would be a failure in my opinion. Of course it would >be best to avoid unnecessary overhead. Therefore it would be most attractive >if the inclusion of the additional field is indicated, for example by a flag >or by a parameter that goes with the payload type. I understand that in the >RTP header no such flag is available, but that the use of a parameter >associated with the payload type would be possible. Would that be a good way >to solve this ? Colin: >In RTP, that parameter is the payload type field. > >I really don't understand why this additional field will add value. It >allows for systems to skip data which they don't understand, how is this >different from using the payload type for the same effect? What happens here is a clash of worlds. The two of you have different pre-conditions for their proposals, if I am not mistaken. One assumption is that huge numbers of devices will be out there that use the ES payload format. Assuming that these devices cannot be upgraded to a newer payload format! Then applications come up with more functionality, using MPEG-4 Systems. New devices will exist that know how to use this functionality. Old devices should at least be able to understand the (unmodified!) MPEG-4 Video over RTP stream. Since the old devices are not reprogrammable, they cannot be upgraded to another payload format. So the old format needs to be by design compatible to any new format. On the other hand is the assumption that when a new payload format gets defined, all the existing devices will just be reprogrammed to read the new format. And possibly the assumption that the changes in payload format will be bigger than what can be captured by the proposal of just adding a single field to be skipped. Is the first assumption so completely wrong that we can afford to go the second way that is apparently being advocated by a majority of the speakers in this thread? Regards, Carsten From rem-conf Mon Sep 11 14:37:52 2000 From rem-conf-request@es.net Mon Sep 11 14:37:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YWy8-00037Q-00; Mon, 11 Sep 2000 10:02:08 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13YWy5-000364-00; Mon, 11 Sep 2000 10:02:06 -0700 Received: from zvil (i0-30.j3.actcom.co.il [192.115.22.252]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id UAA15766; Mon, 11 Sep 2000 20:02:08 +0300 Received: by localhost with Microsoft MAPI; Mon, 11 Sep 2000 20:01:32 +0200 Message-ID: <01C01C2B.14CCA020.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Herpel Carsten'" <HerpelC@thmulti.com>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call_?= Date: Mon, 11 Sep 2000 20:01:31 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1869 Lines: 50 [Herpel Carsten:] One assumption is that huge numbers of devices will be out there that use the ES payload format. Assuming that these devices cannot be upgraded to a newer payload format! Then applications come up with more functionality, using MPEG-4 Systems. New devices will exist that know how to use this functionality. Old devices should at least be able to understand the (unmodified!) MPEG-4 Video over RTP stream. Since the old devices are not reprogrammable, they cannot be upgraded to another payload format. So the old format needs to be by design compatible to any new format. [Reply:] How would it help? The new format will come with a new payload type, and if the old devices don't know this payload type they will not read it because they don't know what it is. In other words they will not know they know how to read it... So they will need to be reprogrammed to identify the new payload type. 2 extra lines of code and they will know how to read it even if it's not identical to the old one. And BTW I'm not sure the assumption is real. The two formats are there more or less at the same time. One is a little bit advanced in the procedure, but I don't believe this will create the "huge numbers" of devices that know one and not the other. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Mon Sep 11 14:38:16 2000 From rem-conf-request@es.net Mon Sep 11 14:38:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YXrM-0005CC-00; Mon, 11 Sep 2000 10:59:12 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13YXrJ-0005Bc-00; Mon, 11 Sep 2000 10:59:10 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.10437-0@bells.cs.ucl.ac.uk>; Mon, 11 Sep 2000 18:58:51 +0100 From: Orion Hodson <O.Hodson@cs.ucl.ac.uk> X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Vincent_Virgilio@nmss.com cc: "'rem-conf@es.net'" <rem-conf@es.net> Subject: Re: Question: packing several frames in a single RTP packet In-reply-to: Your message of "Mon, 11 Sep 2000 11:33:56 CDT." <OF2301DF41.50469773-ON86256957.00559D8B@nmss.com> Date: Mon, 11 Sep 2000 18:58:50 +0100 Message-ID: <28467.968695130@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1153 Lines: 28 <OF2301DF41.50469773-ON86256957.00559D8B@nmss.com>Vincent_Virgilio@nmss.com wri tes: > > Later drafts of RFC 1890 resolve ambiguities even for variable frame length > audio codecs without size indicators (which are not sample-based). For > example, take G.729A/B. It has two types of frames, a 10 byte active, and > a 2 byte Annex B comfort noise. The latest draft profile specifies that > the payload must consist of zero or more active frames followed by zero or > one comfort noise frame. The current draft (draft-ietf-avt-profile-new-09.txt) has the wording about relatively prime payload sizes. I believe the wording about mixing CN and coded frames is specific to G.729, and the combination of speech and CN frames. G.729 and it's annexes cover several different bit-rates and correspondingly different frame sizes. Different payload identifiers are used for the different bit-rate representations and therefore different speech frame sizes cannot be packetized within packets the same packet. This solution is an implicit realization of Amos's point and is one way of solving the problem should it occur with other codecs. - orion. From rem-conf Mon Sep 11 14:38:34 2000 From rem-conf-request@es.net Mon Sep 11 14:38:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YYnI-0007e3-00; Mon, 11 Sep 2000 11:59:04 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13YYnG-0007dt-00; Mon, 11 Sep 2000 11:59:02 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-167.dialup.cs.tu-berlin.de [130.149.145.167]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id UAA06815; Mon, 11 Sep 2000 20:56:35 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000911203651.02cbd2d0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Sep 2000 20:57:18 +0200 To: Herpel Carsten <HerpelC@thmulti.com> From: Stephan Wenger <stewe@cs.tu-berlin.de> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu In-Reply-To: <2CEEE9E85750D2119F4000805F3172884C2CAF@hanexch1.hanover.th multi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2319 Lines: 55 Folks >What happens here is a clash of worlds. Clearly, it is! But I don't think that Carsten came to the real point here. IMHO, the main point is that MPEG-folk seem to think that the media stream (RTP/payload/MPEG) should be self-contained and independent from the higher protocol layers that perform the capability exchange/announcement (and other things such as call establishment etc.). IETF/AVT folk (including me), however, make the implicit assumption that media cannot be seen independently from higher protocols. The latter, however, is not an assumption -- its the plain truth, especially after AVT made it the general policy to no more assign static payload types for media coding. This means, that RTP systems rely (and cannot live without) some external form of capability exchange/announcement, which, as a minimum, dynamically (per call) associates a freely chosen number with a certain payload (e.g. MPEG-4 ES or, in the future, MPEG-4 generic/SL/whatever). The information which payload is to be transmitted is in H.245, for example, coded in ASN.1. For SIP systems, the relevant information is transmitted in ASCII form, where the payload types (such as MPEG-4-ES) has typically a MIME registration. That is why Colin and me and others insist that there is no need to duplicate this type of information in the media stream. Every system that uses RTP in a standard-compliant way has already the functionality build in that is necessary to distinguish between different payload types. >One assumption is that huge numbers of devices will be out there that use >the ES payload format. Assuming that these devices cannot be upgraded to a >newer payload format! >Then applications come up with more functionality, using MPEG-4 Systems. New >devices will exist that know how to use this functionality. Old devices >should at least be able to understand the (unmodified!) MPEG-4 Video over >RTP stream. Since the old devices are not reprogrammable, they cannot be >upgraded to another payload format. So the old format needs to be by design >compatible to any new format. Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-ES. Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-ES. This is how things are done, at least in H.323, all the time. Stephan From rem-conf Mon Sep 11 19:33:47 2000 From rem-conf-request@es.net Mon Sep 11 19:33:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YfpN-0003RQ-00; Mon, 11 Sep 2000 19:29:41 -0700 Received: from relay100.jaring.my [192.228.128.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YfpK-0003RC-00; Mon, 11 Sep 2000 19:29:38 -0700 Received: (from root@localhost) by relay100.jaring.my (8.9.3/8.9.3) with UUCP id KAA13186 for rem-conf@es.net; Tue, 12 Sep 2000 10:28:33 +0800 (MYT) Received: from vmstech.po.my by vmstechnology.po.my (UUPC/extended 1.13b) with ESMTP for rem-conf@es.net; Tue, 12 Sep 2000 10:26:56 +0800 Received: from sweetysl.po.my ([192.228.118.29]) by vmstech.po.my with id 39BD9462.00000511@vmstech.po.my; Tue, 12 Sep 2000 02:26:42 GMT Message-ID: <005701c01c60$79968680$1d76e4c0@sweetysl> From: "yslee" <yslee@vmstech.po.my> To: <rem-conf@es.net> References: <OFEC9E2CDE.B2A86AC6-ON86256951.00581783@nmss.com> Subject: How to receive list mails batched in a daily digest? Date: Tue, 12 Sep 2000 10:23:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5 Lines: 5 From rem-conf Mon Sep 11 23:37:27 2000 From rem-conf-request@es.net Mon Sep 11 23:37:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yja4-0006fU-00; Mon, 11 Sep 2000 23:30:08 -0700 Received: from client80n19221650.rrhi.net (mhruby.lynden.com) [192.216.50.80] by mail1.es.net with smtp (Exim 1.81 #2) id 13Yja2-0006f4-00; Mon, 11 Sep 2000 23:30:07 -0700 From: "Sales/Marketing" <info@luxurycarts.com> To: <rem-conf@es.net> Subject: luxuryCarts,com - Online Source for Custom Golf Carts Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 11 Sep 2000 20:32:16 Message-Id: <E13Yja2-0006f4-00@mail1.es.net> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 265 Lines: 9 Please visit www.luxuryCarts.com for the premier online source for custom golf carts and kit carts available. If this email was received at the wrong party, please type "remove" in the subject line and hit send. Regards, The Marketing Staff at luxuryCarts.com From rem-conf Tue Sep 12 03:17:30 2000 From rem-conf-request@es.net Tue Sep 12 03:17:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yn3Z-00023n-00; Tue, 12 Sep 2000 03:12:49 -0700 Received: from rly-mx1.maxis.net.my [202.75.130.117] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yn3V-00022e-00; Tue, 12 Sep 2000 03:12:45 -0700 Received: from mail pickup service by rly-mx1.maxis.net.my with Microsoft SMTPSVC; Tue, 12 Sep 2000 17:59:11 +0800 Received: from rly-mx1.maxis.net.my ([202.75.130.117]) by rly-mx1.maxis.net.my with Microsoft SMTPSVC(5.5.1877.467.46); Sat, 9 Sep 2000 09:28:44 +0800 Received: from www.mysql.com (web.mysql.com [192.58.197.162]) by rly-mx1.maxis.net.my with SMTP (MailShield v1.5); Sat, 09 Sep 2000 09:28:43 -0700 Received: (qmail 27910 invoked by uid 7797); 9 Sep 2000 01:22:50 -0000 Mailing-List: contact mysql-help@lists.mysql.com; run by ezmlm (http://www.ezmlm.org) List-ID: <mysql.mysql.com> List-Help: <mailto:mysql-help@lists.mysql.com> List-Unsubscribe: <mailto:mysql-unsubscribe-jncc=maxis.net.my@lists.mysql.com> List-Post: <mailto:mysql@lists.mysql.com> List-Subscribe: <mailto:mysql-subscribe@lists.mysql.com> Delivered-To: mailing list mysql@lists.mysql.com Received: (qmail 27895 invoked from network); 9 Sep 2000 01:22:49 -0000 Message-ID: <001201c019fc$d1f066e0$49d78796@rsk> From: "Riyad Kalla" <rsk@u.arizona.edu> To: "Dave Dunstan" <dave@webuildthe.com>, "'Luis Montes'" <LMontes@computer-guidance.com>, "'rusty'" <rustyc@inficad.com>, "'Mark Weaver'" <mdw1982@epix.net> Cc: "'Li Bing'" <bing.li@asu.edu>, "'Zigang Zhu'" <eagle@cloudnet.com.cn>, "'Zhu Zigang'" <sales@cncard.com>, "'ZhenweiShen'" <ZhenweiShen@acersoftech.com.cn>, "'Zheng. Tom. Yuan'" <Tom.Yuan@asu.edu>, "'Yingqi Kong'" <yingqik@asu.edu>, "'Xiaoying Bai'" <xiaoying.bai@asu.edu>, "'WINSOCK-2'" <WINSOCK-2@mailbag.cps.intel.com>, "'Webdesigners'" <webdesigners@egroups.com>, "'VOA XinWen News Service'" <xinwen-l@lists.VOA.GOV>, "'Techeng Shen'" <techeng@asu.edu>, "'SERVLET-INTEREST'" <SERVLET-INTEREST@JAVA.SUN.COM>, "'RTLINUX'" <rtl@rtlinux.org>, "'Rtl-Announce'" <rtl-announce@rtlinux.org>, "'Rtl'" <rtl@www.rtlinux.org>, "'Rsvp'" <rsvp@ISI.EDU>, "'Rem-Conf'" <rem-conf@es.net>, "'Redhat-Devel-List'" <redhat-devel-list@redhat.com>, "'Quyouli'" <quyouli@frdc-fujitsu.com.cn>, "'Pan Guobin'" <Guobin.Pan@asu.edu>, "'MySQL'" <mysql@lists.mysql.com>, "'Msql-Jdbc'" <msql-jdbc@list.imaginary.com>, "'Lyx-Users'" <lyx-users@lists.lyx.org>, "'Lyx-Devel'" <lyx-devel@lyx.org>, "'Lyx Mailing List'" <lyx-devel@lists.lyx.org>, "'Linux-Atm'" <linux-atm@lrc.epfl.ch>, "'JDCMember'" <JDCMember@sun.com>, "'Javamug'" <javamug@utdallas.edu>, "'JavaLearners'" <JavaLearners@egroups.com>, "'Java_Help'" <java_help@egroups.com>, "'Java'" <java@phxjug.org>, "'Java'" <java@egroups.com>, "'Java'" <java@jfind.com>, "'J2EE-INTEREST'" <J2EE-INTEREST@JAVA.SUN.COM>, "'Ietf'" <ietf@ietf.org>, "'IDL-USERS'" <IDL-USERS@JAVA.SUN.COM>, "'Huang Ning'" <ninghuang@lucent.com>, "'Gnome-List'" <gnome-list@gnome.org>, "'Fariaz Karim'" <karim@asu.edu>, "'Dmiller'" <donald.miller@asu.edu>, "'CORBA-patterns'" <CORBA-patterns@cs.uiuc.edu>, "'Corba-Dev'" <corba-dev@randomwalk.com>, "'Confctrl'" <confctrl@ISI.EDU>, "'Cgi-List'" <cgi-list@jann.com>, "'Blinux-Newbie'" <blinux-newbie@braille.uwo.ca>, "'Blinux-List'" <blinux-list@redhat.com>, "'BJ CN \) Jun_Fan Hu \(MED'" <Jun_Fan.Hu@china.med.ge.com>, "'Baisu Huang'" <baisu.huang@asu.edu>, "'ASULUG'" <ASULUG@asu.edu>, "'Agoracgi'" <agoracgi@egroups.com>, "'Advanced-Java'" <advanced-java@xcf.berkeley.edu> References: <CA129E889266D411924000E018C00201024186@dnai-216-15-54-199.cust.dnai.com> Subject: Re: [phxjug-java] Re: Two tools to remove the virus LIFE_STAGES.TXT.SHS Date: Fri, 8 Sep 2000 18:25:20 -0700 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-SMTP-HELO: www.mysql.com X-SMTP-MAIL-FROM: mysql-return-50131-jncc=maxis.net.my@lists.mysql.com X-SMTP-RCPT-TO: jncc@maxis.net.my X-SMTP-PEER-INFO: web.mysql.com [192.58.197.162] X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6714 Lines: 163 Don't say that, its too intelligent. Lets get back to talking about how other OSs cause cancer and kill farm animals <turns around and sees dog drop dead> NOOOOOO!!! I'LL GET YOU WINDOWS!!! Have a good weekend everyone! -Riyad ----- Original Message ----- From: "Dave Dunstan" <dave@webuildthe.com> To: "'Luis Montes'" <LMontes@computer-guidance.com>; "'rusty'" <rustyc@inficad.com>; "'Mark Weaver'" <mdw1982@epix.net> Cc: "'Li Bing'" <bing.li@asu.edu>; "'Zigang Zhu'" <eagle@cloudnet.com.cn>; "'Zhu Zigang'" <sales@cncard.com>; "'ZhenweiShen'" <ZhenweiShen@acersoftech.com.cn>; "'Zheng. Tom. Yuan'" <Tom.Yuan@asu.edu>; "'Yingqi Kong'" <yingqik@asu.edu>; "'Xiaoying Bai'" <xiaoying.bai@asu.edu>; "'WINSOCK-2'" <WINSOCK-2@mailbag.cps.intel.com>; "'Webdesigners'" <webdesigners@egroups.com>; "'VOA XinWen News Service'" <xinwen-l@lists.VOA.GOV>; "'Techeng Shen'" <techeng@asu.edu>; "'SERVLET-INTEREST'" <SERVLET-INTEREST@JAVA.SUN.COM>; "'RTLINUX'" <rtl@rtlinux.org>; "'Rtl-Announce'" <rtl-announce@rtlinux.org>; "'Rtl'" <rtl@www.rtlinux.org>; "'Rsvp'" <rsvp@ISI.EDU>; "'Rem-Conf'" <rem-conf@es.net>; "'Redhat-Devel-List'" <redhat-devel-list@redhat.com>; "'Quyouli'" <quyouli@frdc-fujitsu.com.cn>; "'Pan Guobin'" <Guobin.Pan@asu.edu>; "'MySQL'" <mysql@lists.mysql.com>; "'Msql-Jdbc'" <msql-jdbc@list.imaginary.com>; "'Lyx-Users'" <lyx-users@lists.lyx.org>; "'Lyx-Devel'" <lyx-devel@lyx.org>; "'Lyx Mailing List'" <lyx-devel@lists.lyx.org>; "'Linux-Atm'" <linux-atm@lrc.epfl.ch>; "'JDCMember'" <JDCMember@sun.com>; "'Javamug'" <javamug@utdallas.edu>; "'JavaLearners'" <JavaLearners@egroups.com>; "'Java_Help'" <java_help@egroups.com>; "'Java'" <java@phxjug.org>; "'Java'" <java@egroups.com>; "'Java'" <java@jfind.com>; "'J2EE-INTEREST'" <J2EE-INTEREST@JAVA.SUN.COM>; "'Ietf'" <ietf@ietf.org>; "'IDL-USERS'" <IDL-USERS@JAVA.SUN.COM>; "'Huang Ning'" <ninghuang@lucent.com>; "'Gnome-List'" <gnome-list@gnome.org>; "'Fariaz Karim'" <karim@asu.edu>; "'Dmiller'" <donald.miller@asu.edu>; "'CORBA-patterns'" <CORBA-patterns@cs.uiuc.edu>; "'Corba-Dev'" <corba-dev@randomwalk.com>; "'Confctrl'" <confctrl@ISI.EDU>; "'Cgi-List'" <cgi-list@jann.com>; "'Blinux-Newbie'" <blinux-newbie@braille.uwo.ca>; "'Blinux-List'" <blinux-list@redhat.com>; "'BJ CN ) Jun_Fan Hu (MED'" <Jun_Fan.Hu@china.med.ge.com>; "'Baisu Huang'" <baisu.huang@asu.edu>; "'ASULUG'" <ASULUG@asu.edu>; "'Agoracgi'" <agoracgi@egroups.com>; "'Advanced-Java'" <advanced-java@xcf.berkeley.edu> Sent: Friday, September 08, 2000 5:17 PM Subject: RE: [phxjug-java] Re: Two tools to remove the virus LIFE_STAGES.TXT.SHS > ok zealots. use the right tool for the job and feed your families. > > Dave Dunstan | dave@webuildthe.com > Mission Control Consulting LLC > 1383a 9th Ave, San Francisco CA 94122 > ph: 415.504.8177 | fx: 415.504.8172 > > > > -----Original Message----- > > From: Luis Montes [mailto:LMontes@computer-guidance.com] > > Sent: Friday, September 08, 2000 5:23 PM > > To: rusty; Mark Weaver > > Cc: Li Bing; Zigang Zhu; Zhu Zigang; ZhenweiShen; Zheng. Tom. Yuan; > > Yingqi Kong; Xiaoying Bai; WINSOCK-2; Webdesigners; VOA XinWen News > > Service; Techeng Shen; SERVLET-INTEREST; RTLINUX; Rtl-Announce; Rtl; > > Rsvp; Rem-Conf; Redhat-Devel-List; Quyouli; Pan Guobin; MySQL; > > Msql-Jdbc; Lyx-Users; Lyx-Devel; Lyx Mailing List; Linux-Atm; > > JDCMember; > > Javamug; JavaLearners; Java_Help; Java; Java; Java; > > J2EE-INTEREST; Ietf; > > IDL-USERS; Huang Ning; Gnome-List; Fariaz Karim; Dmiller; > > CORBA-patterns; Corba-Dev; Confctrl; Cgi-List; Blinux-Newbie; > > Blinux-List; BJ CN ) Jun_Fan Hu (MED; Baisu Huang; ASULUG; Agoracgi; > > Advanced-Java > > Subject: RE: [phxjug-java] Re: Two tools to remove the virus > > LIFE_STAGES.TXT.SHS > > > > > > Amen Brother > > > > > -----Original Message----- > > > From: rusty [SMTP:rustyc@inficad.com] > > > Sent: Friday, September 08, 2000 4:59 PM > > > To: Mark Weaver > > > Cc: Li Bing; Zigang Zhu; Zhu Zigang; ZhenweiShen; Zheng. Tom. Yuan; > > > Yingqi Kong; Xiaoying Bai; WINSOCK-2; Webdesigners; VOA XinWen News > > > Service; Techeng Shen; SERVLET-INTEREST; RTLINUX; > > Rtl-Announce; Rtl; Rsvp; > > > Rem-Conf; Redhat-Devel-List; Quyouli; Pan Guobin; MySQL; Msql-Jdbc; > > > Lyx-Users; Lyx-Devel; Lyx Mailing List; Linux-Atm; > > JDCMember; Javamug; > > > JavaLearners; Java_Help; Java; Java; Java; J2EE-INTEREST; > > Ietf; IDL-USERS; > > > Huang Ning; Gnome-List; Fariaz Karim; Dmiller; > > CORBA-patterns; Corba-Dev; > > > Confctrl; Cgi-List; Blinux-Newbie; Blinux-List; BJ CN ) > > Jun_Fan Hu (MED; > > > Baisu Huang; ASULUG; Agoracgi; Advanced-Java > > > Subject: Re: [phxjug-java] Re: Two tools to remove the virus > > > LIFE_STAGES.TXT.SHS > > > > > > Mark Weaver wrote: > > > > > > > > What the HELL is this? A virus warning? This is exactly > > why I don't use > > > > Windows anymore. Thank God for Linux. You all can have > > your Windows and > > > > your virii. > > > > > > > I'd like to put it a bit more strongly - Anybody who uses microsoft > > > tools > > > deserves everything that happens to them, given the track history of > > > viruses on that 'platform'. There is no longer any excuse. > > > > > > And any IT 'professional' who chooses Microsoft tools for their > > > company > > > should pay for the damage caused by use (and breakins using) those > > > tools. > > > > > > Or perhaps just get fired. > > > > > > rusty > > > > > > -- > > > To unsubscribe, send a message to java-request@phxjug.org with > > > "unsubscribe" in the *subject line*. If you have problems, send a > > > message to 'listmaster@phxjug.org'. > > > > -- > > --------------------------------------------------------------------- > > Please check "http://www.mysql.com/php/manual.php" before > > posting. To request this thread, e-mail > > mysql-thread50124@lists.mysql.com > > > > To unsubscribe, send a message to: > > <mysql-unsubscribe-dave=webuildthe.com@lists.mysql.com> > > > > If you have a broken mail client that cannot send a message > > to the above address(Microsoft Outlook), you can use > http://lists.mysql.com/php/unsubscribe.php > > -- > To unsubscribe, send a message to java-request@phxjug.org with > "unsubscribe" in the *subject line*. If you have problems, send a > message to 'listmaster@phxjug.org'. > -- --------------------------------------------------------------------- Please check "http://www.mysql.com/php/manual.php" before posting. To request this thread, e-mail mysql-thread50131@lists.mysql.com To unsubscribe, send a message to: <mysql-unsubscribe-jncc=maxis.net.my@lists.mysql.com> If you have a broken mail client that cannot send a message to the above address(Microsoft Outlook), you can use http://lists.mysql.com/php/unsubscribe.php From rem-conf Tue Sep 12 03:43:44 2000 From rem-conf-request@es.net Tue Sep 12 03:43:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YnWX-0003Dp-00; Tue, 12 Sep 2000 03:42:45 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YnWV-0003Df-00; Tue, 12 Sep 2000 03:42:43 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA26928; Tue, 12 Sep 2000 12:42:41 +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 xma026923; Tue, 12 Sep 00 12:42:41 +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 MAA02450; Tue, 12 Sep 2000 12:42:40 +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 MAA25686; Tue, 12 Sep 2000 12:42:39 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014020160; Tue, 12 Sep 2000 12:43:44 +0200 To: <HerpelC@thmulti.com>, <stewe@cs.tu-berlin.de> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014020160000002L902*@MHS> Date: Tue, 12 Sep 2000 12:43:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 12:41:15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4489 Lines: 128 Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but = I also think that Carsten did make the real point. Let me explain below w= ith an example. A service provides several multicast sessions to mobile devices using t= he simple MPEG-4 ES payload format. This is done during a sport event such= as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch = my own favorite racer on my mobile device. When at home, I watch the broad= cast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favor= ite racer on TV, as an overlay over the broadcast video. For this purpose, = some information is needed that is contained in an SL header. In order to be= bandwidth efficient on the mobile network, the same multicast session i= s used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgrada= ble; these dedicated devices are not capable to even process a single byte t= o upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And t= he essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for = such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan -----Original Message----- From: stewe@cs.tu-berlin.de [mailto:stewe@cs.tu-berlin.de] Sent: maandag, 11 september, 2000 21:05 To: HerpelC@thmulti.com Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Folks >What happens here is a clash of worlds. Clearly, it is! But I don't think that Carsten came to the real point here. IMHO, the main point is that MPEG-folk seem to think that the media stream (RTP/payload/MPEG) should be self-contained and independent from the higher protocol layers that perform the capability exchange/announcement (and other things such as call establishment etc.). IETF/AVT folk (including me), however, make the implicit assumption that media cannot be seen independently from higher protocols. The latter, however, is not an assumption -- its the plain truth, especially after AVT made it the general policy to no more assign static payload types for media coding. This means, that RTP systems rely (and cannot live without) some external form of capability exchange/announcement, which, as a minimum, dynamically (per call) associates a freely chosen number with a certain payload (e.g. MPEG-4 ES or, in the future, MPEG-4 generic/SL/whatever). The information which payload is to be transmitted is in H.245, for example, coded in ASN.1. For SIP systems, the relevant information is transmitted in ASCII form, where the payload types (such as MPEG-4-ES) has typically a MIME registration. That is why Colin and me and others insist that there is no need to duplicate this type of information in the media stream. Every system that uses RTP in a standard-compliant way has already the functionality build in that is necessary to distinguish between different payload types. >One assumption is that huge numbers of devices will be out there that = use >the ES payload format. Assuming that these devices cannot be upgraded = to a >newer payload format! >Then applications come up with more functionality, using MPEG-4 System= s. New >devices will exist that know how to use this functionality. Old device= s >should at least be able to understand the (unmodified!) MPEG-4 Video o= ver >RTP stream. Since the old devices are not reprogrammable, they cannot = be >upgraded to another payload format. So the old format needs to be by d= esign >compatible to any new format. Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-E= S. Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-ES= . This is how things are done, at least in H.323, all the time. Stephan = From rem-conf Tue Sep 12 04:02:03 2000 From rem-conf-request@es.net Tue Sep 12 04:02:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ynn2-0004GN-00; Tue, 12 Sep 2000 03:59:48 -0700 Received: from isis.lip6.fr [132.227.60.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ynn1-0004GD-00; Tue, 12 Sep 2000 03:59:47 -0700 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id MAA06735 for <rem-conf@es.net>; Tue, 12 Sep 2000 12:59:43 +0200 Received: from matisse (sphinx.lip6.fr [132.227.74.253]) by rp.lip6.fr (8.8.8/jtpda-5.2) with SMTP id MAA05288 for <rem-conf@es.net>; Tue, 12 Sep 2000 12:59:42 +0200 (MEST) From: "Eric Horlait" <eric.horlait@lip6.fr> To: "Rem-Conf@Es. Net" <rem-conf@es.net> Subject: Mobile Agents for Telecommunication Applications, Paris, France Date: Tue, 12 Sep 2000 12:59:42 +0200 Message-ID: <LOBBIJNOFFPCOIPKCLMLKEPGEMAA.eric.horlait@lip6.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 809 Lines: 27 ==============================================================(360628) [My apologies if you receive this more than once] ============================================================== CALL FOR PARTICIPATION MATA'2000 - Paris, France NEXT WEEK Second International Workshop on Mobile Agents for Telecommunication Applications ======================================================================== = September 19-20, 2000 Paris, France http://netconf.lip6.fr/mata00/ MATA '2000 presents a unique opportunity for researchers, software and Application developers, and computer network technologists to discuss new developments on the mobile agent technology and applications. For complete program information, registration fees, or online registration form please visit http://netconf.lip6.fr/mata00/ From rem-conf Tue Sep 12 04:29:34 2000 From rem-conf-request@es.net Tue Sep 12 04:29:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yo7o-0005YW-00; Tue, 12 Sep 2000 04:21:16 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yo7m-0005Wn-00; Tue, 12 Sep 2000 04:21:14 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLCKW>; Tue, 12 Sep 2000 14:22:11 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908155@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com, HerpelC@thmulti.com, stewe@cs.tu-berlin.de Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 14:22:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2849 Lines: 70 Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but I also think that Carsten did make the real point. Let me explain below with an example. A service provides several multicast sessions to mobile devices using the simple MPEG-4 ES payload format. This is done during a sport event such as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch my own favorite racer on my mobile device. When at home, I watch the broadcast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favorite racer on TV, as an overlay over the broadcast video. For this purpose, some information is needed that is contained in an SL header. In order to be bandwidth efficient on the mobile network, the same multicast session is used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgradable; these dedicated devices are not capable to even process a single byte to upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And the essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan From rem-conf Tue Sep 12 06:54:25 2000 From rem-conf-request@es.net Tue Sep 12 06:54:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YqRN-0000be-00; Tue, 12 Sep 2000 06:49:37 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YqRM-0000bU-00; Tue, 12 Sep 2000 06:49:36 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA27533; Tue, 12 Sep 2000 15:49:33 +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 xma027524; Tue, 12 Sep 00 15:49:34 +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 PAA12283; Tue, 12 Sep 2000 15:49:33 +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 PAA09820; Tue, 12 Sep 2000 15:49:31 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014027801; Tue, 12 Sep 2000 15:50:36 +0200 To: <ZviL@optibase.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014027801000002L912*@MHS> Date: Tue, 12 Sep 2000 15:50:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 15:47:56" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3685 Lines: 112 Dear Zvi, I thought I did. What I try to say is: to have this type of functionali= ty in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, 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 <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but = I also think that Carsten did make the real point. Let me explain below w= ith an example. A service provides several multicast sessions to mobile devices using t= he simple MPEG-4 ES payload format. This is done during a sport event such= as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch = my own favorite racer on my mobile device. When at home, I watch the broad= cast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favor= ite racer on TV, as an overlay over the broadcast video. For this purpose, = some information is needed that is contained in an SL header. In order to be= bandwidth efficient on the mobile network, the same multicast session i= s used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgrada= ble; these dedicated devices are not capable to even process a single byte t= o upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And t= he essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for = such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan = From rem-conf Tue Sep 12 07:08:47 2000 From rem-conf-request@es.net Tue Sep 12 07:08:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YqfN-0001fR-00; Tue, 12 Sep 2000 07:04:05 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YqfL-0001d4-00; Tue, 12 Sep 2000 07:04:04 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLCW0>; Tue, 12 Sep 2000 17:05:00 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908161@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com, Zvi Lifshitz <ZviL@optibase.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 17:04:59 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4427 Lines: 118 It will not help, because when you get the new payload in the future the old devices don't recognize the payload type and will not handle it. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionality in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but I also think that Carsten did make the real point. Let me explain below with an example. A service provides several multicast sessions to mobile devices using the simple MPEG-4 ES payload format. This is done during a sport event such as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch my own favorite racer on my mobile device. When at home, I watch the broadcast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favorite racer on TV, as an overlay over the broadcast video. For this purpose, some information is needed that is contained in an SL header. In order to be bandwidth efficient on the mobile network, the same multicast session is used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgradable; these dedicated devices are not capable to even process a single byte to upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And the essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan From rem-conf Tue Sep 12 07:19:32 2000 From rem-conf-request@es.net Tue Sep 12 07:19:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yqt9-0002v1-00; Tue, 12 Sep 2000 07:18:19 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yqt7-0002ur-00; Tue, 12 Sep 2000 07:18:17 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA24380; Tue, 12 Sep 2000 10:18:33 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id TAA04967; Tue, 12 Sep 2000 19:18:12 +0500 Message-Id: <200009121418.TAA04967@hafez.east.isi.edu> To: jan.vandermeer@philips.com cc: HerpelC <HerpelC@thmulti.com>, stewe <stewe@cs.tu-berlin.de>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 12:43:44 +0200." <0056890014020160000002L902*@MHS> Date: Tue, 12 Sep 2000 10:18:12 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4835 Lines: 112 I don't understand why you don't simply send the composition information along with the broadcast signal? Sending it with the mobile signal (where it is useless unless the broadcast signal is also received) seems to be a waste of mobile capacity. Colin --> jan.vandermeer@philips.com writes: >Stephan, Carsten, Colin, Zvi and others, > >It surely is a clash of worlds. And I think we did not come to full >understanding yet. I think I understand the point made by Stephan, but I >also think that Carsten did make the real point. Let me explain below with >an example. > >A service provides several multicast sessions to mobile devices using the >simple MPEG-4 ES payload format. This is done during a sport event such as >the "Tour de France" providing the performance of a number of favorite >racers. At the same time there is a broadcast coverage of the event, >providing a more global overview. Now, when I am "on the road" I watch my >own favorite racer on my mobile device. When at home, I watch the broadcast >coverage on my TV. This TV has the capability to also receive mobile >services. Over the normal broadcast channel an MPEG-4 application is >delivered that allows me to display the multicast streaming of my favorite >racer on TV, as an overlay over the broadcast video. For this purpose, some >information is needed that is contained in an SL header. In order to be >bandwidth efficient on the mobile network, the same multicast session is >used as for mobile devices. > >Now follows an essential assumption: the mobile devices are not_upgradable; >these dedicated devices are not capable to even process a single byte to >upgrade their functionality. If this assumption is true, they need the >capability to accept the additional bytes from day one. Otherwise two >separate multicast sessions are needed. > >In my understanding there are no higher level protocols involved. And the >essential question is whether these mobile devices are indeed not >upgradable. It is my guess that upgradability is not a requirement for such >devices, but only a feature that cannot be relied upon. > >I hope this clarifies. > >Kind regards, > >Jan > >-----Original Message----- >From: stewe@cs.tu-berlin.de [mailto:stewe@cs.tu-berlin.de] >Sent: maandag, 11 september, 2000 21:05 >To: HerpelC@thmulti.com >Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to >the last call > > >Folks > >>What happens here is a clash of worlds. > >Clearly, it is! > >But I don't think that Carsten came to the real point here. > >IMHO, the main point is that MPEG-folk seem to think that >the media stream (RTP/payload/MPEG) should be self-contained >and independent from the higher protocol layers that perform the >capability exchange/announcement (and other things such >as call establishment etc.). >IETF/AVT folk (including me), however, make the implicit >assumption that media cannot be seen independently from >higher protocols. > >The latter, however, is not an assumption -- its the plain truth, >especially after AVT made it the general policy to no more >assign static payload types for media coding. > >This means, that RTP systems rely (and cannot live without) >some external form of capability exchange/announcement, which, >as a minimum, dynamically (per call) associates a freely chosen >number with a certain payload (e.g. MPEG-4 ES or, in the future, >MPEG-4 generic/SL/whatever). The information which payload is >to be transmitted is in H.245, for example, coded in ASN.1. For SIP >systems, the relevant information is transmitted in ASCII form, >where the payload types (such as MPEG-4-ES) has typically >a MIME registration. > >That is why Colin and me and others insist that there is no need to >duplicate this type of information in the media stream. Every >system that uses RTP in a standard-compliant way has already >the functionality build in that is necessary to distinguish between >different payload types. > >>One assumption is that huge numbers of devices will be out there that use >>the ES payload format. Assuming that these devices cannot be upgraded to a >>newer payload format! >>Then applications come up with more functionality, using MPEG-4 Systems. >New >>devices will exist that know how to use this functionality. Old devices >>should at least be able to understand the (unmodified!) MPEG-4 Video over >>RTP stream. Since the old devices are not reprogrammable, they cannot be >>upgraded to another payload format. So the old format needs to be by design >>compatible to any new format. > >Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-ES. >Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-ES. >This is how things are done, at least in H.323, all the time. > >Stephan > From rem-conf Tue Sep 12 07:20:41 2000 From rem-conf-request@es.net Tue Sep 12 07:20:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yqum-00032a-00; Tue, 12 Sep 2000 07:20:00 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yqul-00032L-00; Tue, 12 Sep 2000 07:19:59 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA13177; Tue, 12 Sep 2000 16:19:56 +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 xma013159; Tue, 12 Sep 00 16:19: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 QAA00132; Tue, 12 Sep 2000 16:19:55 +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 QAA22612; Tue, 12 Sep 2000 16:19:54 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014029173; Tue, 12 Sep 2000 16:20:59 +0200 To: <ZviL@optibase.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014029173000002L932*@MHS> Date: Tue, 12 Sep 2000 16:20:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 16:18:21" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5505 Lines: 167 Zvi, It is not another payload type; it's the MPEG-4 ES one, but with some o= ther bytes which are not understood by the mobile device but which are allow= ed to be there. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:09 To: ZviL@optibase.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call It will not help, because when you get the new payload in the future th= e old devices don't recognize the payload type and will not handle it. 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 <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionali= ty in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, 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 <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but = I also think that Carsten did make the real point. Let me explain below w= ith an example. A service provides several multicast sessions to mobile devices using t= he simple MPEG-4 ES payload format. This is done during a sport event such= as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch = my own favorite racer on my mobile device. When at home, I watch the broad= cast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favor= ite racer on TV, as an overlay over the broadcast video. For this purpose, = some information is needed that is contained in an SL header. In order to be= bandwidth efficient on the mobile network, the same multicast session i= s used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgrada= ble; these dedicated devices are not capable to even process a single byte t= o upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And t= he essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for = such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan = From rem-conf Tue Sep 12 07:27:32 2000 From rem-conf-request@es.net Tue Sep 12 07:27:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yr17-0004cM-00; Tue, 12 Sep 2000 07:26:33 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yr16-0004c9-00; Tue, 12 Sep 2000 07:26:32 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA16374; Tue, 12 Sep 2000 16:26:20 +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 xma016369; Tue, 12 Sep 00 16:26:25 +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 QAA03902; Tue, 12 Sep 2000 16:26: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 QAA25270; Tue, 12 Sep 2000 16:26:17 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014029423; Tue, 12 Sep 2000 16:27:22 +0200 To: <csp@east.isi.edu> Cc: <HerpelC@thmulti.com>, <stewe@cs.tu-berlin.de>, <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014029423000002L932*@MHS> Date: Tue, 12 Sep 2000 16:27:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 16:24:46" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5389 Lines: 164 Colin, The composition info is sent with the broadcast; with the mobile servic= e only the information needed to allow for the composition is sent. Regards, Jan -----Original Message----- From: csp@east.isi.edu [mailto:csp@east.isi.edu] Sent: dinsdag, 12 september, 2000 16:22 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net; stewe@cs.tu-berlin.de; HerpelC@thmulti.com Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call I don't understand why you don't simply send the composition informatio= n along with the broadcast signal? Sending it with the mobile signal (whe= re it is useless unless the broadcast signal is also received) seems to be= a waste of mobile capacity. Colin --> jan.vandermeer@philips.com writes: >Stephan, Carsten, Colin, Zvi and others, > >It surely is a clash of worlds. And I think we did not come to full >understanding yet. I think I understand the point made by Stephan, but= I >also think that Carsten did make the real point. Let me explain below = with >an example. > >A service provides several multicast sessions to mobile devices using = the >simple MPEG-4 ES payload format. This is done during a sport event suc= h as >the "Tour de France" providing the performance of a number of favorite= >racers. At the same time there is a broadcast coverage of the event, >providing a more global overview. Now, when I am "on the road" I watch= my >own favorite racer on my mobile device. When at home, I watch the broa= dcast >coverage on my TV. This TV has the capability to also receive mobile >services. Over the normal broadcast channel an MPEG-4 application is >delivered that allows me to display the multicast streaming of my favo= rite >racer on TV, as an overlay over the broadcast video. For this purpose,= some >information is needed that is contained in an SL header. In order to b= e >bandwidth efficient on the mobile network, the same multicast session = is >used as for mobile devices. > >Now follows an essential assumption: the mobile devices are not_upgrad= able; >these dedicated devices are not capable to even process a single byte = to >upgrade their functionality. If this assumption is true, they need the= >capability to accept the additional bytes from day one. Otherwise two >separate multicast sessions are needed. > >In my understanding there are no higher level protocols involved. And = the >essential question is whether these mobile devices are indeed not >upgradable. It is my guess that upgradability is not a requirement for= such >devices, but only a feature that cannot be relied upon. > >I hope this clarifies. > >Kind regards, > >Jan > >-----Original Message----- >From: stewe@cs.tu-berlin.de [mailto:stewe@cs.tu-berlin.de] >Sent: maandag, 11 september, 2000 21:05 >To: HerpelC@thmulti.com >Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in respons= e to >the last call > > >Folks > >>What happens here is a clash of worlds. > >Clearly, it is! > >But I don't think that Carsten came to the real point here. > >IMHO, the main point is that MPEG-folk seem to think that >the media stream (RTP/payload/MPEG) should be self-contained >and independent from the higher protocol layers that perform the >capability exchange/announcement (and other things such >as call establishment etc.). >IETF/AVT folk (including me), however, make the implicit >assumption that media cannot be seen independently from >higher protocols. > >The latter, however, is not an assumption -- its the plain truth, >especially after AVT made it the general policy to no more >assign static payload types for media coding. > >This means, that RTP systems rely (and cannot live without) >some external form of capability exchange/announcement, which, >as a minimum, dynamically (per call) associates a freely chosen >number with a certain payload (e.g. MPEG-4 ES or, in the future, >MPEG-4 generic/SL/whatever). The information which payload is >to be transmitted is in H.245, for example, coded in ASN.1. For SIP >systems, the relevant information is transmitted in ASCII form, >where the payload types (such as MPEG-4-ES) has typically >a MIME registration. > >That is why Colin and me and others insist that there is no need to >duplicate this type of information in the media stream. Every >system that uses RTP in a standard-compliant way has already >the functionality build in that is necessary to distinguish between >different payload types. > >>One assumption is that huge numbers of devices will be out there that= use >>the ES payload format. Assuming that these devices cannot be upgraded= to a >>newer payload format! >>Then applications come up with more functionality, using MPEG-4 Syste= ms. >New >>devices will exist that know how to use this functionality. Old devic= es >>should at least be able to understand the (unmodified!) MPEG-4 Video = over >>RTP stream. Since the old devices are not reprogrammable, they cannot= be >>upgraded to another payload format. So the old format needs to be by design >>compatible to any new format. > >Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-= ES. >Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-E= S. >This is how things are done, at least in H.323, all the time. > >Stephan > = From rem-conf Tue Sep 12 07:28:23 2000 From rem-conf-request@es.net Tue Sep 12 07:28:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yr2V-0004op-00; Tue, 12 Sep 2000 07:27:59 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yr2T-0004eg-00; Tue, 12 Sep 2000 07:27:58 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLCY4>; Tue, 12 Sep 2000 17:28:54 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908164@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 17:28:53 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5910 Lines: 166 The ES payload format is not configurable and will never have extra SL header fields, so what is the future functionality of this format you have in mind? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:21 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, It is not another payload type; it's the MPEG-4 ES one, but with some other bytes which are not understood by the mobile device but which are allowed to be there. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:09 To: ZviL@optibase.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call It will not help, because when you get the new payload in the future the old devices don't recognize the payload type and will not handle it. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionality in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but I also think that Carsten did make the real point. Let me explain below with an example. A service provides several multicast sessions to mobile devices using the simple MPEG-4 ES payload format. This is done during a sport event such as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch my own favorite racer on my mobile device. When at home, I watch the broadcast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favorite racer on TV, as an overlay over the broadcast video. For this purpose, some information is needed that is contained in an SL header. In order to be bandwidth efficient on the mobile network, the same multicast session is used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgradable; these dedicated devices are not capable to even process a single byte to upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And the essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan From rem-conf Tue Sep 12 07:44:37 2000 From rem-conf-request@es.net Tue Sep 12 07:44:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YrHl-0006ws-00; Tue, 12 Sep 2000 07:43:45 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YrHj-0006wi-00; Tue, 12 Sep 2000 07:43:44 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA24432; Tue, 12 Sep 2000 16:43:42 +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 xma024430; Tue, 12 Sep 00 16:43:42 +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 QAA13584; Tue, 12 Sep 2000 16:43:41 +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 QAA02383; Tue, 12 Sep 2000 16:43:41 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014030144; Tue, 12 Sep 2000 16:44:45 +0200 To: <ZviL@optibase.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014030144000002L942*@MHS> Date: Tue, 12 Sep 2000 16:44:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 16:42:10" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 7530 Lines: 230 Zvi, I would like to allow for some optional bytes that proceed the ES paylo= ad, e.g. starting with a byte signaling the number of optional bytes. But t= hat would burn at least always one byte signaling no more bytes. Therefore = it would be better to find another signaling method, e.g. two payload type= s of MPEG-4 ES, one with and one without the additional bytes. Does not look= elegant of course and therefore I am still hoping for a better solution= . Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:31 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call The ES payload format is not configurable and will never have extra SL header fields, so what is the future functionality of this format you h= ave in mind? Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:21 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, It is not another payload type; it's the MPEG-4 ES one, but with some o= ther bytes which are not understood by the mobile device but which are allow= ed to be there. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:09 To: ZviL@optibase.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call It will not help, because when you get the new payload in the future th= e old devices don't recognize the payload type and will not handle it. 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 <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionali= ty in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, 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 <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October= 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but = I also think that Carsten did make the real point. Let me explain below w= ith an example. A service provides several multicast sessions to mobile devices using t= he simple MPEG-4 ES payload format. This is done during a sport event such= as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch = my own favorite racer on my mobile device. When at home, I watch the broad= cast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favor= ite racer on TV, as an overlay over the broadcast video. For this purpose, = some information is needed that is contained in an SL header. In order to be= bandwidth efficient on the mobile network, the same multicast session i= s used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgrada= ble; these dedicated devices are not capable to even process a single byte t= o upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And t= he essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for = such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan = From rem-conf Tue Sep 12 08:01:21 2000 From rem-conf-request@es.net Tue Sep 12 08:01:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YrWf-0000DO-00; Tue, 12 Sep 2000 07:59:09 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YrWe-0000C7-00; Tue, 12 Sep 2000 07:59:08 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLC6L>; Tue, 12 Sep 2000 18:00:04 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908166@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 18:00:03 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 8180 Lines: 228 Dear Jan, I think there is a confusion. The ES format has been proceeded as an Internet Draft and there is no more time for comments. I don't think it's possible to make this format extendable, because, first, I'm not sure this is at all possible in IETF. Even if it is, text on extendibility, both syntactically and semantically must be included in the draft, and it is not. So the only thing we can do is proposing that in the Generic format the extra SL header that is contained in the payload will be preceded by a length byte, so it will be readable by systems that don't use MPEG-4 Systems. In any case, the request to have an extra byte in the ES format makes, IMNSHO, no sense. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:45 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I would like to allow for some optional bytes that proceed the ES payload, e.g. starting with a byte signaling the number of optional bytes. But that would burn at least always one byte signaling no more bytes. Therefore it would be better to find another signaling method, e.g. two payload types of MPEG-4 ES, one with and one without the additional bytes. Does not look elegant of course and therefore I am still hoping for a better solution. Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:31 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call The ES payload format is not configurable and will never have extra SL header fields, so what is the future functionality of this format you have in mind? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:21 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, It is not another payload type; it's the MPEG-4 ES one, but with some other bytes which are not understood by the mobile device but which are allowed to be there. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:09 To: ZviL@optibase.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call It will not help, because when you get the new payload in the future the old devices don't recognize the payload type and will not handle it. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionality in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but I also think that Carsten did make the real point. Let me explain below with an example. A service provides several multicast sessions to mobile devices using the simple MPEG-4 ES payload format. This is done during a sport event such as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch my own favorite racer on my mobile device. When at home, I watch the broadcast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favorite racer on TV, as an overlay over the broadcast video. For this purpose, some information is needed that is contained in an SL header. In order to be bandwidth efficient on the mobile network, the same multicast session is used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgradable; these dedicated devices are not capable to even process a single byte to upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And the essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan From rem-conf Tue Sep 12 08:16:02 2000 From rem-conf-request@es.net Tue Sep 12 08:16:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YrlJ-0001V9-00; Tue, 12 Sep 2000 08:14:17 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YrlH-0001Uz-00; Tue, 12 Sep 2000 08:14:16 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA08035; Tue, 12 Sep 2000 17:14:14 +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 xma008033; Tue, 12 Sep 00 17:14:14 +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 RAA29508; Tue, 12 Sep 2000 17:14:14 +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 RAA13608; Tue, 12 Sep 2000 17:14:14 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014031260; Tue, 12 Sep 2000 17:15:18 +0200 To: <ZviL@optibase.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014031260000002L902*@MHS> Date: Tue, 12 Sep 2000 17:15:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 17:12:31" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1994 Lines: 65 Zvi, I don't think there is any confusion. If no such bytes are allowed, the= scenario I gave will not be possible. Which in my view would be a mista= ke. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems,= but not this one Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 17:04 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Dear Jan, I think there is a confusion. The ES format has been proceeded as an Internet Draft and there is no more time for comments. I don't think it= 's possible to make this format extendable, because, first, I'm not sure t= his is at all possible in IETF. Even if it is, text on extendibility, both syntactically and semantically must be included in the draft, and it is= not. So the only thing we can do is proposing that in the Generic format the= extra SL header that is contained in the payload will be preceded by a length byte, so it will be readable by systems that don't use MPEG-4 Systems. In any case, the request to have an extra byte in the ES format makes, IMNSHO, no sense. Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Sep 12 08:27:48 2000 From rem-conf-request@es.net Tue Sep 12 08:27:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yrwu-0002Wd-00; Tue, 12 Sep 2000 08:26:16 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yrwt-0002WC-00; Tue, 12 Sep 2000 08:26:15 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLC89>; Tue, 12 Sep 2000 18:27:11 +0200 Message-ID: <D33D3145480ED4119EEB00062939855190816E@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 18:27:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1223 Lines: 43 The scenario you gave is not possible, for the reasons I previously explained. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:15 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I don't think there is any confusion. If no such bytes are allowed, the scenario I gave will not be possible. Which in my view would be a mistake. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems, but not this one Regards, Jan From rem-conf Tue Sep 12 08:39:22 2000 From rem-conf-request@es.net Tue Sep 12 08:39:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ys8R-0003Te-00; Tue, 12 Sep 2000 08:38:11 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ys8P-0003TU-00; Tue, 12 Sep 2000 08:38:09 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA16076; Tue, 12 Sep 2000 17:38:07 +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 xma016074; Tue, 12 Sep 00 17:38:07 +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 RAA09083; Tue, 12 Sep 2000 17:38:06 +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 RAA20470; Tue, 12 Sep 2000 17:38:05 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014031843; Tue, 12 Sep 2000 17:39:10 +0200 To: <ZviL@optibase.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014031843000002L932*@MHS> Date: Tue, 12 Sep 2000 17:39:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/12/00 17:36:31" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1836 Lines: 68 Which is not a mistake ???? Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 17:33 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call The scenario you gave is not possible, for the reasons I previously explained. Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:15 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I don't think there is any confusion. If no such bytes are allowed, the= scenario I gave will not be possible. Which in my view would be a mista= ke. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems,= but not this one Regards, Jan = From rem-conf Tue Sep 12 08:58:30 2000 From rem-conf-request@es.net Tue Sep 12 08:58:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YsQn-0004ZH-00; Tue, 12 Sep 2000 08:57:09 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YsQm-0004Yz-00; Tue, 12 Sep 2000 08:57:08 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU2VWS4DH2EBV08D@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 08:56:05 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPPT7>; Tue, 12 Sep 2000 08:55:51 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 11:58:45 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, ZviL@optibase.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239A2@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4965 Lines: 121 Zvi, Let me see if I can capture what Jan is proposing as a change to Kikuchi-San's draft. For the same payload type (MPEG4 Video ES), add an adaptation header length followed by the length bytes before MPEG-4 visual stream payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |adaptation length +--length--+ | | | RTP | | | | | MPEG-4 Visual stream (byte aligned) | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) which included meaningful adaptation field data as these receivers will be able to 'parse over' the adaptation and get the ES payload. If they cannot 'parse over' such field, then they will crash. Parsing over such data is not very complex and is easy to implement. If Kikuchi-San's draft can make this change, then it may become fully compatible with what the MPEG AHG may define as 'generic' format. It is always easy to define 'hundred's' of payload types; however service providers want to reach as many receivers as they can and this change will make receivers that implement Kikuchi-San's proposal receive properly generated data in the future that may include adaptation header. If this change cannot be made for some process reason's, then we need to accept the fact that this draft will not be compatible with what MPEG will define for a generic format as there is no place to even carry DTS in this draft. Best Regards Sam Narasimhan Motorola -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 8:15 AM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I don't think there is any confusion. If no such bytes are allowed, the scenario I gave will not be possible. Which in my view would be a mistake. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems, but not this one Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 17:04 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, I think there is a confusion. The ES format has been proceeded as an Internet Draft and there is no more time for comments. I don't think it's possible to make this format extendable, because, first, I'm not sure this is at all possible in IETF. Even if it is, text on extendibility, both syntactically and semantically must be included in the draft, and it is not. So the only thing we can do is proposing that in the Generic format the extra SL header that is contained in the payload will be preceded by a length byte, so it will be readable by systems that don't use MPEG-4 Systems. In any case, the request to have an extra byte in the ES format makes, IMNSHO, no sense. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== From rem-conf Tue Sep 12 09:03:13 2000 From rem-conf-request@es.net Tue Sep 12 09:03:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YsVE-00055G-00; Tue, 12 Sep 2000 09:01:44 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YsVD-0004sb-00; Tue, 12 Sep 2000 09:01:43 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLC07>; Tue, 12 Sep 2000 19:02:39 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908170@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 19:02:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2575 Lines: 87 Mistake is when you can do something and you do it wrong. Here we could not do anything, except asking to reject the Kikuci-san proposal and start another one. Is that what you wanted? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:39 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Which is not a mistake ???? Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 17:33 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call The scenario you gave is not possible, for the reasons I previously explained. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:15 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I don't think there is any confusion. If no such bytes are allowed, the scenario I gave will not be possible. Which in my view would be a mistake. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems, but not this one Regards, Jan From rem-conf Tue Sep 12 09:07:41 2000 From rem-conf-request@es.net Tue Sep 12 09:07:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YsaL-0005yq-00; Tue, 12 Sep 2000 09:07:01 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YsaJ-0005yf-00; Tue, 12 Sep 2000 09:07:00 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id MAA25818; Tue, 12 Sep 2000 12:07:15 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA06181; Tue, 12 Sep 2000 21:06:54 +0500 Message-Id: <200009121606.VAA06181@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, ZviL@optibase.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 11:58:45 EDT." <973597126BDDD11197AA00805FA7EBC9034239A2@ntas0026.gi.com> Date: Tue, 12 Sep 2000 12:06:54 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5530 Lines: 134 Sam, There is no process problem, except that delaying the Kikuchi-san draft will prevent MPEG-4 ES being used with H.323 systems. My main issue is technical: I think that the addition of this extra field is a mistake, and that the correct approach is to use the payload type to indicate that the media data transported is in a different format. I have yet to hear a convincing argument otherwise. Colin --> "Narasimhan, Sam (SD-EX)" writes: >Zvi, > > Let me see if I can capture what Jan is proposing as a change >to Kikuchi-San's draft. For the same payload type (MPEG4 Video ES), >add an adaptation header length followed by the length bytes before >MPEG-4 visual stream payload. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P|X| CC |M| PT | sequence number | RTP > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | timestamp | Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | synchronization source (SSRC) identifier | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | contributing source (CSRC) identifiers | > | .... | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > |adaptation length +--length--+ | > > | | RTP > | | > | | > | MPEG-4 Visual stream (byte aligned) | Payload > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | :...OPTIONAL RTP padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1 - An RTP packet for MPEG-4 Visual stream > > If this draft were to say that receivers should parse over the >adaptation bytes and not process them (as this draft does not >define these), then such receivers will be able to process payload >from future draft (from MPEG) which included meaningful adaptation >field data as these receivers will be able to 'parse over' the >adaptation and get the ES payload. If they cannot 'parse over' >such field, then they will crash. Parsing over such data is not >very complex and is easy to implement. > > If Kikuchi-San's draft can make this change, then it may become >fully compatible with what the MPEG AHG may define as 'generic' >format. It is always easy to define 'hundred's' of payload types; >however service providers want to reach as many receivers as >they can and this change will make receivers that implement Kikuchi-San's >proposal receive properly generated data in the future that may >include adaptation header. > > If this change cannot be made for some process reason's, then we need >to accept the fact that this draft will not be compatible with what MPEG >will >define for a generic format as there is no place to even carry DTS in this >draft. > >Best Regards >Sam Narasimhan >Motorola > >-----Original Message----- >From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] >Sent: Tuesday, September 12, 2000 8:15 AM >To: ZviL@optibase.com >Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response >to the last call > > >Zvi, > >I don't think there is any confusion. If no such bytes are allowed, the >scenario I gave will not be possible. Which in my view would be a mistake. >>From MPEG point of view a serious mistake. > >To allow for extensibility in the "generic format" will solve problems, but >not this one > >Regards, > >Jan > > >-----Original Message----- >From: ZviL@optibase.com [mailto:ZviL@optibase.com] >Sent: dinsdag, 12 september, 2000 17:04 >To: Jan vanderMeer >Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in >response to >the last call > > >Dear Jan, > >I think there is a confusion. The ES format has been proceeded as an >Internet Draft and there is no more time for comments. I don't think it's >possible to make this format extendable, because, first, I'm not sure this >is at all possible in IETF. Even if it is, text on extendibility, both >syntactically and semantically must be included in the draft, and it is not. >So the only thing we can do is proposing that in the Generic format the >extra SL header that is contained in the payload will be preceded by a >length byte, so it will be readable by systems that don't use MPEG-4 >Systems. > >In any case, the request to have an extra byte in the ES format makes, >IMNSHO, no sense. > >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. Mobile: +972(53)461-787 >http://www.optibase.com US voice mail/fax +1(206) 888-4149 >Send SMS from: http://isend.cellcom.co.il/English/Login.htm >================================================================== From rem-conf Tue Sep 12 09:18:05 2000 From rem-conf-request@es.net Tue Sep 12 09:18:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ysja-0007BQ-00; Tue, 12 Sep 2000 09:16:34 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YsjY-00078Z-00; Tue, 12 Sep 2000 09:16:32 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU2WLKQKZ4EBV08D@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 09:15:21 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPPYF>; Tue, 12 Sep 2000 09:15:03 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 12:17:54 -0400 From: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Zvi Lifshitz' <ZviL@optibase.com>, jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC903421643@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 10270 Lines: 270 Dear Zvi, Now, I am confused by your statement. As we discussed in Beijing, the ES format draft being considered by IETF is proposed by individuals and we can not and should not control what they input to IETF. That is IETF's business. What we had agreed to do in Beijing was to come up with WG-11's recommendation and contribution on how to carry ES (as well as SL and other streams types) in RTP and to let IETF know that that contribution is coming (by Oct 2000) and make them aware that WG-11 contribution may or may not align with what is being considered by IETF. As I understand, WG-11 has done that. So, as agreed in Beijing, compatibility with what individual contributions IETF is considering is not a requirement (desired but not required). Therefore, if we think we need additional byte then let us put it in WG-11's contribution to IETF on how to carry ES. The discussion should be on whether we need additional bytes or not, and not whether it is compatible with what was proposed to IETF by some other authors. I know it is a mess and is partly (major part) due to our fault in WG-11 and partly (minor part) due to IETF process. In Beijing, WG-11 had asked people to not to submit individual contributions and/or withdraw their inputs until this matter is fully discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There is nothing we can do about it at this stage. It is water under the bridge. So, let us just discuss whether the additional bytes, as proposed by Jan, make sense or not. In that regard, I think it makes good sense. It gives you lot of flexibility that will be needed in future. We are still reaping the benefits of the flexibility of MPEG-2 systems. I really do not understand the reason for not accepting it. With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 9:00 AM To: jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, I think there is a confusion. The ES format has been proceeded as an Internet Draft and there is no more time for comments. I don't think it's possible to make this format extendable, because, first, I'm not sure this is at all possible in IETF. Even if it is, text on extendibility, both syntactically and semantically must be included in the draft, and it is not. So the only thing we can do is proposing that in the Generic format the extra SL header that is contained in the payload will be preceded by a length byte, so it will be readable by systems that don't use MPEG-4 Systems. In any case, the request to have an extra byte in the ES format makes, IMNSHO, no sense. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:45 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I would like to allow for some optional bytes that proceed the ES payload, e.g. starting with a byte signaling the number of optional bytes. But that would burn at least always one byte signaling no more bytes. Therefore it would be better to find another signaling method, e.g. two payload types of MPEG-4 ES, one with and one without the additional bytes. Does not look elegant of course and therefore I am still hoping for a better solution. Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:31 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call The ES payload format is not configurable and will never have extra SL header fields, so what is the future functionality of this format you have in mind? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 4:21 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, It is not another payload type; it's the MPEG-4 ES one, but with some other bytes which are not understood by the mobile device but which are allowed to be there. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 16:09 To: ZviL@optibase.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call It will not help, because when you get the new payload in the future the old devices don't recognize the payload type and will not handle it. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 3:51 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, I thought I did. What I try to say is: to have this type of functionality in future, you need to allow for inclusion of the additional bytes in the MPEG-2 ES payload now. Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 13:23 To: stewe@cs.tu-berlin.de; HerpelC@thmulti.com; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Jan, You clarified the scenario, but not how it relates to the discussion. Regards, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com <mailto:zvil@csi.com> Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: IBC Amsterdam RAI, Booth # 2.251, September 8th-12, 2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 12:44 PM To: HerpelC@thmulti.com; stewe@cs.tu-berlin.de Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Stephan, Carsten, Colin, Zvi and others, It surely is a clash of worlds. And I think we did not come to full understanding yet. I think I understand the point made by Stephan, but I also think that Carsten did make the real point. Let me explain below with an example. A service provides several multicast sessions to mobile devices using the simple MPEG-4 ES payload format. This is done during a sport event such as the "Tour de France" providing the performance of a number of favorite racers. At the same time there is a broadcast coverage of the event, providing a more global overview. Now, when I am "on the road" I watch my own favorite racer on my mobile device. When at home, I watch the broadcast coverage on my TV. This TV has the capability to also receive mobile services. Over the normal broadcast channel an MPEG-4 application is delivered that allows me to display the multicast streaming of my favorite racer on TV, as an overlay over the broadcast video. For this purpose, some information is needed that is contained in an SL header. In order to be bandwidth efficient on the mobile network, the same multicast session is used as for mobile devices. Now follows an essential assumption: the mobile devices are not_upgradable; these dedicated devices are not capable to even process a single byte to upgrade their functionality. If this assumption is true, they need the capability to accept the additional bytes from day one. Otherwise two separate multicast sessions are needed. In my understanding there are no higher level protocols involved. And the essential question is whether these mobile devices are indeed not upgradable. It is my guess that upgradability is not a requirement for such devices, but only a feature that cannot be relied upon. I hope this clarifies. Kind regards, Jan From rem-conf Tue Sep 12 09:18:07 2000 From rem-conf-request@es.net Tue Sep 12 09:18:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YskG-0007DI-00; Tue, 12 Sep 2000 09:17:16 -0700 Received: from optmail.optibase.co.il [199.203.75.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YskE-00079i-00; Tue, 12 Sep 2000 09:17:15 -0700 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2650.21) id <S48NLDBA>; Tue, 12 Sep 2000 19:18:11 +0200 Message-ID: <D33D3145480ED4119EEB000629398551908172@optmail.optibase.co.il> From: Zvi Lifshitz <ZviL@optibase.com> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 19:18:10 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1100 Lines: 34 [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Tue Sep 12 09:18:08 2000 From rem-conf-request@es.net Tue Sep 12 09:18:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yskn-0007E0-00; Tue, 12 Sep 2000 09:17:49 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yskl-0007Bj-00; Tue, 12 Sep 2000 09:17:47 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU2WN119SGEBV08D@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 09:16:36 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPPY3>; Tue, 12 Sep 2000 09:16:13 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 12:19:05 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Colin Perkins' <csp@east.isi.edu>, "Narasimhan, Sam (SD-EX)" <SNarasimhan@GI.COM> Cc: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, ZviL@optibase.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239A3@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6782 Lines: 169 Colin, If the objective of receivers that implement this draft is to only do one thing and process only one payload type, then there is no change required. Those that are in the CE business want to build receivers that can be fielded in many application areas and will build receivers that will understand different payload types and formats they are carried in. However, content providers will not want to generate 2 separate streams (with 2 payload types) in order to reach 2 different receivers (one that implemented Kikuchi-San's proposal and one that implemented what Jan is proposing). They will probably use the more generic format and reach those receivers that process these adaptation headers. For Example, in US digital cable the receivers span a 5 year deployment window and content providers create a single content that is decodable by ALL these different models. Best Regards Sam Narasimhan -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 9:07 AM To: Narasimhan, Sam (SD-EX) Cc: 'jan.vandermeer@philips.com'; ZviL@optibase.com; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, There is no process problem, except that delaying the Kikuchi-san draft will prevent MPEG-4 ES being used with H.323 systems. My main issue is technical: I think that the addition of this extra field is a mistake, and that the correct approach is to use the payload type to indicate that the media data transported is in a different format. I have yet to hear a convincing argument otherwise. Colin --> "Narasimhan, Sam (SD-EX)" writes: >Zvi, > > Let me see if I can capture what Jan is proposing as a change >to Kikuchi-San's draft. For the same payload type (MPEG4 Video ES), >add an adaptation header length followed by the length bytes before >MPEG-4 visual stream payload. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P|X| CC |M| PT | sequence number | RTP > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | timestamp | Header > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | synchronization source (SSRC) identifier | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | contributing source (CSRC) identifiers | > | .... | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > |adaptation length +--length--+ | > > | | RTP > | | > | | > | MPEG-4 Visual stream (byte aligned) | Payload > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | :...OPTIONAL RTP padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1 - An RTP packet for MPEG-4 Visual stream > > If this draft were to say that receivers should parse over the >adaptation bytes and not process them (as this draft does not >define these), then such receivers will be able to process payload >from future draft (from MPEG) which included meaningful adaptation >field data as these receivers will be able to 'parse over' the >adaptation and get the ES payload. If they cannot 'parse over' >such field, then they will crash. Parsing over such data is not >very complex and is easy to implement. > > If Kikuchi-San's draft can make this change, then it may become >fully compatible with what the MPEG AHG may define as 'generic' >format. It is always easy to define 'hundred's' of payload types; >however service providers want to reach as many receivers as >they can and this change will make receivers that implement Kikuchi-San's >proposal receive properly generated data in the future that may >include adaptation header. > > If this change cannot be made for some process reason's, then we need >to accept the fact that this draft will not be compatible with what MPEG >will >define for a generic format as there is no place to even carry DTS in this >draft. > >Best Regards >Sam Narasimhan >Motorola > >-----Original Message----- >From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] >Sent: Tuesday, September 12, 2000 8:15 AM >To: ZviL@optibase.com >Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response >to the last call > > >Zvi, > >I don't think there is any confusion. If no such bytes are allowed, the >scenario I gave will not be possible. Which in my view would be a mistake. >>From MPEG point of view a serious mistake. > >To allow for extensibility in the "generic format" will solve problems, but >not this one > >Regards, > >Jan > > >-----Original Message----- >From: ZviL@optibase.com [mailto:ZviL@optibase.com] >Sent: dinsdag, 12 september, 2000 17:04 >To: Jan vanderMeer >Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in >response to >the last call > > >Dear Jan, > >I think there is a confusion. The ES format has been proceeded as an >Internet Draft and there is no more time for comments. I don't think it's >possible to make this format extendable, because, first, I'm not sure this >is at all possible in IETF. Even if it is, text on extendibility, both >syntactically and semantically must be included in the draft, and it is not. >So the only thing we can do is proposing that in the Generic format the >extra SL header that is contained in the payload will be preceded by a >length byte, so it will be readable by systems that don't use MPEG-4 >Systems. > >In any case, the request to have an extra byte in the ES format makes, >IMNSHO, no sense. > >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. Mobile: +972(53)461-787 >http://www.optibase.com US voice mail/fax +1(206) 888-4149 >Send SMS from: http://isend.cellcom.co.il/English/Login.htm >================================================================== From rem-conf Tue Sep 12 09:19:32 2000 From rem-conf-request@es.net Tue Sep 12 09:19:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ysm0-0007Xw-00; Tue, 12 Sep 2000 09:19:04 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yslz-0007E2-00; Tue, 12 Sep 2000 09:19:03 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU2WOVODGMEBV08D@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 09:17:58 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPPZC>; Tue, 12 Sep 2000 09:17:43 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 12:20:37 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Zvi Lifshitz' <ZviL@optibase.com>, "Narasimhan, Sam (SD-EX)" <SNarasimhan@GI.COM>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239A4@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1609 Lines: 52 Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Tue Sep 12 09:24:35 2000 From rem-conf-request@es.net Tue Sep 12 09:24:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ysqt-0001nM-00; Tue, 12 Sep 2000 09:24:07 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ysqs-0001mM-00; Tue, 12 Sep 2000 09:24:06 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id MAA26075; Tue, 12 Sep 2000 12:24:23 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA06426; Tue, 12 Sep 2000 21:24:02 +0500 Message-Id: <200009121624.VAA06426@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, ZviL@optibase.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 12:19:05 EDT." <973597126BDDD11197AA00805FA7EBC9034239A3@ntas0026.gi.com> Date: Tue, 12 Sep 2000 12:24:02 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1008 Lines: 25 --> "Narasimhan, Sam (SD-EX)" writes: >Colin, > > If the objective of receivers that implement this draft is to >only do one thing and process only one payload type, then there >is no change required. Those that are in the CE business want >to build receivers that can be fielded in many application >areas and will build receivers that will understand different >payload types and formats they are carried in. However, content >providers will not want to generate 2 separate streams (with 2 >payload types) in order to reach 2 different receivers (one that >implemented Kikuchi-San's proposal and one that implemented >what Jan is proposing). They will probably use the more generic >format and reach those receivers that process these adaptation >headers. > > For Example, in US digital cable the receivers span a 5 year >deployment window and content providers create a single content >that is decodable by ALL these different models. I see nothing in Jan's proposal which makes this easier. Colin From rem-conf Tue Sep 12 09:24:41 2000 From rem-conf-request@es.net Tue Sep 12 09:24:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ysqy-0001oA-00; Tue, 12 Sep 2000 09:24:12 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ysqv-0001nN-00; Tue, 12 Sep 2000 09:24:09 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id MAA26079; Tue, 12 Sep 2000 12:24:26 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA06433; Tue, 12 Sep 2000 21:24:05 +0500 Message-Id: <200009121624.VAA06433@hafez.east.isi.edu> To: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> cc: "'Zvi Lifshitz'" <ZviL@optibase.com>, jan.vandermeer@philips.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 12:17:54 EDT." <973597126BDDD11197AA00805FA7EBC903421643@ntas0026.gi.com> Date: Tue, 12 Sep 2000 12:24:05 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2088 Lines: 38 --> "Luthra, Ajay (SD-EX)" writes: >Dear Zvi, > Now, I am confused by your statement. As we discussed in Beijing, the ES >format draft being considered by IETF is proposed by individuals and we can >not and should not control what they input to IETF. That is IETF's business. >What we had agreed to do in Beijing was to come up with WG-11's >recommendation and contribution on how to carry ES (as well as SL and other >streams types) in RTP and to let IETF know that that contribution is coming >(by Oct 2000) and make them aware that WG-11 contribution may or may not >align with what is being considered by IETF. As I understand, WG-11 has >done that. > > So, as agreed in Beijing, compatibility with what individual contributions >IETF is considering is not a requirement (desired but not required). >Therefore, if we think we need additional byte then let us put it in WG-11's >contribution to IETF on how to carry ES. The discussion should be on whether >we need additional bytes or not, and not whether it is compatible with what >was proposed to IETF by some other authors. I know it is a mess and is >partly (major part) due to our fault in WG-11 and partly (minor part) due to >IETF process. In Beijing, WG-11 had asked people to not to submit individual >contributions and/or withdraw their inputs until this matter is fully >discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There >is nothing we can do about it at this stage. It is water under the bridge. > > So, let us just discuss whether the additional bytes, as proposed by Jan, >make sense or not. In that regard, I think it makes good sense. It gives you >lot of flexibility that will be needed in future. We are still reaping the >benefits of the flexibility of MPEG-2 systems. I really do not understand >the reason for not accepting it. Because we have a mechanism for extensibility in RTP via the payload type. This extra byte provides no advantage - all the examples which have been proposed can be done without using this field - and is incompatible with existing practise. Colin From rem-conf Tue Sep 12 09:38:14 2000 From rem-conf-request@es.net Tue Sep 12 09:38:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yt3W-0004UC-00; Tue, 12 Sep 2000 09:37:10 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yt3V-0004U2-00; Tue, 12 Sep 2000 09:37:09 -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 JAA14127; Tue, 12 Sep 2000 09:27:41 -0700 Message-Id: <3.0.3.32.20000912093000.00b25370@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 12 Sep 2000 09:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina <florissa@bmrc.berkeley.edu> Subject: 9/13 Making Interactive Workspaces Real -- Armando Fox, Computer Science Department, Stanford University Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gumby.cs.berkeley.edu id JAA14127 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2584 Lines: 73 Berkeley Multimedia, Graphics and Interfaces Seminar Making Interactive Workspaces Real Wednesday September 13, 2000,=20 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall)=20 Armando Fox=20 Computer Science Department, Stanford University The Stanford Interactive Workspaces project is developing the computing foundations for bringing reality to ubiquitous computing. A diverse collection of faculty and students from the areas of graphics, human-computer interaction (HCI),networking,ubiquitous computing,and databases, we are looking at new types of human/machine interaction including multimodal input, heterogeneous device integration from wall-sized displays to handheld information appliances, and the "invisibl= e" software infrastructure required to support them. In the same way that today=92s standard operating systems make it feasible to write single-workstation software that uses multiple devices and networked resources,we are constructing a higher level operating system for the wor= ld of ubiquitous computing. We combine research on infrastructure (ways of flexibly configuring and connecting devices, processes,and communication links)with research on HCI (ways of interacting with heterogeneous changi= ng collections of devices with multiple modalities). I will describe our progress on the software infrastructure, including applications running i= n our deployed iRoom that do in fact integrate a variety of devices.=20 --------------- The seminar is broadcast live on the Internet Mbone and as a Real Network= s 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:=20 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 t= he announcement you may be able to receive the session by manually configuri= ng the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center=20 From rem-conf Tue Sep 12 10:22:23 2000 From rem-conf-request@es.net Tue Sep 12 10:22:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ytiy-0006L9-00; Tue, 12 Sep 2000 10:20:00 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ytiw-0006Kx-00; Tue, 12 Sep 2000 10:19:58 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA26939; Tue, 12 Sep 2000 13:20:14 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA06659; Tue, 12 Sep 2000 22:19:53 +0500 Message-Id: <200009121719.WAA06659@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: "'Zvi Lifshitz'" <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 12:20:37 EDT." <973597126BDDD11197AA00805FA7EBC9034239A4@ntas0026.gi.com> Date: Tue, 12 Sep 2000 13:19:53 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 410 Lines: 12 --> "Narasimhan, Sam (SD-EX)" writes: > I am assuming that the payload type from the future draft >could be set to the same value as this draft, if this >draft can accommodate the change. The payload type will have to be negotiated out of band anyway, there will be no more static payload type assignments. Since there must be negotiation having this extra byte in the payload format makes no sense. Colin From rem-conf Tue Sep 12 10:36:29 2000 From rem-conf-request@es.net Tue Sep 12 10:36:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YtxN-0007HP-00; Tue, 12 Sep 2000 10:34:53 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YtxM-0007HF-00; Tue, 12 Sep 2000 10:34:52 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA27141; Tue, 12 Sep 2000 13:35:10 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA06811; Tue, 12 Sep 2000 22:34:49 +0500 Message-Id: <200009121734.WAA06811@hafez.east.isi.edu> To: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> cc: "'Zvi Lifshitz'" <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 13:36:14 EDT." <973597126BDDD11197AA00805FA7EBC903421646@ntas0026.gi.com> Date: Tue, 12 Sep 2000 13:34:49 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 104 Lines: 8 --> "Luthra, Ajay (SD-EX)" writes: >Will it work this way in Multicast environment also? Yes. Colin From rem-conf Tue Sep 12 10:36:29 2000 From rem-conf-request@es.net Tue Sep 12 10:36:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YtxA-0007Gr-00; Tue, 12 Sep 2000 10:34:40 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ytx9-0007Fl-00; Tue, 12 Sep 2000 10:34:39 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU2ZBNLYQ4EBV2SF@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 10:33:37 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPQ24>; Tue, 12 Sep 2000 10:33:21 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 13:36:14 -0400 From: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Colin Perkins' <csp@east.isi.edu> Cc: 'Zvi Lifshitz' <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC903421646@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 809 Lines: 26 Will it work this way in Multicast environment also? Ajay -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 10:20 AM To: Narasimhan, Sam (SD-EX) Cc: 'Zvi Lifshitz'; 'jan.vandermeer@philips.com'; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> "Narasimhan, Sam (SD-EX)" writes: > I am assuming that the payload type from the future draft >could be set to the same value as this draft, if this >draft can accommodate the change. The payload type will have to be negotiated out of band anyway, there will be no more static payload type assignments. Since there must be negotiation having this extra byte in the payload format makes no sense. Colin From rem-conf Tue Sep 12 11:20:22 2000 From rem-conf-request@es.net Tue Sep 12 11:20:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yucc-0001eX-00; Tue, 12 Sep 2000 11:17:30 -0700 Received: from ip-192-185-66-202.diyixian.com (255.255.255.255) [202.66.185.192] by mail1.es.net with smtp (Exim 1.81 #2) id 13Yuca-0001eN-00; Tue, 12 Sep 2000 11:17:29 -0700 From: Suntan - Wilfred <info@suntan.com.hk> To: <rem-conf@es.net> Message-Id: <419.436782.09869606info@suntan.com.hk> Subject: Do you need Capacitors ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 12 Sep 2000 11:17:29 -0700 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1802 Lines: 48 Dear Sir / Madam, Hello, we are a leading firm for manufacting Plastic Film Capacitor in Hong Kong with 500 worker factory in Chinese Mainland - Polyester, Metallized, Polypropylene, Polystyrene. And also handle all kinds of Capacitors-Mica, Mono, Gold, Spark, Starter, Multilayer, Tantalum, Trimmer, Aluminum Electrolytic, Ceramic .. etc. For more details, please visit our homepage at http://www.suntan.com.hk. Moreover, we are happy to inform you that SMD Trimmer Capacitor 3mm TSC03 is now available at Suntan. This capacitor is specially designed for surface mounting use. Features : * Miniature and low profile capacitors * Color-coded case according to its capacitance range for easy visual idenfication. * Mountable by an automatic placer * Reflow soldering applicable * Easy adjustment using a conventinal screwdriver Operating Temperature Range : -25C to +85C Rated Working Voltage : 100VDC Dielectric Withstanding Voltage : 220VDC Rotation Torque : 15 ~ 1000g.m And we also have Dipped type Trimmer Capacitor TSC06 6mm and TSC05 5mm. For more detail, please visit our visit : http://www.suntan.com.hk Should you have any interest products or inquiries, you are welcome to contact us. If you want to discuss with us face to face, you are invited to Hong Kong ElectronicAsia2000 at booth #7N42. See you there!! Best Regards, Mr. Wilfred Ng wilfred@suntan.com.hk Sales & Marketing Manager *********************************************************** Suntan Technology Company Limited Unit A & B, 12/F., Everest Industrial Centre, 396 Kwun Tong Road, Kwun Tong Road, Kowloon, Hong Kong. Tel : (852) 2343 0268 Fax : (852) 2330 9304 Web : http://www.suntan.com.hk E-mail : info@suntan.com.hk *********************************************************** From rem-conf Tue Sep 12 11:52:13 2000 From rem-conf-request@es.net Tue Sep 12 11:52:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yv7r-0002zq-00; Tue, 12 Sep 2000 11:49:47 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yv7p-0002xC-00; Tue, 12 Sep 2000 11:49:45 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <SWVKZRQS>; Tue, 12 Sep 2000 12:48:47 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA7478EA@el-postino.s-vision.com> From: Kris Huber <khuber@sorensonlabs.com> To: Colin Perkins <csp@east.isi.edu> Cc: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, 'Zvi Lifshitz' <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 12:48:46 -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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1009 Lines: 35 Hello Colin, I'm a bit confused. It seems to me that one or more of these assumptions must be wrong: - that multicast involves one-way communication from one sender to many receivers - 'dynamic negotiation' (of payload type in this case) requires two-way communication. Perhaps the precise technical definition of 'negotiate' in this case is what I lack. The definition of the word as generally used seems to require two-way communication (A talks to B, B replies to A, A replies back, etc., until they converge to agreement). Thanks for any clarification, Kris -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 11:35 AM To: Luthra, Ajay (SD-EX) Cc: 'Zvi Lifshitz'; 'jan.vandermeer@philips.com'; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> "Luthra, Ajay (SD-EX)" writes: >Will it work this way in Multicast environment also? Yes. Colin From rem-conf Tue Sep 12 12:13:40 2000 From rem-conf-request@es.net Tue Sep 12 12:13:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YvSl-00047C-00; Tue, 12 Sep 2000 12:11:23 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YvSk-000472-00; Tue, 12 Sep 2000 12:11:22 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA28209; Tue, 12 Sep 2000 15:11:36 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA07416; Wed, 13 Sep 2000 00:11:14 +0500 Message-Id: <200009121911.AAA07416@hafez.east.isi.edu> To: Kris Huber <khuber@sorensonlabs.com> cc: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, "'Zvi Lifshitz'" <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 12:48:46 MDT." <6E031E06378BD311AEF20090273CE1BA7478EA@el-postino.s-vision.com> Date: Tue, 12 Sep 2000 15:11:14 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 848 Lines: 25 --> Kris Huber writes: >Hello Colin, > >I'm a bit confused. It seems to me that one or more of these assumptions >must be wrong: >- that multicast involves one-way communication from one sender to many > receivers >- 'dynamic negotiation' (of payload type in this case) requires two-way > communication. > >Perhaps the precise technical definition of 'negotiate' in this case is what >I lack. The definition of the word as generally used seems to require >two-way communication (A talks to B, B replies to A, A replies back, etc., >until they converge to agreement). > >Thanks for any clarification, In the typical "mbone conference" style of multicast, the sender advertises that a named payload format is using a particular payload type. There's no negotiation (and none needed, since payload type numbers are local to a session). Colin From rem-conf Tue Sep 12 12:36:06 2000 From rem-conf-request@es.net Tue Sep 12 12:36:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YvpT-0005Kd-00; Tue, 12 Sep 2000 12:34:51 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YvpR-0005Ic-00; Tue, 12 Sep 2000 12:34:49 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU33IFK6DQEBV5PO@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 12:33:40 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPQ9W>; Tue, 12 Sep 2000 12:33:20 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 15:36:18 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Colin Perkins' <csp@east.isi.edu>, Kris Huber <khuber@sorensonlabs.com> Cc: "Luthra, Ajay (SD-EX)" <ALuthra@GI.COM>, 'Zvi Lifshitz' <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239A7@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2436 Lines: 65 Colin, In this mode, if the sender wants to reach both the 'generic format receiver' and 'mpeg4-es-03.txt receiver', then he has to use the same payload type. If payload format for the generic format differs from mpeg4-es-03.txt draft, then the sender has to use 2 different payload types, which does not seem to be possible in multicast. If mpeg4-es-03.txt included the header with no processing requirement, then the 'generic format' draft could use the same payload type as this draft. The generic format would define the content of adaptation fields that future receivers that support this will understand. The sender can author content that will play on both the receivers (slightly different from each other) using the same payload type. This is what Jan has been suggesting. This is similar to many 'scalable' modes where same content can play on low end and high end players. Low end players play the base layer and parse over or ignore the enhancement layers while high end players enhance the decoded presentation with the enhancement layers. The adaptation field gives the capability to include such enhancements later without breaking the base layer (at little extra complexity). Best Regards Sam Narasimhan Motorola -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 12:11 PM To: Kris Huber Cc: Luthra, Ajay (SD-EX); 'Zvi Lifshitz'; 'jan.vandermeer@philips.com'; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> Kris Huber writes: >Hello Colin, > >I'm a bit confused. It seems to me that one or more of these assumptions >must be wrong: >- that multicast involves one-way communication from one sender to many > receivers >- 'dynamic negotiation' (of payload type in this case) requires two-way > communication. > >Perhaps the precise technical definition of 'negotiate' in this case is what >I lack. The definition of the word as generally used seems to require >two-way communication (A talks to B, B replies to A, A replies back, etc., >until they converge to agreement). > >Thanks for any clarification, In the typical "mbone conference" style of multicast, the sender advertises that a named payload format is using a particular payload type. There's no negotiation (and none needed, since payload type numbers are local to a session). Colin From rem-conf Tue Sep 12 12:44:08 2000 From rem-conf-request@es.net Tue Sep 12 12:44:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yvxl-00060R-00; Tue, 12 Sep 2000 12:43:25 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yvxj-00060C-00; Tue, 12 Sep 2000 12:43:24 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA28555; Tue, 12 Sep 2000 15:43:40 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA07661; Wed, 13 Sep 2000 00:43:18 +0500 Message-Id: <200009121943.AAA07661@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: Kris Huber <khuber@sorensonlabs.com>, "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, "'Zvi Lifshitz'" <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 15:36:18 EDT." <973597126BDDD11197AA00805FA7EBC9034239A7@ntas0026.gi.com> Date: Tue, 12 Sep 2000 15:43:18 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1315 Lines: 33 Sam, --> "Narasimhan, Sam (SD-EX)" writes: > In this mode, if the sender wants to reach both the >'generic format receiver' and 'mpeg4-es-03.txt receiver', >then he has to use the same payload type. If payload format >for the generic format differs from mpeg4-es-03.txt draft, >then the sender has to use 2 different payload types, which >does not seem to be possible in multicast. Why not? > If mpeg4-es-03.txt included the header with no processing >requirement, then the 'generic format' draft could use the >same payload type as this draft. The generic format would >define the content of adaptation fields that future receivers >that support this will understand. The sender can author >content that will play on both the receivers (slightly >different from each other) using the same payload type. >This is what Jan has been suggesting. This is similar to >many 'scalable' modes where same content can play on >low end and high end players. Low end players play the base >layer and parse over or ignore the enhancement layers while >high end players enhance the decoded presentation with the >enhancement layers. The adaptation field gives the capability >to include such enhancements later without breaking the >base layer (at little extra complexity). How are the enhancements signalled? Colin From rem-conf Tue Sep 12 13:33:45 2000 From rem-conf-request@es.net Tue Sep 12 13:33:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ywi3-0000JA-00; Tue, 12 Sep 2000 13:31:15 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ywi2-0000Io-00; Tue, 12 Sep 2000 13:31:14 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14990 for <rem-conf@es.net>; Tue, 12 Sep 2000 13:31:13 -0700 (PDT) From: Joe Touch <touch@ISI.EDU> Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id NAA29368 for rem-conf@es.net; Tue, 12 Sep 2000 13:31:12 -0700 (PDT) Date: Tue, 12 Sep 2000 13:31:12 -0700 (PDT) Message-Id: <200009122031.NAA29368@rum.isi.edu> To: rem-conf@es.net Subject: Sigcomm 2000 - talks available on multimedia jukebox X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 711 Lines: 23 ACM SIGCOMM 2000 Conference Multicast jukebox announcement http://www.acm.org/sigcomm/sigcomm2000 SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. Multicast jukebox on the Internet There is a multimedia jukebox available at Georgia Institute of Technology, where Sigcomm 2000 (and Sigcomm 99) talks can be selected for multicast. Instructions and further information is available at: http://imj.gatech.edu/ From rem-conf Tue Sep 12 14:01:04 2000 From rem-conf-request@es.net Tue Sep 12 14:01:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yx8J-0001aI-00; Tue, 12 Sep 2000 13:58:23 -0700 Received: from mgw-x1.nokia.com [131.228.20.21] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yx8H-0001a8-00; Tue, 12 Sep 2000 13:58:22 -0700 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8CKvr416796; Tue, 12 Sep 2000 23:57:53 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <SQBJ0NC9>; Tue, 12 Sep 2000 15:54:44 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB021A9994@daeis06nok> From: David.Leon@nokia.com To: SNarasimhan@gi.com, ZviL@optibase.com, jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 15:53: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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 420 Lines: 20 > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > If guess that what you assume is rather that the current and future drafts will have the same NAME and that the future draft will be backward compatible to the current draft. Is that it? Regards, David. From rem-conf Tue Sep 12 14:34:35 2000 From rem-conf-request@es.net Tue Sep 12 14:34:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yxfs-0002r4-00; Tue, 12 Sep 2000 14:33:04 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yxfr-0002qu-00; Tue, 12 Sep 2000 14:33:03 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU37MVFD88EBV90Y@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 14:31:49 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPRXR>; Tue, 12 Sep 2000 14:31:25 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 17:34:18 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: "'David.Leon@nokia.com'" <David.Leon@nokia.com>, SNarasimhan@GI.COM, ZviL@optibase.com, jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239AB@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1064 Lines: 41 David, I am assuming that the 2 drafts will use the same 'payload type' and the header fields before the ES so that the server can send the same RTP packets which can be assembled by either of the receivers. I am not suggesting the same NAME for the drafts. Best Regards Sam Narasimhan Motorola -----Original Message----- From: David.Leon@nokia.com [mailto:David.Leon@nokia.com] Sent: Tuesday, September 12, 2000 1:53 PM To: SNarasimhan@GI.COM; ZviL@optibase.com; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > If guess that what you assume is rather that the current and future drafts will have the same NAME and that the future draft will be backward compatible to the current draft. Is that it? Regards, David. From rem-conf Tue Sep 12 14:38:43 2000 From rem-conf-request@es.net Tue Sep 12 14:38:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yxki-0003Qm-00; Tue, 12 Sep 2000 14:38:04 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yxkg-0003CA-00; Tue, 12 Sep 2000 14:38:03 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU37T6Z4RWEBV90Y@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 14:37:00 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPRYS>; Tue, 12 Sep 2000 14:35:46 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 17:38:41 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Colin Perkins' <csp@east.isi.edu>, "Narasimhan, Sam (SD-EX)" <SNarasimhan@GI.COM> Cc: Kris Huber <khuber@sorensonlabs.com>, "Luthra, Ajay (SD-EX)" <ALuthra@GI.COM>, 'Zvi Lifshitz' <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239AC@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2173 Lines: 62 Colin, See my comments. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 12:43 PM To: Narasimhan, Sam (SD-EX) Cc: Kris Huber; Luthra, Ajay (SD-EX); 'Zvi Lifshitz'; 'jan.vandermeer@philips.com'; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, --> "Narasimhan, Sam (SD-EX)" writes: > In this mode, if the sender wants to reach both the >'generic format receiver' and 'mpeg4-es-03.txt receiver', >then he has to use the same payload type. If payload format >for the generic format differs from mpeg4-es-03.txt draft, >then the sender has to use 2 different payload types, which >does not seem to be possible in multicast. Why not? Sam - If the payload type is different and the payload format is different, then the sender has to send 2 different RTP packets. This can be avoided if the draft included the header fields. > If mpeg4-es-03.txt included the header with no processing >requirement, then the 'generic format' draft could use the >same payload type as this draft. The generic format would >define the content of adaptation fields that future receivers >that support this will understand. The sender can author >content that will play on both the receivers (slightly >different from each other) using the same payload type. >This is what Jan has been suggesting. This is similar to >many 'scalable' modes where same content can play on >low end and high end players. Low end players play the base >layer and parse over or ignore the enhancement layers while >high end players enhance the decoded presentation with the >enhancement layers. The adaptation field gives the capability >to include such enhancements later without breaking the >base layer (at little extra complexity). How are the enhancements signalled? Sam - they do not have to be signaled. The receiver which understands enhancements will parse the information present in the stream. The receiver which does not support enhancement will 'parse over' the enhancement information. Colin From rem-conf Tue Sep 12 14:40:20 2000 From rem-conf-request@es.net Tue Sep 12 14:40:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YxmL-0003gL-00; Tue, 12 Sep 2000 14:39:45 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YxmJ-0003fq-00; Tue, 12 Sep 2000 14:39:44 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA00044; Tue, 12 Sep 2000 17:39:59 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA01088; Wed, 13 Sep 2000 02:39:37 +0500 Message-Id: <200009122139.CAA01088@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: "'David.Leon@nokia.com'" <David.Leon@nokia.com>, ZviL@optibase.com, jan.vandermeer@philips.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 17:34:18 EDT." <973597126BDDD11197AA00805FA7EBC9034239AB@ntas0026.gi.com> Date: Tue, 12 Sep 2000 17:39:37 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1305 Lines: 50 This makes no sense. The payload type is an ephemeral identifier used only during a particular session. It is bound to a fixed name during session setup. Colin --> "Narasimhan, Sam (SD-EX)" writes: >David, > > I am assuming that the 2 drafts will use the same >'payload type' and the header fields before the >ES so that the server can send the same RTP packets >which can be assembled by either of the receivers. >I am not suggesting the same NAME for the drafts. > >Best Regards >Sam Narasimhan >Motorola > >-----Original Message----- >From: David.Leon@nokia.com [mailto:David.Leon@nokia.com] >Sent: Tuesday, September 12, 2000 1:53 PM >To: SNarasimhan@GI.COM; ZviL@optibase.com; jan.vandermeer@philips.com >Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu >Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response >to the last call > > > >> >> Zvi, >> >> I am assuming that the payload type from the future draft >> could be set to the same value as this draft, if this >> draft can accommodate the change. >> >> Regards >> Sam Narasimhan >> Motorola >> > >If guess that what you assume is rather that the current and future drafts >will have the same NAME and that the future draft will be backward >compatible to the current draft. Is that it? > >Regards, David. From rem-conf Tue Sep 12 14:42:53 2000 From rem-conf-request@es.net Tue Sep 12 14:42:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Yxow-0004S2-00; Tue, 12 Sep 2000 14:42:26 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Yxot-0004PR-00; Tue, 12 Sep 2000 14:42:24 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA00080; Tue, 12 Sep 2000 17:42:39 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA01111; Wed, 13 Sep 2000 02:42:18 +0500 Message-Id: <200009122142.CAA01111@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: Kris Huber <khuber@sorensonlabs.com>, "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, "'Zvi Lifshitz'" <ZviL@optibase.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 17:38:41 EDT." <973597126BDDD11197AA00805FA7EBC9034239AC@ntas0026.gi.com> Date: Tue, 12 Sep 2000 17:42:18 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2512 Lines: 70 --> "Narasimhan, Sam (SD-EX)" writes: >Colin, > > See my comments. > >Best Regards >Sam Narasimhan >Motorola > >-----Original Message----- >From: Colin Perkins [mailto:csp@east.isi.edu] >Sent: Tuesday, September 12, 2000 12:43 PM >To: Narasimhan, Sam (SD-EX) >Cc: Kris Huber; Luthra, Ajay (SD-EX); 'Zvi Lifshitz'; >'jan.vandermeer@philips.com'; rem-conf@es.net; >4on2andIP-sys@advent.ee.columbia.edu >Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response >to the last call > > >Sam, > >--> "Narasimhan, Sam (SD-EX)" writes: >> In this mode, if the sender wants to reach both the >>'generic format receiver' and 'mpeg4-es-03.txt receiver', >>then he has to use the same payload type. If payload format >>for the generic format differs from mpeg4-es-03.txt draft, >>then the sender has to use 2 different payload types, which >>does not seem to be possible in multicast. > >Why not? > >Sam - If the payload type is different and the payload format >is different, then the sender has to send 2 different RTP >packets. This can be avoided if the draft included the >header fields. Since they include different information, and since one is not understandable by clients of the other, this would seem to be a good thing! >> If mpeg4-es-03.txt included the header with no processing >>requirement, then the 'generic format' draft could use the >>same payload type as this draft. The generic format would >>define the content of adaptation fields that future receivers >>that support this will understand. The sender can author >>content that will play on both the receivers (slightly >>different from each other) using the same payload type. >>This is what Jan has been suggesting. This is similar to >>many 'scalable' modes where same content can play on >>low end and high end players. Low end players play the base >>layer and parse over or ignore the enhancement layers while >>high end players enhance the decoded presentation with the >>enhancement layers. The adaptation field gives the capability >>to include such enhancements later without breaking the >>base layer (at little extra complexity). > >How are the enhancements signalled? > >Sam - they do not have to be signaled. The receiver which >understands enhancements will parse the information present >in the stream. The receiver which does not support enhancement >will 'parse over' the enhancement information. Of course they have to be signalled - else how do receivers know what sort of enhancement is present? Colin From rem-conf Tue Sep 12 14:48:49 2000 From rem-conf-request@es.net Tue Sep 12 14:48:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YxuD-0005uo-00; Tue, 12 Sep 2000 14:47:53 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YxuC-0005nE-00; Tue, 12 Sep 2000 14:47:52 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU385TZZBYEBV5RS@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 14:46:16 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPR5Y>; Tue, 12 Sep 2000 14:45:57 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 17:48:52 -0400 From: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Zvi Lifshitz' <ZviL@optibase.com>, jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC903421649@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3445 Lines: 107 Yes, if WG-11 does not think Kikuchi-san's proposal meets the needs (I am not saying whether it does or does not - we are currently debating it here). As I understood, conclusion in Beijing was to start WG-11's proposals on how to carry different MPEG-4 streams (ES, SL etc) on RTP. If that aligns with Kikuchi-san's proposal then fine otherwise have "official" proposals from WG-11 according to what its experts collectively think are the best ways to carry MPEG-4 streams. As I mentioned before, alignment with Kikuchi-san's proposal was desired but not required. Ajay -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:03 AM To: jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Mistake is when you can do something and you do it wrong. Here we could not do anything, except asking to reject the Kikuci-san proposal and start another one. Is that what you wanted? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:39 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Which is not a mistake ???? Regards, Jan -----Original Message----- From: ZviL@optibase.com [mailto:ZviL@optibase.com] Sent: dinsdag, 12 september, 2000 17:33 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call The scenario you gave is not possible, for the reasons I previously explained. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Tuesday, September 12, 2000 5:15 PM To: ZviL@optibase.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I don't think there is any confusion. If no such bytes are allowed, the scenario I gave will not be possible. Which in my view would be a mistake. >From MPEG point of view a serious mistake. To allow for extensibility in the "generic format" will solve problems, but not this one Regards, Jan From rem-conf Tue Sep 12 15:31:29 2000 From rem-conf-request@es.net Tue Sep 12 15:31:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YyZG-0007hq-00; Tue, 12 Sep 2000 15:30:18 -0700 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YyZF-0007hg-00; Tue, 12 Sep 2000 15:30:17 -0700 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e8CMU5l18195; Wed, 13 Sep 2000 01:30:05 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <SQBJ03FN>; Tue, 12 Sep 2000 17:26:55 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB021A9995@daeis06nok> From: David.Leon@nokia.com To: SNarasimhan@gi.com, David.Leon@nokia.com, ZviL@optibase.com, jan.vandermeer@philips.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Tue, 12 Sep 2000 17:25:37 -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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 576 Lines: 23 > > > David, > > I am assuming that the 2 drafts will use the same > 'payload type' and the header fields before the > ES so that the server can send the same RTP packets > which can be assembled by either of the receivers. > I am not suggesting the same NAME for the drafts. As it has been said, the payload type is not static. The name is fixed but if you assume that the two formats are using different names, how could a receiver which has implemented the current payload format even know the name of a future (and thus non assigned) payload format? David. From rem-conf Tue Sep 12 16:23:15 2000 From rem-conf-request@es.net Tue Sep 12 16:23:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YzMe-0001Ps-00; Tue, 12 Sep 2000 16:21:20 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13YzMd-0001Pi-00; Tue, 12 Sep 2000 16:21:19 -0700 Received: from BMRC.Berkeley.EDU (opus.cs.berkeley.edu [128.32.131.116]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id QAA16698; Tue, 12 Sep 2000 16:08:15 -0700 Message-ID: <39BEB75F.E9C5DC72@BMRC.Berkeley.EDU> Date: Tue, 12 Sep 2000 16:08:15 -0700 From: "Lawrence A. Rowe" <Rowe@bmrc.berkeley.edu> Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rowe@BMRC.Berkeley.EDU Subject: Distance/Asynchronous Learning Tutorial Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6776 Lines: 135 Hi - I'll be giving an all day tutorial on Distance/Asynchronous Learning as part of the ACM Multimedia 2000 conference in LA on tuesday October 31st. Please pass on the enclosed announcement and details to anyone who you think might be interested in attending either the tutorial or the conference. More details on both is available at http://www.acm.org/sigs/sigmm/MM2000/ You can attend just the tutorial if you are not interested in the general conference. If you're interested in establishing a distance/asynchronous learning program or you want to learn about current technology for webcasting including both room setup and operations, this tutorial might prove interesting. If you have any questions, please contact me. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry ---------------------------------------- Distance/Asynchronous Learning Tutorial Pedagogy, Technology, and Operations Lawrence A. Rowe Berkeley Multiedia Research Center University of California, Berkeley http://bmrc.berkeley.edu/~larry Distance and asynchronous learning are important topics in both industry and academia. Many educators and technologists developing distance learning programs are unfamiliar with previous research and experimental results in pedagogy, technology, and operations related to distributed collaboration and distance learning. Distance learning began over a hundred years ago with correspondence courses. The introduction of television and video conferencing technology created new opportunities for delivering education. More recently, the development of desktop distributed collaboration tools (e.g., CuSeeMe, the H.32x standards, Webx, the Mbone tools, and NetMeeting) and webcasting technology (e.g., Quicktime Streaming, Real Networks G2, and Microsoft Windows Media) that operate over the Internet provides more alternatives for educational delivery. Many universities and companies are using these technologies to deliver remote instruction. Many questions remain about educational effectiveness and costs. This tutorial will present a broad introduction and survey of many topics in distance learning ranging from pedagogy to technology including both studio classroom design and operational issues. The first topic covered will be past results from deploying distance and asynchronous learning technologies. Learn why "sage on the stage" is a discredited approach from a pedagogical perspective and why "tutored video tape" has proven successful in many experiments. In addition, learn about successful synchronous distance learning strategies that work with either television or video conferencing technologies. The second topic covered will be room design and cost. The basic equipment needed to produce video conferences and webcasts will be described and solutions to common problems will be discussed. The development of a well-designed studio classroom with cameras, microphones, multimedia presentation equipment (e.g., projectors, document cameras, VCR's, etc.) is difficult and can be very costly. Different classroom designs will be described and compared. The third topic covered will be the basic technology for distance learning. Different technologies will be described and compared including support for audio/video interaction, whiteboard and multimedia presentations, and other collaboration tools (e.g., chat rooms, media spaces, etc.). Specific examples covered will include H.32x standards, the Internet Mbone tools, and streaming media technologies. Tools for producing live collaborations and for producing rich multimedia material for on-demand replay will be discussed including emerging multimedia standards (e.g., SMIL) and lecture browser technologies. Finally, operational issues of producing distance and asynchronous learning classes will be discussed including program guides, equipment and labor costs, and operational procedures. The tutorial will focus on teaching you what you need to know to develop a distance and asynchronous learning program and what the major research issues that remain to be solved. Date/Location/Registration: The tutorial will be all day tuesday October 31, 2000 at the Marina Beach Marriott in Marina Del Rey in Los Angeles. The tutorial is being held in conjunction with the annual ACM Multimedia Conference. Cost for the tutorial is $500 ($400 for ACM SIGMM/SIGCOMM/SIGGRAPH members). You can attend the tutorial without attending the conference. For more information, including registration see: http://www.acm.org/sigs/sigmm/MM2000/ Background/Prerequisite: Interest in developing a distance or asynchronous learning programming or establishing a research group to explore problems related to distributed collaboration. Instructor Biography: Professor Rowe is a Professor of Electrical Engineering and Computer Science at the University of California at Berkeley. He received a BA in Mathematics and a PhD in Information and Computer Science from the University of California at Irvine in 1970 and 1976, respectively. He is also the founding director of the Berkeley Multimedia Research Center which is an interdisciplinary research group working on applications of multimedia technology to business, education, research, and society. Professor Rowe's current research interests are multimedia applications and databases, video conferencing, hypermedia courseware, and video compression. He heads the research group that produces the regularly scheduled Berkeley Multimedia, Interfaces, and Graphics Seminar http://www.bmrc.berkeley.edu/mig) webcast world-wide on the Internet. Presently, this technology is being used to offer more live and on-demand courses through the Berkeley Internet Broadcasting System (BIBS) - http://www.bmrc.berkeley.edu/bibs. This semester the BIBS system is being used to webcast over 10 classes which produces over 35 hours a week of new video material. Professor Rowe is an ACM Fellow. He has published over ninety papers on multimedia systems and applications, programming systems, and database systems. He is currently Chair of the ACM Special Interest Group on Multimedia. And, he is a member of the editorial board of the ACM Multimedia Systems Journal. He has co-authored papers that have won best paper awards at OOPSLA '91, ACM SIGMOD '96, and ACM Multimedia '98. And, he has organized and chaired several conferences and served on numerous program committees. From rem-conf Tue Sep 12 16:58:55 2000 From rem-conf-request@es.net Tue Sep 12 16:58:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13YzvP-0002o8-00; Tue, 12 Sep 2000 16:57:15 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13YzvO-0002nQ-00; Tue, 12 Sep 2000 16:57:14 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU3CP07460EBV7E9@GI.COM> for rem-conf@es.net; Tue, 12 Sep 2000 16:56:11 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NPSM8>; Tue, 12 Sep 2000 16:55:57 -0400 Content-return: allowed Date: Tue, 12 Sep 2000 19:58:47 -0400 From: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Colin Perkins' <csp@east.isi.edu> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC90342164D@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1713 Lines: 49 Collin, But you said in your previous email, " ... The payload type will have to be negotiated out of band anyway .. ". And in another email you said, "Yes" to the question - does one need to work this way in multicast environment also. And now you are saying it does not need to be negotiated. My understanding of this subject is not yet excellent. So, I do not understand these three emails from you which seem to contradict each other. Does the payload type need to be negotiated or not? With regards, Ajay -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 12:11 PM To: Kris Huber Cc: Luthra, Ajay (SD-EX); 'Zvi Lifshitz'; 'jan.vandermeer@philips.com'; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> Kris Huber writes: >Hello Colin, > >I'm a bit confused. It seems to me that one or more of these assumptions >must be wrong: >- that multicast involves one-way communication from one sender to many > receivers >- 'dynamic negotiation' (of payload type in this case) requires two-way > communication. > >Perhaps the precise technical definition of 'negotiate' in this case is what >I lack. The definition of the word as generally used seems to require >two-way communication (A talks to B, B replies to A, A replies back, etc., >until they converge to agreement). > >Thanks for any clarification, In the typical "mbone conference" style of multicast, the sender advertises that a named payload format is using a particular payload type. There's no negotiation (and none needed, since payload type numbers are local to a session). Colin From rem-conf Tue Sep 12 20:30:51 2000 From rem-conf-request@es.net Tue Sep 12 20:30:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z3CI-00060g-00; Tue, 12 Sep 2000 20:26:54 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z3CG-00060W-00; Tue, 12 Sep 2000 20:26:53 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id FAA19449; Wed, 13 Sep 2000 05:26:51 +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 xma019447; Wed, 13 Sep 00 05:26:51 +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 FAA16783; Wed, 13 Sep 2000 05:26: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 FAA04313; Wed, 13 Sep 2000 05:26:50 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014033793; Wed, 13 Sep 2000 05:27:55 +0200 To: <csp@east.isi.edu> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014033793000002L932*@MHS> Date: Wed, 13 Sep 2000 05:27:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 05:25:19" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4452 Lines: 132 Colin, all, I think it is important to keep in mind that often MPEG uses in-stream signaling. For example, after the length byte, the adaptation field may= start with an identifier that specifies the sort of enhancement. Based = on this approach, the following would be needed : 1) Define an MPEG-4 ES payload format that allows for an adaptation fie= ld without defining the meaning of the adaptation field. 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "ge= neric specification" defines the use of exactly_the_same payload type as defi= ned in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation fi= eld. 3) Next to the payload types for MPEG-4 ES and SL streams, the "generic= specification" may also define payloads for other streams, such as Flex= Mux streams. For these, other payload types will be needed. Now the initial services start using the MPEG-4 ES payload format; thou= gh the adaptation field is not used, this field is allowed to occur. Futur= e services may use exactly the same payload type, but with the adaptation= field as defined by the "generic specification". It may also be important to understand that the presence of the adaptat= ion field is intended to be transparent from RTP point of view and for the session in general. The adaptation field serves MPEG-4 system purposes = which are fully orthogonal to RTP and the streaming session. Kind regards, Jan -----Original Message----- From: csp@east.isi.edu [mailto:csp@east.isi.edu] Sent: dinsdag, 12 september, 2000 23:45 To: SNarasimhan@gi.com Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net; Jan vanderMe= er; ZviL@optibase.com; ALuthra@gi.com; khuber@sorensonlabs.com Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call --> "Narasimhan, Sam (SD-EX)" writes: >Colin, > > See my comments. > >Best Regards >Sam Narasimhan >Motorola > >-----Original Message----- >From: Colin Perkins [mailto:csp@east.isi.edu] >Sent: Tuesday, September 12, 2000 12:43 PM >To: Narasimhan, Sam (SD-EX) >Cc: Kris Huber; Luthra, Ajay (SD-EX); 'Zvi Lifshitz'; >'jan.vandermeer@philips.com'; rem-conf@es.net; >4on2andIP-sys@advent.ee.columbia.edu >Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in respons= e >to the last call > > >Sam, > >--> "Narasimhan, Sam (SD-EX)" writes: >> In this mode, if the sender wants to reach both the >>'generic format receiver' and 'mpeg4-es-03.txt receiver', >>then he has to use the same payload type. If payload format >>for the generic format differs from mpeg4-es-03.txt draft, >>then the sender has to use 2 different payload types, which >>does not seem to be possible in multicast. > >Why not? > >Sam - If the payload type is different and the payload format >is different, then the sender has to send 2 different RTP >packets. This can be avoided if the draft included the >header fields. Since they include different information, and since one is not understandable by clients of the other, this would seem to be a good thing! >> If mpeg4-es-03.txt included the header with no processing >>requirement, then the 'generic format' draft could use the >>same payload type as this draft. The generic format would >>define the content of adaptation fields that future receivers >>that support this will understand. The sender can author >>content that will play on both the receivers (slightly >>different from each other) using the same payload type. >>This is what Jan has been suggesting. This is similar to >>many 'scalable' modes where same content can play on >>low end and high end players. Low end players play the base >>layer and parse over or ignore the enhancement layers while >>high end players enhance the decoded presentation with the >>enhancement layers. The adaptation field gives the capability >>to include such enhancements later without breaking the >>base layer (at little extra complexity). > >How are the enhancements signalled? > >Sam - they do not have to be signaled. The receiver which >understands enhancements will parse the information present >in the stream. The receiver which does not support enhancement >will 'parse over' the enhancement information. Of course they have to be signalled - else how do receivers know what sort of enhancement is present? Colin = From rem-conf Tue Sep 12 21:13:36 2000 From rem-conf-request@es.net Tue Sep 12 21:13:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z3tL-0007Xd-00; Tue, 12 Sep 2000 21:11:23 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z3tK-0007XD-00; Tue, 12 Sep 2000 21:11:22 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-123.dialup.cs.tu-berlin.de [130.149.145.123]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id GAA18251 for <rem-conf@es.net>; Wed, 13 Sep 2000 06:10:56 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000912225736.02bf17c0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Sep 2000 23:07:13 +0200 To: rem-conf@es.net From: Stephan Wenger <stewe@cs.tu-berlin.de> Subject: In band signalling of PT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1112 Lines: 27 Folks, the recent discussion about the MPEG-4 ES payload brought up an issue that, IMHO, may be a shortcoming of current RTP and could easily be fixed. This shortcoming is RTP's need for the out-of-band announcement/negotiation of parameters, including the PT. I wonder whether it may make sense to signal such information in-band as well, e.g. through sender reports or through special media packets. That would allow receivers to "tune" to RTP broadcasts with only IP/Port information (which could, for example, be owned by a TV station). Questions: a) Did I miss something in the current spec? Is this already specified? b) Does such a scenario make sense? Specifically, how do people think to include session announcements in the media packetstream (or in RTCP)? I recall that some time ago there was some discussion about architectural cleanness (it does / doesn't make sense to include session info in the media stream). What is the status of that? c) Would such an enhancement have any impact on the current MPEG discussion? (IMHO not, but I may have missed something) Stephan From rem-conf Tue Sep 12 23:54:46 2000 From rem-conf-request@es.net Tue Sep 12 23:54:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6MU-0002Zh-00; Tue, 12 Sep 2000 23:49:38 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6MS-0002ZX-00; Tue, 12 Sep 2000 23:49:36 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA04771; Wed, 13 Sep 2000 09:49:46 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 09:49:09 +0200 Message-ID: <01C01D67.DD0C9440.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Luthra, Ajay (SD-EX)'" <ALuthra@gi.com>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 09:49:08 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3244 Lines: 78 Dear Ajay, In Paris we came the conclusion that MPEG can support both the ES format proposed by Kikuci-san, and the Generic format (Civanlar et al), since with a proper use of SLConfig the first becomes a subset of the second (at least for video). Therefore we didn't find a reason to delay the process of the ES draft. All seemed pretty nice, until this issue of the extra byte came up and created an awful mess. We can still go forward, if everybody understands that the extension mechanism is dealt by the Generic format, and is not necessary and can serve nothing in the ES draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Tuesday, September 12, 2000 6:18 PM To: 'Zvi Lifshitz'; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, Now, I am confused by your statement. As we discussed in Beijing, the ES format draft being considered by IETF is proposed by individuals and we can not and should not control what they input to IETF. That is IETF's business. What we had agreed to do in Beijing was to come up with WG-11's recommendation and contribution on how to carry ES (as well as SL and other streams types) in RTP and to let IETF know that that contribution is coming (by Oct 2000) and make them aware that WG-11 contribution may or may not align with what is being considered by IETF. As I understand, WG-11 has done that. So, as agreed in Beijing, compatibility with what individual contributions IETF is considering is not a requirement (desired but not required). Therefore, if we think we need additional byte then let us put it in WG-11's contribution to IETF on how to carry ES. The discussion should be on whether we need additional bytes or not, and not whether it is compatible with what was proposed to IETF by some other authors. I know it is a mess and is partly (major part) due to our fault in WG-11 and partly (minor part) due to IETF process. In Beijing, WG-11 had asked people to not to submit individual contributions and/or withdraw their inputs until this matter is fully discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There is nothing we can do about it at this stage. It is water under the bridge. So, let us just discuss whether the additional bytes, as proposed by Jan, make sense or not. In that regard, I think it makes good sense. It gives you lot of flexibility that will be needed in future. We are still reaping the benefits of the flexibility of MPEG-2 systems. I really do not understand the reason for not accepting it. With regards, Ajay From rem-conf Tue Sep 12 23:54:46 2000 From rem-conf-request@es.net Tue Sep 12 23:54:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6OZ-0002eR-00; Tue, 12 Sep 2000 23:51:47 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6OW-0002eE-00; Tue, 12 Sep 2000 23:51:45 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA05143; Wed, 13 Sep 2000 09:52:16 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 09:51:39 +0200 Message-ID: <01C01D68.363AC780.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 09:51:37 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2641 Lines: 81 Sam, It seems you want the current draft to be modified in the future. Then: 1. I don't believe this is possible. 2. I don't think this is necessary. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 6:21 PM To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Tue Sep 12 23:57:19 2000 From rem-conf-request@es.net Tue Sep 12 23:57:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6TM-00031x-00; Tue, 12 Sep 2000 23:56:44 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6TG-00030G-00; Tue, 12 Sep 2000 23:56:42 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA05983; Wed, 13 Sep 2000 09:56:55 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 09:56:17 +0200 Message-ID: <01C01D68.DC791160.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Colin Perkins'" <csp@east.isi.edu>, "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> Cc: "jan.vandermeer@philips.com" <jan.vandermeer@philips.com>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 09:56:16 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3065 Lines: 62 I don't think Colin needs my support, but I will nevertheless give it out of frustration. This is a simple truth. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Colin Perkins [SMTP:csp@east.isi.edu] Sent: Tuesday, September 12, 2000 6:24 PM To: Luthra, Ajay (SD-EX) Cc: 'Zvi Lifshitz'; jan.vandermeer@philips.com; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> "Luthra, Ajay (SD-EX)" writes: >Dear Zvi, > Now, I am confused by your statement. As we discussed in Beijing, the ES >format draft being considered by IETF is proposed by individuals and we can >not and should not control what they input to IETF. That is IETF's business. >What we had agreed to do in Beijing was to come up with WG-11's >recommendation and contribution on how to carry ES (as well as SL and other >streams types) in RTP and to let IETF know that that contribution is coming >(by Oct 2000) and make them aware that WG-11 contribution may or may not >align with what is being considered by IETF. As I understand, WG-11 has >done that. > > So, as agreed in Beijing, compatibility with what individual contributions >IETF is considering is not a requirement (desired but not required). >Therefore, if we think we need additional byte then let us put it in WG-11's >contribution to IETF on how to carry ES. The discussion should be on whether >we need additional bytes or not, and not whether it is compatible with what >was proposed to IETF by some other authors. I know it is a mess and is >partly (major part) due to our fault in WG-11 and partly (minor part) due to >IETF process. In Beijing, WG-11 had asked people to not to submit individual >contributions and/or withdraw their inputs until this matter is fully >discussed in WG-11. The decision to freeze or withdraw is not WG-11's. There >is nothing we can do about it at this stage. It is water under the bridge. > > So, let us just discuss whether the additional bytes, as proposed by Jan, >make sense or not. In that regard, I think it makes good sense. It gives you >lot of flexibility that will be needed in future. We are still reaping the >benefits of the flexibility of MPEG-2 systems. I really do not understand >the reason for not accepting it. Because we have a mechanism for extensibility in RTP via the payload type. This extra byte provides no advantage - all the examples which have been proposed can be done without using this field - and is incompatible with existing practise. Colin From rem-conf Tue Sep 12 23:59:14 2000 From rem-conf-request@es.net Tue Sep 12 23:59:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6VL-0003Xr-00; Tue, 12 Sep 2000 23:58:47 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6VJ-0003Vw-00; Tue, 12 Sep 2000 23:58:46 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA06249; Wed, 13 Sep 2000 09:58:36 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 09:57:58 +0200 Message-ID: <01C01D69.186333E0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Colin Perkins'" <csp@east.isi.edu>, "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Cc: Kris Huber <khuber@sorensonlabs.com>, "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 09:57:57 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 602 Lines: 23 [Colin Perkins:] How are the enhancements signalled? [Reply:] How indeed? z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Wed Sep 13 00:01:33 2000 From rem-conf-request@es.net Wed Sep 13 00:01:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6WF-0003rV-00; Tue, 12 Sep 2000 23:59:43 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6WD-0003p6-00; Tue, 12 Sep 2000 23:59:41 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA06396; Wed, 13 Sep 2000 09:59:35 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 09:58:59 +0200 Message-ID: <01C01D69.3C869B40.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'David.Leon@nokia.com'" <David.Leon@nokia.com>, "SNarasimhan@gi.com" <SNarasimhan@gi.com>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 09:58:57 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1364 Lines: 43 If it has the same name then it is the same format. See my previous comment. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: David.Leon@nokia.com [SMTP:David.Leon@nokia.com] Sent: Tuesday, September 12, 2000 10:53 PM To: SNarasimhan@gi.com; ZviL@optibase.com; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > If guess that what you assume is rather that the current and future drafts will have the same NAME and that the future draft will be backward compatible to the current draft. Is that it? Regards, David. From rem-conf Wed Sep 13 00:24:34 2000 From rem-conf-request@es.net Wed Sep 13 00:24:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6tR-00072R-00; Wed, 13 Sep 2000 00:23:41 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6tP-000725-00; Wed, 13 Sep 2000 00:23:39 -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 <0G0T001E6DT1ZV@ss3000e.cselt.it> for rem-conf@es.net; Wed, 13 Sep 2000 09:22:14 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <R0JLHN15>; Wed, 13 Sep 2000 09:24:27 +0200 Content-return: allowed Date: Wed, 13 Sep 2000 09:22:17 +0200 From: Franceschini Guido <Guido.Franceschini@CSELT.IT> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, 'zvi' <zvil@csi.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <85077463E51D6A498C453073E1677940034EBF@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5585 Lines: 149 Hi all, my own considerations on this thread In RTP and IETF procedure terms, I understand this thread on the extra byte as: 1) modify the current ES draft to accomodate a payload header starting with a byte indicating its length. No specification of what the payload header carries 2) allow the modified ES draft to enter the RFC standard track and be widely implemented 3) propose a new draft for 'generic' ES or SL mapping, which is identical to the modified ES draft but also defines what the payload header carries 4) the 'generic' draft becomes standard and _obsoletes_ the ES draft. Devices implementing the ES draft will skip the payload header information but still understand the media content. Well, I think we have a technical problem here, which has nothing to do with usual practices / procedures / timelines. The problem that I see is that: - the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video - the 'generic' draft will define 1 Payload Format only, and the type of media (Audio, Video, BIFS ...) being carried will be specified using MPEG-4 Object Descriptors. What we achieved at the Paris meeting (before discussing this extra byte feature) has been to allow MPEG-4 Systems terminals implementing the 'generic' draft to use the ES draft as well withouth any need to duplicate implementations (i.e.: the ES draft is a subset of the generic draft in the Data Plane). Now, the 'extra byte' proposal would allow devices implementing the ES draft to be compatible in the Data Plane with the 'generic' format, too. Compatibility in the Control Plane (i.e. Payload Type negotiation/announcement) was not considered in Paris. I believe that devices implementing the 'generic' draft would have no difficulties in understanding 1 more SDP keyword or MIME type as introduced by the ES draft. But the reverse is more difficult and tricky. As I outlined above, the 'generic' draft would not specify by itself the type of media content it is carrying, and would rely on the Object Descriptor to do that. If the goal is to allow devices implementing the ES draft to be compatible with future content delivered by means of the 'generic' draft, than we need to specify NOW how to duplicate the information in the OD so that the media type is made explicit for those devices. And then we will have to accept that devices implementing MPEG-4 Systems get the indication of the media type twice :-( Did I make the point clear ? Guido > ---------- > From: Zvi Lifshitz[SMTP:zvil@csi.com] > Sent: Wednesday, September 13, 2000 9:51 AM > To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > Sam, > > It seems you want the current draft to be modified in the future. Then: > > 1. I don't believe this is possible. > 2. I don't think this is necessary. > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > ================================================================== > > Come see us at: > Streaming Media Europe Earls Court Centre, Booth # 628, London, October > 10th-12th, 2000 > > > -----Original Message----- > From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] > Sent: Tuesday, September 12, 2000 6:21 PM > To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); > 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > > -----Original Message----- > From: Zvi Lifshitz [mailto:ZviL@optibase.com] > Sent: Tuesday, September 12, 2000 10:18 AM > To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response > to the last call > > > [Narasimhan, Sam (SD-EX):] > > If this draft were to say that receivers should parse over the > adaptation bytes and not process them (as this draft does not > define these), then such receivers will be able to process payload > from future draft (from MPEG) > > [Reply:] > > They will not, because they don't know the payload type of the future > draft > therefore they will not know they can process payloads from the future > draft > even though they can. > > If they know, they also know that the future draft has extra header info. > So > work on the future draft, not on the current draft. > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > ================================================================== > > Come see us at: > Streaming Media Europe Earls Court Centre, Booth # 628, London, October > 10th-12th, 2000 > From rem-conf Wed Sep 13 00:30:23 2000 From rem-conf-request@es.net Wed Sep 13 00:30:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z6xj-0007Lu-00; Wed, 13 Sep 2000 00:28:07 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z6xh-0007Lf-00; Wed, 13 Sep 2000 00:28:05 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA11389; Wed, 13 Sep 2000 10:28:23 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:27:45 +0200 Message-ID: <01C01D6D.419E2D60.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'David.Leon@nokia.com'" <David.Leon@nokia.com>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 10:27:44 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1241 Lines: 36 So how would old devices recognize the new name? z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 11:34 PM To: 'David.Leon@nokia.com'; SNarasimhan@gi.com; ZviL@optibase.com; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call David, I am assuming that the 2 drafts will use the same 'payload type' and the header fields before the ES so that the server can send the same RTP packets which can be assembled by either of the receivers. I am not suggesting the same NAME for the drafts. Best Regards Sam Narasimhan Motorola From rem-conf Wed Sep 13 00:32:24 2000 From rem-conf-request@es.net Wed Sep 13 00:32:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z709-0007Xc-00; Wed, 13 Sep 2000 00:30:37 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z701-0007VG-00; Wed, 13 Sep 2000 00:30:36 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA11989; Wed, 13 Sep 2000 10:30:40 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:30:03 +0200 Message-ID: <01C01D6D.93B187A0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'Colin Perkins'" <csp@east.isi.edu> Cc: Kris Huber <khuber@sorensonlabs.com>, "Luthra, Ajay (SD-EX)" <ALuthra@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 10:30:02 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 185 Lines: 14 [Narasimhan, Sam (SD-EX):] The receiver which understands enhancements will parse the information present in the stream. [Reply:] How will it know that there are enhancements? z From rem-conf Wed Sep 13 00:32:37 2000 From rem-conf-request@es.net Wed Sep 13 00:32:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z71k-00000X-00; Wed, 13 Sep 2000 00:32:16 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z71h-00000I-00; Wed, 13 Sep 2000 00:32:14 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA12291; Wed, 13 Sep 2000 10:32:13 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:31:36 +0200 Message-ID: <01C01D6D.CB510820.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Luthra, Ajay (SD-EX)'" <ALuthra@gi.com>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 10:31:35 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1443 Lines: 35 See my previous reply to you. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Tuesday, September 12, 2000 11:49 PM To: 'Zvi Lifshitz'; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Yes, if WG-11 does not think Kikuchi-san's proposal meets the needs (I am not saying whether it does or does not - we are currently debating it here). As I understood, conclusion in Beijing was to start WG-11's proposals on how to carry different MPEG-4 streams (ES, SL etc) on RTP. If that aligns with Kikuchi-san's proposal then fine otherwise have "official" proposals from WG-11 according to what its experts collectively think are the best ways to carry MPEG-4 streams. As I mentioned before, alignment with Kikuchi-san's proposal was desired but not required. Ajay From rem-conf Wed Sep 13 00:33:36 2000 From rem-conf-request@es.net Wed Sep 13 00:33:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z72c-0000Ei-00; Wed, 13 Sep 2000 00:33:10 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z72a-0000DC-00; Wed, 13 Sep 2000 00:33:08 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA12519; Wed, 13 Sep 2000 10:33:20 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:32:43 +0200 Message-ID: <01C01D6D.F2F5A700.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'David.Leon@nokia.com'" <David.Leon@nokia.com>, "SNarasimhan@gi.com" <SNarasimhan@gi.com>, "jan.vandermeer@philips.com" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 10:32:41 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 955 Lines: 37 ;-) z -----Original Message----- From: David.Leon@nokia.com [SMTP:David.Leon@nokia.com] Sent: Wednesday, September 13, 2000 12:26 AM To: SNarasimhan@gi.com; David.Leon@nokia.com; ZviL@optibase.com; jan.vandermeer@philips.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call > > > David, > > I am assuming that the 2 drafts will use the same > 'payload type' and the header fields before the > ES so that the server can send the same RTP packets > which can be assembled by either of the receivers. > I am not suggesting the same NAME for the drafts. As it has been said, the payload type is not static. The name is fixed but if you assume that the two formats are using different names, how could a receiver which has implemented the current payload format even know the name of a future (and thus non assigned) payload format? David. From rem-conf Wed Sep 13 00:37:16 2000 From rem-conf-request@es.net Wed Sep 13 00:37:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z75G-0001N8-00; Wed, 13 Sep 2000 00:35:54 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z758-0001IL-00; Wed, 13 Sep 2000 00:35:46 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA12985; Wed, 13 Sep 2000 10:36:13 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:35:36 +0200 Message-ID: <01C01D6E.5A1E09E0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 10:35:34 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2515 Lines: 60 Jan, Your nice proposal can be incorporated in the Generic format. I hope we managed to explain why it is useless with the ES format. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 5:28 AM To: csp@east.isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Colin, all, I think it is important to keep in mind that often MPEG uses in-stream signaling. For example, after the length byte, the adaptation field may start with an identifier that specifies the sort of enhancement. Based on this approach, the following would be needed : 1) Define an MPEG-4 ES payload format that allows for an adaptation field without defining the meaning of the adaptation field. 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic specification" defines the use of exactly_the_same payload type as defined in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation field. 3) Next to the payload types for MPEG-4 ES and SL streams, the "generic specification" may also define payloads for other streams, such as FlexMux streams. For these, other payload types will be needed. Now the initial services start using the MPEG-4 ES payload format; though the adaptation field is not used, this field is allowed to occur. Future services may use exactly the same payload type, but with the adaptation field as defined by the "generic specification". It may also be important to understand that the presence of the adaptation field is intended to be transparent from RTP point of view and for the session in general. The adaptation field serves MPEG-4 system purposes which are fully orthogonal to RTP and the streaming session. Kind regards, Jan From rem-conf Wed Sep 13 00:43:38 2000 From rem-conf-request@es.net Wed Sep 13 00:43:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z7CC-000451-00; Wed, 13 Sep 2000 00:43:04 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z7C9-000444-00; Wed, 13 Sep 2000 00:43:01 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA14260; Wed, 13 Sep 2000 10:43:13 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 10:42:35 +0200 Message-ID: <01C01D6F.54134BE0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Franceschini Guido'" <Guido.Franceschini@CSELT.IT>, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 10:42:34 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6717 Lines: 188 Hi Guido, You didn't make the point clearer, just showed how messy we got with this idea of extending the ES format. Therefore I propose to kill this discussion about modifications to the ES format, and concentrating how to improve the Generic format, if necessary. Ciao, z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Franceschini Guido [SMTP:Guido.Franceschini@CSELT.IT] Sent: Wednesday, September 13, 2000 9:22 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com'; 'zvi' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Hi all, my own considerations on this thread In RTP and IETF procedure terms, I understand this thread on the extra byte as: 1) modify the current ES draft to accomodate a payload header starting with a byte indicating its length. No specification of what the payload header carries 2) allow the modified ES draft to enter the RFC standard track and be widely implemented 3) propose a new draft for 'generic' ES or SL mapping, which is identical to the modified ES draft but also defines what the payload header carries 4) the 'generic' draft becomes standard and _obsoletes_ the ES draft. Devices implementing the ES draft will skip the payload header information but still understand the media content. Well, I think we have a technical problem here, which has nothing to do with usual practices / procedures / timelines. The problem that I see is that: - the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video - the 'generic' draft will define 1 Payload Format only, and the type of media (Audio, Video, BIFS ...) being carried will be specified using MPEG-4 Object Descriptors. What we achieved at the Paris meeting (before discussing this extra byte feature) has been to allow MPEG-4 Systems terminals implementing the 'generic' draft to use the ES draft as well withouth any need to duplicate implementations (i.e.: the ES draft is a subset of the generic draft in the Data Plane). Now, the 'extra byte' proposal would allow devices implementing the ES draft to be compatible in the Data Plane with the 'generic' format, too. Compatibility in the Control Plane (i.e. Payload Type negotiation/announcement) was not considered in Paris. I believe that devices implementing the 'generic' draft would have no difficulties in understanding 1 more SDP keyword or MIME type as introduced by the ES draft. But the reverse is more difficult and tricky. As I outlined above, the 'generic' draft would not specify by itself the type of media content it is carrying, and would rely on the Object Descriptor to do that. If the goal is to allow devices implementing the ES draft to be compatible with future content delivered by means of the 'generic' draft, than we need to specify NOW how to duplicate the information in the OD so that the media type is made explicit for those devices. And then we will have to accept that devices implementing MPEG-4 Systems get the indication of the media type twice :-( Did I make the point clear ? Guido > ---------- > From: Zvi Lifshitz[SMTP:zvil@csi.com] > Sent: Wednesday, September 13, 2000 9:51 AM > To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > Sam, > > It seems you want the current draft to be modified in the future. Then: > > 1. I don't believe this is possible. > 2. I don't think this is necessary. > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > ================================================================== > > Come see us at: > Streaming Media Europe Earls Court Centre, Booth # 628, London, October > 10th-12th, 2000 > > > -----Original Message----- > From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] > Sent: Tuesday, September 12, 2000 6:21 PM > To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); > 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > > -----Original Message----- > From: Zvi Lifshitz [mailto:ZviL@optibase.com] > Sent: Tuesday, September 12, 2000 10:18 AM > To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response > to the last call > > > [Narasimhan, Sam (SD-EX):] > > If this draft were to say that receivers should parse over the > adaptation bytes and not process them (as this draft does not > define these), then such receivers will be able to process payload > from future draft (from MPEG) > > [Reply:] > > They will not, because they don't know the payload type of the future > draft > therefore they will not know they can process payloads from the future > draft > even though they can. > > If they know, they also know that the future draft has extra header info. > So > work on the future draft, not on the current draft. > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > ================================================================== > > Come see us at: > Streaming Media Europe Earls Court Centre, Booth # 628, London, October > 10th-12th, 2000 > From rem-conf Wed Sep 13 02:57:28 2000 From rem-conf-request@es.net Wed Sep 13 02:57:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Z9Cq-0007EO-00; Wed, 13 Sep 2000 02:51:52 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Z9Co-0007EE-00; Wed, 13 Sep 2000 02:51:50 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA25637; Wed, 13 Sep 2000 11:51:48 +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 xma025634; Wed, 13 Sep 00 11:51: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 LAA18329; Wed, 13 Sep 2000 11:51:48 +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 LAA24832; Wed, 13 Sep 2000 11:51:46 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900011739200; Wed, 13 Sep 2000 11:58:37 +0200 To: <stewe@cs.tu-berlin.de> Cc: <rem-conf@es.net> Subject: Re: In band signalling of PT Message-ID: <0056900011739200000002L002*@MHS> Date: Wed, 13 Sep 2000 11:58:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 11:57:02" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1978 Lines: 77 stewe@cs.tu-berlin.de wrote: > Folks, > > the recent discussion about the MPEG-4 ES payload brought up an > issue that, IMHO, may be a shortcoming of current RTP and could > easily be fixed. This shortcoming is RTP's need for the out-of-band > announcement/negotiation of parameters, including the PT. > > I wonder whether it may make sense to signal such information in-band= > as well, e.g. through sender reports or through special media packets= . > That would allow receivers to "tune" to RTP broadcasts with only > IP/Port information (which could, for example, be owned by a TV stati= on). > > Questions: > > a) Did I miss something in the current spec? Is this already specifi= ed? you can do that out of band using SAP with the config info in the SAP packets > > b) Does such a scenario make sense? Oh YES ! > Specifically, how do people think > to include session announcements in the media packetstream (or in > RTCP)? I recall that some time ago there was some discussion > about architectural cleanness (it does / doesn't make sense to inc= lude > session info in the media stream). What is the status of that? I think config info in the media stream is not a very good idea, design-wise, but it can be made to work, of course > > c) Would such an enhancement have any impact on the current MPEG > discussion? (IMHO not, but I may have missed something) > if I recap the MPEG-4 discussion the problem is that the data stream sy= ntax can (video) or cannot (audio, other system stuff, ODs, BIFS) include c= onfig info, therefore we have an homogeneity problem for system/transport layers th= at should be media unaware > > Stephan -- 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 Wed Sep 13 04:09:38 2000 From rem-conf-request@es.net Wed Sep 13 04:09:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZAMZ-0001Am-00; Wed, 13 Sep 2000 04:05:59 -0700 Received: from dmzraw2.thmulti.com [141.11.234.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZAMX-0001AF-00; Wed, 13 Sep 2000 04:05:57 -0700 Received: from smtprelay.thmulti.com ([141.11.194.9]) by dmzraw2.thmulti.com (8.9.3/8.9.1) with ESMTP id NAA05608; Wed, 13 Sep 2000 13:04:23 +0200 (MET DST) Received: from parexch3.paris.thmulti.com (localhost [127.0.0.1]) by smtprelay.thmulti.com (8.9.3/8.9.1) with SMTP id MAA14985; Wed, 13 Sep 2000 12:02:59 +0200 (MET DST) Received: from 141.11.194.5 by parexch3.paris.thmulti.com (InterScan E-Mail VirusWall NT); Wed, 13 Sep 2000 12:00:29 +0200 (Romance Daylight Time) Received: by parexch3.thmulti.com with Internet Mail Service (5.5.2448.0) id <R88G25G4>; Wed, 13 Sep 2000 12:00:28 +0200 Message-ID: <2CEEE9E85750D2119F4000805F3172884C2CB6@hanexch1.hanover.thmulti.com> From: Herpel Carsten <HerpelC@thmulti.com> To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 12:02:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 865 Lines: 25 [Zvi] Therefore I propose to kill this discussion about modifications to the ES format, and concentrating how to improve the Generic format, if necessary. [Carsten] Amen! (But I do think Guido made a good summary of the problem, though ;-) May I mention again that for the Audio portion of the ES payload format the extra byte does not buy anything anyway, since here we have the situation that the ES format uses LATM while the generic one as it stands today does not. We said in Paris that we want to correct MPEG-4 Systems in order to allow multiple AUs per SL. But I don't recall we said that we want to put LATM inside SL packets. So incompatibility between payload formats is guaranteed, no matter whether we have the Jan-byte ;-) or not. (Disclaimer: This observation is meant to trigger discussion about the _generic_ format ;-) Regards, Carsten From rem-conf Wed Sep 13 08:38:25 2000 From rem-conf-request@es.net Wed Sep 13 08:38:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZEXN-0005uv-00; Wed, 13 Sep 2000 08:33:25 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZEXI-0005ul-00; Wed, 13 Sep 2000 08:33:21 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id SAA32533; Wed, 13 Sep 2000 18:32:41 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 18:32:52 +0200 Message-ID: <01C01DB1.06AD2000.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 18:32:51 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6032 Lines: 159 Sam, what you want either will not work or is not necessary. I'm sorry we didn't manage to convince you. I've run out of words... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Wednesday, September 13, 2000 5:28 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, 1. I thought all the comments were to make changes to Kikuchi-San's draft NOW - not later. If it just added the adaptation length followed by length bytes before the ES payload (in the RTP payload), then content authors could author content that can play on receivers that implemented Kikuchi-San's draft as well as the proposal that will come out of MPEG. I am assuming that the MPEG proposal will use this adaptation bytes to signal type of content. If so, this will make Kikuchi-San's draft a sub-set of what MPEG will propose (preferable was the term you used). The only way this can happen is if Kikuchi-San's draft can be modified NOW. 2. If Kikuchi-San's draft can be modified, it does NOT have to specify the content of adaptation header payload. MPEG will do it. What all it has to say is use the 'adaptation length' field to offset where you pick up the ES payload. 3. In MPEG-2, the byte that follows the adaptation length signals what is in the rest of the adaptation header such as PCR, OPCR, splicing etc. Those that cannot process the adaptation header just use the adaptation length to offset to the next payload start (such as PES header or ES). This is what I am assuming MPEG will do for 'generic' mapping. The byte after adaptation header may signal presence of DTS, SL header, flexmux header, scalable data, buffer etc. 4. If Kikuchi-San's draft progresses 'as is' and MPEG uses the adaptation header, then content authors that used the MPEG coding can only play it on receivers that implemented the re-assembly of MPEG 'generic' mapping and not on those that 'ONLY' implemented Kikuchi-San's draft (if it was not modified). CE vendors can choose to implement receivers that can support multiple payload formats. However, if Kikuchi-San's draft can be modified NOW, we may see a single payload format for MPEG-4 and I believe that is a plus and thus NECESSARY. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 12:52 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, It seems you want the current draft to be modified in the future. Then: 1. I don't believe this is possible. 2. I don't think this is necessary. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 6:21 PM To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Wed Sep 13 08:38:25 2000 From rem-conf-request@es.net Wed Sep 13 08:38:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZEQz-0005op-00; Wed, 13 Sep 2000 08:26:49 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZEQy-0005oW-00; Wed, 13 Sep 2000 08:26:48 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU495HADMMEBVIFS@GI.COM> for rem-conf@es.net; Wed, 13 Sep 2000 08:25:45 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NP4GB>; Wed, 13 Sep 2000 08:25:29 -0400 Content-return: allowed Date: Wed, 13 Sep 2000 11:28:26 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Zvi Lifshitz' <zvil@csi.com>, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@GI.COM>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239AE@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5016 Lines: 134 Zvi, 1. I thought all the comments were to make changes to Kikuchi-San's draft NOW - not later. If it just added the adaptation length followed by length bytes before the ES payload (in the RTP payload), then content authors could author content that can play on receivers that implemented Kikuchi-San's draft as well as the proposal that will come out of MPEG. I am assuming that the MPEG proposal will use this adaptation bytes to signal type of content. If so, this will make Kikuchi-San's draft a sub-set of what MPEG will propose (preferable was the term you used). The only way this can happen is if Kikuchi-San's draft can be modified NOW. 2. If Kikuchi-San's draft can be modified, it does NOT have to specify the content of adaptation header payload. MPEG will do it. What all it has to say is use the 'adaptation length' field to offset where you pick up the ES payload. 3. In MPEG-2, the byte that follows the adaptation length signals what is in the rest of the adaptation header such as PCR, OPCR, splicing etc. Those that cannot process the adaptation header just use the adaptation length to offset to the next payload start (such as PES header or ES). This is what I am assuming MPEG will do for 'generic' mapping. The byte after adaptation header may signal presence of DTS, SL header, flexmux header, scalable data, buffer etc. 4. If Kikuchi-San's draft progresses 'as is' and MPEG uses the adaptation header, then content authors that used the MPEG coding can only play it on receivers that implemented the re-assembly of MPEG 'generic' mapping and not on those that 'ONLY' implemented Kikuchi-San's draft (if it was not modified). CE vendors can choose to implement receivers that can support multiple payload formats. However, if Kikuchi-San's draft can be modified NOW, we may see a single payload format for MPEG-4 and I believe that is a plus and thus NECESSARY. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 12:52 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, It seems you want the current draft to be modified in the future. Then: 1. I don't believe this is possible. 2. I don't think this is necessary. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 6:21 PM To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Wed Sep 13 08:50:58 2000 From rem-conf-request@es.net Wed Sep 13 08:50:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZEl6-00075U-00; Wed, 13 Sep 2000 08:47:36 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZEl4-00070K-00; Wed, 13 Sep 2000 08:47:34 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU49V5M8REEBVMXJ@GI.COM> for rem-conf@es.net; Wed, 13 Sep 2000 08:46:30 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NP4KM>; Wed, 13 Sep 2000 08:46:11 -0400 Content-return: allowed Date: Wed, 13 Sep 2000 11:49:06 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call To: 'Zvi Lifshitz' <zvil@csi.com>, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@GI.COM>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239B0@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6518 Lines: 181 I am sorry you see it this way. I do not agree with you; however I have also run out of words and will save it for the MPEG work. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 9:33 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, what you want either will not work or is not necessary. I'm sorry we didn't manage to convince you. I've run out of words... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Wednesday, September 13, 2000 5:28 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, 1. I thought all the comments were to make changes to Kikuchi-San's draft NOW - not later. If it just added the adaptation length followed by length bytes before the ES payload (in the RTP payload), then content authors could author content that can play on receivers that implemented Kikuchi-San's draft as well as the proposal that will come out of MPEG. I am assuming that the MPEG proposal will use this adaptation bytes to signal type of content. If so, this will make Kikuchi-San's draft a sub-set of what MPEG will propose (preferable was the term you used). The only way this can happen is if Kikuchi-San's draft can be modified NOW. 2. If Kikuchi-San's draft can be modified, it does NOT have to specify the content of adaptation header payload. MPEG will do it. What all it has to say is use the 'adaptation length' field to offset where you pick up the ES payload. 3. In MPEG-2, the byte that follows the adaptation length signals what is in the rest of the adaptation header such as PCR, OPCR, splicing etc. Those that cannot process the adaptation header just use the adaptation length to offset to the next payload start (such as PES header or ES). This is what I am assuming MPEG will do for 'generic' mapping. The byte after adaptation header may signal presence of DTS, SL header, flexmux header, scalable data, buffer etc. 4. If Kikuchi-San's draft progresses 'as is' and MPEG uses the adaptation header, then content authors that used the MPEG coding can only play it on receivers that implemented the re-assembly of MPEG 'generic' mapping and not on those that 'ONLY' implemented Kikuchi-San's draft (if it was not modified). CE vendors can choose to implement receivers that can support multiple payload formats. However, if Kikuchi-San's draft can be modified NOW, we may see a single payload format for MPEG-4 and I believe that is a plus and thus NECESSARY. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 12:52 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, It seems you want the current draft to be modified in the future. Then: 1. I don't believe this is possible. 2. I don't think this is necessary. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 6:21 PM To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Wed Sep 13 09:04:51 2000 From rem-conf-request@es.net Wed Sep 13 09:04:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZEyM-0000dl-00; Wed, 13 Sep 2000 09:01:18 -0700 Received: from (p-mail1.cnet.fr) [192.144.74.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13ZEyL-0000Wc-00; Wed, 13 Sep 2000 09:01:18 -0700 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <SN9PX4HW>; Wed, 13 Sep 2000 17:59:18 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A10@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN <dominique.curet@rd.francetelecom.fr> To: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Pre-MPEG meeting for the '4onIP' AHG Date: Wed, 13 Sep 2000 18:01:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 632 Lines: 25 Dear all, dear Young-Kwon, we are supposed to meet on Saturday(21/10) and Sunday (22/10) before the MPEG meeting in La Baule. Can we say something like: Saturday from 14 to 2000 Sunday from 0900 to 1800 Or only the Sunday from 0900 to 1800 comments regards _________________________________________ > 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 Sep 13 09:36:52 2000 From rem-conf-request@es.net Wed Sep 13 09:36:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZFRB-0002Lp-00; Wed, 13 Sep 2000 09:31:05 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZFRA-0002LH-00; Wed, 13 Sep 2000 09:31:04 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <S5536GK9>; Wed, 13 Sep 2000 10:30:04 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA798468@el-postino.s-vision.com> From: Kris Huber <khuber@sorensonlabs.com> To: Zvi Lifshitz <zvil@csi.com>, Colin Perkins <csp@east.isi.edu> Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 10:30:03 -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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 8921 Lines: 215 Hello Zvi, Colin [last comment before letting this discussion transition to generic format]: I think some of the discussion has resulted from misunderstanding of the semantics of the payload type field apparently involving a change (by IETF?) >from static to dynamic binding of an external "payload name" to this field. In any case, the desire has been to see whether or not this format can somehow be a subset of the soon-to-be more generic payload format. Leaving out lack of LATM in the draft generic format, the answer appears to still be "no", unless the payload name for the future format is assigned now and a subset of its semantics, including how to read its adaptation field, are included in draft-ietf-avt-rtp-mpeg4-es-03. But this would be unprecedented, I suspect (possible? I don't know). The other option is if another static payload type is assigned and a future payload type of a different name (MPEG SL format) uses the same payload type. Why, some have asked? To avoid the redundancy that we video compression engineers hate so much! How would this redundancy result? Information broadcast services begin initially using the Kichuchi-san payload format, then have to make the decision later on between continuing to use it, and either doubling their network bandwidth to do the new broadcasting services or provide services support the new format (since the video ES data will tend to dominate the bandwidth). Allowing early-adopter non-upgradeable devices to cease to function is another possibility, but that also has a high cost if the number of such devices is large. You might wonder about an approach in which a new enhancement payload type is used rather than a single scalable payload type (e.g., generic format to add the enhancement information), and perhaps this is considered the "right way". The only problem I see with this that the information goes in separate packets and therefore additional buffer memory and synchronization functionality are required. Let me clarify, for point-to-point usage there is no efficiency problem, it is only for the broadcast (multipoint) case. It seems that static payload typing, or early assignment of payload name + "Jan-byte" + other modifications would give the proposed interoperability functionality. Out of curiosity let me ask (Colin?), how is "there will be no more static payload assignments" formally stated, with SHALL NOT or SHOULD NOT? Or is it a policy existing outside of an RFC? How many devices would be obsoleted by a new static payload type? Best regards, Kris -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 10:33 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, what you want either will not work or is not necessary. I'm sorry we didn't manage to convince you. I've run out of words... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Wednesday, September 13, 2000 5:28 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, 1. I thought all the comments were to make changes to Kikuchi-San's draft NOW - not later. If it just added the adaptation length followed by length bytes before the ES payload (in the RTP payload), then content authors could author content that can play on receivers that implemented Kikuchi-San's draft as well as the proposal that will come out of MPEG. I am assuming that the MPEG proposal will use this adaptation bytes to signal type of content. If so, this will make Kikuchi-San's draft a sub-set of what MPEG will propose (preferable was the term you used). The only way this can happen is if Kikuchi-San's draft can be modified NOW. 2. If Kikuchi-San's draft can be modified, it does NOT have to specify the content of adaptation header payload. MPEG will do it. What all it has to say is use the 'adaptation length' field to offset where you pick up the ES payload. 3. In MPEG-2, the byte that follows the adaptation length signals what is in the rest of the adaptation header such as PCR, OPCR, splicing etc. Those that cannot process the adaptation header just use the adaptation length to offset to the next payload start (such as PES header or ES). This is what I am assuming MPEG will do for 'generic' mapping. The byte after adaptation header may signal presence of DTS, SL header, flexmux header, scalable data, buffer etc. 4. If Kikuchi-San's draft progresses 'as is' and MPEG uses the adaptation header, then content authors that used the MPEG coding can only play it on receivers that implemented the re-assembly of MPEG 'generic' mapping and not on those that 'ONLY' implemented Kikuchi-San's draft (if it was not modified). CE vendors can choose to implement receivers that can support multiple payload formats. However, if Kikuchi-San's draft can be modified NOW, we may see a single payload format for MPEG-4 and I believe that is a plus and thus NECESSARY. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Wednesday, September 13, 2000 12:52 AM To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Sam, It seems you want the current draft to be modified in the future. Then: 1. I don't believe this is possible. 2. I don't think this is necessary. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] Sent: Tuesday, September 12, 2000 6:21 PM To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, I am assuming that the payload type from the future draft could be set to the same value as this draft, if this draft can accommodate the change. Regards Sam Narasimhan Motorola -----Original Message----- From: Zvi Lifshitz [mailto:ZviL@optibase.com] Sent: Tuesday, September 12, 2000 10:18 AM To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [Narasimhan, Sam (SD-EX):] If this draft were to say that receivers should parse over the adaptation bytes and not process them (as this draft does not define these), then such receivers will be able to process payload >from future draft (from MPEG) [Reply:] They will not, because they don't know the payload type of the future draft therefore they will not know they can process payloads from the future draft even though they can. If they know, they also know that the future draft has extra header info. So work on the future draft, not on the current draft. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Wed Sep 13 09:50:19 2000 From rem-conf-request@es.net Wed Sep 13 09:50:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZFfo-0003Ms-00; Wed, 13 Sep 2000 09:46:12 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZFfF-0003L0-00; Wed, 13 Sep 2000 09:45:40 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id TAA10819; Wed, 13 Sep 2000 19:44:49 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 19:45:00 +0200 Message-ID: <01C01DBB.1A609140.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Kris Huber'" <khuber@sorensonlabs.com>, Colin Perkins <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu>, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Subject: =?us-ascii?Q?RE=3A_AHG_comments_on_draft=2Dietf=2Davt=2Drtp=2D?= =?us-ascii?Q?mpeg4=2Des=2D03_in_response_to=09the_last_call?= Date: Wed, 13 Sep 2000 19:44:59 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3974 Lines: 85 Kris, all, I'm not so concerned about future upgradablity. The ES format is there now, but also we have a pretty good idea about how the Generic format is going to look like. As an implementer of MPEG-4 server technology, that's enough for me, and the official status of the proposals is not so important. I'm sure there are others who have the same approach, and together we'll build state of the art systems. This is assuming we use our time to develop, and not spend it on useless discussions.... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Kris Huber [SMTP:khuber@sorensonlabs.com] Sent: Wednesday, September 13, 2000 6:30 PM To: Zvi Lifshitz; Colin Perkins Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu; 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Hello Zvi, Colin [last comment before letting this discussion transition to generic format]: I think some of the discussion has resulted from misunderstanding of the semantics of the payload type field apparently involving a change (by IETF?) >from static to dynamic binding of an external "payload name" to this field. In any case, the desire has been to see whether or not this format can somehow be a subset of the soon-to-be more generic payload format. Leaving out lack of LATM in the draft generic format, the answer appears to still be "no", unless the payload name for the future format is assigned now and a subset of its semantics, including how to read its adaptation field, are included in draft-ietf-avt-rtp-mpeg4-es-03. But this would be unprecedented, I suspect (possible? I don't know). The other option is if another static payload type is assigned and a future payload type of a different name (MPEG SL format) uses the same payload type. Why, some have asked? To avoid the redundancy that we video compression engineers hate so much! How would this redundancy result? Information broadcast services begin initially using the Kichuchi-san payload format, then have to make the decision later on between continuing to use it, and either doubling their network bandwidth to do the new broadcasting services or provide services support the new format (since the video ES data will tend to dominate the bandwidth). Allowing early-adopter non-upgradeable devices to cease to function is another possibility, but that also has a high cost if the number of such devices is large. You might wonder about an approach in which a new enhancement payload type is used rather than a single scalable payload type (e.g., generic format to add the enhancement information), and perhaps this is considered the "right way". The only problem I see with this that the information goes in separate packets and therefore additional buffer memory and synchronization functionality are required. Let me clarify, for point-to-point usage there is no efficiency problem, it is only for the broadcast (multipoint) case. It seems that static payload typing, or early assignment of payload name + "Jan-byte" + other modifications would give the proposed interoperability functionality. Out of curiosity let me ask (Colin?), how is "there will be no more static payload assignments" formally stated, with SHALL NOT or SHOULD NOT? Or is it a policy existing outside of an RFC? How many devices would be obsoleted by a new static payload type? Best regards, Kris From rem-conf Wed Sep 13 09:52:10 2000 From rem-conf-request@es.net Wed Sep 13 09:52:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZFi6-0003We-00; Wed, 13 Sep 2000 09:48:34 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZFi4-0003WR-00; Wed, 13 Sep 2000 09:48:33 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA26980; Wed, 13 Sep 2000 18:48: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 xma026978; Wed, 13 Sep 00 18:48: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 SAA18557; Wed, 13 Sep 2000 18:48: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 SAA26617; Wed, 13 Sep 2000 18:48:29 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014059791; Wed, 13 Sep 2000 18:49:33 +0200 To: <SNarasimhan@gi.com>, <zvil@csi.com>, <Guido.Franceschini@CSELT.IT> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014059791000002L912*@MHS> Date: Wed, 13 Sep 2000 18:49:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 18:46:56" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6697 Lines: 208 Guido, Thanks. You made your point very clear but not clear enough for all. Ne= ither did I. We seem to live in too different worlds to really understand eac= h other. Sad. Regards, Jan -----Original Message----- From: Guido.Franceschini@CSELT.IT [mailto:Guido.Franceschini@CSELT.IT] Sent: woensdag, 13 september, 2000 09:26 To: zvil@csi.com; Jan vanderMeer; SNarasimhan@gi.com Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Hi all, my own considerations on this thread In RTP and IETF procedure terms, I understand this thread on the extra = byte as: 1) modify the current ES draft to accomodate a payload header starting = with a byte indicating its length. No specification of what the payload head= er carries 2) allow the modified ES draft to enter the RFC standard track and be w= idely implemented 3) propose a new draft for 'generic' ES or SL mapping, which is identic= al to the modified ES draft but also defines what the payload header carries 4) the 'generic' draft becomes standard and _obsoletes_ the ES draft. Devices implementing the ES draft will skip the payload header informat= ion but still understand the media content. Well, I think we have a technical problem here, which has nothing to do= with usual practices / procedures / timelines. The problem that I see is that: - the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video - the 'generic' draft will define 1 Payload Format only, and the type o= f media (Audio, Video, BIFS ...) being carried will be specified using MP= EG-4 Object Descriptors. What we achieved at the Paris meeting (before discussing this extra byt= e feature) has been to allow MPEG-4 Systems terminals implementing the 'generic' draft to use the ES draft as well withouth any need to duplic= ate implementations (i.e.: the ES draft is a subset of the generic draft in= the Data Plane). Now, the 'extra byte' proposal would allow devices implementing the ES = draft to be compatible in the Data Plane with the 'generic' format, too. Compatibility in the Control Plane (i.e. Payload Type negotiation/announcement) was not considered in Paris. I believe that devices implementing the 'generic' draft would have no difficulties in understanding 1 more SDP keyword or MIME type as introd= uced by the ES draft. But the reverse is more difficult and tricky. As I outlined above, the 'generic' draft would not specify by itself the type of media content i= t is carrying, and would rely on the Object Descriptor to do that. If the go= al is to allow devices implementing the ES draft to be compatible with future= content delivered by means of the 'generic' draft, than we need to spec= ify NOW how to duplicate the information in the OD so that the media type i= s made explicit for those devices. And then we will have to accept that devices implementing MPEG-4 Systems get the indication of the media typ= e twice :-( Did I make the point clear ? Guido > ---------- > From: Zvi Lifshitz[SMTP:zvil@csi.com] > Sent: Wednesday, September 13, 2000 9:51 AM > To: 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > Sam, > > It seems you want the current draft to be modified in the future. The= n: > > 1. I don't believe this is possible. > 2. I don't think this is necessary. > > Regards, > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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, Octob= er > 10th-12th, 2000 > > > -----Original Message----- > From: Narasimhan, Sam (SD-EX) [SMTP:SNarasimhan@gi.com] > Sent: Tuesday, September 12, 2000 6:21 PM > To: 'Zvi Lifshitz'; Narasimhan, Sam (SD-EX); > 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in > response to the last call > > > Zvi, > > I am assuming that the payload type from the future draft > could be set to the same value as this draft, if this > draft can accommodate the change. > > Regards > Sam Narasimhan > Motorola > > -----Original Message----- > From: Zvi Lifshitz [mailto:ZviL@optibase.com] > Sent: Tuesday, September 12, 2000 10:18 AM > To: Narasimhan, Sam (SD-EX); 'jan.vandermeer@philips.com' > Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu > Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in respon= se > to the last call > > > [Narasimhan, Sam (SD-EX):] > > If this draft were to say that receivers should parse over the > adaptation bytes and not process them (as this draft does not > define these), then such receivers will be able to process payload > from future draft (from MPEG) > > [Reply:] > > They will not, because they don't know the payload type of the future= > draft > therefore they will not know they can process payloads from the futur= e > draft > even though they can. > > If they know, they also know that the future draft has extra header i= nfo. > So > work on the future draft, not on the current draft. > > Regards, > > 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. Mobile: +972(53)461-787 > http://www.optibase.com US voice mail/fax +1(206) 888-4149 > Send SMS from: > http://isend.cellcom.co.il/English/Login.htm > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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, Octob= er > 10th-12th, 2000 > = From rem-conf Wed Sep 13 09:52:27 2000 From rem-conf-request@es.net Wed Sep 13 09:52:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZFj4-0003XF-00; Wed, 13 Sep 2000 09:49:34 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZFj3-0003X4-00; Wed, 13 Sep 2000 09:49:33 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA27118; Wed, 13 Sep 2000 18:49:31 +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 xma027116; Wed, 13 Sep 00 18:49:31 +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 SAA18780; Wed, 13 Sep 2000 18:49:31 +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 SAA26730; Wed, 13 Sep 2000 18:49:31 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014059806; Wed, 13 Sep 2000 18:50:35 +0200 To: <csp@east.isi.edu>, <zvil@csi.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014059806000002L962*@MHS> Date: Wed, 13 Sep 2000 18:50:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 18:47:58" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3565 Lines: 112 Dear Zvi, My conclusion is that I failed to let you understand the issue. And you= seem to suggest that you are not the only one. Your suggestion to kill this discussion ignores the problem addressed. I agree that putting our head= s into the sand is a way to go forward. But in my opinion we should take = our responsibility to define a future proof solution. Best regards, Jan soon there will be more in this world than plain streaming ... -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: woensdag, 13 september, 2000 09:38 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Jan, Your nice proposal can be incorporated in the Generic format. I hope we= managed to explain why it is useless with the ES format. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 5:28 AM To: csp@east.isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Colin, all, I think it is important to keep in mind that often MPEG uses in-stream signaling. For example, after the length byte, the adaptation field may= start with an identifier that specifies the sort of enhancement. Based = on this approach, the following would be needed : 1) Define an MPEG-4 ES payload format that allows for an adaptation fie= ld without defining the meaning of the adaptation field. 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "ge= neric specification" defines the use of exactly_the_same payload type as defi= ned in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation fi= eld. 3) Next to the payload types for MPEG-4 ES and SL streams, the "generic= specification" may also define payloads for other streams, such as Flex= Mux streams. For these, other payload types will be needed. Now the initial services start using the MPEG-4 ES payload format; thou= gh the adaptation field is not used, this field is allowed to occur. Futur= e services may use exactly the same payload type, but with the adaptation= field as defined by the "generic specification". It may also be important to understand that the presence of the adaptat= ion field is intended to be transparent from RTP point of view and for the session in general. The adaptation field serves MPEG-4 system purposes = which are fully orthogonal to RTP and the streaming session. Kind regards, Jan = From rem-conf Wed Sep 13 10:15:43 2000 From rem-conf-request@es.net Wed Sep 13 10:15:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZG54-0006HC-00; Wed, 13 Sep 2000 10:12:18 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZG50-0006H2-00; Wed, 13 Sep 2000 10:12:15 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id UAA14940; Wed, 13 Sep 2000 20:11:56 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 20:12:06 +0200 Message-ID: <01C01DBE.E3B8BA60.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 20:12:05 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1984 Lines: 57 Hi Jan, I have the same conclusion. Maybe I would have had another conclusion if I saw answers to the questions Collin and me and other asked. I'll try to summarize it for last time: 1. Applications that know only the ES format will not recognize a future format because they will not identify the format name. 2. Therefore having extension mechanism in the ES format without fully describing the extensions makes no sense. 3. Defining the extensions in the ES format amounts to replacing it by the Generic format. Practically in time-to-market terms, that means suppressing the ES format. What is the gain, if the Generic format is going to be a superset of the ES format? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 6:51 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, My conclusion is that I failed to let you understand the issue. And you seem to suggest that you are not the only one. Your suggestion to kill this discussion ignores the problem addressed. I agree that putting our heads into the sand is a way to go forward. But in my opinion we should take our responsibility to define a future proof solution. Best regards, Jan soon there will be more in this world than plain streaming ... From rem-conf Wed Sep 13 10:19:43 2000 From rem-conf-request@es.net Wed Sep 13 10:19:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZG9P-0006T9-00; Wed, 13 Sep 2000 10:16:47 -0700 Received: from foxtrot.nab.org ([209.116.240.194]) [209.116.240.194] by mail1.es.net with smtp (Exim 1.81 #2) id 13ZG9O-0006S3-00; Wed, 13 Sep 2000 10:16:46 -0700 Received: from wilma.nab.org by [209.116.240.194] via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 13 Sep 2000 17:16:46 UT Received: by wilma.nab.org with Internet Mail Service (5.5.2650.21) id <S3XVW325>; Wed, 13 Sep 2000 13:16:41 -0400 Message-ID: <119889647E5CD31193D4009027991299ED7503@wilma.nab.org> From: "Allison, Art" <AAllison@nab.org> To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 13:16:40 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1598 Lines: 41 >From this seat at the NAB it seems to me that unless the business models change and a serious business justification exists, one should not expect broadcasters (at least the small set of US broadcasters) to change methods to one that obsolete previous deployments once a method is started. On the other hand, as this is MPEG4 over IP, and IP will be a clean layer so that a broadcaster need not worry about the content of the IP, only those broadcasters that think consumers will complain to the station may care. If the problem is only on 'PCs', those users are less likely to complain. One could reason that manufacturers of 'TVs' would be unlikely to add support for M4/IP for similar reasons. If it doesn't work for broadcasters in the US, they will find another way to provide the desired functionality. Disclosure: This view may be biased by my assessment of MPEG-4's timing capabilities in addition to the issues under discussion. <old dead issue>. Art ::{) -----Original Message----- From: Kris Huber [mailto:khuber@sorensonlabs.com] Sent: Wednesday, September 13, 2000 12:30 PM To: Zvi Lifshitz; Colin Perkins Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu; 'Narasimhan, Sam (SD-EX)'; 'jan.vandermeer@philips.com' Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Hello Zvi, Colin [last comment before letting this discussion transition to generic format]: <snip> ... Let me clarify, for point-to-point usage there is no efficiency problem, it is only for the broadcast (multipoint) case. ... <snip> Best regards, Kris <snip> From rem-conf Wed Sep 13 10:26:27 2000 From rem-conf-request@es.net Wed Sep 13 10:26:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZGFw-0007hi-00; Wed, 13 Sep 2000 10:23:32 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZGFu-0007h8-00; Wed, 13 Sep 2000 10:23:31 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA07802; Wed, 13 Sep 2000 13:23:45 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA08349; Wed, 13 Sep 2000 22:23:24 +0500 Message-Id: <200009131723.WAA08349@hafez.east.isi.edu> To: "Luthra, Ajay (SD-EX)" <ALuthra@gi.com> cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Tue, 12 Sep 2000 19:58:47 EDT." <973597126BDDD11197AA00805FA7EBC90342164D@ntas0026.gi.com> Date: Wed, 13 Sep 2000 13:23:24 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 957 Lines: 21 --> "Luthra, Ajay (SD-EX)" writes: >Collin, > But you said in your previous email, " ... The payload type will have to >be negotiated out of band anyway .. ". And in another email you said, "Yes" >to the question - does one need to work this way in multicast environment >also. And now you are saying it does not need to be negotiated. My >understanding of this subject is not yet excellent. So, I do not understand >these three emails from you which seem to contradict each other. > >Does the payload type need to be negotiated or not? The payload type is dynamically assigned, and has to be communicated between the sender and the receiver(s) somehow. RTP does not specify how that communication is done. In the unicast case it is typical to negotiate, in the one-to-many multicast case the sender tells the receivers (i.e. the receiver has no choice, so it can't really be called "negotiation"). But there is always out of band signalling. Colin From rem-conf Wed Sep 13 10:26:34 2000 From rem-conf-request@es.net Wed Sep 13 10:26:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZGFj-0007g9-00; Wed, 13 Sep 2000 10:23:19 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZGFh-0007ff-00; Wed, 13 Sep 2000 10:23:18 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id TAA01739; Wed, 13 Sep 2000 19:23:16 +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 xma001737; Wed, 13 Sep 00 19:23:16 +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 TAA26030; Wed, 13 Sep 2000 19:23:16 +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 TAA01318; Wed, 13 Sep 2000 19:23:15 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014059984; Wed, 13 Sep 2000 19:24:20 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: <rem-conf@es.net> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014059984000002L942*@MHS> Date: Wed, 13 Sep 2000 19:24:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 19:21:43" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5494 Lines: 160 Dear all, I would like to put the problem in a little bit wider perspective. Seve= ral people perfectly understand the problem while some (?) others don't yet= understand the problem, while suggesting that we are wasting our time w= ith useless discussions. As Ajay stated correctly, it is the responsibility= of IETF to decide how to proceed with the current MPEG-4 ES proposal. The = only thing we can say right now is that several (perhaps even well respected= ) MPEG members have substantial comments on the current proposal. As a consequence it is likely that MPEG (members) will submit another propos= al for carriage of MPEG-4 ES to IETF. Though this proposal is expected to = have a high level of overlap with the current one, it is slightly different.= IETF may wish to take this into account when coming to a decision. Kind regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: woensdag, 13 september, 2000 18:52 To: csp@east.isi.edu; khuber@sorensonlabs.com Cc: Jan vanderMeer; SNarasimhan@gi.com; 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Kris, all, I'm not so concerned about future upgradablity. The ES format is there= now, but also we have a pretty good idea about how the Generic format i= s going to look like. As an implementer of MPEG-4 server technology, that= 's enough for me, and the official status of the proposals is not so important. I'm sure there are others who have the same approach, and together we'll build state of the art systems. This is assuming we use = our time to develop, and not spend it on useless discussions.... Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: Kris Huber [SMTP:khuber@sorensonlabs.com] Sent: Wednesday, September 13, 2000 6:30 PM To: Zvi Lifshitz; Colin Perkins Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu; 'Narasimhan,= Sam (SD-EX)'; 'jan.vandermeer@philips.com' Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Hello Zvi, Colin [last comment before letting this discussion transitio= n to generic format]: I think some of the discussion has resulted from misunderstanding of th= e semantics of the payload type field apparently involving a change (by IETF?) >from static to dynamic binding of an external "payload name" to this fi= eld. In any case, the desire has been to see whether or not this format can somehow be a subset of the soon-to-be more generic payload format. Lea= ving out lack of LATM in the draft generic format, the answer appears to sti= ll be "no", unless the payload name for the future format is assigned now and= a subset of its semantics, including how to read its adaptation field, ar= e included in draft-ietf-avt-rtp-mpeg4-es-03. But this would be unprecedented, I suspect (possible? I don't know). The other option i= s if another static payload type is assigned and a future payload type of a different name (MPEG SL format) uses the same payload type. Why, some have asked? To avoid the redundancy that we video compressio= n engineers hate so much! How would this redundancy result? Information= broadcast services begin initially using the Kichuchi-san payload forma= t, then have to make the decision later on between continuing to use it, a= nd either doubling their network bandwidth to do the new broadcasting serv= ices or provide services support the new format (since the video ES data wil= l tend to dominate the bandwidth). Allowing early-adopter non-upgradeabl= e devices to cease to function is another possibility, but that also has = a high cost if the number of such devices is large. You might wonder abo= ut an approach in which a new enhancement payload type is used rather than a single scalable payload type (e.g., generic format to add the enhanceme= nt information), and perhaps this is considered the "right way". The only= problem I see with this that the information goes in separate packets a= nd therefore additional buffer memory and synchronization functionality ar= e required. Let me clarify, for point-to-point usage there is no efficie= ncy problem, it is only for the broadcast (multipoint) case. It seems that static payload typing, or early assignment of payload nam= e + "Jan-byte" + other modifications would give the proposed interoperabili= ty functionality. Out of curiosity let me ask (Colin?), how is "there wil= l be no more static payload assignments" formally stated, with SHALL NOT or SHOULD NOT? Or is it a policy existing outside of an RFC? How many devices would be obsoleted by a new static payload type? Best regards, Kris = From rem-conf Wed Sep 13 10:28:10 2000 From rem-conf-request@es.net Wed Sep 13 10:28:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZGHa-0000AB-00; Wed, 13 Sep 2000 10:25:14 -0700 Received: from foxtrot.nab.org ([209.116.240.194]) [209.116.240.194] by mail1.es.net with smtp (Exim 1.81 #2) id 13ZGHZ-00009k-00; Wed, 13 Sep 2000 10:25:13 -0700 Received: from wilma.nab.org by [209.116.240.194] via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 13 Sep 2000 17:25:12 UT Received: by wilma.nab.org with Internet Mail Service (5.5.2650.21) id <S3XVW3KS>; Wed, 13 Sep 2000 13:25:12 -0400 Message-ID: <119889647E5CD31193D4009027991299ED7504@wilma.nab.org> From: "Allison, Art" <AAllison@nab.org> To: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 13:25:10 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3597 Lines: 101 Here! here! Art ::{) -----Original Message----- From: jan.vandermeer@philips.com [mailto:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 12:51 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, My conclusion is that I failed to let you understand the issue. And you seem to suggest that you are not the only one. Your suggestion to kill this discussion ignores the problem addressed. I agree that putting our heads into the sand is a way to go forward. But in my opinion we should take our responsibility to define a future proof solution. Best regards, Jan soon there will be more in this world than plain streaming ... -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: woensdag, 13 september, 2000 09:38 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Jan, Your nice proposal can be incorporated in the Generic format. I hope we managed to explain why it is useless with the ES format. z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 5:28 AM To: csp@east.isi.edu Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Colin, all, I think it is important to keep in mind that often MPEG uses in-stream signaling. For example, after the length byte, the adaptation field may start with an identifier that specifies the sort of enhancement. Based on this approach, the following would be needed : 1) Define an MPEG-4 ES payload format that allows for an adaptation field without defining the meaning of the adaptation field. 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic specification" defines the use of exactly_the_same payload type as defined in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation field. 3) Next to the payload types for MPEG-4 ES and SL streams, the "generic specification" may also define payloads for other streams, such as FlexMux streams. For these, other payload types will be needed. Now the initial services start using the MPEG-4 ES payload format; though the adaptation field is not used, this field is allowed to occur. Future services may use exactly the same payload type, but with the adaptation field as defined by the "generic specification". It may also be important to understand that the presence of the adaptation field is intended to be transparent from RTP point of view and for the session in general. The adaptation field serves MPEG-4 system purposes which are fully orthogonal to RTP and the streaming session. Kind regards, Jan From rem-conf Wed Sep 13 10:54:11 2000 From rem-conf-request@es.net Wed Sep 13 10:54:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZGf7-0003El-00; Wed, 13 Sep 2000 10:49:33 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZGf5-0003ER-00; Wed, 13 Sep 2000 10:49:32 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id TAA04342; Wed, 13 Sep 2000 19:49: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 xma004340; Wed, 13 Sep 00 19:49: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 TAA01109; Wed, 13 Sep 2000 19:49: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 TAA04289; Wed, 13 Sep 2000 19:49:29 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014060125; Wed, 13 Sep 2000 19:50:34 +0200 To: <csp@east.isi.edu>, <zvil@csi.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014060125000002L952*@MHS> Date: Wed, 13 Sep 2000 19:50:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/13/00 19:47:52" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3008 Lines: 101 Zvi, Your first assumption is incorrect. The name does not change when inclu= ding the adaptation field. But rather than explaining once more by email, I = will try to reach you by phone. A few minutes ago I failed to reach you on b= oth phone numbers you gave, so I will give it another try by tomorrow, assu= ming that you will be in your office by than. If needed, please let me know = how I can reach you otherwise. Best regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: woensdag, 13 september, 2000 19:15 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Hi Jan, I have the same conclusion. Maybe I would have had another conclusion i= f I saw answers to the questions Collin and me and other asked. I'll try to= summarize it for last time: 1. Applications that know only the ES format will not recognize a futur= e format because they will not identify the format name. 2. Therefore having extension mechanism in the ES format without fully describing the extensions makes no sense. 3. Defining the extensions in the ES format amounts to replacing it by = the Generic format. Practically in time-to-market terms, that means suppres= sing the ES format. What is the gain, if the Generic format is going to be a= superset of the ES format? Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 6:51 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Dear Zvi, My conclusion is that I failed to let you understand the issue. And you= seem to suggest that you are not the only one. Your suggestion to kill this discussion ignores the problem addressed. I agree that putting our head= s into the sand is a way to go forward. But in my opinion we should take = our responsibility to define a future proof solution. Best regards, Jan soon there will be more in this world than plain streaming ... = From rem-conf Wed Sep 13 12:23:09 2000 From rem-conf-request@es.net Wed Sep 13 12:23:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZI3p-0006VT-00; Wed, 13 Sep 2000 12:19:09 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZI3n-0006Um-00; Wed, 13 Sep 2000 12:19:07 -0700 Received: from zvil (i0-6.j2.actcom.co.il [192.115.22.99]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA02148; Wed, 13 Sep 2000 22:18:36 +0300 Received: by localhost with Microsoft MAPI; Wed, 13 Sep 2000 22:18:44 +0200 Message-ID: <01C01DD0.94631B60.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Wed, 13 Sep 2000 22:18:43 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3803 Lines: 108 Sorry I'm not available for MPEG discussions 24 hours a day ;-) Try tomorrow, why not? I'm curious to hear your explanation to your first sentence below.. If you manage to make it through my hard head there will be a big apologize on the reflector ;-)) z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 7:51 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Zvi, Your first assumption is incorrect. The name does not change when including the adaptation field. But rather than explaining once more by email, I will try to reach you by phone. A few minutes ago I failed to reach you on both phone numbers you gave, so I will give it another try by tomorrow, assuming that you will be in your office by than. If needed, please let me know how I can reach you otherwise. Best regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: woensdag, 13 september, 2000 19:15 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Hi Jan, I have the same conclusion. Maybe I would have had another conclusion if I saw answers to the questions Collin and me and other asked. I'll try to summarize it for last time: 1. Applications that know only the ES format will not recognize a future format because they will not identify the format name. 2. Therefore having extension mechanism in the ES format without fully describing the extensions makes no sense. 3. Defining the extensions in the ES format amounts to replacing it by the Generic format. Practically in time-to-market terms, that means suppressing the ES format. What is the gain, if the Generic format is going to be a superset of the ES format? 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Wednesday, September 13, 2000 6:51 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Zvi, My conclusion is that I failed to let you understand the issue. And you seem to suggest that you are not the only one. Your suggestion to kill this discussion ignores the problem addressed. I agree that putting our heads into the sand is a way to go forward. But in my opinion we should take our responsibility to define a future proof solution. Best regards, Jan soon there will be more in this world than plain streaming ... From rem-conf Wed Sep 13 13:42:48 2000 From rem-conf-request@es.net Wed Sep 13 13:42:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZJJL-0001gY-00; Wed, 13 Sep 2000 13:39:15 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZJJJ-0001gH-00; Wed, 13 Sep 2000 13:39:13 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id QAA09906; Wed, 13 Sep 2000 16:39:32 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id BAA08950; Thu, 14 Sep 2000 01:39:10 +0500 Message-Id: <200009132039.BAA08950@hafez.east.isi.edu> To: Stephan Wenger <stewe@cs.tu-berlin.de> cc: rem-conf@es.net Subject: Re: In band signalling of PT In-Reply-To: Your message of "Tue, 12 Sep 2000 23:07:13 +0200." <4.3.2.7.2.20000912225736.02bf17c0@mail.cs.tu-berlin.de> Date: Wed, 13 Sep 2000 16:39:10 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1193 Lines: 29 --> Stephan Wenger writes: >Folks, > >the recent discussion about the MPEG-4 ES payload brought up an >issue that, IMHO, may be a shortcoming of current RTP and could >easily be fixed. This shortcoming is RTP's need for the out-of-band >announcement/negotiation of parameters, including the PT. > >I wonder whether it may make sense to signal such information in-band >as well, e.g. through sender reports or through special media packets. >That would allow receivers to "tune" to RTP broadcasts with only >IP/Port information (which could, for example, be owned by a TV station). > >Questions: > >a) Did I miss something in the current spec? Is this already specified? >b) Does such a scenario make sense? Specifically, how do people think > to include session announcements in the media packetstream (or in > RTCP)? I recall that some time ago there was some discussion > about architectural cleanness (it does / doesn't make sense to include > session info in the media stream). What is the status of that? Does it help? Since you need out of band information to know where to find the media stream, you may as well include information about the format of the media. Colin From rem-conf Wed Sep 13 14:30:49 2000 From rem-conf-request@es.net Wed Sep 13 14:30:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZK3q-0003oZ-00; Wed, 13 Sep 2000 14:27:18 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZK3p-0003oP-00; Wed, 13 Sep 2000 14:27:17 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id OAA23525 for rem-conf@es.net; Wed, 13 Sep 2000 14:27:19 -0700 Date: Wed, 13 Sep 2000 14:27:19 -0700 From: John Lazzaro <lazzaro@CS.Berkeley.EDU> Message-Id: <200009132127.OAA23525@snap.CS.Berkeley.EDU> To: rem-conf@es.net Subject: Re: In band signalling of PT X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1104 Lines: 24 [Colin Perkins writes ...] > Does it help? Since you need out of band information to know where to find > the media stream, you may as well include information about the format of > the media. I think it could really help move the conversation forward if one of the pro-inband folks explicitly describes the out-of-band system they have in mind for finding the initial media stream, and explain why this out-of-band system can't be based on IETF protocols known to be able to handle the tasks that the pro-inband folks are requesting RTP changes to handle. There's an implicit sense of "implementing those IETF protocols on a dumb MPEG-4 terminal is too complex/costly" -- once you make that implicit statement explicit and supported, there's an opportunity to move forward with the discussion ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Wed Sep 13 16:42:30 2000 From rem-conf-request@es.net Wed Sep 13 16:42:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZM66-0006EL-00; Wed, 13 Sep 2000 16:37:46 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZM63-0006E7-00; Wed, 13 Sep 2000 16:37:44 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id TAA10902; Wed, 13 Sep 2000 19:37:57 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id EAA13317; Thu, 14 Sep 2000 04:37:35 +0500 Message-Id: <200009132337.EAA13317@hafez.east.isi.edu> To: jan.vandermeer@philips.com cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Wed, 13 Sep 2000 05:27:55 +0200." <0056890014033793000002L932*@MHS> Date: Wed, 13 Sep 2000 19:37:35 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1201 Lines: 28 --> jan.vandermeer@philips.com writes: >Colin, all, > >I think it is important to keep in mind that often MPEG uses in-stream >signaling. For example, after the length byte, the adaptation field may >start with an identifier that specifies the sort of enhancement. Based on >this approach, the following would be needed : > >1) Define an MPEG-4 ES payload format that allows for an adaptation field >without defining the meaning of the adaptation field. > >2) Define the meaning of the adaptation field in the "generic MPEG-4 >specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic >specification" defines the use of exactly_the_same payload type as defined >in 1). The only difference is the defined use of the adaptation field. >Whether or not an SL header is carried is signaled in the adaptation field. I do not believe that this is possible. The differences between the ES format and the "generic" format are too great - one assumes the use of MPEG Systems, one requires that MPEG systems is NOT used (and that LATM is used instead, in the case of audio). Simply adding an extra byte for an extension header will not solve this fundamental semantic difference. Colin From rem-conf Wed Sep 13 16:48:31 2000 From rem-conf-request@es.net Wed Sep 13 16:48:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZMDZ-0006cN-00; Wed, 13 Sep 2000 16:45:29 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZMDX-0006cB-00; Wed, 13 Sep 2000 16:45:27 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id TAA10940; Wed, 13 Sep 2000 19:45:45 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id EAA13348; Thu, 14 Sep 2000 04:45:24 +0500 Message-Id: <200009132345.EAA13348@hafez.east.isi.edu> To: Franceschini Guido <Guido.Franceschini@cselt.it> cc: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "'zvi'" <zvil@csi.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Wed, 13 Sep 2000 09:22:17 +0200." <85077463E51D6A498C453073E1677940034EBF@exc2k02.cselt.it> Date: Wed, 13 Sep 2000 19:45:24 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2631 Lines: 54 --> Franceschini Guido writes: >Hi all, >my own considerations on this thread > >In RTP and IETF procedure terms, I understand this thread on the extra byte >as: >1) modify the current ES draft to accomodate a payload header starting with >a byte indicating its length. No specification of what the payload header >carries >2) allow the modified ES draft to enter the RFC standard track and be widely >implemented >3) propose a new draft for 'generic' ES or SL mapping, which is identical to >the modified ES draft but also defines what the payload header carries >4) the 'generic' draft becomes standard and _obsoletes_ the ES draft. >Devices implementing the ES draft will skip the payload header information >but still understand the media content. > >Well, I think we have a technical problem here, which has nothing to do with >usual practices / procedures / timelines. >The problem that I see is that: >- the ES draft defines 2 Payload Formats: 1 for Audio, 1 for Video >- the 'generic' draft will define 1 Payload Format only, and the type of >media (Audio, Video, BIFS ...) being carried will be specified using MPEG-4 >Object Descriptors. > >What we achieved at the Paris meeting (before discussing this extra byte >feature) has been to allow MPEG-4 Systems terminals implementing the >'generic' draft to use the ES draft as well withouth any need to duplicate >implementations (i.e.: the ES draft is a subset of the generic draft in the >Data Plane). >Now, the 'extra byte' proposal would allow devices implementing the ES draft >to be compatible in the Data Plane with the 'generic' format, too. > >Compatibility in the Control Plane (i.e. Payload Type >negotiation/announcement) was not considered in Paris. >I believe that devices implementing the 'generic' draft would have no >difficulties in understanding 1 more SDP keyword or MIME type as introduced >by the ES draft. >But the reverse is more difficult and tricky. As I outlined above, the >'generic' draft would not specify by itself the type of media content it is >carrying, and would rely on the Object Descriptor to do that. If the goal is >to allow devices implementing the ES draft to be compatible with future >content delivered by means of the 'generic' draft, than we need to specify >NOW how to duplicate the information in the OD so that the media type is >made explicit for those devices. And then we will have to accept that >devices implementing MPEG-4 Systems get the indication of the media type >twice :-( And get the necessary changes to H.323 made in time for the next ITU meeting in November, where the ES format is to be included. Colin From rem-conf Wed Sep 13 17:16:21 2000 From rem-conf-request@es.net Wed Sep 13 17:16:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZMeX-0000Lw-00; Wed, 13 Sep 2000 17:13:21 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZMeV-0000Lm-00; Wed, 13 Sep 2000 17:13:19 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id UAA11085; Wed, 13 Sep 2000 20:13:31 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id FAA13488; Thu, 14 Sep 2000 05:13:10 +0500 Message-Id: <200009140013.FAA13488@hafez.east.isi.edu> To: Kris Huber <khuber@sorensonlabs.com> cc: Zvi Lifshitz <zvil@csi.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu, "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Wed, 13 Sep 2000 10:30:03 MDT." <6E031E06378BD311AEF20090273CE1BA798468@el-postino.s-vision.com> Date: Wed, 13 Sep 2000 20:13:10 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3106 Lines: 57 --> Kris Huber writes: >Hello Zvi, Colin [last comment before letting this discussion transition to >generic format]: > >I think some of the discussion has resulted from misunderstanding of the >semantics of the payload type field apparently involving a change (by IETF?) >from static to dynamic binding of an external "payload name" to this field. The decision to refuse further static payload type assignments was made at the Munich IETF meeting, in August 1997. >In any case, the desire has been to see whether or not this format can >somehow be a subset of the soon-to-be more generic payload format. Leaving >out lack of LATM in the draft generic format, the answer appears to still be >"no", unless the payload name for the future format is assigned now and a >subset of its semantics, including how to read its adaptation field, are >included in draft-ietf-avt-rtp-mpeg4-es-03. But this would be >unprecedented, I suspect (possible? I don't know). The other option is if >another static payload type is assigned and a future payload type of a >different name (MPEG SL format) uses the same payload type. This is one problem, certainly. The LATM problem is also major, and seems to be ignored in much of this discussion. >Why, some have asked? To avoid the redundancy that we video compression >engineers hate so much! How would this redundancy result? Information >broadcast services begin initially using the Kichuchi-san payload format, >then have to make the decision later on between continuing to use it, and >either doubling their network bandwidth to do the new broadcasting services >or provide services support the new format (since the video ES data will >tend to dominate the bandwidth). Allowing early-adopter non-upgradeable >devices to cease to function is another possibility, but that also has a >high cost if the number of such devices is large. You might wonder about an >approach in which a new enhancement payload type is used rather than a >single scalable payload type (e.g., generic format to add the enhancement >information), and perhaps this is considered the "right way". The only >problem I see with this that the information goes in separate packets and >therefore additional buffer memory and synchronization functionality are >required. Let me clarify, for point-to-point usage there is no efficiency >problem, it is only for the broadcast (multipoint) case. I would consider the correct solution would be to send the extra information as an additional stream. I don't believe the overheads are significant. >It seems that static payload typing, or early assignment of payload name + >"Jan-byte" + other modifications would give the proposed interoperability >functionality. Out of curiosity let me ask (Colin?), how is "there will be >no more static payload assignments" formally stated, with SHALL NOT or >SHOULD NOT? Or is it a policy existing outside of an RFC? How many devices >would be obsoleted by a new static payload type? The policy was made in the AVT working group, to prevent exhaustion of the limited payload type space. Colin From rem-conf Wed Sep 13 17:29:17 2000 From rem-conf-request@es.net Wed Sep 13 17:29:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZMpj-0001Fg-00; Wed, 13 Sep 2000 17:24:55 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZMpi-0001FU-00; Wed, 13 Sep 2000 17:24:54 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id UAA11136; Wed, 13 Sep 2000 20:25:12 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id FAA13548; Thu, 14 Sep 2000 05:24:51 +0500 Message-Id: <200009140024.FAA13548@hafez.east.isi.edu> To: jan.vandermeer@philips.com cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, rem-conf <rem-conf@es.net> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Wed, 13 Sep 2000 19:24:20 +0200." <0056890014059984000002L942*@MHS> Date: Wed, 13 Sep 2000 20:24:51 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1341 Lines: 25 --> jan.vandermeer@philips.com writes: >I would like to put the problem in a little bit wider perspective. Several >people perfectly understand the problem while some (?) others don't yet >understand the problem, while suggesting that we are wasting our time with >useless discussions. As Ajay stated correctly, it is the responsibility of >IETF to decide how to proceed with the current MPEG-4 ES proposal. The only >thing we can say right now is that several (perhaps even well respected) >MPEG members have substantial comments on the current proposal. As a >consequence it is likely that MPEG (members) will submit another proposal >for carriage of MPEG-4 ES to IETF. Though this proposal is expected to have >a high level of overlap with the current one, it is slightly different. IETF >may wish to take this into account when coming to a decision. We look forward to your proposal, however note that due to interactions with the ITU (who which to use MPEG-4 ES as part of the next version of H.323) you need to produce this as an internet draft within the next few days or else we will be unable to consider it. As an alternative, you may wish to propose explicit wording changes to the Kikuchi-san proposal to bring it into line with your ideas. This discussion may reach closure faster if we have a more concrete design. Colin From rem-conf Wed Sep 13 17:39:45 2000 From rem-conf-request@es.net Wed Sep 13 17:39:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZN17-0001wQ-00; Wed, 13 Sep 2000 17:36:41 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZN16-0001wC-00; Wed, 13 Sep 2000 17:36:40 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id UAA11182; Wed, 13 Sep 2000 20:36:56 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id FAA13596; Thu, 14 Sep 2000 05:36:35 +0500 Message-Id: <200009140036.FAA13596@hafez.east.isi.edu> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> cc: "'Zvi Lifshitz'" <zvil@csi.com>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Wed, 13 Sep 2000 11:28:26 EDT." <973597126BDDD11197AA00805FA7EBC9034239AE@ntas0026.gi.com> Date: Wed, 13 Sep 2000 20:36:35 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2500 Lines: 52 --> "Narasimhan, Sam (SD-EX)" writes: >Zvi, > >1. I thought all the comments were to make changes to > Kikuchi-San's draft NOW - not later. If it just added > the adaptation length followed by length bytes before > the ES payload (in the RTP payload), then content > authors could author content that can play on receivers > that implemented Kikuchi-San's draft as well as the > proposal that will come out of MPEG. I am assuming > that the MPEG proposal will use this adaptation > bytes to signal type of content. If so, this will > make Kikuchi-San's draft a sub-set of what MPEG will > propose (preferable was the term you used). The only way > this can happen is if Kikuchi-San's draft can be modified > NOW. The Kikuchi-san draft is needed for inclusion in the H.323 standard, under revision in the ITU. This is why we are very short on time for modifications. >2. If Kikuchi-San's draft can be modified, it does NOT have to > specify the content of adaptation header payload. MPEG will > do it. What all it has to say is use the 'adaptation length' > field to offset where you pick up the ES payload. This assumes that the ES payload is either LATM audio or video in the Combined Configuration/Elementary stream mode. Can you really produce a generic format which always includes ES data in that format? If not, you will break the old receivers. >3. In MPEG-2, the byte that follows the adaptation length > signals what is in the rest of the adaptation header such > as PCR, OPCR, splicing etc. Those that cannot process the > adaptation header just use the adaptation length to offset to > the next payload start (such as PES header or ES). This > is what I am assuming MPEG will do for 'generic' mapping. The > byte after adaptation header may signal presence of DTS, > SL header, flexmux header, scalable data, buffer etc. >4. If Kikuchi-San's draft progresses 'as is' and MPEG uses the > adaptation header, then content authors that used the MPEG > coding can only play it on receivers that implemented the > re-assembly of MPEG 'generic' mapping and not on those that > 'ONLY' implemented Kikuchi-San's draft (if it was not modified). > CE vendors can choose to implement receivers that can support > multiple payload formats. However, if Kikuchi-San's draft can > be modified NOW, we may see a single payload format for MPEG-4 > and I believe that is a plus and thus NECESSARY. Colin From rem-conf Wed Sep 13 17:42:34 2000 From rem-conf-request@es.net Wed Sep 13 17:42:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZN3S-0002BB-00; Wed, 13 Sep 2000 17:39:06 -0700 Received: from newdev.eecs.harvard.edu (newdev.harvard.edu) [140.247.60.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZN3R-0002At-00; Wed, 13 Sep 2000 17:39:05 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA01549; Wed, 13 Sep 2000 20:38:44 -0400 (EDT) Date: Wed, 13 Sep 2000 20:38:44 -0400 (EDT) From: Scott Bradner <sob@harvard.edu> Message-Id: <200009140038.UAA01549@newdev.harvard.edu> To: csp@east.isi.edu, jan.vandermeer@philips.com Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Cc: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 289 Lines: 9 > As an alternative, you may wish to propose explicit wording changes to > the Kikuchi-san proposal to bring it into line with your ideas. This > discussion may reach closure faster if we have a more concrete design. I would strongly suggest that this is the better path to take Scott From rem-conf Wed Sep 13 19:37:07 2000 From rem-conf-request@es.net Wed Sep 13 19:37:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZOoL-0005wR-00; Wed, 13 Sep 2000 19:31:37 -0700 Received: from mail.caramail.com [195.68.99.70] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZOoK-0005wH-00; Wed, 13 Sep 2000 19:31:36 -0700 Received: from caramail.com (www24.caramail.com [195.68.99.44]) by mail.caramail.com (8.8.8/8.8.8) with SMTP id EAA21762 for rem-conf@es.net; Thu, 14 Sep 2000 04:31:32 +0100 (WET DST) Posted-Date: Thu, 14 Sep 2000 04:31:32 +0100 (WET DST) From: Jerome Proffit <jeromeproffit@caramail.com> To: rem-conf@es.net Message-ID: <968902319018113@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [216.241.227.140] Mime-Version: 1.0 Subject: Questions about RTP payload for DTMF digit (RFC 2833) and for Redundant Audio data (RFC 2198) Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_018113968902319_ID" Date: Wed, 13 Sep 2000 19:31:36 -0700 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1079 Lines: 35 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_Caramail_018113968902319_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, I have some questions about RTP payload for DTMF digit (RFC 2833) and for Redundant Audio data (RFC 2198). 1) If there is only one event, does one have to send a block header. 2) When one detects a new event, one sends the absolute timestamp of the begining of the event in the RTP header. But does one have to increment the Timestamp field in the RTP header for the following packets concerning the same event? or does one still send the same Timestamp (begining of the event)? 3) if there is a big gap between two events, does one need to send a RTP packet? if yes what is the format of it? Thanks a lot, Jerome Proffit ______________________________________________________ Bo=EEte aux lettres - Caramail - http://www.caramail.com --=_NextPart_Caramail_018113968902319_ID-- From rem-conf Wed Sep 13 22:56:00 2000 From rem-conf-request@es.net Wed Sep 13 22:55:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZRoG-0004ac-00; Wed, 13 Sep 2000 22:43:44 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZRoF-0004aN-00; Wed, 13 Sep 2000 22:43:43 -0700 Received: from kaipara.live.com (sdsl-208-185-235-154.dsl.sjc.megapath.net [208.185.235.154]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA11970 for <rem-conf@es.net>; Wed, 13 Sep 2000 22:42:22 -0700 (PDT) Message-Id: <4.3.1.1.20000913223429.00b65e80@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 13 Sep 2000 22:40:26 -0700 To: rem-conf@es.net From: Ross Finlayson <finlayson@live.com> Subject: Re: In band signalling of PT In-Reply-To: <200009132127.OAA23525@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 577 Lines: 14 Another point to keep in mind here is that - in the general case - a multimedia session can consist of *more than one* RTP stream (e.g., one RTP stream for video; another for audio; another for subtitles). Even if each individual stream were - somehow - to have in-band information about its payload format, etc., you'd still need a way of describing which individual RTP streams make up an entire session. Although the MPEG world has often assumed that multiple media are multiplexed together in a single stream, RTP has more flexibility than this. Ross. From rem-conf Thu Sep 14 00:54:57 2000 From rem-conf-request@es.net Thu Sep 14 00:54:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZTlv-0000tR-00; Thu, 14 Sep 2000 00:49:27 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZTlm-0000sw-00; Thu, 14 Sep 2000 00:49:18 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id KAA01682; Thu, 14 Sep 2000 10:48:32 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 10:48:43 +0200 Message-ID: <01C01E39.59817780.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 14 Sep 2000 10:48:41 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3315 Lines: 72 [jan.vandermeer@philips.com:] 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic specification" defines the use of exactly_the_same payload type as defined in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation field. [Reply:] If I understand you right, you seem to suggest what I asked you about few emails ago. To define one payload format, with an empty extension, and later to define the content of the extension. Same payload format, same name. Well, if this is your meaning at least I can understand what you want to do technically. Theoretically this can work, as it solves the problem of old devices having to recognize new name. [Over night I thought about another scenario which solves the old-device-new-name issue, and planned to ask you (and Sam) if this was your scenario. This is when streams are broadcast but session description is interactively negotiated point-to-point. Then, assuming a stream is broadcast in the "new" format and a client starts negotiation to locate this stream, the server asks the client what formats it recognizes. If the client says the new format is OK, the server tells it the truth that this is in the new format. But if the client says it knows only the "old" format, the server bluffs and tells this is the old format]. Still, I don't believe this can work. I think also Colin said that. First, I believe this is against the IETF practice. Then, the Generic format differs from the ES format in much more than just the extension content. The ES format uses LATM. The Generic format is not only for audio/video elementary streams. The ES format defines fragmentation rules, which in the Generic format are configured by the SLConfig. The evolution that one needs to reach the other is Darwinian and might take 2 billion years... The main question is, assuming old devices can peacefully skip the extension field, how do we guarantee that they correctly handle the content beyond? And, again, I don't see why we need it. If a stream that is delivered with the ES format can be played and synchronized, why would you ever want to put something in its adaptation field? What kind of extra SL info do you think can enhance it? The only thing I can think of is combining it with other streams that require the Generic format, but this is possible without touching the stream. ---- at this point I'm getting a phone call from Jan :-)............ --- (20 minutes later).. OK, we clarified between us few more things. At least we better understand now the disagreement... I'll send my message is as and let Jan continue... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 14 01:50:35 2000 From rem-conf-request@es.net Thu Sep 14 01:50:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZUhT-00033b-00; Thu, 14 Sep 2000 01:48:55 -0700 Received: from omega.cisco.com [171.69.63.141] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZUhS-00032t-00; Thu, 14 Sep 2000 01:48:54 -0700 Received: from tmima-homepc.cisco.com (tmima-dsl5.cisco.com [144.254.211.46]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA10176; Thu, 14 Sep 2000 01:39:55 -0700 (PDT) Message-Id: <4.3.1.2.20000914010737.01f5b750@omega.cisco.com> X-Sender: tmima@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 14 Sep 2000 01:40:08 -0700 To: Andy Valencia <vandys@zendo.com>, "W. Mark Townsley" <townsley@cisco.com> From: Tmima Koren <tmima@cisco.com> Subject: Re: 0 byte L2TPHC header and implied PPPMUX Cc: brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, gurdeep@microsoft.com, palter@zev.net, l2tp@diameter.org, rem-conf@es.net In-Reply-To: <4.3.1.2.20000907161936.029ba8e0@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1501 Lines: 46 Hi Since there was no feedback from the lists about this issue, can we update the draft with the suggested changes? (3 flags in byte 9 of L2TPHC AVP) Thanks, Tmima At 06:03 PM 9/7/00 -0700, Tmima Koren wrote: >I suggest a few minor changes to the L2TPHC draft draft-ietf-l2tpext-l2tphc-02.txt >to improve bandwidth utilization in special cases. > > >When the L2TPHC header is 1 byte long, actually only 1 bit is significant: the P (Priority) bit. > >If all the packets in the tunnel will have the same priority, the L2TPHC byte is redundant. > >We could add to the L2TPHC AVP one more byte (byte 9) >We really need only 2 flag bits: > >flag 1: value 1 means: L2TPHC byte will be omitted > value 0 means: L2TPHC byte is there, get P (Priority) from the L2TPHC byte > >flag 2: value 1 means all packets have implied P=1 > value 0 means all packets have implied P=0 > >consult flag 2 only when flag 1 is 1 > > >If the packet in the L2TPHC tunnel is always PPPMUX, there is another useful flag: > >flag 3: value 1 means 'PPPMUX only' > value 0 means: any PPP packet > > >When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can be omitted >PPP packets that have a different priority or that are not PPPMUX can still be sent in the tunnel using the UDP/L2TP format, same as the L2TP control packets > >TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: the tunneling overhead will be reduced by 2 bytes. > >Tmima > From rem-conf Thu Sep 14 02:04:11 2000 From rem-conf-request@es.net Thu Sep 14 02:04:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZUsm-0003wa-00; Thu, 14 Sep 2000 02:00:36 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZUsk-0003wO-00; Thu, 14 Sep 2000 02:00:34 -0700 Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de with SMTP id KAA15073; Thu, 14 Sep 2000 10:59:37 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" <christ@rus.uni-stuttgart.de> To: "CURET Dominique FTRD/DMI/REN" <dominique.curet@rd.francetelecom.fr>, <4on2andIP-sys@advent.ee.columbia.edu>, <rem-conf@es.net> Subject: RE: Pre-MPEG meeting for the '4onIP' AHG Date: Thu, 14 Sep 2000 11:17:59 +0200 Message-ID: <015c01c01e2c$ad136e60$aa1e4581@ksat10.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A10@l-rmhs.lannion.cnet.fr> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by artemis.rus.uni-stuttgart.de id KAA15073 X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1003 Lines: 42 Dear D., dear all, for me both days are o.k.. Paul Christ > -----Original Message----- > From: CURET Dominique FTRD/DMI/REN > [mailto:dominique.curet@rd.francetelecom.fr] > Sent: Mittwoch, 13. September 2000 18:01 > To: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net > Subject: Pre-MPEG meeting for the '4onIP' AHG > > > Dear all, dear Young-Kwon, > > we are supposed to meet on Saturday(21/10) and Sunday (22/10) > before the MPEG meeting in La Baule. > > Can we say something like: > Saturday from 14 to 2000 > Sunday from 0900 to 1800 > Or only the Sunday from 0900 to 1800 > > comments > > regards > _________________________________________ > > 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 Thu Sep 14 02:34:41 2000 From rem-conf-request@es.net Thu Sep 14 02:34:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZVO7-0005I4-00; Thu, 14 Sep 2000 02:32:59 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZVO3-0005GI-00; Thu, 14 Sep 2000 02:32:55 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39BFD3EC000190F8 for rem-conf@es.net; Thu, 14 Sep 2000 11:30:07 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39BF3DC400039BC6 for rem-conf@es.net; Thu, 14 Sep 2000 11:29:24 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Thu, 14 Sep 2000 11:28:52 +0200 (Paris, Madrid (heure d't)) X-Internal-ID: 39ACAAB700009558 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, 14 Sep 2000 11:32:00 +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 379; Thu, 14 Sep 2000 11:17:35 +0200 Message-ID: <39C09A8F.C2968411@thomcast.thomson-csf.com> Date: Thu, 14 Sep 2000 11:29:52 +0200 From: "Pierre Clement" <pierre.clement@thomcast.thomson-csf.com> X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: fpabot@matra-lhpc.ens-lyon.fr CC: CURET Dominique FTRD/DMI/REN <dominique.curet@rd.francetelecom.fr> , 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Pre-MPEG meeting for the '4onIP' AHG References: <200009131830.UAA21099@fwm1.matra-ms2i.fr> <39C097E6.6452FD4F@matra-ms2i.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-Printable X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1241 Lines: 49 Dominique, I will attend as well Pierre Frederic Pabot a =E9crit : > Dear Dominique, all, > > We would also be happy to participate to this 4onIP AHG meeting. > Please let me know how to procede. > > Best regards, > F. Pabot > > CURET Dominique FTRD/DMI/REN a =E9crit : > > > > Dear all, dear Young-Kwon, > > > > we are supposed to meet on Saturday(21/10) and Sunday (22/10) > > before the MPEG meeting in La Baule. > > > > Can we say something like: > > Saturday from 14 to 2000 > > Sunday from 0900 to 1800 > > Or only the Sunday from 0900 to 1800 > > > > comments > > > > regards > > _________________________________________ > > > 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 > > _________________________________________ > > -- > Frederic PABOT > SYCOMORE A=E9rospatiale Matra, Division Multimedia, FRANCE > ENS-Lyon L.H.P.C. voice : +33 4 72 72 82 30 > 46 allee d'Italie fax : +33 4 72 72 04 67 > F-69364 Lyon Cedex 07 mailto:fpabot@matra-ms2i.fr From rem-conf Thu Sep 14 03:35:01 2000 From rem-conf-request@es.net Thu Sep 14 03:35:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZWIh-0006w3-00; Thu, 14 Sep 2000 03:31:27 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZWIf-0006vt-00; Thu, 14 Sep 2000 03:31:25 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA09731; Thu, 14 Sep 2000 12:31:21 +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 xma009670; Thu, 14 Sep 00 12:31:24 +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 MAA03300; Thu, 14 Sep 2000 12:29:28 +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 MAA00826; Thu, 14 Sep 2000 12:29:28 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014074476; Thu, 14 Sep 2000 12:30:32 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: <rem-conf@es.net> Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats Message-ID: <0056890014074476000002L962*@MHS> Date: Thu, 14 Sep 2000 12:30:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 12:27:53" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2898 Lines: 90 Dear all, As promised in a previous email, I would like to review the problems associated with making the proposal of Kikuchi-san a subset of the set = of generic formats that hopefully will be produced in La Baule. My assumpt= ion is that there will be "generic formats" for several MPEG-4 streams, suc= h as: - MPEG-4 audio elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 video elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 system streams For now, I would like to constrain the discussion to the first two, as = these two are also addressed in the proposal of Kikuchi-san. In the following= review I make a separation between video specific issues and audio spec= ific issues. The general issue of the additional bytes is discussed extensiv= ely and I don't think there is a need to recap that here. The only clarific= ation that may be useful in this context is that the additional bytes can be = used to carry the remainder of an SL header in cases where needed, thereby providing the same functionality as in the proposal of Civanlar et al. Video specific issues My proposal would be to use for the generic MPEG-4 video ES format exac= tly the same payload type and names as Kikuchi-san. I also suggest to use t= he same fragmentation rules. So from my perspective no need to change anyt= hing specific to that. Audio specific issues Also for the generic MPEG-4 audio ES format I suggest to use the same payload type, names and fragmentation rules as Kikuchi-san. With audio = we have the "LATM problem". However, with some pragmatism we may be able t= o solve this. In Paris we agreed to allow for more than one access unit w= ithin one SL packet. We could slightly modify this by allowing LATM as multip= lex structure within SL. (Note that the FlexMux provides a multiplex struct= ure on top of SL.) To indicate usage of LATM within an SL packet a currentl= y reserved bit in the SL header could be assigned. If we agree on his, th= en the important question is whether we need also define carriage of MPEG-= 4 audio ES over IP without LATM. Perhaps not. LATM adds only little overh= ead in case of a single large AU and for a small AU it is likely that LATM = is applied anyhow. A final remark on this issue: LATM is also used for car= riage of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LA= TM within SL and for transport over IP. Along these lines I will propose specific wording changes to the propos= al of Kikuchi-san. Please comment if you disagree with the approach described= . I hope that my proposal for usage of LATM is not too big of a shock. In m= y view it is an acceptable price to pay for compatibility with the propos= al >from Kikuchi-san. And I believe such compatibility is important for the= success of MPEG-4 on the market place. Best regards, Jan = From rem-conf Thu Sep 14 05:15:04 2000 From rem-conf-request@es.net Thu Sep 14 05:15:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZXsE-00015E-00; Thu, 14 Sep 2000 05:12:14 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZXs8-000154-00; Thu, 14 Sep 2000 05:12:08 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id PAA16312; Thu, 14 Sep 2000 15:11:49 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 15:11:59 +0200 Message-ID: <01C01E5E.20E65920.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "rem-conf@es.net" <rem-conf@es.net> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Date: Thu, 14 Sep 2000 15:11:58 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5638 Lines: 125 Dear Jan, all, Even after we talked I wasn't convinced to agree to your approach. The main thing is that you are talking about upgrading the Kikuchi-san proposal, while I see no reason to do it. Specifically, I cannot think if any in-band info I would like to add in the future to a stream that is delivered by the ES format. Theoretically crazy ideas can always come up, but practically the chances for this are not more than for any content carried over RTP. And other payload formats didn't care about such extensions. It seems that all the fancy enhancements that you, and Sam, and actually also me and most people in MPEG want to have will be done through addition of extra streams on top of the audio/video streams for which the Kikuchi-san proposal works well. Therefore I see no reason to change the Kikuchi-san proposal, as long as future applications will be able to smoothly integrate streams using this format and the generic format, which is indeed seems the situation. Some other comments regarding your proposal: 1. The Generic payload format is for every MPEG-4 stream, including audio. You seem to restrict the use of this format by requiring that whenever audio is transmitted, the format cannot be used natively and LATM must be used. I don't see a point and this restriction. LATM is for systems that don't use MPEG-4 Systems. If an MPEG-4 server doesn't care about compatibility with other systems why should we force it? Same argument for video fragmentation. 2. Just like we made the ES proposal for video a subset of the Generic format from MPEG-4/SL point of view, we can do that for audio, by allowing (NOT requiring) LATM as an MPEG-4 stream. You want do indicate that in a bit in the SL header, which I find no reason for. We need this indication just once per stream. It can be in the SLConfig, but since LATM is only for audio, it's a kind of format that should be indicated in the DecoderConfigDescriptor. Maybe in objectTypeIndication. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Thursday, September 14, 2000 12:31 PM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats Dear all, As promised in a previous email, I would like to review the problems associated with making the proposal of Kikuchi-san a subset of the set of generic formats that hopefully will be produced in La Baule. My assumption is that there will be "generic formats" for several MPEG-4 streams, such as: - MPEG-4 audio elementary streams (allowing for carriage of the remainder of an SL header) - MPEG-4 video elementary streams (allowing for carriage of the remainder of an SL header) - MPEG-4 system streams For now, I would like to constrain the discussion to the first two, as these two are also addressed in the proposal of Kikuchi-san. In the following review I make a separation between video specific issues and audio specific issues. The general issue of the additional bytes is discussed extensively and I don't think there is a need to recap that here. The only clarification that may be useful in this context is that the additional bytes can be used to carry the remainder of an SL header in cases where needed, thereby providing the same functionality as in the proposal of Civanlar et al. Video specific issues My proposal would be to use for the generic MPEG-4 video ES format exactly the same payload type and names as Kikuchi-san. I also suggest to use the same fragmentation rules. So from my perspective no need to change anything specific to that. Audio specific issues Also for the generic MPEG-4 audio ES format I suggest to use the same payload type, names and fragmentation rules as Kikuchi-san. With audio we have the "LATM problem". However, with some pragmatism we may be able to solve this. In Paris we agreed to allow for more than one access unit within one SL packet. We could slightly modify this by allowing LATM as multiplex structure within SL. (Note that the FlexMux provides a multiplex structure on top of SL.) To indicate usage of LATM within an SL packet a currently reserved bit in the SL header could be assigned. If we agree on his, then the important question is whether we need also define carriage of MPEG-4 audio ES over IP without LATM. Perhaps not. LATM adds only little overhead in case of a single large AU and for a small AU it is likely that LATM is applied anyhow. A final remark on this issue: LATM is also used for carriage of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LATM within SL and for transport over IP. Along these lines I will propose specific wording changes to the proposal of Kikuchi-san. Please comment if you disagree with the approach described. I hope that my proposal for usage of LATM is not too big of a shock. In my view it is an acceptable price to pay for compatibility with the proposal >from Kikuchi-san. And I believe such compatibility is important for the success of MPEG-4 on the market place. Best regards, Jan From rem-conf Thu Sep 14 05:27:08 2000 From rem-conf-request@es.net Thu Sep 14 05:27:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZY5q-0001z4-00; Thu, 14 Sep 2000 05:26:18 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZY5o-0001yn-00; Thu, 14 Sep 2000 05:26: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 <0G0V007I2MH4QJ@ss3000e.cselt.it> for rem-conf@es.net; Thu, 14 Sep 2000 14:24:40 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <R0JLH8QC>; Thu, 14 Sep 2000 14:26:45 +0200 Content-return: allowed Date: Thu, 14 Sep 2000 14:24:55 +0200 From: Franceschini Guido <Guido.Franceschini@CSELT.IT> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats To: 4on2andIP-sys@advent.ee.columbia.edu, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net Message-id: <85077463E51D6A498C453073E1677940034ECE@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4942 Lines: 113 Dear Jan, I am not really happy to signal LATM usage (which is an audio specific tool) at the SL level (which is generic). I would prefer to expand the audio specific configuration parameters. Also, I think that while compatibility at the level of RTP packets is reachable (e.g. by means of the extra byte), the real technical difficulty resides in the control plane. Once somebody finds a solution for the control plane issues, then maybe we will find more than one possible approach for the data plane. The usage of one extra byte (thus a payload header) in all RTP packets is a possible technical solution, but also the usage of an indicator at config time telling whether such extra byte (thus a payload header) is present or not in the RTP packets could be considered (this way you would not force the extra byte all the time). And maybe there are more solutions. To conclude: I would not assert that the ONLY way to fulfill your requirement is to force one extra byte all the time. I understand and agree with the requirement, but personally don't like the proposed solution. I would appreciate some more investigation in the control plane aspects. Also, let's remember that the SDP and the MPEG-4 Object Descriptors serve two very similar purposes. In IETF current practice, the 'negotiation' is mostly done using SDP, while when using MPEG-4 Systems it is done through ODs. A solution aiming at serving with the same bits of information devices compliant to the IETF current practice as well as devices compliant to MPEG-4 Systems MUST consider the overlap between SDP and ODs. IMHO, we can start this work, but we cannot rush it. And this work would involve the MMUSIC group. Regards Guido > ---------- > From: jan.vandermeer@philips.com[SMTP:jan.vandermeer@philips.com] > Sent: Thursday, September 14, 2000 12:30 PM > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats > > Dear all, > > As promised in a previous email, I would like to review the problems > associated with making the proposal of Kikuchi-san a subset of the set of > generic formats that hopefully will be produced in La Baule. My assumption > is that there will be "generic formats" for several MPEG-4 streams, such > as: > - MPEG-4 audio elementary streams (allowing for carriage of the remainder > of > an SL header) > - MPEG-4 video elementary streams (allowing for carriage of the remainder > of > an SL header) > - MPEG-4 system streams > For now, I would like to constrain the discussion to the first two, as > these > two are also addressed in the proposal of Kikuchi-san. In the following > review I make a separation between video specific issues and audio > specific > issues. The general issue of the additional bytes is discussed extensively > and I don't think there is a need to recap that here. The only > clarification > that may be useful in this context is that the additional bytes can be > used > to carry the remainder of an SL header in cases where needed, thereby > providing the same functionality as in the proposal of Civanlar et al. > > Video specific issues > > My proposal would be to use for the generic MPEG-4 video ES format exactly > the same payload type and names as Kikuchi-san. I also suggest to use the > same fragmentation rules. So from my perspective no need to change > anything > specific to that. > > Audio specific issues > > Also for the generic MPEG-4 audio ES format I suggest to use the same > payload type, names and fragmentation rules as Kikuchi-san. With audio we > have the "LATM problem". However, with some pragmatism we may be able to > solve this. In Paris we agreed to allow for more than one access unit > within > one SL packet. We could slightly modify this by allowing LATM as multiplex > structure within SL. (Note that the FlexMux provides a multiplex structure > on top of SL.) To indicate usage of LATM within an SL packet a currently > reserved bit in the SL header could be assigned. If we agree on his, then > the important question is whether we need also define carriage of MPEG-4 > audio ES over IP without LATM. Perhaps not. LATM adds only little overhead > in case of a single large AU and for a small AU it is likely that LATM is > applied anyhow. A final remark on this issue: LATM is also used for > carriage > of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LATM > within SL and for transport over IP. > > Along these lines I will propose specific wording changes to the proposal > of > Kikuchi-san. Please comment if you disagree with the approach described. I > hope that my proposal for usage of LATM is not too big of a shock. In my > view it is an acceptable price to pay for compatibility with the proposal > from Kikuchi-san. And I believe such compatibility is important for the > success of MPEG-4 on the market place. > > Best regards, > > Jan > > From rem-conf Thu Sep 14 05:43:14 2000 From rem-conf-request@es.net Thu Sep 14 05:43:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZYLM-00034t-00; Thu, 14 Sep 2000 05:42:20 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZYLK-00034L-00; Thu, 14 Sep 2000 05:42:18 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA23783; Thu, 14 Sep 2000 11:52: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 xma023779; Thu, 14 Sep 00 11:52:55 +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 LAA16407; Thu, 14 Sep 2000 11:52:54 +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 LAA18031; Thu, 14 Sep 2000 11:52:54 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014073139; Thu, 14 Sep 2000 11:53:58 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: <rem-conf@es.net> Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats Message-ID: <0056890014073139000002L992*@MHS> Date: Thu, 14 Sep 2000 11:53:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 11:51:18" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2898 Lines: 90 Dear all, As promised in a previous email, I would like to review the problems associated with making the proposal of Kikuchi-san a subset of the set = of generic formats that hopefully will be produced in La Baule. My assumpt= ion is that there will be "generic formats" for several MPEG-4 streams, suc= h as: - MPEG-4 audio elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 video elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 system streams For now, I would like to constrain the discussion to the first two, as = these two are also addressed in the proposal of Kikuchi-san. In the following= review I make a separation between video specific issues and audio spec= ific issues. The general issue of the additional bytes is discussed extensiv= ely and I don't think there is a need to recap that here. The only clarific= ation that may be useful in this context is that the additional bytes can be = used to carry the remainder of an SL header in cases where needed, thereby providing the same functionality as in the proposal of Civanlar et al. Video specific issues My proposal would be to use for the generic MPEG-4 video ES format exac= tly the same payload type and names as Kikuchi-san. I also suggest to use t= he same fragmentation rules. So from my perspective no need to change anyt= hing specific to that. Audio specific issues Also for the generic MPEG-4 audio ES format I suggest to use the same payload type, names and fragmentation rules as Kikuchi-san. With audio = we have the "LATM problem". However, with some pragmatism we may be able t= o solve this. In Paris we agreed to allow for more than one access unit w= ithin one SL packet. We could slightly modify this by allowing LATM as multip= lex structure within SL. (Note that the FlexMux provides a multiplex struct= ure on top of SL.) To indicate usage of LATM within an SL packet a currentl= y reserved bit in the SL header could be assigned. If we agree on his, th= en the important question is whether we need also define carriage of MPEG-= 4 audio ES over IP without LATM. Perhaps not. LATM adds only little overh= ead in case of a single large AU and for a small AU it is likely that LATM = is applied anyhow. A final remark on this issue: LATM is also used for car= riage of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LA= TM within SL and for transport over IP. Along these lines I will propose specific wording changes to the propos= al of Kikuchi-san. Please comment if you disagree with the approach described= . I hope that my proposal for usage of LATM is not too big of a shock. In m= y view it is an acceptable price to pay for compatibility with the propos= al >from Kikuchi-san. And I believe such compatibility is important for the= success of MPEG-4 on the market place. Best regards, Jan = From rem-conf Thu Sep 14 05:43:14 2000 From rem-conf-request@es.net Thu Sep 14 05:43:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZYLJ-00034V-00; Thu, 14 Sep 2000 05:42:17 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZYLI-00034L-00; Thu, 14 Sep 2000 05:42:16 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA27838; Thu, 14 Sep 2000 12:02: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 xma027836; Thu, 14 Sep 00 12:02: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 MAA21454; Thu, 14 Sep 2000 12:02:05 +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 MAA21859; Thu, 14 Sep 2000 12:02:04 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014073526; Thu, 14 Sep 2000 12:03:08 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: <rem-conf@es.net> Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats Message-ID: <0056890014073526000002L962*@MHS> Date: Thu, 14 Sep 2000 12:03:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 11:59:41" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2898 Lines: 90 Dear all, As promised in a previous email, I would like to review the problems associated with making the proposal of Kikuchi-san a subset of the set = of generic formats that hopefully will be produced in La Baule. My assumpt= ion is that there will be "generic formats" for several MPEG-4 streams, suc= h as: - MPEG-4 audio elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 video elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 system streams For now, I would like to constrain the discussion to the first two, as = these two are also addressed in the proposal of Kikuchi-san. In the following= review I make a separation between video specific issues and audio spec= ific issues. The general issue of the additional bytes is discussed extensiv= ely and I don't think there is a need to recap that here. The only clarific= ation that may be useful in this context is that the additional bytes can be = used to carry the remainder of an SL header in cases where needed, thereby providing the same functionality as in the proposal of Civanlar et al. Video specific issues My proposal would be to use for the generic MPEG-4 video ES format exac= tly the same payload type and names as Kikuchi-san. I also suggest to use t= he same fragmentation rules. So from my perspective no need to change anyt= hing specific to that. Audio specific issues Also for the generic MPEG-4 audio ES format I suggest to use the same payload type, names and fragmentation rules as Kikuchi-san. With audio = we have the "LATM problem". However, with some pragmatism we may be able t= o solve this. In Paris we agreed to allow for more than one access unit w= ithin one SL packet. We could slightly modify this by allowing LATM as multip= lex structure within SL. (Note that the FlexMux provides a multiplex struct= ure on top of SL.) To indicate usage of LATM within an SL packet a currentl= y reserved bit in the SL header could be assigned. If we agree on his, th= en the important question is whether we need also define carriage of MPEG-= 4 audio ES over IP without LATM. Perhaps not. LATM adds only little overh= ead in case of a single large AU and for a small AU it is likely that LATM = is applied anyhow. A final remark on this issue: LATM is also used for car= riage of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LA= TM within SL and for transport over IP. Along these lines I will propose specific wording changes to the propos= al of Kikuchi-san. Please comment if you disagree with the approach described= . I hope that my proposal for usage of LATM is not too big of a shock. In m= y view it is an acceptable price to pay for compatibility with the propos= al >from Kikuchi-san. And I believe such compatibility is important for the= success of MPEG-4 on the market place. Best regards, Jan = From rem-conf Thu Sep 14 05:52:03 2000 From rem-conf-request@es.net Thu Sep 14 05:52:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZYU6-00052b-00; Thu, 14 Sep 2000 05:51:22 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZYU4-00052K-00; Thu, 14 Sep 2000 05:51:20 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA23490; Thu, 14 Sep 2000 11:51:58 +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 xma023488; Thu, 14 Sep 00 11:51:58 +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 LAA15967; Thu, 14 Sep 2000 11:51:58 +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 LAA17796; Thu, 14 Sep 2000 11:51:56 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014073093; Thu, 14 Sep 2000 11:53:01 +0200 To: <csp@east.isi.edu> Cc: <4on2andIP-sys@advent.ee.columbia.edu>, <rem-conf@es.net> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014073093000002L932*@MHS> Date: Thu, 14 Sep 2000 11:53:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 11:50:04" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1995 Lines: 65 Colin, all, I am happy to take the challenge. My objective will be to produce a mod= ified Kikuchi proposal that can be agreed upon as a subset of the generic for= mat. I will propose explicit wording changes, but first I would like to revi= ew the problems to be solved. I will come back on both in separate emails today. Regards, Jan -----Original Message----- From: csp@east.isi.edu [mailto:csp@east.isi.edu] Sent: donderdag, 14 september, 2000 02:27 To: Jan vanderMeer Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call --> jan.vandermeer@philips.com writes: >I would like to put the problem in a little bit wider perspective. Sev= eral >people perfectly understand the problem while some (?) others don't ye= t >understand the problem, while suggesting that we are wasting our time = with >useless discussions. As Ajay stated correctly, it is the responsibilit= y of >IETF to decide how to proceed with the current MPEG-4 ES proposal. The= only >thing we can say right now is that several (perhaps even well respecte= d) >MPEG members have substantial comments on the current proposal. As a >consequence it is likely that MPEG (members) will submit another propo= sal >for carriage of MPEG-4 ES to IETF. Though this proposal is expected to= have >a high level of overlap with the current one, it is slightly different= . IETF >may wish to take this into account when coming to a decision. We look forward to your proposal, however note that due to interactions= with the ITU (who which to use MPEG-4 ES as part of the next version of= H.323) you need to produce this as an internet draft within the next fe= w days or else we will be unable to consider it. As an alternative, you may wish to propose explicit wording changes to the Kikuchi-san proposal to bring it into line with your ideas. This discussion may reach closure faster if we have a more concrete design. Colin = From rem-conf Thu Sep 14 07:04:18 2000 From rem-conf-request@es.net Thu Sep 14 07:04:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZZZo-0006is-00; Thu, 14 Sep 2000 07:01:20 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZZZn-0006i2-00; Thu, 14 Sep 2000 07:01:19 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA03058; Thu, 14 Sep 2000 16:01: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 xma003056; Thu, 14 Sep 00 16:01: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 QAA27004; Thu, 14 Sep 2000 16:01:16 +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 QAA23672; Thu, 14 Sep 2000 16:01:16 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014083250; Thu, 14 Sep 2000 16:02:20 +0200 To: <csp@east.isi.edu>, <zvil@csi.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014083250000002L902*@MHS> Date: Thu, 14 Sep 2000 16:02:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 15:59:34" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 4243 Lines: 126 Hello Zvi, I am glad we came to technical understanding. In your email you ask man= y questions, some of which I think are answered in the email I sent meanw= hile on Kikuchi-san's proposal as a subset of the generic format. Is that ri= ght ? Perhaps we could continue our discussion within the "generic context". Kind regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: donderdag, 14 september, 2000 09:52 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call [jan.vandermeer@philips.com:] 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic specification" defines the use of exactly_the_same payload type as defi= ned in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation fi= eld. [Reply:] If I understand you right, you seem to suggest what I asked you about f= ew emails ago. To define one payload format, with an empty extension, and later to define the content of the extension. Same payload format, same= name. Well, if this is your meaning at least I can understand what you = want to do technically. Theoretically this can work, as it solves the proble= m of old devices having to recognize new name. [Over night I thought about another scenario which solves the old-device-new-name issue, and planned to ask you (and Sam) if this was= your scenario. This is when streams are broadcast but session descripti= on is interactively negotiated point-to-point. Then, assuming a stream is broadcast in the "new" format and a client starts negotiation to locate= this stream, the server asks the client what formats it recognizes. If = the client says the new format is OK, the server tells it the truth that th= is is in the new format. But if the client says it knows only the "old" format, the server bluffs and tells this is the old format]. Still, I don't believe this can work. I think also Colin said that. Fir= st, I believe this is against the IETF practice. Then, the Generic format differs from the ES format in much more than just the extension content= . The ES format uses LATM. The Generic format is not only for audio/video= elementary streams. The ES format defines fragmentation rules, which in= the Generic format are configured by the SLConfig. The evolution that one n= eeds to reach the other is Darwinian and might take 2 billion years... The m= ain question is, assuming old devices can peacefully skip the extension fie= ld, how do we guarantee that they correctly handle the content beyond? And, again, I don't see why we need it. If a stream that is delivered w= ith the ES format can be played and synchronized, why would you ever want t= o put something in its adaptation field? What kind of extra SL info do yo= u think can enhance it? The only thing I can think of is combining it wit= h other streams that require the Generic format, but this is possible wit= hout touching the stream. ---- at this point I'm getting a phone call from Jan :-)............ --- (20 minutes later).. OK, we clarified between us few more things. At le= ast we better understand now the disagreement... I'll send my message is as= and let Jan continue... Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 = From rem-conf Thu Sep 14 07:44:02 2000 From rem-conf-request@es.net Thu Sep 14 07:44:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZaD3-0000MC-00; Thu, 14 Sep 2000 07:41:53 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZaD2-0000M0-00; Thu, 14 Sep 2000 07:41:52 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA28950; Thu, 14 Sep 2000 16:41:50 +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 xma028947; Thu, 14 Sep 00 16:41:50 +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 QAA17612; Thu, 14 Sep 2000 16:41:50 +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 QAA07066; Thu, 14 Sep 2000 16:41:49 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014084898; Thu, 14 Sep 2000 16:42:54 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu>, <zvil@csi.com> Cc: <rem-conf@es.net> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Message-ID: <0056890014084898000002L982*@MHS> Date: Thu, 14 Sep 2000 16:42:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 16:40:22" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6822 Lines: 207 Zvil, I fully agree that signaling at OD level is a better solution. With res= pect to migration towards other solutions, I think that it is better to have= one simple and straightforward solution for carriage of MPEG-4 A/V ES over = IP then the situation in which "you have many standards to choose from". Specifically in case of thin clients. With respect to audio, the reason of my suggestion to always use LATM i= s to achieve a single solution for audio. I believe that this is often usefu= l, while the pain in terms of overhead and processing is very acceptable. Regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: donderdag, 14 september, 2000 14:15 To: 4on2andIP-sys@advent.ee.columbia.edu; Jan vanderMeer Cc: rem-conf@es.net Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Dear Jan, all, Even after we talked I wasn't convinced to agree to your approach. The = main thing is that you are talking about upgrading the Kikuchi-san proposal,= while I see no reason to do it. Specifically, I cannot think if any in-= band info I would like to add in the future to a stream that is delivered by= the ES format. Theoretically crazy ideas can always come up, but practicall= y the chances for this are not more than for any content carried over RTP= . And other payload formats didn't care about such extensions. It seems t= hat all the fancy enhancements that you, and Sam, and actually also me and = most people in MPEG want to have will be done through addition of extra stre= ams on top of the audio/video streams for which the Kikuchi-san proposal wo= rks well. Therefore I see no reason to change the Kikuchi-san proposal, as long a= s future applications will be able to smoothly integrate streams using th= is format and the generic format, which is indeed seems the situation. Some other comments regarding your proposal: 1. The Generic payload format is for every MPEG-4 stream, including aud= io. You seem to restrict the use of this format by requiring that whenever audio is transmitted, the format cannot be used natively and LATM must = be used. I don't see a point and this restriction. LATM is for systems tha= t don't use MPEG-4 Systems. If an MPEG-4 server doesn't care about compatibility with other systems why should we force it? Same argument = for video fragmentation. 2. Just like we made the ES proposal for video a subset of the Generic format from MPEG-4/SL point of view, we can do that for audio, by allow= ing (NOT requiring) LATM as an MPEG-4 stream. You want do indicate that in = a bit in the SL header, which I find no reason for. We need this indicati= on just once per stream. It can be in the SLConfig, but since LATM is only= for audio, it's a kind of format that should be indicated in the DecoderConfigDescriptor. Maybe in objectTypeIndication. Regards, 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Thursday, September 14, 2000 12:31 PM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats Dear all, As promised in a previous email, I would like to review the problems associated with making the proposal of Kikuchi-san a subset of the set = of generic formats that hopefully will be produced in La Baule. My assumpt= ion is that there will be "generic formats" for several MPEG-4 streams, suc= h as: - MPEG-4 audio elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 video elementary streams (allowing for carriage of the remaind= er of an SL header) - MPEG-4 system streams For now, I would like to constrain the discussion to the first two, as these two are also addressed in the proposal of Kikuchi-san. In the following= review I make a separation between video specific issues and audio spec= ific issues. The general issue of the additional bytes is discussed extensiv= ely and I don't think there is a need to recap that here. The only clarification that may be useful in this context is that the additional bytes can be = used to carry the remainder of an SL header in cases where needed, thereby providing the same functionality as in the proposal of Civanlar et al. Video specific issues My proposal would be to use for the generic MPEG-4 video ES format exac= tly the same payload type and names as Kikuchi-san. I also suggest to use t= he same fragmentation rules. So from my perspective no need to change anyt= hing specific to that. Audio specific issues Also for the generic MPEG-4 audio ES format I suggest to use the same payload type, names and fragmentation rules as Kikuchi-san. With audio = we have the "LATM problem". However, with some pragmatism we may be able t= o solve this. In Paris we agreed to allow for more than one access unit within one SL packet. We could slightly modify this by allowing LATM as multip= lex structure within SL. (Note that the FlexMux provides a multiplex struct= ure on top of SL.) To indicate usage of LATM within an SL packet a currentl= y reserved bit in the SL header could be assigned. If we agree on his, th= en the important question is whether we need also define carriage of MPEG-= 4 audio ES over IP without LATM. Perhaps not. LATM adds only little overh= ead in case of a single large AU and for a small AU it is likely that LATM = is applied anyhow. A final remark on this issue: LATM is also used for carriage of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LA= TM within SL and for transport over IP. Along these lines I will propose specific wording changes to the propos= al of Kikuchi-san. Please comment if you disagree with the approach described= . I hope that my proposal for usage of LATM is not too big of a shock. In m= y view it is an acceptable price to pay for compatibility with the propos= al >from Kikuchi-san. And I believe such compatibility is important for the= success of MPEG-4 on the market place. Best regards, Jan = From rem-conf Thu Sep 14 08:01:27 2000 From rem-conf-request@es.net Thu Sep 14 08:01:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZaUR-0001Ks-00; Thu, 14 Sep 2000 07:59:51 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZaUO-0001Ki-00; Thu, 14 Sep 2000 07:59:49 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id RAA14374; Thu, 14 Sep 2000 17:59:18 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 17:59:25 +0200 Message-ID: <01C01E75.85086260.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "rem-conf@es.net" <rem-conf@es.net> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Date: Thu, 14 Sep 2000 17:59:24 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1265 Lines: 42 [jan.vandermeer@philips.com:] I fully agree that signaling at OD level is a better solution. With respect to migration towards other solutions, I think that it is better to have one simple and straightforward solution for carriage of MPEG-4 A/V ES over IP [Reply:] But you want to further complicate the solution that we already have, simple or not.. [Original message:] then the situation in which "you have many standards to choose from". [Reply:] There is something in between - the standard that best fits to every case. [Original message:] With respect to audio, the reason of my suggestion to always use LATM is to achieve a single solution for audio. [Reply:] And what is the reason to achieve a single solution for audio? z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 14 08:01:27 2000 From rem-conf-request@es.net Thu Sep 14 08:01:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZaUy-0001LU-00; Thu, 14 Sep 2000 08:00:24 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZaUx-0001LK-00; Thu, 14 Sep 2000 08:00:23 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA07055; Thu, 14 Sep 2000 17:00:21 +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 xma007053; Thu, 14 Sep 00 17:00:21 +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 RAA25970; Thu, 14 Sep 2000 17:00:21 +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 RAA12555; Thu, 14 Sep 2000 17:00:21 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014085532; Thu, 14 Sep 2000 17:01:25 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu>, <Guido.Franceschini@CSELT.IT> Cc: <rem-conf@es.net> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Message-ID: <0056890014085532000002L922*@MHS> Date: Thu, 14 Sep 2000 17:01:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 16:58:48" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 6244 Lines: 197 Dear Guido, As also said in my reply to Zvi, I have no problems to remove the signa= ling >from SL level. Zvi and you are right. With respect to a solution in the control plane, that is fine too, as l= ong as it is required that clients MUST support both cases (with and withou= t the additional bytes). I agree with your analysis that such solution may be= more elegant; however, taking more time for study is only OK as long as we t= ake into account that the ITU needs their "compatible solution" really fast= . If the "control plane" solution can not be achieved quickly, I propose to = focus on the solution I suggested. Perhaps for me the best thing to do is wait whether there are some more= reactions, possibly also from the US. Tomorrow I have a 12 hr+ flight b= ack >from the Far East and than I may be able to prepare a more detailed solution. To be distributed after late tomorrow, European time. Kind regards, Jan -----Original Message----- From: Guido.Franceschini@CSELT.IT [mailto:Guido.Franceschini@CSELT.IT] Sent: donderdag, 14 september, 2000 14:29 To: Jan vanderMeer; 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats Dear Jan, I am not really happy to signal LATM usage (which is an audio specific = tool) at the SL level (which is generic). I would prefer to expand the audio specific configuration parameters. Also, I think that while compatibility at the level of RTP packets is reachable (e.g. by means of the extra byte), the real technical difficu= lty resides in the control plane. Once somebody finds a solution for the co= ntrol plane issues, then maybe we will find more than one possible approach f= or the data plane. The usage of one extra byte (thus a payload header) in all RTP packets = is a possible technical solution, but also the usage of an indicator at conf= ig time telling whether such extra byte (thus a payload header) is present= or not in the RTP packets could be considered (this way you would not forc= e the extra byte all the time). And maybe there are more solutions. To conclude: I would not assert that the ONLY way to fulfill your requirement is to force one extra byte all the time. I understand and a= gree with the requirement, but personally don't like the proposed solution. = I would appreciate some more investigation in the control plane aspects. Also, let's remember that the SDP and the MPEG-4 Object Descriptors ser= ve two very similar purposes. In IETF current practice, the 'negotiation' = is mostly done using SDP, while when using MPEG-4 Systems it is done throu= gh ODs. A solution aiming at serving with the same bits of information devices compliant to the IETF current practice as well as devices compliant to MPEG-4 Systems MUST consider the overlap between SDP and ODs. IMHO, we can start this work, but we cannot rush it. And this work would involve the MMUSIC group. Regards Guido > ---------- > From: jan.vandermeer@philips.com[SMTP:jan.vandermeer@philips.com] > Sent: Thursday, September 14, 2000 12:30 PM > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats > > Dear all, > > As promised in a previous email, I would like to review the problems > associated with making the proposal of Kikuchi-san a subset of the se= t of > generic formats that hopefully will be produced in La Baule. My assum= ption > is that there will be "generic formats" for several MPEG-4 streams, s= uch > as: > - MPEG-4 audio elementary streams (allowing for carriage of the remai= nder > of > an SL header) > - MPEG-4 video elementary streams (allowing for carriage of the remai= nder > of > an SL header) > - MPEG-4 system streams > For now, I would like to constrain the discussion to the first two, a= s > these > two are also addressed in the proposal of Kikuchi-san. In the followi= ng > review I make a separation between video specific issues and audio > specific > issues. The general issue of the additional bytes is discussed extens= ively > and I don't think there is a need to recap that here. The only > clarification > that may be useful in this context is that the additional bytes can b= e > used > to carry the remainder of an SL header in cases where needed, thereby= > providing the same functionality as in the proposal of Civanlar et al= . > > Video specific issues > > My proposal would be to use for the generic MPEG-4 video ES format ex= actly > the same payload type and names as Kikuchi-san. I also suggest to use= the > same fragmentation rules. So from my perspective no need to change > anything > specific to that. > > Audio specific issues > > Also for the generic MPEG-4 audio ES format I suggest to use the same= > payload type, names and fragmentation rules as Kikuchi-san. With audi= o we > have the "LATM problem". However, with some pragmatism we may be able= to > solve this. In Paris we agreed to allow for more than one access unit= > within > one SL packet. We could slightly modify this by allowing LATM as mult= iplex > structure within SL. (Note that the FlexMux provides a multiplex stru= cture > on top of SL.) To indicate usage of LATM within an SL packet a curren= tly > reserved bit in the SL header could be assigned. If we agree on his, = then > the important question is whether we need also define carriage of MPE= G-4 > audio ES over IP without LATM. Perhaps not. LATM adds only little ove= rhead > in case of a single large AU and for a small AU it is likely that LAT= M is > applied anyhow. A final remark on this issue: LATM is also used for > carriage > of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of = LATM > within SL and for transport over IP. > > Along these lines I will propose specific wording changes to the prop= osal > of > Kikuchi-san. Please comment if you disagree with the approach describ= ed. I > hope that my proposal for usage of LATM is not too big of a shock. In= my > view it is an acceptable price to pay for compatibility with the prop= osal > from Kikuchi-san. And I believe such compatibility is important for t= he > success of MPEG-4 on the market place. > > Best regards, > > Jan > > = From rem-conf Thu Sep 14 08:37:06 2000 From rem-conf-request@es.net Thu Sep 14 08:37:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZayZ-0003NB-00; Thu, 14 Sep 2000 08:30:59 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZayW-0003N1-00; Thu, 14 Sep 2000 08:30:56 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id SAA19864; Thu, 14 Sep 2000 18:30:11 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 18:30:18 +0200 Message-ID: <01C01E79.D5740340.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "csp@east.isi.edu" <csp@east.isi.edu> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 14 Sep 2000 18:30:17 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5258 Lines: 130 Jan, I would welcome continuing the discussion within the "generic" and, moreover, the framework contexts, to make it a superset of the Kikuchi-san proposal (which doesn't need a change ;-). Two suggestions I have in mind right now, on top of the SL configuration issues we discussed in Paris: 1. Precede the extra (in-band) header in the Generic format by a byte indicating its length. This would enable non-MPEG systems to read it. 2. Allowing LATM as valid stream content 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Thursday, September 14, 2000 4:02 PM To: csp@east.isi.edu; zvil@csi.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Hello Zvi, I am glad we came to technical understanding. In your email you ask many questions, some of which I think are answered in the email I sent meanwhile on Kikuchi-san's proposal as a subset of the generic format. Is that right ? Perhaps we could continue our discussion within the "generic context". Kind regards, Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: donderdag, 14 september, 2000 09:52 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call [jan.vandermeer@philips.com:] 2) Define the meaning of the adaptation field in the "generic MPEG-4 specification". For carriage of MPEG-4 ES and MPEG-4 SL streams the "generic specification" defines the use of exactly_the_same payload type as defined in 1). The only difference is the defined use of the adaptation field. Whether or not an SL header is carried is signaled in the adaptation field. [Reply:] If I understand you right, you seem to suggest what I asked you about few emails ago. To define one payload format, with an empty extension, and later to define the content of the extension. Same payload format, same name. Well, if this is your meaning at least I can understand what you want to do technically. Theoretically this can work, as it solves the problem of old devices having to recognize new name. [Over night I thought about another scenario which solves the old-device-new-name issue, and planned to ask you (and Sam) if this was your scenario. This is when streams are broadcast but session description is interactively negotiated point-to-point. Then, assuming a stream is broadcast in the "new" format and a client starts negotiation to locate this stream, the server asks the client what formats it recognizes. If the client says the new format is OK, the server tells it the truth that this is in the new format. But if the client says it knows only the "old" format, the server bluffs and tells this is the old format]. Still, I don't believe this can work. I think also Colin said that. First, I believe this is against the IETF practice. Then, the Generic format differs from the ES format in much more than just the extension content. The ES format uses LATM. The Generic format is not only for audio/video elementary streams. The ES format defines fragmentation rules, which in the Generic format are configured by the SLConfig. The evolution that one needs to reach the other is Darwinian and might take 2 billion years... The main question is, assuming old devices can peacefully skip the extension field, how do we guarantee that they correctly handle the content beyond? And, again, I don't see why we need it. If a stream that is delivered with the ES format can be played and synchronized, why would you ever want to put something in its adaptation field? What kind of extra SL info do you think can enhance it? The only thing I can think of is combining it with other streams that require the Generic format, but this is possible without touching the stream. ---- at this point I'm getting a phone call from Jan :-)............ --- (20 minutes later).. OK, we clarified between us few more things. At least we better understand now the disagreement... I'll send my message is as and let Jan continue... 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 14 08:51:32 2000 From rem-conf-request@es.net Thu Sep 14 08:51:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZbFQ-0004KL-00; Thu, 14 Sep 2000 08:48:24 -0700 Received: from bodhi.zendo.com [205.187.71.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZbFP-0004KB-00; Thu, 14 Sep 2000 08:48:23 -0700 Received: from vandys-pc.zendo.com (dialup-63.214.14.57.Seattle1.Level3.net [63.214.14.57]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8E7QEm12668; Thu, 14 Sep 2000 07:26:16 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00468; Thu, 14 Sep 2000 08:44:29 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009141544.IAA00468@vandys-pc.zendo.com> To: Tmima Koren <tmima@cisco.com> cc: "W. Mark Townsley" <townsley@cisco.com>, brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, gurdeep@microsoft.com, palter@zev.net, l2tp@diameter.org, rem-conf@es.net Subject: Re: 0 byte L2TPHC header and implied PPPMUX In-reply-to: Your message of "Thu, 14 Sep 2000 01:40:08 PDT." <4.3.1.2.20000914010737.01f5b750@omega.cisco.com> Date: Thu, 14 Sep 2000 08:44:29 -0700 From: Andy Valencia <vandys@zendo.com> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1843 Lines: 42 [Tmima Koren <tmima@cisco.com> writes:] >>flag 2: value 1 means all packets have implied P=1 >> value 0 means all packets have implied P=0 I'm concerned with this one. Since L2TPHC is basically useless except for payload, what you've achieved with this flag is to ensure that your control traffic will be interrupted if you *ever* permit all payload traffic to be given preference by choosing P=1. My experience is that this will make your link unworkable. And no, using the UDP side doesn't help, since priority is (and should be) global to the PPP connection. I would suggest that when omitting the L2TPHC header entirely, that P=0 always be the mode of operation. This shouldn't affect your TCRTP mode of operation, because the only thing aside from those payload packets would be control packets which should be given priority anyway (and they can go via UDP). >>When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can > be omitted How about A/C fields? Isn't it a little weird that a field in the middle of the PPP packet is coming and going based on this, but the bytes in front depend on PPP negotiation? Also, why hard-wire it to PPPMUX? Why not include the implicit protocol value, so that these savings could apply to IP-only connections which weren't using PPPMUX and/or TCRTP? >>PPP packets that have a different priority or that are not PPPMUX can still b >e sent in the tunnel using the UDP/L2TP format, same as the L2TP control packe >ts >>TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: t >he tunneling overhead will be reduced by 2 bytes. I guess I'm OK with a 0-byte L2TPHC header option (subject to a nod from the chair). I'd sure like to hear from some people (not just infer something >from silence) on the PPP header aspect. Andy Valencia From rem-conf Thu Sep 14 08:54:41 2000 From rem-conf-request@es.net Thu Sep 14 08:54:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZbKT-0004aF-00; Thu, 14 Sep 2000 08:53:37 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZbKR-0004Zr-00; Thu, 14 Sep 2000 08:53:36 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA23941; Thu, 14 Sep 2000 17:53:32 +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 xma023939; Thu, 14 Sep 00 17:53:32 +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 RAA16451; Thu, 14 Sep 2000 17:53:31 +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 RAA27305; Thu, 14 Sep 2000 17:53:31 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014086766; Thu, 14 Sep 2000 17:54:35 +0200 To: <zvil@csi.com> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Message-ID: <0056890014086766000002L962*@MHS> Date: Thu, 14 Sep 2000 17:54:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/14/00 17:51:51" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 923 Lines: 42 Zvi, We agree to a large extend, with the one exception that you know very w= ell. Kind regards, anyhow. Jan -----Original Message----- From: zvil@csi.com [mailto:zvil@csi.com] Sent: donderdag, 14 september, 2000 17:34 To: csp@east.isi.edu; Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response= to the last call Jan, I would welcome continuing the discussion within the "generic" and, moreover, the framework contexts, to make it a superset of the Kikuchi-= san proposal (which doesn't need a change ;-). Two suggestions I have in mind right now, on top of the SL configuratio= n issues we discussed in Paris: 1. Precede the extra (in-band) header in the Generic format by a byte indicating its length. This would enable non-MPEG systems to read it. 2. Allowing LATM as valid stream content in MPEG-4. Regards, z = From rem-conf Thu Sep 14 10:01:52 2000 From rem-conf-request@es.net Thu Sep 14 10:01:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZcKb-0007KS-00; Thu, 14 Sep 2000 09:57:49 -0700 Received: from isis.lip6.fr [132.227.60.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZcKZ-0007KI-00; Thu, 14 Sep 2000 09:57:48 -0700 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA09079 for <rem-conf@es.net>; Thu, 14 Sep 2000 18:57:46 +0200 Received: from rp.lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id SAA14772 for <rem-conf@es.net>; Thu, 14 Sep 2000 18:57:46 +0200 (MEST) Message-ID: <39C1038A.ED4ED543@rp.lip6.fr> Date: Thu, 14 Sep 2000 18:57:46 +0200 From: Vida Rolland <Rolland.Vida@lip6.fr> Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "rem-conf@es.net" <rem-conf@es.net> Subject: SSM and RTCP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 287 Lines: 15 Hello, I'm new on this mailing list, maybe you've discussed already this subject. If it is the case, i'm sorry. My question is related to the new PIM-SSM protocol. What do you think about a modification of RTP/RTCP in order to work in a PIM-SSM environment? Regards, Rolland Vida From rem-conf Thu Sep 14 10:15:44 2000 From rem-conf-request@es.net Thu Sep 14 10:15:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZcZO-0000Vy-00; Thu, 14 Sep 2000 10:13:06 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZcZM-0000V6-00; Thu, 14 Sep 2000 10:13:05 -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 <0G0V00D3RZRLS9@ss3000e.cselt.it> for rem-conf@es.net; Thu, 14 Sep 2000 19:11:45 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <R0JL2BWM>; Thu, 14 Sep 2000 19:13:50 +0200 Content-return: allowed Date: Thu, 14 Sep 2000 19:12:01 +0200 From: Franceschini Guido <Guido.Franceschini@CSELT.IT> Subject: RE: Kikuchi-san proposal as subset of generic MPEG-4 formats To: 4on2andIP-sys@advent.ee.columbia.edu, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: rem-conf@es.net Message-id: <85077463E51D6A498C453073E1677940034EDB@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 801 Lines: 23 Dear Jan, > With respect to a solution in the control plane, that is fine too, as long > as it is required that clients MUST support both cases (with and without > the > additional bytes). I agree with your analysis that such solution may be > more > elegant; however, taking more time for study is only OK as long as we take > into account that the ITU needs their "compatible solution" really fast. > If > the "control plane" solution can not be achieved quickly, I propose to > focus > on the solution I suggested. The point is I believe that your extra-byte proposal does not work as is, since the 'old' device, in presence of 'new' content, would know from the control plane only that the RTP Payload Format is the 'generic' one, but it would not know what media is being carried. Bye Guido From rem-conf Thu Sep 14 10:21:15 2000 From rem-conf-request@es.net Thu Sep 14 10:21:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZcgJ-0001D4-00; Thu, 14 Sep 2000 10:20:15 -0700 Received: from omega.cisco.com [171.69.63.141] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZcgH-00010w-00; Thu, 14 Sep 2000 10:20:13 -0700 Received: from tmima-homepc.cisco.com (tmima-dsl5.cisco.com [144.254.211.46]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA15944; Thu, 14 Sep 2000 10:14:56 -0700 (PDT) Message-Id: <4.3.1.2.20000914093751.027ac100@omega.cisco.com> X-Sender: tmima@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 14 Sep 2000 10:15:15 -0700 To: Andy Valencia <vandys@zendo.com> From: Tmima Koren <tmima@cisco.com> Subject: Re: 0 byte L2TPHC header and implied PPPMUX Cc: "W. Mark Townsley" <townsley@cisco.com>, brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, gurdeep@microsoft.com, palter@zev.net, tmima@cisco.com, l2tp@diameter.org, rem-conf@es.net In-Reply-To: <200009141544.IAA00468@vandys-pc.zendo.com> References: <Your message of "Thu, 14 Sep 2000 01:40:08 PDT." <4.3.1.2.20000914010737.01f5b750@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2649 Lines: 57 At 08:44 AM 9/14/00 -0700, Andy Valencia wrote: >[Tmima Koren <tmima@cisco.com> writes:] > > >>flag 2: value 1 means all packets have implied P=1 > >> value 0 means all packets have implied P=0 > >I'm concerned with this one. Since L2TPHC is basically useless except for >payload, what you've achieved with this flag is to ensure that your control >traffic will be interrupted if you *ever* permit all payload traffic to be >given preference by choosing P=1. My experience is that this will make your >link unworkable. And no, using the UDP side doesn't help, since priority is >(and should be) global to the PPP connection. > >I would suggest that when omitting the L2TPHC header entirely, that P=0 >always be the mode of operation. This shouldn't affect your TCRTP mode of >operation, because the only thing aside from those payload packets would be >control packets which should be given priority anyway (and they can go via >UDP). In the typical case of a TCRTP tunnel both ends of the tunnel are tied to virtual PPP interfaces. RTP packets arrive to one side, compressed and tunneled to the other side where they are decompressed and routed to their destination. Those RTP packets carry voice and may have certain priority. Those packets should regain their priority when they leave the tunnel. Can this be done with P=0? > >>When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can > > be omitted > >How about A/C fields? Isn't it a little weird that a field in the middle of >the PPP packet is coming and going based on this, but the bytes in front >depend on PPP negotiation? > >Also, why hard-wire it to PPPMUX? Why not include the implicit protocol >value, so that these savings could apply to IP-only connections which >weren't using PPPMUX and/or TCRTP? I thought about this option. The difference is that the PPPMux protocol ID at the head of the packet really acts as a flag to indicate that there is more then one packet in this packet.. but each multiplex carries its own PPP protocol ID. If you think it's ok to generalize for any protocol, I support that. Tmima > >>PPP packets that have a different priority or that are not PPPMUX can still b > >e sent in the tunnel using the UDP/L2TP format, same as the L2TP control packe > >ts > >>TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: t > >he tunneling overhead will be reduced by 2 bytes. > >I guess I'm OK with a 0-byte L2TPHC header option (subject to a nod from the >chair). I'd sure like to hear from some people (not just infer something >from silence) on the PPP header aspect. > >Andy Valencia From rem-conf Thu Sep 14 10:43:03 2000 From rem-conf-request@es.net Thu Sep 14 10:43:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zd1H-0002Nz-00; Thu, 14 Sep 2000 10:41:55 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zd1F-0002Np-00; Thu, 14 Sep 2000 10:41:53 -0700 Received: from Young ([157.197.210.164]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091502424888:48174 ; Fri, 15 Sep 2000 02:42:48 +0900 Message-ID: <000001c01e73$01567710$a4d2c59d@Young> Reply-To: "Young-Kwon LIM" <young@techway.co.kr> From: "Young-Kwon LIM" <young@techway.co.kr> To: <jan.vandermeer@philips.com>, "Colin Perkins" <csp@east.isi.edu> Cc: <stewe@cs.tu-berlin.de>, <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> References: <200009111522.UAA08057@hafez.east.isi.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 15 Sep 2000 01:27:21 +0900 Organization: TechWay 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-09-15 02:42:49 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-15 02:43:12 AM, Serialize complete at 2000-09-15 02:43:12 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 640 Lines: 12 RGVhciBDb2xpbiwgYW5kbCBhbGwNCg0KPiANCj4gSW4gUlRQLCB0aGF0IHBhcmFtZXRlciBpcyB0 aGUgcGF5bG9hZCB0eXBlIGZpZWxkLiANCj4gDQo+IEkgcmVhbGx5IGRvbid0IHVuZGVyc3RhbmQg d2h5IHRoaXMgYWRkaXRpb25hbCBmaWVsZCB3aWxsIGFkZCB2YWx1ZS4gSXQgDQo+IGFsbG93cyBm b3Igc3lzdGVtcyB0byBza2lwIGRhdGEgd2hpY2ggdGhleSBkb24ndCB1bmRlcnN0YW5kLCBob3cg aXMgdGhpcw0KPiBkaWZmZXJlbnQgZnJvbSB1c2luZyB0aGUgcGF5bG9hZCB0eXBlIGZvciB0aGUg c2FtZSBlZmZlY3Q/DQo+IA0KDQpUaGUgbGVuZ3RoIG9mIGFkZGl0aW9uYWwgaGVhZGVyIHdpbGwg YmUgdmFyaWFibGUuIFNvLCB0aGUgZGV2aWNlIHNob3VsZCBrbm93IHRoZSBsZW5ndGggdG8gc2tp cCB0aGUgYWRkaXRpb25hbCBoZWFkZXJzIGl0IGRvZXNuJ3QgdW5kZXJzdGFuZC4NCg0KU2luY2Vy ZWx5LA0KWW91bmcuDQo= From rem-conf Thu Sep 14 10:43:03 2000 From rem-conf-request@es.net Thu Sep 14 10:43:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zd1I-0002OA-00; Thu, 14 Sep 2000 10:41:56 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zd1H-0002Np-00; Thu, 14 Sep 2000 10:41:55 -0700 Received: from Young ([157.197.210.164]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091502425038:48175 ; Fri, 15 Sep 2000 02:42:50 +0900 Message-ID: <000301c01e73$023ba6f0$a4d2c59d@Young> Reply-To: "Young-Kwon LIM" <young@techway.co.kr> From: "Young-Kwon LIM" <young@techway.co.kr> To: "Herpel Carsten" <HerpelC@thmulti.com>, <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> References: <2CEEE9E85750D2119F4000805F3172884C2CAF@hanexch1.hanover.thmulti.com> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 15 Sep 2000 01:29:27 +0900 Organization: TechWay 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-09-15 02:42:51 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-15 02:43:13 AM, Serialize complete at 2000-09-15 02:43:13 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1013 Lines: 17 RGVhciBDYXJzdGVuLCBhbmQgYWxsDQoNCj4gDQo+IE9uZSBhc3N1bXB0aW9uIGlzIHRoYXQgaHVn ZSBudW1iZXJzIG9mIGRldmljZXMgd2lsbCBiZSBvdXQgdGhlcmUgdGhhdCB1c2UNCj4gdGhlIEVT IHBheWxvYWQgZm9ybWF0LiBBc3N1bWluZyB0aGF0IHRoZXNlIGRldmljZXMgY2Fubm90IGJlIHVw Z3JhZGVkIHRvIGENCj4gbmV3ZXIgcGF5bG9hZCBmb3JtYXQhDQo+IFRoZW4gYXBwbGljYXRpb25z IGNvbWUgdXAgd2l0aCBtb3JlIGZ1bmN0aW9uYWxpdHksIHVzaW5nIE1QRUctNCBTeXN0ZW1zLiBO ZXcNCj4gZGV2aWNlcyB3aWxsIGV4aXN0IHRoYXQga25vdyBob3cgdG8gdXNlIHRoaXMgZnVuY3Rp b25hbGl0eS4gT2xkIGRldmljZXMNCj4gc2hvdWxkIGF0IGxlYXN0IGJlIGFibGUgdG8gdW5kZXJz dGFuZCB0aGUgKHVubW9kaWZpZWQhKSBNUEVHLTQgVmlkZW8gb3Zlcg0KPiBSVFAgc3RyZWFtLiBT aW5jZSB0aGUgb2xkIGRldmljZXMgYXJlIG5vdCByZXByb2dyYW1tYWJsZSwgdGhleSBjYW5ub3Qg YmUNCj4gdXBncmFkZWQgdG8gYW5vdGhlciBwYXlsb2FkIGZvcm1hdC4gU28gdGhlIG9sZCBmb3Jt YXQgbmVlZHMgdG8gYmUgYnkgZGVzaWduDQo+IGNvbXBhdGlibGUgdG8gYW55IG5ldyBmb3JtYXQu DQo+IA0KDQpJIGRvIGJlbGl2ZSB0aGF0IHRoaXMgc2NlbmFyaW8gaXMgbW9yZSByZWFsaXN0aWMg YW5kIG1vcmUgdXNlZnVsIHRoYW4gdGhlIHNlY29uZCBjYXNlLg0KDQpTaW5jZXJlbHksDQpZb3Vu Zy4NCg== From rem-conf Thu Sep 14 10:43:03 2000 From rem-conf-request@es.net Thu Sep 14 10:43:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zd1N-0002Oh-00; Thu, 14 Sep 2000 10:42:01 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zd1M-0002Np-00; Thu, 14 Sep 2000 10:42:01 -0700 Received: from Young ([157.197.210.164]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091502425566:48178 ; Fri, 15 Sep 2000 02:42:55 +0900 Message-ID: <000601c01e73$05626260$a4d2c59d@Young> Reply-To: "Young-Kwon LIM" <young@techway.co.kr> From: "Young-Kwon LIM" <young@techway.co.kr> To: "Narasimhan, Sam \(SD-EX\)" <SNarasimhan@gi.com>, "Colin Perkins" <csp@east.isi.edu> Cc: "Kris Huber" <khuber@sorensonlabs.com>, "Luthra, Ajay \(SD-EX\)" <ALuthra@gi.com>, "'Zvi Lifshitz'" <ZviL@optibase.com>, <jan.vandermeer@philips.com>, <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> References: <200009122142.CAA01111@hafez.east.isi.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 15 Sep 2000 02:02:48 +0900 Organization: TechWay 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-09-15 02:42:56 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-15 02:43:19 AM, Serialize complete at 2000-09-15 02:43:19 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1762 Lines: 26 RGVhciBDb2xpbiwNCg0KPiA+DQo+ID5TYW0gLSBJZiB0aGUgcGF5bG9hZCB0eXBlIGlzIGRpZmZl cmVudCBhbmQgdGhlIHBheWxvYWQgZm9ybWF0DQo+ID5pcyBkaWZmZXJlbnQsIHRoZW4gdGhlIHNl bmRlciBoYXMgdG8gc2VuZCAyIGRpZmZlcmVudCBSVFANCj4gPnBhY2tldHMuIFRoaXMgY2FuIGJl IGF2b2lkZWQgaWYgdGhlIGRyYWZ0IGluY2x1ZGVkIHRoZQ0KPiA+aGVhZGVyIGZpZWxkcy4NCj4g DQo+IFNpbmNlIHRoZXkgaW5jbHVkZSBkaWZmZXJlbnQgaW5mb3JtYXRpb24sIGFuZCBzaW5jZSBv bmUgaXMgbm90DQo+IHVuZGVyc3RhbmRhYmxlIGJ5IGNsaWVudHMgb2YgdGhlIG90aGVyLCB0aGlz IHdvdWxkIHNlZW0gdG8gYmUNCj4gYSBnb29kIHRoaW5nIQ0KPiANCg0KSSBkbyBiZWxpdmUgdGhp cyBpcyBhIGdvb2QgdGhpbmcgYW5kIHdlIGhhdmUgdmVyeSBlZmZpY2llbnQgYW5kIG5pY2Ugc29s dXRpb24gd2hpY2ggbWFrZSB0aGlzIGhhcHBlbiBlYXNpbHkuIExvdy1lbmQgZGV2aWNlcyBoYXZp bmcgbGltaXRlZCBjYXBhYmlsaXRpZXMgd2lsbCB1bmRlcnN0YW5kIG9ubHkgdGhlIHBhcnRpYWwg aW5mb3JtYXRpb24gb2YgdGhlIGJpdHN0cmVhbSBidXQgaGlnaC1lbmQsIHBvd2VyZnVsIGRldmlj ZXMgd2lsbCB1bmRlcnN0YW5kIGFsbCB0aGUgaW5mb3JtYXRpb25zIGFuZCBwZXJmb3JtIGJldHRl ciB0aGFuIHRoZSBsb3ctZW5kIG9uZS4NCg0KPiA+DQo+ID5TYW0gLSB0aGV5IGRvIG5vdCBoYXZl IHRvIGJlIHNpZ25hbGVkLiBUaGUgcmVjZWl2ZXIgd2hpY2gNCj4gPnVuZGVyc3RhbmRzIGVuaGFu Y2VtZW50cyB3aWxsIHBhcnNlIHRoZSBpbmZvcm1hdGlvbiBwcmVzZW50DQo+ID5pbiB0aGUgc3Ry ZWFtLiBUaGUgcmVjZWl2ZXIgd2hpY2ggZG9lcyBub3Qgc3VwcG9ydCBlbmhhbmNlbWVudA0KPiA+ d2lsbCAncGFyc2Ugb3ZlcicgdGhlIGVuaGFuY2VtZW50IGluZm9ybWF0aW9uLiANCj4gDQo+IE9m IGNvdXJzZSB0aGV5IGhhdmUgdG8gYmUgc2lnbmFsbGVkIC0gZWxzZSBob3cgZG8gcmVjZWl2ZXJz IGtub3cgDQo+IHdoYXQgc29ydCBvZiBlbmhhbmNlbWVudCBpcyBwcmVzZW50Pw0KPiANCg0KRm9y IHRoZSByZWNlaXZlcnMgdW5kZXJzdGFuZGluZyBlbmhhbmNlbWVudHMsIGNvbmZpZ3VyYXRpb24g aW5mb3JtYXRpb24gdW5kZXJzdGFuZGFibGUgYnkgdGhlIE1QRUctNCBTeXN0ZW0gZW50aXR5IHdp bGwgYmUgc2VudCBhZGRpdGlvbmFsbHkuIEkgdGhpbmsgdGhpcyBpcyB0aGUgc2FtZSB0aGluZyB3 aGVuIHlvdSBzYXkgInNpZ25hbGxlZCIuDQoNClNpbmNlcmVseSwNCllvdW5nLg0K From rem-conf Thu Sep 14 10:43:03 2000 From rem-conf-request@es.net Thu Sep 14 10:43:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zd1K-0002OL-00; Thu, 14 Sep 2000 10:41:58 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zd1J-0002Np-00; Thu, 14 Sep 2000 10:41:57 -0700 Received: from Young ([157.197.210.164]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091502425218:48176 ; Fri, 15 Sep 2000 02:42:52 +0900 Message-ID: <000401c01e73$034b9050$a4d2c59d@Young> Reply-To: "Young-Kwon LIM" <young@techway.co.kr> From: "Young-Kwon LIM" <young@techway.co.kr> To: "Herpel Carsten" <HerpelC@thmulti.com>, "Stephan Wenger" <stewe@cs.tu-berlin.de> Cc: <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> References: <4.3.2.7.2.20000911203651.02cbd2d0@mail.cs.tu-berlin.de> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 15 Sep 2000 01:40:43 +0900 Organization: TechWay 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-09-15 02:42:52 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-15 02:43:15 AM, Serialize complete at 2000-09-15 02:43:15 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 725 Lines: 13 RGVhciBTdGVwaGUgYW5kIGFsbCwNCg0KPiANCj4gVmVyeSBzaW1wbGUgdG8gYWNoaWV2ZS4gIEhh dmUgdHdvIHBheWxvYWQgdHlwZXMsIE1QRUctNC1TTCBhbmQgTVBFRy00LUVTLg0KPiBUcnkgdG8g bmVnb3RpYXRlIE1QRUctNC1TTC4gIElmIHRoZSBvdGhlciBzeXN0ZW0gcmVqZWN0cywgdXNlIE1Q RUctNC1FUy4NCj4gVGhpcyBpcyBob3cgdGhpbmdzIGFyZSBkb25lLCBhdCBsZWFzdCBpbiBILjMy MywgYWxsIHRoZSB0aW1lLg0KPiANCg0KV2l0aCBhZGRpdGlvbmFsIG9uZSBieXRlIGluZGljYXRp bmcgdGhlIGxlbmd0aCBvZiB0aGUgcGF5bG9hZCBoZWFkZXIgYXQgdGhlIGJlZ2lubmluZyBvZiB0 aGUgcGF5bG9hZCwgYml0c3RyZWFtIGZvciBNUEVHLTQgU0wgY2FuIGJlIGNvbXN1bWVkIGJ5IHRo ZSBkZXZpY2Ugb25seSBzdXBwb3J0aW5nIE1QRUctNCBFUyB3aXRob3V0IGFueSBtb2RpZmljYXRp b24uIFRoaXMgaXMgb25lIG9mIHRoZSBhZHZhbnRhZ2VzIHVzaW5nIHRoaXMgYnl0ZS4NCg0KU2lu Y2VyZWx5LA0KWW91bmcuDQoNCg== From rem-conf Thu Sep 14 10:43:04 2000 From rem-conf-request@es.net Thu Sep 14 10:43:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zd1M-0002OW-00; Thu, 14 Sep 2000 10:42:00 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zd1K-0002Np-00; Thu, 14 Sep 2000 10:41:59 -0700 Received: from Young ([157.197.210.164]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091502425380:48177 ; Fri, 15 Sep 2000 02:42:53 +0900 Message-ID: <000501c01e73$0444bd60$a4d2c59d@Young> Reply-To: "Young-Kwon LIM" <young@techway.co.kr> From: "Young-Kwon LIM" <young@techway.co.kr> To: "Narasimhan, Sam \(SD-EX\)" <SNarasimhan@gi.com>, "Colin Perkins" <csp@east.isi.edu> Cc: "'Zvi Lifshitz'" <ZviL@optibase.com>, <jan.vandermeer@philips.com>, <rem-conf@es.net>, <4on2andIP-sys@advent.ee.columbia.edu> References: <200009121719.WAA06659@hafez.east.isi.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Fri, 15 Sep 2000 01:51:21 +0900 Organization: TechWay 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-09-15 02:42:54 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-15 02:43:17 AM, Serialize complete at 2000-09-15 02:43:17 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 615 Lines: 11 RGVhciBDb2xpbiBhbmQgYWxsLA0KDQo+IA0KPiBUaGUgcGF5bG9hZCB0eXBlIHdpbGwgaGF2ZSB0 byBiZSBuZWdvdGlhdGVkIG91dCBvZiBiYW5kIGFueXdheSwgdGhlcmUgd2lsbA0KPiBiZSBubyBt b3JlIHN0YXRpYyBwYXlsb2FkIHR5cGUgYXNzaWdubWVudHMuIFNpbmNlIHRoZXJlIG11c3QgYmUg bmVnb3RpYXRpb24NCj4gaGF2aW5nIHRoaXMgZXh0cmEgYnl0ZSBpbiB0aGUgcGF5bG9hZCBmb3Jt YXQgbWFrZXMgbm8gc2Vuc2UuDQo+IA0KDQpJJ2QgbGlrZSB0byBiZSBtb3JlIGNsZWFyIG9uIHRo aXMgcG9pbnQuIFRoZSBwYXlsb2FkIHR5cGUgb2YgTVBFRy00IEVTIG92ZXIgUlRQIGJpdHN0cmVh bSBhbmQgTVBFRy00IFNMIG92ZXIgUlRQIGJpdHN0cmVhbSBjYW4gaGF2ZSB0aGUgc2FtZSB0YXls b2FkIHR5cGUgc2VtYW50aWNhbGx5LiBSaWdodD8NCg0KU2luY2VyZWx5LA0KWW91bmcuDQo= From rem-conf Thu Sep 14 10:57:35 2000 From rem-conf-request@es.net Thu Sep 14 10:57:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZdFX-0006LT-00; Thu, 14 Sep 2000 10:56:39 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZdFW-0006LJ-00; Thu, 14 Sep 2000 10:56:38 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id NAA17327; Thu, 14 Sep 2000 13:56:53 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA20052; Thu, 14 Sep 2000 22:56:31 +0500 Message-Id: <200009141756.WAA20052@hafez.east.isi.edu> To: Young-Kwon LIM <young@techway.co.kr> cc: Herpel Carsten <HerpelC@thmulti.com>, Stephan Wenger <stewe@cs.tu-berlin.de>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Fri, 15 Sep 2000 01:40:43 +0900." <000401c01e73$034b9050$a4d2c59d@Young> Date: Thu, 14 Sep 2000 13:56:31 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 955 Lines: 26 --> Young-Kwon LIM writes: >Dear Stephe and all, > >> >> Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-ES. >> Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-ES. >> This is how things are done, at least in H.323, all the time. >> > >With additional one byte indicating the length of the payload header at >the beginning of the payload, bitstream for MPEG-4 SL can be comsumed by >the device only supporting MPEG-4 ES without any modification. This is one >of the advantages using this byte. This does not work, since a device supporting the ES format will only understand LATM audio or video in Combined Configuration/Elementary stream mode. If the content sent after the payload header is in a format other than these, the old receiver will break (even if it can skip the payload header). Surely you are not proposing a generic format which can only transport this particular subset of MPEG4? Colin From rem-conf Thu Sep 14 11:09:43 2000 From rem-conf-request@es.net Thu Sep 14 11:09:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZdQK-0007Oi-00; Thu, 14 Sep 2000 11:07:48 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZdQI-0007OY-00; Thu, 14 Sep 2000 11:07:46 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA17478; Thu, 14 Sep 2000 14:08:00 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA20114; Thu, 14 Sep 2000 23:07:39 +0500 Message-Id: <200009141807.XAA20114@hafez.east.isi.edu> To: Young-Kwon LIM <young@techway.co.kr> cc: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com>, "'Zvi Lifshitz'" <ZviL@optibase.com>, "jan.vandermeer" <jan.vandermeer@philips.com>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Fri, 15 Sep 2000 01:51:21 +0900." <000501c01e73$0444bd60$a4d2c59d@Young> Date: Thu, 14 Sep 2000 14:07:39 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 605 Lines: 16 --> Young-Kwon LIM writes: >> The payload type will have to be negotiated out of band anyway, there will >> be no more static payload type assignments. Since there must be negotiation >> having this extra byte in the payload format makes no sense. > >I'd like to be more clear on this point. The payload type of MPEG-4 ES >over RTP bitstream and MPEG-4 SL over RTP bitstream can have the same >payload type semantically. Right? I don't understand your question. If the formats are different, they will have different MIME types. What payload type those MIME types are mapped to is not relevent. Colin From rem-conf Thu Sep 14 11:13:24 2000 From rem-conf-request@es.net Thu Sep 14 11:13:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZdUQ-0007np-00; Thu, 14 Sep 2000 11:12:02 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZdUN-0007mL-00; Thu, 14 Sep 2000 11:12:00 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA17512; Thu, 14 Sep 2000 14:12:15 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA20133; Thu, 14 Sep 2000 23:11:54 +0500 Message-Id: <200009141811.XAA20133@hafez.east.isi.edu> To: Young-Kwon LIM <young@techway.co.kr> cc: Herpel Carsten <HerpelC@thmulti.com>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Fri, 15 Sep 2000 01:29:27 +0900." <000301c01e73$023ba6f0$a4d2c59d@Young> Date: Thu, 14 Sep 2000 14:11:54 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1058 Lines: 27 --> Young-Kwon LIM writes: >Dear Carsten, and all > >> >> One assumption is that huge numbers of devices will be out there that use >> the ES payload format. Assuming that these devices cannot be upgraded to a >> newer payload format! >> Then applications come up with more functionality, using MPEG-4 Systems. New >> devices will exist that know how to use this functionality. Old devices >> should at least be able to understand the (unmodified!) MPEG-4 Video over >> RTP stream. Since the old devices are not reprogrammable, they cannot be >> upgraded to another payload format. So the old format needs to be by design >> compatible to any new format. > >I do belive that this scenario is more realistic and more useful than the >second case. The existing ES format is intended for devices which do not implement MPEG-4 systems. I fail to see why anyone would use it for an application which depended on the systems framework, since a number of features of the draft are in direct opposition to the systems framework. Square peg. Round hole. Colin From rem-conf Thu Sep 14 11:14:46 2000 From rem-conf-request@es.net Thu Sep 14 11:14:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZdVh-0000CR-00; Thu, 14 Sep 2000 11:13:21 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZdVf-0000At-00; Thu, 14 Sep 2000 11:13:20 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA17532; Thu, 14 Sep 2000 14:13:33 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA20147; Thu, 14 Sep 2000 23:13:12 +0500 Message-Id: <200009141813.XAA20147@hafez.east.isi.edu> To: Young-Kwon LIM <young@techway.co.kr> cc: "jan.vandermeer" <jan.vandermeer@philips.com>, stewe <stewe@cs.tu-berlin.de>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call In-Reply-To: Your message of "Fri, 15 Sep 2000 01:27:21 +0900." <000001c01e73$01567710$a4d2c59d@Young> Date: Thu, 14 Sep 2000 14:13:12 -0400 From: Colin Perkins <csp@east.isi.edu> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 693 Lines: 18 --> Young-Kwon LIM writes: >> In RTP, that parameter is the payload type field. >> >> I really don't understand why this additional field will add value. It >> allows for systems to skip data which they don't understand, how is this >> different from using the payload type for the same effect? > >The length of additional header will be variable. So, the device should >know the length to skip the additional headers it doesn't understand. But this doesn't help, since the ES draft imposes strict limitations on the format of the elementary stream following this additional header. If you try to use it for generic elementary stream transport, you will break existing receivers. Colin From rem-conf Thu Sep 14 11:29:48 2000 From rem-conf-request@es.net Thu Sep 14 11:29:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zdk8-0002EP-00; Thu, 14 Sep 2000 11:28:16 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zdk7-0002EF-00; Thu, 14 Sep 2000 11:28:15 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA26471; Thu, 14 Sep 2000 11:28:13 -0700 Date: Thu, 14 Sep 2000 11:28:13 -0700 From: John Lazzaro <lazzaro@CS.Berkeley.EDU> Message-Id: <200009141828.LAA26471@snap.CS.Berkeley.EDU> To: 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com Subject: Re: Kikuchi-san proposal as subset of generic MPEG-4 formats Cc: rem-conf@es.net X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1115 Lines: 24 [jan.vandermeer@philips.com writes] > If we agree on his, then > the important question is whether we need also define carriage of MPEG-4 > audio ES over IP without LATM. Perhaps not. LATM adds only little overhead > in case of a single large AU and for a small AU it is likely that LATM is > applied anyhow. Here's an app where it may be worthwhile to carry MPEG-4 audio ES over IP without LATM: using SA_access_units to transmit MIDI Events between a set of Structured Audio decoders over a low-latency network for real-time musical performance. Since SA_access_units's are defined to hold a single MIDI command, most often 3 bytes, and in many cases there won't be another audio codec being used along with the Structured Audio decoder, the LATM overhead will be significant and won't be adding any value. ------------------------------------------------------------------------- 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 Sep 14 11:47:21 2000 From rem-conf-request@es.net Thu Sep 14 11:47:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zdzx-0003N3-00; Thu, 14 Sep 2000 11:44:37 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zdzw-0003Lz-00; Thu, 14 Sep 2000 11:44:36 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <S5536H0X>; Thu, 14 Sep 2000 12:43:39 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA7985F2@el-postino.s-vision.com> From: Kris Huber <khuber@sorensonlabs.com> To: Colin Perkins <csp@east.isi.edu>, Young-Kwon LIM <young@techway.co.kr> Cc: Herpel Carsten <HerpelC@thmulti.com>, rem-conf <rem-conf@es.net>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 14 Sep 2000 12:43:37 -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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2817 Lines: 72 Colin, >The existing ES format is intended for devices which do not implement >MPEG-4 systems. I fail to see why anyone would use it for an application >which depended on the systems framework, since a number of features of >the draft are in direct opposition to the systems framework. > >Square peg. Round hole. Existing ES may become used by systems that implement the system framework simply to avoid sending duplicate broadcasts to non-updateable devices and newer devices utilizing systems tools. I think this is the reason why. Remember video ES data probably dominates bandwidth consumption which is not unlimited (yet!?) and therefore we should consider a precious resource. I'm assuming services worried about not obsoleting nonupgradable devices can take the approach of using Kikuchi-san format in their systems-based services for video ES if they want. Of course, it is not guaranteed that nonupgradeable devices won't become obsolete quite soon, especially if the generic format is rapidly deployed, but since it seems to be an option of the services provider to avoid it, I am satisfied and have no further comment other than to wish the generic format definition to continue along well. I may attend the pre-meeting Saturday (if I'm not bought off by the airlines to delay! $:>). Actually, I have relatives living at a few hours distance that I hope to visit, too. I have full confidence in the superiority of the rest of the group in this area! regards, Kris -----Original Message----- From: Colin Perkins [mailto:csp@east.isi.edu] Sent: Thursday, September 14, 2000 12:12 PM To: Young-Kwon LIM Cc: Herpel Carsten; rem-conf; 4on2andIP-sys Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call --> Young-Kwon LIM writes: >Dear Carsten, and all > >> >> One assumption is that huge numbers of devices will be out there that use >> the ES payload format. Assuming that these devices cannot be upgraded to a >> newer payload format! >> Then applications come up with more functionality, using MPEG-4 Systems. New >> devices will exist that know how to use this functionality. Old devices >> should at least be able to understand the (unmodified!) MPEG-4 Video over >> RTP stream. Since the old devices are not reprogrammable, they cannot be >> upgraded to another payload format. So the old format needs to be by design >> compatible to any new format. > >I do belive that this scenario is more realistic and more useful than the >second case. The existing ES format is intended for devices which do not implement MPEG-4 systems. I fail to see why anyone would use it for an application which depended on the systems framework, since a number of features of the draft are in direct opposition to the systems framework. Square peg. Round hole. Colin From rem-conf Thu Sep 14 12:03:39 2000 From rem-conf-request@es.net Thu Sep 14 12:03:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZeH3-0004Tf-00; Thu, 14 Sep 2000 12:02:17 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZeGu-0004TP-00; Thu, 14 Sep 2000 12:02:11 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA19908; Thu, 14 Sep 2000 22:01:20 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 22:01:25 +0200 Message-ID: <01C01E97.533A5280.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Young-Kwon LIM'" <young@techway.co.kr>, "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com>, Colin Perkins <csp@east.isi.edu> Cc: "jan.vandermeer@philips.com" <jan.vandermeer@philips.com>, "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 14 Sep 2000 22:01:23 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 959 Lines: 30 [Young-Kwon LIM:] I'd like to be more clear on this point. The payload type of MPEG-4 ES over RTP bitstream and MPEG-4 SL over RTP bitstream can have the same tayload type semantically. Right? [Reply:] Wrong. The option that was raised when I talked to Jan was that a server would advertise same content twice, once as having the ES format and then as having the Generic format. This would probably work but IMO is useless... z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 14 12:08:40 2000 From rem-conf-request@es.net Thu Sep 14 12:08:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZeMe-0005Fp-00; Thu, 14 Sep 2000 12:08:04 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZeMc-0005FP-00; Thu, 14 Sep 2000 12:08:03 -0700 Received: from zvil (i1-18.j1.actcom.co.il [192.115.22.180]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id WAA20644; Thu, 14 Sep 2000 22:07:12 +0300 Received: by localhost with Microsoft MAPI; Thu, 14 Sep 2000 22:07:17 +0200 Message-ID: <01C01E98.2547D220.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Young-Kwon LIM'" <young@techway.co.kr>, Herpel Carsten <HerpelC@thmulti.com>, Stephan Wenger <stewe@cs.tu-berlin.de> Cc: "rem-conf@es.net" <rem-conf@es.net>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Date: Thu, 14 Sep 2000 22:07:17 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1480 Lines: 44 If you want to make the stream consumable to devices knowing only MPEG4-ES, use MPEG-4 ES. What value will the MPEG-4 SL give you? z soon the whole world will STREAM ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Young-Kwon LIM [SMTP:young@techway.co.kr] Sent: Thursday, September 14, 2000 6:41 PM To: Herpel Carsten; Stephan Wenger Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: AHG comments on draft-ietf-avt-rtp-mpeg4-es-03 in response to the last call Dear Stephe and all, > > Very simple to achieve. Have two payload types, MPEG-4-SL and MPEG-4-ES. > Try to negotiate MPEG-4-SL. If the other system rejects, use MPEG-4-ES. > This is how things are done, at least in H.323, all the time. > With additional one byte indicating the length of the payload header at the beginning of the payload, bitstream for MPEG-4 SL can be comsumed by the device only supporting MPEG-4 ES without any modification. This is one of the advantages using this byte. Sincerely, Young. From rem-conf Thu Sep 14 12:44:02 2000 From rem-conf-request@es.net Thu Sep 14 12:44:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zepo-0006YN-00; Thu, 14 Sep 2000 12:38:12 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zepm-0006YD-00; Thu, 14 Sep 2000 12:38:10 -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 EAA01134; Fri, 15 Sep 2000 04:38:01 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id EAA25066; Fri, 15 Sep 2000 04:38:00 +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 EAA29286; Fri, 15 Sep 2000 04:38:00 +0900 (JST) Received: from default (kwa0208.mobile.toshiba.co.jp [133.120.199.40]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id EAA67743; Fri, 15 Sep 2000 04:37:56 +0900 (JST) Message-ID: <03e101c01e83$4df19180$28c77885@default> From: "Yoshihiro Kikuchi" <kiku@eel.rdc.toshiba.co.jp> To: "IETF AVT" <rem-conf@es.net> Cc: "Zvi Lifshitz" <ZviL@optibase.com>, "Colin Perkins" <csp@east.isi.edu>, "Yoshihiro Kikuchi" <kiku@eel.rdc.toshiba.co.jp> Subject: comments on in-band-signaling proposal Date: Fri, 15 Sep 2000 04:38:04 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2268 Lines: 58 Dear all experts, The authors of the Internet-Draft have discussed the issue of in-band-signaling proposal. We understand the importance of interoperability, however, we do not believe the specific proposal of an extra byte in the RTP header is a good solution. It is our common and firm desire that any proposal will not degrade the original intention, purpose and functionality of the RTP payload format. Especially, the following points are important. o Overhead caused by an extra RTP header The in-band-signaling proposal will cause at least one byte overhead per each RTP packet. Since this RTP payload format may be used in very low bitrate applications such as mobile and analog modem, the overhead is a serious problem. On the other hand, the ways suggested by Colin, Stephan, etc. of using different payload types will not cause any overhead problem. o Stability and reliability As was pointed out by many, there is no guaranty that receivers of ES-based RTP payload format can receive SL-based RTP packets correctly, even if the extra byte in the RTP header is added. It is dangerous to adopt such proposal at this moment without any guaranty. It is our strong desire that only verified solution will be adopted in the RTP payload format specification. o Schedule There is no specific description of changes about the proposal, so far. It is hard to accept such proposal. Even if the proposal has some value (although we doubt it), it should not be too late to adopt it in SL-based proposal, by keeping backword compatibility with ES-based RTP payload format. These points are very important to keep the original functionality of the proposal. Constructive comments are welcome, however, we cannot accept any proposals to harm the original intention and functionality. By this point, it is hard to accept the in-band-signaling proposal which causes overhead problem and which is not well verified. It should be remarked that the alternatives proposed by IETF experts will not cause any such problems. Kind regards, Yoshihiro Kikuchi and authors of the Intenet 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 Thu Sep 14 14:07:33 2000 From rem-conf-request@es.net Thu Sep 14 14:07:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZgA2-0000eh-00; Thu, 14 Sep 2000 14:03:10 -0700 Received: from (sr4-spo.nttnet.com.br) [200.194.94.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zg9z-0000ct-00; Thu, 14 Sep 2000 14:03:07 -0700 Received: from gimemoney (sdn-ar-020casfrMP223.dialsprint.net [158.252.248.225]) by sr4-spo.nttnet.com.br (8.11.0/8.11.0) with SMTP id e8EJ6tK05426; Thu, 14 Sep 2000 16:06:59 -0300 Message-Id: <200009141906.e8EJ6tK05426@sr4-spo.nttnet.com.br> From: workfromhome@ozbytes.net.au To: Subject: Helping To Create Wealth In Others Date: Thu, 14 Sep 2000 10:57:47 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_72B8_00003CAC.00005061" X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3103 Lines: 56 ------=_NextPart_000_72B8_00003CAC.00005061 Content-Type: text/html; <HTML> <BODY> <FONT face="Times New Roman"> <FONT size=3><B> LOOKING FOR GEMS!<BR> <BR> It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... <BR> We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!<BR> <BR> Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? <BR> <BR> If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need.<BR> <BR> Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-320-9895 ext. 6396<BR> <BR> We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you.<BR> <BR> You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! <BR> <BR> The call is FREE, and there is absolutely no obligation, So what have you got to lose? <BR> <BR> Call Toll Free 1-800-320-9895 ext. 6396<BR> <BR> P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life!<BR> <BR> Please, serious inquiries only.<BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> To be removed from future mailings send a blank email with remove in the subject line and <BR> the email address or addresses to be removed in the body to<BR> bowfinger@unbounded.com<BR> <BR> </B> <FONT face="MS Sans Serif"> <FONT size=2> <BR> </FONT></FONT></FONT></FONT><p><p><p><p><p><p><p><p><p><p> <p><FONT face="Times New Roman"><p><FONT size=3><B> LOOKING FOR GEMS!<BR><p><BR><p>It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... <BR><p>We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!<BR><p><p><p><p><p><p><p><p><p></BODY></HTML> From rem-conf Thu Sep 14 17:15:46 2000 From rem-conf-request@es.net Thu Sep 14 17:15:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zj7J-00031r-00; Thu, 14 Sep 2000 17:12:33 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zj7H-00031O-00; Thu, 14 Sep 2000 17:12:31 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JU65MNFZLCEBWCWM@GI.COM> for rem-conf@es.net; Thu, 14 Sep 2000 17:10:05 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id <SS4NP6TW>; Thu, 14 Sep 2000 16:42:41 -0400 Content-return: allowed Date: Thu, 14 Sep 2000 19:45:43 -0400 From: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com> Subject: RE: comments on in-band-signaling proposal To: 'Yoshihiro Kikuchi' <kiku@eel.rdc.toshiba.co.jp>, IETF AVT <rem-conf@es.net>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: Zvi Lifshitz <ZviL@optibase.com>, Colin Perkins <csp@east.isi.edu>, "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <973597126BDDD11197AA00805FA7EBC9034239BA@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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5781 Lines: 133 Dear Kikuchi-San and experts, I am coming from a world where content creators and servers are very 'receiver-aware' and will not do anything in the content creation that will crash receivers. In this regard, the service providers who use the content want to play this on as many receivers as possible and they are also aware of the fact that receivers vary in their capabilities. Service providers, on the other hand, will not send 2 separate content streams to play on 2 receivers on the same wire as this consumes precious bandwidth. 2 examples of streams that one may want to play on receivers that implement your draft are 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. 2. One may author SL packetized video where there was information in the SL header and this will be in the adaptation field. In addition, the authors will make sure that the video ES in the SL packet would be independently decodable by receivers that implemented your draft. This will require the ability to parse the first byte in the adaptation header and use it to offset where the video ES payload would be picked up. If your draft can accommodate this simple extension, then it will enable the receivers to play more content from the future and it will enable service providers to keep this in mind when they author MPEG-4 based content in the future. Regards to your concerns, 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition to the 16 byte RTP header. If we sent 1 VOP per packet, then it is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. This is very minimal. The FEC proposal proposes the same type of overhead. 2. The content authors will always make sure they follow all the other recommendations from your draft to make sure that the future content will play on receivers that implement the draft (such as sending data in decoding order, not splitting the headers etc). The only change from an implementation of today is the extra parsing of one byte before the ES payload to offset where the ES payload is picked up. 3. The change to your draft would to be add 2 fields after the CSRC and before the video ES. These would be 'adaptation length' and 'length (if adaptation length is greater than 0)'. The semantics will say, the first byte after CSRC will contain the length of adaptation field. If this length value is zero, then the video payload will start in the next byte. Otherwise, the video payload will start after the number of bytes indicated in the adaptation length field. The content of the adaptation field after the length is private and left for future extensions. Jan Vandermeer may also have some suggested changes to the draft, if this can be accommodated. Thank you for your kind patience. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] Sent: Thursday, September 14, 2000 12:38 PM To: IETF AVT Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi Subject: comments on in-band-signaling proposal Dear all experts, The authors of the Internet-Draft have discussed the issue of in-band-signaling proposal. We understand the importance of interoperability, however, we do not believe the specific proposal of an extra byte in the RTP header is a good solution. It is our common and firm desire that any proposal will not degrade the original intention, purpose and functionality of the RTP payload format. Especially, the following points are important. o Overhead caused by an extra RTP header The in-band-signaling proposal will cause at least one byte overhead per each RTP packet. Since this RTP payload format may be used in very low bitrate applications such as mobile and analog modem, the overhead is a serious problem. On the other hand, the ways suggested by Colin, Stephan, etc. of using different payload types will not cause any overhead problem. o Stability and reliability As was pointed out by many, there is no guaranty that receivers of ES-based RTP payload format can receive SL-based RTP packets correctly, even if the extra byte in the RTP header is added. It is dangerous to adopt such proposal at this moment without any guaranty. It is our strong desire that only verified solution will be adopted in the RTP payload format specification. o Schedule There is no specific description of changes about the proposal, so far. It is hard to accept such proposal. Even if the proposal has some value (although we doubt it), it should not be too late to adopt it in SL-based proposal, by keeping backword compatibility with ES-based RTP payload format. These points are very important to keep the original functionality of the proposal. Constructive comments are welcome, however, we cannot accept any proposals to harm the original intention and functionality. By this point, it is hard to accept the in-band-signaling proposal which causes overhead problem and which is not well verified. It should be remarked that the alternatives proposed by IETF experts will not cause any such problems. Kind regards, Yoshihiro Kikuchi and authors of the Intenet 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 Thu Sep 14 22:35:34 2000 From rem-conf-request@es.net Thu Sep 14 22:35:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zo4j-0005xT-00; Thu, 14 Sep 2000 22:30:13 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zo4i-0005xJ-00; Thu, 14 Sep 2000 22:30:12 -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 OAA07425; Fri, 15 Sep 2000 14:29:51 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA01067; Fri, 15 Sep 2000 14:29:50 +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 OAA01761; Fri, 15 Sep 2000 14:29:49 +0900 (JST) Received: from default (kwa0207.mobile.toshiba.co.jp [133.120.199.39]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id OAA79488; Fri, 15 Sep 2000 14:29:45 +0900 (JST) Message-ID: <052d01c01ed5$faa10da0$28c77885@default> From: "Yoshihiro Kikuchi" <kiku@eel.rdc.toshiba.co.jp> To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com>, "IETF AVT" <rem-conf@es.net>, <jan.vandermeer@philips.com> Cc: "Zvi Lifshitz" <ZviL@optibase.com>, "Colin Perkins" <csp@east.isi.edu>, "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" <kiku@eel.rdc.toshiba.co.jp> References: <973597126BDDD11197AA00805FA7EBC9034239BA@ntas0026.gi.com> Subject: Re: comments on in-band-signaling proposal Date: Fri, 15 Sep 2000 14:29:51 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 8256 Lines: 190 Dear Sam and all, Additional comment: When one content is delivered to different applications and environments, such as set-top-box and mobile terminals, there are many differences on the conditions. Network conditions, such as bitrate, error rate, jitter rate, are different in most cases. Profile@Level for set-top-box and tiny mobile terminals are probably different. For some applications, non-MPEG-4 codec may be used in combined. To adjust to these differences, we need to use different set of parameters, such as bitrate, image size, refresh rate, etc. at codec level anyway and different types of codec may be necessary. > I am coming from a world where content creators and > servers are very 'receiver-aware' and will not do anything > in the content creation that will crash receivers. In this > regard, the service providers who use the content want to > play this on as many receivers as possible and they are also > aware of the fact that receivers vary in their capabilities. > Service providers, on the other hand, will not send 2 separate > content streams to play on 2 receivers on the same wire as this > consumes precious bandwidth. > Considering above, having the same format ONLY at the RTP level may not help the situation so much. It may be useful for some kind of mobile terminals with Mbps bandwidth, error-free, large display size, but maybe it is not so usual case. Or, such powerful terminal can easily implement SL-based format. > 2 examples of streams that one may want to play on receivers > that implement your draft are > > 1. A video ES that required CTS (in the RTP header) and DTS (which > could be in the adaptation field). This may be needed for receivers > that implement MPEG buffer models. This stream can play on > receivers that implement your draft as it has a bigger buffer > and does not need DTS, as long as your draft enabled these > receivers to use the adaptation length field to offset where > the video ES payload was picked up. > 2. One may author SL packetized video where there was information > in the SL header and this will be in the adaptation field. In addition, > the authors will make sure that the video ES in the SL packet > would be independently decodable by receivers that implemented your > draft. This will require the ability to parse the first byte in > the adaptation header and use it to offset where the video ES > payload would be picked up. > I think these streams are covered by SL-based payload. Why don't you use this? > If your draft can accommodate this simple extension, then it will enable > the receivers to play more content from the future and it will enable > service providers to keep this in mind when they author MPEG-4 based > content in the future. > > Regards to your concerns, > > 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition > to the 16 byte RTP header. If we sent 1 VOP per packet, then it > is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. > This is very minimal. The FEC proposal proposes the same type > of overhead. I'm not convinced by this explanation. A VOP may be fragmented into many RTP packets for error resiliency and/or low-delay requirements, and the size of the RTP packet is relatively small. The fixed RTP header is compressed by the header compression technique, but the extra field is not. The overhead is still a serious problem since this RTP payload format may be used in very low bitrate environment. > 2. The content authors will always make sure they follow all the > other recommendations from your draft to make sure that the > future content will play on receivers that implement the draft > (such as sending data in decoding order, not splitting the headers > etc). The only change from an implementation of today is the > extra parsing of one byte before the ES payload to offset where > the ES payload is picked up. Is there any guaranty on this? There were many concerns raised by both IETF and MPEG experts on whether the ES payload receiver can decode SL payload packet correctly only by adding the extra byte fields. We must be care not to bring any danger to the implementers of ES payload format. > 3. The change to your draft would to be add 2 fields after the CSRC > and before the video ES. These would be > 'adaptation length' and > 'length (if adaptation length is greater than 0)'. > The semantics will say, the first byte after CSRC will contain the > length of adaptation field. If this length value is zero, then the > video payload will start in the next byte. Otherwise, the video > payload will start after the number of bytes indicated in the > adaptation length field. The content of the adaptation field after > the length is private and left for future extensions. > Maybe I'm not a correct person to decide whether this change is small or not. But again, we must be care not to bring any danger to the implementers of ES payload format. > Jan Vandermeer may also have some suggested changes to the draft, if this > can be accommodated. Thank you for your kind patience. > We are not so stubborn to reject all changes if it is really useful and supported. Actually, many people helped us for the editorial clarification of the Internet-Draft. However, the proposal of adding extra byte has many serious problems: - Clear disadvantage of the overhead. - No guaranty to work.. - There are many concerns raised by both MPEG and IETF members. How can we adopt such proposal? Best regards, Yoshihiro Kikuchi > -----Original Message----- > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > Sent: Thursday, September 14, 2000 12:38 PM > To: IETF AVT > Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi > Subject: comments on in-band-signaling proposal > > > Dear all experts, > > > The authors of the Internet-Draft have discussed the issue of > in-band-signaling proposal. We understand the importance of > interoperability, however, we do not believe the specific proposal of an > extra byte in the RTP header is a good solution. It is our common and firm > desire that any proposal will not degrade the original intention, purpose > and functionality of the RTP payload format. > > Especially, the following points are important. > > o Overhead caused by an extra RTP header > The in-band-signaling proposal will cause at least one byte overhead per > each RTP packet. Since this RTP payload format may be used in very low > bitrate applications such as mobile and analog modem, the overhead is a > serious problem. On the other hand, the ways suggested by Colin, Stephan, > etc. of using different payload types will not cause any overhead problem. > > o Stability and reliability > As was pointed out by many, there is no guaranty that receivers of ES-based > RTP payload format can receive SL-based RTP packets correctly, even if the > extra byte in the RTP header is added. It is dangerous to adopt such > proposal at this moment without any guaranty. It is our strong desire that > only verified solution will be adopted in the RTP payload format > specification. > > o Schedule > There is no specific description of changes about the proposal, so far. It > is hard to accept such proposal. Even if the proposal has some value > (although we doubt it), it should not be too late to adopt it in > SL-based proposal, by keeping backword compatibility with ES-based RTP > payload format. > > > These points are very important to keep the original functionality of the > proposal. Constructive comments are welcome, however, we cannot accept > any proposals to harm the original intention and functionality. By this > point, it is hard to accept the in-band-signaling proposal which causes > overhead problem and which is not well verified. It should be remarked that > the alternatives proposed by IETF experts will not cause any such problems. > > > Kind regards, > Yoshihiro Kikuchi > and authors of the Intenet 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 Thu Sep 14 23:42:21 2000 From rem-conf-request@es.net Thu Sep 14 23:42:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Zp7e-0007An-00; Thu, 14 Sep 2000 23:37:18 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Zp7c-0007Ab-00; Thu, 14 Sep 2000 23:37:16 -0700 Received: from zvil (i0-28.j2.actcom.co.il [192.115.22.120]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA02093; Fri, 15 Sep 2000 09:33:54 +0300 Received: by localhost with Microsoft MAPI; Fri, 15 Sep 2000 09:34:04 +0200 Message-ID: <01C01EF8.16C7F620.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'Narasimhan, Sam (SD-EX)'" <SNarasimhan@gi.com>, "'Yoshihiro Kikuchi'" <kiku@eel.rdc.toshiba.co.jp>, IETF AVT <rem-conf@es.net>, "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com> Cc: Colin Perkins <csp@east.isi.edu>, "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Date: Fri, 15 Sep 2000 09:34: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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 1551 Lines: 43 [Narasimhan, Sam (SD-EX):] 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. [Reply:] The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model. [Original message:] 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition to the 16 byte RTP header. If we sent 1 VOP per packet, then it is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. This is very minimal. The FEC proposal proposes the same type of overhead. [Reply:] There is header compression. I think Kikuchi-san mentioned that, along with few other good arguments. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 14 23:55:15 2000 From rem-conf-request@es.net Thu Sep 14 23:55:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZpMk-0000Ew-00; Thu, 14 Sep 2000 23:52:54 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZpMj-0000ER-00; Thu, 14 Sep 2000 23:52:53 -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 <0G0X00LB91PQ3U@ss3000e.cselt.it> for rem-conf@es.net; Fri, 15 Sep 2000 08:51:26 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id <R0JL2FYS>; Fri, 15 Sep 2000 08:53:32 +0200 Content-return: allowed Date: Fri, 15 Sep 2000 08:51:41 +0200 From: Franceschini Guido <Guido.Franceschini@CSELT.IT> Subject: RE: comments on in-band-signaling proposal To: "Narasimhan, Sam (SD-EX)" <SNarasimhan@gi.com>, IETF AVT <rem-conf@es.net>, jan.vandermeer@philips.com, 'Yoshihiro Kikuchi' <kiku@eel.rdc.toshiba.co.jp> Cc: Zvi Lifshitz <ZviL@optibase.com>, Colin Perkins <csp@east.isi.edu>, 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <85077463E51D6A498C453073E1677940034EE0@exc2k02.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 9533 Lines: 234 Sorry MPEG friends, but I fully support Kikuchi-sun. At least until I see a proposal that does not address just the extra-byte detail, but solves the real problem (negotiation). So that everybody can convince himself that there are different ways to fit the requirement at the level of RTP packets ... Remember, when using the SL mapping an 'old' receiver has currently no way to know the media being carried. It could even be BIFS ! [ps: in addition there is a need to clean-up the LATM issue, but this is orthogonal IMHO.] Best regards Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Friday, September 15, 2000 7:29 AM > To: Narasimhan, Sam (SD-EX); IETF AVT; jan.vandermeer@philips.com > Cc: Zvi Lifshitz; Colin Perkins; 4on2andIP-sys; Yoshihiro Kikuchi > Subject: Re: comments on in-band-signaling proposal > > Dear Sam and all, > > Additional comment: > > When one content is delivered to different applications and environments, > such as set-top-box and mobile terminals, there are many differences on > the > conditions. Network conditions, such as bitrate, error rate, jitter rate, > are > different in most cases. Profile@Level for set-top-box and tiny mobile > terminals are probably different. For some applications, non-MPEG-4 codec > may be used in combined. To adjust to these differences, we need to use > different set of parameters, such as bitrate, image size, refresh rate, > etc. at codec level anyway and different types of codec may be necessary. > > > I am coming from a world where content creators and > > servers are very 'receiver-aware' and will not do anything > > in the content creation that will crash receivers. In this > > regard, the service providers who use the content want to > > play this on as many receivers as possible and they are also > > aware of the fact that receivers vary in their capabilities. > > Service providers, on the other hand, will not send 2 separate > > content streams to play on 2 receivers on the same wire as this > > consumes precious bandwidth. > > > Considering above, having the same format ONLY at the RTP level may not > help > the situation so much. It may be useful for some kind of mobile terminals > with Mbps bandwidth, error-free, large display size, but maybe it is not > so > usual case. Or, such powerful terminal can easily implement SL-based > format. > > > 2 examples of streams that one may want to play on receivers > > that implement your draft are > > > > 1. A video ES that required CTS (in the RTP header) and DTS (which > > could be in the adaptation field). This may be needed for receivers > > that implement MPEG buffer models. This stream can play on > > receivers that implement your draft as it has a bigger buffer > > and does not need DTS, as long as your draft enabled these > > receivers to use the adaptation length field to offset where > > the video ES payload was picked up. > > 2. One may author SL packetized video where there was information > > in the SL header and this will be in the adaptation field. In > addition, > > the authors will make sure that the video ES in the SL packet > > would be independently decodable by receivers that implemented your > > draft. This will require the ability to parse the first byte in > > the adaptation header and use it to offset where the video ES > > payload would be picked up. > > > I think these streams are covered by SL-based payload. Why don't you use > this? > > > If your draft can accommodate this simple extension, then it will > enable > > the receivers to play more content from the future and it will enable > > service providers to keep this in mind when they author MPEG-4 based > > content in the future. > > > > Regards to your concerns, > > > > 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition > > to the 16 byte RTP header. If we sent 1 VOP per packet, then it > > is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. > > This is very minimal. The FEC proposal proposes the same type > > of overhead. > > I'm not convinced by this explanation. A VOP may be fragmented into many > RTP > packets for error resiliency and/or low-delay requirements, and the size > of > the RTP packet is relatively small. The fixed RTP header is compressed by > the header compression technique, but the extra field is not. The overhead > is still a serious problem since this RTP payload format may be used in > very > low bitrate environment. > > > 2. The content authors will always make sure they follow all the > > other recommendations from your draft to make sure that the > > future content will play on receivers that implement the draft > > (such as sending data in decoding order, not splitting the headers > > etc). The only change from an implementation of today is the > > extra parsing of one byte before the ES payload to offset where > > the ES payload is picked up. > > Is there any guaranty on this? There were many concerns raised by both > IETF > and MPEG experts on whether the ES payload receiver can decode SL payload > packet correctly only by adding the extra byte fields. We must be care not > to bring any danger to the implementers of ES payload format. > > > 3. The change to your draft would to be add 2 fields after the CSRC > > and before the video ES. These would be > > 'adaptation length' and > > 'length (if adaptation length is greater than 0)'. > > The semantics will say, the first byte after CSRC will contain the > > length of adaptation field. If this length value is zero, then the > > video payload will start in the next byte. Otherwise, the video > > payload will start after the number of bytes indicated in the > > adaptation length field. The content of the adaptation field after > > the length is private and left for future extensions. > > > Maybe I'm not a correct person to decide whether this change is small or > not. But again, we must be care not to bring any danger to the > implementers > of ES payload format. > > > Jan Vandermeer may also have some suggested changes to the draft, if > this > > can be accommodated. Thank you for your kind patience. > > > We are not so stubborn to reject all changes if it is really useful and > supported. Actually, many people helped us for the editorial clarification > of the Internet-Draft. However, the proposal of adding extra byte has many > serious problems: > > - Clear disadvantage of the overhead. > - No guaranty to work.. > - There are many concerns raised by both MPEG and IETF members. > > How can we adopt such proposal? > > Best regards, > Yoshihiro Kikuchi > > > -----Original Message----- > > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > > Sent: Thursday, September 14, 2000 12:38 PM > > To: IETF AVT > > Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi > > Subject: comments on in-band-signaling proposal > > > > > > Dear all experts, > > > > > > The authors of the Internet-Draft have discussed the issue of > > in-band-signaling proposal. We understand the importance of > > interoperability, however, we do not believe the specific proposal of an > > extra byte in the RTP header is a good solution. It is our common and > firm > > desire that any proposal will not degrade the original intention, > purpose > > and functionality of the RTP payload format. > > > > Especially, the following points are important. > > > > o Overhead caused by an extra RTP header > > The in-band-signaling proposal will cause at least one byte overhead per > > each RTP packet. Since this RTP payload format may be used in very low > > bitrate applications such as mobile and analog modem, the overhead is a > > serious problem. On the other hand, the ways suggested by Colin, > Stephan, > > etc. of using different payload types will not cause any overhead > problem. > > > > o Stability and reliability > > As was pointed out by many, there is no guaranty that receivers of > ES-based > > RTP payload format can receive SL-based RTP packets correctly, even if > the > > extra byte in the RTP header is added. It is dangerous to adopt such > > proposal at this moment without any guaranty. It is our strong desire > that > > only verified solution will be adopted in the RTP payload format > > specification. > > > > o Schedule > > There is no specific description of changes about the proposal, so far. > It > > is hard to accept such proposal. Even if the proposal has some value > > (although we doubt it), it should not be too late to adopt it in > > SL-based proposal, by keeping backword compatibility with ES-based RTP > > payload format. > > > > > > These points are very important to keep the original functionality of > the > > proposal. Constructive comments are welcome, however, we cannot accept > > any proposals to harm the original intention and functionality. By this > > point, it is hard to accept the in-band-signaling proposal which causes > > overhead problem and which is not well verified. It should be remarked > that > > the alternatives proposed by IETF experts will not cause any such > problems. > > > > > > Kind regards, > > Yoshihiro Kikuchi > > and authors of the Intenet 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 Fri Sep 15 09:39:29 2000 From rem-conf-request@es.net Fri Sep 15 09:39:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ZyBx-00071P-00; Fri, 15 Sep 2000 09:18:21 -0700 Received: from shako.cisco.com [161.44.3.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ZyBv-00070s-00; Fri, 15 Sep 2000 09:18:19 -0700 Received: from cisco.com (sj-dial-3-66.cisco.com [171.68.180.67]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA09332; Fri, 15 Sep 2000 12:13:21 -0400 (EDT) Message-ID: <39C24AA8.12666180@cisco.com> Date: Fri, 15 Sep 2000 12:13:28 -0400 From: "W. Mark Townsley" <townsley@cisco.com> X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tmima Koren <tmima@cisco.com> CC: Andy Valencia <vandys@zendo.com>, brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, l2tp@diameter.org, rem-conf@es.net Subject: Re: 0 byte L2TPHC header and implied PPPMUX References: <4.3.1.2.20000907161936.029ba8e0@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 5439 Lines: 120 Tmima, I am just getting around to reading this thread myself, so a week is really not a lot of time for people to consider this. I would like to hear from others. Paolo? To summarize, the current l2tphc provides a 1, 2 or 3 byte header and now we need to consider a 0 byte header. Bandwidth is precious, the more flexible the header, the more difficult it is to switch. Our variable length l2tp header is no joy to switch as is. That said, you know your market better than I and if you have to get rid of this byte, even with the processing cost, so be it. I have some new concerns about this first byte in general that have come up during my most recent hard look at this. The first byte of the l2tphc header carries more than the P bit of course, it carries at least one bit for future use and a few more bits which are essentially static for all packets. These bits may be more precious that we think. Given the number of suggestions for changing this header and the ways it which it is being used that were never dreamed of in the beginning (l2tphc was really designed for voluntary tunnels across slow dialup links which have yet to be implemented, where it *is* being deployed today is on ATM networks and voice applications!) I would not dare to guess what will be next. Further, we may wish to carry a uncompressed version of L2TP directly over IP at some point and Ip protocol IDs are hard to come by. So, I think the static bits should be put to better use, and a version field seems to be in order so that I can sleep well at night. This is what I would like to see in the first byte: 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|P|I|J|x|x| ver | Session ID... | PPP packet... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T,P,I,J are as defined in the l2tphc spec. ver is 1 (or 2 to match l2tp if you like). As for the compression of the first byte via l2tphc, as long as one side can always force a peer to include this byte if need be then I am OK with its removal. This has to be a very strong MUST though as it is the local box that knows if it is going to need this first byte to multiplex l2tphc with other l2tp or l2tphc versions, not its peer. It should be very explicit that this is the case (e.g. An l2tphc implementation MUST be able to send the header format requested by its peer... and then perhaps even an explanation of why). More comments below on the mechanisms. Some of these concerns certainly overlap with Andy's. Tmima Koren wrote: > > I suggest a few minor changes to the L2TPHC draft draft-ietf-l2tpext-l2tphc-02.txt > to improve bandwidth utilization in special cases. > > When the L2TPHC header is 1 byte long, actually only 1 bit is significant: the P (Priority) bit. > > If all the packets in the tunnel will have the same priority, the L2TPHC byte is redundant. > > We could add to the L2TPHC AVP one more byte (byte 9) > We really need only 2 flag bits: > > flag 1: value 1 means: L2TPHC byte will be omitted > value 0 means: L2TPHC byte is there, get P (Priority) from the L2TPHC byte > > flag 2: value 1 means all packets have implied P=1 > value 0 means all packets have implied P=0 > Since we now have potentially more information in the first byte, perhaps you should compress it away in a general manner. A new AVP which defines what the static byte should look like would accomplish this. e.g. something like this in the AVP: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+ |T|P|I|J|x|x| ver | +-+-+-+-+-+-+-+-+-+ ...which sets the proper bits that are "always on" for this session (and, really, the entire box!) I would include cautionary text about setting the P bit for all packets as Andy pointed out (perhaps even stating that it MUST be 0), as well as the loss of functionality for prioritizing LCP echos in general. > consult flag 2 only when flag 1 is 1 > > If the packet in the L2TPHC tunnel is always PPPMUX, there is another useful flag: > > flag 3: value 1 means 'PPPMUX only' > value 0 means: any PPP packet > > When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can be omitted > PPP packets that have a different priority or that are not PPPMUX can still be sent in the tunnel using the UDP/L2TP format, same as the L2TP control packets This actually falls nicely in the new Service Type model. As soon as Suhail and Danny finish this up (its my fault, I keep sending it back to them with corrections) then you will have a framework to identify a new Service Type for TCRTP/PPPMUX. PPPMUX at least is really a different framing method and protocol for l2tp so it should be treated as such. You will need to write a draft identifying this new service type. Nice thing is that you get l2tp or l2tphc functionality to boot. It also provides a good place to talk about any pppmux/rtp/l2tphc concerns, as well as a vehicle for idenifying any specific new avps you might need for the session that you have not thought of yet. > > TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: the tunneling overhead will be reduced by 2 bytes. Some of the lengths (no pun intended) we go to for a byte or two still amaze me. > > Tmima From rem-conf Fri Sep 15 20:25:24 2000 From rem-conf-request@es.net Fri Sep 15 20:25:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13a8XE-0006tG-00; Fri, 15 Sep 2000 20:21:00 -0700 Received: from gull.prod.itd.earthlink.net [207.217.121.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 13a8XC-0006t6-00; Fri, 15 Sep 2000 20:20:58 -0700 Received: from 37.com (sdn-ar-003nynyorP291.dialsprint.net [168.191.122.157]) by gull.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id UAA15346 for <rem-conf@es.net>; Fri, 15 Sep 2000 20:20:55 -0700 (PDT) Date: Fri, 15 Sep 2000 23:20:48 -0400 From: "flowergarden@37.com" <flowergarden@37.com> Organization: flowergarden@37.com Reply-To: friendlyservice@bonbon.net Message-ID: <B5E85F50.6CE9CB@[168.191.122.1]> To: rem-conf@es.net Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+ Choices! Up to $81. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 10443 Lines: 335 With your first purchase of any size of any new or renewal subscription AT OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay us and will even go back 6 months later if you find a better deal and refund you the difference!); customers living overseas pay only for FPH (foreign postage & handling) on the free subscription. FOR MORE INFO OR TO BE REMOVED FROM OUR MAILING LIST: Just fill out the below form and return to us via email at: friendlyservice@bonbon.net Remove requests will be immediately honored and request for more information will be fulfilled within 24 hours. For more information, if you do not get a reply within 24 hours, then please fax us at: 1-602-294-5643 or write us via smail at: or send via smail (first class mail or airmail) to: Tempting Tear-Outs Att. Free-catalogue-by-email Dept PMB 200 3835 Richmond Ave. Staten Island NY 10312-3828 USA When replying, your reply must include only this form*: (*If you can't figure out how to cut and past this text, just type it out in the same format): *------------cut here/begin-------------------------------------------* No thank you. Please remove me from your mailing list. My email address is: Yes, please send me more info. I realize I am not committing myself to buying anything at this time and I would just like more info on the offer and a FREE copy of your magazine subscription catalogue. Here are my details: Name (First Middle Last): Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Cellular (Mobile) Tel. #: Beeper (Pager) Tel. #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 091300-ng Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF: The company making the offer is a magazine subscription agency based in the USA. They have over 1,100 popular USA titles available to be shipped to ANY country, including of course, to anywhere in the USA! They offer a FREE 1 yr. subscription to your choice of over 200 of the titles in their catalogue to any new customer using them for the first time. The dollar value of the freebies, based on the subscription prices directly >from the publishers, ranges from $6.97 all the way up to $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,100+ titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly >from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas customers. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new customers who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply email or fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the two formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa, American Express, Diner's Club and Carte Blanche. Overseas, they accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche, even if your credit card is a local one in local currency (that most merchants in the USA would not normally be willing to accept). That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on marketing & consulting rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828, USA. This email message has been sent to you by: Tempting Tear-Outs, PMB 200, 3835 Richmond Ave., Staten Island NY 10312-3828, USA. From rem-conf Sat Sep 16 03:50:56 2000 From rem-conf-request@es.net Sat Sep 16 03:50:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13aFUX-0004Hc-00; Sat, 16 Sep 2000 03:46:41 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13aFUV-0004HM-00; Sat, 16 Sep 2000 03:46:40 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA04543; Sat, 16 Sep 2000 12:46:26 +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 xma004541; Sat, 16 Sep 00 12:46:26 +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 MAA02070; Sat, 16 Sep 2000 12:46:25 +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 MAA18713; Sat, 16 Sep 2000 12:46:25 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014123034; Sat, 16 Sep 2000 12:47:29 +0200 To: <kiku@eel.rdc.toshiba.co.jp>, <rem-conf@es.net>, <SNarasimhan@gi.com> Cc: <ZviL@optibase.com>, <csp@east.isi.edu>, <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Message-ID: <0056890014123034000002L942*@MHS> Date: Sat, 16 Sep 2000 12:47:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/16/00 12:44:58" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 7548 Lines: 204 This one did not came through yesterday, due to network problems Sam, Kikuchi-san, others While I am personally confident that it is possible to define a feasibl= e and good solution, I share some of the concern of Kikuchi-san. Within MPEG = there are far too many misunderstandings and disagreements to approve anythin= g at this time. MPEG clearly needs more time to identify the most desirable approach. Therefore I would like to suggest the following way forward : 1) The IETF proceeds with the Kikuchi-san draft without implementing th= e in-band signaling proposal so as to meet the ITU deadline with minimum = risk. 2) MPEG continues to consider the most desirable format for MPEG-4 ES a= nd other MPEG-4 streams. 3) In the La Baule meeting MPEG concludes its discussion by producing i= ts "generic" MPEG-4 over IP draft. 4) If MPEG at the La Baule meeting is confident about the feasibility a= nd usefulness of a forward and backward compatible solution using the Kikuchi-san draft with in-band signaling, then MPEG will request IETF t= o start the publication process of an "update" of the Kikuchi-san draft, = that will obsolete the current one. 5) In case of such "update", MPEG commits to neither change the "update= " of the Kikuchi-san draft, nor elements in the "generic MPEG-4 A/V ES" draf= t that impact the forward and backward compatibility with the updated Kikuchi-san draft. Kind regards, Jan -----Original Message----- From: SNarasimhan@gi.com [mailto:SNarasimhan@gi.com] Sent: vrijdag, 15 september, 2000 02:15 To: Jan vanderMeer; rem-conf@es.net; kiku@eel.rdc.toshiba.co.jp Cc: 4on2andIP-sys@advent.ee.columbia.edu; csp@east.isi.edu; ZviL@optibase.com Subject: RE: comments on in-band-signaling proposal Dear Kikuchi-San and experts, I am coming from a world where content creators and servers are very 'receiver-aware' and will not do anything in the content creation that will crash receivers. In this regard, the service providers who use the content want to play this on as many receivers as possible and they are also aware of the fact that receivers vary in their capabilities. Service providers, on the other hand, will not send 2 separate content streams to play on 2 receivers on the same wire as this consumes precious bandwidth. 2 examples of streams that one may want to play on receivers that implement your draft are 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. 2. One may author SL packetized video where there was information in the SL header and this will be in the adaptation field. In additi= on, the authors will make sure that the video ES in the SL packet would be independently decodable by receivers that implemented your draft. This will require the ability to parse the first byte in the adaptation header and use it to offset where the video ES payload would be picked up. If your draft can accommodate this simple extension, then it will enab= le the receivers to play more content from the future and it will enable service providers to keep this in mind when they author MPEG-4 based content in the future. Regards to your concerns, 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition to the 16 byte RTP header. If we sent 1 VOP per packet, then it is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. This is very minimal. The FEC proposal proposes the same type of overhead. 2. The content authors will always make sure they follow all the other recommendations from your draft to make sure that the future content will play on receivers that implement the draft (such as sending data in decoding order, not splitting the headers etc). The only change from an implementation of today is the extra parsing of one byte before the ES payload to offset where the ES payload is picked up. 3. The change to your draft would to be add 2 fields after the CSRC and before the video ES. These would be 'adaptation length' and 'length (if adaptation length is greater than 0)'. The semantics will say, the first byte after CSRC will contain the length of adaptation field. If this length value is zero, then the video payload will start in the next byte. Otherwise, the video payload will start after the number of bytes indicated in the adaptation length field. The content of the adaptation field after the length is private and left for future extensions. Jan Vandermeer may also have some suggested changes to the draft, if t= his can be accommodated. Thank you for your kind patience. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] Sent: Thursday, September 14, 2000 12:38 PM To: IETF AVT Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi Subject: comments on in-band-signaling proposal Dear all experts, The authors of the Internet-Draft have discussed the issue of in-band-signaling proposal. We understand the importance of interoperability, however, we do not believe the specific proposal of a= n extra byte in the RTP header is a good solution. It is our common and f= irm desire that any proposal will not degrade the original intention, purpo= se and functionality of the RTP payload format. Especially, the following points are important. o Overhead caused by an extra RTP header The in-band-signaling proposal will cause at least one byte overhead pe= r each RTP packet. Since this RTP payload format may be used in very low bitrate applications such as mobile and analog modem, the overhead is a= serious problem. On the other hand, the ways suggested by Colin, Stepha= n, etc. of using different payload types will not cause any overhead probl= em. o Stability and reliability As was pointed out by many, there is no guaranty that receivers of ES-b= ased RTP payload format can receive SL-based RTP packets correctly, even if = the extra byte in the RTP header is added. It is dangerous to adopt such proposal at this moment without any guaranty. It is our strong desire t= hat only verified solution will be adopted in the RTP payload format specification. o Schedule There is no specific description of changes about the proposal, so far.= It is hard to accept such proposal. Even if the proposal has some value (although we doubt it), it should not be too late to adopt it in SL-based proposal, by keeping backword compatibility with ES-based RTP payload format. These points are very important to keep the original functionality of t= he proposal. Constructive comments are welcome, however, we cannot accept any proposals to harm the original intention and functionality. By this= point, it is hard to accept the in-band-signaling proposal which causes= overhead problem and which is not well verified. It should be remarked = that the alternatives proposed by IETF experts will not cause any such probl= ems. Kind regards, Yoshihiro Kikuchi and authors of the Intenet 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 Sat Sep 16 08:57:14 2000 From rem-conf-request@es.net Sat Sep 16 08:57:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13aKDN-0000wK-00; Sat, 16 Sep 2000 08:49:17 -0700 Received: from bodhi.zendo.com [205.187.71.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13aKDM-0000wA-00; Sat, 16 Sep 2000 08:49:16 -0700 Received: from vandys-pc.zendo.com (dialup-209.244.110.150.Seattle1.Level3.net [209.244.110.150]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8G7RPm18122; Sat, 16 Sep 2000 07:27:28 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id IAA00614; Sat, 16 Sep 2000 08:46:01 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009161546.IAA00614@vandys-pc.zendo.com> To: "W. Mark Townsley" <townsley@cisco.com> cc: Tmima Koren <tmima@cisco.com>, brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, l2tp@diameter.org, rem-conf@es.net Subject: Re: 0 byte L2TPHC header and implied PPPMUX In-reply-to: Your message of "Fri, 15 Sep 2000 12:13:28 EDT." <39C24AA8.12666180@cisco.com> Date: Sat, 16 Sep 2000 08:46:01 -0700 From: Andy Valencia <vandys@zendo.com> X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2317 Lines: 52 ["W. Mark Townsley" <townsley@cisco.com> writes:] >I would not dare to guess what will be next. Further, we may wish to >carry a uncompressed version of L2TP directly over IP at some point and >Ip protocol IDs are hard to come by. So, I think the static bits should >be put to better use, and a version field seems to be in order so that I >can sleep well at night. But but but... the approach I was trying to take was the version fields (being invariant) would belong in the L2TPHC *AVP*'s. So version--like any other negotiation-phase parameter--do not take bits from the payload. >This is what I would like to see in the first byte: > 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 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |T|P|I|J|x|x| ver | Session ID... | PPP packet... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is it just me, or is that a 9-bit byte? :-> >T,P,I,J are as defined in the l2tphc spec. ver is 1 (or 2 to match l2tp >if you like). If you want a version field for L2TPHC, let me define Yet Another AVP! >As for the compression of the first byte via l2tphc, as long as one side >can always force a peer to include this byte if need be then I am OK >with its removal. This has to be a very strong MUST though as it is the >local box that knows if it is going to need this first byte to multiplex >l2tphc with other l2tp or l2tphc versions, not its peer. It should be >very explicit that this is the case (e.g. An l2tphc implementation MUST >be able to send the header format requested by its peer... and then >perhaps even an explanation of why). Understood. I can be sure to strengthen that verbage. >Since we now have potentially more information in the first byte, >perhaps you should compress it away in a general manner. A new AVP which >defines what the static byte should look like would accomplish this. >e.g. something like this in the AVP: > 0 1 2 3 4 5 6 7 8 > +-+-+-+-+-+-+-+-+-+ > |T|P|I|J|x|x| ver | > +-+-+-+-+-+-+-+-+-+ Do you want the AVP to say "This is a version 0 format L2TPHC header"? Or do you actually want a general bit assignment description (bleh)? Andy From rem-conf Sat Sep 16 11:38:16 2000 From rem-conf-request@es.net Sat Sep 16 11:38:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13aMkz-0003Sk-00; Sat, 16 Sep 2000 11:32:09 -0700 Received: from shako.cisco.com [161.44.3.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 13aMkx-0003Rn-00; Sat, 16 Sep 2000 11:32:07 -0700 Received: from cisco.com (sj-dial-4-10.cisco.com [171.68.181.139]) by shako.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA00016; Sat, 16 Sep 2000 14:27:13 -0400 (EDT) Message-ID: <39C3BB88.26C56DD6@cisco.com> Date: Sat, 16 Sep 2000 14:27:20 -0400 From: "W. Mark Townsley" <townsley@cisco.com> X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Andy Valencia <vandys@zendo.com> CC: Tmima Koren <tmima@cisco.com>, brucet@cisco.com, dwing@cisco.com, Stephen Casner <casner@packetdesign.com>, l2tp@diameter.org, rem-conf@es.net Subject: Re: 0 byte L2TPHC header and implied PPPMUX References: <200009161546.IAA00614@vandys-pc.zendo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 3367 Lines: 75 Andy Valencia wrote: > > ["W. Mark Townsley" <townsley@cisco.com> writes:] > > >I would not dare to guess what will be next. Further, we may wish to > >carry a uncompressed version of L2TP directly over IP at some point and > >Ip protocol IDs are hard to come by. So, I think the static bits should > >be put to better use, and a version field seems to be in order so that I > >can sleep well at night. > > But but but... the approach I was trying to take was the version fields > (being invariant) would belong in the L2TPHC *AVP*'s. So version--like any > other negotiation-phase parameter--do not take bits from the payload. Unless we have another l2tp header variant come along that we would like to carry on protocol ID 115. l2tphc only leaves one bit to make the distinction. Utilizing AVPs to determine the l2tp version assumes that you can read the session ID, lookup state, and identify the l2tp version for that packet. This is fine when the session id is in a known location in the header, but if I have a completely different header from that defined in l2tphc I am out of luck. Since you are defining a completely new header anyway, I don't see much benefit it not allowing the Offset, Sequence and Length bits to be put to good use (or at least reserved for good use). Really, the ver field is no different than using the I and J bits to identify presence of the one or two byte session ID that l2tphc does now. We could simply leave the bits reserved or call them something else if you like. > > >This is what I would like to see in the first byte: > > 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 2 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |T|P|I|J|x|x| ver | Session ID... | PPP packet... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Is it just me, or is that a 9-bit byte? :-> Whoops. Just remove one of the x's here. > > >T,P,I,J are as defined in the l2tphc spec. ver is 1 (or 2 to match l2tp > >if you like). > > If you want a version field for L2TPHC, let me define Yet Another AVP! > > >As for the compression of the first byte via l2tphc, as long as one side > >can always force a peer to include this byte if need be then I am OK > >with its removal. This has to be a very strong MUST though as it is the > >local box that knows if it is going to need this first byte to multiplex > >l2tphc with other l2tp or l2tphc versions, not its peer. It should be > >very explicit that this is the case (e.g. An l2tphc implementation MUST > >be able to send the header format requested by its peer... and then > >perhaps even an explanation of why). > > Understood. I can be sure to strengthen that verbage. > > >Since we now have potentially more information in the first byte, > >perhaps you should compress it away in a general manner. A new AVP which > >defines what the static byte should look like would accomplish this. > >e.g. something like this in the AVP: > > 0 1 2 3 4 5 6 7 8 > > +-+-+-+-+-+-+-+-+-+ > > |T|P|I|J|x|x| ver | > > +-+-+-+-+-+-+-+-+-+ > > Do you want the AVP to say "This is a version 0 format L2TPHC header"? Or > do you actually want a general bit assignment description (bleh)? > > Andy From rem-conf Sun Sep 17 02:18:18 2000 From rem-conf-request@es.net Sun Sep 17 02:18:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13aaQO-00040W-00; Sun, 17 Sep 2000 02:07:48 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13aaQL-00040M-00; Sun, 17 Sep 2000 02:07:46 -0700 Received: from zvil (i0-2.j2.actcom.co.il [192.115.22.52]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id MAA28924; Sun, 17 Sep 2000 12:07:21 +0300 Received: by localhost with Microsoft MAPI; Sun, 17 Sep 2000 12:07:28 +0200 Message-ID: <01C0209F.D92D7DE0.zvil@csi.com> From: Zvi Lifshitz <zvil@csi.com> To: "'jan.vandermeer@philips.com'" <jan.vandermeer@philips.com>, "kiku@eel.rdc.toshiba.co.jp" <kiku@eel.rdc.toshiba.co.jp>, "rem-conf@es.net" <rem-conf@es.net>, "SNarasimhan@gi.com" <SNarasimhan@gi.com> Cc: "ZviL@optibase.com" <ZviL@optibase.com>, "csp@east.isi.edu" <csp@east.isi.edu>, "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Date: Sun, 17 Sep 2000 12:07:26 +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: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 2268 Lines: 56 With the exception that I didn't understand 5, this is ok with me. 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 -----Original Message----- From: jan.vandermeer@philips.com [SMTP:jan.vandermeer@philips.com] Sent: Saturday, September 16, 2000 12:47 PM To: kiku@eel.rdc.toshiba.co.jp; rem-conf@es.net; SNarasimhan@gi.com Cc: ZviL@optibase.com; csp@east.isi.edu; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: comments on in-band-signaling proposal This one did not came through yesterday, due to network problems Sam, Kikuchi-san, others While I am personally confident that it is possible to define a feasible and good solution, I share some of the concern of Kikuchi-san. Within MPEG there are far too many misunderstandings and disagreements to approve anything at this time. MPEG clearly needs more time to identify the most desirable approach. Therefore I would like to suggest the following way forward : 1) The IETF proceeds with the Kikuchi-san draft without implementing the in-band signaling proposal so as to meet the ITU deadline with minimum risk. 2) MPEG continues to consider the most desirable format for MPEG-4 ES and other MPEG-4 streams. 3) In the La Baule meeting MPEG concludes its discussion by producing its "generic" MPEG-4 over IP draft. 4) If MPEG at the La Baule meeting is confident about the feasibility and usefulness of a forward and backward compatible solution using the Kikuchi-san draft with in-band signaling, then MPEG will request IETF to start the publication process of an "update" of the Kikuchi-san draft, that will obsolete the current one. 5) In case of such "update", MPEG commits to neither change the "update" of the Kikuchi-san draft, nor elements in the "generic MPEG-4 A/V ES" draft that impact the forward and backward compatibility with the updated Kikuchi-san draft. Kind regards, Jan From rem-conf Sun Sep 17 07:10:38 2000 From rem-conf-request@es.net Sun Sep 17 07:10:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13af55-0007Jo-00; Sun, 17 Sep 2000 07:06:07 -0700 Received: from dns1.fp-group.gr.jp [210.175.105.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13af53-0007Jd-00; Sun, 17 Sep 2000 07:06:05 -0700 Received: from host (sdn-ar-002riprovP272.dialsprint.net [168.191.126.202]) by dns1.fp-group.gr.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id XAA08828; Sun, 17 Sep 2000 23:02:29 +0900 Message-Id: <200009171402.XAA08828@dns1.fp-group.gr.jp> From: "Frank levin" <wrk23@kozmail.com> Subject: You are Invited #2F74 To: in39e@dns1.fp-group.gr.jp X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VD.1712.3 Mime-Version: 1.0 Date: Sun, 17 Sep 2000 08:21:57 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" X-Mailing-List: <rem-conf@es.net> X-Loop: rem-conf@es.net Precedence: list Content-Length: 11300 Lines: 409 This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!doctype html public "-//w3c//dtd html 4=2E0 transitional//en"> <html> <head> <title>Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for biographical
inclusion in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

P=2ES=2E There is no cost or obligation to be included in the Internation= al
Executive Guild Registry=2E For accuracy and publication purposes, we ask=
you to fill in the brief bit of information in the registration form
below=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From rem-conf Sun Sep 17 15:26:14 2000 From rem-conf-request@es.net Sun Sep 17 15:26:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ammx-0006F6-00; Sun, 17 Sep 2000 15:19:55 -0700 Received: from (penguin.poly.edu) [128.238.35.86] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ammw-0006Eg-00; Sun, 17 Sep 2000 15:19:54 -0700 Received: (from icme2000@localhost) by penguin.poly.edu (8.8.7/8.8.7) id KAA07636; Sun, 17 Sep 2000 10:22:55 -0400 Date: Sun, 17 Sep 2000 10:22:55 -0400 Message-Id: <200009171422.KAA07636@penguin.poly.edu> From: icme2000@penguin.poly.edu Bcc: Subject: Call For Papers To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 5112 Lines: 135 International Federation for Information Processing CMS 2001 Communications and Multimedia Security Joint working conference IFIP TC6 and TC11 May 21-22, 2001 GMD Darmstadt, Germany GMD-German National Research Center for Information Technology, Institute IPSI - Dept. Mobile Interactive Media Darmstadt, Germany and Darmstadt Univ. of Technology, Industrial Process and System Communications, Dept.of Electrical Engineering & Information Technology -------------------------------------------------------------------------------- Call For Papers GOALS and TOPICS of INTEREST CMS 2001 is the sixth working conference on Communications and Multimedia Security since 1995. State-of-the-art issues as well as practical experiences and new trends in the areas will be the topics of interest again, as proven by preceding conferences. This year the organisers want to focus the attention on watermarking and copyright protection for e-commerce applications and multimedia data. We want to evaluate the progress of digital watermarking, the robustness and the practical usage for authentication and also for integrity checks. Topics of interest include, but are not limited to Applied cryptography Biometry Combined multimedia security Communications systems security Cryptography steganography watermarking aspects Digital watermarking applications Digital watermarking technologies Electronic commerce and digital signatures Internet, intranet and extranet security Legal, social and ethical aspects of communication systems security Mobile communications security Multimedia systems security Possible attacks on multimedia systems SUBMISSION DETAILS Authors are strongly encouraged to submit their papers electronically. Please email your submission in postscript or pdf format to: cms2001@darmstadt.gmd.de Electronic submissions must be received by December 4, 2000. Authors unable to submit electronically are invited to contact us (cms2001@darmstadt.gmd.de) or send the papers to the postal address below. Authors are asked to submit original papers only. Papers that have previously been published and papers that are currently being considered for publication by another journal or conference are not eligible. All submitted papers will be refereed for correctness, originality, relevance to the conference, and quality of presentation. All submissions must be in English. The paper must be anonymous, with no author names, affiliations, acknowledgements, or obvious references. It should begin with a title, a short abstract, and a list of key words, and its introduction should summarise the contributions of the paper at a level appropriate for a non-specialist reader. The paper should be at most 5000 words long. A full page figure is 500 words. All submitted papers will be refereed by at least three members of the International Program Committee according to the standard blind refereeing procedures. The Conference Proceedings will be published by an international publisher; copies of the proceedings will be available at the conference. Notification of acceptance or rejection will be sent to authors by 15th of January. Authors of accepted papers must guarantee that their paper will be presented at the conference. -------------------------------------------------------------------------------- Important dates : Submission Deadline: December 4, 2000 Notification: January 15, 2001 Final camera-ready version: February 28, 2001 Conference: May 20-21, 2001 To submit a paper, or for further details, please contact: Yvonne Sobon German National Research Center for Information Technology Institute IPSI - Dept. Mobile Interactive Media Dolivostr.15 D-64293 Darmstadt Germany tel: +49-6151-869-847 | fax:-6847 cms2001@darmstadt.gmd.de For further details see http://www.darmstadt.gmd.de/mobile/cms/start.html -------------------------------------------------------------------------------- Program Committee Chair: Chair: R. Steinmetz Co-Chair: J. Dittmann Program Committee: I. Cox, NEC Research Institut, USA E. Delp, Purdue University, USA J. Fridrich, Center for Intelligent Systems SUNY Binghamton, USA D. Gollmann, Microsoft Research, UK R. Grimm, GMD SIT, Germany P. Horster, Universitaet Klagenfurt, Austria T. Kalker, Philips Research Eindhoven, The Netherlands K. Keus, BSI, Germany P. Kraaibeek, ConSecur, Germany D. Kundur, University of Toronto, Canada N. Memon, Polytechnic University Brooklyn, USA K. Nahrstedt, University of Illinois at Urbana-Champaign, USA G. Pernul, University of Essen, Germany F. Petitcolas, Microsoft, UK B. Preneel, Katholieke Universiteit Leuven, Belgium C. Schmidt, Software Professional GmbH & Co. KG, Germany J. Schwenk, Telekom, Germany A. Tirkel, Scientific Technology, Australia P. Wohlmacher, Universitaet Klagenfurt, Austria R. Zuccherato, Entrust Technologies, Canada Organising Committee Chair: Chair: J. Dittmann Co-Chair: M. Steinebach Organising Committee: Yvonne Sobon Main Organiser: IFIP TC 11 and TC 6 From rem-conf Mon Sep 18 03:48:47 2000 From rem-conf-request@es.net Mon Sep 18 03:48:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ayMS-0005xs-00; Mon, 18 Sep 2000 03:41:20 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ayML-0005xV-00; Mon, 18 Sep 2000 03:41:16 -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 TAA26795; Mon, 18 Sep 2000 19:39:09 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id TAA17636; Mon, 18 Sep 2000 19:39:09 +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 TAA16056; Mon, 18 Sep 2000 19:39:08 +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 TAA00697; Mon, 18 Sep 2000 19:39:08 +0900 (JST) Message-ID: <008f01c0215c$b1ebc3a0$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: , , Cc: , , <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <0056890014123034000002L942*@MHS> Subject: Re: comments on in-band-signaling proposal Date: Mon, 18 Sep 2000 19:39:16 +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 Content-Length: 8775 Lines: 210 Dear Jan and all, Following suggestion 1, the authors will produce an updated Internet-Draft of MPEG-4 Audio/Visual RTP soon with reflecting comments raised and agreed during the WG last call period. It does not included in-band signaling proposal. It is too early for us to comment on suggestions 2-5, because we have not seen detailed proposal. In any case, we cannot accept any disadvantage (overhead, efficiency, risk, documentation, ...) compared to the current spec. We should also be care that we will not fall into "an MPEG only solution". But if we can keep on these, maybe we will have a good solution in the end. Kind regards, Yoshihiro Kikuchi ----- Original Message ----- From: To: ; ; Cc: ; ; <4on2andIP-sys@advent.ee.columbia.edu> Sent: Saturday, September 16, 2000 7:47 PM Subject: RE: comments on in-band-signaling proposal > This one did not came through yesterday, due to network problems > Sam, Kikuchi-san, others > While I am personally confident that it is possible to define a feasible and > good solution, I share some of the concern of Kikuchi-san. Within MPEG there > are far too many misunderstandings and disagreements to approve anything at > this time. MPEG clearly needs more time to identify the most desirable > approach. > > Therefore I would like to suggest the following way forward : > > 1) The IETF proceeds with the Kikuchi-san draft without implementing the > in-band signaling proposal so as to meet the ITU deadline with minimum risk. > 2) MPEG continues to consider the most desirable format for MPEG-4 ES and > other MPEG-4 streams. > 3) In the La Baule meeting MPEG concludes its discussion by producing its > "generic" MPEG-4 over IP draft. > 4) If MPEG at the La Baule meeting is confident about the feasibility and > usefulness of a forward and backward compatible solution using the > Kikuchi-san draft with in-band signaling, then MPEG will request IETF to > start the publication process of an "update" of the Kikuchi-san draft, that > will obsolete the current one. > 5) In case of such "update", MPEG commits to neither change the "update" of > the Kikuchi-san draft, nor elements in the "generic MPEG-4 A/V ES" draft > that impact the forward and backward compatibility with the updated > Kikuchi-san draft. > > Kind regards, > > Jan > > -----Original Message----- > From: SNarasimhan@gi.com [mailto:SNarasimhan@gi.com] > Sent: vrijdag, 15 september, 2000 02:15 > To: Jan vanderMeer; rem-conf@es.net; kiku@eel.rdc.toshiba.co.jp > Cc: 4on2andIP-sys@advent.ee.columbia.edu; csp@east.isi.edu; > ZviL@optibase.com > Subject: RE: comments on in-band-signaling proposal > > > Dear Kikuchi-San and experts, > > I am coming from a world where content creators and > servers are very 'receiver-aware' and will not do anything > in the content creation that will crash receivers. In this > regard, the service providers who use the content want to > play this on as many receivers as possible and they are also > aware of the fact that receivers vary in their capabilities. > Service providers, on the other hand, will not send 2 separate > content streams to play on 2 receivers on the same wire as this > consumes precious bandwidth. > > 2 examples of streams that one may want to play on receivers > that implement your draft are > > 1. A video ES that required CTS (in the RTP header) and DTS (which > could be in the adaptation field). This may be needed for receivers > that implement MPEG buffer models. This stream can play on > receivers that implement your draft as it has a bigger buffer > and does not need DTS, as long as your draft enabled these > receivers to use the adaptation length field to offset where > the video ES payload was picked up. > 2. One may author SL packetized video where there was information > in the SL header and this will be in the adaptation field. In addition, > the authors will make sure that the video ES in the SL packet > would be independently decodable by receivers that implemented your > draft. This will require the ability to parse the first byte in > the adaptation header and use it to offset where the video ES > payload would be picked up. > > If your draft can accommodate this simple extension, then it will enable > the receivers to play more content from the future and it will enable > service providers to keep this in mind when they author MPEG-4 based > content in the future. > > Regards to your concerns, > > 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition > to the 16 byte RTP header. If we sent 1 VOP per packet, then it > is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. > This is very minimal. The FEC proposal proposes the same type > of overhead. > 2. The content authors will always make sure they follow all the > other recommendations from your draft to make sure that the > future content will play on receivers that implement the draft > (such as sending data in decoding order, not splitting the headers > etc). The only change from an implementation of today is the > extra parsing of one byte before the ES payload to offset where > the ES payload is picked up. > 3. The change to your draft would to be add 2 fields after the CSRC > and before the video ES. These would be > 'adaptation length' and > 'length (if adaptation length is greater than 0)'. > The semantics will say, the first byte after CSRC will contain the > length of adaptation field. If this length value is zero, then the > video payload will start in the next byte. Otherwise, the video > payload will start after the number of bytes indicated in the > adaptation length field. The content of the adaptation field after > the length is private and left for future extensions. > > Jan Vandermeer may also have some suggested changes to the draft, if this > can be accommodated. Thank you for your kind patience. > > Best Regards > Sam Narasimhan > Motorola > > -----Original Message----- > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > Sent: Thursday, September 14, 2000 12:38 PM > To: IETF AVT > Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi > Subject: comments on in-band-signaling proposal > > > Dear all experts, > > > The authors of the Internet-Draft have discussed the issue of > in-band-signaling proposal. We understand the importance of > interoperability, however, we do not believe the specific proposal of an > extra byte in the RTP header is a good solution. It is our common and firm > desire that any proposal will not degrade the original intention, purpose > and functionality of the RTP payload format. > > Especially, the following points are important. > > o Overhead caused by an extra RTP header > The in-band-signaling proposal will cause at least one byte overhead per > each RTP packet. Since this RTP payload format may be used in very low > bitrate applications such as mobile and analog modem, the overhead is a > serious problem. On the other hand, the ways suggested by Colin, Stephan, > etc. of using different payload types will not cause any overhead problem. > > o Stability and reliability > As was pointed out by many, there is no guaranty that receivers of ES-based > RTP payload format can receive SL-based RTP packets correctly, even if the > extra byte in the RTP header is added. It is dangerous to adopt such > proposal at this moment without any guaranty. It is our strong desire that > only verified solution will be adopted in the RTP payload format > specification. > > o Schedule > There is no specific description of changes about the proposal, so far. It > is hard to accept such proposal. Even if the proposal has some value > (although we doubt it), it should not be too late to adopt it in > SL-based proposal, by keeping backword compatibility with ES-based RTP > payload format. > > > These points are very important to keep the original functionality of the > proposal. Constructive comments are welcome, however, we cannot accept > any proposals to harm the original intention and functionality. By this > point, it is hard to accept the in-band-signaling proposal which causes > overhead problem and which is not well verified. It should be remarked that > the alternatives proposed by IETF experts will not cause any such problems. > > > Kind regards, > Yoshihiro Kikuchi > and authors of the Intenet 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 Mon Sep 18 05:31:08 2000 From rem-conf-request@es.net Mon Sep 18 05:31:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13b00e-0000My-00; Mon, 18 Sep 2000 05:26:56 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13b00V-0000Mn-00; Mon, 18 Sep 2000 05:26:48 -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 VAA28237; Mon, 18 Sep 2000 21:26:22 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id VAA21189; Mon, 18 Sep 2000 21:26:22 +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 VAA09293; Mon, 18 Sep 2000 21:26:21 +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 VAA06249; Mon, 18 Sep 2000 21:26:21 +0900 (JST) Message-ID: <01c101c0216b$ac58ec60$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" Subject: New I/D submitted for MPEG-4 A/V RTP Date: Mon, 18 Sep 2000 21:26: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 Content-Length: 863 Lines: 35 Dear all, I have submitted a new version (-04) of the internet draft of MPEG-4 Audio/Visual RTP payload format to reflect comments raised and agreed during the WG last call period. The document should be available soon at the internet draft archive. The following is the summary of changes from the previous version (-03). 1) Default value of MIME type 2) Editorial update of abstract and introduction 3) Clarification related to multiple VOPs concatenation (timestamp, fragmentation rule 4) 4) LATM related modification (section 1.2, 4.2) 5) Some other editorial clarifications The authors would like to thank for those who raised comments. Best regards, Yoshihiro Kikuchi ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Mon Sep 18 07:27:54 2000 From rem-conf-request@es.net Mon Sep 18 07:27:52 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13b1oi-0001jr-00; Mon, 18 Sep 2000 07:22:44 -0700 Received: from pool-209-138-168-39-nwrk.grid.net ([209.138.168.39] helo=209.138.168.39) by mail2.es.net with smtp (Exim 1.92 #1) id 13b1od-0001jW-00; Mon, 18 Sep 2000 07:22:40 -0700 From: 998766financebuyout@888.nu To: Subject: ___We have foreigners who want to buy or finance your business/speak to them right now Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 18 Sep 2000 07:22:40 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2560 Lines: 90 As per your inquiry.................phone calls only..... OUR LIST OF FOREIGNERS SEEKING TO BUY OR FINANCE YOUR BUSINESS.....................can be on your desk in 10 minutes. With phone numbers, fax numbers and emails ready to go. for an absolutely free total inspection.............. NO CREDIT CARD NECESSARY: List costs $55.00 if you decide to buy after total inspection. Our list includes the most ready to invest venture capital people as well as private investors/buyers and just plain individuals seeking to get into the business world by buying or financing a business. PLEASE READ OUR VERY EASY RULES . 1. This is a list of 277 persons and organizations worldwide seeking to finance and or buy your business Venture capital people as well. NONE charges any type of fee. They want you to contact them. 2. Our lists include phone numbers,fax numbers, and emails. We have been in the business 7 years. Emailing these names on our list your business description works best. And it's free. 3. If you don't want to email but prefer to fax Several websites offer FREE WORLDWIDE FAXING We will send you the site addresses when you decide to buy. But these buyers and finance people love email so why bother. 4. Our list costs $55.00. 5. When you decide to buy, you will call us back for our company info on sending in your check. This of course is After you call and check out the names on our list as thoroughly as you care to , but BEFORE you email or fax your business profile to these persons seeking to buy or finance your business. HERE AGAIN ARE THE RULES. 1. Call anybody on our list. ( BUT don't fax or email them your business description) Thoroughly satisfy yourself the list is everything we say it is. We want you to pay for the calls to these people to show that you are as "real as we are ". DON"T FAX or EMAIL any business description until you decide to buy our list. Do call all you want. 2. If you decide to buy our list call us and we will email you our company info on mailing in your check. We have been in the business 7 years and know many people on the list. We assure you if you screw us we will find out and mass email to all the people on the list what you did. None will deal with you. As is customary the list is also seeded to prevent misuse and resale. Phone calls only.......... Susan McCoy 732-247-3173 Scott Allen Export Sales 36 Heather Drive Somerset, New Jersey 08873 U.S.A. We have foreigners who want to buy or finance your business/speak to them right now... From rem-conf Mon Sep 18 14:36:29 2000 From rem-conf-request@es.net Mon Sep 18 14:36:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13b8WS-0000A5-00; Mon, 18 Sep 2000 14:32:20 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13b8WR-00009v-00; Mon, 18 Sep 2000 14:32:19 -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 OAA10339 for ; Mon, 18 Sep 2000 14:32:17 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 18 Sep 2000 14:32:15 -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 OAA18906; Mon, 18 Sep 2000 14:32:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A10@l-rmhs.lannion.cnet.fr> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A10@l-rmhs.lannion.cnet.fr> Date: Mon, 18 Sep 2000 14:30:38 -0700 To: CURET Dominique FTRD/DMI/REN From: Dave Singer Subject: Re: Pre-MPEG meeting for the '4onIP' AHG 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 Content-Length: 648 Lines: 24 At 6:01 PM +0200 9/13/00, CURET Dominique FTRD/DMI/REN wrote: >Dear all, dear Young-Kwon, > >we are supposed to meet on Saturday(21/10) and Sunday (22/10) >before the MPEG meeting in La Baule. > >Can we say something like: > Saturday from 14 to 2000 > Sunday from 0900 to 1800 >Or only the Sunday from 0900 to 1800 > >comments whoa! I'm completely snowed by the mail on this...and read as fast as I can, I am not catching up. hence no comment from me yet! I'll be in La Baule via SFO, JFK, LHR, CDG, CDG TGV, Nantes TGV, La Baule SNCF on Saturday night, if all those connections work... -- David Singer Apple Computer/QuickTime From rem-conf Mon Sep 18 19:22:59 2000 From rem-conf-request@es.net Mon Sep 18 19:22:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bCuK-0003E6-00; Mon, 18 Sep 2000 19:13:16 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bCuJ-0003Dw-00; Mon, 18 Sep 2000 19:13:15 -0700 Received: from young ([150.183.107.207]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000091911142627:439 ; Tue, 19 Sep 2000 11:14:26 +0900 Message-ID: <007801c021df$1ea02810$cf6bb796@young> Reply-To: "LIM, Young-Kwon" From: "LIM, Young-Kwon" To: "CURET Dominique FTRD/DMI/REN" , "Dave Singer" Cc: <4on2andIP-sys@advent.ee.columbia.edu>, References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A10@l-rmhs.lannion.cnet.fr> Subject: Re: Pre-MPEG meeting for the '4onIP' AHG Date: Tue, 19 Sep 2000 11:12:54 +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-09-19 11:14:26 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-09-19 11:14:43 AM, Serialize complete at 2000-09-19 11:14:43 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 684 Lines: 12 RGVhciBhbGwsDQoNCk4zNDU4IHNheXMgdGhhdCB0aGlzIEFIRyB3aWxsIG1lZXQgb24gU2F0dXJk YXkgYmVyZm9yZSBMYSBCYXVsZSBtZWV0aW5nLg0KTXkgcGxhbiB3YXMgdG8gbWVldCBvbiBTYXR1 cmRheSBhZnRlcm5vb24gYW5kIGV2ZW5pbmcgYW5kIGFsc28gb24gU3VuZGF5IGlmIG5lZWRlZC4N CldlIGNhbiBzdGFydCBvbiBTYXR1cmRheSBldmVuaW5nIGlmIG1vc3Qgb2YgdGhlIG1lbWViZXJz IHdpbGwgYXJyaXZlIHRoZXJlIGxhdGVseS4NCg0KPiANCj4gSSdsbCBiZSBpbiBMYSBCYXVsZSB2 aWEgU0ZPLCBKRkssIExIUiwgQ0RHLCBDREcgVEdWLCBOYW50ZXMgVEdWLCBMYSANCj4gQmF1bGUg U05DRiBvbiBTYXR1cmRheSBuaWdodCwgaWYgYWxsIHRob3NlIGNvbm5lY3Rpb25zIHdvcmsuLi4N Cg0KUG9vciBEYXZpZC4gV2hhdCBhYm91dCB2aWEgU0VMLCBDREcsIGFuZCBzbyBvbj8NCkdvb2Qg bHVjayBhbmQgc2FmZSBqb3VybmV5IQ0KDQpTaW5jZXJlbHksDQpZb3VuZy4NCg== From rem-conf Mon Sep 18 20:29:34 2000 From rem-conf-request@es.net Mon Sep 18 20:29:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bE3B-0004V2-00; Mon, 18 Sep 2000 20:26:29 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bE39-0004TT-00; Mon, 18 Sep 2000 20:26:27 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JUBXQ7EWCAEBXFMD@GI.COM> for rem-conf@es.net; Mon, 18 Sep 2000 20:25:15 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 20:24:52 -0400 Content-return: allowed Date: Mon, 18 Sep 2000 23:27:58 -0400 From: "Narasimhan, Sam (SD-EX)" Subject: RE: comments on in-band-signaling proposal To: 'Yoshihiro Kikuchi' , jan.vandermeer@philips.com, rem-conf@es.net, SNarasimhan@GI.COM Cc: ZviL@optibase.com, csp@east.isi.edu, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239BE@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 Content-Length: 9517 Lines: 231 Dear Jan and Kikuchi-San, I support Jan's proposal and I am sorry to see no support for this from Kikuchi-San. MPEG will define a format for carriage of MPEG-4 ES only which will require CTS and DTS (like we did for MPEG-2 carriage) and this will not be backward compatible with Kikuchi-San's draft. If so, then one has to choose a more generic proposal. Best Regards Sam Narasimhan Motorola -----Original Message----- From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] Sent: Monday, September 18, 2000 3:39 AM To: jan.vandermeer@philips.com; rem-conf@es.net; SNarasimhan@GI.COM Cc: ZviL@optibase.com; csp@east.isi.edu; 4on2andIP-sys@advent.ee.columbia.edu; Yoshihiro Kikuchi Subject: Re: comments on in-band-signaling proposal Dear Jan and all, Following suggestion 1, the authors will produce an updated Internet-Draft of MPEG-4 Audio/Visual RTP soon with reflecting comments raised and agreed during the WG last call period. It does not included in-band signaling proposal. It is too early for us to comment on suggestions 2-5, because we have not seen detailed proposal. In any case, we cannot accept any disadvantage (overhead, efficiency, risk, documentation, ...) compared to the current spec. We should also be care that we will not fall into "an MPEG only solution". But if we can keep on these, maybe we will have a good solution in the end. Kind regards, Yoshihiro Kikuchi ----- Original Message ----- From: To: ; ; Cc: ; ; <4on2andIP-sys@advent.ee.columbia.edu> Sent: Saturday, September 16, 2000 7:47 PM Subject: RE: comments on in-band-signaling proposal > This one did not came through yesterday, due to network problems > Sam, Kikuchi-san, others > While I am personally confident that it is possible to define a feasible and > good solution, I share some of the concern of Kikuchi-san. Within MPEG there > are far too many misunderstandings and disagreements to approve anything at > this time. MPEG clearly needs more time to identify the most desirable > approach. > > Therefore I would like to suggest the following way forward : > > 1) The IETF proceeds with the Kikuchi-san draft without implementing the > in-band signaling proposal so as to meet the ITU deadline with minimum risk. > 2) MPEG continues to consider the most desirable format for MPEG-4 ES and > other MPEG-4 streams. > 3) In the La Baule meeting MPEG concludes its discussion by producing its > "generic" MPEG-4 over IP draft. > 4) If MPEG at the La Baule meeting is confident about the feasibility and > usefulness of a forward and backward compatible solution using the > Kikuchi-san draft with in-band signaling, then MPEG will request IETF to > start the publication process of an "update" of the Kikuchi-san draft, that > will obsolete the current one. > 5) In case of such "update", MPEG commits to neither change the "update" of > the Kikuchi-san draft, nor elements in the "generic MPEG-4 A/V ES" draft > that impact the forward and backward compatibility with the updated > Kikuchi-san draft. > > Kind regards, > > Jan > > -----Original Message----- > From: SNarasimhan@gi.com [mailto:SNarasimhan@gi.com] > Sent: vrijdag, 15 september, 2000 02:15 > To: Jan vanderMeer; rem-conf@es.net; kiku@eel.rdc.toshiba.co.jp > Cc: 4on2andIP-sys@advent.ee.columbia.edu; csp@east.isi.edu; > ZviL@optibase.com > Subject: RE: comments on in-band-signaling proposal > > > Dear Kikuchi-San and experts, > > I am coming from a world where content creators and > servers are very 'receiver-aware' and will not do anything > in the content creation that will crash receivers. In this > regard, the service providers who use the content want to > play this on as many receivers as possible and they are also > aware of the fact that receivers vary in their capabilities. > Service providers, on the other hand, will not send 2 separate > content streams to play on 2 receivers on the same wire as this > consumes precious bandwidth. > > 2 examples of streams that one may want to play on receivers > that implement your draft are > > 1. A video ES that required CTS (in the RTP header) and DTS (which > could be in the adaptation field). This may be needed for receivers > that implement MPEG buffer models. This stream can play on > receivers that implement your draft as it has a bigger buffer > and does not need DTS, as long as your draft enabled these > receivers to use the adaptation length field to offset where > the video ES payload was picked up. > 2. One may author SL packetized video where there was information > in the SL header and this will be in the adaptation field. In addition, > the authors will make sure that the video ES in the SL packet > would be independently decodable by receivers that implemented your > draft. This will require the ability to parse the first byte in > the adaptation header and use it to offset where the video ES > payload would be picked up. > > If your draft can accommodate this simple extension, then it will enable > the receivers to play more content from the future and it will enable > service providers to keep this in mind when they author MPEG-4 based > content in the future. > > Regards to your concerns, > > 1. The overhead is 1 byte/RTP packet and this is a 6.25% addition > to the 16 byte RTP header. If we sent 1 VOP per packet, then it > is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead. > This is very minimal. The FEC proposal proposes the same type > of overhead. > 2. The content authors will always make sure they follow all the > other recommendations from your draft to make sure that the > future content will play on receivers that implement the draft > (such as sending data in decoding order, not splitting the headers > etc). The only change from an implementation of today is the > extra parsing of one byte before the ES payload to offset where > the ES payload is picked up. > 3. The change to your draft would to be add 2 fields after the CSRC > and before the video ES. These would be > 'adaptation length' and > 'length (if adaptation length is greater than 0)'. > The semantics will say, the first byte after CSRC will contain the > length of adaptation field. If this length value is zero, then the > video payload will start in the next byte. Otherwise, the video > payload will start after the number of bytes indicated in the > adaptation length field. The content of the adaptation field after > the length is private and left for future extensions. > > Jan Vandermeer may also have some suggested changes to the draft, if this > can be accommodated. Thank you for your kind patience. > > Best Regards > Sam Narasimhan > Motorola > > -----Original Message----- > From: Yoshihiro Kikuchi [mailto:kiku@eel.rdc.toshiba.co.jp] > Sent: Thursday, September 14, 2000 12:38 PM > To: IETF AVT > Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi > Subject: comments on in-band-signaling proposal > > > Dear all experts, > > > The authors of the Internet-Draft have discussed the issue of > in-band-signaling proposal. We understand the importance of > interoperability, however, we do not believe the specific proposal of an > extra byte in the RTP header is a good solution. It is our common and firm > desire that any proposal will not degrade the original intention, purpose > and functionality of the RTP payload format. > > Especially, the following points are important. > > o Overhead caused by an extra RTP header > The in-band-signaling proposal will cause at least one byte overhead per > each RTP packet. Since this RTP payload format may be used in very low > bitrate applications such as mobile and analog modem, the overhead is a > serious problem. On the other hand, the ways suggested by Colin, Stephan, > etc. of using different payload types will not cause any overhead problem. > > o Stability and reliability > As was pointed out by many, there is no guaranty that receivers of ES-based > RTP payload format can receive SL-based RTP packets correctly, even if the > extra byte in the RTP header is added. It is dangerous to adopt such > proposal at this moment without any guaranty. It is our strong desire that > only verified solution will be adopted in the RTP payload format > specification. > > o Schedule > There is no specific description of changes about the proposal, so far. It > is hard to accept such proposal. Even if the proposal has some value > (although we doubt it), it should not be too late to adopt it in > SL-based proposal, by keeping backword compatibility with ES-based RTP > payload format. > > > These points are very important to keep the original functionality of the > proposal. Constructive comments are welcome, however, we cannot accept > any proposals to harm the original intention and functionality. By this > point, it is hard to accept the in-band-signaling proposal which causes > overhead problem and which is not well verified. It should be remarked that > the alternatives proposed by IETF experts will not cause any such problems. > > > Kind regards, > Yoshihiro Kikuchi > and authors of the Intenet 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 Mon Sep 18 23:35:44 2000 From rem-conf-request@es.net Mon Sep 18 23:35:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bGwl-0006Wx-00; Mon, 18 Sep 2000 23:32:03 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13bGwh-0006Wl-00; Mon, 18 Sep 2000 23:32:00 -0700 Received: from zvil (i0-12.j2.actcom.co.il [192.115.22.105]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id JAA16749; Tue, 19 Sep 2000 09:31:17 +0300 Received: by localhost with Microsoft MAPI; Tue, 19 Sep 2000 09:31:20 +0200 Message-ID: <01C0221C.5E69E200.zvil@csi.com> From: Zvi Lifshitz To: "'Narasimhan, Sam (SD-EX)'" , "'Yoshihiro Kikuchi'" , "jan.vandermeer@philips.com" , "rem-conf@es.net" Cc: "ZviL@optibase.com" , "csp@east.isi.edu" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Date: Tue, 19 Sep 2000 09:31:19 +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 Content-Length: 1082 Lines: 33 [Narasimhan, Sam (SD-EX):] I support Jan's proposal and I am sorry to see no support for this from Kikuchi-San. MPEG will define a format for carriage of MPEG-4 ES only which will require CTS and DTS (like we did for MPEG-2 carriage) and this will not be backward compatible with Kikuchi-San's draft. If so, then one has to choose a more generic proposal. [Reply:] In Paris we said that in cases when DTS is not required (we never said it would always be required as you seem to propose) then it can be backward compatible. 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-461787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Tue Sep 19 00:26:00 2000 From rem-conf-request@es.net Tue Sep 19 00:25:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bHm1-0007kE-00; Tue, 19 Sep 2000 00:25:01 -0700 Received: from talos.forthnet.gr (forthnet.gr) [193.92.150.21] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bHly-0007jt-00; Tue, 19 Sep 2000 00:24:59 -0700 Received: from oemcomputer.unipi.gr (assinik.ath.forthnet.gr [193.92.136.196]) by forthnet.gr (8.8.8/8.8.5) with ESMTP id IAA22277; Tue, 19 Sep 2000 08:40:55 +0300 Message-Id: <4.3.1.0.20000917201353.00a91c40@assinik.ath.forthnet.gr/popper.forthnet.gr@127.0.0.1> X-Sender: ASSINIK@assinik.ath.forthnet.gr/popper.forthnet.gr@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 17 Sep 2000 20:14:00 +0300 To: assinik@unipi.gr From: Nikitas Assimakopoulos Subject: Special Issue of JASS journal Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_936996==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2783 Lines: 71 --=====================_936996==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed ------------------------------------------------------------------- We extend our sincere apologies if this announcement would disturb your inbox with multiple copies of it. ------------------------------------------------------------------- Journal of Applied Systems Studies Methodologies and Applications for Systems Approaches ' JASS ' http://www.unipi.gr/jass/ JASS announces that the Special Issue on "Virtual Organizations and E-Commerce Applications" has been scheduled. If you are interested in the above special issue title AND for the current issues, please visit JASS web site. For submission of papers and special issue proposals consult the "Aims & Scope" of JASS. --=====================_936996==_.ALT Content-Type: text/html; charset="us-ascii"
-------------------------------------------------------------------
  We extend our sincere apologies if this announcement
   would disturb your inbox with multiple copies of it.
-------------------------------------------------------------------

Journal of Applied Systems Studies
      Methodologies and Applications for Systems Approaches
                        ' JASS '  

                  http://www.unipi.gr/jass/


JASS announces that the Special Issue on  "Virtual Organizations and E-Commerce Applications"  has been scheduled.

If you are interested in the above special issue title  AND  for the current issues, please visit  JASS  web site.
For submission of papers and special issue proposals consult the "Aims & Scope" of  JASS.



 --=====================_936996==_.ALT-- From rem-conf Tue Sep 19 03:40:03 2000 From rem-conf-request@es.net Tue Sep 19 03:40:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bKl5-0002Ch-00; Tue, 19 Sep 2000 03:36:16 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bKl4-0002CX-00; Tue, 19 Sep 2000 03:36:14 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11150; Tue, 19 Sep 2000 06:36:09 -0400 (EDT) Message-Id: <200009191036.GAA11150@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-04.txt Date: Tue, 19 Sep 2000 06:36:09 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2755 Lines: 85 --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-04.txt Pages : 19 Date : 18-Sep-00 This document describes respective 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-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mpeg4-es-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000918140632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000918140632.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Sep 19 09:14:44 2000 From rem-conf-request@es.net Tue Sep 19 09:14:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bPtz-00064L-00; Tue, 19 Sep 2000 09:05:47 -0700 Received: from (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bPtx-00063f-00; Tue, 19 Sep 2000 09:05:45 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 09:05:45 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B14176D4@HAPPY> From: Bill Nowicki To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Pre-MPEG meeting for the '4onIP' AHG Date: Tue, 19 Sep 2000 09:05:39 -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 Content-Length: 449 Lines: 10 Ah, is there a rule that people going to standards meetings must travel on every mode of transportation that has an acronym? Probably would not be allowed to go to a "group" meeting in a country that just has "trains" and "airports"? Sorry I could not resist. Seriously, we appreciate standards efforts, but would appreciate the acronyms spelled out once in a while for the benefit of those of us unable to attend the meetings in person. Thanks. From rem-conf Tue Sep 19 09:39:36 2000 From rem-conf-request@es.net Tue Sep 19 09:39:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bQMz-000728-00; Tue, 19 Sep 2000 09:35:45 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13bQMw-00071s-00; Tue, 19 Sep 2000 09:35:42 -0700 Received: from zvil (i0-12.j2.actcom.co.il [192.115.22.105]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id TAA28186; Tue, 19 Sep 2000 19:35:42 +0300 Received: by localhost with Microsoft MAPI; Tue, 19 Sep 2000 19:35:34 +0200 Message-ID: <01C02270.C7A5FE80.zvil@csi.com> From: Zvi Lifshitz To: "'Bill Nowicki'" , "rem-conf@es.net" , "4on2andIP-sys@advent.ee.columbia.edu" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Pre-MPEG meeting for the '4onIP' AHG Date: Tue, 19 Sep 2000 19:35:33 +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 Content-Length: 1527 Lines: 38 You mean these: I'll be in La Baule via SFO, JFK, LHR, CDG, CDG TGV, Nantes TGV, La Baule SNCF on Saturday night, if all those connections work... ??? Well, those who are unable to attend the meeting in person don't need these acronyms spelled out... z soon the whole world will STREAM (but hopefully we'll still get through these ;-) ================================================================== Zvi Lifshitz Phone +972(2)679-4788 zvil@optibase.com Fax +972(2)679-4789 Optibase Ltd. GSM: +972-54-461787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 ================================================================== > Come see us at: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Bill Nowicki [SMTP:BNowicki@Omneon.com] Sent: Tuesday, September 19, 2000 6:06 PM To: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Pre-MPEG meeting for the '4onIP' AHG Ah, is there a rule that people going to standards meetings must travel on every mode of transportation that has an acronym? Probably would not be allowed to go to a "group" meeting in a country that just has "trains" and "airports"? Sorry I could not resist. Seriously, we appreciate standards efforts, but would appreciate the acronyms spelled out once in a while for the benefit of those of us unable to attend the meetings in person. Thanks. From rem-conf Tue Sep 19 12:37:55 2000 From rem-conf-request@es.net Tue Sep 19 12:37:53 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13bT86-0002U7-00; Tue, 19 Sep 2000 12:32:34 -0700 Received: from ip204.seattle17.wa.pub-ip.psi.net ([38.28.132.204] helo=c596821-a) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 13bT83-0002Tx-00; Tue, 19 Sep 2000 12:32:31 -0700 From: "Accountant's Marketing Enterprises" To: Subject: CPAs, QuickBooks Advisors and Accountants -- New Year-Round Business Clients Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Sep 2000 12:34:14 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 4314 Lines: 48 Hello: We found your firm's name recently on one of the search directories... We offer a unique and affordable marketing and appointment setting service for Accountants, QuickBooks Advisors, CPAs and Tax Advisors... We'd like to introduce you to several business owners (with 1-20 employees, annual revenues of $250,000 to $750,000) who have an immediate need for accounting, tax, payroll and consulting services... Most of these business owners have questions regarding incorporation, what software to buy for their businesses, retirement, tax and business planning, etc... Many have had problems with QuickBooks... What we're finding this time of year, are business owners who have immediate tax needs, and also year-round accounting and "tax planning" needs as well... With our service, you pay as you go -- for results! We charge $350 for every two year-round monthly or quarterly business clients that you actually sign up from our leads, business prospects and appointments... Let us know that you're interested, and would like more information by calling us, or you may fax your request for more info... We'll send you more information about our program, including: where we're located, how we find qualified business clients (85-90% of our business owner leads are coming "inbound" directly from our web site), references, the four ways that we generate appointments with interested business owners, the size and types of businesses that we're finding, the average Accounting fees that are being generated by our 500+ member Accountants and CPAs nationwide, and our exclusive area guarantee (we give every customer of ours an exclusive 10 to 50 mile area)... Looking forward to hearing from you soon... Best wishes to you and your family... From my wife Jennifer, and daughters Michelle and Molly, and myself, "Have a GREAT year!" Randy Hirsch OUR CONTACT INFORMATION: Accountant's Marketing Enterprises "New Year-Round Business Clients for CPAs and Accountants" Call us Toll-Free: (888) 305-0651 For the fastest response, FAX your request for information to: (509) 472-7479 Be sure to include your email address, firm name, phone and fax numbers or you may E-mail your request for more information... For remove instructions, please see below... P.S. Respond right away and we'll email or fax a map of the exclusive area that we have in mind for your firm, and give you a $25 discount on your first two business clients... AND just to say "Thanks for responding so promptly" we're sending you a complimentary copy of our best selling: BLUEPRINTS Marketing Report for Growing and Expanding Accounting & Tax Firms." The report is packed with good ideas on growing your business and adding new clients, and sample introduction letters, two postcards, flyers, brochures and three sample Accounting Service agreements that we designed... We hope that you find the report helpful and informative... ************************************************************************************************************************************* REMOVAL INSTRUCTIONS: This message is being sent to you in compliance with the proposed Federal Legislation commercial e-mail S.1618 -- Section 301... "Pursuant to 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 submitting a request to "REMOVE" on the reply line of this message.... Further, this message cannot be considered SPAM as long as we include sender contact information... This is a one time mailing, done by an independent marketing company... We apologize for any inconvenience this may have caused you... We respect your online privacy and apologize if you have received this message in error... We do respect our remove lists! Your name was provided to us after extensive research and screening, as either an Accountant, CPA, QuickBooks Advisor,Tax Professional, Business Owner or Self-Employed Person... If you would like to be removed from any future mailings, please reply to this email and send us a remove request email... Please be aware that any disruption to our remove request email link above, also prevents those that want to be removed from our database from being removed... Thank You... From rem-conf Tue Sep 19 13:04:22 2000 From rem-conf-request@es.net Tue Sep 19 13:04:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bTbk-0002m3-00; Tue, 19 Sep 2000 13:03:12 -0700 Received: from swan.prod.itd.earthlink.net [207.217.120.123] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bTbg-0002lP-00; Tue, 19 Sep 2000 13:03:08 -0700 Received: from localhost (sdn-ar-001paphilP312.dialsprint.net [168.191.31.178]) by swan.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id MAA19932; Tue, 19 Sep 2000 12:33:00 -0700 (PDT) Message-Id: <4.2.0.58.20000919151736.00a30f00@mail.speedycam.com> X-Sender: livevideo@mail.speedycam.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 19 Sep 2000 15:27:51 -0400 To: (Recipient list suppressed) From: Dan Subject: Dear ISP / Webmaster: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1424 Lines: 31 Dear ISP / Webmaster: Get new members and keep them with Speedycam! You can now offer your members a way to interact with each other via live video and chat ! Your members can have their own live video web page with chat and real time video conferencing with audio! Your members will love it. Our members stay an average of 35 minutes per log-in! We have award winning software that takes less than 15 seconds to download and self install so even a complete novice can use it with ease. Web pages are created on the fly as soon as your someone signs up. Your members will love it ! We are offering this to only a limited amount of web master so contact us today to get started. You give this to your members for FREE and then simply pay us a small monthly fee. Prices start at $500 per month for unlimited use. We pay all the bandwidth charges, no hidden fees! We are also interested in possible partnerships with isp's. http://www.speedycam.com To test out our product, enter the code : isptrial in the "Referrer" field on the join page. Just email us before January 1, 2001 to cancel your demo and we will never bill you. You may also email info@speedycam.com for a demo and for custom video/audio solutions for your company. You were sent this email because you are part of a webmaster list, if you wish to be removed from our list send a email to : remove@speedycam.com Thank you. From rem-conf Tue Sep 19 18:10:12 2000 From rem-conf-request@es.net Tue Sep 19 18:10:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bYKv-0006uA-00; Tue, 19 Sep 2000 18:06:09 -0700 Received: from (bioinfo.biotec.or.th) [203.150.241.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bYKn-0006tI-00; Tue, 19 Sep 2000 18:06:02 -0700 Received: from 203.150.241.24 ([158.252.73.20]) by bioinfo.biotec.or.th (8.8.8+Sun/8.8.8) with SMTP id OAA27126; Wed, 20 Sep 2000 14:54:17 GMT From: infomarketing4@china.com Received: from infomarketing4@china.com by infomarketing4@china.com (8.8.5/8.6.5) with SMTP id GAA03055 for ; Tue, 19 Sep 2000 19:41:22 -0600 (EST) Date: Tue, 19 Sep 00 19:41:22 EST To: infomarketing4@china.com Subject: INTERNET MARKETING PROGRAM Message-ID: <> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 17787 Lines: 382 THE INTERNET MARKETING PROGRAM $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ INCREDIBLE $0 to $50,000 in 90 days!!! Dear Friend, You can earn $50,000 or more in the next 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, it's been very exciting. 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've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level email order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using email. 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 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 that 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but Donald Trump recently 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 deadpanned his response: "That's why I'm sitting up here and you are all sitting out there!" 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 you don't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the 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 just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 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: M & M PO BOX 1862 Santa Rosa Beach, FL 32459 REPORT #2 "The Insiders Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Steve Goodwin PO BOX 283 Johnston, IA 50131 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: M & H Consulting 2714 W 5th North Platte, NE 69101 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Nancy Brooks 3182 Lakeway ST Akron, Ohio 44319 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. Order the reports and follow the program outlined above-SUCCESS will be your reward. 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 local office of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependant on your activities 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 rivers@dcemail.com ///////////////////////////////////////////////////////////////// This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html From rem-conf Tue Sep 19 18:15:21 2000 From rem-conf-request@es.net Tue Sep 19 18:15:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bYT4-0007HO-00; Tue, 19 Sep 2000 18:14:34 -0700 Received: from oberon.dnai.com [207.181.194.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bYT3-0007GL-00; Tue, 19 Sep 2000 18:14:33 -0700 Received: from azoth.dnai.com (azoth.dnai.com [207.181.194.94]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id SAA65333 for ; Tue, 19 Sep 2000 18:13:33 -0700 (PDT) Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by azoth.dnai.com (8.9.3/8.9.3) with ESMTP id SAA10213 for ; Tue, 19 Sep 2000 18:13:32 -0700 (PDT) Received: from hariv (pc_hariv [192.168.0.44]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id SAA26478 for ; Tue, 19 Sep 2000 18:13:03 -0700 (PDT) Message-ID: <010d01c0229f$129b83a0$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Voice Playout for VoATM Date: Tue, 19 Sep 2000 18:06:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 91 Lines: 8 Hi, I am looking for Voice playout schemes for VoATM. Are there any references? hari From rem-conf Tue Sep 19 21:25:08 2000 From rem-conf-request@es.net Tue Sep 19 21:25:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bbLX-0002jb-00; Tue, 19 Sep 2000 21:18:59 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bbLU-0002jR-00; Tue, 19 Sep 2000 21:18:57 -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 UAA01641; Tue, 19 Sep 2000 20:16:13 +0100 Message-Id: <200009191916.UAA01641@purple.east.isi.edu> To: Yoshihiro Kikuchi cc: IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: New I/D submitted for MPEG-4 A/V RTP In-Reply-To: Message from Yoshihiro Kikuchi of "Mon, 18 Sep 2000 21:26:30 +0900." <01c101c0216b$ac58ec60$cc51c485@eel.rdc.toshiba.co.jp> Date: Tue, 19 Sep 2000 15:16:10 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1097 Lines: 46 Folks, Now that this update has made it to the i-d archives, please can you send any final comments this week, such that we can progress this document. Thanks, Colin --> Yoshihiro Kikuchi writes: >Dear all, > >I have submitted a new version (-04) of the internet draft of MPEG-4 >Audio/Visual RTP payload format to reflect comments raised and agreed during >the WG last call period. The document should be available soon at the >internet draft archive. > >The following is the summary of changes from the previous version (-03). > >1) Default value of MIME type >2) Editorial update of abstract and introduction >3) Clarification related to multiple VOPs concatenation (timestamp, >fragmentation rule 4) >4) LATM related modification (section 1.2, 4.2) >5) Some other editorial clarifications > > >The authors would like to thank for those who raised comments. > >Best regards, >Yoshihiro Kikuchi > >---- > Yoshihiro Kikuchi > >E-mail: kiku@eel.rdc.toshiba.co.jp >Corporate Research and Development Center >TOSHIBA Corporation >TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 > > > > From rem-conf Wed Sep 20 03:13:39 2000 From rem-conf-request@es.net Wed Sep 20 03:13:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bgoE-0006wy-00; Wed, 20 Sep 2000 03:08:58 -0700 Received: from (p-mail2.cnet.fr) [192.144.74.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13bgoC-0006vK-00; Wed, 20 Sep 2000 03:08:56 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 12:06:48 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132A6F@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: 'Dave Singer' Cc: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net, CURET Dominique FTRD/DMI/REN Subject: RE: Pre-MPEG meeting for the '4onIP' AHG Date: Wed, 20 Sep 2000 12:08:27 +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 Content-Length: 1898 Lines: 61 Dear Dave, dear all, It seems that going from SFO to La Baule is quite tricky, as you said: " I'll be in La Baule via SFO, JFK, LHR, CDG, CDG TGV, Nantes TGV, La=20 Baule SNCF"=20 I don't have any advice to give, but if it can help you and some = others: * there are some direct flights from SFO to CDG (or London?) * If you were coming via London you may catch a flight to Nantes,=20 but it is from Gatwick (3 flights per day) * If you were coming via Bruxelles you may catch a flight to Nantes,=20 (3 flights per day) * you can check that there are a large number of flights from other=20 Euoropean airports=20 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: lundi 18 septembre 2000 23:31 =C0: CURET Dominique FTRD/DMI/REN Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Objet: Re: Pre-MPEG meeting for the '4onIP' AHG At 6:01 PM +0200 9/13/00, CURET Dominique FTRD/DMI/REN wrote: >Dear all, dear Young-Kwon, > >we are supposed to meet on Saturday(21/10) and Sunday (22/10) >before the MPEG meeting in La Baule. > >Can we say something like: > Saturday from 14 to 2000 > Sunday from 0900 to 1800 >Or only the Sunday from 0900 to 1800 > >comments whoa! I'm completely snowed by the mail on this...and read as fast=20 as I can, I am not catching up. hence no comment from me yet! I'll be in La Baule via SFO, JFK, LHR, CDG, CDG TGV, Nantes TGV, La=20 Baule SNCF on Saturday night, if all those connections work... --=20 David Singer Apple Computer/QuickTime From rem-conf Wed Sep 20 06:03:21 2000 From rem-conf-request@es.net Wed Sep 20 06:03:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bjTY-0001Xl-00; Wed, 20 Sep 2000 05:59:48 -0700 Received: from mailgate.pit.comms.marconi.com [169.144.68.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bjTW-0001XT-00; Wed, 20 Sep 2000 05:59:46 -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 IAA29698; Wed, 20 Sep 2000 08:58:35 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA28917; Wed, 20 Sep 2000 08:58:35 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 08:58:28 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E6C5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Hari Krishna Vuppaladhadiam'" , rem-conf@es.net Subject: RE: Voice Playout for VoATM Date: Wed, 20 Sep 2000 08:58:06 -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 Content-Length: 976 Lines: 34 You wouldn't use RTP for VoATM except for a case of VoIP over ATM. So, I suspect this group can't help you much. The ATM Forum has some specs on carrying voice. The most recent is the BLES spec for VoDSL, which is ATM AAL2 based. The Q.BICC work in ITU covers VoATM using an extension to ISUP to carry an NSAP address. H.323 in ITU offers Annex C, which is an AAL5 VoATM bearer. Finally, there is work in MMUSIC to extend SDP to include ATM bearers, which would allow SIP, MEGACO and MGCP to support VoATM. MEGACO (H.248) has VoATM support in the "native" tags media format using binary encoding. The SDP work extends similar support for text encoding. Brian > -----Original Message----- > From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] > Sent: Tuesday, September 19, 2000 9:07 PM > To: rem-conf@es.net > Subject: Voice Playout for VoATM > > > Hi, > I am looking for Voice playout schemes for VoATM. Are there any > references? > hari > > > From rem-conf Wed Sep 20 06:18:29 2000 From rem-conf-request@es.net Wed Sep 20 06:18:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bjjO-0002bY-00; Wed, 20 Sep 2000 06:16:10 -0700 Received: from mail.unisannio.it [193.206.108.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bjjM-0002bO-00; Wed, 20 Sep 2000 06:16:08 -0700 Received: (from icsm2001@localhost) by mail.unisannio.it (8.9.3/8.8.7) id PAA07981 for rem-conf@es.net; Wed, 20 Sep 2000 15:16:04 +0200 Date: Wed, 20 Sep 2000 15:16:04 +0200 From: ICSM2001 (Canfora) Message-Id: <200009201316.PAA07981@mail.unisannio.it> To: rem-conf@es.net Subject: CFPs: IEEE Int. Conf. on Software Maint., Florence, Italy X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 6639 Lines: 155 Dear Colleague I hope that this CFPs could be useful for your work. Please forward the following to anybody who you think may be interested. Apologies if you have already seen this. If you would like to be removed from our list please send an email to icsm2001@unisannio.it with REMOVE in the subject. ICSM2001 Technical Committee _=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= CALL---FOR---PAPERS IEEE International Conference on Software Maintenance 2001 FLORENCE, ITALY, 5-9 November 2001, http://www.dsi.unifi.it/icsm2001 Theme: Systems and Software Evolution in the era of the Internet _=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. In the era of the Internet, businesses and end-users have invested in new technologies and small and large software organizations around the world are looking for Internet related solutions to evolve and maintain their new Internet software products. Internet technologies are strongly impacting system architectures and business processes and rules. In some cases businesses and end-users have been overwhelmed trying to keep up with software development and evolution processes and practices. In addition to novel solutions to enable the life-cycle of new web-based software systems, huge investments are necessary to migrate aginglegacy applications to web-enabled contemporary systems. ICSM 2001 will address these major changes in the software landscape and their impact on maintenance and evolution. The focus of the conference will be to explore the new challenges that the Internet, as a driver for business changes, poses for software maintenance, and the new opportunities it opens as infrastructure and enabling technology. The purpose of the conference is to promote discussion and interaction between researchers and practitioners. We are particularly interested in exchanging concepts, prototypes, research ideas, and other results which could contribute to the academic arena and also benefit business and the industrial community. ICSM 2001 will be participatory, with working collaborative sessions and presentations of industry projects. ICSM 2001 will bring together researchers, practitioners, developers and users of tools, technology transfer experts, and project managers. The Conference will be held in conjunction with WESS, the Workshop on Empirical Studies of Software. Topics of interest include but are not restricted to the following aspects of maintenance and evolution: - Methods and theories -Processes and strategies - Organizational frameworks -Life cycle and process control - Design for maintenance -Tools and environments - Internet and distributed systems -Multimedia systems - User interface evolution -Commercial off-the-shelf (COTS) - Third party maintenance -Freeware and open source applications - Program comprehension -Software and system visualization - Knowledge based systems -Formal methods - Impact of new software practices -Empirical studies - Software reusability -Programming languages - Source code analysis and manipulation -Testing and regression testing - Models and methods for error prediction -Measurement of software - Maintenance and/or productivity metrics -Preventive maintenance - Personnel aspects of maintenance -Reengineering and reverse engineering - Version and configuration management -Legal aspects and standards - Management and organization -Remote, tele-work, and co-operative applications RESEARCH PAPERS Research papers should describe original and significant work in the research and practice of software maintenance. Research case studies, empirical research, and experiments are particularly welcome. Papers should be 2000 - 5000 words in length, in English. Submit them in PDF or PostScript via email to icsm2001@unisannio.it by 15 January 2001. A prize of the Journal of Software Maintenance will be assigned at the Best submitted Paper. INDUSTRIAL APPLICATIONS We welcome proposals for presentations of Industrial Applications. These can be experience reports from real projects, industrial practices and models, or tool demonstrations. Submit proposals for Industrial Application presentations via email to icsm2001.industry@unisannio.it by 12 March 2001. Industrial Applications proposals will be reviewed by a dedicated sub-committee of the program committee and a 1 page summary of accepted proposals will be included in the conference proceedings. TUTORIALS Tutorials should present software maintenance and evolution topics of interest to practitioners. Tutorials may be full-day or half-day in length. Submit tutorial proposals via email to icsm2001.tutorial@unisannio.it by 12 February 2001. IMPORTANT DATES Research Paper submission 15 January 2001, notification of acceptance 1 June 2001 Industrial Application submission 12 March 2001 Tutorial submission 12 February 2001 ------------------------------ General chair: Paolo Nesi, University of Florence, Italy, nesi@dsi.unifi.it Financial chair: Vaclav Rajlich, Wayne State University, USA, vtr@cs.wayne.edu Program co-chairs: Gerardo Canfora, University of Sannio, Italy, gerardo.canfora@unisannio.it Anneliese von Mayrhauser, Colorado State University, USA, avm@CS.ColoState.EDU Tutorials co-chairs: Lionel C. Briand, Carleton University, briand@sce.carleton.ca Alessandro Fantechi, University of Florence, Italy, Fantechi@dsi.unifi.it Industrial Applications co-chairs: Panagiotis K. Linos, Tennessee Technological University, USA, linos@tntech.edu Harry Sneed, Software Engineering Service GmbH, Germany, Harry.Sneed@t-online.de Chris Verhoef, University of Amsterdam, NL, x@wins.uva.nl Publicity co-chairs: Nicholas Zvegintzov (General Co-chair), Software Management Network, USA, zvegint@attglobal.net Malcolm Munro (Co-chair for Europe), University of Durham, UK, malcolm.munro@durham.ac.uk William Cheng-Chung Chu (Co-chair for East), TungHai University, Taiwan, chu@cis.thu.edu.tw Local Arrangements co-chairs: Fabrizio Fioravanti, University of Florence, Italy, fioravan@dsi.unifi.it Pierfrancesco Bellini (Industrial Applications, and Demos), University of Florence, Italy, bellini@hpcn.dsi.unifi.it WEB Master: Marius Bogdan Spinu, University of Florence, Italy, spinu@hpcn.dsi.unifi.it -------------------------------------------------------------------------------------------------------------- From rem-conf Wed Sep 20 08:12:08 2000 From rem-conf-request@es.net Wed Sep 20 08:12:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13blUM-00056M-00; Wed, 20 Sep 2000 08:08:46 -0700 Received: from david.siemens.de [192.35.17.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13blUJ-00056C-00; Wed, 20 Sep 2000 08:08:44 -0700 X-Envelope-Sender-Is: Gero.X.Baese@mchp.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e8KF8fN18798 for ; Wed, 20 Sep 2000 17:08:42 +0200 (MET DST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e8KF8fF00196 for ; Wed, 20 Sep 2000 17:08:41 +0200 (MET DST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Sep 2000 17:09:07 +0200 Message-ID: <82BDC6DE2C18D411ACF6009027FD426744CFF7@mchp951a.mch.sbs.de> From: Baese Gero To: rem-conf@es.net Subject: new version of the ID "An RTP Payload Format for Erasure-Resilien t Transmission of Progressive Multimedia Streams" Date: Wed, 20 Sep 2000 17:09:05 +0200 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 Content-Length: 1023 Lines: 25 Dear Experts, we are glad to announce the completion of the new version of the I-D "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams" (draft-lnt-avt-uxp-02). This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon codes. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic unequal erasure protection (UXP). The new version includes effective in-band signaling for erasure protection profiles. We would highly appreciate any comments. If questions remaining don't hesitate to contact anyone of us. Best Wishes Gero Baese From rem-conf Wed Sep 20 09:39:15 2000 From rem-conf-request@es.net Wed Sep 20 09:39:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bmn2-00077B-00; Wed, 20 Sep 2000 09:32:08 -0700 Received: from sjc3-1.relay.mail.uu.net [199.171.54.122] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bmn1-000771-00; Wed, 20 Sep 2000 09:32:07 -0700 Received: from 21rst-century.com by sjc3sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjhmg03887; Wed, 20 Sep 2000 16:31:44 GMT Message-ID: <39C8E5FF.BF16CEED@21rst-century.com> Date: Wed, 20 Sep 2000 12:29:52 -0400 From: Thomas 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: Baese Gero CC: rem-conf@es.net Subject: Re: new version of the ID "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams" References: <82BDC6DE2C18D411ACF6009027FD426744CFF7@mchp951a.mch.sbs.de> 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 Content-Length: 1569 Lines: 49 Baese Gero wrote: > Dear Experts, > > we are glad to announce the completion of the new version of the I-D "An RTP > Payload Format for Erasure-Resilient Transmission of Progressive Multimedia > Streams" (draft-lnt-avt-uxp-02). > This document specifies an efficient way to ensure erasure-resilient > transmission of progressively encoded multimedia sources via RTP using > Reed-Solomon codes. The level of erasure protection can be explicitly > adapted to the importance of the respective parts in the source stream, thus > allowing a graceful degradation of application quality with increasing > packet loss rate on the network. Nevertheless, backward compatibility to > currently standardized non-progressive multimedia codecs is ensured, since > equal erasure protection (EXP) represents a subset of generic unequal > erasure protection (UXP). The new version includes effective in-band > signaling for erasure protection profiles. > We would highly appreciate any comments. If questions remaining don't > hesitate to contact anyone of us. > > Best Wishes > Gero Baese Hello; This (draft-lnt-avt-uxp-02) does not seem to be present in http://www.ietf.org/ids.by.wg/none.html Could you tell me where I can find it ? -- 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 Sep 20 10:32:36 2000 From rem-conf-request@es.net Wed Sep 20 10:32:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bngf-0000rg-00; Wed, 20 Sep 2000 10:29:37 -0700 Received: from atlas.dnai.com [207.181.194.95] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bnge-0000qK-00; Wed, 20 Sep 2000 10:29:36 -0700 Received: from azoth.dnai.com (azoth.dnai.com [207.181.194.94]) by atlas.dnai.com (8.9.3/8.9.3) with ESMTP id KAA41013; Wed, 20 Sep 2000 10:28:27 -0700 (PDT) Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by azoth.dnai.com (8.9.3/8.9.3) with ESMTP id KAA41009; Wed, 20 Sep 2000 10:28:26 -0700 (PDT) Received: from hariv (pc_hariv [192.168.0.44]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id KAA08371; Wed, 20 Sep 2000 10:27:58 -0700 (PDT) Message-ID: <00a601c02327$441caac0$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: "Rosen, Brian" , Subject: Re: Voice Playout for VoATM Date: Wed, 20 Sep 2000 10:21:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1437 Lines: 52 Thanks Brian for the information. I am trying to capture the differences as per the jitter buffer requirements for VoIP and VoATM case. How does it differ for these two? Regards Hari V -----Original Message----- From: Rosen, Brian To: 'Hari Krishna Vuppaladhadiam' ; rem-conf@es.net Date: Wednesday, September 20, 2000 6:11 AM Subject: RE: Voice Playout for VoATM >You wouldn't use RTP for VoATM except for a case of VoIP over ATM. >So, I suspect this group can't help you much. > >The ATM Forum has some specs on carrying voice. The most recent >is the BLES spec for VoDSL, which is ATM AAL2 based. >The Q.BICC work in ITU covers VoATM using an extension to ISUP >to carry an NSAP address. > >H.323 in ITU offers Annex C, which is an AAL5 VoATM bearer. > >Finally, there is work in MMUSIC to extend SDP to include >ATM bearers, which would allow SIP, MEGACO and MGCP to >support VoATM. MEGACO (H.248) has VoATM support in the >"native" tags media format using binary encoding. The SDP >work extends similar support for text encoding. > >Brian > >> -----Original Message----- >> From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] >> Sent: Tuesday, September 19, 2000 9:07 PM >> To: rem-conf@es.net >> Subject: Voice Playout for VoATM >> >> >> Hi, >> I am looking for Voice playout schemes for VoATM. Are there any >> references? >> hari >> >> >> > From rem-conf Wed Sep 20 11:30:16 2000 From rem-conf-request@es.net Wed Sep 20 11:30:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13boZf-0002O0-00; Wed, 20 Sep 2000 11:26:27 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13boZe-0002Nq-00; Wed, 20 Sep 2000 11:26:26 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA05456; Wed, 20 Sep 2000 11:26:17 -0700 Date: Wed, 20 Sep 2000 11:26:17 -0700 From: John Lazzaro Message-Id: <200009201826.LAA05456@snap.CS.Berkeley.EDU> To: purnhage@tnt.uni-hannover.de, tmn@iis.fhg.de Subject: Re: LATM specified in a public MPEG document? Cc: grl@iis.fhg.de, lazzaro@CS.Berkeley.EDU, mpeg4_vm@tnt.uni-hannover.de, purnhagen@tnt.uni-hannover.de, rem-conf@es.net, t-nomura@ccm.cl.nec.co.jp X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1717 Lines: 35 [ Bodo Teichmann writes] > LATM was actually developed for only "natural" audio coders, > i.e. not fo Structured Audio. it is not possible to transmitt > multiple objects, no scene desctipion and no time stamps > can be transmitted . in your case you better should either use > SyncLayer packets (thats an Acess unit with a Sync Layer header) > with rtp or use flexmux with rtp. but both options are just > drafts at the moment. Thanks for the info, 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. I'm currently prototyping using SA_access_units for MIDI messages for low-latency "jam session" sorts of applications, and its becoming apparent that a SA-specific profile for RTP (particularly RTCP) may have enough value to simply pursue it as an another valid packetization scheme, described as an I-D -- the draft-singer-mpeg4-ip-00.txt states that these application-specific packetization schemes are appropriate complements to the major ones like draft-ietf-avt-rtp-mpeg4-es-04.txt. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Wed Sep 20 11:33:57 2000 From rem-conf-request@es.net Wed Sep 20 11:33:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bofa-0002e4-00; Wed, 20 Sep 2000 11:32:34 -0700 Received: from mailgate.pit.comms.marconi.com [169.144.68.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bofU-0002Vt-00; Wed, 20 Sep 2000 11:32:29 -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 OAA00593; Wed, 20 Sep 2000 14:31:11 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28415; Wed, 20 Sep 2000 14:31:12 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 14:31:04 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E6D6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Hari Krishna Vuppaladhadiam'" , rem-conf@es.net Subject: RE: Voice Playout for VoATM Date: Wed, 20 Sep 2000 14:29:32 -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 Content-Length: 2166 Lines: 74 There is no simple answer for VoATM, as the underlying ATM network has mechanisms to control transmission characteristics the affect jitter. With ATM, one can maintain Stratum 2 timing end to end and not need much jitter buffer. Of course, one can also use UBR, and be under the same basic position that VoIP is. I usually tell folks "less, how much less depends on what you are doing". Brian > -----Original Message----- > From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] > Sent: Wednesday, September 20, 2000 1:22 PM > To: Rosen, Brian; rem-conf@es.net > Subject: Re: Voice Playout for VoATM > > > Thanks Brian for the information. > > I am trying to capture the differences as per the jitter > buffer requirements > for VoIP and VoATM case. How does it differ for these two? > > Regards > Hari V > > -----Original Message----- > From: Rosen, Brian > To: 'Hari Krishna Vuppaladhadiam' ; > rem-conf@es.net > > Date: Wednesday, September 20, 2000 6:11 AM > Subject: RE: Voice Playout for VoATM > > > >You wouldn't use RTP for VoATM except for a case of VoIP over ATM. > >So, I suspect this group can't help you much. > > > >The ATM Forum has some specs on carrying voice. The most recent > >is the BLES spec for VoDSL, which is ATM AAL2 based. > >The Q.BICC work in ITU covers VoATM using an extension to ISUP > >to carry an NSAP address. > > > >H.323 in ITU offers Annex C, which is an AAL5 VoATM bearer. > > > >Finally, there is work in MMUSIC to extend SDP to include > >ATM bearers, which would allow SIP, MEGACO and MGCP to > >support VoATM. MEGACO (H.248) has VoATM support in the > >"native" tags media format using binary encoding. The SDP > >work extends similar support for text encoding. > > > >Brian > > > >> -----Original Message----- > >> From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] > >> Sent: Tuesday, September 19, 2000 9:07 PM > >> To: rem-conf@es.net > >> Subject: Voice Playout for VoATM > >> > >> > >> Hi, > >> I am looking for Voice playout schemes for VoATM. Are there any > >> references? > >> hari > >> > >> > >> > > > > From rem-conf Wed Sep 20 19:58:06 2000 From rem-conf-request@es.net Wed Sep 20 19:58:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13bwTM-0001Yx-00; Wed, 20 Sep 2000 19:52:28 -0700 Received: from research.gate.nec.co.jp [202.247.6.217] by mail1.es.net with esmtp (Exim 1.81 #2) id 13bwTK-0001XQ-00; Wed, 20 Sep 2000 19:52:27 -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 LAA13974; Thu, 21 Sep 2000 11:52:16 +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 LAA02970; Thu, 21 Sep 2000 11:52:14 +0900 (JST) Message-ID: <007e01c02376$f2313c80$152c380a@dsp.cl.nec.co.jp> From: "Toshiyuki Nomura" To: "John Lazzaro" , Cc: , , , References: <200009201826.LAA05456@snap.CS.Berkeley.EDU> Subject: Re: LATM specified in a public MPEG document? Date: Thu, 21 Sep 2000 11:52:12 +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 Content-Length: 1378 Lines: 38 Dear John and Bodo, > [ Bodo Teichmann writes] > > > LATM was actually developed for only "natural" audio coders, > > i.e. not fo Structured Audio. it is not possible to transmitt > > multiple objects, no scene desctipion and no time stamps > > can be transmitted . in your case you better should either use > > SyncLayer packets (thats an Acess unit with a Sync Layer header) > > with rtp or use flexmux with rtp. but both options are just > > drafts at the moment. > > Thanks for the info, 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. Simple SA session without scene description can be realized by the LATM-based RTP specification. Therefore, I'll modify the current draft to claim "Since LATM has no funciton to handle scene description, Structured Audio with scene description MUST NOT be transported using RTP packetization specified in this document". Best Regards, Toshiyuki Nomura, NEC -------------------------- From rem-conf Thu Sep 21 00:29:50 2000 From rem-conf-request@es.net Thu Sep 21 00:29:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13c0e9-0004Yd-00; Thu, 21 Sep 2000 00:19:53 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13c0e6-0004YT-00; Thu, 21 Sep 2000 00:19:51 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 21 Sep 2000 08:19:36 +0100 To: "Rosen, Brian" cc: 'Hari Krishna Vuppaladhadiam' , rem-conf@es.net Subject: Re: Voice Playout for VoATM In-reply-to: Your message of "Wed, 20 Sep 2000 14:29:32 EDT." <4FBEA8857476D311A03300204840E1CF01A6E6D6@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 21 Sep 2000 08:19:35 +0100 Message-ID: <937.969520775@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2842 Lines: 92 In message <4FBEA8857476D311A03300204840E1CF01A6E6D6@whq-msgusr-02.pit.comms.ma rconi.com>, "Rosen, Brian" typed: >>There is no simple answer for VoATM, as the underlying >>ATM network has mechanisms to control transmission characteristics the >>affect jitter. With ATM, one can maintain Stratum 2 timing >>end to end and not need much jitter buffer. Of course, one >>can also use UBR, and be under the same basic position that >>VoIP is. right - you can run VOIP with 40 byte rtp+udp+ip headers over a TDM network, and get whatever bit level jitte the TDM net guarantees, or at the other weirder extreme, you can run PCM voice in ATM cells in cells-in-frames on an ethernet - then you get absolutely nada in the way of jitter control..... >>I usually tell folks "less, how much less depends on what >>you are doing". usually less, but see above... >> >>> -----Original Message----- >>> From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] >>> Sent: Wednesday, September 20, 2000 1:22 PM >>> To: Rosen, Brian; rem-conf@es.net >>> Subject: Re: Voice Playout for VoATM >>> >>> >>> Thanks Brian for the information. >>> >>> I am trying to capture the differences as per the jitter >>> buffer requirements >>> for VoIP and VoATM case. How does it differ for these two? >>> >>> Regards >>> Hari V >>> >>> -----Original Message----- >>> From: Rosen, Brian >>> To: 'Hari Krishna Vuppaladhadiam' ; >>> rem-conf@es.net >>> >>> Date: Wednesday, September 20, 2000 6:11 AM >>> Subject: RE: Voice Playout for VoATM >>> >>> >>> >You wouldn't use RTP for VoATM except for a case of VoIP over ATM. >>> >So, I suspect this group can't help you much. >>> > >>> >The ATM Forum has some specs on carrying voice. The most recent >>> >is the BLES spec for VoDSL, which is ATM AAL2 based. >>> >The Q.BICC work in ITU covers VoATM using an extension to ISUP >>> >to carry an NSAP address. >>> > >>> >H.323 in ITU offers Annex C, which is an AAL5 VoATM bearer. >>> > >>> >Finally, there is work in MMUSIC to extend SDP to include >>> >ATM bearers, which would allow SIP, MEGACO and MGCP to >>> >support VoATM. MEGACO (H.248) has VoATM support in the >>> >"native" tags media format using binary encoding. The SDP >>> >work extends similar support for text encoding. >>> > >>> >Brian >>> > >>> >> -----Original Message----- >>> >> From: Hari Krishna Vuppaladhadiam [mailto:hariv@chiplogic.com] >>> >> Sent: Tuesday, September 19, 2000 9:07 PM >>> >> To: rem-conf@es.net >>> >> Subject: Voice Playout for VoATM >>> >> >>> >> >>> >> Hi, >>> >> I am looking for Voice playout schemes for VoATM. Are there any >>> >> references? >>> >> hari >>> >> >>> >> >>> >> >>> > >>> >>> >> cheers jon From rem-conf Thu Sep 21 01:13:16 2000 From rem-conf-request@es.net Thu Sep 21 01:13:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13c1SD-0005nd-00; Thu, 21 Sep 2000 01:11:37 -0700 Received: from ns2.system-io.co.jp (ns2.system-io.co.jp.) [203.139.112.11] by mail1.es.net with smtp (Exim 1.81 #2) id 13c1SA-0005nB-00; Thu, 21 Sep 2000 01:11:34 -0700 Received: from gnr.net by ns2.system-io.co.jp. (SMI-8.6/SMI-SVR4) id RAA00008; Thu, 21 Sep 2000 17:11:38 +0900 Date: Thu, 21 Sep 2000 17:11:38 +0900 From: nile333@kadet.co.uk Message-Id: <200009210811.RAA00008@ns2.system-io.co.jp.> To: nile333@kadet.co.uk Subject: So, How in the heck have you been? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 21379 Lines: 532 So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we havent met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you dont miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you dont believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, dont miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated 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 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 extra money at home. The results 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. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, Im from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-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 could not 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. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months 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 toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didnt 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 couldnt believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects 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 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 dont need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. 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 DONT 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, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it wont work if you dont 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 wont work and youll 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 toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are 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, cpuld 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 wasnt working. Finally, I figured it out. It wasnt me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I dont 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 ANDTHE 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 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 everimagined.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 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 copyof 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 DO IT!! BEFORE YOU delete this program from your in box, 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. HERES HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! 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 business. 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isnt this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so dont worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you cant sell them if you dont 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! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After youve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this 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! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL lets say that you decide to start small, just to see how it goes, and well assume you and all those involved email out only 2,000 programs each. Lets also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) 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. Thats 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 HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Lets say you decide to start small 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. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISNT IT 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 100s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Dont you want your name to be on the emails they will send out? *** DONT MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** 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 cant advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. 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 & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insiders Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insiders Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************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 letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you dont receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you dont continue advertising or sending e-mail 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. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities 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. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From rem-conf Thu Sep 21 01:30:11 2000 From rem-conf-request@es.net Thu Sep 21 01:30:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13c1iQ-0006rY-00; Thu, 21 Sep 2000 01:28:22 -0700 Received: from tnt-dal-42-205.dallas.net (bfgbhome.inetint.com) [209.44.42.205] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13c1iJ-0006r6-00; Thu, 21 Sep 2000 01:28:16 -0700 Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id DAA07144 for rem-conf@es.net; Thu, 21 Sep 2000 03:28:08 -0500 Date: Thu, 21 Sep 2000 03:28:08 -0500 From: "Brian F. G. Bidulock" To: rem-conf@es.net Subject: Re: So, How in the heck have you been? Message-ID: <20000921032808.A7095@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: rem-conf@es.net References: <200009210811.RAA00008@ns2.system-io.co.jp.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200009210811.RAA00008@ns2.system-io.co.jp.>; from nile333@kadet.co.uk on Thu, Sep 21, 2000 at 05:11:38PM +0900 Organization: Brian F. G. Bidulock, P. Eng. Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bfgbhome.inetint.com id DAA07144 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 22968 Lines: 584 Could someone PLEEEEEASE put a spam filter on this list! --brian On Thu, 21 Sep 2000, nile333@kadet.co.uk wrote: >=20 > So, How in the heck have you been? >=20 > Do you remember holding previous conversations regarding business and > money making opportunities? I did not send this to you in error! >=20 > You Said: >=20 > If only I could find an easier way to make a higher income! >=20 > and >=20 > If I had more money, I could spend more time with my Family, and less > time at work and I sure could use more money so I could pay off my > bills once and for all! >=20 > And >=20 > I would love to get involved in a business in which will generate money > while I am not at work (like a Gas Pump)! >=20 > Dear Friend, >=20 > There is a possibility that we haven=92t met, but you were chosen by > someone to receive this E-Mail. Please, please, print this off and > read thoroughly. Be sure that you don=92t miss any of the points > outlined. Then put it down, and then read it again. I am sending > you a whole lot of information in which you might not understand > the first time you read it. If you don=92t believe this program > will work for you, send it to 10-20 of your closest friends > (in which you trust deeply), and ask them what they think? > This really works! Have faith, don=92t miss this opportunity, > get involved also, and it will work for you as it does for us!!!! >=20 > Due to the popularity of this letter on the Internet, A Major Nightly > News Program recently dedicated 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 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 extra money at home. The > results 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. >=20 > You will understand only if you get involved! > ********** THE ENTIRE PLAN IS HERE BELOW ********** > **** Print This Now For Future Reference **** >=20 > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > If you would like to make AT LEAST $50,000 in less than 90 days! If not= , >=20 > forward this to someone who would like to make this kind of money. > It works (like designed) but only for those who follow it to the letter= ! >=20 > Please read this program THEN READ IT AGAIN!! > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ >=20 > THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT > require you to come into contact with people or make or take any > telephone > calls. Just follow the instructions, and you will make money. This > simplified e-mail marketing program works perfectly 100% EVERY TIME! >=20 > E-mail is the sales tool of the future. Take advantage of this virtuall= y >=20 > free method of advertising NOW!!! The longer you wait, the more people > will > be doing business using e-mail. Get your piece of this action!!! >=20 > Hello, My name is Johnathon Rourke, I=92m from Rhode Island. The enclo= sed >=20 > information is something I almost let slip through my fingers. > Fortunately, sometime later I re-read everything and gave some thought > and study to it. Two years ago, the corporation I worked for the past > twelve yearsdown-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 could not seem to make ends meet. I had to refinance and borrow > against > my home to support my family and struggling business. >=20 > AT THAT MOMENT something significant happened in my life. I am writing > to share the experience I hopes that this could change your life > FOREVER. > FINANCIALLY$$$!!! >=20 > In mid December, I received this program in my e-mail. Six months 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 toodifficult for me to comprehend > or > the initial investment was too muchfor me to risk to see if they would > work. > But as I was saying, in December of 1997 I received this program.I > didn=92t > send for it, or ask for it, they just got my name off a mailing list. >=20 > THANK GOODNESS FOR THAT!!! >=20 > After reading it several times, to make sure I was reading it correctly. > I > couldn=92t believe my eyes! Here was a MONEY MAKING MACHINE I could sta= rt > immediately without any debt. Like most of you I was still a little > skeptical and a little worried about the legalaspects 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 > I decided WHY NOT!?!?? >=20 > 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=92t need any paper = for >=20 > printing to send out the program, and because I also send the product > (reports) by e-mail, my only expense is my time. In less than one week,= I > was > starting to receive orders for REPORT #1. >=20 > 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=92T > 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. >=20 > Well, I had 196 orders for REPORT #2. 96 more than I needed. So I > sat back and relaxed. >=20 > By March 1, of my e-mailing of 10,000, received $58,000 with more comin= g > in > every day. I paid off ALL my debts and bought a much need new car! > Please > take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! > Remember, it won=92t work if you don=92t try it. This program does work= , But > you > must follow it EXACTLY! Especially the rules of not trying to place you= r >=20 > name in a different place. It won=92t work and you=92ll lose out on a l= ot of >=20 > money! In order for this program to work, you must meet your goal of 20= + >=20 > orders for REPORT #1, and 100+ orders for REPORT #2 and you will make > $50,000 or more in 90 days. >=20 > I AM LIVING PROOF THAT IT WORKS!!! >=20 > 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 > toparticipate, follow the program and you will be on your way to > financial security. If you are a fellow business owner and > are financial trouble like I was, or you want to start your own > business, consider this a sign. I DID! $$ >=20 > Sincerely, > Johnathon Rourke >=20 > 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, cpuld not have been created by a= n >=20 > 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=92t > working. > Finally, I figured it out. It wasn=92t me, it was the economy. Inflatio= n > and > recession had replaced the stable economy that had been with us since > 1945. > I don=92t have to tell you what happened to the unemployment rate becau= se > many > of you know from first hand experience. There were more failures and > bankruptcies than ever before. The middle class was vanishing. Those wh= o >=20 > 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 RICHE= R >=20 > ANDTHE 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 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 > everimagined.I should also point out that I will not see a penny of thi= s >=20 > money, nor anyone else who has provided a testimonial for this program. > I > 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 copyof this > exciting report to everyone you can think of. One of the people you sen= d >=20 > 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. >=20 > IT IS UP TO YOU!! NOW DO IT!! >=20 > BEFORE YOU delete this program from your in box, as I almost did, take = a >=20 > 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 doubt= s > you > have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ >=20 > Jody Jacobs Richmond, VA. >=20 > HERE=92S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF > DOLLARS$$$$!!!! >=20 > 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 yo= u > say > BULL, please read this program carefully. This is not a chain letter,bu= t > a > perfectly legal money making business. 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 sell and deliver a product for EVERY dollar received. >=20 > 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 EASIEST marketing plan anywhere! It is simply order > filling by e-mail! The product is informational and instructional > material, > keys to the secrets for everyone on how to open the doors to the magic > world > of E-COMMERCE, the information highway, the wave of the future ! >=20 > PLAN SUMMARY: >=20 > (1) You order the 4 reports listed below ($5 each) They come to you by > e-mail. >=20 > (2) Save a copy of this entire letter and put your name after Report #= 1 > and > move the other names down. >=20 > (3) Via the internet, access Yahoo.com or any of the other major searc= h >=20 > engines to locate hundreds of bulk e-mail service companies (search for > bulk > email) and have them send 25,000 50,000 emails for you about $49+. >=20 > (4) Orders will come to you by postal mail simply e-mail them the > Report they ordered. Let me ask you isn=92t this about as easy as it > gets? >=20 > By the way there are over 50 MILLION e-mail address with millions more > joining the internet each year so don=92t worry about running out or > saturation. People are used to seeing and hearing the same > advertisements every day on radio/TV. How many times have you received > the same pizza flyers on your door? Then one day you are hungry for > pizza > and order one. Same thing with this letter. I received this letter many > times then one day I decided it was time to try it. >=20 > YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR > REPORTS >=20 > Order the four reports shown on the list below (you can=92t sell them i= f > you don=92t 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! Within a few days you will receive, by e-mai= l >=20 > each of the four reports.Save them on your computer so you can send the= m > to > the 1,000=92s of people who will order them from you. >=20 > STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER >=20 > a. Look below for the listing of the four reports. > b. After you=92ve ordered the four reports, delete the name and address > under REPORT #4. This person has made it through the cycle. > c. Move the name and address under REPORT #3 down to REPORT #4. > d. Move the name and address under REPORT #2 down to REPORT #3. > e. Move the name and address under REPORT #1 down to REPORT #2. > f. Insert your name/address in the REPORT #1 position. Please make sure > you >=20 > COPY ALL INFORMATION, every name and address, ACCURATELY! >=20 > STEP #3. Take this entire letter, including the modified list of names, > and save it to your computer. Make NO changes to these instructions. No= w > you > are ready to use this entire e-mail to send by e-mail to prospects. >=20 > Report #1 will tell you how to download bulk email software and email > address so you can send it out to thousands of people while you sleep! > Remember that 50,000+ new people are joining the internet every month! > Your cost to participate in this is practically nothing ( surely you ca= n >=20 > afford $20 and initial bulk mailing cost). You obviously already have a > computer and an Internet connection and e-mail is FREE! There are two > primary methods of building your downline: METHOD #1: SENDING BULK > E-MAIL > let=92s say that you decide to start small, just to see how it goes, an= d > we=92ll > assume you and all those involved email out only 2,000 programs each. > Let=92s > also assume that the mailing receives a 0.5% response. The response > could be > much better. Also, many people will email out thousands of thousands of > programs instead of 2,000 (Why stop at 2000?) But continuing with this > example, you send out only 2,000 programs. With a 0.5% response, that i= s >=20 > 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=92s 10,000 $5 bills for yo= u. > CASH!!! Your total income in this example is $50 + $500 + $5000 + > $50,000 > for a total of $55,550!!! >=20 > REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAI= L > TO > WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A > MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS > INSTEAD OF 2,000. Believe me, many people will do just that, and more! >=20 > 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=92s say you decide to start small to see how well it wor= ks. >=20 > 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 onl= y > 10 > downline members. Look how this small number accumulates to achieve the > STAGGERING results below: >=20 > 1St level your first 10 send you $5........................$50 > 2nd level 10 members from those 10 ($5 x 100)............$500 > 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 > 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 > $$$$$$ THIS TOTALS > ------------------------------------------------55,5550 > $$$$$ >=20 > AMAZING ISN=92T IT 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=92s of > participants and many will continue to work this program, sending out > programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! > People are going to get emails about this plan from you or somebody els= e > and > many will work this plan the question is Don=92t you want your name to= be > on > the emails they will send out? >=20 > *** DON=92T MISS OUT !!!*** > ***JUST TRY IT ONCE !!!*** > ***SEE WHAT HAPPENS !!!*** > ***YOU'LL BE AMAZED !!!*** >=20 > 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 promp= t >=20 > because they can=92t advertise until they receive the report! >=20 > GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- > ALWAYS SEND $5 CASH (U.S. 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: >=20 > (a) the number & name of the report you are ordering > (b) your e-mail address, and > (c) your name & postal address. >=20 > REPORT #1b The Insider=92s Guide to Advertising for Free on the Interne= t > ORDER REPORT #1 FROM: >=20 > NICK NICHOLAS > 473 MICHIGAN ST > ST.PAUL, MN 55102 >=20 > NOTE: I and every member below are dedicated at helping you with this > program so it will work for you also. TRY US! >=20 > REPORT #2 The Insider=92s Guide to Sending Bulk E-Mail on the Internet > ORDER REPORT #2 FROM: >=20 > DIANE COLON > 1811 TAMARIND AVE # 206 > LOS ANGELES, CA. 90028 >=20 > REPORT #3 The Secrets to Multilevel Marketing on the Internet > ORDER REPORT #3 FROM: >=20 > MELISSA HOGENMILLER > 3709 MONHEIM ROAD > CONOVER, WI 54519 >=20 > REPORT #4 How to become a Millionaire utilizing the Power of Multilevel > Marketing and the Internet > ORDER REPORT #4 FROM: >=20 > CATHY BARROW > 10 SYCAMORE STREET > CONWAY, SC 29527 >=20 > *************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 letter (with your name on them). >=20 > --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be > patient and persistent with this program- If you follow the > instructions exactly results WILL FOLLOW. $$$$ >=20 > ************ YOUR SUCCESS GUIDELINES *************** >=20 > Follow these guidelines to guarantee your success: If you don=92t recei= ve > 20 orders for REPORT #1 within two weeks, continue advertising or > sending > e-mail until you do. Then a couple of weeks later you should receive at > least 100 orders for REPORT #2. If you don=92t continue advertising or > sending > e-mail 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. To generate more income, simply send another > batch of > e-mails or continue placing ads and start the whole process again! Ther= e > 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: >=20 > ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? >=20 > 1. If the answer is no, then please look at the following facts about > this super simple MLM program: NO face to face selling, NO meetings, NO > inventory! NO Telephone calls, NO big cost to start! Nothing to learn, > No skills needed! (Surely you know how to send email?) >=20 > 2. No equipment to buy you already have a computer and internet > connection so you have everything you need to fill orders! >=20 > 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR > SHIP! (Email copies of the reports are FREE!) >=20 > 4. All of your customers pay you in CASH! This program will change your > LIFE FOREEVER!! Look at the potential for you to be able to quit your > job and live a life of luxury you could only dream about! Imagine > getting out of debt and buying the car and home of your dreams and > being able to work a super-high paying leisurely easy business from > home! >=20 > $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! > Take your first step toward achieving financial independence. Order > the reports and follow the program outlined above __ SUCCESS will be > your reward. >=20 > Thank you for your time and consideration. PLEASE NOT: If you need > help with starting a business, registering a business name, learning > now income tax is handled, etc., contact your local office of the > Small Business Administration (A Federal Agency) 1-800-827-5722 > for free help and answers to questions. Also the Internal Revenue > Service offers free help via telephone and free seminars about > business tax requirements. Your earnings are highly dependent on > your activities 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. >=20 > Under Bill s.1618 TITLE III passed by the 105th US Congress this > letter cannot be considered spam as long as the sender includes > contact information and a method of removal. This is a one time > e-mail transmission. No request for removal is necessary. >=20 >=20 >=20 --=20 Brian F. G. Bidulock, P. Eng. bidulock@dallas.net From rem-conf Thu Sep 21 05:30:29 2000 From rem-conf-request@es.net Thu Sep 21 05:30:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13c5Ok-0002f8-00; Thu, 21 Sep 2000 05:24:18 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13c5Oi-0002er-00; Thu, 21 Sep 2000 05:24:16 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA17374; Thu, 21 Sep 2000 14:24:02 +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 xma017369; Thu, 21 Sep 00 14:24:02 +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 OAA05198; Thu, 21 Sep 2000 14:24:02 +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 OAA11264; Thu, 21 Sep 2000 14:24:01 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014249640; Thu, 21 Sep 2000 14:25:05 +0200 To: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: Types of MPEG-4 streams over IP Message-ID: <0056890014249640000002L902*@MHS> Date: Thu, 21 Sep 2000 14:25:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/21/00 14:22:39" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1405 Lines: 57 Dear all, 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 : - 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 For MP4 files only a standard MIME type is required. For all other stre= ams also use of RTP and SDP need to be defined. Please correct me if I am w= rong. The framework document (Singer et al) indicates that also a MIME type i= s needed for an MPEG-4 MuxCodeTable. Is this required indeed, or can we a= ssume (/require) that the MuxCodeTable is transported inside the same FlexMux= stream (in a packet with simple mode). This could provide an easy solut= ion for the timing of applicability of the table that would need to be reso= lved otherwise when using e.g. HTTP; however it would require MuxCodeTable t= o become a new entry in the table for streamType values, right ? 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 Thu Sep 21 10:50:16 2000 From rem-conf-request@es.net Thu Sep 21 10:50:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13c9wG-0007GJ-00; Thu, 21 Sep 2000 10:15:12 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13c9wE-0007Ff-00; Thu, 21 Sep 2000 10:15:11 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JUFJ94GGXEEBYNBB@GI.COM> for rem-conf@es.net; Thu, 21 Sep 2000 10:13:56 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 10:13:22 -0400 Content-return: allowed Date: Thu, 21 Sep 2000 13:16:31 -0400 From: "Luthra, Ajay (SD-EX)" Subject: RE: comments on in-band-signaling proposal To: 'Zvi Lifshitz' , "'Narasimhan, Sam (SD-EX)'" , 'Yoshihiro Kikuchi' , IETF AVT , "'jan.vandermeer@philips.com'" Cc: Colin Perkins , "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <973597126BDDD11197AA00805FA7EBC903421687@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 Content-Length: 2899 Lines: 71 Zvi, Assuming CTS=DTS is confusing. If you have B-frames then there can be a large (arbitrary with no legal upper limit put by MPEG) difference between CTS and DTS. All the profiles except Simple use B-frames. So, unless we are defining this only for the carriage of MPEG4 Simple Profile ES over IP, this assumption does not seem to make sense. Due to instantaneous decoding model at the System Level, one can assume that the picture is instantaneously decoded and available for the prediction of next frame at DTS time (if DTS is present). However, this is not same as assuming CTS=DTS. Actually, if you are sending only one Time Stamp then you send CTS and your assumption will be DTS=CTS which will be a disaster. So, if there is no DTS and you have B-frames then only reasonable choice is to not to assume it to be anything (like DTS=CTS) and hope / pray receiver decodes the picture as fast it can and does not overflow. In MPEG-2 kind of environment with fixed/limited/pre-defined frame rates, it was easier to live without paying too much attention to DTS. I am not so sure about MPEG-4 where there is no fixed frame rate. That is one of the reasons the buffer model is so messy in the Video part of MPEG-4. Praying may not help here. Why is jitter forcing you to assume CTS=DTS? Are you saying that due to jitter in IP networks B-frames are not allowed and we need only to use Simple Profile? Please clarify. Thanks. With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Friday, September 15, 2000 12:34 AM To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal [Narasimhan, Sam (SD-EX):] 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. [Reply:] The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 21 11:09:48 2000 From rem-conf-request@es.net Thu Sep 21 11:09:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cAgr-0000tR-00; Thu, 21 Sep 2000 11:03:21 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cAgn-0000si-00; Thu, 21 Sep 2000 11:03:19 -0700 Received: from zvil (i1-14.j1.actcom.co.il [192.115.22.176]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id UAA17928; Thu, 21 Sep 2000 20:59:55 +0300 Received: by localhost with Microsoft MAPI; Thu, 21 Sep 2000 20:59:49 +0200 Message-ID: <01C0240E.E1772D80.zvil@csi.com> From: Zvi Lifshitz To: "'Luthra, Ajay (SD-EX)'" , "'Narasimhan, Sam (SD-EX)'" , "'Yoshihiro Kikuchi'" , IETF AVT , "'jan.vandermeer@philips.com'" Cc: Colin Perkins , "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Date: Thu, 21 Sep 2000 20:59: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 Content-Length: 4183 Lines: 106 Ajay, You're right assuming DTS=CTS is not sufficient, but I believe we need to assume CTS-DTS < delta, when delta has an upper limit. If it doesn't we are in troubles because we don't know how much memory to allocate to the composition buffer. If indeed delta is known, it can be used to calculate the extra memory the decoding buffer would need to compensate for its ignorance of DTSs. 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: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Thursday, September 21, 2000 7:17 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal Zvi, Assuming CTS=DTS is confusing. If you have B-frames then there can be a large (arbitrary with no legal upper limit put by MPEG) difference between CTS and DTS. All the profiles except Simple use B-frames. So, unless we are defining this only for the carriage of MPEG4 Simple Profile ES over IP, this assumption does not seem to make sense. Due to instantaneous decoding model at the System Level, one can assume that the picture is instantaneously decoded and available for the prediction of next frame at DTS time (if DTS is present). However, this is not same as assuming CTS=DTS. Actually, if you are sending only one Time Stamp then you send CTS and your assumption will be DTS=CTS which will be a disaster. So, if there is no DTS and you have B-frames then only reasonable choice is to not to assume it to be anything (like DTS=CTS) and hope / pray receiver decodes the picture as fast it can and does not overflow. In MPEG-2 kind of environment with fixed/limited/pre-defined frame rates, it was easier to live without paying too much attention to DTS. I am not so sure about MPEG-4 where there is no fixed frame rate. That is one of the reasons the buffer model is so messy in the Video part of MPEG-4. Praying may not help here. Why is jitter forcing you to assume CTS=DTS? Are you saying that due to jitter in IP networks B-frames are not allowed and we need only to use Simple Profile? Please clarify. Thanks. With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Friday, September 15, 2000 12:34 AM To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal [Narasimhan, Sam (SD-EX):] 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. [Reply:] The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 21 11:31:27 2000 From rem-conf-request@es.net Thu Sep 21 11:31:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cB6N-00025y-00; Thu, 21 Sep 2000 11:29:43 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cB6L-00022Q-00; Thu, 21 Sep 2000 11:29:41 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JUFLUQENI2EBZ9AU@GI.COM> for rem-conf@es.net; Thu, 21 Sep 2000 11:28:31 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 11:28:02 -0400 Content-return: allowed Date: Thu, 21 Sep 2000 14:31:03 -0400 From: "Luthra, Ajay (SD-EX)" Subject: RE: comments on in-band-signaling proposal To: 'Zvi Lifshitz' , 'IETF AVT' Cc: "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Message-id: <973597126BDDD11197AA00805FA7EBC90342168B@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 Content-Length: 5097 Lines: 127 But MPEG does not put any limit on that Delta (CTS-DTS). In MPEG-2, different user groups (like ATSC, SMPTE, DVD, DVB etc) put their own limits for their own applications. It is not clear at this stage if those limits will be carried in the Internet world or not. They may not, as many Internet applications and users are lot more delay tolerant. So, if we have to assume some Delta at this stage then I would say that the proposal is broken as with in MPEG, currently, there is no assigned value to it, except in Simple Profile. Am I missing something? With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Thursday, September 21, 2000 12:00 PM To: 'Luthra, Ajay (SD-EX)'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal Ajay, You're right assuming DTS=CTS is not sufficient, but I believe we need to assume CTS-DTS < delta, when delta has an upper limit. If it doesn't we are in troubles because we don't know how much memory to allocate to the composition buffer. If indeed delta is known, it can be used to calculate the extra memory the decoding buffer would need to compensate for its ignorance of DTSs. 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: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Thursday, September 21, 2000 7:17 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal Zvi, Assuming CTS=DTS is confusing. If you have B-frames then there can be a large (arbitrary with no legal upper limit put by MPEG) difference between CTS and DTS. All the profiles except Simple use B-frames. So, unless we are defining this only for the carriage of MPEG4 Simple Profile ES over IP, this assumption does not seem to make sense. Due to instantaneous decoding model at the System Level, one can assume that the picture is instantaneously decoded and available for the prediction of next frame at DTS time (if DTS is present). However, this is not same as assuming CTS=DTS. Actually, if you are sending only one Time Stamp then you send CTS and your assumption will be DTS=CTS which will be a disaster. So, if there is no DTS and you have B-frames then only reasonable choice is to not to assume it to be anything (like DTS=CTS) and hope / pray receiver decodes the picture as fast it can and does not overflow. In MPEG-2 kind of environment with fixed/limited/pre-defined frame rates, it was easier to live without paying too much attention to DTS. I am not so sure about MPEG-4 where there is no fixed frame rate. That is one of the reasons the buffer model is so messy in the Video part of MPEG-4. Praying may not help here. Why is jitter forcing you to assume CTS=DTS? Are you saying that due to jitter in IP networks B-frames are not allowed and we need only to use Simple Profile? Please clarify. Thanks. With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Friday, September 15, 2000 12:34 AM To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal [Narasimhan, Sam (SD-EX):] 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. [Reply:] The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 21 11:41:58 2000 From rem-conf-request@es.net Thu Sep 21 11:41:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cBFu-0002vS-00; Thu, 21 Sep 2000 11:39:34 -0700 Received: from lmail.actcom.co.il [192.114.47.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cBFq-0002vE-00; Thu, 21 Sep 2000 11:39:32 -0700 Received: from zvil (i1-14.j1.actcom.co.il [192.115.22.176]) by lmail.actcom.co.il (8.9.3/8.9.1) with SMTP id VAA23696; Thu, 21 Sep 2000 21:39:33 +0300 Received: by localhost with Microsoft MAPI; Thu, 21 Sep 2000 21:39:25 +0200 Message-ID: <01C02414.69BFD7A0.zvil@csi.com> From: Zvi Lifshitz To: "'Luthra, Ajay (SD-EX)'" , "'IETF AVT'" Cc: "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: comments on in-band-signaling proposal Date: Thu, 21 Sep 2000 21:39:24 +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 Content-Length: 6288 Lines: 160 I think whatever delta an application assumes would be implemented by extending the terminal buffers accordingly. I still don't see how knowing the explicit DTS helps the terminal. Maybe I don't understand something, but thinking about it as a developer, I don't care whether the difficulties are on implementing the decoding buffer model, or accommodating DTS < CTS at the composition buffer. 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: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Thursday, September 21, 2000 8:31 PM To: 'Zvi Lifshitz'; 'IETF AVT' Cc: '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal But MPEG does not put any limit on that Delta (CTS-DTS). In MPEG-2, different user groups (like ATSC, SMPTE, DVD, DVB etc) put their own limits for their own applications. It is not clear at this stage if those limits will be carried in the Internet world or not. They may not, as many Internet applications and users are lot more delay tolerant. So, if we have to assume some Delta at this stage then I would say that the proposal is broken as with in MPEG, currently, there is no assigned value to it, except in Simple Profile. Am I missing something? With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Thursday, September 21, 2000 12:00 PM To: 'Luthra, Ajay (SD-EX)'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal Ajay, You're right assuming DTS=CTS is not sufficient, but I believe we need to assume CTS-DTS < delta, when delta has an upper limit. If it doesn't we are in troubles because we don't know how much memory to allocate to the composition buffer. If indeed delta is known, it can be used to calculate the extra memory the decoding buffer would need to compensate for its ignorance of DTSs. 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: The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 www.isp-conferences.com/ispf2000 Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 -----Original Message----- From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] Sent: Thursday, September 21, 2000 7:17 PM To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal Zvi, Assuming CTS=DTS is confusing. If you have B-frames then there can be a large (arbitrary with no legal upper limit put by MPEG) difference between CTS and DTS. All the profiles except Simple use B-frames. So, unless we are defining this only for the carriage of MPEG4 Simple Profile ES over IP, this assumption does not seem to make sense. Due to instantaneous decoding model at the System Level, one can assume that the picture is instantaneously decoded and available for the prediction of next frame at DTS time (if DTS is present). However, this is not same as assuming CTS=DTS. Actually, if you are sending only one Time Stamp then you send CTS and your assumption will be DTS=CTS which will be a disaster. So, if there is no DTS and you have B-frames then only reasonable choice is to not to assume it to be anything (like DTS=CTS) and hope / pray receiver decodes the picture as fast it can and does not overflow. In MPEG-2 kind of environment with fixed/limited/pre-defined frame rates, it was easier to live without paying too much attention to DTS. I am not so sure about MPEG-4 where there is no fixed frame rate. That is one of the reasons the buffer model is so messy in the Video part of MPEG-4. Praying may not help here. Why is jitter forcing you to assume CTS=DTS? Are you saying that due to jitter in IP networks B-frames are not allowed and we need only to use Simple Profile? Please clarify. Thanks. With regards, Ajay -----Original Message----- From: Zvi Lifshitz [mailto:zvil@csi.com] Sent: Friday, September 15, 2000 12:34 AM To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' Subject: RE: comments on in-band-signaling proposal [Narasimhan, Sam (SD-EX):] 1. A video ES that required CTS (in the RTP header) and DTS (which could be in the adaptation field). This may be needed for receivers that implement MPEG buffer models. This stream can play on receivers that implement your draft as it has a bigger buffer and does not need DTS, as long as your draft enabled these receivers to use the adaptation length field to offset where the video ES payload was picked up. [Reply:] The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model. 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. Mobile: +972(53)461-787 http://www.optibase.com US voice mail/fax +1(206) 888-4149 Send SMS from: http://isend.cellcom.co.il/English/Login.htm ================================================================== > Come see us at: Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000 From rem-conf Thu Sep 21 12:18:14 2000 From rem-conf-request@es.net Thu Sep 21 12:18:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cBoC-0004WQ-00; Thu, 21 Sep 2000 12:15:00 -0700 Received: from lukla.sun.com [192.18.98.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cBoA-0004WB-00; Thu, 21 Sep 2000 12:14:58 -0700 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03447; Thu, 21 Sep 2000 13:14:56 -0600 (MDT) Received: from inbam.eng.sun.com (inbam.Eng.Sun.COM [129.146.122.106]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA15566; Thu, 21 Sep 2000 12:14:55 -0700 (PDT) Received: from inbam (inbam [129.146.122.106]) by inbam.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA04392; Thu, 21 Sep 2000 12:18:08 -0700 (PDT) Message-Id: <200009211918.MAA04392@inbam.eng.sun.com> Date: Thu, 21 Sep 2000 12:18:08 -0700 (PDT) From: Viswanathan Swaminathan Reply-To: Viswanathan Swaminathan Subject: Re: Types of MPEG-4 streams over IP To: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3o0t3th7Mi5m3kieqA/tnA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2308 Lines: 77 Jan, In your list you missed MPEG-J Streams. Regards, Vishy > X-Authentication-Warning: advent.ctr.columbia.edu: mjrdomo set sender to owner-4on2andIP-sys@advent.ee.columbia.edu using -f > From: jan.vandermeer@philips.com > To: , <4on2andIP-sys@advent.ee.columbia.edu> > Subject: Types of MPEG-4 streams over IP > Date: Thu, 21 Sep 2000 14:25:05 +0200 > MIME-Version: 1.0 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by advent.ctr.columbia.edu id IAA24511 > > Dear all, > > 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 : > > - 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 > > For MP4 files only a standard MIME type is required. For all other streams > also use of RTP and SDP need to be defined. Please correct me if I am wrong. > > The framework document (Singer et al) indicates that also a MIME type is > needed for an MPEG-4 MuxCodeTable. Is this required indeed, or can we assume > (/require) that the MuxCodeTable is transported inside the same FlexMux > stream (in a packet with simple mode). This could provide an easy solution > for the timing of applicability of the table that would need to be resolved > otherwise when using e.g. HTTP; however it would require MuxCodeTable to > become a new entry in the table for streamType values, right ? > > 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 > ************************ > > ------------------------------------------------------ Viswanathan Swaminathan Sun Microsystems Inc. 901 San Antonio Road, M/S UMPK15-214 Palo Alto, California 94303 Tel:(650) 786 4258 Fax:(650) 786 6445 email: vishy@eng.sun.com, viswanathan.swaminathan@eng.sun.com From rem-conf Thu Sep 21 16:12:05 2000 From rem-conf-request@es.net Thu Sep 21 16:12:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cFTH-0000LH-00; Thu, 21 Sep 2000 16:09:39 -0700 Received: from sigma.cisco.com (cisco.com) [171.69.63.142] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cFTF-0000Kk-00; Thu, 21 Sep 2000 16:09:37 -0700 Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA14634; Thu, 21 Sep 2000 16:00:45 -0700 (PDT) Message-Id: <4.3.1.0.20000918173607.01236230@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Sep 2000 04:05:09 -0700 To: Andy Valencia , Tmima Koren From: Bruce A Thompson Subject: Re: 0 byte L2TPHC header and implied PPPMUX Cc: "W. Mark Townsley" , dwing@cisco.com, Stephen Casner , gurdeep@microsoft.com, palter@zev.net, l2tp@diameter.org, rem-conf@es.net In-Reply-To: <200009141544.IAA00468@vandys-pc.zendo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 3442 Lines: 65 Sorry for the late response here. I just went through this thread. At 08:44 AM 09/14/2000 -0700, Andy Valencia wrote: >[Tmima Koren writes:] > > >>flag 2: value 1 means all packets have implied P=1 > >> value 0 means all packets have implied P=0 > >I'm concerned with this one. Since L2TPHC is basically useless except for >payload, what you've achieved with this flag is to ensure that your control >traffic will be interrupted if you *ever* permit all payload traffic to be >given preference by choosing P=1. My experience is that this will make your >link unworkable. And no, using the UDP side doesn't help, since priority is >(and should be) global to the PPP connection. I'm trying to understand this issue a little better. I assume normally, the P bit in the L2TP header would be mapped to IP precedence/DSCP at IP level. It sounnds like you are saying that when we negotiate for the P bit using the L2TPHC AVP, we are negotiating for the PPP session and not for the L2TPHC connection. However, L2TPHC does not preclude sending uncompressed L2TP packets down the UDP side. These frames will have the P bit set in them. If the P bit is negotiated using the L2TPHC AVP, are you saying that it should be ignored in uncompressed L2TP frames? >I would suggest that when omitting the L2TPHC header entirely, that P=0 >always be the mode of operation. This shouldn't affect your TCRTP mode of >operation, because the only thing aside from those payload packets would be >control packets which should be given priority anyway (and they can go via >UDP). > > >>When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can > > be omitted > >How about A/C fields? Isn't it a little weird that a field in the middle of >the PPP packet is coming and going based on this, but the bytes in front >depend on PPP negotiation? > >Also, why hard-wire it to PPPMUX? Why not include the implicit protocol >value, so that these savings could apply to IP-only connections which >weren't using PPPMUX and/or TCRTP? After thinking about PPPMUX negotiation using L2TP AVP negotiation, I think there's a layer violation here. PPPMUX is supposed to be negotiated using LCP. If we want to get rid of the PPPMUX protocol ID in the encapsulation, then why not negotiate this using another LCP option for PPPMUX? My bet is that the PPPEXT working group would accept this option. If PPPMUX was negotiated to not include the PPPMUX protocol ID, then the PPPMUX encapsulation would now not be RFC 1661 compliant. If this is an important option for bandwidth savings with multiplexed encapsulations, then it should be important for both L2TP and PPP. I think that this option should be proposed in PPPEXT and not as an extension to L2TP. Bruce T > >>PPP packets that have a different priority or that are not PPPMUX can still b > >e sent in the tunnel using the UDP/L2TP format, same as the L2TP control packe > >ts > >>TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: t > >he tunneling overhead will be reduced by 2 bytes. > >I guess I'm OK with a 0-byte L2TPHC header option (subject to a nod from the >chair). I'd sure like to hear from some people (not just infer something >from silence) on the PPP header aspect. > >Andy Valencia Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From rem-conf Thu Sep 21 17:40:05 2000 From rem-conf-request@es.net Thu Sep 21 17:40:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cGqx-00027h-00; Thu, 21 Sep 2000 17:38:11 -0700 Received: from smtp-out001.onemain.com (mail012.mail.onemain.com) [63.208.208.71] by mail1.es.net with smtp (Exim 1.81 #2) id 13cGqw-00027E-00; Thu, 21 Sep 2000 17:38:10 -0700 Received: (qmail 13935 invoked from network); 22 Sep 2000 00:27:08 -0000 Received: from unknown (HELO rZgA16xn3?) ([209.63.112.152]) (envelope-sender <037SUTfH9@excite.com>) by mail012.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 22 Sep 2000 00:27:08 -0000 DATE: 21 Sep 00 5:27:07 PM FROM: 037SUTfH9@excite.com Reply-to: ExpressEmail11@netscape.net Message-ID: TO: Dear webmaster SUBJECT: About your website X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1391 Lines: 37 Dear Webmaster, Just visited your website and thought you would be interested in a way to increase sales by leaps and bounds................. Are you tired of getting less than 100 visitors per day to your site? Now you can receive up to 1000 visitors a day or more using our extensive database of over 1,000,000 opt-in internet users to send your (spam free) email advertising to. These internet users have signed up and asked to revieve different offers via email. Plus, Get over $5000 in FREE "cash generating" software?! And, tons, of free products, services, and techniques to make your site look and run like a million bucks?! Also get access to my million dollar publishing business, complete with website, absolutely free! (Limited time offer) Do you have a service, message or product that you would like to advertise to the internet buyer? Now you can safely reach millions of people who "want" to read your ad! (spam free) Do What the "big boys" do and watch your sales soar through the roof, with just one click of a button! If your serious about making money online, then you can't afford to miss this unique offer, Visit us at: http://3630238861/%6D%65%67%61%68i%74s%2E%68%74%6D Please report broken link to:. Megahitspromoter@netscape.net Visit now and download our FREE 199 PAGE BOOK, "The Road To Riches". A must read for making money on the internet! From rem-conf Thu Sep 21 19:32:19 2000 From rem-conf-request@es.net Thu Sep 21 19:32:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cIa9-0004PK-00; Thu, 21 Sep 2000 19:28:57 -0700 Received: from smtp-out001.onemain.com (mail017.mail.onemain.com) [63.208.208.71] by mail1.es.net with smtp (Exim 1.81 #2) id 13cIa7-0004P2-00; Thu, 21 Sep 2000 19:28:55 -0700 Received: (qmail 28435 invoked from network); 21 Sep 2000 23:32:09 -0000 Received: from unknown (HELO RC3ac8AOO?) ([209.63.112.152]) (envelope-sender ) by mail017.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 21 Sep 2000 23:32:09 -0000 DATE: 21 Sep 00 4:32:08 PM FROM: GUa5w3qyi@excite.com Reply-to: ExpressEmail11@netscape.net Message-ID: <8r6Md2C96RH7olFy6TO> TO: Dear webmaster SUBJECT: About your website X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1391 Lines: 37 Dear Webmaster, Just visited your website and thought you would be interested in a way to increase sales by leaps and bounds................. Are you tired of getting less than 100 visitors per day to your site? Now you can receive up to 1000 visitors a day or more using our extensive database of over 1,000,000 opt-in internet users to send your (spam free) email advertising to. These internet users have signed up and asked to revieve different offers via email. Plus, Get over $5000 in FREE "cash generating" software?! And, tons, of free products, services, and techniques to make your site look and run like a million bucks?! Also get access to my million dollar publishing business, complete with website, absolutely free! (Limited time offer) Do you have a service, message or product that you would like to advertise to the internet buyer? Now you can safely reach millions of people who "want" to read your ad! (spam free) Do What the "big boys" do and watch your sales soar through the roof, with just one click of a button! If your serious about making money online, then you can't afford to miss this unique offer, Visit us at: http://3630238861/%6D%65%67%61%68i%74s%2E%68%74%6D Please report broken link to:. Megahitspromoter@netscape.net Visit now and download our FREE 199 PAGE BOOK, "The Road To Riches". A must read for making money on the internet! From rem-conf Thu Sep 21 19:49:59 2000 From rem-conf-request@es.net Thu Sep 21 19:49:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cIsv-0005W2-00; Thu, 21 Sep 2000 19:48:21 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cIst-0005Vq-00; Thu, 21 Sep 2000 19:48:19 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id TAA25136; Thu, 21 Sep 2000 19:48:16 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA00794; Thu, 21 Sep 2000 19:48:14 -0700 (MST)] Received: from hamsa.miel.mot.com (hamsa.miel.mot.com [199.2.101.49]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id IAA19558; Fri, 22 Sep 2000 08:23:20 +0530 (IST) Received: from localhost by hamsa.miel.mot.com (8.9.1/8.9.1) with ESMTP id IAA05048; Fri, 22 Sep 2000 08:18:10 +0530 (IST) Date: Fri, 22 Sep 2000 08:17:51 +0530 (IST) From: "Kuntal D. Sampat" 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 In-Reply-To: <0056890014249640000002L902*@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1738 Lines: 61 Jan, isn't the "ERROR_PROTECTION_STREAM" (from 14496-3/Amd.1:1999 Part 3, Section 9, pp. 124), which is the error protected audio stream also a unique streamType? -Kuntal. DSP Group, Motorola, India. On Thu, 21 Sep 2000 jan.vandermeer@philips.com wrote: > Dear all, > > 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 : > > - 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 > > For MP4 files only a standard MIME type is required. For all other streams > also use of RTP and SDP need to be defined. Please correct me if I am wrong. > > The framework document (Singer et al) indicates that also a MIME type is > needed for an MPEG-4 MuxCodeTable. Is this required indeed, or can we assume > (/require) that the MuxCodeTable is transported inside the same FlexMux > stream (in a packet with simple mode). This could provide an easy solution > for the timing of applicability of the table that would need to be resolved > otherwise when using e.g. HTTP; however it would require MuxCodeTable to > become a new entry in the table for streamType values, right ? > > 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 Fri Sep 22 00:43:11 2000 From rem-conf-request@es.net Fri Sep 22 00:43:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cNN2-0001qs-00; Fri, 22 Sep 2000 00:35:44 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13cNN0-0001qi-00; Fri, 22 Sep 2000 00:35:42 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Sep 2000 08:35:27 +0100 To: 'Hari Krishna Vuppaladhadiam' , rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Voice Playout for VoATM #2 In-reply-to: Your message of "Thu, 21 Sep 2000 08:19:35 BST." <937.969520775@cs.ucl.ac.uk> Date: Fri, 22 Sep 2000 08:35:25 +0100 Message-ID: <1387.969608125@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1403 Lines: 34 after a chat with orion hodson and dimitris terzis here who've done lots of voice of ip and atm: 2 more important consequences of playout for ATM versus IP 1/ native atm never re-orders packets - IP frequently does - this adds to the playout for an IP receiver potentially in odd ways - the re-ordering statistcs are not necessarily distributed the way that jitter is distributed when causesd by statistical multiplexing so algoruithms based on assu,mptions about that distribution (e.g. rolling averasge + some number times the variance of inter-arrival times) might not accomoadate this well, whereas ATM wont have this problem 2/ there's a strong incentive not to go for packetisation larger than a single cell in native atm, whereas in ip there's nothing to stop ou picking anything up to an mtu really - this leads to sender side delays in sampling and packetising and serialising the packet for transmission from an IP box - all of these may be subject to operating system scheduling effects too (see papre by kouvelas on cushioning these, or henning schulzrinnes work way back on various band pass filter ways of remioving these glitches) - again, vice on atm would be more like to be written device to device, and a cell payload at a time, so much less susceptible so basically, voice on atm playout is easier than voip, once you can swallow the idea of using ATM :-) cheers jon From rem-conf Fri Sep 22 04:42:04 2000 From rem-conf-request@es.net Fri Sep 22 04:42:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cR3N-0005wI-00; Fri, 22 Sep 2000 04:31:41 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cR3L-0005w7-00; Fri, 22 Sep 2000 04:31:40 -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 e8MBVHr04221; Fri, 22 Sep 2000 13:31:20 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "Jon Crowcroft" , "'Hari Krishna Vuppaladhadiam'" , Subject: RE: Voice Playout for VoATM #2 Date: Fri, 22 Sep 2000 13:31:17 +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: <1387.969608125@cs.ucl.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 81 Lines: 8 > [...] vice on atm [...] Is there an RFC for vice on ATM? Gruesse, Carsten From rem-conf Fri Sep 22 07:18:22 2000 From rem-conf-request@es.net Fri Sep 22 07:18:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cTaY-0000uj-00; Fri, 22 Sep 2000 07:14:06 -0700 Received: from scandd1.dresden.fhg.de (scandd1.fhg.de) [192.102.167.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cTaW-0000uZ-00; Fri, 22 Sep 2000 07:14:04 -0700 Received: from scandd1.fhg.de (localhost [127.0.0.1]) by scandd1.fhg.de (8.9.3/8.9.3) with ESMTP id QAA03397; Fri, 22 Sep 2000 16:14:02 +0200 (MET DST) Received: from iis.fhg.de (iis.iis.fhg.de [153.96.172.2]) by scandd1.fhg.de (8.9.3/8.9.3) with ESMTP id QAA03393; Fri, 22 Sep 2000 16:13:59 +0200 (MET DST) Received: by iis.fhg.de with ESMTP; Fri, 22 Sep 2000 16:13:57 +0200 (MET DST) from sunserv02.iis.fhg.de Received: from iis.fhg.de by sunserv02.iis.fhg.de (8.8.8+Sun/SMI-SVR4) id QAA28268; Fri, 22 Sep 2000 16:13:45 +0200 (MET DST) Message-ID: <39CA67D1.10E8DBF3@iis.fhg.de> Date: Thu, 21 Sep 2000 21:56:01 +0200 From: Ralph Sperschneider Organization: Fraunhofer IIS Audio & Multimedia (http://www.iis.fhg.de/amm) X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: Toshiyuki Nomura CC: John Lazzaro , tmn , grl , mpeg4_vm , purnhagen , rem-conf Subject: Re: LATM specified in a public MPEG document? References: <200009201826.LAA05456@snap.CS.Berkeley.EDU> <007e01c02376$f2313c80$152c380a@dsp.cl.nec.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 649 Lines: 22 Dear Toshiyuki, > Simple SA session without scene description can be realized > by the LATM-based RTP specification. Are these facts already stated within the current LATM description? We otherwise would now have the chance to clear these matters by means of the Corrigendum (deadline is the end of September). Best regards, Ralph -- Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344 FhG IIS-A | Fax: +49 9131 776 398 Am Weichselgarten 3 | mailto:sps@iis.fhg.de D 91058 Erlangen | http://www.iis.fhg.de/amm/ Facts do not cease to exist because they are ignored. (Aldous Huxley) From rem-conf Fri Sep 22 07:30:07 2000 From rem-conf-request@es.net Fri Sep 22 07:30:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cTpM-0001mK-00; Fri, 22 Sep 2000 07:29:24 -0700 Received: from tnt-dal-42-205.dallas.net (bfgbhome.inetint.com) [209.44.42.205] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cTpK-0001mA-00; Fri, 22 Sep 2000 07:29:22 -0700 Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id JAA17150; Fri, 22 Sep 2000 09:29:03 -0500 Date: Fri, 22 Sep 2000 09:29:03 -0500 From: "Brian F. G. Bidulock" To: "Dr. Carsten Bormann" Cc: Jon Crowcroft , "'Hari Krishna Vuppaladhadiam'" , rem-conf@es.net Subject: Re: Voice Playout for VoATM #2 Message-ID: <20000922092903.A17078@dallas.net> Reply-To: bidulock@dallas.net Mail-Followup-To: "Dr. Carsten Bormann" , Jon Crowcroft , 'Hari Krishna Vuppaladhadiam' , rem-conf@es.net References: <1387.969608125@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from cabo@tzi.org on Fri, Sep 22, 2000 at 01:31:17PM +0200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 143 Lines: 11 > > [...] vice on atm [...] > > Is there an RFC for vice on ATM? it be rc01.xt at ftp.iet.og -- Brian F. G. Bidulock bidulock@dallas.net From rem-conf Fri Sep 22 10:24:23 2000 From rem-conf-request@es.net Fri Sep 22 10:24:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cWSx-0004q6-00; Fri, 22 Sep 2000 10:18:27 -0700 Received: from (VISI.) [203.69.38.37] by mail1.es.net with smtp (Exim 1.81 #2) id 13cWSv-0004p4-00; Fri, 22 Sep 2000 10:18:25 -0700 Received: from _[169.248.95.149]_by by VISI. (SMI-8.6/SMI-SVR4) id LAA16663; Mon, 22 May 2000 11:17:24 +0800 From: ListMember343@earthonline.com Message-Id: <200005220317.LAA16663@VISI.> Received: from [97.238.10.212] by _[169.248.95.149]_by with SMTP id A24C26E10 Fri, 22 Sep 2000 12:59:20 PDT To: rem-conf@es.net Subject: RDRT CEO - Rapid Growth- Fibre Optic company IPO Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Fri, 22 Sep 2000 13:16:37 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 8337 Lines: 171 Read Read-Rite launches Scion, a new Fibre optics company

Read-Rite CEO gets into growth

By Janet Haney, CBS.MarketWatch.com
Last Update: 1:51 PM ET Sep 21, 2000 		NewsWatch
Latest headlines

SAN FRANCISCO (CBS.MW) -- Read-Rite Chief Executive Officer Alan Lowe waxed positive about the future growth prospects for the magnetic-recording-head supplier.

Lowe told a crowd of investors and analysts during a presentation at the Banc of America Securities Investment Conference in San Francisco on Thursday that he expects huge unit growth potential for Read-Rite's (RDRT: news, msgs) December quarter, as well as the possibility of profitability.

Lowe added that the company is hiring people as fast as it can for its wafer fabrication facility.

For the September quarter, the CEO said Read-Rite has a "lot of product to ship in the last 10 days of the quarter."

Additionally, Lowe talked about Read-Rite's recent formation of an independent fiber optic company called Scion Photonics which he said hopes to go public.

Scion received funding from Tyco, which will make a presentation at the conference later Thursday. 

Janet Haney is a reporter for CBS.MarketWatch.com.

 

Read-Rite Corp <RDRT> said late on Wednesday it has formed a new fibre optics company, Scion Photonics Inc, with $25 million in initial funding from Tyco Ventures and Integral Capital Partners. Read-Rite also said it was in discussions with several other interested parties for more technology and capital investments into Scion.

Scion's business charter is "to design, manufacture and market high-performance optical components to the fibre optics communications market," Read-Rite said in a statement.

Scion will act as a separate company, but will have access to Read-Rite's resources and manufacturing infrastructure, Read-Rite chairman Cyril Yansouni said in a statement. Read-Rite is contributing its Milpitas, California wafer fabrication plant, technical and management resources and its knowledge and experience in thin-film technology and materials science to Scion, which will be based in Milpitas.

Tyco Ventures, the venture capital unit of Tyco International Ltd. <TYC>, invested $15 million in Scion and also invested $15 million in Read-Rite through a private placement with the company, Tyco Ventures president Richard Kashnow said in a statement.

 

 
For the complete streaming audio story users should access
http://www.on24.com/index.html?id=36870&type=av&ref=bizwire
 

ALWAYS DO RESEARCH BEFORE INVESTING IN ANY STOCK!!!

 

 

From rem-conf Fri Sep 22 11:21:12 2000 From rem-conf-request@es.net Fri Sep 22 11:21:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cXMB-0006aI-00; Fri, 22 Sep 2000 11:15:31 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cXMA-0006a8-00; Fri, 22 Sep 2000 11:15:30 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA01556; Fri, 22 Sep 2000 11:15:20 -0700 Date: Fri, 22 Sep 2000 11:15:20 -0700 From: John Lazzaro Message-Id: <200009221815.LAA01556@snap.CS.Berkeley.EDU> To: sps@iis.fhg.de, t-nomura@ccm.cl.nec.co.jp Subject: Re: LATM specified in a public MPEG document? Cc: grl@iis.fhg.de, lazzaro@cs.berkeley.edu, mpeg4_vm@tnt.uni-hannover.de, purnhagen@tnt.uni-hannover.de, rem-conf@es.net, tmn@iis.fhg.de X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2258 Lines: 46 >> Simple SA session without scene description can be realized >> by the LATM-based RTP specification. > Are these facts already stated within the current LATM description? > We otherwise would now have the chance to clear these matters by means > of the Corrigendum (deadline is the end of September). Since there's no publicly-available LATM document, I'm on shakey ground commenting on this, but nonetheless -- note that the MIDI SA_access_unit's don't include their own timestamp (unlike SASL SA_access_units that do have an optional timestamp in "scorebeats", which are tempo modulatable), and since Bodo Teichmann's comment stated: > [ Bodo Teichmann writes] > > > LATM was actually developed for only "natural" audio coders, > > i.e. not fo Structured Audio. it is not possible to transmitt > > multiple objects, no scene desctipion and no time stamps > > can be transmitted . This means that taking LATM by itself, there would be no way to have timestamps on MIDI SA_access_units. For RTP over LATM this shouldn't be insurmountable, because of the RTP timestamps, but if the Corrigendum you're mentioning isn't about LATM over RTP but just LATM itself, it would seem to break using MIDI in SA_access_units for all but "use immediately" semantics, which is what I assumed the quoted section above meant to convey. For my own work, its becoming clear that making an RTP packetization just for Structured Audio is the right thing to do -- one lost MIDI NoteOff command can really wreck the entire performance (for those not familiar with MIDI, NoteOff's end individual notes of a performance which are begun by a NoteOn -- a lost NoteOff means a note that sounds "forever"), and a packetization meant for interactive performance over low-latency networks really has to address this issue to be useful, either by schemes similiar to draft-ietf-avt-rtprx-00.txt for unicast, or by various FEC approaches for multicast ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Fri Sep 22 11:41:21 2000 From rem-conf-request@es.net Fri Sep 22 11:41:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cXi9-0007e3-00; Fri, 22 Sep 2000 11:38:13 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cXhz-0007cF-00; Fri, 22 Sep 2000 11:38:03 -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 LAA17483 for ; Fri, 22 Sep 2000 11:37:58 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Fri, 22 Sep 2000 11:37:58 -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 LAA01726; Fri, 22 Sep 2000 11:37:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <0056890014249640000002L902*@MHS> References: <0056890014249640000002L902*@MHS> Date: Fri, 22 Sep 2000 11:34:30 -0700 To: jan.vandermeer@philips.com 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 Content-Length: 1449 Lines: 38 At 2:25 PM +0200 9/21/00, jan.vandermeer@philips.com wrote: >Dear all, > >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 : > >- 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 > >For MP4 files only a standard MIME type is required. For all other streams >also use of RTP and SDP need to be defined. Please correct me if I am wrong. > >The framework document (Singer et al) indicates that also a MIME type is >needed for an MPEG-4 MuxCodeTable. Is this required indeed, or can we assume >(/require) that the MuxCodeTable is transported inside the same FlexMux >stream (in a packet with simple mode). This could provide an easy solution >for the timing of applicability of the table that would need to be resolved >otherwise when using e.g. HTTP; however it would require MuxCodeTable to >become a new entry in the table for streamType values, right ? The MuxCodeTable needs to be delivered out-of-band. If you see my proposal, it was to deliver this via a URL in SDP, which then requires a MIME type if HTTP or DATA are to be used. -- David Singer Apple Computer/QuickTime From rem-conf Fri Sep 22 11:41:26 2000 From rem-conf-request@es.net Fri Sep 22 11:41:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cXi1-0007ch-00; Fri, 22 Sep 2000 11:38:05 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cXhz-0007cK-00; Fri, 22 Sep 2000 11:38:03 -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 LAA17514 for ; Fri, 22 Sep 2000 11:38:02 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Fri, 22 Sep 2000 11:37:59 -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 LAA01743; Fri, 22 Sep 2000 11:37:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <200009221815.LAA01556@snap.CS.Berkeley.EDU> References: <200009221815.LAA01556@snap.CS.Berkeley.EDU> Date: Fri, 22 Sep 2000 11:35:40 -0700 To: John Lazzaro From: Dave Singer Subject: Re: LATM specified in a public MPEG document? Cc: sps@iis.fhg.de, t-nomura@ccm.cl.nec.co.jp, grl@iis.fhg.de, lazzaro@CS.Berkeley.EDU, mpeg4_vm@tnt.uni-hannover.de, purnhagen@tnt.uni-hannover.de, rem-conf@es.net, tmn@iis.fhg.de Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 565 Lines: 18 At 11:15 AM -0700 9/22/00, John Lazzaro wrote: > >> Simple SA session without scene description can be realized >>> by the LATM-based RTP specification. > >> Are these facts already stated within the current LATM description? >> We otherwise would now have the chance to clear these matters by means >> of the Corrigendum (deadline is the end of September). > >Since there's no publicly-available LATM document, well, this is a show-stopper. we cannot base a standard on something that is not publicly defined. -- David Singer Apple Computer/QuickTime From rem-conf Fri Sep 22 12:03:55 2000 From rem-conf-request@es.net Fri Sep 22 12:03:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cY57-0001gS-00; Fri, 22 Sep 2000 12:01:57 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cY56-0001gI-00; Fri, 22 Sep 2000 12:01:56 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id MAA01790; Fri, 22 Sep 2000 12:01:06 -0700 Date: Fri, 22 Sep 2000 12:01:06 -0700 From: John Lazzaro Message-Id: <200009221901.MAA01790@snap.CS.Berkeley.EDU> To: lazzaro@cs.berkeley.edu, singer@apple.com Subject: Re: LATM specified in a public MPEG document? Cc: grl@iis.fhg.de, mpeg4_vm@tnt.uni-hannover.de, purnhagen@tnt.uni-hannover.de, rem-conf@es.net, sps@iis.fhg.de, t-nomura@ccm.cl.nec.co.jp, tmn@iis.fhg.de X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 951 Lines: 21 > well, this is a show-stopper. we cannot base a standard on something > that is not publicly defined. Oh, this is just temporary -- eventually anyone can send a check to MPEG and buy the FDIS that defines LATM, which I think would meet the requirement of "publicly defined". Usually the FCD's are posted on publically-available websites like this one: http://sound.media.mit.edu/mpeg4/audio/ but you'll notice the last FCD is Dec 1999 (scroll down to MPEG 4) which is pre-LATM. So in that sense, I'm in the dark as someone outside of MPEG trying to comment on an I-D that references something not in a publically available working document ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Fri Sep 22 18:02:48 2000 From rem-conf-request@es.net Fri Sep 22 18:02:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cddk-0007Ru-00; Fri, 22 Sep 2000 17:58:04 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13cddh-0007Rf-00; Fri, 22 Sep 2000 17:58:02 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-100.dialup.cs.tu-berlin.de [130.149.145.100]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id CAA01887; Sat, 23 Sep 2000 02:53:13 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000922025625.029e2490@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Sep 2000 03:00:40 +0200 To: "Luthra, Ajay (SD-EX)" From: Stephan Wenger Subject: RE: comments on in-band-signaling proposal Cc: "'Zvi Lifshitz'" , "'IETF AVT'" , "'4on2andIP-sys@advent.ee.columbia.edu'" <4on2andIP-sys@advent.ee.columbia.edu> In-Reply-To: <973597126BDDD11197AA00805FA7EBC90342168B@ntas0026.gi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 5995 Lines: 146 At 02:31 PM 9/21/00 -0400, Luthra, Ajay (SD-EX) wrote: >But MPEG does not put any limit on that Delta (CTS-DTS). In MPEG-2, >different user groups (like ATSC, SMPTE, DVD, DVB etc) put their own limits >for their own applications. It is not clear at this stage if those limits >will be carried in the Internet world or not. They may not, as many Internet >applications and users are lot more delay tolerant. So, if we have to assume >some Delta at this stage then I would say that the proposal is broken as >with in MPEG, currently, there is no assigned value to it, except in Simple >Profile. Am I missing something? My remark to that thread would be that it may be desirable that a payload spec allows for the full functionality of a media coding, but that there is no obligation to have such an attribute. Maybe a sentence indicating that, when B-frames are used, it is necessarily to carefully tune the size of the playout buffer may be enough? I personally would object to add more timestamp fields in the payload header just to accommodate some theoretically possible applications that are more than unlikely to happen in the field. Stephan >With regards, >Ajay > >-----Original Message----- >From: Zvi Lifshitz [mailto:zvil@csi.com] >Sent: Thursday, September 21, 2000 12:00 PM >To: 'Luthra, Ajay (SD-EX)'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro >Kikuchi'; IETF AVT; 'jan.vandermeer@philips.com' >Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' >Subject: RE: comments on in-band-signaling proposal > > >Ajay, > >You're right assuming DTS=CTS is not sufficient, but I believe we need to >assume CTS-DTS < delta, when delta has an upper limit. If it doesn't we are >in troubles because we don't know how much memory to allocate to the >composition buffer. If indeed delta is known, it can be used to calculate >the extra memory the decoding buffer would need to compensate for its >ignorance of DTSs. > >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: >The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 >www.isp-conferences.com/ispf2000 >Streaming Media Europe Earls Court Centre, Booth # 628, London, October >10th-12th, 2000 > > >-----Original Message----- >From: Luthra, Ajay (SD-EX) [SMTP:ALuthra@gi.com] >Sent: Thursday, September 21, 2000 7:17 PM >To: 'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF > >AVT; 'jan.vandermeer@philips.com' >Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' >Subject: RE: comments on in-band-signaling proposal > > >Zvi, > Assuming CTS=DTS is confusing. If you have B-frames then there can be a >large (arbitrary with no legal upper limit put by MPEG) difference between >CTS and DTS. All the profiles except Simple use B-frames. So, unless we are >defining this only for the carriage of MPEG4 Simple Profile ES over IP, >this >assumption does not seem to make sense. Due to instantaneous decoding model >at the System Level, one can assume that the picture is instantaneously >decoded and available for the prediction of next frame at DTS time (if DTS >is present). However, this is not same as assuming CTS=DTS. Actually, if >you >are sending only one Time Stamp then you send CTS and your assumption will >be DTS=CTS which will be a disaster. So, if there is no DTS and you have >B-frames then only reasonable choice is to not to assume it to be anything >(like DTS=CTS) and hope / pray receiver decodes the picture as fast it can >and does not overflow. In MPEG-2 kind of environment with >fixed/limited/pre-defined frame rates, it was easier to live without paying >too much attention to DTS. I am not so sure about MPEG-4 where there is no >fixed frame rate. That is one of the reasons the buffer model is so messy >in >the Video part of MPEG-4. Praying may not help here. > > Why is jitter forcing you to assume CTS=DTS? Are you saying that due to >jitter in IP networks B-frames are not allowed and we need only to use >Simple Profile? > > Please clarify. Thanks. > >With regards, >Ajay > >-----Original Message----- >From: Zvi Lifshitz [mailto:zvil@csi.com] >Sent: Friday, September 15, 2000 12:34 AM >To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT; >'jan.vandermeer@philips.com' >Cc: Colin Perkins; '4on2andIP-sys@advent.ee.columbia.edu' >Subject: RE: comments on in-band-signaling proposal > > >[Narasimhan, Sam (SD-EX):] > >1. A video ES that required CTS (in the RTP header) and DTS (which > could be in the adaptation field). This may be needed for receivers > that implement MPEG buffer models. This stream can play on > receivers that implement your draft as it has a bigger buffer > and does not need DTS, as long as your draft enabled these > receivers to use the adaptation length field to offset where > the video ES payload was picked up. > >[Reply:] > >The jitter on IP network is such that practically receivers may always >assume CTS=DTS for implementation of the buffer model. > >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. Mobile: +972(53)461-787 >http://www.optibase.com US voice mail/fax +1(206) 888-4149 >Send SMS from: http://isend.cellcom.co.il/English/Login.htm >================================================================== > > Come see us at: >Streaming Media Europe Earls Court Centre, Booth # 628, London, October >10th-12th, 2000 From rem-conf Sat Sep 23 12:55:42 2000 From rem-conf-request@es.net Sat Sep 23 12:55:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13cvA1-0004Os-00; Sat, 23 Sep 2000 12:40:33 -0700 Received: from bodhi.zendo.com [205.187.71.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13cv9z-0004Oe-00; Sat, 23 Sep 2000 12:40:31 -0700 Received: from vandys-pc.zendo.com (dialup-209.244.109.239.Seattle1.Level3.net [209.244.109.239]) by bodhi.zendo.com (8.10.1/8.10.1) with ESMTP id e8NBG0909719; Sat, 23 Sep 2000 11:16:01 GMT Received: from vandys-pc.zendo.com (localhost.zendo.com [127.0.0.1]) by vandys-pc.zendo.com (8.9.1/8.9.1) with ESMTP id MAA00543; Sat, 23 Sep 2000 12:37:27 -0700 (PDT) (envelope-from vandys@vandys-pc.zendo.com) Message-Id: <200009231937.MAA00543@vandys-pc.zendo.com> To: Bruce A Thompson cc: Tmima Koren , "W. Mark Townsley" , dwing@cisco.com, Stephen Casner , gurdeep@microsoft.com, palter@zev.net, l2tp@diameter.org, rem-conf@es.net Subject: Re: 0 byte L2TPHC header and implied PPPMUX In-reply-to: Your message of "Tue, 19 Sep 2000 04:05:09 PDT." <4.3.1.0.20000918173607.01236230@sigma.cisco.com> Date: Sat, 23 Sep 2000 12:37:26 -0700 From: Andy Valencia X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1033 Lines: 24 [Bruce A Thompson writes:] >I assume normally, the P bit in the L2TP header would be mapped to IP preceden >ce/DSCP at IP level. No. This is packet queueing on the transmitter of an HDLC device carrying PPP. >After thinking about PPPMUX negotiation using L2TP AVP negotiation, I think th >ere's a layer violation here. PPPMUX is supposed to be negotiated using LCP. I >f we want to get rid of the PPPMUX protocol ID in the encapsulation, then why >not negotiate this using another LCP option for PPPMUX? Because we're not talking about removing the PPP protocol ID. We're talking about L2TP not carrying it across the link, because it's implicitly understood, and can be inserted after the PPP packet (sans protocol ID) has traversed the L2TP link. So this is an L2TP(HC)-only consideration. PPP continues to see what it always saw. And you can't do it at the PPP level, because then there'd be no way for NCP (not even LCP) to talk across the link--which PPPEXT would assuredly reject! Andy Valencia From rem-conf Sat Sep 23 17:12:06 2000 From rem-conf-request@es.net Sat Sep 23 17:12:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13czJp-0000Dv-00; Sat, 23 Sep 2000 17:06:57 -0700 Received: from othello.physics.gla.ac.uk [130.209.204.200] (exim) by mail1.es.net with esmtp (Exim 1.81 #2) id 13czJo-0000Dl-00; Sat, 23 Sep 2000 17:06:56 -0700 Received: from a5.ph.gla.ac.uk ([130.209.45.103]) by othello.physics.gla.ac.uk with esmtp (Exim 3.13 #1) id 13czJm-0008Dw-00; Sun, 24 Sep 2000 01:06:54 +0100 Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with ESMTP id BAA20755; Sun, 24 Sep 2000 01:06:53 +0100 (BST) Date: Sun, 24 Sep 2000 01:06:53 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: "Brian F. G. Bidulock" cc: postmaster@dallas.net, rem-conf@es.net Subject: Email abuse, was Re: So, How in the heck have you been? In-Reply-To: <20000921032808.A7095@dallas.net> Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 551 Lines: 21 On Thu, 21 Sep 2000, Brian F. G. Bidulock wrote: > Could someone PLEEEEEASE put a spam filter on this list! Please would you (and anyone else tempted to copy you) desist from relaying additional copies of spam, and complaints about it, to all the other victims, and refer your proposals to the list owner. Postmaster, please instruct your user about appropriate use of email. Thank you. Fortunately I won't be seeing anything else from this particular user, as their address is going straight into my filter list. (24K of drivel deleted) From rem-conf Sun Sep 24 12:01:14 2000 From rem-conf-request@es.net Sun Sep 24 12:01:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dGtU-0005TY-00; Sun, 24 Sep 2000 11:52:56 -0700 Received: from annies.annies.co.jp [210.173.129.1] by mail1.es.net with smtp (Exim 1.81 #2) id 13dGtS-0005TL-00; Sun, 24 Sep 2000 11:52:55 -0700 Received: from sdn-ar-002riprovp285.dialsprint.net by annies.annies.co.jp (NX5.67g/NX3.0M) id AA12622; Mon, 25 Sep 2000 03:42:48 +0900 Message-Id: <200009241842.AA12622@annies.annies.co.jp> From: "Kile Franco" Subject: Big Change #28F8 To: online29e@matmail.com X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Sun, 24 Sep 2000 13:39:06 -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 Content-Length: 834 Lines: 34 Accepting credit cards for your business Has never been so easy & affordable! Our specialty is establishing your merchant account! NO APPLICATION =46EE! NO PROGRAMMING =46EE! $9.95 PROCESSING =46EE Call today and apply: (888) 264-9272 Now you can design your web site with our complete software package, which offers: =B7 Domain Registration =B7 Web Hosting Services =B7 Web Design Tools =B7 Online Shopping Cart =B7 Credit Card Processing Integration Quick, Easy and Affordable at just $99.00! Call (888) 264-9272 and order today! ************************************************************ If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:pk92l@starmate.net?subject=3Dremove ************************************************************ From rem-conf Sun Sep 24 18:31:27 2000 From rem-conf-request@es.net Sun Sep 24 18:31:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dMv9-0003si-00; Sun, 24 Sep 2000 18:19:03 -0700 Received: from ace.uproad.ne.jp [202.216.193.11] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13dMv7-0003sY-00; Sun, 24 Sep 2000 18:19:02 -0700 Received: from sdn-ar-005mokcitP165.dialsprint.net_[206.133.173.101] (sdn-ar-005mokcitP165.dialsprint.net [206.133.173.101]) by ace.uproad.ne.jp (8.10.1/3.7W) with SMTP id e8P112Y00637; Mon, 25 Sep 2000 10:01:05 +0900 Received: from alpha.futurenet.co.za by sdn-ar-005mokcitP165.dialsprint.net with ESMTP; Sun, 24 Sep 2000 20:04:47 -0500 Message-ID: <00003cc2704c$000024fb$0000242a@alpha.futurenet.co.za> To: From: bmw325@actebis-sro.cz Subject: Re: Earn a fortune in the currency market 9258 Date: Sun, 24 Sep 2000 20:04:45 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 4174 Lines: 100
= 



Do You Have The Yen To Be a A Millionaire?

100% return in less than 90 days!

Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

Get our Reports, Charts and Strategies on the U.S. Dollar vs
Japanese yen and euro dollar.

Example:

A $5,000 Investment in the yen vs the dollar, "properly positioned",
on 08/18 could have returned $15,184.45 on 09/19/99.

For a "FREE NO OBLIGATION PACKET" Just Click Below to visit our website:


CLICK HERE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






To Be Removed From Any Future Mailings:
Click here and = click on link at bottom of page that loadsThanks! ************************************************************

<= SCRIPT LANGUAGE=3D"JavaScript">=

From rem-conf Sun Sep 24 21:18:58 2000 From rem-conf-request@es.net Sun Sep 24 21:18:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dPdE-0006PK-00; Sun, 24 Sep 2000 21:12:44 -0700 Received: from xyu01.xiyou.edu.cn [202.117.128.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13dPdA-0006PA-00; Sun, 24 Sep 2000 21:12:41 -0700 Received: from atm06 ([202.117.133.25]) by xyu01.xiyou.edu.cn (8.9.2/8.9.2) with SMTP id MAA26405 for ; Mon, 25 Sep 2000 12:15:06 +0800 (CST) Message-ID: <001501c026a6$f636ff80$060a0a0a@atm06> From: "huang tingxue" To: Subject: RTP payload format for G.723.1? Date: Mon, 25 Sep 2000 12:13:29 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C026EA.03EDE920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 887 Lines: 32 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C026EA.03EDE920 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I don't know whether RTP payload format for G.723.1 exists. If someone = know , please tell me. I am very thankful! ------=_NextPart_000_0012_01C026EA.03EDE920 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I don't know whether RTP payload = format for=20 G.723.1 exists. If someone know , please tell me. I am very=20 thankful!
------=_NextPart_000_0012_01C026EA.03EDE920-- From rem-conf Mon Sep 25 05:27:08 2000 From rem-conf-request@es.net Mon Sep 25 05:27:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dXBa-0004qq-00; Mon, 25 Sep 2000 05:16:42 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13dXBX-0004qf-00; Mon, 25 Sep 2000 05:16:40 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA09825; Mon, 25 Sep 2000 14:16:37 +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 xma009823; Mon, 25 Sep 00 14:16:37 +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 OAA21586; Mon, 25 Sep 2000 14:16:36 +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 OAA17994; Mon, 25 Sep 2000 14:16:36 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014340965; Mon, 25 Sep 2000 14:17:40 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014340965000002L952*@MHS> Date: Mon, 25 Sep 2000 14:17:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/25/00 14:15:08" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 746 Lines: 32 Hello David, Yes, I understand and I agree that a URL is a fine solution for a stati= c table. However, I understood that the MuxCode may change in the course = of a FlexMux. If yes, then the timing of the change need be specified. In th= at case in-band carriage of the MuxCode maybe a more convenient solution. = If such in-band carriage was defined, would there still be a need for a UR= L ? But I may miss something. Perhaps we constrain the use of MuxCode to st= atic cases ? Kind regards, Jan van der Meer The MuxCodeTable needs to be delivered out-of-band. If you see my proposal, it was to deliver this via a URL in SDP, which then requires a MIME type if HTTP or DATA are to be used. -- David Singer Apple Computer/QuickTime = From rem-conf Mon Sep 25 05:45:53 2000 From rem-conf-request@es.net Mon Sep 25 05:45:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dXWK-0005rD-00; Mon, 25 Sep 2000 05:38:08 -0700 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 13dXWG-0005qn-00; Mon, 25 Sep 2000 05:38:04 -0700 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 39CBB1D0000103E5 for rem-conf@es.net; Mon, 25 Sep 2000 14:34:53 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.048) id 39CB75B1000151EA for rem-conf@es.net; Mon, 25 Sep 2000 14:33:57 +0200 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 14:33:55 +0200 (Paris, Madrid (heure d't)) X-Internal-ID: 39CA6F2100001677 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; Mon, 25 Sep 2000 14:38:04 +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 337; Mon, 25 Sep 2000 14:23:00 +0200 Message-ID: <39CF4695.3E0E2AB@thomcast.thomson-csf.com> Date: Mon, 25 Sep 2000 14:35:33 +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: singer@apple.com, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: Types of MPEG-4 streams over IP References: <0056890014340965000002L952*@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 Content-Length: 1518 Lines: 56 Dear Jan, I'm not sure, but the change of the MuxCode may also be announced through= an out of band mean. As an example, in SDP/SAP, a server may automatically update the mpeg4-flexmuxinfo as described in Dave's framework, and announce the chan= ge by updating the Message Identifier Hash of the SAP header to announce that t= he session description has been modified. The change timing capacity in SDP = may be used to specify the time at which the change is valid.The session description may use a "t=3D " line for that purpose. in case RTSP is used to convey the flexmuxinfo, I guess the Cseq paramet= er may be used to announce a change has occured in the SDP session. Regards Pierre jan.vandermeer@philips.com a =E9crit : > Hello David, > > Yes, I understand and I agree that a URL is a fine solution for a stati= c > table. However, I understood that the MuxCode may change in the course = of a > FlexMux. If yes, then the timing of the change need be specified. In th= at > case in-band carriage of the MuxCode maybe a more convenient solution. = If > such in-band carriage was defined, would there still be a need for a UR= L ? > > But I may miss something. Perhaps we constrain the use of MuxCode to st= atic > cases ? > > Kind regards, > > Jan van der Meer > > The MuxCodeTable needs to be delivered out-of-band. If you see my > proposal, it was to deliver this via a URL in SDP, which then > requires a MIME type if HTTP or DATA are to be used. > -- > David Singer > Apple Computer/QuickTime From rem-conf Mon Sep 25 08:31:32 2000 From rem-conf-request@es.net Mon Sep 25 08:31:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13da4y-0001CQ-00; Mon, 25 Sep 2000 08:22:04 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13da4v-0001CF-00; Mon, 25 Sep 2000 08:22:02 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA29425; Mon, 25 Sep 2000 11:22:18 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA22478; Mon, 25 Sep 2000 20:21:59 +0500 Message-Id: <200009251521.UAA22478@hafez.east.isi.edu> To: huang tingxue cc: rem-conf Subject: Re: RTP payload format for G.723.1? In-Reply-To: Your message of "Mon, 25 Sep 2000 12:13:29 +0800." <001501c026a6$f636ff80$060a0a0a@atm06> Date: Mon, 25 Sep 2000 11:21:59 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 208 Lines: 9 --> huang tingxue writes: >I don't know whether RTP payload format for G.723.1 exists. If someone >know , please tell me. I am very thankful! See section 4.5.4 of draft-ietf-avt-profile-new-09.txt Colin From rem-conf Mon Sep 25 11:03:27 2000 From rem-conf-request@es.net Mon Sep 25 11:03:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dcZ9-0004Yd-00; Mon, 25 Sep 2000 11:01:23 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13dcZ7-0004YT-00; Mon, 25 Sep 2000 11:01:21 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA05183; Mon, 25 Sep 2000 11:00:30 -0700 Date: Mon, 25 Sep 2000 11:00:30 -0700 From: John Lazzaro Message-Id: <200009251800.LAA05183@snap.CS.Berkeley.EDU> To: lazzaro@cs.berkeley.edu, sps@iis.fhg.de, t-nomura@ccm.cl.nec.co.jp Subject: Re: LATM specified in a public MPEG document? Cc: grl@iis.fhg.de, mpeg4_vm@tnt.uni-hannover.de, purnhagen@tnt.uni-hannover.de, rem-conf@es.net, tmn@iis.fhg.de X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2611 Lines: 62 > By the way, could you let me know what is "use immediately semantics"? >From 5.5.2 of 14496-3:1999(E), starting at the bottom of page 20: The Structured Audio access unit contains real-time streaming control information to be provided to a running Structured Audio decoding process. It may contain as many control instructions as desired and as permitted by the available bandwidth. It shall not contain new instrument definitions; the orchestra configuration is fixed at decoder start-up. It may contain score lines, MIDI events, and new sample data. When provided as part of an access unit, the score line is not required to contain a timestamp. When has_time is cleared in the score_line class, the event is dispatched immediately according to the rules in subclause 5.7.3.3.6. Score lines without timestamps are not responsive to orchestra tempo changes. Annex 5.E discusses when the random access point flag, conveyed in the Access Unit packaging in the Systems specification, may be set. The "score line is not required to contain a timestamp" section is what I meant by "use immediately semantics". > I think such limitation should not be described in the LATM > itself definitions. > This is because these matters depend on the functions of the > transport layer. I guess the issue I'm trying to bring up is this: [1] Let's say you're sending an SA_access_unit using MIDI, whose semantics are NOT "use immediately semantics". If so, you're dependent on a timestamp to say "when to fire" supplied from elsewhere. Note this means the timestamp has two bounds on it -- too early and the note fires too early, too late and the note fires too late. The precision of the timestamp becomes the precision of the performance -- too sloppy and things sound bad. [2] If I understand the earlier info on LATM correctly (remember, I don't have access to the spec), LATM doesn't supply timestamps. [3] So, whatever packetization is used (for example, RTP), needs to supply this timestamp -- however, the accuracy requirements for this timestamp (as described in [1] above) is sufficiently unusual for someone used to "natural audio" codecs, that an explicit heads up may be in order, in both the LATM and the RTP documents. Hope this helps ... --john lazzaro ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Mon Sep 25 11:03:44 2000 From rem-conf-request@es.net Mon Sep 25 11:03:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dcav-0004ax-00; Mon, 25 Sep 2000 11:03:13 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13dcat-0004an-00; Mon, 25 Sep 2000 11:03:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09564; Mon, 25 Sep 2000 14:03:09 -0400 (EDT) Message-Id: <200009251803.OAA09564@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 25 Sep 2000 14:03:08 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 717 Lines: 19 The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio as a Proposed Standard. Note that a companion document, RTP Payload Format for DV Format Video has already been last called. 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 9, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-audio-02.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-video-03.txt From rem-conf Mon Sep 25 21:32:42 2000 From rem-conf-request@es.net Mon Sep 25 21:32:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dmGg-00006n-00; Mon, 25 Sep 2000 21:22:58 -0700 Received: from netsys.kaist.ac.kr [143.248.148.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13dmGZ-00006d-00; Mon, 25 Sep 2000 21:22:51 -0700 Received: from hinet1 (netsys1.kaist.ac.kr [143.248.148.77]) by netsys.kaist.ac.kr (8.9.3/8.9.3) with SMTP id SAA01994; Mon, 25 Sep 2000 18:49:16 +0900 Message-ID: <000c01c026dd$84948e10$4d94f88f@hinet1> From: "PV2001" To: , , , , , Subject: PV2001 Final Call for Papers Date: Mon, 25 Sep 2000 19:44:01 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C02728.F463A500" 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 Content-Length: 146560 Lines: 1919 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C02728.F463A500 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgYXR0YWNoZWQgRmluYWwgQ2FsbCBmb3IgUGFwZXJzIG9mIFBhY2tldCBWaWRl byBXb3Jrc2hvcCAyMDAxIHRvIGJlIGhlbGQgaW4gS3l1bmdqdSwgS29yZWEgRHVyaW5nIDMwIEFw cmlsIC0gMSBNYXksIDIwMDEuDQoNClRoZSBkZWFkbGluZSBmb3IgcGFwZXIgc3VibWlzc2lvbiwg MTUgTm92ZW1iZXIgMjAwMCwgaXMgY29taW5nIHNvb24uDQoNClVwZGF0ZWQgcGFwZXIgc3VibWlz c2lvaW4gaW5mb3JtYXRpb24gaXMgYXQNCmh0dHA6Ly9wdjIwMDEua2Fpc3QuYWMua3IuDQoNCkZv ciBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VuZCBhbiBlbWFpbCB0byBwdkBwdjIwMDEu a2Fpc3QuYWMua3IuDQoNCldlIGxvb2sgZm9yd2FyZCB0byBhbiBleGNpdGluZyBQVjIwMDEuDQoN CkJlc3QgUmVnYXJkcywNCkNoaWV0ZXVrIEFobg0KUFYyMDAxIE9yZ2FuaXppbmcgQ29tbWl0dGVl IENoYWlyDQo= ------=_NextPart_000_000A_01C02728.F463A500 Content-Type: application/pdf; name="PVW-callforpaper-final.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PVW-callforpaper-final.pdf" JVBERi0xLjINJeLjz9MNCjMgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDUgDS9IIFsgMTE4 NzkgNzM4IF0gDS9MIDEwNzY5NSANL0UgMTA3MzcyIA0vTiAxIA0vVCAxMDc1MTggDT4+IA1lbmRv YmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMgNTc0IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMTE4MjYgMDAwMDAgbg0KMDAw MDAxMjYxNyAwMDAwMCBuDQowMDAwMDEyODI5IDAwMDAwIG4NCjAwMDAwMTgyMDYgMDAwMDAgbg0K MDAwMDAxODI1NSAwMDAwMCBuDQowMDAwMDE4MzA0IDAwMDAwIG4NCjAwMDAwMTgzNTMgMDAwMDAg bg0KMDAwMDAxODQwMyAwMDAwMCBuDQowMDAwMDE4NDUzIDAwMDAwIG4NCjAwMDAwMTg1MDMgMDAw MDAgbg0KMDAwMDAxODU1MyAwMDAwMCBuDQowMDAwMDE4NjAzIDAwMDAwIG4NCjAwMDAwMTg2NTMg MDAwMDAgbg0KMDAwMDAxODcwMyAwMDAwMCBuDQowMDAwMDE4NzUzIDAwMDAwIG4NCjAwMDAwMTg4 MDMgMDAwMDAgbg0KMDAwMDAxODg1MyAwMDAwMCBuDQowMDAwMDE4OTAzIDAwMDAwIG4NCjAwMDAw MTg5NTMgMDAwMDAgbg0KMDAwMDAxOTAwMyAwMDAwMCBuDQowMDAwMDE5MDUzIDAwMDAwIG4NCjAw MDAwMTkxMDMgMDAwMDAgbg0KMDAwMDAxOTE1MyAwMDAwMCBuDQowMDAwMDE5MjAzIDAwMDAwIG4N CjAwMDAwMTkyNTMgMDAwMDAgbg0KMDAwMDAxOTMwMyAwMDAwMCBuDQowMDAwMDE5MzUzIDAwMDAw IG4NCjAwMDAwMTk0MDMgMDAwMDAgbg0KMDAwMDAxOTQ1MyAwMDAwMCBuDQowMDAwMDE5NTAzIDAw MDAwIG4NCjAwMDAwMTk1NTMgMDAwMDAgbg0KMDAwMDAxOTYwMyAwMDAwMCBuDQowMDAwMDE5NjUz IDAwMDAwIG4NCjAwMDAwMTk3MDMgMDAwMDAgbg0KMDAwMDAxOTc1MyAwMDAwMCBuDQowMDAwMDE5 ODAzIDAwMDAwIG4NCjAwMDAwMTk4NTMgMDAwMDAgbg0KMDAwMDAxOTkwMyAwMDAwMCBuDQowMDAw MDE5OTUzIDAwMDAwIG4NCjAwMDAwMjAwMDMgMDAwMDAgbg0KMDAwMDAyMDA1MyAwMDAwMCBuDQow MDAwMDIwMTAzIDAwMDAwIG4NCjAwMDAwMjAxNTMgMDAwMDAgbg0KMDAwMDAyMDIwMyAwMDAwMCBu DQowMDAwMDIwMjUzIDAwMDAwIG4NCjAwMDAwMjAzMDMgMDAwMDAgbg0KMDAwMDAyMDM1MyAwMDAw MCBuDQowMDAwMDIwNDAzIDAwMDAwIG4NCjAwMDAwMjA0NTMgMDAwMDAgbg0KMDAwMDAyMDUwMyAw MDAwMCBuDQowMDAwMDIwNTUzIDAwMDAwIG4NCjAwMDAwMjA2MDMgMDAwMDAgbg0KMDAwMDAyMDY1 MyAwMDAwMCBuDQowMDAwMDIwNzAzIDAwMDAwIG4NCjAwMDAwMjA3NTMgMDAwMDAgbg0KMDAwMDAy MDgwMyAwMDAwMCBuDQowMDAwMDIwODUzIDAwMDAwIG4NCjAwMDAwMjA5MDMgMDAwMDAgbg0KMDAw MDAyMDk1MyAwMDAwMCBuDQowMDAwMDIxMDAzIDAwMDAwIG4NCjAwMDAwMjEwNTMgMDAwMDAgbg0K MDAwMDAyMTEwMyAwMDAwMCBuDQowMDAwMDIxMTUzIDAwMDAwIG4NCjAwMDAwMjEyMDMgMDAwMDAg bg0KMDAwMDAyMTI1MyAwMDAwMCBuDQowMDAwMDIxMzAzIDAwMDAwIG4NCjAwMDAwMjEzNTMgMDAw MDAgbg0KMDAwMDAyMTQwMyAwMDAwMCBuDQowMDAwMDIxNDUzIDAwMDAwIG4NCjAwMDAwMjE1MDMg MDAwMDAgbg0KMDAwMDAyMTU1MyAwMDAwMCBuDQowMDAwMDIxNjAzIDAwMDAwIG4NCjAwMDAwMjE2 NTMgMDAwMDAgbg0KMDAwMDAyMTcwMyAwMDAwMCBuDQowMDAwMDIxNzUzIDAwMDAwIG4NCjAwMDAw MjE4MDMgMDAwMDAgbg0KMDAwMDAyMTg1MyAwMDAwMCBuDQowMDAwMDIxOTAzIDAwMDAwIG4NCjAw MDAwMjE5NTMgMDAwMDAgbg0KMDAwMDAyMjAwMyAwMDAwMCBuDQowMDAwMDIyMDUzIDAwMDAwIG4N CjAwMDAwMjIyNDEgMDAwMDAgbg0KMDAwMDAyMjYzMCAwMDAwMCBuDQowMDAwMDIyODE4IDAwMDAw IG4NCjAwMDAwMjMxMTMgMDAwMDAgbg0KMDAwMDAyMzMwNCAwMDAwMCBuDQowMDAwMDIzODcxIDAw MDAwIG4NCjAwMDAwMjQwNTIgMDAwMDAgbg0KMDAwMDAyNDQ0MyAwMDAwMCBuDQowMDAwMDI0NjIz IDAwMDAwIG4NCjAwMDAwMjQ2NzMgMDAwMDAgbg0KMDAwMDAyNDcyMyAwMDAwMCBuDQowMDAwMDI1 MTQ5IDAwMDAwIG4NCjAwMDAwMjUzNDcgMDAwMDAgbg0KMDAwMDAyNTg3NyAwMDAwMCBuDQowMDAw MDI2MDgzIDAwMDAwIG4NCjAwMDAwMjYxMzMgMDAwMDAgbg0KMDAwMDAyNjE4NCAwMDAwMCBuDQow MDAwMDI2MjM1IDAwMDAwIG4NCjAwMDAwMjYyODYgMDAwMDAgbg0KMDAwMDAyNjMzNyAwMDAwMCBu DQowMDAwMDI2Mzg4IDAwMDAwIG4NCjAwMDAwMjY0MzkgMDAwMDAgbg0KMDAwMDAyNjQ5MCAwMDAw MCBuDQowMDAwMDI2NTQxIDAwMDAwIG4NCjAwMDAwMjY1OTIgMDAwMDAgbg0KMDAwMDAyNjY0MyAw MDAwMCBuDQowMDAwMDI2Njk0IDAwMDAwIG4NCjAwMDAwMjY3NDUgMDAwMDAgbg0KMDAwMDAyNjc5 NiAwMDAwMCBuDQowMDAwMDI2ODQ3IDAwMDAwIG4NCjAwMDAwMjY4OTggMDAwMDAgbg0KMDAwMDAy Njk0OSAwMDAwMCBuDQowMDAwMDI3MDAwIDAwMDAwIG4NCjAwMDAwMjcwNTEgMDAwMDAgbg0KMDAw MDAyNzEwMiAwMDAwMCBuDQowMDAwMDI3MTUzIDAwMDAwIG4NCjAwMDAwMjcyMDQgMDAwMDAgbg0K MDAwMDAyNzI1NSAwMDAwMCBuDQowMDAwMDI3MzA2IDAwMDAwIG4NCjAwMDAwMjczNTcgMDAwMDAg bg0KMDAwMDAyNzQwOCAwMDAwMCBuDQowMDAwMDI3NDU5IDAwMDAwIG4NCjAwMDAwMjc1MTAgMDAw MDAgbg0KMDAwMDAyNzU2MSAwMDAwMCBuDQowMDAwMDI3NjEyIDAwMDAwIG4NCjAwMDAwMjc2NjMg MDAwMDAgbg0KMDAwMDAyNzcxNCAwMDAwMCBuDQowMDAwMDI3NzY1IDAwMDAwIG4NCjAwMDAwMjc4 MTYgMDAwMDAgbg0KMDAwMDAyNzg2NyAwMDAwMCBuDQowMDAwMDI3OTE4IDAwMDAwIG4NCjAwMDAw Mjc5NjkgMDAwMDAgbg0KMDAwMDAyODAyMCAwMDAwMCBuDQowMDAwMDI4MDcxIDAwMDAwIG4NCjAw MDAwMjgxMjIgMDAwMDAgbg0KMDAwMDAyODE3MyAwMDAwMCBuDQowMDAwMDI4MjI0IDAwMDAwIG4N CjAwMDAwMjgyNzUgMDAwMDAgbg0KMDAwMDAyODMyNiAwMDAwMCBuDQowMDAwMDI4Mzc3IDAwMDAw IG4NCjAwMDAwMjg0MjggMDAwMDAgbg0KMDAwMDAyODQ3OSAwMDAwMCBuDQowMDAwMDI4NTMwIDAw MDAwIG4NCjAwMDAwMjg1ODEgMDAwMDAgbg0KMDAwMDAyODYzMiAwMDAwMCBuDQowMDAwMDI4Njgz IDAwMDAwIG4NCjAwMDAwMjg3MzQgMDAwMDAgbg0KMDAwMDAyODc4NSAwMDAwMCBuDQowMDAwMDI4 ODM2IDAwMDAwIG4NCjAwMDAwMjg4ODcgMDAwMDAgbg0KMDAwMDAyODkzOCAwMDAwMCBuDQowMDAw MDI4OTg5IDAwMDAwIG4NCjAwMDAwMjkwNDAgMDAwMDAgbg0KMDAwMDAyOTA5MSAwMDAwMCBuDQow MDAwMDI5MTQyIDAwMDAwIG4NCjAwMDAwMjkxOTMgMDAwMDAgbg0KMDAwMDAyOTI0NCAwMDAwMCBu DQowMDAwMDI5Mjk1IDAwMDAwIG4NCjAwMDAwMjkzNDYgMDAwMDAgbg0KMDAwMDAyOTM5NyAwMDAw MCBuDQowMDAwMDI5NDQ4IDAwMDAwIG4NCjAwMDAwMjk0OTkgMDAwMDAgbg0KMDAwMDAyOTU1MCAw MDAwMCBuDQowMDAwMDI5NjAxIDAwMDAwIG4NCjAwMDAwMjk2NTIgMDAwMDAgbg0KMDAwMDAyOTcw MyAwMDAwMCBuDQowMDAwMDI5NzU0IDAwMDAwIG4NCjAwMDAwMjk4MDUgMDAwMDAgbg0KMDAwMDAy OTg1NiAwMDAwMCBuDQowMDAwMDI5OTA3IDAwMDAwIG4NCjAwMDAwMjk5NTggMDAwMDAgbg0KMDAw MDAzMDAwOSAwMDAwMCBuDQowMDAwMDMwMDYwIDAwMDAwIG4NCjAwMDAwMzAxMTEgMDAwMDAgbg0K MDAwMDAzMDE2MiAwMDAwMCBuDQowMDAwMDMwMjEzIDAwMDAwIG4NCjAwMDAwMzAyNjQgMDAwMDAg bg0KMDAwMDAzMDMxNSAwMDAwMCBuDQowMDAwMDMwMzY2IDAwMDAwIG4NCjAwMDAwMzA0MTcgMDAw MDAgbg0KMDAwMDAzMDQ2OCAwMDAwMCBuDQowMDAwMDMwNTE5IDAwMDAwIG4NCjAwMDAwMzA1NzAg MDAwMDAgbg0KMDAwMDAzMDYyMSAwMDAwMCBuDQowMDAwMDMwNjcyIDAwMDAwIG4NCjAwMDAwMzA3 MjMgMDAwMDAgbg0KMDAwMDAzMDc3NCAwMDAwMCBuDQowMDAwMDMwODI1IDAwMDAwIG4NCjAwMDAw MzA4NzYgMDAwMDAgbg0KMDAwMDAzMDkyNyAwMDAwMCBuDQowMDAwMDMwOTc4IDAwMDAwIG4NCjAw MDAwMzEwMDEgMDAwMDAgbg0KMDAwMDAzMjYyOSAwMDAwMCBuDQowMDAwMDMyODI1IDAwMDAwIG4N CjAwMDAwMzMxMTAgMDAwMDAgbg0KMDAwMDAzMzMyNSAwMDAwMCBuDQowMDAwMDMzNDA0IDAwMDAw IG4NCjAwMDAwMzM2MjcgMDAwMDAgbg0KMDAwMDAzMzY1MCAwMDAwMCBuDQowMDAwMDM1NDk4IDAw MDAwIG4NCjAwMDAwMzU2NzkgMDAwMDAgbg0KMDAwMDAzNTg4NyAwMDAwMCBuDQowMDAwMDM1OTU0 IDAwMDAwIG4NCjAwMDAwMzYxMjUgMDAwMDAgbg0KMDAwMDAzNjE0OCAwMDAwMCBuDQowMDAwMDM3 NzU5IDAwMDAwIG4NCjAwMDAwMzc3ODIgMDAwMDAgbg0KMDAwMDAzOTU0NCAwMDAwMCBuDQowMDAw MDM5NTY3IDAwMDAwIG4NCjAwMDAwNDEzOTggMDAwMDAgbg0KMDAwMDA0MTYwNiAwMDAwMCBuDQow MDAwMDQxNzc3IDAwMDAwIG4NCjAwMDAwNDE5NTggMDAwMDAgbg0KMDAwMDA0MjAyNSAwMDAwMCBu DQowMDAwMDQyMDQ4IDAwMDAwIG4NCjAwMDAwNDM1NDAgMDAwMDAgbg0KMDAwMDA0MzU2MiAwMDAw MCBuDQowMDAwMDQ0MjQ0IDAwMDAwIG4NCjAwMDAwNDQyNjYgMDAwMDAgbg0KMDAwMDA0NDkwMyAw MDAwMCBuDQowMDAwMDQ1MDIzIDAwMDAwIG4NCjAwMDAwNDUxNzEgMDAwMDAgbg0KMDAwMDA0NTI5 MSAwMDAwMCBuDQowMDAwMDQ1NDE0IDAwMDAwIG4NCjAwMDAwNDU1MjggMDAwMDAgbg0KMDAwMDA0 NTY1MiAwMDAwMCBuDQowMDAwMDQ1ODAxIDAwMDAwIG4NCjAwMDAwNDU5MTIgMDAwMDAgbg0KMDAw MDA0NjAyOSAwMDAwMCBuDQowMDAwMDQ2MTQwIDAwMDAwIG4NCjAwMDAwNDYyNTEgMDAwMDAgbg0K MDAwMDA0NjQwMCAwMDAwMCBuDQowMDAwMDQ2NTQ5IDAwMDAwIG4NCjAwMDAwNDY2NjYgMDAwMDAg bg0KMDAwMDA0Njc4MCAwMDAwMCBuDQowMDAwMDQ2OTMyIDAwMDAwIG4NCjAwMDAwNDcwNTMgMDAw MDAgbg0KMDAwMDA0NzIwOCAwMDAwMCBuDQowMDAwMDQ3MzcwIDAwMDAwIG4NCjAwMDAwNDc0OTEg MDAwMDAgbg0KMDAwMDA0NzYxMSAwMDAwMCBuDQowMDAwMDQ3NzI4IDAwMDAwIG4NCjAwMDAwNDc4 NDggMDAwMDAgbg0KMDAwMDA0Nzk3MiAwMDAwMCBuDQowMDAwMDQ4MTMwIDAwMDAwIG4NCjAwMDAw NDgyNDcgMDAwMDAgbg0KMDAwMDA0ODM3MSAwMDAwMCBuDQowMDAwMDQ4NTI5IDAwMDAwIG4NCjAw MDAwNDg2NTAgMDAwMDAgbg0KMDAwMDA0ODgwMiAwMDAwMCBuDQowMDAwMDQ4OTE2IDAwMDAwIG4N CjAwMDAwNDkwNDAgMDAwMDAgbg0KMDAwMDA0OTE1NCAwMDAwMCBuDQowMDAwMDQ5MjY4IDAwMDAw IG4NCjAwMDAwNDkzOTEgMDAwMDAgbg0KMDAwMDA0OTUxNSAwMDAwMCBuDQowMDAwMDQ5NjM5IDAw MDAwIG4NCjAwMDAwNDk3NTAgMDAwMDAgbg0KMDAwMDA0OTg0NSAwMDAwMCBuDQowMDAwMDQ5OTk3 IDAwMDAwIG4NCjAwMDAwNTAxMDggMDAwMDAgbg0KMDAwMDA1MDU0NCAwMDAwMCBuDQowMDAwMDUw NjYxIDAwMDAwIG4NCjAwMDAwNTA3NzggMDAwMDAgbg0KMDAwMDA1MDg4MiAwMDAwMCBuDQowMDAw MDUwOTg3IDAwMDAwIG4NCjAwMDAwNTExNDIgMDAwMDAgbg0KMDAwMDA1MTI1NSAwMDAwMCBuDQow MDAwMDUxMzcyIDAwMDAwIG4NCjAwMDAwNTE0NzYgMDAwMDAgbg0KMDAwMDA1MTU5MyAwMDAwMCBu DQowMDAwMDUxNzgwIDAwMDAwIG4NCjAwMDAwNTE4ODQgMDAwMDAgbg0KMDAwMDA1MTk4OCAwMDAw MCBuDQowMDAwMDUyMTA1IDAwMDAwIG4NCjAwMDAwNTIyMTYgMDAwMDAgbg0KMDAwMDA1MjMyMCAw MDAwMCBuDQowMDAwMDUyNDM3IDAwMDAwIG4NCjAwMDAwNTI1NDggMDAwMDAgbg0KMDAwMDA1MjY2 MSAwMDAwMCBuDQowMDAwMDUyODIwIDAwMDAwIG4NCjAwMDAwNTI5MzQgMDAwMDAgbg0KMDAwMDA1 MzA4OSAwMDAwMCBuDQowMDAwMDUzMTk2IDAwMDAwIG4NCjAwMDAwNTMzNTQgMDAwMDAgbg0KMDAw MDA1MzQ2NSAwMDAwMCBuDQowMDAwMDUzNTc2IDAwMDAwIG4NCjAwMDAwNTM2ODcgMDAwMDAgbg0K MDAwMDA1MzgyNiAwMDAwMCBuDQowMDAwMDUzOTM2IDAwMDAwIG4NCjAwMDAwNTQwODcgMDAwMDAg bg0KMDAwMDA1NDIwMSAwMDAwMCBuDQowMDAwMDU0MzA4IDAwMDAwIG4NCjAwMDAwNTQ0MTkgMDAw MDAgbg0KMDAwMDA1NDUzNiAwMDAwMCBuDQowMDAwMDU0Njc1IDAwMDAwIG4NCjAwMDAwNTQ3OTIg MDAwMDAgbg0KMDAwMDA1NDkwMiAwMDAwMCBuDQowMDAwMDU1MDE5IDAwMDAwIG4NCjAwMDAwNTUx MjkgMDAwMDAgbg0KMDAwMDA1NTI0OSAwMDAwMCBuDQowMDAwMDU1MzczIDAwMDAwIG4NCjAwMDAw NTU0ODQgMDAwMDAgbg0KMDAwMDA1NTYwNyAwMDAwMCBuDQowMDAwMDU1NzI0IDAwMDAwIG4NCjAw MDAwNTU4NDIgMDAwMDAgbg0KMDAwMDA1NTk1OSAwMDAwMCBuDQowMDAwMDU2MDc2IDAwMDAwIG4N CjAwMDAwNTYxODkgMDAwMDAgbg0KMDAwMDA1NjMwMCAwMDAwMCBuDQowMDAwMDU2NDI0IDAwMDAw IG4NCjAwMDAwNTY1NDIgMDAwMDAgbg0KMDAwMDA1NjY1MyAwMDAwMCBuDQowMDAwMDU2NzY5IDAw MDAwIG4NCjAwMDAwNTY4ODAgMDAwMDAgbg0KMDAwMDA1Njk5NCAwMDAwMCBuDQowMDAwMDU3MTEx IDAwMDAwIG4NCjAwMDAwNTcyMzIgMDAwMDAgbg0KMDAwMDA1NzM0OSAwMDAwMCBuDQowMDAwMDU3 NDYwIDAwMDAwIG4NCjAwMDAwNTc1NzQgMDAwMDAgbg0KMDAwMDA1NzY5NCAwMDAwMCBuDQowMDAw MDU3ODA1IDAwMDAwIG4NCjAwMDAwNTc5MjIgMDAwMDAgbg0KMDAwMDA1ODAzOSAwMDAwMCBuDQow MDAwMDU4MTQ5IDAwMDAwIG4NCjAwMDAwNTgyNjYgMDAwMDAgbg0KMDAwMDA1ODM4MyAwMDAwMCBu DQowMDAwMDU4NTAwIDAwMDAwIG4NCjAwMDAwNTg2MTcgMDAwMDAgbg0KMDAwMDA1ODczNCAwMDAw MCBuDQowMDAwMDU4ODUxIDAwMDAwIG4NCjAwMDAwNTg5NjggMDAwMDAgbg0KMDAwMDA1OTA4NSAw MDAwMCBuDQowMDAwMDU5MTk5IDAwMDAwIG4NCjAwMDAwNTkzMDkgMDAwMDAgbg0KMDAwMDA1OTQy NiAwMDAwMCBuDQowMDAwMDU5NTQzIDAwMDAwIG4NCjAwMDAwNTk2NjAgMDAwMDAgbg0KMDAwMDA1 OTc3NCAwMDAwMCBuDQowMDAwMDU5ODkxIDAwMDAwIG4NCjAwMDAwNjAwMDggMDAwMDAgbg0KMDAw MDA2MDExOSAwMDAwMCBuDQowMDAwMDYwMjM2IDAwMDAwIG4NCjAwMDAwNjAzNDcgMDAwMDAgbg0K MDAwMDA2MDQ2NCAwMDAwMCBuDQowMDAwMDYwNTgxIDAwMDAwIG4NCjAwMDAwNjA3MDEgMDAwMDAg bg0KMDAwMDA2MDg0NCAwMDAwMCBuDQowMDAwMDYwOTYxIDAwMDAwIG4NCjAwMDAwNjExMTAgMDAw MDAgbg0KMDAwMDA2MTIzMCAwMDAwMCBuDQowMDAwMDYxMzQ3IDAwMDAwIG4NCjAwMDAwNjE0NjEg MDAwMDAgbg0KMDAwMDA2MTU3OCAwMDAwMCBuDQowMDAwMDYxNjk5IDAwMDAwIG4NCjAwMDAwNjE4 MTYgMDAwMDAgbg0KMDAwMDA2MTk2OSAwMDAwMCBuDQowMDAwMDYyMDkwIDAwMDAwIG4NCjAwMDAw NjIyMDcgMDAwMDAgbg0KMDAwMDA2MjM2NSAwMDAwMCBuDQowMDAwMDYyNDc5IDAwMDAwIG4NCjAw MDAwNjI1OTIgMDAwMDAgbg0KMDAwMDA2Mjc1MyAwMDAwMCBuDQowMDAwMDYyODY0IDAwMDAwIG4N CjAwMDAwNjI5ODEgMDAwMDAgbg0KMDAwMDA2MzA5OCAwMDAwMCBuDQowMDAwMDYzMjQ0IDAwMDAw IG4NCjAwMDAwNjMzNTggMDAwMDAgbg0KMDAwMDA2MzQ2OSAwMDAwMCBuDQowMDAwMDYzNjIxIDAw MDAwIG4NCjAwMDAwNjM3MzggMDAwMDAgbg0KMDAwMDA2Mzg1OCAwMDAwMCBuDQowMDAwMDYzOTcy IDAwMDAwIG4NCjAwMDAwNjQwODkgMDAwMDAgbg0KMDAwMDA2NDE5OSAwMDAwMCBuDQowMDAwMDY0 MzEwIDAwMDAwIG4NCjAwMDAwNjQ0MjEgMDAwMDAgbg0KMDAwMDA2NDU0NSAwMDAwMCBuDQowMDAw MDY0NjY5IDAwMDAwIG4NCjAwMDAwNjQ3OTIgMDAwMDAgbg0KMDAwMDA2NDkwNiAwMDAwMCBuDQow MDAwMDY1MDE5IDAwMDAwIG4NCjAwMDAwNjUxMjMgMDAwMDAgbg0KMDAwMDA2NTI0NyAwMDAwMCBu DQowMDAwMDY1MzcxIDAwMDAwIG4NCjAwMDAwNjU0OTEgMDAwMDAgbg0KMDAwMDA2NTYwOCAwMDAw MCBuDQowMDAwMDY1NzI1IDAwMDAwIG4NCjAwMDAwNjU4MzYgMDAwMDAgbg0KMDAwMDA2NTk1NyAw MDAwMCBuDQowMDAwMDY2MDc3IDAwMDAwIG4NCjAwMDAwNjYyMDEgMDAwMDAgbg0KMDAwMDA2NjMx MiAwMDAwMCBuDQowMDAwMDY2NDM2IDAwMDAwIG4NCjAwMDAwNzIwMzMgMDAwMDAgbg0KMDAwMDA3 MjIxMyAwMDAwMCBuDQowMDAwMDcyMzk3IDAwMDAwIG4NCjAwMDAwNzI1ODEgMDAwMDAgbg0KMDAw MDA3Mjc3NCAwMDAwMCBuDQowMDAwMDcyOTY1IDAwMDAwIG4NCjAwMDAwNzMxNTUgMDAwMDAgbg0K MDAwMDA3MzM0NCAwMDAwMCBuDQowMDAwMDczNTMzIDAwMDAwIG4NCjAwMDAwNzM3MjIgMDAwMDAg bg0KMDAwMDA3MzkxMSAwMDAwMCBuDQowMDAwMDc0MTAwIDAwMDAwIG4NCjAwMDAwNzQyODkgMDAw MDAgbg0KMDAwMDA3NDQ3OCAwMDAwMCBuDQowMDAwMDc0NjY3IDAwMDAwIG4NCjAwMDAwNzQ4NTUg MDAwMDAgbg0KMDAwMDA3NTA0NCAwMDAwMCBuDQowMDAwMDc1MjMzIDAwMDAwIG4NCjAwMDAwNzU0 MjMgMDAwMDAgbg0KMDAwMDA3NTYxNyAwMDAwMCBuDQowMDAwMDc1ODExIDAwMDAwIG4NCjAwMDAw NzYwMDUgMDAwMDAgbg0KMDAwMDA3NjE5OSAwMDAwMCBuDQowMDAwMDc2Mzk0IDAwMDAwIG4NCjAw MDAwNzY1ODkgMDAwMDAgbg0KMDAwMDA3Njc4NCAwMDAwMCBuDQowMDAwMDc2OTgxIDAwMDAwIG4N CjAwMDAwNzcxNzcgMDAwMDAgbg0KMDAwMDA3NzM3MyAwMDAwMCBuDQowMDAwMDc3NTY5IDAwMDAw IG4NCjAwMDAwNzc3NjMgMDAwMDAgbg0KMDAwMDA3Nzk1OCAwMDAwMCBuDQowMDAwMDc4MTUzIDAw MDAwIG4NCjAwMDAwNzgzNDggMDAwMDAgbg0KMDAwMDA3ODU0MyAwMDAwMCBuDQowMDAwMDc4NzM4 IDAwMDAwIG4NCjAwMDAwNzg5MzEgMDAwMDAgbg0KMDAwMDA3OTEyNCAwMDAwMCBuDQowMDAwMDc5 MzE2IDAwMDAwIG4NCjAwMDAwNzk1MDUgMDAwMDAgbg0KMDAwMDA3OTY5NCAwMDAwMCBuDQowMDAw MDc5ODg3IDAwMDAwIG4NCjAwMDAwODAwODEgMDAwMDAgbg0KMDAwMDA4MDI3NSAwMDAwMCBuDQow MDAwMDgwNDcwIDAwMDAwIG4NCjAwMDAwODA2NjcgMDAwMDAgbg0KMDAwMDA4MDg2NCAwMDAwMCBu DQowMDAwMDgxMDYxIDAwMDAwIG4NCjAwMDAwODEyNTggMDAwMDAgbg0KMDAwMDA4MTQ1MyAwMDAw MCBuDQowMDAwMDgxNjUwIDAwMDAwIG4NCjAwMDAwODE4NDcgMDAwMDAgbg0KMDAwMDA4MjA0NCAw MDAwMCBuDQowMDAwMDgyMjM5IDAwMDAwIG4NCjAwMDAwODI0MzMgMDAwMDAgbg0KMDAwMDA4MjYy OCAwMDAwMCBuDQowMDAwMDgyODIzIDAwMDAwIG4NCjAwMDAwODMwMTcgMDAwMDAgbg0KMDAwMDA4 MzIxMCAwMDAwMCBuDQowMDAwMDgzNDA0IDAwMDAwIG4NCjAwMDAwODM1OTggMDAwMDAgbg0KMDAw MDA4Mzc5MiAwMDAwMCBuDQowMDAwMDgzOTg0IDAwMDAwIG4NCjAwMDAwODQxNzYgMDAwMDAgbg0K MDAwMDA4NDM2OSAwMDAwMCBuDQowMDAwMDg0NTYyIDAwMDAwIG4NCjAwMDAwODQ3NTUgMDAwMDAg bg0KMDAwMDA4NDk0OSAwMDAwMCBuDQowMDAwMDg1MTQyIDAwMDAwIG4NCjAwMDAwODUzMzQgMDAw MDAgbg0KMDAwMDA4NTUyNiAwMDAwMCBuDQowMDAwMDg1NzE3IDAwMDAwIG4NCjAwMDAwODU5MDgg MDAwMDAgbg0KMDAwMDA4NjEwMSAwMDAwMCBuDQowMDAwMDg2Mjk0IDAwMDAwIG4NCjAwMDAwODY0 ODcgMDAwMDAgbg0KMDAwMDA4NjY4MCAwMDAwMCBuDQowMDAwMDg2ODc0IDAwMDAwIG4NCjAwMDAw ODcwNjggMDAwMDAgbg0KMDAwMDA4NzI2MiAwMDAwMCBuDQowMDAwMDg3NDU3IDAwMDAwIG4NCjAw MDAwODc2NTAgMDAwMDAgbg0KMDAwMDA4Nzg0NSAwMDAwMCBuDQowMDAwMDg4MDQwIDAwMDAwIG4N CjAwMDAwODgyMzUgMDAwMDAgbg0KMDAwMDA4ODQzMCAwMDAwMCBuDQowMDAwMDg4NjI1IDAwMDAw IG4NCjAwMDAwODg4MjAgMDAwMDAgbg0KMDAwMDA4OTAxNSAwMDAwMCBuDQowMDAwMDg5MjA5IDAw MDAwIG4NCjAwMDAwODk0MDMgMDAwMDAgbg0KMDAwMDA4OTU5OCAwMDAwMCBuDQowMDAwMDg5Nzkz IDAwMDAwIG4NCjAwMDAwODk5ODggMDAwMDAgbg0KMDAwMDA5MDE4MiAwMDAwMCBuDQowMDAwMDkw Mzc2IDAwMDAwIG4NCjAwMDAwOTA1NzEgMDAwMDAgbg0KMDAwMDA5MDc2NSAwMDAwMCBuDQowMDAw MDkwOTU5IDAwMDAwIG4NCjAwMDAwOTExNTMgMDAwMDAgbg0KMDAwMDA5MTM0NiAwMDAwMCBuDQow MDAwMDkxNTQxIDAwMDAwIG4NCjAwMDAwOTE3MzQgMDAwMDAgbg0KMDAwMDA5MTkyNyAwMDAwMCBu DQowMDAwMDkyMTIwIDAwMDAwIG4NCjAwMDAwOTIzMTMgMDAwMDAgbg0KMDAwMDA5MjUwNyAwMDAw MCBuDQowMDAwMDkyNzAwIDAwMDAwIG4NCjAwMDAwOTI4OTMgMDAwMDAgbg0KMDAwMDA5MzA4NiAw MDAwMCBuDQowMDAwMDkzMjgwIDAwMDAwIG4NCjAwMDAwOTM0NzQgMDAwMDAgbg0KMDAwMDA5MzY2 OCAwMDAwMCBuDQowMDAwMDkzODYwIDAwMDAwIG4NCjAwMDAwOTQwNTUgMDAwMDAgbg0KMDAwMDA5 NDI1MCAwMDAwMCBuDQowMDAwMDk0NDQ0IDAwMDAwIG4NCjAwMDAwOTQ2MzggMDAwMDAgbg0KMDAw MDA5NDgzMyAwMDAwMCBuDQowMDAwMDk1MDI4IDAwMDAwIG4NCjAwMDAwOTUyMjMgMDAwMDAgbg0K MDAwMDA5NTQxOCAwMDAwMCBuDQowMDAwMDk1NjEyIDAwMDAwIG4NCjAwMDAwOTU4MDYgMDAwMDAg bg0KMDAwMDA5NjAwMCAwMDAwMCBuDQowMDAwMDk2MTkzIDAwMDAwIG4NCjAwMDAwOTYzODYgMDAw MDAgbg0KMDAwMDA5NjU3NyAwMDAwMCBuDQowMDAwMDk2NzY4IDAwMDAwIG4NCjAwMDAwOTY5NTkg MDAwMDAgbg0KMDAwMDA5NzE1MCAwMDAwMCBuDQowMDAwMDk3MzQxIDAwMDAwIG4NCjAwMDAwOTc1 MzIgMDAwMDAgbg0KMDAwMDA5NzcyMyAwMDAwMCBuDQowMDAwMDk3OTE0IDAwMDAwIG4NCjAwMDAw OTgxMDUgMDAwMDAgbg0KMDAwMDA5ODI5NiAwMDAwMCBuDQowMDAwMDk4NDg3IDAwMDAwIG4NCjAw MDAwOTg2NzggMDAwMDAgbg0KMDAwMDA5ODg2OSAwMDAwMCBuDQowMDAwMDk5MDYwIDAwMDAwIG4N CjAwMDAwOTkyNTIgMDAwMDAgbg0KMDAwMDA5OTQ0NCAwMDAwMCBuDQowMDAwMDk5NjI4IDAwMDAw IG4NCjAwMDAwOTk4NDEgMDAwMDAgbg0KMDAwMDEwMDA1NSAwMDAwMCBuDQowMDAwMTAwMjY2IDAw MDAwIG4NCjAwMDAxMDA0NzkgMDAwMDAgbg0KMDAwMDEwMDY5MSAwMDAwMCBuDQowMDAwMTAwOTA2 IDAwMDAwIG4NCjAwMDAxMDExMjEgMDAwMDAgbg0KMDAwMDEwMTMzNyAwMDAwMCBuDQowMDAwMTAx NTU0IDAwMDAwIG4NCjAwMDAxMDE3NjggMDAwMDAgbg0KMDAwMDEwMTk4MiAwMDAwMCBuDQowMDAw MTAyMTk1IDAwMDAwIG4NCjAwMDAxMDI0MDggMDAwMDAgbg0KMDAwMDEwMjYyMSAwMDAwMCBuDQow MDAwMTAyODM0IDAwMDAwIG4NCjAwMDAxMDMwNDggMDAwMDAgbg0KMDAwMDEwMzI2MCAwMDAwMCBu DQowMDAwMTAzNDc1IDAwMDAwIG4NCjAwMDAxMDM2OTAgMDAwMDAgbg0KMDAwMDEwMzkwNyAwMDAw MCBuDQowMDAwMTA0MTIwIDAwMDAwIG4NCjAwMDAxMDQzMzMgMDAwMDAgbg0KMDAwMDEwNDU0OCAw MDAwMCBuDQowMDAwMTA0NzYyIDAwMDAwIG4NCjAwMDAxMDQ5NzQgMDAwMDAgbg0KMDAwMDEwNTE2 OCAwMDAwMCBuDQowMDAwMTA1MzUzIDAwMDAwIG4NCjAwMDAxMDU1MzggMDAwMDAgbg0KMDAwMDEw NTcyMyAwMDAwMCBuDQowMDAwMTA1OTA5IDAwMDAwIG4NCjAwMDAxMDcyMjkgMDAwMDAgbg0KMDAw MDAxMTg3OSAwMDAwMCBuDQowMDAwMDEyNTk1IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNTc3 DS9JbmZvIDIgMCBSIA0vUm9vdCA0IDAgUiANL1ByZXYgMTA3NTA5IA0vSURbPGM2MWQ3ZDJkOWYy ZGM5ZWFjYjIyODkzMWVmNGQ3ODBiPjxjNjFkN2QyZDlmMmRjOWVhY2IyMjg5MzFlZjRkNzgwYj5d DT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICANNCAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9Q YWdlcyAxIDAgUiANPj4gDWVuZG9iag01NzUgMCBvYmoNPDwgL1MgMzYgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCA1NzYgMCBSID4+IA1zdHJlYW0NCkiJzJM/aBNRHMd/7929NM1d06i5XCuK Vwdp0pJEBClF8OIgTpLWGttSmkND7eAQQaHDoe+dIBGKRHDoIHpDUfpPg4h2kPoCIh2KdnU70MHx FqFDEN9LCy6dHMQfHMeH7/f3/f5uOAB8BiB7HQDQzW+w30T33gkAPLz7iElBF/k5zE+jRhetKvQI BB0whHgc/iE81+bS3vHYo4TnZq2nQlH6NfiFA4UehR8d9jDajtNbiv9fAZw4T6qFpqfUK1T9bj8j 21ohA4cOU/UrRUO1LMt0himqvuOQ9EH9HLHOopruTyn5Y/w1CQdZpTu4i3dMpEby57y87lzFOz10 K0pzbOEAXFMTJmwRnkWPdT6DNw8WVFL/glwtGMULffZbEqaRm/RHcd0UaVaOVTTnAQ767OUoFdGa dRtzy14nxUHmxv0y5iZvRKxTqKL7ZQVMvkEag2xBhwkcpoQtPMlczZpSEil7Q9wme8riNmELc6yq QRvWJVS0YELCx456jrV0u4wDk38iYYHNa0ENB6lmigjF7aZTeNOiGxErK9JEz2Yv3YoUs+hGzJ5R 8j1U9rB53RYf17vysDMYwTXDWSJ2unkxVr3kPUkGL8hQmgkYww2DrhJnoDAZ277irRv85R6UvDeG s0KKcqdREjb/FZkbaE5L23sjWNu18cteO6CYYaVYQ4KzLKAwKmHVcGQ0mhQBIs1fI7PtnRJuQ1vh MtpZI+OZZkn2rMpSoYzHfLkjomd3z5GHrgibiK6PeYuGtUQu/AFR2s/u6DDttUzejETz7L4ODm6Z wQeyk0eunnDu6QKEgtwYH/Hmk85ifz1u7/sz/8X8FmAA7B8s+w1lbmRzdHJlYW0NZW5kb2JqDTU3 NiAwIG9iag02MzAgDWVuZG9iag01IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxIDAg UiANL1Jlc291cmNlcyA2IDAgUiANL0NvbnRlbnRzIFsgMTk2IDAgUiAyMDMgMCBSIDIwOSAwIFIg MjExIDAgUiAyMTMgMCBSIDIxOSAwIFIgMjIxIDAgUiAyMjMgMCBSIF0gDS9NZWRpYUJveCBbIDAg MCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5k b2JqDTYgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSAN L0ZvbnQgPDwgL0YyIDE5NyAwIFIgL0Y0IDIwNyAwIFIgL0Y2IDIxNSAwIFIgL1RUMiA4OSAwIFIg L1RUNCA4NyAwIFIgL1RUNiA4NSAwIFIgDS9UVDggOTEgMCBSIC9UVDEwIDk3IDAgUiAvVFQxMiA5 NSAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgMzk5IDAgUiAvSW0yIDQwMCAwIFIgL0ltMyA0MDEg MCBSIC9JbTQgNDAwIDAgUiAvSW01IDQwMiAwIFIgDS9JbTYgNDAzIDAgUiAvSW03IDQwNCAwIFIg L0ltOCA0MDUgMCBSIC9JbTkgNDA2IDAgUiAvSW0xMCA0MDcgMCBSIA0vSW0xMSA0MDggMCBSIC9J bTEyIDQwOSAwIFIgL0ltMTMgNDA5IDAgUiAvSW0xNCA0MTAgMCBSIC9JbTE1IDQxMSAwIFIgDS9J bTE2IDQxMiAwIFIgL0ltMTcgNDEzIDAgUiAvSW0xOCA0MTQgMCBSIC9JbTE5IDQxNSAwIFIgL0lt MjAgNDE2IDAgUiANL0ltMjEgNDE3IDAgUiAvSW0yMiA0MTcgMCBSIC9JbTIzIDQxOCAwIFIgL0lt MjQgNDE0IDAgUiAvSW0yNSA0MTkgMCBSIA0vSW0yNiA0MjAgMCBSIC9JbTI3IDQyMSAwIFIgL0lt MjggNDIyIDAgUiAvSW0yOSA0MjMgMCBSIC9JbTMwIDQyNCAwIFIgDS9JbTMxIDQyNSAwIFIgL0lt MzIgNDI2IDAgUiAvSW0zMyA0MjcgMCBSIC9JbTM0IDQyOCAwIFIgL0ltMzUgNDI5IDAgUiANL0lt MzYgNDMwIDAgUiAvSW0zNyA0MzEgMCBSIC9JbTM4IDQzMiAwIFIgL0ltMzkgNDMzIDAgUiAvSW00 MCA0MzQgMCBSIA0vSW00MSA0MzUgMCBSIC9JbTQyIDQzNiAwIFIgL0ltNDMgNDM3IDAgUiAvSW00 NCA0MzggMCBSIC9JbTQ1IDQzOSAwIFIgDS9JbTQ2IDQ0MCAwIFIgL0ltNDcgNDQxIDAgUiAvSW00 OCA0NDIgMCBSIC9JbTQ5IDQ0MyAwIFIgL0ltNTAgNDQ0IDAgUiANL0ltNTEgNDQ1IDAgUiAvSW01 MiA0NDYgMCBSIC9JbTUzIDQ0NyAwIFIgL0ltNTQgNDQ4IDAgUiAvSW01NSA0NDkgMCBSIA0vSW01 NiA0NTAgMCBSIC9JbTU3IDQ1MSAwIFIgL0ltNTggNDUyIDAgUiAvSW01OSA0NTMgMCBSIC9JbTYw IDQ1NCAwIFIgDS9JbTYxIDQ1NSAwIFIgL0ltNjIgNDU2IDAgUiAvSW02MyA0NTcgMCBSIC9JbTY0 IDQ1OCAwIFIgL0ltNjUgNDU5IDAgUiANL0ltNjYgNDYwIDAgUiAvSW02NyA0NjEgMCBSIC9JbTY4 IDQ2MiAwIFIgL0ltNjkgNDYzIDAgUiAvSW03MCA0NjQgMCBSIA0vSW03MSA0NjUgMCBSIC9JbTcy IDQ2NiAwIFIgL0ltNzMgNDY3IDAgUiAvSW03NCA0NjggMCBSIC9JbTc1IDQ2OSAwIFIgDS9JbTc2 IDQ3MCAwIFIgL0ltNzcgNDcxIDAgUiAvSW03OCA0NzIgMCBSIC9JbTc5IDQ3MyAwIFIgL0ltODAg NDc0IDAgUiANL0ltODEgNDc1IDAgUiAvSW04MiA0NzYgMCBSIC9JbTgzIDQ3NyAwIFIgL0ltODQg NDc4IDAgUiAvSW04NSA0NzkgMCBSIA0vSW04NiA0ODAgMCBSIC9JbTg3IDQ4MSAwIFIgL0ltODgg NDgyIDAgUiAvSW04OSA0ODMgMCBSIC9JbTkwIDQ4NCAwIFIgDS9JbTkxIDQ4NSAwIFIgL0ltOTIg NDg2IDAgUiAvSW05MyA0ODcgMCBSIC9JbTk0IDQ4OCAwIFIgL0ltOTUgNDg5IDAgUiANL0ltOTYg NDkwIDAgUiAvSW05NyA0OTEgMCBSIC9JbTk4IDQ5MiAwIFIgL0ltOTkgNDkzIDAgUiAvSW0xMDAg NDk0IDAgUiANL0ltMTAxIDQ5NSAwIFIgL0ltMTAyIDQ5NiAwIFIgL0ltMTAzIDQ5NyAwIFIgL0lt MTA0IDQ5OCAwIFIgL0ltMTA1IDQ5OSAwIFIgDS9JbTEwNiA1MDAgMCBSIC9JbTEwNyA1MDEgMCBS IC9JbTEwOCA1MDIgMCBSIC9JbTEwOSA1MDMgMCBSIC9JbTExMCA1MDQgMCBSIA0vSW0xMTEgNTA1 IDAgUiAvSW0xMTIgNTA2IDAgUiAvSW0xMTMgNTA3IDAgUiAvSW0xMTQgNTA4IDAgUiAvSW0xMTUg NTA5IDAgUiANL0ltMTE2IDUxMCAwIFIgL0ltMTE3IDUxMSAwIFIgL0ltMTE4IDUxMiAwIFIgL0lt MTE5IDUxMyAwIFIgL0ltMTIwIDUxNCAwIFIgDS9JbTEyMSA1MTUgMCBSIC9JbTEyMiA1MTYgMCBS IC9JbTEyMyA1MTcgMCBSIC9JbTEyNCA1MTggMCBSIC9JbTEyNSA1MTkgMCBSIA0vSW0xMjYgNTIw IDAgUiAvSW0xMjcgNTIxIDAgUiAvSW0xMjggNTIyIDAgUiAvSW0xMjkgNTIzIDAgUiAvSW0xMzAg NTI0IDAgUiANL0ltMTMxIDUyNSAwIFIgL0ltMTMyIDUyNiAwIFIgL0ltMTMzIDUyNyAwIFIgL0lt MTM0IDUyOCAwIFIgL0ltMTM1IDUyOSAwIFIgDS9JbTEzNiA1MzAgMCBSIC9JbTEzNyA1MzEgMCBS IC9JbTEzOCA1MzIgMCBSIC9JbTEzOSA1MzMgMCBSIC9JbTE0MCA1MzQgMCBSIA0vSW0xNDEgNTM1 IDAgUiAvSW0xNDIgNTM2IDAgUiAvSW0xNDMgNTM3IDAgUiAvSW0xNDQgNTM4IDAgUiAvSW0xNDUg NTM5IDAgUiANL0ltMTQ2IDU0MCAwIFIgL0ltMTQ3IDU0MSAwIFIgL0ltMTQ4IDU0MiAwIFIgL0lt MTQ5IDU0MiAwIFIgL0ltMTUwIDU0MyAwIFIgDS9JbTE1MSA1NDQgMCBSIC9JbTE1MiA1NDUgMCBS IC9JbTE1MyA1NDYgMCBSIC9JbTE1NCA1NDcgMCBSIC9JbTE1NSA1NDggMCBSIA0vSW0xNTYgNTQ5 IDAgUiAvSW0xNTcgNTUwIDAgUiAvSW0xNTggNTUxIDAgUiAvSW0xNTkgNTUyIDAgUiAvSW0xNjAg NTUzIDAgUiANL0ltMTYxIDU1NCAwIFIgL0ltMTYyIDU1NSAwIFIgL0ltMTYzIDU1NiAwIFIgL0lt MTY0IDU1NyAwIFIgL0ltMTY1IDU1OCAwIFIgDS9JbTE2NiA1NTkgMCBSIC9JbTE2NyA1NjAgMCBS IC9JbTE2OCA1NjEgMCBSIC9JbTE2OSA1NjIgMCBSIC9JbTE3MCA1NjMgMCBSIA0vSW0xNzEgNTY0 IDAgUiAvSW0xNzIgNTY1IDAgUiAvSW0xNzMgNTY2IDAgUiAvSW0xNzQgNTY3IDAgUiAvSW0xNzUg NTY4IDAgUiANL0ltMTc2IDU2OSAwIFIgL0ltMTc3IDU3MCAwIFIgL0ltMTc4IDU3MSAwIFIgL0lt MTc5IDU3MiAwIFIgL0ltMTgxIDU3MyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1NzQgMCBS ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDkyIDAgUiAvQ3M5IDkzIDAgUiAvQ3MxMCA5NCAwIFIg L0NzMTEgODMgMCBSIC9DczEyIDcyIDAgUiAvQ3MxMyA3MyAwIFIgDS9DczE0IDc0IDAgUiAvQ3Mx NSA3MSAwIFIgL0NzMTYgNjkgMCBSIC9DczE3IDcwIDAgUiAvQ3MxOCA3NSAwIFIgDS9DczE5IDgw IDAgUiAvQ3MyMCA4MSAwIFIgL0NzMjEgODIgMCBSIC9DczIyIDc5IDAgUiAvQ3MyMyA3NiAwIFIg DS9DczI0IDc3IDAgUiAvQ3MyNSA3OCAwIFIgL0NzMjYgOTkgMCBSIC9DczI3IDEyMCAwIFIgL0Nz MjggMTIxIDAgUiANL0NzMjkgMTIyIDAgUiAvQ3MzMCAxMTkgMCBSIC9DczMxIDExNiAwIFIgL0Nz MzIgMTE3IDAgUiAvQ3MzMyAxMTggMCBSIA0vQ3MzNCAxMjMgMCBSIC9DczM1IDEyOCAwIFIgL0Nz MzYgMTI5IDAgUiAvQ3MzNyAxMzAgMCBSIC9DczM4IDEyNyAwIFIgDS9DczM5IDEyNCAwIFIgL0Nz NDAgMTI1IDAgUiAvQ3M0MSAxMjYgMCBSIC9DczQyIDExNSAwIFIgL0NzNDMgMTA0IDAgUiANL0Nz NDQgMTA1IDAgUiAvQ3M0NSAxMDYgMCBSIC9DczQ2IDEwMyAwIFIgL0NzNDcgMTAwIDAgUiAvQ3M0 OCAxMDEgMCBSIA0vQ3M0OSAxMDIgMCBSIC9DczUwIDEwNyAwIFIgL0NzNTEgMTEyIDAgUiAvQ3M1 MiAxMTMgMCBSIC9DczUzIDExNCAwIFIgDS9DczU0IDExMSAwIFIgL0NzNTUgMTA4IDAgUiAvQ3M1 NiAxMDkgMCBSIC9DczU3IDExMCAwIFIgL0NzNTggNjggMCBSIA0vQ3M1OSAyNiAwIFIgL0NzNjAg MjcgMCBSIC9DczYxIDI4IDAgUiAvQ3M2MiAyNSAwIFIgL0NzNjMgMjIgMCBSIA0vQ3M2NCAyMyAw IFIgL0NzNjUgMjQgMCBSIC9DczY2IDI5IDAgUiAvQ3M2NyAzNCAwIFIgL0NzNjggMzUgMCBSIA0v Q3M2OSAzNiAwIFIgL0NzNzAgMzMgMCBSIC9DczcxIDMwIDAgUiAvQ3M3MiAzMSAwIFIgL0NzNzMg MzIgMCBSIA0vQ3M3NCAyMSAwIFIgL0NzNzUgMTAgMCBSIC9Dczc2IDExIDAgUiAvQ3M3NyAxMiAw IFIgL0NzNzggOSAwIFIgDS9Dczc5IDcgMCBSIC9DczgwIDggMCBSIC9DczgxIDEzIDAgUiAvQ3M4 MiAxOCAwIFIgL0NzODMgMTkgMCBSIC9Dczg0IDIwIDAgUiANL0NzODUgMTcgMCBSIC9Dczg2IDE0 IDAgUiAvQ3M4NyAxNSAwIFIgL0NzODggMTYgMCBSIC9Dczg5IDEzMSAwIFIgDS9DczkwIDU3IDAg UiAvQ3M5MSA1OCAwIFIgL0NzOTIgNTkgMCBSIC9DczkzIDU2IDAgUiAvQ3M5NCA1MyAwIFIgDS9D czk1IDU0IDAgUiAvQ3M5NiA1NSAwIFIgL0NzOTcgNjAgMCBSIC9Dczk4IDY1IDAgUiAvQ3M5OSA2 NiAwIFIgDS9DczEwMCA2NyAwIFIgL0NzMTAxIDY0IDAgUiAvQ3MxMDIgNjEgMCBSIC9DczEwMyA2 MiAwIFIgL0NzMTA0IDYzIDAgUiANL0NzMTA1IDUyIDAgUiAvQ3MxMDYgNDEgMCBSIC9DczEwNyA0 MiAwIFIgL0NzMTA4IDQzIDAgUiAvQ3MxMDkgNDAgMCBSIA0vQ3MxMTAgMzggMCBSIC9DczExMSAz OSAwIFIgL0NzMTEyIDQ0IDAgUiAvQ3MxMTMgNDkgMCBSIC9DczExNCA1MCAwIFIgDS9DczExNSA1 MSAwIFIgL0NzMTE2IDQ4IDAgUiAvQ3MxMTcgNDUgMCBSIC9DczExOCA0NiAwIFIgL0NzMTE5IDQ3 IDAgUiANL0NzMTIwIDM3IDAgUiAvQ3MxMjEgMTkzIDAgUiAvQ3MxMjIgMTkxIDAgUiAvQ3MxMjMg MTg1IDAgUiAvQ3MxMjQgMTgzIDAgUiANL0NzMTI1IDE4OSAwIFIgL0NzMTI2IDE5MCAwIFIgL0Nz MTI3IDE4NCAwIFIgL0NzMTI4IDE4MiAwIFIgL0NzMTI5IDE4NyAwIFIgDS9DczEzMCAxODggMCBS IC9DczEzMSAxOTIgMCBSIC9DczEzMiAxODYgMCBSIC9DczEzMyAxOTQgMCBSIC9DczEzNCAxMzMg MCBSIA0vQ3MxMzUgMTQ3IDAgUiAvQ3MxMzYgMTQ4IDAgUiAvQ3MxMzcgMTQ2IDAgUiAvQ3MxMzgg MTQ0IDAgUiAvQ3MxMzkgMTQ1IDAgUiANL0NzMTQwIDE0OSAwIFIgL0NzMTQxIDE1MyAwIFIgL0Nz MTQyIDE1NCAwIFIgL0NzMTQzIDE1NSAwIFIgL0NzMTQ0IDE1MiAwIFIgDS9DczE0NSAxNTAgMCBS IC9DczE0NiAxNTEgMCBSIC9DczE0NyAxNDMgMCBSIC9DczE0OCAxMzUgMCBSIC9DczE0OSAxMzYg MCBSIA0vQ3MxNTAgMTM0IDAgUiAvQ3MxNTEgMTMyIDAgUiAvQ3MxNTIgMTgxIDAgUiAvQ3MxNTMg MTM3IDAgUiAvQ3MxNTQgMTQxIDAgUiANL0NzMTU1IDE0MiAwIFIgL0NzMTU2IDE0MCAwIFIgL0Nz MTU3IDEzOCAwIFIgL0NzMTU4IDEzOSAwIFIgL0NzMTU5IDE1NiAwIFIgDS9DczE2MCAxNzIgMCBS IC9DczE2MSAxNzMgMCBSIC9DczE2MiAxNzEgMCBSIC9DczE2MyAxNjkgMCBSIC9DczE2NCAxNzAg MCBSIA0vQ3MxNjUgMTc0IDAgUiAvQ3MxNjYgMTc4IDAgUiAvQ3MxNjcgMTc5IDAgUiAvQ3MxNjgg MTgwIDAgUiAvQ3MxNjkgMTc3IDAgUiANL0NzMTcwIDE3NSAwIFIgL0NzMTcxIDE3NiAwIFIgL0Nz MTcyIDE2OCAwIFIgL0NzMTczIDE2MCAwIFIgL0NzMTc0IDE2MSAwIFIgDS9DczE3NSAxNTkgMCBS IC9DczE3NiAxNTcgMCBSIC9DczE3NyAxNTggMCBSIC9DczE3OCAxNjIgMCBSIC9DczE3OSAxNjYg MCBSIA0vQ3MxODAgMTY3IDAgUiAvQ3MxODEgMTY1IDAgUiAvQ3MxODIgMTYzIDAgUiAvQ3MxODMg MTY0IDAgUiA+PiANPj4gDWVuZG9iag03IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzA1 IDAgUiANXQ1lbmRvYmoNOCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMwNCAwIFIgDV0N ZW5kb2JqDTkgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzMDcgMCBSIA1dDWVuZG9iag0x MCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMyNSAwIFIgDV0NZW5kb2JqDTExIDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzIxIDAgUiANXQ1lbmRvYmoNMTIgMCBvYmoNWyANL0lu ZGV4ZWQgOTIgMCBSIDI1NSAzMTQgMCBSIA1dDWVuZG9iag0xMyAwIG9iag1bIA0vSW5kZXhlZCA5 MiAwIFIgMjU1IDMxMiAwIFIgDV0NZW5kb2JqDTE0IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMzQwIDAgUiANXQ1lbmRvYmoNMTUgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzNDQg MCBSIA1dDWVuZG9iag0xNiAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM0OSAwIFIgDV0N ZW5kb2JqDTE3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzQxIDAgUiANXQ1lbmRvYmoN MTggMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzMTEgMCBSIA1dDWVuZG9iag0xOSAwIG9i ag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMxMCAwIFIgDV0NZW5kb2JqDTIwIDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMzQyIDAgUiANXQ1lbmRvYmoNMjEgMCBvYmoNWyANL0luZGV4ZWQg OTIgMCBSIDI1NSAzMjAgMCBSIA1dDWVuZG9iag0yMiAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIg MjU1IDM5NSAwIFIgDV0NZW5kb2JqDTIzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzk0 IDAgUiANXQ1lbmRvYmoNMjQgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzNzggMCBSIA1d DWVuZG9iag0yNSAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM5OCAwIFIgDV0NZW5kb2Jq DTI2IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzg5IDAgUiANXQ1lbmRvYmoNMjcgMCBv YmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzODggMCBSIA1dDWVuZG9iag0yOCAwIG9iag1bIA0v SW5kZXhlZCA5MiAwIFIgMjU1IDM5NiAwIFIgDV0NZW5kb2JqDTI5IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMzc3IDAgUiANXQ1lbmRvYmoNMzAgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBS IDI1NSAzNTAgMCBSIA1dDWVuZG9iag0zMSAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMx OSAwIFIgDV0NZW5kb2JqDTMyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzE1IDAgUiAN XQ1lbmRvYmoNMzMgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzODIgMCBSIA1dDWVuZG9i ag0zNCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM3NiAwIFIgDV0NZW5kb2JqDTM1IDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzg0IDAgUiANXQ1lbmRvYmoNMzYgMCBvYmoNWyAN L0luZGV4ZWQgOTIgMCBSIDI1NSAzODMgMCBSIA1dDWVuZG9iag0zNyAwIG9iag1bIA0vSW5kZXhl ZCA5MiAwIFIgMjU1IDI3MiAwIFIgDV0NZW5kb2JqDTM4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMjQ1IDAgUiANXQ1lbmRvYmoNMzkgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAy NTYgMCBSIA1dDWVuZG9iag00MCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM2NSAwIFIg DV0NZW5kb2JqDTQxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzU3IDAgUiANXQ1lbmRv YmoNNDIgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzNTMgMCBSIA1dDWVuZG9iag00MyAw IG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM3MiAwIFIgDV0NZW5kb2JqDTQ0IDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMjI4IDAgUiANXQ1lbmRvYmoNNDUgMCBvYmoNWyANL0luZGV4 ZWQgOTIgMCBSIDI1NSAyNjcgMCBSIA1dDWVuZG9iag00NiAwIG9iag1bIA0vSW5kZXhlZCA5MiAw IFIgMjU1IDI2NCAwIFIgDV0NZW5kb2JqDTQ3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg Mjc4IDAgUiANXQ1lbmRvYmoNNDggMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzMDAgMCBS IA1dDWVuZG9iag00OSAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDIzOCAwIFIgDV0NZW5k b2JqDTUwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjg1IDAgUiANXQ1lbmRvYmoNNTEg MCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAyODMgMCBSIA1dDWVuZG9iag01MiAwIG9iag1b IA0vSW5kZXhlZCA5MiAwIFIgMjU1IDM5MiAwIFIgDV0NZW5kb2JqDTUzIDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMzM3IDAgUiANXQ1lbmRvYmoNNTQgMCBvYmoNWyANL0luZGV4ZWQgOTIg MCBSIDI1NSAzMzUgMCBSIA1dDWVuZG9iag01NSAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1 IDMzNCAwIFIgDV0NZW5kb2JqDTU2IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzMyIDAg UiANXQ1lbmRvYmoNNTcgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzMzggMCBSIA1dDWVu ZG9iag01OCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMzMSAwIFIgDV0NZW5kb2JqDTU5 IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzI3IDAgUiANXQ1lbmRvYmoNNjAgMCBvYmoN WyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzMjggMCBSIA1dDWVuZG9iag02MSAwIG9iag1bIA0vSW5k ZXhlZCA5MiAwIFIgMjU1IDMxNyAwIFIgDV0NZW5kb2JqDTYyIDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMzg1IDAgUiANXQ1lbmRvYmoNNjMgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1 NSAzODYgMCBSIA1dDWVuZG9iag02NCAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMyMiAw IFIgDV0NZW5kb2JqDTY1IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzQ3IDAgUiANXQ1l bmRvYmoNNjYgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAzNDMgMCBSIA1dDWVuZG9iag02 NyAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDMwOCAwIFIgDV0NZW5kb2JqDTY4IDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzkwIDAgUiANXQ1lbmRvYmoNNjkgMCBvYmoNWyANL0lu ZGV4ZWQgOTIgMCBSIDI1NSAyOTYgMCBSIA1dDWVuZG9iag03MCAwIG9iag1bIA0vSW5kZXhlZCA5 MiAwIFIgMjU1IDMwMSAwIFIgDV0NZW5kb2JqDTcxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMjkzIDAgUiANXQ1lbmRvYmoNNzIgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAyNjgg MCBSIA1dDWVuZG9iag03MyAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDI4MSAwIFIgDV0N ZW5kb2JqDTc0IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjk1IDAgUiANXQ1lbmRvYmoN NzUgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAyOTcgMCBSIA1dDWVuZG9iag03NiAwIG9i ag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDI5MCAwIFIgDV0NZW5kb2JqDTc3IDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMjg3IDAgUiANXQ1lbmRvYmoNNzggMCBvYmoNWyANL0luZGV4ZWQg OTIgMCBSIDI1NSAyMzQgMCBSIA1dDWVuZG9iag03OSAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIg MjU1IDI4OSAwIFIgDV0NZW5kb2JqDTgwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjkx IDAgUiANXQ1lbmRvYmoNODEgMCBvYmoNWyANL0luZGV4ZWQgOTIgMCBSIDI1NSAyNjEgMCBSIA1d DWVuZG9iag04MiAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDI4MiAwIFIgDV0NZW5kb2Jq DTgzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjY5IDAgUiANXQ1lbmRvYmoNODQgMCBv YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCAxMDA1IA0vQ2FwSGVpZ2h0IDAg DS9EZXNjZW50IC0yMjAgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTE2OSAtMzA3IDExNTIgMTA2 MCBdIA0vRm9udE5hbWUgL0NlbnR1cnlHb3RoaWMgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCAN Pj4gDWVuZG9iag04NSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSAN L0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDExNyANL1dpZHRocyBbIDI3NyAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDc0MCAw IDgxMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1OTIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg DTAgMCAwIDAgNjgzIDAgNjQ3IDY4NSA2NTAgMzE0IDAgMCAwIDAgMCAyMDAgOTM4IDYxMCA2NTUg NjgyIDAgMzAxIA0zODggMzM5IDYwOCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jh c2VGb250IC9DZW50dXJ5R290aGljIA0vRm9udERlc2NyaXB0b3IgODQgMCBSIA0+PiANZW5kb2Jq DTg2IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMTAwNSANL0NhcEhl aWdodCAwIA0vRGVzY2VudCAtMjA5IA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC03MyAtMjA4IDE3 MDcgMTAwMCBdIA0vRm9udE5hbWUgL1ZlcmRhbmEtQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViAxMzMgDT4+IA1lbmRvYmoNODcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1 ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciA4NiANL1dpZHRocyBbIDI1MCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1ODcgNjAwIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0w IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU5MSAwIDAgMCAwIDAgNjIwIF0g DS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FsZ2VyaWFuIA0vRm9udERl c2NyaXB0b3IgOTAgMCBSIA0+PiANZW5kb2JqDTg4IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2Ny aXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFncyAz NCANL0ZvbnRCQm94IFsgLTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL1RpbWVzTmV3 Um9tYW5QU01UIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDT4+IA1lbmRvYmoNODkgMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0 Q2hhciAxNTAgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDc3OCAwIDMzMyAzMzMgMCAwIDI1MCAz MzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDUwMCAwIDUwMCAyNzggMCAw IDAgMCAwIDAgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiANMzMzIDM4OSA3MjIgNjEx IDg4OSA3MjIgNzIyIDU1NiA3MjIgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgMCA3MjIgDTYxMSAw IDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3 OCANNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0 NCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAwIDAg MCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXNOZXdS b21hblBTTVQgDS9Gb250RGVzY3JpcHRvciA4OCAwIFIgDT4+IA1lbmRvYmoNOTAgMCBvYmoNPDwg DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4ODggDS9DYXBIZWlnaHQgMCANL0Rlc2Nl bnQgLTIyMyANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtMTg4IC0yNTkgMTAxNyA4ODggXSANL0Zv bnROYW1lIC9BbGdlcmlhbiANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2JqDTkx IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMy IA0vTGFzdENoYXIgMTE2IA0vV2lkdGhzIFsgMzQyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNzExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAg NTQ2IDAgMCAwIDAgMCAwIDczMyAwIDAgMCAwIDAgNzY0IDExMjggMCAwIDAgDTAgMCAwIDAgMCAw IDY2OCAwIDU4OCA2OTkgNjY0IDAgMCA3MTIgMzQyIDAgNjcxIDM0MiAwIDcxMiA2ODcgNjk5IA0w IDQ5NyA1OTMgNDU2IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL1Zl cmRhbmEtQm9sZCANL0ZvbnREZXNjcmlwdG9yIDg2IDAgUiANPj4gDWVuZG9iag05MiAwIG9iag1b IA0vQ2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIy MjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4z NTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag05 MyAwIG9iag1bIA0vSW5kZXhlZCA5MiAwIFIgMjU1IDI2NSAwIFIgDV0NZW5kb2JqDTk0IDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjYyIDAgUiANXQ1lbmRvYmoNOTUgMCBvYmoNPDwgDS9U eXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAx MjIgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDMzMyAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzg5IDAgMCAw IDAgMCAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCA1MDAgNTAwIDQ0NCA1 MDAgNDQ0IDAgNTAwIDU1NiAyNzggMCAwIDI3OCAwIDU1NiA1MDAgDTUwMCAwIDM4OSAzODkgMjc4 IDAgMCA2NjcgMCA0NDQgMzg5IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZv bnQgL1RpbWVzTmV3Um9tYW5QUy1Cb2xkSXRhbGljTVQgDS9Gb250RGVzY3JpcHRvciA5OCAwIFIg DT4+IA1lbmRvYmoNOTYgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4 OTEgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxNiANL0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAt NTU4IC0zMDcgMjAzNCAxMDI2IF0gDS9Gb250TmFtZSAvVGltZXNOZXdSb21hblBTLUJvbGRNVCAN L0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNOTcgMCBvYmoNPDwgDS9UeXBl IC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNTAg DS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMCAyNTAgMjc4IDUw MCA1MDAgNTAwIDUwMCAwIDAgMCANMCAwIDAgMzMzIDAgMCAwIDAgMCA5MzAgNzIyIDAgNzIyIDcy MiA2NjcgMCA3NzggMCAzODkgMCA3NzggMCA5NDQgDTAgNzc4IDYxMSAwIDcyMiA1NTYgNjY3IDcy MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IA00NDQgMzMzIDUwMCA1NTYg Mjc4IDMzMyA1NTYgMjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1NiANNTAwIDAg MCA1MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IA0wIDAgMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGlt ZXNOZXdSb21hblBTLUJvbGRNVCANL0ZvbnREZXNjcmlwdG9yIDk2IDAgUiANPj4gDWVuZG9iag05 OCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdo dCAwIA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC01NDcgLTMwNyAxMjA2 IDEwMzIgXSANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuUFMtQm9sZEl0YWxpY01UIA0vSXRhbGlj QW5nbGUgLTE1IA0vU3RlbVYgMTMzIA0+PiANZW5kb2JqDTk5IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMjMzIDAgUiANXQ1lbmRvYmoNMTAwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMzYzIDAgUiANXQ1lbmRvYmoNMTAxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzY4 IDAgUiANXQ1lbmRvYmoNMTAyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzczIDAgUiAN XQ1lbmRvYmoNMTAzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzAyIDAgUiANXQ1lbmRv YmoNMTA0IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjUwIDAgUiANXQ1lbmRvYmoNMTA1 IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQ3IDAgUiANXQ1lbmRvYmoNMTA2IDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzY2IDAgUiANXQ1lbmRvYmoNMTA3IDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMzY5IDAgUiANXQ1lbmRvYmoNMTA4IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMzYwIDAgUiANXQ1lbmRvYmoNMTA5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMzU5IDAgUiANXQ1lbmRvYmoNMTEwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg MzU4IDAgUiANXQ1lbmRvYmoNMTExIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzU2IDAg UiANXQ1lbmRvYmoNMTEyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzYyIDAgUiANXQ1l bmRvYmoNMTEzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzU1IDAgUiANXQ1lbmRvYmoN MTE0IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzUxIDAgUiANXQ1lbmRvYmoNMTE1IDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQ2IDAgUiANXQ1lbmRvYmoNMTE2IDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMjI0IDAgUiANXQ1lbmRvYmoNMTE3IDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMjI5IDAgUiANXQ1lbmRvYmoNMTE4IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMjI3IDAgUiANXQ1lbmRvYmoNMTE5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMjI2IDAgUiANXQ1lbmRvYmoNMTIwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjMx IDAgUiANXQ1lbmRvYmoNMTIxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQwIDAgUiAN XQ1lbmRvYmoNMTIyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjM3IDAgUiANXQ1lbmRv YmoNMTIzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjYwIDAgUiANXQ1lbmRvYmoNMTI0 IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjU3IDAgUiANXQ1lbmRvYmoNMTI1IDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQ0IDAgUiANXQ1lbmRvYmoNMTI2IDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMjQzIDAgUiANXQ1lbmRvYmoNMTI3IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMjU4IDAgUiANXQ1lbmRvYmoNMTI4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMjU1IDAgUiANXQ1lbmRvYmoNMTI5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg MjUyIDAgUiANXQ1lbmRvYmoNMTMwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjU5IDAg UiANXQ1lbmRvYmoNMTMxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzQ1IDAgUiANXQ1l bmRvYmoNMTMyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzk3IDAgUiANXQ1lbmRvYmoN MTMzIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzMzIDAgUiANXQ1lbmRvYmoNMTM0IDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzkzIDAgUiANXQ1lbmRvYmoNMTM1IDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMzgwIDAgUiANXQ1lbmRvYmoNMTM2IDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMzc5IDAgUiANXQ1lbmRvYmoNMTM3IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMzc0IDAgUiANXQ1lbmRvYmoNMTM4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMzcxIDAgUiANXQ1lbmRvYmoNMTM5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzY0 IDAgUiANXQ1lbmRvYmoNMTQwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzU0IDAgUiAN XQ1lbmRvYmoNMTQxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzYxIDAgUiANXQ1lbmRv YmoNMTQyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzUyIDAgUiANXQ1lbmRvYmoNMTQz IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzgxIDAgUiANXQ1lbmRvYmoNMTQ0IDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzQ4IDAgUiANXQ1lbmRvYmoNMTQ1IDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMzM5IDAgUiANXQ1lbmRvYmoNMTQ2IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMzQ2IDAgUiANXQ1lbmRvYmoNMTQ3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMzM2IDAgUiANXQ1lbmRvYmoNMTQ4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg MzI5IDAgUiANXQ1lbmRvYmoNMTQ5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzI2IDAg UiANXQ1lbmRvYmoNMTUwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzE2IDAgUiANXQ1l bmRvYmoNMTUxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzE4IDAgUiANXQ1lbmRvYmoN MTUyIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzIzIDAgUiANXQ1lbmRvYmoNMTUzIDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzEzIDAgUiANXQ1lbmRvYmoNMTU0IDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMzAzIDAgUiANXQ1lbmRvYmoNMTU1IDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMzA2IDAgUiANXQ1lbmRvYmoNMTU2IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMzY3IDAgUiANXQ1lbmRvYmoNMTU3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMjcwIDAgUiANXQ1lbmRvYmoNMTU4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjYz IDAgUiANXQ1lbmRvYmoNMTU5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjk0IDAgUiAN XQ1lbmRvYmoNMTYwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjk5IDAgUiANXQ1lbmRv YmoNMTYxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjkyIDAgUiANXQ1lbmRvYmoNMTYy IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjcxIDAgUiANXQ1lbmRvYmoNMTYzIDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjczIDAgUiANXQ1lbmRvYmoNMTY0IDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMjc1IDAgUiANXQ1lbmRvYmoNMTY1IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMjc2IDAgUiANXQ1lbmRvYmoNMTY2IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMjc3IDAgUiANXQ1lbmRvYmoNMTY3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg MjgwIDAgUiANXQ1lbmRvYmoNMTY4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjg0IDAg UiANXQ1lbmRvYmoNMTY5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQxIDAgUiANXQ1l bmRvYmoNMTcwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjUzIDAgUiANXQ1lbmRvYmoN MTcxIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjUxIDAgUiANXQ1lbmRvYmoNMTcyIDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjQ4IDAgUiANXQ1lbmRvYmoNMTczIDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMjQyIDAgUiANXQ1lbmRvYmoNMTc0IDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMjI1IDAgUiANXQ1lbmRvYmoNMTc1IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMjg4IDAgUiANXQ1lbmRvYmoNMTc2IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAy NTUgMjg2IDAgUiANXQ1lbmRvYmoNMTc3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjM1 IDAgUiANXQ1lbmRvYmoNMTc4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjMwIDAgUiAN XQ1lbmRvYmoNMTc5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjM2IDAgUiANXQ1lbmRv YmoNMTgwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjM5IDAgUiANXQ1lbmRvYmoNMTgx IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzg3IDAgUiANXQ1lbmRvYmoNMTgyIDAgb2Jq DVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzcwIDAgUiANXQ1lbmRvYmoNMTgzIDAgb2JqDVsgDS9J bmRleGVkIDkyIDAgUiAyNTUgMjk4IDAgUiANXQ1lbmRvYmoNMTg0IDAgb2JqDVsgDS9JbmRleGVk IDkyIDAgUiAyNTUgMjQ5IDAgUiANXQ1lbmRvYmoNMTg1IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAg UiAyNTUgMjY2IDAgUiANXQ1lbmRvYmoNMTg2IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUg MzA5IDAgUiANXQ1lbmRvYmoNMTg3IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzkxIDAg UiANXQ1lbmRvYmoNMTg4IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMzc1IDAgUiANXQ1l bmRvYmoNMTg5IDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjMyIDAgUiANXQ1lbmRvYmoN MTkwIDAgb2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjU0IDAgUiANXQ1lbmRvYmoNMTkxIDAg b2JqDVsgDS9JbmRleGVkIDkyIDAgUiAyNTUgMjc5IDAgUiANXQ1lbmRvYmoNMTkyIDAgb2JqDVsg DS9JbmRleGVkIDkyIDAgUiAyNTUgMzI0IDAgUiANXQ1lbmRvYmoNMTkzIDAgb2JqDVsgDS9JbmRl eGVkIDkyIDAgUiAyNTUgMjc0IDAgUiANXQ1lbmRvYmoNMTk0IDAgb2JqDVsgDS9JbmRleGVkIDky IDAgUiAyNTUgMzMwIDAgUiANXQ1lbmRvYmoNMTk1IDAgb2JqDTE1NDggDWVuZG9iag0xOTYgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxOTUgMCBSID4+IA1zdHJlYW0NCkiJ 3FdLb9tGEL7rV+yRC1jMvrgkc3Mco3CNokatOoc6B0VSLMaKaEh0A/eH9Pf2m5mlJFuWTzoUSRBx H7Mz33zz2M2H0eDdaOSUVaOvgzqvozL4ywPvcu9MVGXpclcZr0bfB+/O1oWarFnIqPVk8O6Xa6vu 1gOjRhP6+THIlB59I6VBlPoqN5WtIG5tXsayVs5i6HvlPo9GlJu8DLXa/YUBUTc0uTGuUvS1NqjR R1pywZdkN1NbIV+orYyRXdrcICYpV1mSYpmjGXgNvcmLYEvWelxj/w9vrg4Ykw1ajx44n4vWldqT POjO0Sy87k/0OL715+aQtZs9azcHrN287c/RLBzwJ4b482Sbq5NWMeYOcef2uHMHuHNvu3M0Cwei E9xudMwha2bPmjlgzbztz9EsHKqen9Ybe8iW3bNlD9iyb3tzLAu4aeNr17ery9xGvmJDHkJ/xcIc lyWqy8WCLuy/UKH050xXeZGNNQzV2WKhtHMVRl+1z0PW6ojxql+80iG3vezDbLXWRe6zfne8nPbD U+1tHrPlUhQ8wobLlnpoMZnMvs+Wnf48+nWAp0FVFDvoQ10Dqimeo99/ZFTiui34KD7WlqgzcjvU een6g9iTKBuwx43HMnvPObOereJwEfNY7XDm+Uw3pzM7xgrzijFSUQnHsBYSxxfLbrZajkFclXXa gNOmTdOFupLB5H7WqRsMi6whjkI21SGbaWK5VZ/a1f163j4wY/DdGnHeQTBIqrxk6Hy0zUCrGjVw JfLPqjICL2DDa6eGfH41G4BHgyjFzT5vPNuu8mA226Hw8HpXoFcfXF5VqvAF3n5q6JCIsv9hNKiF 7u3zUgZMnYA+8Ax1eH7ELcUFh2TYR4c49kbpiMRG1gUk3YMuMV41OmYL/FP/gq7fQGvIS0ndMnvS RQ2yT7Sj9HUI14m6fGqXfPLu2yN/0+5lu9K2yCkeVBFjtYlDej4bYsKZUHEkCGLcQowC8Roai+yB LRTZWtfQ3xKWkK00AulZe5lN1VhEpgpmSeouLcAdSP3Da7Op+vL0Mh1QS7GK5V5CvE8l06PNvS/7 DtOXU68DJBZpj9GHPp1N8uPyAoyeXavbjGlxADYbK1pcgnsPzyKynMu86R67mWq/qrP2u3ZU/+nz uGwm4w5VoK4nzWw5mdGhW73H6xDqXVnal/QGu6GXappgXYCiEhAQ7UnbojHxfCxAOq6xhn9bWWLJ H2hKIa2LzJyWb9NkNpmzWzGJTMYL/sLCcM36KZwxk3FSLIZv9V5w0J1sKIRage56boMTJ97rYQE+ 1fmff5xeX1zpmjroibo4Pz9XZ7/rYcQm8hjZ4pBPlMZp8UxsJ9HrK11Quqo1MFEeg+ROVDegOgFL HFNxBede7yIV3VlUkDzoCzJW4WXhvijtiP859iXLN9ymLboyXT2jOTBTWs+AMVMW1wYmltFJE4iq KNF0WB2c3DZZ59wWp3TmHkB06DsvADDDybylO3DTlRGqKqPWTF/ko7bEaZrjHrRU7lfA6UGirE74 914kRUGnLSUFi3k80rmxNLw43ZVre5FPuqZGj+A4bK6SMtQAFueymKA8yAwZqW0JJNTibiDn0LJE woiEkZmVGUrph7YMA9f5FzGv5vJdoLEsle+P86dHdiqnktlVs1BDap3i+pN2QVqlapaJnEtJMN5q l3ei7dsjeimj7F0Uy6LmhBO3B5j8bYTXOZbjhmthRHUJuJpIDsvmQ9P1cZpw0uBKstvut/Pc2dzE TfeE5gkf0JL4yBCXfai9p/7i8WfTX9JJD4VydMxPJDxfUEw8bDR3vu1yxy7X7DKaQODrQt5V9Esh pLVT7SiI+UcWVlFbuuxLOpTGw2dympaScC0CvkB3IZkTzTeaWtDtlCxPdmx2OxintKkakWTAHEEP baLViN17mTULatnb4518xC+15tuxfexE3XzXUdnrwDFSltBdy24rih/J9CJPyEekQJIgGUICsOM7 NCZIopheQTxVjSwkN6Zy/G/Z5NOMOeIeFYkuIVAPu9ERJbtx7Dm6S+JQ4/jRyjLzZdvTnQSQup// E2AAv/UQMQ1lbmRzdHJlYW0NZW5kb2JqDTE5NyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0 eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxIA0vTGFzdENoYXIgMiANL1dpZHRocyBbIDU3MyAxMDAw IF0gDS9FbmNvZGluZyAyMDAgMCBSIA0vQmFzZUZvbnQgL0FFSU9PTitUVDQ3NW8wMCANL0ZvbnRE ZXNjcmlwdG9yIDIwMSAwIFIgDS9Ub1VuaWNvZGUgMTk4IDAgUiANPj4gDWVuZG9iag0xOTggMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTAgPj4gDXN0cmVhbQ0KSIlUkLsO wjAMRfd+hUcQQ9IKxFJ1gaUDD1FgD4lbRaJO5KYDf09SXmKIJfvm6F5bbOptTTaAOLLTDQZoLRnG wY2sEW7YWYK8AGN1eHdT1b3yICLcPIaAfU2tg7LMxCmKQ+AHzM7n5XrlpFzIOYgDG2RLXRznl2sc NKP3d+yRAkioKjDYZmKzU36vegTxgyclf5s6g4NXGllRh1DKonoVJPOvfYhb+2p/X0spC1llkfho CU7bfN31yByDTStPmVIGS/i9inc+WaaXPQUYAFfnaIEKZW5kc3RyZWFtDWVuZG9iag0xOTkgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjMgL1N1YnR5cGUgL1R5cGUxQyA+ PiANc3RyZWFtDQpIiWJkYGFkYGRkFHB09fT399MOCTExN803MACJaf6Q4RHr7v7VJsMyjVVuAYNH U+P/7m44g4f9Bf9bwe7vskIMTIyMnIJFGfm5SaXFJnAjgICRsZ2BmZGRmV2xm0+Gg4EPaNJ3i5/N oj+sQfAPFP6wZuUDCDAAx/4o3QplbmRzdHJlYW0NZW5kb2JqDTIwMCAwIG9iag08PCANL1R5cGUg L0VuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9yaG9tYnVzNCAvc3BhY2UgXSANPj4gDWVuZG9i ag0yMDEgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCAwIA0vQ2FwSGVp Z2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA0IA0vRm9udEJCb3ggWyAwIDAgNDkzIDU3MyBdIA0v Rm9udE5hbWUgL0FFSU9PTitUVDQ3NW8wMCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hh clNldCAoL3Job21idXM0L3NwYWNlKQ0vRm9udEZpbGUzIDE5OSAwIFIgDT4+IA1lbmRvYmoNMjAy IDAgb2JqDTE3NjggDWVuZG9iag0yMDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCAyMDIgMCBSID4+IA1zdHJlYW0NCkiJdFdLc6NGEL77V8wRqiQCAwMit63NZVOVqq2yKjlk 9yABtogxEAFO/O/T3V+PhOSND2YeX78f0zL7Xx9cEZXWxGb/y8M2juI43Zl99UD7fx7+DA5duE3K KA1M+J2wW4C3SZTSH5MwhUuFIoptVihZWEZJUBNtlAVvYWL1pK/k07yGNuUvDgGbp7CIdoFRZG3a vh9WtHM79AppwySPHBHSpRFIGzK/GgwHM59D50WCOyhVbosd/oN06A2EgQXTmxEcqpfr+Sxg0+vu n9DGxGJguKDAckO6e2q+mlvYvXT+LHMEmk9gY76E7uKFq3w9WQuOzFc6TKJSjQPbj/oRKKWg/R4W GZt74xxxmgL+CEvH+kPSnRUnnArBuPaiOR0kG5yNHKdB7BMhLzQR0jxHIpBLU7EhiSlg5iiL3O/7 MCZVRJOlp6BScgV/Lw0HqbxknAr5v5xLkgyiyOUQNrIdCGZby//+WYyGz0ylfhCLNCP0Q1kgUOGw SH7V5ilMdqTh4C/MuPKkOqbTSCpW6JXnDxP0Rof6CrjRVOXDqn4V5A9pd0OssVVVcAXCDkogipEy 9hnFzADD/W1xXmqQRfg6BIMBdeizeZVM76F13DtuKlGsNeO1Qitlrb1B/m9CwkAKUnrtEV4jFLXP w8yt8zDxueG0H02kQka8KvaJJVlvxLoI2rlt5HzaCKBkHR1d1HJ9zUBhf5+BmuxJUmiyH5cpZPat tAcXYIf/4gO0LPYBJYC1JI9bGl8vkiwIgGPTCKQk49iJa+AuJ/5wgbTAK71iQQgmplGJW3YxpC0A APwMXQDjXk0p8YUdVIBIK9PGwMXJJkzYORJp4WcoEROSziFX2S8AQ6vTMBrqtYRxHE0+giUnFbp0 yknEm1mNwgZavqy1VJXGTiKTxbcvV6ZxT2yhPeFQNfRYbHOiYZO4aEhIQZl00m1DNiTSZpsXVE5G lbNTLRjRgV4//lSp7pg/h5a6G/Lmp/0+iQ2p9PRA0CRfKVo6VTS1OyjKRchlzKVYkJMkC+dwWxJT ChpnY4ND8zncFqpITg6tPRFV/9bCST5t492HpC21NHJ2Fkt+fCf6TFpgymaPZAJ6G1nCMRMjS9os cvPKNU02fgtC/n4N2WOfCZcEjwIwNo5BnXwLvSesOiKO7LVM09wrk2u8OBgloiPvdEWWZ8FJw66X bdfxQ8I35oRvV/NMwJXcg9I8Ntojl06puU3F3I0svg7IrW4L8wnsR5yf225VAIyIk4gPyHZ6NjNp VaIDlByUrG4PUKl755ImdNu/gUE7K4V2aAUMi5kH1W0G8Qu2Ch9xeJ6Jlced2sk7y0tWoumkzNQQ c8TWqzMtR0kdefskh+dZXsj4OuZJnO5SJ5XUkfyNteG946WmtgJdxAuWvA5dcn5jHFv6Cbd13fIU d5B87siap0vBC5UoVAS4Z6Q5N7J+BjtckIt7Pbi7pxygzRSycbOsz1deG3MaZsA7ufPEwGN9fltL AhnWNJC++eFF9gu+3vJLVhaBp+hphKi0dgt5VcRMQ3bNp1tq7I4GurSqZ4Rw7KI4o6qJjSyywkU2 oxDkMc1QeUwBeuVxXWd2CuH+L6p+R9Vf5hzEJM8sBxE3pXAqTWqj1BIXV5D8DFwQXOeHOF755iTO 4bJ2HK1C3jWZfnjZVPyicjdqzGHB2czOKriSC7wQhbzZ21gG7wRzwZnw0wsoQ06UGjguCD40ilSe R3xeeVLkcjKHXvFNRzqcQaRnLXubeqlR+EEE6OVytaE6t+ONyhwT51Wl4mi8kBb3PVT77XFLfSC+ M63Gpbacmys9/Or9N08fRG8U0994zevV/CvMq6ZRN7WKe4bQBLt4rcJ4o4InoPyiwisu7r7BwlHP frSS3NMekPkB3/L8zbnRUOd3MjFaStd9uLO0kPnU8u8w6hAZyRnXMMNPl5MJNZNueHmusvuek6WX nqPP1Xhu5K3hQtkFWPccaZlRd/o7EWW180XJx2ZZk9Qg2ZjhDKoObxc2VOvjAPgM/FlvZsC4fIWp yhnAjtueV41mn5vutwuOwzLT40j5aK38KuP//TKvDfqR4qpgN8wKrak84DV6sdPLLzBxU5pphOTH mEToUGHYSeD5WH5e0tNAjbbjmYLa6Hh73kxNryczEIcwlp4qmxYfz8xDNzwLFVwmcu2PKxWy6L7W 7x3sWbLO3N1OlSebpg9iP/ZGl2pvdHlx6WriluLaICN0yJx6mbN23SGli6JNrqa3MipzNE1eXPpm RsrE675pvedTC8/vqW5jNEyuyLGtJqPrp3Cb8ajW9jNWDWcQB4CE+M00X1BVt9TNxhwXf3QAH8Wb Xvn6667VOa31/ClpsFLkz+H3/wQYAPVSEvgNZW5kc3RyZWFtDWVuZG9iag0yMDQgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA5MCAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJl YW0NCkiJYmRgYWRgZGQUcHT1DHDy0A4JMTFzyjcwAImp/pDhEesGAla5BQzTU5P/d3fDGTzs9/kf CXa/FWJgYmRk4XE3MYfrZGBgbAeJMrN1831/yQcQYACzuxmHCmVuZHN0cmVhbQ1lbmRvYmoNMjA1 IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAw IA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgMCAwIDAgMCBdIA0vRm9udE5hbWUg L0FFSVBCSCtUVDQ2Qm8wMCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoL0c0 NykNL0ZvbnRGaWxlMyAyMDQgMCBSIA0+PiANZW5kb2JqDTIwNiAwIG9iag08PCANL1R5cGUgL0Vu Y29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9HNDcgXSANPj4gDWVuZG9iag0yMDcgMCBvYmoNPDwg DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMSANL0xhc3RDaGFyIDEg DS9XaWR0aHMgWyAzMzMgXSANL0VuY29kaW5nIDIwNiAwIFIgDS9CYXNlRm9udCAvQUVJUEJIK1RU NDZCbzAwIA0vRm9udERlc2NyaXB0b3IgMjA1IDAgUiANPj4gDWVuZG9iag0yMDggMCBvYmoNMTUz MSANZW5kb2JqDTIwOSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIwOCAw IFIgPj4gDXN0cmVhbQ0KSImsV81y2zYQnvbop8ARmIloAiT401vTuK07TpqJNblkelAkymJNixqS sps8Rp+4u/uBlJ2RO3VHFwLYH2B38e0uqOa/nZ3P505ZNV+fuTjyWZaoWM3fnNFnyZ+HM63M/M+z 85+DVEn8WJUqcVHi4kz5JI1cHCdqfncWR3EcW9bU330vWtPmFtvOWMR52ZxmvuATPumPxie6NrM0 yvXKzMrI6crYKNEtFqofwOyqxZ2xPpqktxC4UUHy3qSs3KnLwAmK2K4LxCpQlfmDQzD6NrNqZiOb ZrmEYPIGcXjGJRZLSxYT52wGl96ZPLJ0bEHHDA+GgpvqtiPrMn1rrKVBLYRJ/tqo0FjssBjqe8hA X4VVbRwrgNiqJcZVvb15suN2pQacFNbYtCeLUr0LRgyn8j2x423GDq5fdF3bnTdt36uuMllU6r5u asy2AzlTkjW1iWm5ApV9kVF8YTa5IuLsSpiaWUJ29+TA6Wx3k+0Wtl8Zm1LYcv3FuERgyKCjz4pM zCcDS63WxmYk0LJZXndKJMlxJeLwmGLPWjxRvCm5I5bH39rr0wlALliyqYzgF0NnPMGp5ZtMNF23 E3AxZ4uh3fP9kl1hDcyVjDnWvIVKkDkavuyFwfP2APqQxx/orFRQV7LhPAhKyYytQLKAC5luOH7F 6FKmwVTGJuTfx9eyD3YD+AsBfwnwM2BOhYAJAAlcuOZAeSobsSRlJtnYD/VSpiA0wlR3HOFC7xkB uW6GetdUwv+LbiAXhBda4JIDLgALwUSB2Ek+V492xrGggMv3KZwHjpen+7zFhseBlBwqURwqEQEv FIVKZh3Zbdm+LTiN4ZXaDwTZr0IBfajbrTIz5xO+hRPF+whofpJrblHECo0LZqBmMOE5AAFm5Nfn cSaQpzK5GjaB2zQt1AMmxaUnntgy8uxGGdni5XU/O3gT8HOxNgnnHd13Hkp2qtmGNMwrmVM143wc UKkTsW+i9tI7oDSV90QwxHu2kIKi2mDDAQOIQSLohRMxoE7Y5/Dj3eT4JyktoZDkaF4lmhfu5z/3 z39/DUwp6ANgL7g5F1xMqVtTsixl5Natl9WiYa7X8gzw0tc9eAMYaiErfkZoteOvqPeUWW6SEXrH UcrAXlZ9X4Mp6jfk7GlQL04mxehkHsr73KRcAOhEqxdr47jorKVykxmZXqp+Q0CnJ5le7MJEGNuw uFGQbsOaGtCRXeRbjToDr9S4qkwMygNfaX7YCUbdSiCFsgrjczXn0LzGNiqlxoVS40KpcVJq3KNS 4zToR/Ly/zal4tBIPWx5T9ZbSbxSGo2XGFExLdAcGUsukdcSC1DHLuXlxV8VWO0K60aS0QnMIL1S 4NyDDGpjWGmPhTg3HmhmXBxw7JFwftI7VvJ6KV/p2rCcb48fGuoetFpWK7BadH0vycohFsfSUf9U xduVU7dMEdvL7cDtiZDcDx1mC/neoWio/guDsuSoMnnTtVu6+YPcGBwfleiOlPcqKO+xnhrrs03P J4dLh10cJAmRRYjonaF2FBONBVevIszldUz1cyErtgfcb/tE8fIWMbW55dT7RkBSR1reVkP9taLk KuRe6zCrjGS1ENecmtOyUw/8QMrl54eepQ0VrfO78LBggc8Y6qbiwBPinO6HSiT609Wy6fctKyaH 5MLEJTPzsJAHcc9y5SX/QBoJVH7QqcBeA8hh2alNmI0UcoI7W6Wu6HYS/SNf8Lu/TcpaJ/HtOMDf 7hu8/UbA9pJYA34DMv2KE5oy7O3r399dKIjsds0TFcHUqUy0U7t0YwpyXPkB0IXZgg7EbCTIL0Cj +mERKKvHjC6s+h/UW8Ym5+LFL/x7U+hZCt6rI6x8ZB3PytQfHkfB1l8lHpF0AZddcdonpP+YnLjk lfpgcm7rcwi8NyWdgtbxlHMNlrq+pHbtnghev5FN2Wj37EvlJd0F5WX6YfR+7OO5lzeW/MXIqyST /ET45e3ZYCkNlQkrDKqvuvuqU4tuuQEl6A0YqmWY7MGV9wrVB64KMZqJkNVl2HfUgy2BWAUqReAf AQYAR3wGuw1lbmRzdHJlYW0NZW5kb2JqDTIxMCAwIG9iag0xNjgyIA1lbmRvYmoNMjExIDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjEwIDAgUiA+PiANc3RyZWFtDQpIiZRX S3PbNhCe9OhfwVMGyJgMHnzmlri16zhuMhbdTieTgywzFhuZ9FByMv733QdAgaySSXUgCWCx++17 FdVvj1QU60SneRHVvx7FKlFalVG9gv3629FHUf8pY2NEJD8B7ctTE+mo/nwU6/AWXFJK4yXx7BdZ /3P0sq4doY6Up7BEQbSGeZ/fS6OSSjxsGpnD2y150cnYJrnYLWUhdm3fbSP86m6jFR33fOyujDcL MfB5i9QbuIOLh4dNu4I1r5gbK1TXWjHSLFEpgFURfViTWKPyKE1VkgP2qL5HizizgDlAyyqpcrpB H+MNkyUmdTdAWZ16tXXOap/JMtGAFYydia4ZlpvoZL1sh1cRmDqzYoTmbFixkEirIsnyAyLQCyvy nbIpy3grq8SAvhplNPyKQftUfJHawutJmjwpRN930QXgAYPJFGjAkPg6Jgi6AMXAWU58nialmouf 22QkrpBmSkwIKQo+iovXUqOk84WMga+oZVnB66DgqkhUeUjwVKZROsnmLiCZxsmEoClB6aFZkpip A40Bu/xATBArsa4SXZkSk8AWNvMhnprREdrF+IcB9bSivxuW99IqEZ1IC3oDFA360hY90P4Qm7um YWxeeRDFTtcaP+ZWf0XQTlMGphILP8458WyaijEEgTIQKyAYwsyOoAsOUJMZHzsFxE6/7iLAhUHy GrPLiAEQpqLrN7cQqBYyQ0T0u6asSqSG00gCa3j3nyU4sRjXfxBNA5GWiW/Mzh8t+sfdGhY5ivpL VhkFLhJumH5LeI4d/wmkR8gYd76TBmgZo7ve4juHO3Fe2QQTK7aVpa+IlWRCCHpDabKX5sFd9rfh 9q7teuCSKtQdjQBJlIsr6S93TMZP3tqwDF4wPM/8A8SA4VgwYvOEqQe1jilX9Fx3LX/4K+fsg7na ybEnYGcsJJbD197Qn8Y6n3uvZ7n3utbsdqAGAqiwg8zARA1UELRkFQB+AyeV29tSFeMnBbNG+5pS s33xByluCsptjZXnOZYhDSuDme55vuNDZnrD/GJCcEXSmkBaiIlRruh7zfIDI6DYhcQMc2qht9TU bVF0xmfMFkLWahAIkctR4yOAJfGzlXZEA6UT5KpZaLGNfkLJGdoLeoa+CrprFhSWap+lBWI4AYEc WdAVKbcKNIvfIXUgTsg5lSVvxiz4f30gypSyvBJOJrkdIhzytBJ3Umt2l4i80Aj1Boy3fXccMYML eqK5Cuv4p7rMqVTMRf5OtGA0zisgOYNiivo5GJePvA8JbJkOXWKMY+cYT5CP0ALm/dc9drAamu0Y YwMlNaMl90JYbcjXbMyu+gXlEndiNzq9g5pWUOqbXJG5TKbgNj6Xbm+AFUbGLe0yhY+LE3gXENu4 18IT2+X8nt+/g328s3Frvx/K9Dg4OZn7Ap4GlPuN6A1gtrmi+LVpQYOA94mvPyx3N8Pj5YJRCrZ+ 7pxgqzTnIuxrb1CFF1T2zcjOQ/zq1PHrbmKYSwKNNZJPWZXlhHamsoxhMnCag/uwgF8DRUmNa6oi c5vvvqFd5peP5v8yw7mZ6fEEZsTzuRm9bG9+KFKFCYOJx5axM1durLuEVkaQ432Bumqg/HFd5ELn 1GhxsKrE12XHxxteLwc0gBm7NxRpHDFwAIPbz2ssiVlQuHCXOd8wny0OrkbEV822WQ4rJ/w4hHS9 QJyZwAZARc3V3rD/9nyvGbArWHHn777fMU73wjvz7n090d8x+sx8Rn8Nzb3UGVb37gDCM0bWkGKD o/SWesLZxYaZfWBKWqzbdUzd+JSa7eM+fjJsSH64oF5NxZErGwZ8Puagb/6Pbga5wVW7nPR8N1/9 uMXHRhv1nSzj4YuZ9ut2G4w+o9WJhGDv/Emsy5nhF333JCvUZAQTzlEPTuPDA4cdBw4XzAucjEtw tHU9WIuHNb+7wJhgrSVtbqlDUvVNHT00Zdbd7qcOvnIOJwv+fC9dJRNhx81oPsjYghijWv1MxTrd C3ZIGBz0uHCsc+3EUfJXi59Mjc2pDN1FcAkPDUtavCSrMFC39Y5foSJeVM9QUACb8xEizpAwCC7a +c5k8Z+4/htC1VJlJ1+6yF03wRQ7ifS+RQcUgQMWTNU/bqbTP3PctX3n5vPvBfgFrSkxeGBmhi4u 0WjZ3EORSwSXRm6WHkvkOKC3N45iDNVYZ8XUyVi1cuqBGqec52REqIsllaNxoMsclxwHOkwCrgZ7 WeG/gGUw/rvRHtU7kNNlMLb/K8AAuLayPw1lbmRzdHJlYW0NZW5kb2JqDTIxMiAwIG9iag0xNzUx IA1lbmRvYmoNMjEzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjEyIDAg UiA+PiANc3RyZWFtDQpIiZRXWXPURhB+96/QU0qT8ipz6MwbBowN2CRebaWSVB7EIizZa8ml1YbA D8nvTV+6FlNUTLEazfR0f323vPz1Sf7jyUoHWtvMy7cnuIqtl386+dM/V6s4SPxOrVxg/aJRqyyI /W2537a89F4p4ywsAqS0vnc2LF6U3nXRq1UUGL9QOsj8Hb+U9OKplY1cEMLiL4AQBXGahJ6Gf5ln HAi1OvacSYIw1c7LH040YUNYcCW/O8lGYsChj4hZHcPq2ChNWZ1NgBBQJssGJdIg9T8qw5BsjNrm KkxZaQs0ZcNEoEoYuOHK6ZLRpZwWO35+VgAGOKKWGigc6usyd7TyLoX53YK5bN6qEC0sIm4q3i1L ZBqGGq7jn1qZUGv/Wu52gkSoh9vPi04IBGHNDxFVDHRrBUYcdC3kWQ6nGyGXy3+rxICrxahHJtms 8T3zn0GAjG5eGRNk1luZwIRx4uUvKNpCOzjKRuyoXKUGXNAeOuWAR6FS/wO6I/LvBv4v309nVf2g rAVYFq1rnI7RcPT38hfc8M/fKhP5p6Oan5TJQEDdf4HrJfxnZjvk1nxAC5tYf8Np66pu7uqRlQhv 79qZ7JH8nYqBaK8wsJD5PccaLkdLEUnD+tVg1ASewYj19Xj3kdCxJSFn0XRusJxL2HJnJZCDOqgE 34cMTZExpB3st6icc+FkobUyKLin84JuN5jvCeZFjDGJ627kt5mgbdbPmDkaLLZLzecmEwzMvfus rBu1Xx92O1A6Ix1nwtGYqVkyuqq3zEFZjI59Swj7p/DMbBQmY3ixjV4AE3IBUDZ1Sc+dsnSPGTFF oMwsoF8pCzwwyIDwsIdEsX5PPo8S1hL/Nk/cRJgJqSTJqCKRfqsMEu5qfu0g40ORMCp1SZs9bRYz rGDFUOyUhd82/VXdiJQVMcpVFGE4DLuTHxpkZfU87L+jDZXL31QWYXMgaGwWKD52ksDQ2+Z0HvAZ lBpN5YGsyg7TVBnioS7YcHBc6NhzV22FQWL9B74mj5L25hGP1beSKkaHzXt+dpC4WC/FW8Fcq3n5 ernfM9d/IDQNFjdpEazBG7SR5fDEZXgc/N4Ny9sd8V1vaVvUYBFCwi8Y24a9euTLCyaom64WJqzg 6mJ+Eyoa9d8hepp9X/eHHkncFFRiIt7txIxiqaGFWTvWbT0v2dxco8E3mWTVWdF11PeiWcoY57g/ TOXuotjfl9SFEl8eqG0yK0mQxVSeoQ0Akh9yZc0sfd7SbgFB6fz3OIZYCDvtr27KfVl024q3TpdS sR2hrtiOyKZ6Eegk8yuoVzz+HJhjx/1wivxcJRGYEHHcF6LKI9MC5yRZum/T8FHNhFDnseAeSWyZ hiaSyY43sj3oVu4FCQuH3pV8V+NZQbRjQQzZdRf7A0ZC5FcrKhfZLGAvCjoZd1fZrLte82Fftw2v dmONq2reaSdrwQFUziP+3E6EIh3CEArUJyzlwxsGJYWJSY8TLccBI6Jk8GtWAwPR2oWnWDbSdDsm 6vv664J3eX1z+YwFU8pP89d5N0OypSXzWZiWsoISxEhDhmIfOCqhAOdfefNeq0TKeYqZBlzeUOU8 tDTdZTwyjSPy/1hsiI/Iw6oGEbFuD31VkjBsMQkqQecMh2HsaiJuhaLm3VNmxFxhVIBfKtkRJ607 BuHiVD+BCm6GNGTYgOYt+H2sWAK0Haqj1EciOeTekfhz0HOuURrzTmhSCR07Xt7Sb9XUvBD1SLT3 lHnOyApzUbsautUr1nO+j5OecMwGI7L7FkPZOM86mWfPC4XT7Bf4HQfHNy22GLB0XzcUiWaWWMvG NC/oZ13d1/tqzLN2dwBUBishhniNksYy/xzfGvz5AD/SV8J0Wfku6q7dV4iLwu53sDymXeLvD3iL 7thIRhzwQWa1/yS+KYkTHhsjGHczsBQOfEDSTjMt8n0kcMtRLR0sZzK2HCYKR2hMnohpjEHGEB8y BEHQts1oVrSxwk9SchbVCmvToePjMQWwo8EqwsgEzBB6McX6VHSRskUXZ+T8SMQzFG762be/7NCK biRnzL8itBHoHxWfNSzjlhWiD7rlt8cVxXEsKNo9WYSnMPgsHXsEBLERjEwyx8t3kU+ClRIFTkFC N2W3bgoi+nogI8+gU+Asvzv5Kc+N9oyXfzwBF8eehn+0cDZwVsee1TbQIX6hPMy+8rg2ysjwrrst GiiiBjwWgvAv4Dcna96/hRKFcUSOSMGlTvMPE/V9WQpFRfQF73c/E3zAaBkifOKkmUGUNFvaKJ6p Q/pkrIFnsC3rp/AnA/4onGq7zLr8EdHz43Avo7UMt1VzSnBw5Iq1FUEWS0m6FPSfAAMAUJq/UA1l bmRzdHJlYW0NZW5kb2JqDTIxNCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNj ZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDQgDS9Gb250QkJveCBbIDAg MCAwIDAgXSANL0ZvbnROYW1lIC9BRUlQSEQrVFQ0N0VvMDAgDS9JdGFsaWNBbmdsZSAwIA0vU3Rl bVYgMCANL0NoYXJTZXQgKC9HNDcpDS9Gb250RmlsZTMgMjE2IDAgUiANPj4gDWVuZG9iag0yMTUg MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMSANL0xh c3RDaGFyIDEgDS9XaWR0aHMgWyAzMzcgXSANL0VuY29kaW5nIDIxNyAwIFIgDS9CYXNlRm9udCAv QUVJUEhEK1RUNDdFbzAwIA0vRm9udERlc2NyaXB0b3IgMjE0IDAgUiANPj4gDWVuZG9iag0yMTYg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA5MCAvU3VidHlwZSAvVHlwZTFD ID4+IA1zdHJlYW0NCkiJYmRgYWRgZGQUcHT1DPBw0Q4JMTF3zTcwAImp/pDhEesGAla5BQzTU5P/ d3fDGTzs9/kfCXa/FWJgYmRk4XE3MYfrZGBgbAeJMrN1831/ywcQYAC1+xmVCmVuZHN0cmVhbQ1l bmRvYmoNMjE3IDAgb2JqDTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL0c0 NyBdIA0+PiANZW5kb2JqDTIxOCAwIG9iag0xNDEyIA1lbmRvYmoNMjE5IDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjE4IDAgUiA+PiANc3RyZWFtDQpIiYxXS2/cNhBGr/oV PFJAliaHD4k+FYVjwCkaJM2il6AHZS3bam3vdnftIP++MyQlUesYZgKsKHKG38w3L5lVkq039PO9 4qxe/1N5JvG/ZwCN0CAdAwlCGqnZ+qGSQkqlSeMrf7+uFQjF/7x6V/+9/lCpRngnYVQ3XtgX6qR5 AmM1qS3lVoQDjqS1aDytviPi79t65YXm+75jLGCerddKMsXWN5XHa+KdtNAQjVdtI6DNbpXhVlrp dOuXp28PNVgBfDjWKyM8Z7uuXjnh+K7fH1ja3Mat8yQywkNER9+VbRB9fREuBz3R+pXf1S1afTzu zs/Ods/hBZBH8W9YdrUUhg+H2uK9R9Ft0v7+hYcjZbIVpj1xDgRypyO/keAFH9D8hBAy1JBKYEZF Y6/qBt1ERrxo+S4Yha4D3x+7x2giu+iO/SGIsfNTIlYtRrEFtlJCGeNGPqxOOGDISgJCM1dGhhQK Kyn5pw4Zxxcwih+QBM+faqWQC4qQQcGhdukg/tL79jHKoJ7CS8J1ZBP5rthhUwEa4J2Zg2Oa2ekm GvOxNuQm3fNcKyka3teABCCuFpZ/i0donLLvMABSThCSINBpBWpEAOuyoorhWGGGydZoIgaU81Oi jOmY6EcvGkv5tdL0/Lg9Dje1R3uGTXcc0NeWs23cYd1m0+8oLC3f9ESbDSzEx4ICrE2F6BkFfqbA R+QPeBF6HjinR1djDv5A/znTKjitlk470Xrlxjtb25os5ym64KWmJAlqK62ExMAGAjBFRku0jwyA hZkCbaWLT9XG/Ag7l5iALQbd4K2PyAEZCfw+vLOa/N7FDKLldR8PovhzEO/JIaCYhH8neYIZZp3L SMqKw0Tb/uj2mzvix/AxFSIrY3Ea60RD/UxZRYvU9xJlCgtX6yVNCsBNLGXlDqIxbmwpc+PMSg1b rJcoQrnZ0LUXY3P9eS9EHLR3Kv2pFSpjozWXWAIWXdszzIWw+lFjACjVruN7egyYinH1WJPxXayP ezYkvZvQwsbr8NSGYlIeX7ugjClpkzab5TSBLZXZvt/0w3OQHGqCiVq3UXffx8VTFL/v9uwpbOwW FicLsXGxheXsE80Uy//CBsMZxCMZjmR8UfHxDhMIxdOt98GQvjv0LLfsMBzZ8S5sUEEq4N/p3j6C f4u64x3JpGh+EmHd8fxFJhhs7q3yWWK6xXRxaD9Ol/A8P8Ma0Tz+xq3nkKSYs47jaMF4YryGcE5N FPgRB5DmNHiog6JCEtqftHY6k3N5YIKnyjUytBAuUquzIHzb5oW+mtsurZrUdb/0cag+XgdkyrO0 EdjE5NPE1yZubpMQphHNgvQYr6AxzUNwgxDmEnbRw9PtbRI4BIGBfkaZxzjcp3ea7S/rEFPXWgMZ +zZjnyg22F3QWct/rZtxIw14JNLGQFtOnEPgXI1zPhyf8oyDV3k948WpLqYxgrVuF110bg7v19V/ lTWh9vGhPPZc+lLQDX2MabZ5qM6uHhS72Fafq9/W1dml+9nXExi71MOOwX+ZAAx9slkb5Cn8+HWB 055ajMdW4yYciDhvKCh4S0G7TCF11ahgChBU7nqJSSp+IJWbhNNyRtAFCFiKM4ItUjBmUnBFJskZ oXkbocWkmxHaIgUnJwX/tkmoADMCFlcJhJwhlCrQaPPkUAWxQw2TYRQEDzVUhvFKBi4wGtFmGAXx Rg2bYbwS8BMNnRX4KxFfWOXo765JoyTk+GWTYbwS8xMNk5XSKzE/sSrvByUxxy+LDKOgwFHDmTc1 FlbZRUsos0qaNz1faJhFlpRUlMm7QlEETfwATFYVdM9W51kCr9THwiqdNwYoyXa9GBoF7Q01ss4A Jf0N8s4AJVzBYm6UxAPyzqBLYq7GyfG/AAMAozGv9w1lbmRzdHJlYW0NZW5kb2JqDTIyMCAwIG9i ag02MDIgDWVuZG9iag0yMjEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAy MjAgMCBSID4+IA1zdHJlYW0NCkiJjJdNamQxEIP3fYp3Ak+V7frxPpssc4ZZh2Huv0klEKzXxERk 1QQhg+qTuq/Hn9f3odfLv8fb4/9jjrbc7JLPv9bn1UObdvErtXnKuP6+fyn6z4rhN8XoWzEoDwGP SSik5dwKI14lbYKHUx4dPIJSiGxF/v6qWM3BY/3uUYq5PaZQCvWtOGR+e1W2BI9D5jePbAYeh8yf PDp4EJlH1H+24pD5kyL2Jc5D5rdXRX3cCiLzUih4HDK/KbzlvsR5yPz2Km+2PYzJ3FvfHkZwXgrZ l2gE52HYDEZwXooJHkzmhldiBOcxsRmM4LwUDh6HzJ88oBmMyXxiMxjD+WixL9EPmd9eNbAZnMl8 YDM4w3lva1+iM5x3bAZnMu+4H85w3nE/nOFcsRmc4VxxP5zJXPFKnOFcsBmC4VxwP4LJXPBKguFc sBmC4NwX7kccMkePUkAzBJF5KaAZguDcE/cjCM5LAc0QROalgP0IgvNSwH4kwbkHNkMSmZcC9iMJ zksB+5EE5+7YDElwXgrYj2Qyd7ySJDgvBTRDEpy74X4kk7nhlSTBeSmgGRbBeSlgPxbxHc4nNsNi Mp/YDIvhfOJ+LIbzgc2wmMwH7sdiOB+4H4vhvGMzLCbzjvuxGM477ocKA3rHalBhSFdcEBUmdsVD UWFYV2wHFQZ2xRFRYZIXvBUVBnfBglBheBfcERXiR5strAgVIv2SQEeoEsiXBKZElWC+JIIuRPqW OCaqBPUlgTVRJbAviaILkb4F7okqAX5JYFBUCfJLMtCFQL8kgi5M+v59MB8CDABh/IqEDWVuZHN0 cmVhbQ1lbmRvYmoNMjIyIDAgb2JqDTU1NyANZW5kb2JqDTIyMyAwIG9iag08PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDIyMiAwIFIgPj4gDXN0cmVhbQ0KSImMV7tqHEEQxOl+xYRWMppH d89sKuTAoWD/QODAcBj/f+K+lZCqVx4oLrljp7YaqrpqLm2PP2+1lfT8Z3vZ/m7S826qqdw/uVtq o2Z/bkktyyw9vd7eIPX/kCYB0gQgjWDRPJGlEyyaDVmEgkgBiFKDFWQxgkXyRJZBQdQAMonBJDdk 2QmW+5NPSF+of4GMBpCF+mGw7j8BslD/wlKRhVG/BcP0hfphsJYVWRbqX1gasjDqt2CYvlA/DFaz IctC/cBSsyDLQv0LSwEWYdQveQKLMLtfsoEthdn9EuJCGPVLLshC7L7seYAthdh9h2BcCKG+Qyqy ELsvM+9gSyF23yEYF0LsvkM6wXKBBMMwg40QF0p4zCHYL0p4zCFoGCU8JhbiQgmPOQT7RYmEcQjG hRIJ4xCMC2U8pqFflEgYh2BcKKO+hn5RxmMS+sWI24VDMC6MUV9CvxjRLw7BfrGF+mGwHuLCmITp oV+MUb8Hw9hC/TBYC3FhTMK00C/GqN+CYYzoF4dgXAxm92vol0HcLhyCcTEY9WuIi8Hsfg39Mpjd LyEuBqN+Cf0ymN0voV9WEBys7yEuBqG+Q7BfBuExh2C/DMIwfWJcEAvmAGgXQnkHgFmImnAABAUz 0sBeYRgGhsQ7w9Ox7Q44j59fej1v95/Hj9v2/dvD8Xv7cfjr/foj5+H7P62Z+v1qJ19eXmf9eP3j cbRU0/Fr299Y3EnnFTJSpHeKfwIMAPkF21INZW5kc3RyZWFtDWVuZG9iag0yMjQgMCBvYmoNPDwg L0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZOTbt28N DQ1v3rzJz8+vrKwcFxf3/ft3hlEwCoY7AAgwAMPkDnoKZW5kc3RyZWFtDWVuZG9iag0yMjUgMCBv YmoNPDwgL0xlbmd0aCA3NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+c nBwrK+umTZtcXV1v3rz5+PHjyMhIMzMzDQ0NSUnJhoYGLi6ue/furVixwsHBITk5+fv37wyjYBQM CwAQYAAQ9RjlCmVuZHN0cmVhbQ1lbmRvYmoNMjI2IDAgb2JqDTw8IC9MZW5ndGggNDYgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTk9u3bMzIyJCUlra2tvby84uLivn// zjAKRsFwBwABBgACBA02CmVuZHN0cmVhbQ1lbmRvYmoNMjI3IDAgb2JqDTw8IC9MZW5ndGggNDkg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGRkcnLynj17cnNza2pqGhoa MjIy4uLivn//zjAKRsGwBgABBgB+1xDPCmVuZHN0cmVhbQ1lbmRvYmoNMjI4IDAgb2JqDTw8IC9M ZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr48eP ra2tjx079v37d4ZRMApGBgAIMABKkgvvCmVuZHN0cmVhbQ1lbmRvYmoNMjI5IDAgb2JqDTw8IC9M ZW5ndGggNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGSkjo7Op0+f Fi9e7Orq6uXldfXq1bi4uO/fvzOMglEwrAFAgAEATCYRbgplbmRzdHJlYW0NZW5kb2JqDTIzMCAw IG9iag08PCAvTGVuZ3RoIDc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPn j5ycHCsr66ZNm1xdXW/evPn48ePIyEgzM7MXL16EhIT4+/tfvXrVwcHh3r17K1as0NHR+f79O8Mo GAXDAgAEGADdCxz/CmVuZHN0cmVhbQ1lbmRvYmoNMjMxIDAgb2JqDTw8IC9MZW5ndGggMzcgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTkvHnztm/fHhcX9/37d4ZRMApG DAAIMACV4wv+CmVuZHN0cmVhbQ1lbmRvYmoNMjMyIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytreXn5wYMH4+LiXrx48f37d4ZR MApGAAAIMACERA29CmVuZHN0cmVhbQ1lbmRvYmoNMjMzIDAgb2JqDTw8IC9MZW5ndGggMzcgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTkvHnzGhoa4uLivn//zjAKRsGI AQABBgCtNwtZCmVuZHN0cmVhbQ1lbmRvYmoNMjM0IDAgb2JqDTw8IC9MZW5ndGggMzcgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTk1atXvby84uLivn//zjAKRsGIAQAB BgC4CAtcCmVuZHN0cmVhbQ1lbmRvYmoNMjM1IDAgb2JqDTw8IC9MZW5ndGggNzUgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2brl69evPmzcePH0dGRpqZmZ0/ f76rq2vPnj3+/v7l5eX37t1bsWKFg4PD9+/fGUbBKBgWACDAAHyRH5wKZW5kc3RyZWFtDWVuZG9i ag0yMzYgMCBvYmoNPDwgL0xlbmd0aCA3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIifrz54+cnBwrK+umTZtcXV1v3rz5+PHjyMhIMzOzmpqarq6utra2T58+OTg43Lt3b8WKFdu3 b//+/TvDKBgFwwIABBgAa+ke+gplbmRzdHJlYW0NZW5kb2JqDTIzNyAwIG9iag08PCAvTGVuZ3Ro IDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkZENDw7x58/z9/VlZ WePi4r5//84wCkbBCAAAAQYAe2MMVQplbmRzdHJlYW0NZW5kb2JqDTIzOCAwIG9iag08PCAvTGVu Z3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr671795SV lfv7+79//84wCkbByAAAAQYAZPMK8wplbmRzdHJlYW0NZW5kb2JqDTIzOSAwIG9iag08PCAvTGVu Z3RoIDc4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr66ZNm65e vXrz5s3Hjx9HRkaamZnx8/N3dXW1tbX5+/uXl5ffu3dvxYoVDg4OIiIi379/ZxgFo2DoA4AAAwDJ vhz2CmVuZHN0cmVhbQ1lbmRvYmoNMjQwIDAgb2JqDTw8IC9MZW5ndGggNDcgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGSkl5fX1atX9+zZw8rKun379ri4uO/fvzOMglEw 3AFAgAEAgZ4PxAplbmRzdHJlYW0NZW5kb2JqDTI0MSAwIG9iag08PCAvTGVuZ3RoIDgxIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr66ZNm65evXrz5s3Hjx9HRkaa mZmJiIhkZGTExcXdu3fv7du3GhoaK1ascHBw8Pf3nzlz5vfv3xlGwSgY4gAgwAAKAR+QCmVuZHN0 cmVhbQ1lbmRvYmoNMjQyIDAgb2JqDTw8IC9MZW5ndGggODggL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2brl69evPmzcePH0dGRpqZmYmIiBgaGsbFxa1YsWLx 4sU6Ojrnz5+/d++eg4ODv7//27dvZ86c+f37d4ZRMAqGLAAIMAA26yNNCmVuZHN0cmVhbQ1lbmRv YmoNMjQzIDAgb2JqDTw8IC9MZW5ndGggNDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIn68+dPZGRkXFzcwYMHV6xYUV5eXlNTs3jx4u/fvzOMglEw3AFAgAEAE5MQ/AplbmRzdHJl YW0NZW5kb2JqDTI0NCAwIG9iag08PCAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnT2RkpIaGxvfv3+/du+fg4ODq6nrz5s24uDiGUTAKhjsACDAAy48PKwpl bmRzdHJlYW0NZW5kb2JqDTI0NSAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr68GDB8vLy1esWGFtbf39+3eGUTAKRgAACDAAJFYM lAplbmRzdHJlYW0NZW5kb2JqDTI0NiAwIG9iag08PCAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkZFxc3MGDB4uKisrLy2tqahYvXvz9+3eGUTAKhjsA CDAANa8QWgplbmRzdHJlYW0NZW5kb2JqDTI0NyAwIG9iag08PCAvTGVuZ3RoIDUwIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2Rk5OnTp+Xk5FhZWR8/fvzixQszM7O4uLjv 378zjIJRMKwBQIABAHIXEMwKZW5kc3RyZWFtDWVuZG9iag0yNDggMCBvYmoNPDwgL0xlbmd0aCA4 NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZuuXr168+bN x48fR0ZGmpmZiYiIZGRkxMXFrVixIjc3V0dHZ+bMmffu3XNwcPD393/79u33798ZRsEoGMoAIMAA kQEg4wplbmRzdHJlYW0NZW5kb2JqDTI0OSAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr6+nTp83MzF68eFFTU/P9+3eGUTAKRgAA CDAArLYNcgplbmRzdHJlYW0NZW5kb2JqDTI1MCAwIG9iag08PCAvTGVuZ3RoIDUwIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2Rk5JQpU7q6uqytrdeuXbtp06bc3Ny4uLjv 378zjIJRMKwBQIABAE/OEW4KZW5kc3RyZWFtDWVuZG9iag0yNTEgMCBvYmoNPDwgL0xlbmd0aCA4 NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZuuXr168+bN x48fR0ZGmpmZiYiIGBkZxcXF3bt3b/HixTo6Oq6uritWrHBwcPD39585c+b3798ZRsEoGMoAIMAA EPwe6wplbmRzdHJlYW0NZW5kb2JqDTI1MiAwIG9iag08PCAvTGVuZ3RoIDQ3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkJD8//82bNw8ePBgXF6ejo7Nnz57v378zjIJR MNwBQIABAEVBD7IKZW5kc3RyZWFtDWVuZG9iag0yNTMgMCBvYmoNPDwgL0xlbmd0aCA3OCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZtcXV1v3rz5+PHjyMhI MzMzERGRq1evamhobN++fcqUKffu3VuxYoWDg0NycvL3798ZRsEoGPoAIMAAY4kdmAplbmRzdHJl YW0NZW5kb2JqDTI1NCAwIG9iag08PCAvTGVuZ3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnj5ycHCsrKxcX1/fv3zU0NDZt2sQwCkbByAAAAQYAc9II7wplbmRzdHJl YW0NZW5kb2JqDTI1NSAwIG9iag08PCAvTGVuZ3RoIDUwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnT2Rk5Pnz5/39/b9//66hofH27VtWVtZPnz7FxcUxjIJRMKwBQIABAI+y EX0KZW5kc3RyZWFtDWVuZG9iag0yNTYgMCBvYmoNPDwgL0xlbmd0aCA0MCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK2tISMjatWuLioq+f//OMApGwcgAAAEGAGB6 CpwKZW5kc3RyZWFtDWVuZG9iag0yNTcgMCBvYmoNPDwgL0xlbmd0aCA0MCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZOSmTZvMzMyUlZXj4uK+f//OMApGwcgAAAEGAPfe CyAKZW5kc3RyZWFtDWVuZG9iag0yNTggMCBvYmoNPDwgL0xlbmd0aCA0OSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZGRNTU1ubm5ISMjp06fPnz/v7+8fFxf3/ft3hlEw CoY1AAgwAFYEEXEKZW5kc3RyZWFtDWVuZG9iag0yNTkgMCBvYmoNPDwgL0xlbmd0aCA1MCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZKSrq+vixYu7urqmTJkyc+bMtra2 uLi479+/M4yCUTCsAUCAAQBLIRFuCmVuZHN0cmVhbQ1lbmRvYmoNMjYwIDAgb2JqDTw8IC9MZW5n dGggNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTkzJkz29razMzM Xrx4sX37dkNDw7i4uO/fvzOMglEwrAFAgAEAU+sRbgplbmRzdHJlYW0NZW5kb2JqDTI2MSAwIG9i ag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2Rk 5Nu3b42MjOLi4r5//84wCkbBiAEAAQYAuOALXAplbmRzdHJlYW0NZW5kb2JqDTI2MiAwIG9iag08 PCAvTGVuZ3RoIDIxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnD8MoGAUj FQAEGADchAL1CmVuZHN0cmVhbQ1lbmRvYmoNMjYzIDAgb2JqDTw8IC9MZW5ndGggNzggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2bXF1dDx48KCIiMm/evGPH jikrK2toaGRkZDQ0NMTFxd27d2/FihUODg7+/v7fv39nGAWjYOgDgAADAD50GsUKZW5kc3RyZWFt DWVuZG9iag0yNjQgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIifrz54+cnBwrK+vjx4/Xrl37/ft3hlEwCkYMAAgwAHLWCvMKZW5kc3RyZWFtDWVu ZG9iag0yNjUgMCBvYmoNPDwgL0xlbmd0aCAzNjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInkxxHX9TAQBODL9XIxVgsGY8FYdHFtcTUYu7FoMBiMBoPFcLF4sV/7/o3vOTPnzHw+ n/4Ry7Jsi5OLVYvty76uq1hdW+VY5bZt+wZyA7O5tqm+KSGEFCAFeuGCsEWYKnQVpgs9hN73Xe2o d6y7HruRUhqJJJEleglZuipNf2OHNEoprdgqKsoOZbXWRpPRzJqCpqLx0M4YY43vBqy1zrKzHmxg 67OFbLlaahaHxcOicw4cgwsAgBAQIkFiiB5igpABM4QC1IA68AE8gRGR0BNGxlSRGvKBTERMgSkx ZU85ESdKjcJBfpJnZs85s28cTo7+lYKPwZfoQ3/2K8UQYygx1BTiGXL8xvjN6Vvrt/Zvns9+5Zxq Tu1KJb9Kya3k3nKbuVzPfdVaylHqVVqttdXe6mit9TZG67P1Xxv9dRx9nH085hi/cfyZx3E+nXOe c97z/HNdb6/7+j3u+/78x/4JMABcVA7VCmVuZHN0cmVhbQ1lbmRvYmoNMjY2IDAgb2JqDTw8IC9M ZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr48eP Q0JCTp8+HRcX9/37d4ZRMApGAAAIMACEcg1jCmVuZHN0cmVhbQ1lbmRvYmoNMjY3IDAgb2JqDTw8 IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyur tbX1sWPHlJWVHz9+/P37d4ZRMApGAAAIMABnegxYCmVuZHN0cmVhbQ1lbmRvYmoNMjY4IDAgb2Jq DTw8IC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPV1cX Kytrbm4uwygYBSMMAAQYAKVkBekKZW5kc3RyZWFtDWVuZG9iag0yNjkgMCBvYmoNPDwgL0xlbmd0 aCAzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz58/3799ZWVkXL17MMApG wQgDAAEGAFVOB9IKZW5kc3RyZWFtDWVuZG9iag0yNzAgMCBvYmoNPDwgL0xlbmd0aCA4MSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZtcXV3NzMy6urpERESu Xr167NgxZWXluLi4jIyM7du3nz59+t69eytWrHBwcPD39//+/TvDKBgFQxwABBgAHT4d9QplbmRz dHJlYW0NZW5kb2JqDTI3MSAwIG9iag08PCAvTGVuZ3RoIDM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsra1FRUUZGRk1NjZmZGcMoGAUjAwAEGADCGggCCmVuZHN0 cmVhbQ1lbmRvYmoNMjcyIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrf3//ihUrysvLubi4vn//zjAKRsEIAAABBgC7mAtrCmVu ZHN0cmVhbQ1lbmRvYmoNMjczIDAgb2JqDTw8IC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+fPwYMHWVlZ29raGEbBKBhhACDAAHAPBtkKZW5kc3RyZWFtDWVu ZG9iag0yNzQgMCBvYmoNPDwgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIifrz54+cnBwrK2tkZOS9e/ccHBxOnz79/ft3hlEwCkYAAAgwAHNUDQkKZW5kc3RyZWFt DWVuZG9iag0yNzUgMCBvYmoNPDwgL0xlbmd0aCAxMTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGAQEhKSlZU1MjJydHRkcK3mcq1m8GmR92lR9ym2DckJCQkxTZkSkpITktOS AwLF0dVLiqurW1paOjo6invWTJk8pWf2miVLlqxatWrKmqNb9hy9CgJ3379/////f4ZRMAoGMQAI MACIZSxnCmVuZHN0cmVhbQ1lbmRvYmoNMjc2IDAgb2JqDTw8IC9MZW5ndGggMzAgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPV1cXKyvrzZs3GUbBKBhhACDAAGT4By0KZW5k c3RyZWFtDWVuZG9iag0yNzcgMCBvYmoNPDwgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK2tubi7DKBgFIwwABBgA3jgEpQplbmRzdHJlYW0NZW5k b2JqDTI3OCAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnj5ycHCsr67Fjx4qKitauXevg4PD9+3eGUTAKRgAACDAAfHYMsgplbmRzdHJlYW0N ZW5kb2JqDTI3OSAwIG9iag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJ+vPnj5ycHCsrq7Ky8pQpU75//84wCkbBiAEAAQYA660IaAplbmRzdHJlYW0NZW5k b2JqDTI4MCAwIG9iag08PCAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnT0hICCsr6+LFixlGwSgYYQAgwAChmAXpCmVuZHN0cmVhbQ1lbmRvYmoNMjgxIDAg b2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dP SEjIlClT3r59y8rK+v3795qamtzcXIZRMApGAAAIMADV0A4jCmVuZHN0cmVhbQ1lbmRvYmoNMjgy IDAgb2JqDTw8IC9MZW5ndGggMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6 8+dPZGTk9u3bMzIy4uLivn//zjAKRsGIAQABBgC2+gtcCmVuZHN0cmVhbQ1lbmRvYmoNMjgzIDAg b2JqDTw8IC9MZW5ndGggMzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+eP nJwcKytrUVFRf3+/srLy9+/fGUbBKBgZACDAAKkrCa8KZW5kc3RyZWFtDWVuZG9iag0yODQgMCBv YmoNPDwgL0xlbmd0aCA4NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+c nBwrK+umTZuuXr26ePFiZWXl/v5+MzMzV1fX79+/Hzt27PTp058+fUpOTp45c2ZbW5uDg8O9e/dW rFjh7+/PMApGwVAGAAEGAHfoIpYKZW5kc3RyZWFtDWVuZG9iag0yODUgMCBvYmoNPDwgL0xlbmd0 aCA0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+uKFSsiIyOP HTv2/ft3hlEwCkYGAAgwAEfbC5gKZW5kc3RyZWFtDWVuZG9iag0yODYgMCBvYmoNPDwgL0xlbmd0 aCA4MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZuuXr26 ePHix48fR0ZGmpmZHTt2jJ+f//v3758+fUpOTtbR0fH39y8vL793796KFSscHBwYRsEoGOIAIMAA phAfvQplbmRzdHJlYW0NZW5kb2JqDTI4NyAwIG9iag08PCAvTGVuZ3RoIDMzIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkpLKyclxc3Pfv3xlGwSgYSQAgwAD+xAhoCmVu ZHN0cmVhbQ1lbmRvYmoNMjg4IDAgb2JqDTw8IC9MZW5ndGggODQgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2brl69evPmzcePH0dGRpqZmfHz8x88eHDPnj3J yck6OjqSkpLl5eX37t1bsWKFg4ODv7//9+/fGUbBKBjKACDAABy3H/kKZW5kc3RyZWFtDWVuZG9i ag0yODkgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIifrz509kZGRDQ8O8efPi4uK+f//OMApGwYgBAAEGAKwpC1kKZW5kc3RyZWFtDWVuZG9iag0y OTAgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI ifrz509kZKSXl9fVq1fj4uK+f//OMApGwYgBAAEGALMlC1wKZW5kc3RyZWFtDWVuZG9iag0yOTEg MCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz 509kZKSOjs6nT5/i4uK+f//OMApGwYgBAAEGAKk1C1kKZW5kc3RyZWFtDWVuZG9iag0yOTIgMCBv YmoNPDwgL0xlbmd0aCA2NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+c nBwrK+umTZtcXV1zc3O/f/8eGRlpZmbW398/ZcoUBweHe/furVixwt/fn2EUjILhBQACDABkWRXE CmVuZHN0cmVhbQ1lbmRvYmoNMjkzIDAgb2JqDTw8IC9MZW5ndGggMzYgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePsrJycnIyKyvrzZs3IyMjGUbBKBgxACDAAEZcCCwKZW5k c3RyZWFtDWVuZG9iag0yOTQgMCBvYmoNPDwgL0xlbmd0aCA3NyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZtcXV1zc3MPHjyorKzc398fGRkZFxeXkZHx9u1b Li6ue/furVixwsHBwd/f//v37wyjYBQMfQAQYAC2WBtJCmVuZHN0cmVhbQ1lbmRvYmoNMjk1IDAg b2JqDTw8IC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dP ZGSkjo4OKyvr4sWLX7x4YWZmxjAKRsHIAAABBgAoBgnWCmVuZHN0cmVhbQ1lbmRvYmoNMjk2IDAg b2JqDTw8IC9MZW5ndGggMzMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dP ZGRkcnKyv79/f38/wygYBSMJAAQYABwPB8MKZW5kc3RyZWFtDWVuZG9iag0yOTcgMCBvYmoNPDwg L0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZGRycvKe PXvi4uK+f//OMApGwYgBAAEGALQGC1wKZW5kc3RyZWFtDWVuZG9iag0yOTggMCBvYmoNPDwgL0xl bmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+vatWu7 urqmTJmioaHx/ft3hlEwCkYAAAgwAMOmDBwKZW5kc3RyZWFtDWVuZG9iag0yOTkgMCBvYmoNPDwg L0xlbmd0aCA2NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+um TZtcXV0XL178/fv3yMhIMzOz/v7+KVOmODg43Lt3b8WKFf7+/gyjYBQMLwAQYABAVxZmCmVuZHN0 cmVhbQ1lbmRvYmoNMzAwIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurtbX1sWPHIiMjHz9+/P37d4ZRMApGAAAIMABDeAz6CmVu ZHN0cmVhbQ1lbmRvYmoNMzAxIDAgb2JqDTw8IC9MZW5ndGggMzYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGRkcnJyW1tbXFzc9+/fGUbBKBgxACDAANQ8CroKZW5kc3Ry ZWFtDWVuZG9iag0zMDIgMCBvYmoNPDwgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIifrz509kZKSDgwMrK2t/f39cXNzBgwe/f//OMApGwQgAAAEGAJ0lDL4KZW5k c3RyZWFtDWVuZG9iag0zMDMgMCBvYmoNPDwgL0xlbmd0aCAzNiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK2tDQ4OhoeH3798ZRsEoGDEAIMAAudwIVgplbmRzdHJl YW0NZW5kb2JqDTMwNCAwIG9iag08PCAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnj5ycXFxc3M2bN11dXZWVlc+fP8/Kyvr9+3eGUTAKhjsACDAA+vgNjQpl bmRzdHJlYW0NZW5kb2JqDTMwNSAwIG9iag08PCAvTGVuZ3RoIDUwIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJ+vPnj5yc3JQpUxYvXlxTUzNv3jwvLy9XV1dWVtbv378zjIJRMKwB QIABAOKgDuMKZW5kc3RyZWFtDWVuZG9iag0zMDYgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK6uXl9enT5++f//OMApGwYgBAAEG AIYUCfcKZW5kc3RyZWFtDWVuZG9iag0zMDcgMCBvYmoNPDwgL0xlbmd0aCA0OSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnNzp06dzc3M3bdqUkZHR0NBQU1PDysr6/ft3 hlEwCoY1AAgwAKpfEC0KZW5kc3RyZWFtDWVuZG9iag0zMDggMCBvYmoNPDwgL0xlbmd0aCA0MyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+uePXtcXV1v3ryZm5v7 /ft3hlEwCkYAAAgwAKRHDRgKZW5kc3RyZWFtDWVuZG9iag0zMDkgMCBvYmoNPDwgL0xlbmd0aCA0 NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+uLFy8kJSXPnz8/ c+bM79+/M4yCUTACAECAAQDP9g1+CmVuZHN0cmVhbQ1lbmRvYmoNMzEwIDAgb2JqDTw8IC9MZW5n dGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrTU1NW1vb zJkzGxoavn//zjAKRsEIAAABBgAdlgyUCmVuZHN0cmVhbQ1lbmRvYmoNMzExIDAgb2JqDTw8IC9M ZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrixcv /P39z58/39DQ8P37d4ZRMApGAAAIMADSXA3VCmVuZHN0cmVhbQ1lbmRvYmoNMzEyIDAgb2JqDTw8 IC9MZW5ndGggMzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJychoaG srKyl5cXKyvr9+/fGUbBKBgZACDAALhmCAIKZW5kc3RyZWFtDWVuZG9iag0zMTMgMCBvYmoNPDwg L0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+v2 7dszMjK+f//OMApGwYgBAAEGAIlFCaAKZW5kc3RyZWFtDWVuZG9iag0zMTQgMCBvYmoNPDwgL0xl bmd0aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnNzp06fNzMxe vHhhaGi4ffv2TZs2sbKyfv/+nWEUjIJhDQACDAB12hDMCmVuZHN0cmVhbQ1lbmRvYmoNMzE1IDAg b2JqDTw8IC9MZW5ndGggNDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+eP nJzclClTTp8+7e/vf/78eQ0Nje/fvzOMglEwAgBAgAEAx64OIwplbmRzdHJlYW0NZW5kb2JqDTMx NiAwIG9iag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ +vPnj5ycHCsr69WrV9va2r5//84wCkbBiAEAAQYAnU0KVAplbmRzdHJlYW0NZW5kb2JqDTMxNyAw IG9iag08PCAvTGVuZ3RoIDQyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPn j5ycHCsra1tbW01NTW5urpmZ2ffv3xlGwSgYAQAgwAAQbgsyCmVuZHN0cmVhbQ1lbmRvYmoNMzE4 IDAgb2JqDTw8IC9MZW5ndGggMzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6 8+ePnJwcKyvrvHnzJCUlv3//zjAKRsGIAQABBgDwAAhoCmVuZHN0cmVhbQ1lbmRvYmoNMzE5IDAg b2JqDTw8IC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+eP nJxcXFzcvXv3uLi4lJWVv3//zjAKRsHIAAABBgDplwpvCmVuZHN0cmVhbQ1lbmRvYmoNMzIwIDAg b2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+eP nJzclClTQkJC2traZs6cqaGh8f37d4ZRMApGAAAIMACxIwzBCmVuZHN0cmVhbQ1lbmRvYmoNMzIx IDAgb2JqDTw8IC9MZW5ndGggNDcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn6 8+ePnJzc6dOnv3//rqGh8enTJ1ZW1rdv37548YJhFIyC4Q4AAgwAbmERcQplbmRzdHJlYW0NZW5k b2JqDTMyMiAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnj5ycHCsra1tbW01NzeLFi83MzL5//84wCkbBCAAAAQYA7F0L1AplbmRzdHJlYW0N ZW5kb2JqDTMyMyAwIG9iag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJ+vPnj5ycHCsrq4iIyJ49e75//84wCkbBiAEAAQYAyGYIswplbmRzdHJlYW0NZW5k b2JqDTMyNCAwIG9iag08PCAvTGVuZ3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnj5ycHCsr64sXL5SVlWfOnPn9+3eGUTAKRgYACDAAFfYLLwplbmRzdHJlYW0NZW5k b2JqDTMyNSAwIG9iag08PCAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnj5yc3OnTp7u6uuLi4vbs2ZOcnKyhofH9+3eGUTAKhjsACDAAqRsPIgplbmRzdHJl YW0NZW5kb2JqDTMyNiAwIG9iag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnj5ycHCsr69u3bzMyMr5//84wCkbBiAEAAQYAaQ8KQgplbmRzdHJlYW0N ZW5kb2JqDTMyNyAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJ+vPnj5ycHCsr6/bt2xsaGubNm2dkZPT9+3eGUTAKRgAACDAAc/UMWAplbmRzdHJl YW0NZW5kb2JqDTMyOCAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnj5ycHCsra0ZGxsyZM9va2iQlJb9//84wCkbBCAAAAQYA5D0LIwplbmRz dHJlYW0NZW5kb2JqDTMyOSAwIG9iag08PCAvTGVuZ3RoIDM2IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsrKz8/v6Gh4ffv3xlGwSgYMQAgwADN3gcDCmVuZHN0cmVh bQ1lbmRvYmoNMzMwIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2b2traZs6cqaOj8/37d4ZRMApGAAAIMAAb5ww6CmVuZHN0 cmVhbQ1lbmRvYmoNMzMxIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr27dvvby8rl69mpGR8f37d4ZRMApGAAAIMAA0wQ2fCmVu ZHN0cmVhbQ1lbmRvYmoNMzMyIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrQ0PD9u3bMzIyPn369P37d4ZRMApGAAAIMAArsQ32 CmVuZHN0cmVhbQ1lbmRvYmoNMzMzIDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrTU3Nnj17kpOT3759+/37d4ZRMApGAAAIMADc ZA3bCmVuZHN0cmVhbQ1lbmRvYmoNMzM0IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr1atXk5OT9+zZ4+/v//37d4ZRMApGAAAI MACE5Q0MCmVuZHN0cmVhbQ1lbmRvYmoNMzM1IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyuriIiIjo7Op0+f2travn//zjAKRsEI AAABBgCqOgtrCmVuZHN0cmVhbQ1lbmRvYmoNMzM2IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurq6vrp0+fdHR0tm/f/v37d4ZR MApGAAAIMAASxQyRCmVuZHN0cmVhbQ1lbmRvYmoNMzM3IDAgb2JqDTw8IC9MZW5ndGggNDMgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurl5fX27dvDQ0N9+zZ8/37 d4ZRMApGAAAIMABq5QyvCmVuZHN0cmVhbQ1lbmRvYmoNMzM4IDAgb2JqDTw8IC9MZW5ndGggNDAg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurjo6OsrLyvHnzvn// zjAKRsHIAAABBgC7pQkKCmVuZHN0cmVhbQ1lbmRvYmoNMzM5IDAgb2JqDTw8IC9MZW5ndGggMzYg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrcnJyRkbG9+/fGUbB KBgxACDAAJ7wCKQKZW5kc3RyZWFtDWVuZG9iag0zNDAgMCBvYmoNPDwgL0xlbmd0aCA0MyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+v58+eNjIzevn3b0NDw/ft3 hlEwCkYAAAgwAPwGDY0KZW5kc3RyZWFtDWVuZG9iag0zNDEgMCBvYmoNPDwgL0xlbmd0aCA0MyAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrKys/P/+nT590dHS2b9/+ /ft3hlEwCkYAAAgwADL7C+8KZW5kc3RyZWFtDWVuZG9iag0zNDIgMCBvYmoNPDwgL0xlbmd0aCA0 MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK6urq+uePXuSk5O3 b9/+/ft3hlEwCkYAAAgwABmvDJQKZW5kc3RyZWFtDWVuZG9iag0zNDMgMCBvYmoNPDwgL0xlbmd0 aCA0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+unT5+UlZUX L178/ft3hlEwCkYGAAgwAMbqC2sKZW5kc3RyZWFtDWVuZG9iag0zNDQgMCBvYmoNPDwgL0xlbmd0 aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+v58+eNjIy2 b9/e0NDw/ft3hlEwCkYAAAgwACAXDOsKZW5kc3RyZWFtDWVuZG9iag0zNDUgMCBvYmoNPDwgL0xl bmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK2tycvK8 efO8vLxERES+f//OMApGwQgAAAEGAKdPCmAKZW5kc3RyZWFtDWVuZG9iag0zNDYgMCBvYmoNPDwg L0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+v5 8+czMjK+f//OMApGwYgBAAEGAF6ECegKZW5kc3RyZWFtDWVuZG9iag0zNDcgMCBvYmoNPDwgL0xl bmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK6uRkdH5 8+f9/f1v3rz5/ft3hlEwCkYAAAgwAJMyDL4KZW5kc3RyZWFtDWVuZG9iag0zNDggMCBvYmoNPDwg L0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+vM mTMzMjK+f//OMApGwYgBAAEGAH66CUYKZW5kc3RyZWFtDWVuZG9iag0zNDkgMCBvYmoNPDwgL0xl bmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+vMmTMz MjIaGhq8vLy+f//OMApGwQgAAAEGAF9LC6QKZW5kc3RyZWFtDWVuZG9iag0zNTAgMCBvYmoNPDwg L0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnJyGhsa9 e/ccHByUlZXj4uK+f//OMApGwQgAAAEGABZqC4kKZW5kc3RyZWFtDWVuZG9iag0zNTEgMCBvYmoN PDwgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZOTb t29ZWVlXrFhhZmamrKwcFxf3/ft3hlEwCoY7AAgwAOMVDdgKZW5kc3RyZWFtDWVuZG9iag0zNTIg MCBvYmoNPDwgL0xlbmd0aCA2OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz 54+cnBwrK+umTZtcXV1v3rz5+PHjyMhIMzOz79+/v337louL6969eytWrHBwcNDR0WEYBaNgGAGA AAMAF/oYxAplbmRzdHJlYW0NZW5kb2JqDTM1MyAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsra25u7unTp0NCQu7du/f9+3eGUTAK RgAACDAA0/UNgQplbmRzdHJlYW0NZW5kb2JqDTM1NCAwIG9iag08PCAvTGVuZ3RoIDc1IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr66ZNm1xdXW/evPn48ePIyEgz MzMNDQ1ra+vv37+/ffuWi4vr3r17K1ascHBwSE5OZhgFo2BYAIAAAwD4YxqSCmVuZHN0cmVhbQ1l bmRvYmoNMzU1IDAgb2JqDTw8IC9MZW5ndGggNDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIn68+dPZGSkjo4OKytrbm7u48ePra2t4+Livn//zjAKRsFwBwABBgDnAQ0zCmVuZHN0 cmVhbQ1lbmRvYmoNMzU2IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+dPZGTk9u3bMzIyNDQ0vn//fuzYsbi4OIZRMApGAAAIMADZWg4mCmVu ZHN0cmVhbQ1lbmRvYmoNMzU3IDAgb2JqDTw8IC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr4sWLp0yZ0tXV9f37d4ZRMApGBgAIMAAUtAuGCmVu ZHN0cmVhbQ1lbmRvYmoNMzU4IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGSksrLylClTQkJCjh07FhcX9/37d4ZRMApGAAAIMAC2ag1y CmVuZHN0cmVhbQ1lbmRvYmoNMzU5IDAgb2JqDTw8IC9MZW5ndGggNDcgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGSkl5fX1atXp0yZ0tXVdezYsbi4uO/fvzOMglEw3AFA gAEAN6sRCAplbmRzdHJlYW0NZW5kb2JqDTM2MCAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkZENDw7x58+Li4g4ePNjf3//9+3eGUTAK RgAACDAAJ3gPSQplbmRzdHJlYW0NZW5kb2JqDTM2MSAwIG9iag08PCAvTGVuZ3RoIDc5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr66ZNm1xdXW/evPn48ePIyEgz M7Oamppjx44dPHhw+/btp0+fvnfv3ooVKxwcHN6+ffv9+3eGUTAKhj4ACDAA59gisQplbmRzdHJl YW0NZW5kb2JqDTM2MiAwIG9iag08PCAvTGVuZ3RoIDQ3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ+vPnT2Rk5MyZM1lZWRcvXrx27dqioqK4uLjv378zjIJRMNwBQIABAJgRDx8K ZW5kc3RyZWFtDWVuZG9iag0zNjMgMCBvYmoNPDwgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIifrz509kZOTatWtZWVmnTJkSEhISFxf3/ft3hlEwCkYAAAgwANhc DM0KZW5kc3RyZWFtDWVuZG9iag0zNjQgMCBvYmoNPDwgL0xlbmd0aCA4NCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+umTZuuXr168+bNx48fR0ZGmpmZiYiIxMXF FRUV6ejozJw5s62tzcHB4d69eytWrPD3909OTv7+/TvDKBgFQxkABBgAL64frgplbmRzdHJlYW0N ZW5kb2JqDTM2NSAwIG9iag08PCAvTGVuZ3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJ+vPnj5ycHCsr6/fv3x0cHO7du1dUVMQwCkbByAAAAQYAbGcK8wplbmRzdHJlYW0N ZW5kb2JqDTM2NiAwIG9iag08PCAvTGVuZ3RoIDM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJ+vPnT2RkJBcXl7W1tYaGxvfv3+Pi4hhGwSgYGQAgwAB7YwlGCmVuZHN0cmVhbQ1l bmRvYmoNMzY3IDAgb2JqDTw8IC9MZW5ndGggODcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIn68+ePnJwcKyvrpk2brl69evPmzcePH0dGRpqZmYmIiMybNy8uLq6oqCg3N1dHRyc5 Odnf39/BweHevXsrVqyYOXPm9+/fGUbBKBiyACDAAG7CIT0KZW5kc3RyZWFtDWVuZG9iag0zNjgg MCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz 509kZOTp06fl5OTi4uK+f//OMApGwYgBAAEGANfkCroKZW5kc3RyZWFtDWVuZG9iag0zNjkgMCBv YmoNPDwgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509k ZOT58+clJSUdHBxWrFgRFxf3/ft3hlEwCkYAAAgwALZkDW8KZW5kc3RyZWFtDWVuZG9iag0zNzAg MCBvYmoNPDwgL0xlbmd0aCA0MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz 54+cnBwrK+uUKVNyc3M3bdrk6ur6/ft3hlEwCkYAAAgwAOvqDCsKZW5kc3RyZWFtDWVuZG9iag0z NzEgMCBvYmoNPDwgL0xlbmd0aCA3MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI ifrz54+cnBwrK+umTZtcXV1v3rz5+PHjyMhIMzMzDQ0Na2trHR0dBweHe/furVixYubMmd+/f2cY BaNguACAAAMA6igY0wplbmRzdHJlYW0NZW5kb2JqDTM3MiAwIG9iag08PCAvTGVuZ3RoIDQwIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsrq5mZmbKy8ooVK75//84w CkbByAAAAQYAbKgJRgplbmRzdHJlYW0NZW5kb2JqDTM3MyAwIG9iag08PCAvTGVuZ3RoIDM3IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2RkJBcX17179+Li4r5//84wCkbB iAEAAQYAyDkKtwplbmRzdHJlYW0NZW5kb2JqDTM3NCAwIG9iag08PCAvTGVuZ3RoIDc4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsr66ZNm1xdXW/evPn48ePIyEgz M7OZM2f29/d3dXV5eXnFxcXdu3dvxYoVDg4ODQ0N379/ZxgFo2DoA4AAAwBUPR3pCmVuZHN0cmVh bQ1lbmRvYmoNMzc1IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIn68+ePnJwcKyurhobGzZs3XV1dz58///37d4ZRMApGAAAIMADi4wyCCmVuZHN0 cmVhbQ1lbmRvYmoNMzc2IDAgb2JqDTw8IC9MZW5ndGggNDYgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurq6ursrKymZnZixcv4uLivn//zjAKRsFwBwABBgAefAvv CmVuZHN0cmVhbQ1lbmRvYmoNMzc3IDAgb2JqDTw8IC9MZW5ndGggNDAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePsrLysWPHIiMjv3//rqGhERcXxzAKRsHIAAABBgA2nAsy CmVuZHN0cmVhbQ1lbmRvYmoNMzc4IDAgb2JqDTw8IC9MZW5ndGggNDMgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGSkv7//+fPn+/v7u7q64uLivn//zjAKRsEIAAABBgBE Yw6kCmVuZHN0cmVhbQ1lbmRvYmoNMzc5IDAgb2JqDTw8IC9MZW5ndGggMzYgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKytrW1ubmZnZ9+/fGUbBKBgxACDAABt0CHcK ZW5kc3RyZWFtDWVuZG9iag0zODAgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK+unT59yc3O/f//OMApGwYgBAAEGAMG2CmAKZW5k c3RyZWFtDWVuZG9iag0zODEgMCBvYmoNPDwgL0xlbmd0aCAzNyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifrz54+cnBwrK2tGRsbNmze/f//OMApGwYgBAAEGALNfCgYKZW5kc3Ry ZWFtDWVuZG9iag0zODIgMCBvYmoNPDwgL0xlbmd0aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIifrz54+cnBwrK+uLFy9WrFhRXl5+8+ZNV1fXuLi479+/M4yCUTCsAUCAAQBo URDMCmVuZHN0cmVhbQ1lbmRvYmoNMzgzIDAgb2JqDTw8IC9MZW5ndGggNTAgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvrpk2bioqK1q5du3jx4pqamri4uO/fvzOM glEwrAFAgAEAjXkQLQplbmRzdHJlYW0NZW5kb2JqDTM4NCAwIG9iag08PCAvTGVuZ3RoIDQ5IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsra01NjbW19ePHj3Nzczdt 2hQXF/f9+3eGUTAKhjUACDAAoQoPiAplbmRzdHJlYW0NZW5kb2JqDTM4NSAwIG9iag08PCAvTGVu Z3RoIDQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsrq7+//6ZN m8zMzL5//84wCkbByAAAAQYAT28J6AplbmRzdHJlYW0NZW5kb2JqDTM4NiAwIG9iag08PCAvTGVu Z3RoIDM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnj5ycHCsrq6SkpIaG xvfv37u6uhhGwSgYGQAgwACSogikCmVuZHN0cmVhbQ1lbmRvYmoNMzg3IDAgb2JqDTw8IC9MZW5n dGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyvr9+/fGUbB KBhhACDAAKhXBkMKZW5kc3RyZWFtDWVuZG9iag0zODggMCBvYmoNPDwgL0xlbmd0aCA1MCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIifrz509kZGRGRsb27dsdHBxWrFhRVFS0du3a uLi479+/M4yCUTCsAUCAAQBVERFxCmVuZHN0cmVhbQ1lbmRvYmoNMzg5IDAgb2JqDTw8IC9MZW5n dGggNTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTkvHnzGhoauLi4 7t27Z21t/fjx47i4uO/fvzOMglEwrAFAgAEAQYIRawplbmRzdHJlYW0NZW5kb2JqDTM5MCAwIG9i ag08PCAvTGVuZ3RoIDQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ+vPnT2Rk 5NWrV728vE6fPi0nJ6esrBwXF/f9+3eGUTAKhjsACDAA1EAOgAplbmRzdHJlYW0NZW5kb2JqDTM5 MSAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ +vPnj5ycHCsra1xc3OLFi2tqavj5+b9//84wCkbBCAAAAQYAM/0K5wplbmRzdHJlYW0NZW5kb2Jq DTM5MiAwIG9iag08PCAvTGVuZ3RoIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJ+vPnj5ycHCsr682bN+Pi4g4ePBgSEvL9+3eGUTAKRgAACDAA1CMNJwplbmRzdHJlYW0NZW5k b2JqDTM5MyAwIG9iag08PCAvTGVuZ3RoIDM3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJ+vPnj5ycHCsr682bN7u6ur5//84wCkbBiAEAAQYA5DkKbAplbmRzdHJlYW0NZW5kb2Jq DTM5NCAwIG9iag08PCAvTGVuZ3RoIDQ3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJ+vPnT2RkZFtb28yZM48dOxYSEjJlypS4uLjv378zjIJRMNwBQIABAGFNEGYKZW5kc3RyZWFt DWVuZG9iag0zOTUgMCBvYmoNPDwgL0xlbmd0aCA0NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIifrz509kZOSePXuSk5OVlZXl5OROnz4dFxf3/ft3hlEwCoY7AAgwAMePDoAKZW5k c3RyZWFtDWVuZG9iag0zOTYgMCBvYmoNPDwgL0xlbmd0aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIifrz509kZKSRkdHbt2/Xrl1bVFS0YsWK8vLyuLi479+/M4yCUTCsAUCA AQA9tBIWCmVuZHN0cmVhbQ1lbmRvYmoNMzk3IDAgb2JqDTw8IC9MZW5ndGggMzcgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+ePnJwcKyurmZnZvXv3vn//zjAKRsGIAQABBgAj aQl/CmVuZHN0cmVhbQ1lbmRvYmoNMzk4IDAgb2JqDTw8IC9MZW5ndGggNTAgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIn68+dPZGTkp0+fdHR0Hj9+bG1tfe/ePS4urri4uO/fvzOM glEwrAFAgAEAVZ4RawplbmRzdHJlYW0NZW5kb2JqDTM5OSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyNSAvSGVpZ2h0IDEyNSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSA5MyAwIFIgL0xlbmd0aCA1NDI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ7Fddi97GFZZQQe8u5EIOpWAoiEBNzKaMN2CMGvciDa1qE0Jc3F6N65Y0 F+2YzY1J37hkQrzGTsfFi4eQDZ3abofETDx/ss+ZM6NX++mP1r2qsN+VRtI85zznOR+K8f/Hcx/W Wfxz/1PM4JQUfTU7WiGUeflGeD12VdUJKZ2zIS3Bd61GMkbIl2iAkx2cVPYou3C7GvTLQPbYupP+ KU/p4SXga1G1Y3i2R4H/VCOfB7qrhjnZSslB9Ga6prPgpssAksb/Erw+sFUlldZyRUQFy9R4/Dsv dNhDtulSek2ehwp2KHnAZPlscTry8KIaCnRQBU4oZJecwGUFic2iEBhUt636T7BV25VYe1l1Q0ET fdeXlAuyVa2PXbFRG11lvY+VeGHng6gKl34E+aHiCzsK0bWgXvFVgO+xKm+5ttdtfs/3/MzzH6aa vIltins1dumGcvB9KjbO0U+Xr7QYB8rK/KqshvgCx4HXkvd81vZSqS7rWyj82PJwr2UF02S5dm3r nhcalJs9C54CqHlNdtrqsXDbD9LaWII7DtFXENsKsd+301MPBGtPfoWxUrZCoPlSDWJUUxZoKZB8 fCGVaMcqtvPEG6t9aXj84ao+W50DKyXKFrKpf5oTHvmvHPQ4r4imGo984SB22ycWVdSVy4W17R2t qNVTlocJuy+bkHmqC37Pqn529Oy3a8exl4WD+WHV3mEC/X1mgu1WATfRmudC99nvSlJmiX2aD0oA DRpDfVdGo8iPVHOwNo0S7aqnyk5xxXlG9CneHqNDVflOzW6iYlcjeek0BG+t0gYW4MLb1O/J6lmL UWpoDUv3mdBD32cG+wHlSUg/vYQKW2UFWmUDqoyykIU1Kliq+xac7G29PYTeZuOnonvMIaY6abRA yvroGD0MVat92sArHYK20ZigolNB6+Dx3xg/tpVw+X0ZdA+h69YKvq5cPP6Qs/zWMFsiDClLZdtJ woNnjiorXA3KAxwmRK2p6KrgtLN9lUce2cVWhM7aQvhYHd9mzJ5qZNQAbFqBgiV5bIL2BuUl1TpD +LipHKFbrXUqPFMrHSGCqnOr3tJ18ZgjZCPhBRPQd0m6SLhkdIC8QDmFJAA4MLjFBaSPHs9RRYCG 9PgI6fqZO749rtT1PbuPvtDy+4NJss9aCXARfkJvITnO4HDdUdoZr01wSD8lW47e2O2lUldHzN20 SZKE5SeGUl18O9VKwkB6OeIl8E9eBueGKUsdFrrV/CdjO5usGbqjwh6YlS6T15ls7cAIxvnkNhA0 tjJpZuVbIN0aes1qlTeTKYLZU9N2mL0dxfUo4vukB19yTQ0ZG1U8xlvmix9rHiDAryE45/HZFiyU loKtSX/OKPbNJ3Q+Z+41/ZojiLech8gMawR9eon0hkhptMQ7n57aZj9Dcp+CSyXWugB8ix+TciCX AjfVtJAT3JBbvTgUPM+HULwQqJOBqrquekCw/U/M+ycfENMu5ogX2kmBxIVy9CQlvSeOdJ6FTMGj 8ugPLXS6lJfSF1qDJEeiG6PTHbOMf61vgv/kfhZGftYnI7TlNeOSgdgyLUsI1sGjoafL8bBkLyMZ EGmPMFBxhel2B35hr4dEwL367EeJB81MFs/5OtPhdJlyUpijolF3tNYktw5zXa/qqsF8iImNekz2 zS3NQ/WQ7n1R/+C7ydMZODPBileT5KPARI/BIF9xeT3E9ex4lqei78wxCUXR9BK2l2zv7vt1fS/m EWEGHlgYCukIEqA8ni50R9VCpIIVMsRB17PjZpaGlguET4xavVzuPolP1MObdf1hLLz6aR+Og1Up G6G3ZJ4zPoW9x6Qhpw+ecf9wlAeWvl2NIR2L1CUFAG03V5J7dX36yuTwZKqOgSod2wDiFdOhklf4 yBldedTty/Vc/i3N+FVpv5YirpKEeWD3t9T27uMI39e/2g/uKdkcXKcLhfqniA10ovZgYvd7hxrJ IhCYznJvCqiqKF0PkwqKvnb1Lujf+aCu6z8zJPPkqcqZKQ0gUvqkDTrV3VmIjUhh1XsbO1d1N4Ci nsM5dEjv8gwncHyypJ3djv4R0H/2j+CJWAeOFeq+yQOWps6buMLAg4YQxyx2P3rMw2n3PZLzM1Ok 5BUTzSQrxI4S7NGSr3d2fgX0+vepvGqb6hrExTfxkidw6u8hRT5DGYm2kdpRHOYjcdafwbdn5CeT uS5/iZLjD9ZPnn370lcJZ/koXq7rtfomGsvKgXxK323Ja2Ux1tpEYmReASPSjnbOe8esC6fbPhbH Y9IbnPfL9OjZOh1nL//hvb9HQgf1fsZfaWfU6KjLYqrkJh5yU5eIqu15ZfWe57aTuMhSL0UJHSOY TOilenWcZFNOvrcC177wjoEDessVOK4+PKQbHct5WOndcAsfiRI5oyIZieFk97Gjjbf/uFavr9VE OI71tXU6ubfaJWcvKd9hnlmFxHIFc9J32UXdTq/l+KOTa5U8d/MRm/Jle3s3hmV48DpAE3Lye43+ fThBMEEYd2jus1Mc4qTuIcpxaBlgutcmGw31PfZYts4mZwMNijbsAD+k3pGEtp6A17IJp7/LRqYZ GzqjHkhi0FMhy71kbNshT7iroLOfsh9VpqoTzqGUerfUuzSWxydOLZe3yNpPi8/1xMAalztSmqKi lnqKmnp+nOKaxMPuiRJXy7eUFX2bxzjLu0Ezyt+9u7X1uy0cd81WOm7Xj9LfT7Zun1qDGe/cubp5 5sKdsPztDbBl759fvHLuc7/pwox3Ls/00ZkLcGkuubZi1kc5ojOdZ0gHAZulPn+ioWPhv95c4O+J X9Tv/jCtND9FIX3w4FzTfO+NRbPx+Ykt7HKjWZy5sdGcaNxc7zIHPeZ8mhQns8hG0wq1WuDDL/W3 jxcA/QmReL9pPlneers++RagX1mvL10zjzaaxc//5h5vYeU6Hlk0X6IunG8Abqagl95BGwpmO8zN omE/jyBiPlzrh/Ffm82iWRJzW83t+DH62vpFmPMaQn7qS/h9Pj14oWng+fVmw1wDbtP8M7rPyiY5 slJgRGKLSlvt+TOUpnOuE0mKPnNGgXsLUFfodnORu+g378KcN0ltf8HJfX7yBHl+ptm0S+v1Z1j1 HxXwaXoWIoMWcL6hOszqVXnSG23zUIIf8vyXeGqxWVo4SF68Cc/f2cBJRrhCnjfNq9EutX8M2h+r iT/GstI5Jd2cXQYfKQt65kjppBWjv2UsULv4tY9XG19a21b2/APceSMDmAU8x7pLGb/x9bzMpKkZ Nc5iuAgz8MBWiahHTkJXPphSe/jYGEO0/ybcb25gbTdlzXWskOdXKfanv2HwM8nzZrFFj9wJB8FD 8OUzhheK8CRRwmkwgdPdbVS5c0S7f3UzTuBE+9WzrPrXcoU3dwOJHeZczC9fW4Gzo4bklHzNGZUd NROemk9dqWJvAkKdby7MwRfg4fLrJ/D3+2DgT7QDheo8ud5ssHJXnv+b86r5jeO24qPsYVYS0GJc NC7ky1wS1PJhlMaxM3DQFulhUCFAgcDIiXaMFjlxYedgOEQQUEhG8IECshDRegMwXtWEV6KH/2Tf 4yNnZiU7VkpJq/lY8n3/3u/FM2ECrGs2Eh7LoKlZ/CorwT34iz/z9tR2e2DPPpx67FYOXLE6cw/g 7v7p6XMQNL2JIHvdukMNu75Hy+H3yJ06GOtWp2d4lmtIFkfXm5E2Onm5qevgEV7w0UKGdgePg789 AQ/wj+/D3X0uDOLcTQJ5YFUzLh7dCbKh5gV/JPpTwsgLc4PUtpAX3e5cVRRq9JxWn+3hyKeJqz2c BkjxQfgmSf8zee42mT5dd3uoI8N8ZfVYeLS8zlL98/EwRcLhsAMM75VeONw8DsKnwfJNFP83aq4P SNNvgYX1wonMaAb1pPWgDfSwkB1horAjV0ThkiyffPFtcGZMuIOI5Cjln5ubW5FcPQ97joLtH4xG igThiGORs0VqFdHHO6PKC8J7eP3iZA/jHtkRWodux2x4+Gqnb+1ff4kHHGGGTnpCi8LDpULjQlGc R7iSN3kUbsfCT3yo83tzgyd+ElyRYn6GWb+PBGeTxN+8QsdjcfZUHhaNgLwCcGV2TXic01xZjl0R 19yEOp/OVDhxchxswAYKPcvNsAZ8mB7B7p2Nm5PPX2IfxzJIrG44knNWl9TJCzmORyD3NmhVDO4i UMGEgwHVYYT3nuDTx3D5AIRrrAF88HJnc+P3X+58DHj34xOLmbg3IhOJLCGUyJG7exLdZKwm70Ay APGPvscYY2SfzrBlgyxBwoPbVwIzb//5s2f+1R/fne5v3pzc2Np4z6PwB5734YuIjT2FNLJJOKMp QqK48IjnhhsryWmYsnvB3TAXhnont08nf7camOreZDrFhNv4w5XffQpun/xpa2Pn1dPJxLlhLGlC blsC1pErRhdpGSK2kQU9scco886BIS0mj6HPAa2bTu8pNZsrcMaN9z56/8Pp9F9bKPzKXzY2r2NQ BvYayblFKyOBLHpZQ3avsWpOr/ciYM4eRKC7/zA+2UO32D1ik9OvMdsnAK83fjOd3PajfHNRQp0z FlGln1P7dJcNvYoIoM7w8+TA/ATjz7GctbPv4eLwqXP44L8/GUsw8vQTSPnP7mKx/XV/6/PPPri9 /4+dj18NIefkW+1lFbBsPI9VMQxZxcgpklo8wYG/1yGoPhGCbvXREKABw34knNlKoxQU3jBEFk36 FwcWN8xjMePQXFuO/O5Id2mOxAyyMebACDq8nfWX//ltFHr16lVQAFX4Jn0rYqg2RVEEqWpIszi2 OS/rnJpNTToQA4TJL+xYEhkdgeYYvc3RD1s4vm1tPhLyEAr/yXc/xykusnaT5020gJXDGWQoK2Uq PxU5vVrh/CVic+KrcwL9qJrUwr/8lCbIRwdA8h1/lV6lAMPoqspw1hjGUoL5uoo9uKAncg4suEeq lvw+JNJYEewB/rswQe4oMTO6TW9k1nfW2E/NEPKBMkJwauo/MqS94zClwo5I/oHMKrIxrSEELrhH m7sY7etOiUHFmG6jMWiNMcRiwzq0zvQ7XojIBuJBSlhsisfKd/ZYqwNgWFIqQyQgBGDmzSMAeYA4 kG6SZbS7rPoYFeN5LPldovHELmGLFiomto6go6UBNACnctmqBZS5kTAhgAowH4XxpsUQ/QDGX5fC hOnOu7wZHNwEY9Z7dq9dpUxJg6wvC76MGAc+fYGfh463UvJWLLrk7PAFYCE048ilxZTpIPHelSsn 0WM8RlzDPFZSL29yv7YyElN6WZoq+EtjKOZyZLoVkPlq6Uetsp/GLNcCtEo5+Wxz4/0TTBJt48k6 KxI+uHyokbAYKaPqEmamIujHUGU9p/cQwGUrWsPR5hFoJ+HwyEkppCAPLsRXGx+hTrKIFW2dLCW1 aXm+kbnYSySeZmgDAk46HQKI8GrC5PoiifRnIl7AO/jtOJVHJxb+35t3gwXkJVPDcKbIwiEJ0hrF gefkIZNB6smgbDcHraCYuAlAw1+cs9xx51o0dLWQsAOjpZbffIUDL70vjQSCGA0fyv6c6VoD/Loi vOeAyRotsUJqafkKnBsKIAXDr6JweLFSiEmgp+YKsq6DN69+zmLnDGWXU0iKC4YPpqOuWtIm6LBg EzkbipxrBzZCxp1Emf5UDofzjjIC7AcfYfvpGalnWL5Mk+FrdbZuOn6aIqesvZYZI3VsbpRmGsMc 8ypZHoBOt8KEOyXnXIPOroi2AmTntXXUsy5GPGgXY2Hhiuu4r8yMlKSIi5DFFyjIdyuzWMwFIE0i XJJH7bSW4KuuTDY2mTIwjYXt/GLEw8oI9Az2XGep/cAJTMe2ZskDqxAIKaDmVcsBRjm5xnDUoVsI rs3pC7Ho7Va1zBKeprK/sGQsC4xwV29H95SQdQtKMIPxRqwSIqJ+yHaruADUhfJSvOWCvrvIk92m ks4WEc7rc+A2rD4/wPrSN6RjV2eyi+pqdAHAnPRLeuJCnXNrJUcCgf0l0p2stMnWcGoVbtW4l64v l0fvVHjBUxdi2W6CNI0Ie3IGRlL6BcsNegEwyGJIYsvP6gT/hW1yEwcCn621s/XFezzyWHss5obK 86iw5VjKgHdLF0hHSHNMxCW3C4g1D63e7o4i29qQcOG6XOvj51edWEWo8Z72u5KaIQwocxHohXAK 3yGNwnnK4tMVhh6VybdTKRsSKkkoe7PTw8pT2A3mqswPk/7v5Ny1aO2So+0IOUuyXEBtoMUdUC4I gN7OeHI5BLxQmCaxjXP/i8smDEDPy6Yt+yDxLCfYc0KufNeKgCMcDXdo8Rl2NNVUWdUXMqhfK9im oiKvhZfxkhHofM0RY13RpLNcnWWhoLs5N51vhWwR4YRxQFm6BTjE8TyrBoLH35mDw5Uln7ui9G9d LEvcycBHU5higCQ4/BrKN0IuO6hu5fhcOnHoltBvZZXlzQi3d4EoIz2Jqpfnu/hrV5MNRAM4hmXj UM2bd7JrTC60kKYViG8ak7ypyiyr2xFyWkNQ3rBodz7S6zLSXZgbWanq8UbDQVC2vV3eqmDdqooC bkumutF3Tku22MaL1BfKVKyXl45RxxyV/Nw3kLKC5N2qKivG23MHO8Z43mF+sSj7snavSUedGYxR l97pka053fhdBmVW8njGpe0m6anEqpxmDZZV7PXNcH1JlgM2V4GbL+mR+TV2hzOyVGKqRuaEM61k Rv6yfKm7RpsKap1BnaSqycvLaD1eOitNvEQ10IFAarOmeWMIZIXwuWJ+1y/AXzw+Zm/HlosLCnMk B2lIXSNG3wI3VKxR2Fph6A09liEQgkCctG55AB+vo6O76m2Y+obFsrr3l2zAF4u6ZA06xQaBlpcW YQsIQp0tfJXBuAO7XJf1Q4XKil8X7mGZYjBeVpXymbVgG7uF77BD5aaCf4BdrM5hFtMeWM+ud0ll W2eXStLXL8ci7aMVGy4PlYDXleY85yaD3lvlFipSl83wfZYX+v8WjUtX2QjeqD3r/7Vf7TgMgzDU W4ZMzF16A2afwJfwDXIHH4CRNRtSJdRcso+2UtukCmlEO/WxgeH5I/CjQzubSuSERLgefmTNfWZ+ DtNctyJbNsIcyaxueNwY9Y0sk5gptKlJfLWxnnh/xmf043I6IQ85vk0sdrShvh+2/YnF/4Dk1Iq6 IApaZqjbpeFAzs51ww9hiMjbuGIRxJHTvRe7ghykgwMaFoVOo96W1nxr4ICph3ggdHJ0bQzx/qom ePgu8QMxgLYoiaNnVYu/4v2jBS7WXYqVCmVuZHN0cmVhbQ1lbmRvYmoNNDAwIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDk0IDAgUiAvTGVuZ3RoIDE1IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmAgHgAEGAAALAABCmVuZHN0cmVhbQ1lbmRvYmoNNDAxIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgzIDAgUiAvTGVuZ3RoIDE5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkIg4wMzAABBgAB2IAUwplbmRzdHJlYW0N ZW5kb2JqDTQwMiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA3MiAwIFIgL0xl bmd0aCAxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIOMDMwAAQYAAdi AFMKZW5kc3RyZWFtDWVuZG9iag00MDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgNzMgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YGRiQAbMLCwsrAyYgI2dgQEgwAAC3AAlCmVuZHN0cmVhbQ1lbmRvYmoNNDA0IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc0IDAgUiAvTGVuZ3RoIDI2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzCwMWAArGwMDQIABAAFlABYKZW5kc3RyZWFtDWVu ZG9iag00MDUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzEgMCBSIC9MZW5n dGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRABUzMLAzYACsDA0CA AQABTgAQCmVuZHN0cmVhbQ1lbmRvYmoNNDA2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDY5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmBkQAVMzAxYAQsDA0CAAQAA5wALCmVuZHN0cmVhbQ1lbmRvYmoNNDA3IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDcwIDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzAxYAQsrA0CAAQAA8QAQCmVuZHN0cmVhbQ1lbmRv YmoNNDA4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc1IDAgUiAvTGVuZ3Ro IDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzAxYAQsrA0CAAQAA 8QAQCmVuZHN0cmVhbQ1lbmRvYmoNNDA5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDgwIDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBkQAVMzAxYAQsrA0CAAQAA8QAQCmVuZHN0cmVhbQ1lbmRvYmoNNDEwIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDgxIDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBkQAFMzAzYAQsrA0CAAQAA9gAQCmVuZHN0cmVhbQ1lbmRvYmoN NDExIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDgyIDAgUiAvTGVuZ3RoIDI0 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAFMzAzYAQsrA0CAAQAA9gAQ CmVuZHN0cmVhbQ1lbmRvYmoNNDEyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDc5IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk QAFMzAzYAQsrA0CAAQAA9gAQCmVuZHN0cmVhbQ1lbmRvYmoNNDEzIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDc2IDAgUiAvTGVuZ3RoIDI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJYmBkQAFMzAzYAQsrA0CAAQAA9gAQCmVuZHN0cmVhbQ1lbmRvYmoNNDE0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDc3IDAgUiAvTGVuZ3RoIDIzIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAFMDDgAMwsDQIABAACgAAsKZW5k c3RyZWFtDWVuZG9iag00MTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNzgg MCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRABkzM DDgACysDQIABAAD7ABAKZW5kc3RyZWFtDWVuZG9iag00MTYgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgOTkgMCBSIC9MZW5ndGggMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGRABkzMDDgACysDQIABAAD7ABAKZW5kc3RyZWFtDWVuZG9iag00MTcgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTIwIDAgUiAvTGVuZ3RoIDI0IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAZMzAw4AAsrA0CAAQAA+wAQCmVuZHN0 cmVhbQ1lbmRvYmoNNDE4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyMSAw IFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEABTMxQ BgsrG4oEOwcDQIABAAIRACUKZW5kc3RyZWFtDWVuZG9iag00MTkgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTIyIDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJYmBkQAFMzFAGCysTigQbOwNAgAEAAcgAHwplbmRzdHJlYW0NZW5kb2Jq DTQyMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTkgMCBSIC9MZW5ndGgg MjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRAAUzMUAYLKxuKBDsHA0CA AQACEQAlCmVuZHN0cmVhbQ1lbmRvYmoNNDIxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDExNiAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgZEABTMwQmoWVgQ1Fgp2DASDAAAIaACUKZW5kc3RyZWFtDWVuZG9iag00MjIgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE3IDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzGCKhZWBjR1ZnIOTASDAAAKKAC4KZW5k c3RyZWFtDWVuZG9iag00MjMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTE4 IDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVM zGCKhZWBjR1ZnIOTASDAAAKKAC4KZW5kc3RyZWFtDWVuZG9iag00MjQgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTIzIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzGCKhZWBjR1ZnIOTASDAAAKKAC4KZW5kc3RyZWFtDWVu ZG9iag00MjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTI4IDAgUiAvTGVu Z3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQAVMzCCShZWBgY2d A0mck4UBIMAAAwQAMgplbmRzdHJlYW0NZW5kb2JqDTQyNiAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMjkgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGRAA0zMQIKFFUiwsSMJs3IwAAQYAAJ2ACoKZW5kc3RyZWFtDWVuZG9iag00 MjcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTMwIDAgUiAvTGVuZ3RoIDMw IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQANMzECChRVIsLEjCXNwMgAE GAACgQAuCmVuZHN0cmVhbQ1lbmRvYmoNNDI4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xv clNwYWNlIDEyNyAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgZEADTMxAgoUVSLCxIwlzcDIABBgAAoEALgplbmRzdHJlYW0NZW5kb2JqDTQyOSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMjQgMCBSIC9MZW5ndGggMjggL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRAA0zMQIIFzGRBEmZlYwAIMAABgQAaCmVu ZHN0cmVhbQ1lbmRvYmoNNDMwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEy NSAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEAH TMwMLKxgFhs7QpSDmQEgwAACbAAoCmVuZHN0cmVhbQ1lbmRvYmoNNDMxIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDEyNiAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgZEAHTMwMLKxgFhs7kigHA0CAAQACZAAnCmVuZHN0cmVhbQ1l bmRvYmoNNDMyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDExNSAwIFIgL0xl bmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEAHTMwMLKxgFhs7 kigHA0CAAQACZAAnCmVuZHN0cmVhbQ1lbmRvYmoNNDMzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDEwNCAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZEAHTMwMLKxgFhs7QpSDkwEgwAACeAAuCmVuZHN0cmVhbQ1lbmRvYmoNNDM0 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwNSAwIFIgL0xlbmd0aCAyOSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEAHTMwMLKxgFhs7QpSDkwEgwAAC eAAuCmVuZHN0cmVhbQ1lbmRvYmoNNDM1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDEwNiAwIFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iWJgZMAATMwwQRZWuCAbKwNAgAEAAXcAHAplbmRzdHJlYW0NZW5kb2JqDTQzNiAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMDMgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGTAAEzMLFAWKxtckJWdASDAAAHVACIKZW5kc3RyZWFt DWVuZG9iag00MzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTAwIDAgUiAv TGVuZ3RoIDI2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkwABMzDAWCytc kI2dASDAAAFlAB0KZW5kc3RyZWFtDWVuZG9iag00MzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTAxIDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmBkwAOYmOFMFlYGgAADAACwABAKZW5kc3RyZWFtDWVuZG9iag00MzkgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTAyIDAgUiAvTGVuZ3RoIDIzIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkwAeYmGEsFlYGgAADAACrABAKZW5kc3RyZWFt DWVuZG9iag00NDAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTA3IDAgUiAv TGVuZ3RoIDI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkAAImZgbsgIUV xmJjZwAIMAABogAdCmVuZHN0cmVhbQ1lbmRvYmoNNDQxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDExMiAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZAACJmYWBqyAlQ3GYudgAAgwAAJQACUKZW5kc3RyZWFtDWVuZG9iag00NDIg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTEzIDAgUiAvTGVuZ3RoIDI4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkAAImZhYGrICVDcZi52AACDAAAlAA JQplbmRzdHJlYW0NZW5kb2JqDTQ0MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMTQgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YGRgYGBiZmFlwA7YYAx2DgaAAAMAAswAJQplbmRzdHJlYW0NZW5kb2JqDTQ0NCAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTEgMCBSIC9MZW5ndGggMzEgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgYGBiZmBhZcAKGNmgDHZWBoAAAwACwwAjCmVuZHN0 cmVhbQ1lbmRvYmoNNDQ1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEwOCAw IFIgL0xlbmd0aCAzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGBgYGJm YGFlwArY2KAMFnYGgAADAAL6ACcKZW5kc3RyZWFtDWVuZG9iag00NDYgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTA5IDAgUiAvTGVuZ3RoIDMxIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBkYGBgYmZgYWXACtgYoQx2DgaAAAMAAs4AJgplbmRzdHJlYW0N ZW5kb2JqDTQ0NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMTAgMCBSIC9M ZW5ndGggMzEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgYGBiYGBmYcAK WBmhDDZ2BoAAAwACBAAeCmVuZHN0cmVhbQ1lbmRvYmoNNDQ4IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDY4IDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJYmBkYGBiZmBgYWXADtigNDsHA0CAAQACwgAlCmVuZHN0cmVhbQ1lbmRvYmoN NDQ5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDI2IDAgUiAvTGVuZ3RoIDMy IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYGBiZmBgYGFlwArY2CE0BycD QIABAAMEAC4KZW5kc3RyZWFtDWVuZG9iag00NTAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMjcgMCBSIC9MZW5ndGggMzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIliYGRgYGJmYGBgYWXACtjYITQHJwNAgAEAAwQALgplbmRzdHJlYW0NZW5kb2JqDTQ1MSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAyOCAwIFIgL0xlbmd0aCAzMiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGBgYmZgYGBhZcAK2NghNAcnA0CAAQAD BAAuCmVuZHN0cmVhbQ1lbmRvYmoNNDUyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDI1IDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBkYGJmAAIWVgasgI0dQnNwMgAEGAADCQAuCmVuZHN0cmVhbQ1lbmRvYmoNNDUzIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIyIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYGJmAAEWBuyAlQ1MsXMwAAQYAAI2ACUKZW5kc3Ry ZWFtDWVuZG9iag00NTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjMgMCBS IC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgYmYAAUYW BqyAlQ1MsXMwAAQYAAJUACYKZW5kc3RyZWFtDWVuZG9iag00NTUgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMjQgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYGRgYmYAARYWBqyAlQ1MsbEzAAQYAAK1ACcKZW5kc3RyZWFtDWVuZG9i ag00NTYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjkgMCBSIC9MZW5ndGgg MjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRgZAADJmYGrICFFUyxsTAA BBgAAZYAGwplbmRzdHJlYW0NZW5kb2JqDTQ1NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAzNCAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgZGJmgAAWBuyAlQ1EsnMwAAQYAAIsACUKZW5kc3RyZWFtDWVuZG9iag00NTggMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzUgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZoAAFlYGrICNHURycDIABBgAAuIALgplbmRz dHJlYW0NZW5kb2JqDTQ1OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzNiAw IFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmgAAW VgasgI0dRHJwMgAEGAAC4gAuCmVuZHN0cmVhbQ1lbmRvYmoNNDYwIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDMzIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJYmBkYmaAABZWBqyAjR1EcnAyAAQYAALiAC4KZW5kc3RyZWFtDWVuZG9i ag00NjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzAgMCBSIC9MZW5ndGgg MjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRigAJmFgbsgBVEsLEzAAQY AAHWAB0KZW5kc3RyZWFtDWVuZG9iag00NjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMzEgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYGRigAJmFgbsgBVEMLExAAQYAAHIABgKZW5kc3RyZWFtDWVuZG9iag00NjMgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzIgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRigAFGZgasgIUVSLCxMwAEGAABiwAeCmVuZHN0cmVh bQ1lbmRvYmoNNDY0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDIxIDAgUiAv TGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYoABZgQTBbCw Agk2dgaAAAMAAawAHwplbmRzdHJlYW0NZW5kb2JqDTQ2NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMCAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZGKAAWYWBqyAlQ1IsHMwAAQYAAH+ACUKZW5kc3RyZWFtDWVuZG9iag00NjYg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTEgMCBSIC9MZW5ndGggMjkgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRigAFmFgasgJWNnYGDjZkBIMAAAjsA LgplbmRzdHJlYW0NZW5kb2JqDTQ2NyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxMiAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg ZGKAA2YWBqyAlY2BnYOTASDAAAINAC4KZW5kc3RyZWFtDWVuZG9iag00NjggMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgOSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgZGKAA2YWBqyAlY2BnYOTASDAAAINAC4KZW5kc3RyZWFtDWVu ZG9iag00NjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNyAwIFIgL0xlbmd0 aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGKAA2YWBqyAlY2BnYOT ASDAAAINAC4KZW5kc3RyZWFtDWVuZG9iag00NzAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgOCAwIFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiWJgZGKAA2YWBuyAlY2dnYMBIMAAAf0ALAplbmRzdHJlYW0NZW5kb2JqDTQ3MSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMyAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJAAGYG7ICFlZWVjQEgwAABZQAgCmVuZHN0cmVh bQ1lbmRvYmoNNDcyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4IDAgUiAv TGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmaAAxZWBqyA jYmJiZ0BIMAAAnkAIwplbmRzdHJlYW0NZW5kb2JqDTQ3MyAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxOSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZGJmgAMWVgasgI2JiYmdASDAAAJ5ACMKZW5kc3RyZWFtDWVuZG9iag00NzQg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjAgMCBSIC9MZW5ndGggMjggL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiZoADFlYGrICNiYmJnQEgwAACeQAj CmVuZHN0cmVhbQ1lbmRvYmoNNDc1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDE3IDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk YmaAAxZWBqyAjYmJiZ0BIMAAAnkAIwplbmRzdHJlYW0NZW5kb2JqDTQ3NiAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNCAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgZGJiZoADFlYGbICNiYmJnQEgwAACvwAlCmVuZHN0cmVhbQ1l bmRvYmoNNDc3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE1IDAgUiAvTGVu Z3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkYmJmgAMWVgZsgI2J iYmdASDAAAK/ACUKZW5kc3RyZWFtDWVuZG9iag00NzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTYgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYGRiYmaAAxZWBmyAjYmJiZ0BIMAAAr8AJQplbmRzdHJlYW0NZW5kb2JqDTQ3OSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzEgMCBSIC9MZW5ndGggMjkgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiYmaAAxZWBmyAjYmJiZ0BIMAAAr8A JQplbmRzdHJlYW0NZW5kb2JqDTQ4MCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSA1NyAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg ZGJiZkAAFgYsgJUJCNgYAAIMAAI4ACAKZW5kc3RyZWFtDWVuZG9iag00ODEgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTggMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiYmJmgAMWVgZMwAZUw8TOABBgAAMVACkKZW5kc3RyZWFt DWVuZG9iag00ODIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTkgMCBSIC9M ZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiYmJmgAMWVgZM wAZUw8TOABBgAAMVACkKZW5kc3RyZWFtDWVuZG9iag00ODMgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgNTYgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGRiYmJmgAMWVgYMwMYEAuwMAAEGAAMpACsKZW5kc3RyZWFtDWVuZG9iag00 ODQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTMgMCBSIC9MZW5ndGggMzAg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRiYmJmgAMWVgYMwMYEAuwMAAEG AAMpACsKZW5kc3RyZWFtDWVuZG9iag00ODUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgNTQgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYGRiYmJmQAAWVgZ0wMYEAuwMAAEGAAMgACsKZW5kc3RyZWFtDWVuZG9iag00ODYgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTUgMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCAmYGOGBhZUAHbCAlTOwMAAEGAANrAC0KZW5k c3RyZWFtDWVuZG9iag00ODcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjAg MCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCAmYG OGBhZUAHbCAlTOwMAAEGAANrAC0KZW5kc3RyZWFtDWVuZG9iag00ODggMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgNjUgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGQCAmYGOGBhZUADbExgwM4AEGAAA4EALwplbmRzdHJlYW0NZW5k b2JqDTQ4OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0 IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA2NiAwIFIgL0xlbmd0 aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZAIBZgY4YGFAA6xgFUxs DAABBgADOQAqCmVuZHN0cmVhbQ1lbmRvYmoNNDkwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9D b2xvclNwYWNlIDY3IDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJYmBkAgFmBjhgYWVABWxgFUzsDAABBgADwQAxCmVuZHN0cmVhbQ1lbmRvYmoNNDkxIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDY0IDAgUiAvTGVuZ3RoIDMwIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkAgFmBjhgYWVABWxgFUzsDAABBgADwQAx CmVuZHN0cmVhbQ1lbmRvYmoNNDkyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDYxIDAgUiAvTGVuZ3RoIDMwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk AgFmBjhgYWVABWxgFUzsDAABBgADwQAxCmVuZHN0cmVhbQ1lbmRvYmoNNDkzIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDYyIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkAgFmBjhgYWVAAWxMEMDGABBgAAPXADIKZW5kc3RyZWFt DWVuZG9iag00OTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNjMgMCBSIC9M ZW5ndGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCAWYGBGBhZUAG bEwQwMoAEGAAA8wAMQplbmRzdHJlYW0NZW5kb2JqDTQ5NSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSA1MiAwIFIgL0xlbmd0aCAzMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiWJgZAIDZgY4YGFlQAZsEAVM7AwAAQYABBcANQplbmRzdHJlYW0NZW5kb2JqDTQ5 NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0MSAwIFIgL0xlbmd0aCAyOSAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZAIDZgY4YGFlQAZQBUxsDAABBgAD 4wAvCmVuZHN0cmVhbQ1lbmRvYmoNNDk3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDQyIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBkAgNmBjhgYWVAAmxMUMDOABBgAAQxADcKZW5kc3RyZWFtDWVuZG9iag00OTggMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDMgMCBSIC9MZW5ndGggMjkgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGQCA2YGBGBBYjOwMkEBGwNAgAEAA6gAMAplbmRzdHJl YW0NZW5kb2JqDTQ5OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0MCAwIFIg L0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIIAZgY4YGFF sBnYmOAKAAIMAARlADUKZW5kc3RyZWFtDWVuZG9iag01MDAgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCANL0NvbG9yU3BhY2UgMzggMCBSIC9MZW5ndGggMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGSCAGYGOGBhRbAZ2KDyTOwMAAEGAARtADkKZW5kc3RyZWFtDWVuZG9iag01 MDEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzkgMCBSIC9MZW5ndGggMjgg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCAGYGOGBhRbAZmGCAjQEgwAAE PwA0CmVuZHN0cmVhbQ1lbmRvYmoNNTAyIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDQ0IDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ YmBkggBGBjhgZkGwWZlggI0BIMAABAYANQplbmRzdHJlYW0NZW5kb2JqDTUwMyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0OSAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIICZgY4YEEwWWHSTGwMAAEGAARHADYKZW5kc3RyZWFt DWVuZG9iag01MDQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNTAgMCBSIC9M ZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCAmYGOGBhRTBh 0kxsDAABBgAEqQA6CmVuZHN0cmVhbQ1lbmRvYmoNNTA1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg DS9Db2xvclNwYWNlIDUxIDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmBkggJmBjhgYYEzWWHSTGwMAAEGAASfADoKZW5kc3RyZWFtDWVuZG9iag01MDYg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDggMCBSIC9MZW5ndGggMjggL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCAmYGOGBhhbHYmOCAnQEgwAAE4QA/ CmVuZHN0cmVhbQ1lbmRvYmoNNTA3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDQ1IDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk ggJmBjhgYYWx2JjggJ0BIMAABOEAPwplbmRzdHJlYW0NZW5kb2JqDTUwOCAwIG9iag08PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSA0NiAwIFIgL0xlbmd0aCAyOCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgZIIBBgRgYoYyWOCyTKwMAAEGAARCADYKZW5kc3RyZWFtDWVu ZG9iag01MDkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgNDcgMCBSIC9MZW5n dGggMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCAWYGOGBhhTLY4LJM 7AwAAQYABRkAQQplbmRzdHJlYW0NZW5kb2JqDTUxMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAzNyAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiWJgZIIBZgY4YGGFMtjgskzsDAABBgAFGQBBCmVuZHN0cmVhbQ1lbmRvYmoNNTExIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5MyAwIFIgL0xlbmd0aCAyOCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZIIBZgY4YGGF0GxMCMDOABBgAAU5AEMK ZW5kc3RyZWFtDWVuZG9iag01MTIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTkxIDAgUiAvTGVuZ3RoIDI2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk ggFmBgSAslmYEICVASDAAASXADkKZW5kc3RyZWFtDWVuZG9iag01MTMgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTg1IDAgUiAvTGVuZ3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJYmBkggNmBjhgYQVTbAhJJnYGgAADAAVvAEUKZW5kc3RyZWFtDWVu ZG9iag01MTQgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTgzIDAgUiAvTGVu Z3RoIDI5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkggNmBjhgYQVTbAhJ JnYGgAADAAVvAEUKZW5kc3RyZWFtDWVuZG9iag01MTUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTg5IDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJYmBkggNmBjhgYQWRbExIgJ0BIMAABZEARwplbmRzdHJlYW0NZW5kb2JqDTUxNiAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTAgMCBSIC9MZW5ndGggMjggL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGSCA2YGOGBhBZFsTEiAhQEgwAAFiwBE CmVuZHN0cmVhbQ1lbmRvYmoNNTE3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDE4NCAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJg ZEIAZgY4YGEFEmxIckzsDAABBgAFxQBJCmVuZHN0cmVhbQ1lbmRvYmoNNTE4IDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4MiAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIAZgY4YGEFEmxIckzsDAABBgAFxQBJCmVuZHN0cmVh bQ1lbmRvYmoNNTE5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4NyAwIFIg L0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIAZgY4YGEF EmxIckzsDAABBgAFxQBJCmVuZHN0cmVhbQ1lbmRvYmoNNTIwIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDE4OCAwIFIgL0xlbmd0aCAyOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiWJgZEIAZgY4YGFlYGBjQgbsDAABBgAF6QBLCmVuZHN0cmVhbQ1lbmRvYmoN NTIxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE5MiAwIFIgL0xlbmd0aCAy OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEICzAxwwMLAwIosxcTGABBg AAWvAEYKZW5kc3RyZWFtDWVuZG9iag01MjIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTg2IDAgUiAvTGVuZ3RoIDI4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmBkQgLMDHDAwsrAhizFxM4AEGAABhsATQplbmRzdHJlYW0NZW5kb2JqDTUyMyAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxOTQgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIliYGRCAswMcMDCysCGLMXEzgAQYAAGGwBNCmVuZHN0 cmVhbQ1lbmRvYmoNNTI0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzMyAw IFIgL0xlbmd0aCAyNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEICzAxw wMLKxoQC2BkAAgwABkEATwplbmRzdHJlYW0NZW5kb2JqDTUyNSAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAxNDcgMCBSIC9MZW5ndGggMjcgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIliYGRCAswMcMDCysaEAtgZAAIMAAZBAE8KZW5kc3RyZWFtDWVuZG9iag01 MjYgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTQ4IDAgUiAvTGVuZ3RoIDI1 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgLMDAjAwoQKWBkAAgwABZsA RAplbmRzdHJlYW0NZW5kb2JqDTUyNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFj ZSAxNDYgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIli YGRCBswMcMDChApYGQACDAAF1ABGCmVuZHN0cmVhbQ1lbmRvYmoNNTI4IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDE0NCAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiWJgZEIGzAxwwMKEClgZAAIMAAXUAEYKZW5kc3RyZWFtDWVuZG9i ag01MjkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAv SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTQ1IDAgUiAvTGVuZ3Ro IDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgbMDHDAwoQKWBkAAgwA BdQARgplbmRzdHJlYW0NZW5kb2JqDTUzMCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JT cGFjZSAxNDkgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SIliYGRCAcwMMMCCKsHEygAQYAAGCwBICmVuZHN0cmVhbQ1lbmRvYmoNNTMxIDAgb2JqDTw8IC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE1MyAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIBzAwwwIIqwcTKABBgAAYLAEgKZW5kc3RyZWFtDWVu ZG9iag01MzIgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0 NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTU0IDAgUiAvTGVu Z3RoIDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgHMDDDAgirBxMoA EGAABgsASAplbmRzdHJlYW0NZW5kb2JqDTUzMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29s b3JTcGFjZSAxNTUgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIliYGRCAcwMUMDChAZYGQACDAAGMwBKCmVuZHN0cmVhbQ1lbmRvYmoNNTM0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE1MiAwIFIgL0xlbmd0aCAyNSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIBzAxQwMKEBlgZAAIMAAYzAEoKZW5kc3RyZWFt DWVuZG9iag01MzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTUwIDAgUiAv TGVuZ3RoIDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgXMDBDAgibO xMoAEGAABmgATAplbmRzdHJlYW0NZW5kb2JqDTUzNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0v Q29sb3JTcGFjZSAxNTEgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSIliYGRCBcwMEMCCJs7EygAQYAAGaABMCmVuZHN0cmVhbQ1lbmRvYmoNNTM3IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE0MyAwIFIgL0xlbmd0aCAyNSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIFzAxgwMKEDlgZAAIMAAaSAE4KZW5kc3Ry ZWFtDWVuZG9iag01MzggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTM1IDAg UiAvTGVuZ3RoIDI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBkQgPMDCDA gi7MxMoAEGAABsUAUAplbmRzdHJlYW0NZW5kb2JqDTUzOSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxMzYgMCBSIC9MZW5ndGggMjUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGRCA8wMIMCCLszEygAQYAAGxQBQCmVuZHN0cmVhbQ1lbmRvYmoNNTQwIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzNCAwIFIgL0xlbmd0aCAyNiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIHzAwMDCwYokysDAABBgAHIgBUCmVu ZHN0cmVhbQ1lbmRvYmoNNTQxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEz MiAwIFIgL0xlbmd0aCAyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZEIH zAwMLBiCTEysDAABBgAHUABWCmVuZHN0cmVhbQ1lbmRvYmoNNTQyIDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDE4MSAwIFIgL0xlbmd0aCAxOCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiWJgZCISMDMABBgAB2UAVQplbmRzdHJlYW0NZW5kb2JqDTU0MyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxMzcgMCBSIC9MZW5ndGggNDcgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkMiccNADAQg8il97L/sLEfCGSceSDEZJkiraa1 LgyYtvbRfZWPL8AADdQAxwplbmRzdHJlYW0NZW5kb2JqDTU0NCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IA0vQ29sb3JTcGFjZSAxNDEgMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIkUiEkSwCAQhLDdNW75/2MdLxSAkwdCTMqUp1VS64YPhuba9o7lzxVgAA2X AMUKZW5kc3RyZWFtDWVuZG9iag01NDUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMTQyIDAgUiAvTGVuZ3RoIDQ1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ FIfHAQAgCMTiYcO6/7biJ4UkA3KpavSfJgkPjJi59glxJecJMAALGQCaCmVuZHN0cmVhbQ1lbmRv YmoNNTQ2IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE0MCAwIFIgL0xlbmd0 aCA0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiRTItxEAIBAEsWPxPLb/ZoFM Izm8pBATWeVTlSYD+vOYa/87YLoCDAAM6AC2CmVuZHN0cmVhbQ1lbmRvYmoNNTQ3IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzOCAwIFIgL0xlbmd0aCA0NiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiRTGxxEAIAwEseVIBkzov1rGL4mkDJTa1LEoQxNMK+77 eHilxxdgAAwDAKoKZW5kc3RyZWFtDWVuZG9iag01NDggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAN L0NvbG9yU3BhY2UgMTM5IDAgUiAvTGVuZ3RoIDQ5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJBMGHAYAgAMCwUlCWCI7/byUhGJN6nGZKpCaaHYoX42auZ/J+DP3ZAgwAEdwBDgpl bmRzdHJlYW0NZW5kb2JqDTU0OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAx NTYgMCBSIC9MZW5ndGggNDkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkEwQkC QCAAAMG1oUIn/f+rZtgMu3qcRlIgX9w+UKy0zpjvoFc+XfwCDAATwgEqCmVuZHN0cmVhbQ1lbmRv YmoNNTUwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3MiAwIFIgL0xlbmd0 aCA1MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzIURaAEAAAwbUkRSq6/1nz N28IxqRu2Z0SOU6qDS479/qnvQzn4scvwAAR9wEJCmVuZHN0cmVhbQ1lbmRvYmoNNTUxIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3MyAwIFIgL0xlbmd0aCA1MSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzI2QKAEAAAwW2FDtLB//9q5nFYDKsak5ktsB+c FqhetPl3eXj9ug5+AQYAEhIBDwplbmRzdHJlYW0NZW5kb2JqDTU1MiAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxNzEgMCBSIC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIkEwQkCQCAAAMG1SUoX9f+3muEwnGq8TNyBXHis0OwwtM6Xr7N08wsw ABG8AQQKZW5kc3RyZWFtDWVuZG9iag01NTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTY5IDAgUiAvTGVuZ3RoIDQ4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJBMEBAoAQEADBbS9EivT/v5rhME41ZQtXUBu3HZI+8NrH5Fss/dkCDAAQ4AD5CmVuZHN0cmVh bQ1lbmRvYmoNNTU0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3MCAwIFIg L0xlbmd0aCA0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzIxQEAIBAEsbnF XfovFp4JJgf4EJXIjlJp9iNIHYbm2l8c6fIEGAANsADBCmVuZHN0cmVhbQ1lbmRvYmoNNTU1IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE3NCAwIFIgL0xlbmd0aCA0NyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZGJmYGBgYWVjYmfgADEZOBlBJBcTN5Dk 4eXjB/EEmJgEGQACDAALOwCmCmVuZHN0cmVhbQ1lbmRvYmoNNTU2IDAgb2JqDTw8IC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9u ZW50IDggDS9Db2xvclNwYWNlIDE3OCAwIFIgL0xlbmd0aCA0NyAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiRTHtxEAIBDEQHF4D/03C59oVjh5IMSkTDFWtV+6NGCuPe2OdHkCDAAM mAC2CmVuZHN0cmVhbQ1lbmRvYmoNNTU3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDE3OSAwIFIgL0xlbmd0aCA0NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iRTHtxEAIBDEQHF4D/03y5NotDh5IMSkTPlb1ax0SYO59jQcw+UJMAAMxgC6CmVuZHN0cmVhbQ1l bmRvYmoNNTU4IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg NDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE4MCAwIFIgL0xl bmd0aCA0OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiQzIxw0AIBDEQLPkHPov lvtYGuPkg6SYlCkeqGpWus3BXPsYruHxBRgADdwAxQplbmRzdHJlYW0NZW5kb2JqDTU1OSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNzcgMCBSIC9MZW5ndGggNDYgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkUyLcBACAQAzFz5Az7L8ujUnL4AMREVvFShSbT LYfm2keD7+oJMAAOKwDFCmVuZHN0cmVhbQ1lbmRvYmoNNTYwIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggDS9Db2xvclNwYWNlIDE3NSAwIFIgL0xlbmd0aCA0OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiRTExwGAIAAEweWISlBC/7UC8xiMrJPkgyLJAo/eM7lQG9/fB1PXYgswAA/o AOoKZW5kc3RyZWFtDWVuZG9iag01NjEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3Bh Y2UgMTc2IDAgUiAvTGVuZ3RoIDQ5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ FMEBAoAQEEXB199QbWxx/7tihkN2SkpZhcu4eeQsb6UF398Hoc2ZAgwAEVYA8AplbmRzdHJlYW0N ZW5kb2JqDTU2MiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNjggMCBSIC9M ZW5ndGggNTEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkUwQkSgCAQBLF2VuQQ hAX+/1bKhEt2Swo8kWREssor1fbRBz6Xs/UrHAEGABNfAQ4KZW5kc3RyZWFtDWVuZG9iag01NjMg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTYwIDAgUiAvTGVuZ3RoIDQ3IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJFIjJEQAgDIRw4xWj9l+ukQfDQJEBtaV6 5sAmLi08D7FPcPXpPAEGAAr5AJoKZW5kc3RyZWFtDWVuZG9iag01NjQgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21w b25lbnQgOCANL0NvbG9yU3BhY2UgMTYxIDAgUiAvTGVuZ3RoIDQ3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJFMZLFgAQDMXQeKU+xf6Xq+4gJxQZUFvGczs2mNLKS7FPcPU5T4AB AArVAJgKZW5kc3RyZWFtDWVuZG9iag01NjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMTU5IDAgUiAvTGVuZ3RoIDQ5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJYmBkYmZgYGBhBRJsQCY7AwMHAycTExcDNw9QiJePX4BBkAkEhBgAAgwADEUAvwplbmRzdHJl YW0NZW5kb2JqDTU2NiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNTcgMCBS IC9MZW5ndGggNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkUxscRwCAAxEBx YHKm/14NeuwIIwu47+LvhkgiS4XaoGvMxdbr8AswAA3kANQKZW5kc3RyZWFtDWVuZG9iag01Njcg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA0NCAvSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTU4IDAgUiAvTGVuZ3RoIDQ2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJFMa3EQAgEASx5fDe9F8s84qEkweCIlhT plClRh8wtfbhyjy+AAMADLAAxAplbmRzdHJlYW0NZW5kb2JqDTU2OCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAxNjIgMCBSIC9MZW5ndGggMjggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIliYGSCAEYGZiY0wMKKxGFjYAAIMAAHcgBZCmVuZHN0cmVhbQ1lbmRv YmoNNTY5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQg L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE2NiAwIFIgL0xlbmd0 aCAxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIOMDMwAAQYAAdiAFMK ZW5kc3RyZWFtDWVuZG9iag01NzAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA0NCAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2Ug MTY1IDAgUiAvTGVuZ3RoIDE5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJYmBk Ig4wMzAABBgAB2IAUwplbmRzdHJlYW0NZW5kb2JqDTU3MSAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDQ0IC9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAxNjcgMCBSIC9MZW5ndGggMTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIliYGQiDjAzMAAEGAAHYgBTCmVuZHN0cmVhbQ1lbmRvYmoNNTcyIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDQgL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDE2MyAwIFIgL0xlbmd0aCAyMCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWJgZCIKMDMwMAAEGAAHXQBRCmVuZHN0cmVhbQ1lbmRv YmoNNTczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNjYg L0hlaWdodCA3NSAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAxNjQgMCBSIC9MZW5n dGggMTE1MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibSXi5KrKhBF69Q5Ahp8 4IhEEPz/v7zdjQ90klEzdUnVTGuS5e7dzSPT9D+P4Fz4HUCJTLrfEBTPskz4zwEmw8GrjxPxIosI /UsAjOEjQJArgItP3AyKviwUgri872YESGOtNci47WbQCFAWOdLCBVc3EVhHYXS0QRgLpt5DaHp0 tVpZYWyuIwIqUGarBeIgH3MZgAqUznZDoBkXEUHDZNALQM4By8xVBJXRqOXZNiydyYy55IVX+NkV kIVpi/UVFR7tSzxU0+SyHUL/rAIBqYLMwk15A+FElpiIueOnbXKNb/7QWgZXJJ0owCTAW5HcQYHV m2lGVdwpiElMU8oU0J1vZqqnHq4sSwkaPupt2pzQnXD5avV1gtPbqWIcYZKHO9LmIOW4asUMsnwD sDizMx8JqTKN1h5mu5+fo5fZyKhkjmEx8D0bnNnUxXKrxIylXGoOWNwhPCoKU0V++CmsOqTLo6mr BavzsxQCBI0PZXNXC/DfrYi5YGKZJbQxkUWLlqSEYdLr3SUCEfOj5pL0M0EsPkpER0u4nzcuKPTW FwuB91GEK/hOXBQR+wM0zMpU8KuVat4OeRcJvi94ZLil9tR0TkshLNQpF8r4kLTK/DleDLEe3rVl hghWbZOosmSn9975EKAu6YQlrTwr6pkQvPsqc77LA22RSlvnrLNaybRVNeXA87Lp/dJW3vUNmcHs oYeZNd+7WpAAALiwNmbwz7bAmXGcGOCpPwIKALCiaQefNnYYh65klP+REHazVTjJMIO6SwSsmRBC 7eY3nD1CCsitgrfBguHFCQ0R4CfTJvmG3WsQWBJelO3Tv1rqAviJiGXDnQmepwCYrgBwLwHo53BE 2HSZzFEBK8CC8eX3yc9nTQj1ikCbOaMivgOsKrJVBaxEy4EMF0jO0jZ6o2Jod4lIKTcAA8Dgj1V8 jTis+lhkwTJRNs/xdO8FL0iFTrtTwL7NoI/a4RywqVDbHIGzGIMylvUFBbOKmuEccXrJoMrIxOFn ExOEH6DBGZ7hZA4CKB9QcCmFNZEHuVDBAuFwJtxSQAjXz4unlDQtYDZf9GAhbAgavGgwhaGur5/y YfHMeQLoANA9/j6+ujuIBcDypscU6unPX/hzOZFxKKMInuOCNBHhzw3C5iYr5xXtMfzrusd1AiBa WHw5L2BBiXfqur4DQCtKhqvyjU46ivB9WZZUhk9HcM+2vdWK3xGjd+PJirIfTik3WaU0vCCCy1bB lZm8jjdPTtV4quUl/Dzg+IIID7kUeUf/+fkPT5PxymvO8wJG580cVUiI0SmBA0Fx3jg4Nni8LCgK Dlg9RVcIGp6nvrQa8TKvIAJHIIFKa/U8AZAPqIGjEz1eUtyhBjwpgTcXNRRt2345tCVvIBwC+lBC 1L/5YfDNhxIyhk40MQJHHKz/A0WXNEDOsFVJjRo4RoqyoOgMAV8uRxWz5/989AE2be+iNZydrXK+ KvsJDodN01SQs2/Ltm6qshvHDqK2gZPDWRoT7KuwXceBlzTGeLLE8ZtZ9m78NwAqmauyCmVuZHN0 cmVhbQ1lbmRvYmoNNTc0IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9T TSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiANZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdl cyANL0tpZHMgWyA1IDAgUiBdIA0vQ291bnQgMSANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vQ3Jl YXRpb25EYXRlIChEOjIwMDAwOTI0MTY1ODI1KQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVy IDQuMCBmb3IgV2luZG93cykNL01vZERhdGUgKEQ6MjAwMDA5MjQxNjU5MTMrMDknMDAnKQ0+PiAN ZW5kb2JqDXhyZWYNMCAzIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAxMDczMDggMDAwMDAgbg0K MDAwMDEwNzM3MiAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDMNL0lEWzxjNjFkN2QyZDlmMmRj OWVhY2IyMjg5MzFlZjRkNzgwYj48YzYxZDdkMmQ5ZjJkYzllYWNiMjI4OTMxZWY0ZDc4MGI+XQ0+ Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== ------=_NextPart_000_000A_01C02728.F463A500-- From rem-conf Tue Sep 26 06:27:01 2000 From rem-conf-request@es.net Tue Sep 26 06:27:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13duhW-0000NO-00; Tue, 26 Sep 2000 06:23:14 -0700 Received: from (sun2.) [202.101.139.250] by mail1.es.net with smtp (Exim 1.81 #2) id 13duhT-0000N8-00; Tue, 26 Sep 2000 06:23:12 -0700 Received: from _[184.40.213.6]_by by sun2. (SMI-8.6/SMI-SVR4) id VAA00987; Tue, 26 Sep 2000 21:14:54 +0800 From: HotStocks@aba.com Message-Id: <200009261314.VAA00987@sun2.> Received: from [103.189.225.37] by _[184.40.213.6]_by with SMTP id A0C24E1 Tue, 26 Sep 2000 09:05:02 PDT To: rem-conf@es.net Subject: RDRT CEO- EARLY PROFITS- IPO SPINOFF Mime-Version: 1.0 Content-Type: text/plain, charset="iso-8859-1" Date: Tue, 26 Sep 2000 09:22:19 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 2636 Lines: 42 Read-Rite launches Scion, a new Fibre optics company Read-rite symbol= RDRT Read-Rite CEO gets into growth By Janet Haney, CBS.MarketWatch.com Last Update: [Timestamp]NewsWatch Latest headlines SAN FRANCISCO (CBS.MW) -- Read-Rite Chief Executive Officer Alan Lowe waxed positive about the future growth prospects for the magnetic-recording-head supplier. Lowe told a crowd of investors and analysts during a presentation at the Banc of America Securities Investment Conference in San Francisco on Thursday that he expects huge unit growth potential for Read-Rite's (RDRT: news, msgs) December quarter, as well as the possibility of profitability. Lowe added that the company is hiring people as fast as it can for its wafer fabrication facility. For the September quarter, the CEO said Read-Rite has a "lot of product to ship in the last 10 days of the quarter." Additionally, Lowe talked about Read-Rite's recent formation of an independent fiber optic company called Scion Photonics which he said hopes to go public. Scion received funding from Tyco, which will make a presentation at the conference later Thursday. Janet Haney is a reporter for CBS.MarketWatch.com. Read-Rite Corp said late on Wednesday it has formed a new fibre optics company, Scion Photonics Inc, with $25 million in initial funding from Tyco Ventures and Integral Capital Partners. Read-Rite also said it was in discussions with several other interested parties for more technology and capital investments into Scion. Scion's business charter is "to design, manufacture and market high-performance optical components to the fibre optics communications market," Read-Rite said in a statement. Scion will act as a separate company, but will have access to Read-Rite's resources and manufacturing infrastructure, Read-Rite chairman Cyril Yansouni said in a statement. Read-Rite is contributing its Milpitas, California wafer fabrication plant, technical and management resources and its knowledge and experience in thin-film technology and materials science to Scion, which will be based in Milpitas. Tyco Ventures, the venture capital unit of Tyco International Ltd. , invested $15 million in Scion and also invested $15 million in Read-Rite through a private placement with the company, Tyco Ventures president Richard Kashnow said in a statement. CBS article: http://cbs.marketwatch.com/archive/20000907/news/current/screamers.htx?source=blq/yhoo&dist=yhoo For the complete streaming audio story users should access http://www.on24.com/index.html?id=36870&type=av&ref=bizwire ALWAYS DO RESEARCH BEFORE INVESTING IN ANY STOCK!!! From rem-conf Tue Sep 26 11:40:20 2000 From rem-conf-request@es.net Tue Sep 26 11:40:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13dzT7-0006cD-00; Tue, 26 Sep 2000 11:28:41 -0700 Received: from daemyung.co.kr (www.daemyung.co.kr) [210.92.79.2] by mail1.es.net with smtp (Exim 1.81 #2) id 13dzT4-0006bl-00; Tue, 26 Sep 2000 11:28:38 -0700 Date: Wed, 27 Sep 2000 03:08:20 +0900 From: donald453@bbc.co.uk Message-Id: <200009261808.DAA00933@www.daemyung.co.kr> To: donald453@bbc.co.uk Subject: Porche Boxter or Luxury Cruise Earn $$$ In Days This Works!!! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 21118 Lines: 564 Dear Friend, This really works! Have the faith, don't miss this opportunity, get involved also, and it will work for you as it does for us!!!!! Thank you for your time and interest. This email contains the ENTIRE PLAN of how YOU can make $50,000 or more in the next 90 days simply sending email! Seem impossible? Just read on and see how easy this is.... 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 that there are absolutely no laws prohibiting 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 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. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days, please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello - My name is Johnathon Rourke, I'm from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for 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 $)C toll on my business and I just couldn4 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. I am writing toshare the experience in hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months 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. But as I was saying, in December of 1997 I received this program. I didn4 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 couldn4 believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. 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 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 don4 need any money for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. 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 DON4, 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 your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won4 work if you don4 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 won4 work and you4l 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 wasn4 working. Finally, I figured it out. It wasn4 me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don4 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 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 every one of them! Remember though, the more you send out, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HERE4 HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$$$$!!!! 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 business. 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order-filling by email! ******************************************************************* The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E- COMMERCE, the information highway, the wave of the future! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 US each.) They come to you by email. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk email service companies (search for "bulk email") and have them send 25,000 - 50,000 emails for you about $49+). (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn4 this about as easy as it gets? ************************************************************ By the way there are over 50 MILLION email addresses with millions more joining the internet each year so don4 worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. ************************************************************ YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can4 sell them if you don4 order them). -- For each report, send $5.00 (US) 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! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,0004 of people who will order them >from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you4e ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name and address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. SAVE THIS LETTER Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire email to send by email to prospects. Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing; surely you can afford $20 (US) and initial bulk mailing cost. You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let4 say that you decide to start small, just to see how it goes, and we4l assume you and all those involved email out only 2,000 programs each. Let4 also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out hundreds of thousands of programs instead of 2,000. (Why stop at 2000?). 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. That4 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 just that, and more! METHOD #2: PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let4 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. Look how this small number accumulates to achieve the STAGGERING results below: 1st level--your first 10 send you $5..................................$50 2nd level--10 members from those 10 ($5 x 100).............$500 3rd level--10 members from those 100 ($5 x 1000)........$5,000 4th level--10 members from those 1000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ AMAZING ISN4 IT? 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 1004 of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan. The question is, don4 you want your name to be on the emails they will send out? * * * DON4 MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU4L BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 can4 advertise until they receive the report! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: ALWAYS SEND $5 CASH (U.S. 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 of paper write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1 "The Insider4 Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Andrew Skidmore 9379 Alexander Rd Alexander, NY 14005 USA REPORT #2 "The Insider4 Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Lars Pedersen Skejbygaardsvej 7, 1, 10 8240 Risskov Denmark REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: John Cole Werner PO Box 3281 Lihue, HI 96766 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Zac Majors 2242 E Woodchuck Way Sandy, UT 84093 ******* 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 - If you follow the instructions exactly - results WILL FOLLOW. $$$$ ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don4 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 don4, 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. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program, please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! NOthing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above-- SUCCESS will be your reward. 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 local office of the Small Business Administration (a Federal Agency) at 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities 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. ================================================ Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From rem-conf Tue Sep 26 16:57:03 2000 From rem-conf-request@es.net Tue Sep 26 16:57:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13e4Vn-0004a9-00; Tue, 26 Sep 2000 16:51:47 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13e4Vm-0004Zy-00; Tue, 26 Sep 2000 16:51:46 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA01941 for ; Tue, 26 Sep 2000 16:51:45 -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 QAA21782 for ; Tue, 26 Sep 2000 16:51:45 -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 SAA01731; Tue, 26 Sep 2000 18:51:44 -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 SAA20998; Tue, 26 Sep 2000 18:51:43 -0500 (CDT) Message-Id: <200009262351.SAA20998@agevole.cig.mot.com> Date: Tue, 26 Sep 2000 18:51:29 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: AVT List Subject: Comments on draft-ietf-avt-rtp-amr-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 4751 Lines: 123 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 =============================================================== From rem-conf Tue Sep 26 17:18:02 2000 From rem-conf-request@es.net Tue Sep 26 17:18:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13e4qZ-0005qH-00; Tue, 26 Sep 2000 17:13:15 -0700 Received: from (upiter.mag.co.il) [212.25.93.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13e4qX-0005q7-00; Tue, 26 Sep 2000 17:13:14 -0700 Received: from hGHgaAN7L (1Cust32.tnt2.league-city.tx.da.uu.net [63.24.14.32]) by upiter.mag.co.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id TLMN38FZ; Wed, 27 Sep 2000 03:13:06 +0200 DATE: 26 Sep 00 7:07:44 PM FROM: 51UL2PxUA@golferslist.com Message-ID: SUBJECT: potentially explosive Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1858 Lines: 49 Greetings: This Opportunity is Exploding on the Internet!!!! A Referral Marketing Opportunity with a Minimum Commission GUARANTEE!!! The Sooner you sign up as a Free Post launch Member, the higher your position! Anyone who signs up after you will be Your Down line! Sign-up now and you even get a chance to win a $100.00 shopping spree at DHS Club! Want A FREE Membership in the Discount Home Shopping Club? Your FREE Membership Is Ready and Waiting. Join the Fastest Growing Down line Club on the Net!!!! Join The FREE Club Shop Post Launch Program! Now, join forces with other consumers and actually consolidate your buying power by becoming a DHS Club Member, FREE! As a Club Member you will also receive a position in our Network with our FREE down line building program - Post Launch. This position will enable you to see first hand how our network marketing aspect of the Club works, without obligation, cost or risk. As a Post launch Participant (PLP), you can begin to see a network growing underneath you as a result of the efforts of your up line VIP Members. With the Club's innovative team building method - The Vertical Integration Plan, you'll see just one of the many reasons this opportunity is so different. You will also be able to view your position and line of sponsorship after you have joined as a FREE Member........No Obligation!! To get your Free Membership, type your First and Last Name in the Message Body. Mailto:derf75@n2.com?subject=sendmymembership Ride the Wave of Success!!!!!!! ******************************************************************* We apologize if this message has reached you in error. If you would like to be removed from future mailings, mailto:nitro535@etang.com?subject=remove ******************************************************************* From rem-conf Wed Sep 27 07:38:18 2000 From rem-conf-request@es.net Wed Sep 27 07:38:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13eICC-0003um-00; Wed, 27 Sep 2000 07:28:28 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13eICB-0003uc-00; Wed, 27 Sep 2000 07:28:27 -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 e8RESOZ02606 for ; Wed, 27 Sep 2000 16:28:24 +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 QAA04840 for ; Wed, 27 Sep 2000 16:28:22 +0200 (MET DST) Message-ID: <39D203BA.561299A1@era.ericsson.se> Date: Wed, 27 Sep 2000 16:27:06 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 5747 Lines: 149 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 From rem-conf Wed Sep 27 10:54:27 2000 From rem-conf-request@es.net Wed Sep 27 10:54:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13eLKq-0000Wm-00; Wed, 27 Sep 2000 10:49:36 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13eLKp-0000Wb-00; Wed, 27 Sep 2000 10:49:35 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA02336; Wed, 27 Sep 2000 10:49:33 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA18852; Wed, 27 Sep 2000 10:49:32 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id MAA11558; Wed, 27 Sep 2000 12:49:31 -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 MAA02664; Wed, 27 Sep 2000 12:49:31 -0500 (CDT) Message-Id: <200009271749.MAA02664@agevole.cig.mot.com> Date: Wed, 27 Sep 2000 12:49:23 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@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 Content-Length: 6906 Lines: 170 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 From rem-conf Thu Sep 28 12:33:57 2000 From rem-conf-request@es.net Thu Sep 28 12:33:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ejED-00019q-00; Thu, 28 Sep 2000 12:20:21 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13ejEC-00019f-00; Thu, 28 Sep 2000 12:20:20 -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 MAA19491; Thu, 28 Sep 2000 12:02:43 -0700 Message-Id: <3.0.3.32.20000928093000.00a96350@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Sep 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 Content-Length: 2182 Lines: 61 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: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Fri Sep 29 01:55:31 2000 From rem-conf-request@es.net Fri Sep 29 01:55:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13evor-0006tr-00; Fri, 29 Sep 2000 01:47:01 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13evoq-0006th-00; Fri, 29 Sep 2000 01:47:00 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id KAA27213; Fri, 29 Sep 2000 10:46: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 xma027200; Fri, 29 Sep 00 10:46:58 +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 KAA08356; Fri, 29 Sep 2000 10:46: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 KAA09608; Fri, 29 Sep 2000 10:46:52 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014456674; Fri, 29 Sep 2000 10:47:57 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014456674000002L942*@MHS> Date: Fri, 29 Sep 2000 10:47:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/29/00 10:45:25" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 4017 Lines: 152 Dear Kuntal, all, Kuntal wrote : isn't the "ERROR_PROTECTION_STREAM" (from 14496-3/Amd.1:1999 Part 3, Section 9, pp. 124), which is the error protected audio stream also a unique streamType? I contacted our audio expert Ralf Funken and he gave the reply below. M= y conclusion : an error protection stream is a special audio stream as signaled in the AudioSpecificInfo. It is not another type of stream tha= t contains audio and consequently there is no need for another unique streamType. Kind regards, Jan --------------------------- The Error Protection (EP) tool in MPEG-4 Audio Version 2 acts as an intermediate operation between the audio core coder and the MPEG-4 Syst= ems multiplexer. Each audio elementary stream coming from the audio encoder= is packed by the EP-tool (like adding CRC checks, applying interleaving, applying FEC coding etc.) and transferred to the multiplexer. All information required to decode the EP protected audio stream is contain= ed in the packed EP elementary stream itself; there is no specific channel fo= r EP side-information or whatsoever. The usage of the EP-tool is signaled by the AudioSpecificInfo data (thi= s is the audio-related header information which is transmitted at the start = of each elementary stream). In the AudioSpecificInfo, the epConfig field signals if and how the EP-tool must be used. The use of the EP-tool does not affect the audio object type indication= in a stream. The audio object type determines the audio encoding/decoding algorithm. Whether you use EP or not is signaled separately, see above.= The indication of profile@level defines limits on whether a MPEG-4 rece= iver must implement the EP-decoder or not. Some levels allow the EP-tool to = be used, others do not. --------------------------- ************************ 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 ************************ -----Original Message----- From: sampat@miel.mot.com [mailto:sampat@miel.mot.com] Sent: vrijdag, 22 september, 2000 04:51 To: Jan vanderMeer Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Subject: Re: Types of MPEG-4 streams over IP Jan, isn't the "ERROR_PROTECTION_STREAM" (from 14496-3/Amd.1:1999 Part 3, Section 9, pp. 124), which is the error protected audio stream also a unique streamType? -Kuntal. DSP Group, Motorola, India. On Thu, 21 Sep 2000 jan.vandermeer@philips.com wrote: > Dear all, > > I would like to verify my understanding on the types of MPEG-4 stream= s that > need tools for transport over IP. I summarized my understanding by th= e > following list : > > - 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 > > For MP4 files only a standard MIME type is required. For all other st= reams > also use of RTP and SDP need to be defined. Please correct me if I am= wrong. > > The framework document (Singer et al) indicates that also a MIME type= is > needed for an MPEG-4 MuxCodeTable. Is this required indeed, or can we= assume > (/require) that the MuxCodeTable is transported inside the same FlexM= ux > stream (in a packet with simple mode). This could provide an easy sol= ution > for the timing of applicability of the table that would need to be resolved > otherwise when using e.g. HTTP; however it would require MuxCodeTable= to > become a new entry in the table for streamType values, right ? > > 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 Sat Sep 30 02:14:33 2000 From rem-conf-request@es.net Sat Sep 30 02:14:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fISF-00021Z-00; Sat, 30 Sep 2000 01:57:11 -0700 Received: from (ns.) [210.104.124.1] by mail1.es.net with smtp (Exim 1.81 #2) id 13fISD-00021N-00; Sat, 30 Sep 2000 01:57:09 -0700 Received: from _[251.214.117.146]_by by ns. (SMI-8.6/SMI-SVR4) id LAA19197; Wed, 27 Sep 2000 11:30:03 +0900 From: HotStock@masterone.com Message-Id: <200009270230.LAA19197@ns.> Received: from [17.77.182.111] by _[251.214.117.146]_by with SMTP id A77C26E8 Tue, 26 Sep 2000 22:10:59 PDT To: rem-conf@es.net Subject: Why So Much Smart Money Is So High on Read-Rite !! Mime-Version: 1.0 Content-Type: text/plain, charset="iso-8859-1" Date: Tue, 26 Sep 2000 22:28:15 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 4697 Lines: 97 Commentary: Herb on TheStreet.com -------------------------------------------------------------------------------- Why So Much Smart Money Is So High on Read-Rite By Herb Greenberg Senior Columnist 9/26/00 6:30 AM ET Read-Rite(symbol= RDRT) Feeling benevolent, so let's get bullish: Reading right: As I've written in RealMoney.com's Columnist Conversation, the one stock quite a few of my smartest sources are yapping about is Read-Rite (RDRT:Nasdaq - news - boards), the (until very recently) long-forgotten maker of heads for disk drives. The only reason I take it seriously is because of the variety of investors in the stock (from seasoned and savvy traders to some of the most-dogged researchers I know). Most of the sizzle surrounding the company in recent weeks has been tied to the launch of a new division called Scion Photonics, which is developing optical wafers for use in the fiber-optic networks, and which was initially funded with $25 mil from Tyco Ventures and Roger McNamee's Integral Capital, which got a quarter of the company in return. But that's only part of the story: According to Scott Turkel of TCM Partners, who has had his share of hits and misses in this column, and who also happens to be the only on-the-record holder among my sources, the company without Scion is worth about where it trades today, $10.50, or around 1 times sales. "They're completely sold out in their core business in the fourth quarter," he says, "and for the first time, they have pricing power." (One reason is that disk drives are no longer sold mostly for PCs; they've become a staple in storage networks.) Scion, meanwhile, is currently valued at around $100 million (based on Tyco/Integral's 25% stake). "Chump change," says Turkel. That's because the valuation is without even having a marketable product; the first wafer isn't expected to hit the market until next year (which, I should point out, is why some skeptics are, uh, skeptical). But another very sharp manager I know, who is often short stocks, said he saw Read-Rite at several recent conferences, and "I thought the story got better between Salomon Smith Barney and Banc of America, both on the optics side and on their base business. They actually showed a slide of the optical wafer prototype they had made; they said they are sampling product with several customers. They said, Our customers have said, 'If you can make them, we'll buy them.' In other words, the move to optical is less theoretical than it was a month ago." What's more, according to this money manger, who is great at spotting nuances, "They went from saying, 'We'll be break-even cash flow in Q-4 from core businesses,' to saying, 'We are on allocation and we may actually make money in Q4' from the core business.' " Based on that, Turkel (who first bought the stock when it was $4 not long ago) thinks he now owns a $10 stock that is worth $25. P.S.: Read-Rite recently paid the first installment of interest on a convertible bond with cash, rather than stock, which was an alternative. (The cash came from the State of Wisconsin Investment Board, already a large Read-Rite investor.) Translation to some investors: The only reason the state paid with cash is because it thinks the stock is going higher. Or, put another way, Wisconsin, which already owns a 20% stake, wouldn't have sunk in even more cash if it didn't think it would make a decent return. (Did I really write something that glowing? Must be some kind of a market top!) (Voluntary Disclosure: Position- Long) Read-Rite CEO gets into growth By Janet Haney, CBS.MarketWatch.com Last Update: [Timestamp]NewsWatch Latest headlines SAN FRANCISCO (CBS.MW) -- Read-Rite Chief Executive Officer Alan Lowe waxed positive about the future growth prospects for the magnetic-recording-head supplier. Lowe told a crowd of investors and analysts during a presentation at the Banc of America Securities Investment Conference in San Francisco on Thursday that he expects huge unit growth potential for Read-Rite's (RDRT: news, msgs) December quarter, as well as the possibility of profitability. Lowe added that the company is hiring people as fast as it can for its wafer fabrication facility. For the September quarter, the CEO said Read-Rite has a "lot of product to ship in the last 10 days of the quarter." Additionally, Lowe talked about Read-Rite's recent formation of an independent fiber optic company called Scion Photonics which he said hopes to go public. Scion received funding from Tyco, which will make a presentation at the conference later Thursday. Janet Haney is a reporter for CBS.MarketWatch.com. From rem-conf Sat Sep 30 14:08:42 2000 From rem-conf-request@es.net Sat Sep 30 14:08:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fTnM-00035m-00; Sat, 30 Sep 2000 14:03:44 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13fTnL-00035c-00; Sat, 30 Sep 2000 14:03:43 -0700 Received: from BMRC.Berkeley.EDU (opus.cs.berkeley.edu [128.32.131.116]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id NAA28111; Sat, 30 Sep 2000 13:59:29 -0700 Message-ID: <39D65431.4B814FBC@BMRC.Berkeley.EDU> Date: Sat, 30 Sep 2000 13:59:29 -0700 From: "Lawrence A. Rowe" Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: openmash Subject: Open Mash Multicast Workshop videos published Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Length: 1065 Lines: 25 Hi everyone - It is not perfect yet - no Berkeley Lecture Browser (BLB) until we finish a set of database/UI changes we are making to BIBS to support miscellaneous lectures - but I have published the video+slides from the Open Mash Workshop. The workshop material is available at http://www.openmash.org/events/00workshop You'll have to flip slides yourself while watching the video. Once the In addition, I want to announce that we have *finally* hired one of the full-time staff programmers for the project. His name is Lloyd Lim. He will be making a big difference once he gets up to speed. NO, NO, don't try to hire him away :)! Watch the consortium website over the next couple of months - we should start to make some visible progress. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry