From rem-conf Mon Nov 01 06:10:36 1999 From rem-conf-request@es.net Mon Nov 01 06:10:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11iI0P-0000fk-00; Mon, 1 Nov 1999 06:00:17 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11iI0M-0000fY-00; Mon, 1 Nov 1999 06:00:16 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23665; Mon, 1 Nov 1999 08:59:55 -0500 (EST) Message-Id: <199911011359.IAA23665@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: Guidelines for Writers of RTP Payload Format Specifications to BCP Date: Mon, 01 Nov 1999 08:59:55 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'Guidelines for Writers of RTP Payload Format Specifications' as a BCP. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document provides guidelines for how to design efficient formats for carrying payloads in RTP packets. The document emphasizes the importance of keeping each packet as self-contained as possible, so that packets remain useful even in the presence of loss and reordering. The discussion is in terms of codec payloads, but the principles apply to most other forms of RTP payloads, too. Working Group Summary The goal of this document was to capture discussion which occurred over the course of many AVT meetings regarding functions that an RTP pyaload format should provide. The document was revised twice to address working group comments. There were no controversial issues remaining regarding the present draft. Protocol Quality The document was reviewed for the IESG by Scott Bradner and Vern Paxson. From rem-conf Mon Nov 01 08:40:35 1999 From rem-conf-request@es.net Mon Nov 01 08:40:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11iKQO-0002cz-00; Mon, 1 Nov 1999 08:35:16 -0800 Received: from eis-msg-014.jpl.nasa.gov [137.78.160.158] by mail1.es.net with esmtp (Exim 1.81 #2) id 11iKQN-0002cp-00; Mon, 1 Nov 1999 08:35:15 -0800 Received: from johnjs (johnjs.jpl.nasa.gov [137.78.16.133]) by eis-msg-014.jpl.nasa.gov (8.9.3/8.9.3) with SMTP id IAA29719; Mon, 1 Nov 1999 08:35:14 -0800 (PST) From: "John Schwartz" To: Cc: "Cathy Schwartz" Subject: How do I get off the email list? Date: Mon, 1 Nov 1999 08:35:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cathyms@pacbell.net would like to get off this email list. How does she do this? jjs From rem-conf Mon Nov 01 10:03:55 1999 From rem-conf-request@es.net Mon Nov 01 10:03:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11iLft-00049O-00; Mon, 1 Nov 1999 09:55:21 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11iLfr-00049E-00; Mon, 1 Nov 1999 09:55:20 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Nov 1999 17:55:02 +0000 To: rem-conf@es.net Subject: AVT agenda for Washington DC cc: casner@cisco.com, agenda@ietf.org Date: Mon, 01 Nov 1999 17:55:01 +0000 Message-ID: <9738.941478901@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Audio/Video Transport Working Group Agenda Wednesday 10th November 1999, 15:30-17:30 ========================================= - Introduction and status update 10 draft-ietf-avt-fec-08.txt draft-ietf-avt-rtp-format-guidelines-04.txt draft-ietf-avt-rtpsample-05.txt draft-ietf-avt-rtp-mib-07.txt draft-ietf-avt-tones-02.txt - RTP and the audio/video profile 30 draft-ietf-avt-rtp-new-05.txt draft-ietf-avt-profile-new-07.txt draft-ietf-avt-rtp-mime-01.txt draft-ietf-avt-rtcp-bw-00.txt draft-ietf-avt-rtp-interop-02.txt draft-ietf-avt-rtptest-02.txt - RTP Payload Format for Real-Time Pointers draft-ietf-avt-pointer-00.txt (Civanlar) 5 - RTP Payload for text conversation draft-ietf-avt-rtp-text-02.txt (Hellstrom) 5 - RTP Payload Format for DV Format Video draft-ietf-avt-dv-video-01.txt (Kobayashi) 10 - RTP Payload Format for 12 bits, 20bits and 24 bits DV Audio draft-ietf-avt-dv-audio-00.txt (Kobayashi) 10 - A RTCP-based Retransmission Protocol for Unicast RTP Streaming Multimedia draft-podolsky-avt-rtprx-00.txt (Yano) 10 - RTP Payload Format for MPEG-2 AAC Streams draft-ietf-avt-rtp-mpeg2aac-01.txt (Basso) 10 - A More Loss-Tolerant RTP Payload Format for MP3 Audio draft-ietf-avt-rtp-mp3-01.txt (Finlayson) 10 - Extension of RTP payload Type for Multiple Program MPEG Transport Stream draft-ietf-avt-rtp-mp2t-00.txt (sent to list) (Liu) 10 Thursday 11th November 1999, 09:00-11:30 ======================================== - Transport of MPEG-4 draft-ietf-avt-rtp-mpeg4-02.txt (Basso) 5 draft-guillemot-genrtp-01.txt (Christ) 5 draft-jnb-mpeg4av-rtp-00.txt (Kikuchi) 5 Liason statement from MPEG (29n3290.zip) draft-singer-rtp-qtfile-01.txt Discussion 45 - Multiplexing draft-koren-avt-crtp-enhance-00.txt (Thompson) 10 draft-tulai-avt-dynamic-nx64-00.txt (Tulai) 10 Discussion 30 - Charter Bashing 10 The documents mentioned are available from: http://www.ietf.org/html.charters/avt-charter.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/IETF46/internet-drafts/ NOTE to presenters: The purpose of these slots on the AVT schedule is not to present what's in the draft, but to identify what problems were resolved, or what issues still remain open, and to make it clear what action from the working group is requested so we can discuss it. Please confirm with us that you will be able to make the presentations listed. NOTE to attendees: Since the presenters aren't supposed to present their drafts, it follows that the attendees are responsible for having read the drafts already or they may be disappointed! At the Oslo meeting, we had too many brand new drafts to cover so we did not have adequate time for discussion. We'll try to manage that more carefully this time. We also plan to hold a separate design team meeting to discuss transport of MPEG-4. Those who would be interested in attending such a meeting should contact us so we can arrange for a room. This is for those who have been active in the discussion of MPEG-4 and the MPEG-4 payload format - we will report back to the rest of the group during the Thursday session. Colin & Steve From rem-conf Mon Nov 01 13:05:32 1999 From rem-conf-request@es.net Mon Nov 01 13:05:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11iOaA-0006wX-00; Mon, 1 Nov 1999 13:01:38 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11iOa6-0006wM-00; Mon, 1 Nov 1999 13:01:35 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Nov 1999 21:01:06 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id UAA02648 for ; Mon, 1 Nov 1999 20:45:54 GMT Message-Id: <199911012045.UAA02648@cperkins-d.cs.ucl.ac.uk> To: rem-conf@es.net Subject: RTP A/V profile interoperability draft Date: Mon, 01 Nov 1999 20:45:54 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached is draft-ietf-avt-profile-interop-00.txt, the interoperability statement for the RTP audio/video profile which missed the I-D deadline. This complements draft-ietf-avt-rtp-interop-02.txt. As Steve has noted previously: >In addition, this is a request to RTP implementors to fill in the >interoperability checklist that we will need to accompany the drafts >for advancement to Draft Standard. We've made the same request >informally before, but this time we're asking that you do this in the >next two weeks so that we can have at least a first-pass tally at the >meeting. If it looks like there are features for which we don't have >two interoperable implementations, we may have to remove those >features from the draft, or do some additional implementation and >interop testing! We also need implementation reports for the a/v profile, as detailed by this draft. I would encourage implementors to complete this checklist and the checklist for the main RTP specification. Colin ------------------------------------------------------------------------------- INTERNET-DRAFT 28 October 1999 Colin Perkins University College London RTP Audio/Video Profile Interoperability Statement draft-ietf-avt-profile-interop-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Comments are solicited and should be addressed to the author and/or the IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. Abstract It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. 1 Introduction The Internet standards process [1] places a number of requirements on a standards track protocol specification. In particular, when advancing a protocol from proposed standard to draft standard it is necessary to demonstrate at least two independent and interoperable implementations, from different code bases, of all options and features of that protocol. Further, in cases where one or more options or features have not been demonstrated in at least two interoperable Perkins Page 1 INTERNET-DRAFT 28 October 1999 implementations, the specification may advance to the draft standard level only if those options or features are removed. The RTP Profile for Audio and Video Conferences with Minimal Control was originally specified in RFC1890 as a proposed standard [2]. The revision of this specification for draft standard status is now well underway, so it has become necessary to conduct such an interoperability demonstration. This memo describes the set of features and options of the RTP Audio/Video profile which need to be tested as a basis for this demonstration. This memo is for information only and does not specify a standard of any kind. 2 Features and options required to demonstrate interoperability In order to demonstrate interoperability it is required to produce a statement of interoperability for each feature noted below. Such a statement should note the pair of implementations tested, including version numbers, and a pass/fail statement for each feature. It is not expected that every implementation will implement every feature, but each feature needs to be demonstrated by some pair of applications. The RTP specification [3] enumerates a number of items that can be specified or modified by a profile. Those modified from the defaults by the audio/video profile are as follows, and interoperable behaviour must be demonstrated: 1.Exchange of RTCP packets with the default RTCP reporting interval. 2.Exchange of RTCP packets with a modified RTCP reporting interval as selected by a different fraction of the session bandwidth (the means by which this interval is signalled are outside of the scope of this memo, but one such mechanism should be demonstrated). 3.Implementations must send RTCP packets containing an SDES CNAME in every reporting interval. 4.Other SDES items must be sent every third interval, with NAME every 7 of 8 times within that slot and any other SDES items cycically taking up the 8th slot. 5.Interoperable selection of `pass phrase' for encryption and exchange of media using DES encryption. This must include mapping of the pass phrase to the canonical form. 6.Interoperable transport of RTP via unicast UDP 7.Interoperable transport of RTP via multicast UDP 8.Interoperable transport of RTP via TCP using the encapsulation defined in section 7 of [2]. Perkins Page 2 INTERNET-DRAFT 28 October 1999 The primary purpose of the audio/video profile is to define the mapping >from payload format to payload type number. Accordingly, the majority of the work needed to demonstrate interoperability consists of testing that media data is exchanged in an interoperable manner using the full range of codecs enumerated in the profile. The following codecs are assigned static payload types. It should be verified that interoperable implementations exist for each static payload type: 1.The 8kHz PCMU codec (payload type 0) 2.The 8kHz 1016 codec (payload type 1) 3.The 8kHz G726-32 codec (payload type 2) 4.The 8kHz GSM codec (payload type 3) 5.The 8kHz G723 codec (payload type 4) 6.The 8kHz DVI4 codec (payload type 5) 7.The 16kHz DVI4 codec (payload type 6) 8.The 8kHz LPC codec (payload type 7) 9.The 8kHz PCMA codec (payload type 8) 10.The 8kHz G722 codec (payload type 9) 11.The 44.1kHz stereo L16 codec (payload type 10) 12.The 44.1kHz mono L16 codec (payload type 11) 13.The 8kHz QCELP codec (payload type 12) 14.The 8kHz CN codec (payload type 13) 15.The MPA codec (payload type 14) 16.The 8kHz G728 codec (payload type 15) 17.The 11.025kHz DVI4 codec (payload type 16) 18.The 22.050kHz DVI4 codec (payload type 17) 19.The 8kHz G729 codec (payload type 18) The following codecs use dynamic payload types. It should be verified that some non-RTP means can be used to assign a dynamic payload type to be used by implementations, and that those implementations can then interwork. 1.The GSM-HR codec 2.The GSM-EFR codec Perkins Page 3 INTERNET-DRAFT 28 October 1999 3.The L8 codec 4.The RED codec 5.The VDVI codec Similarly, interoperable implementation of the following video codecs with static payload type numbers must be demonstrated: 1.The CelB codec (payload type 25) 2.The JPEG codec (payload type 26) 3.The nv codec (payload type 28) 4.The H261 codec (payload type 31) 5.The MPV codec (payload type 32) 6.The MP2T codec (payload type 33) 7.The H263 codec (payload type 34) The following codecs use dynamic payload types. It should be verified that some non-RTP means can be used to assign a dynamic payload type to be used by implementations, and that those implementations can then interwork. 1.The BT656 codec 2.The H263-1998 codec 3.The MP1S codec 4.The MP2P codec 5.The BMPEG codec Implementations must also demonstrate interoperable use of the marker bit. That is, the M bit is set on the first packet of each talkspurt for audio and on the last packet of each frame for video. 3 Author's Address Colin Perkins Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom Email: c.perkins@cs.ucl.ac.uk Perkins Page 4 INTERNET-DRAFT 28 October 1999 4 References [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', RFC2026, Internet Engineering Task Force, October 1996. [2] H. Schulzrinne, S. Casner, ``RTP Profile for Audio and Video Conferences with Minimal Control'', RFC1890, Internet Engineering Task Force, January 1996. [3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A Transport Protocol to Real-Time Applications'', RFC1889, Internet Engineering Task Force, January 1996. Perkins Page 5 From rem-conf Mon Nov 01 16:08:08 1999 From rem-conf-request@es.net Mon Nov 01 16:08:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11iRS5-0001Vm-00; Mon, 1 Nov 1999 16:05:29 -0800 Received: from shattuck.cs.berkeley.edu [128.32.130.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 11iRS3-0001Vc-00; Mon, 1 Nov 1999 16:05:27 -0800 Received: (from podolsky@localhost) by shattuck.CS.Berkeley.EDU (8.9.3/8.9.1) id QAA00431; Mon, 1 Nov 1999 16:05:26 -0800 (PST) Date: Mon, 1 Nov 1999 16:05:26 -0800 (PST) Message-Id: <199911020005.QAA00431@shattuck.CS.Berkeley.EDU> From: Matt Podolsky To: rem-conf@es.net CC: Koichi Yano , Steve McCanne Subject: RTCP-based Retransmissions for Unicast RTP Streams Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello- I'd like to announce the availability of draft-podolsky-avt-rtprx-00.txt, written by Koichi Yano, Steve McCanne, and myself. It's a first cut at creating a standard format for doing retransmissions of unicast RTP streams. We're very interested in getting feedback from the group and improving it. It can be found on the IETF website at: http://search.ietf.org/internet-drafts/draft-podolsky-avt-rtprx-00.txt The abstract is below. Koichi and I will also be at the IETF next week, and we have a slot in Wednesday's session for discussion. Thanks, Matt ---------------------------------------------------------------------- Abstract: This note defines a retransmission request protocol for use with unicast Real Time Protocol (RTP) multimedia sessions. We refer to this protocol as RTPRx. The protocol is defined as a new RTCP type and is flexible enough to allow a variety of retransmission request and response schemes. This note describes the basic format for retransmission requests, and provides examples of three different retransmission request-response algorithms which use different methods to determine if retransmissions should be requested and whether the requests should be served. From rem-conf Tue Nov 02 04:10:04 1999 From rem-conf-request@es.net Tue Nov 02 04:10:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11icfF-0007X8-00; Tue, 2 Nov 1999 04:03:49 -0800 Received: from (futuralink.it) [195.31.162.66] by mail1.es.net with smtp (Exim 1.81 #2) id 11icfC-0007Wy-00; Tue, 2 Nov 1999 04:03:47 -0800 Received: from iutit (38.26.183.135) by futuralink.it (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 02 Nov 1999 13:16:50 +0100 Date: Tue, 02 Nov 1999 13:16:50 +0100 Message-ID: To: jhfuy@aol.com Bcc: shrager@gte.net, compartsmn@earthlink.net, larrylw@att.net, writerman@att.net, jlower@ameritech.net, robert@telalink.net, chevyboy@earthlink.net, bhbe@ix.netcom.com, tmcgee@att.net, pfry@iols.net, esia@flash.net, jvanvliet@mv.igs.net, larrylw@fia.net, alberich@communique.net, lkmussat@gte.net, canter@altavista.net, rem-conf@es.net From: Subject: Take Control of Your Life content-length: 834 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am looking for a special person with a good work Ethic and an extraordinary desire who wants to earn $3000-$5000 per week in 30-45 days "THIS IS NOT MULTI-LEVEL MARKETING" We will give you the training and personal support you will need to ensure your success. WORK FROM THE PRIVACY OF YOUR OWN HOME If you are skeptical or you have tried things in the past that failed to live up to their promises, I guarantee this is different from anything else you have seen. LEARN THE STRATAGIES OF THE ULTRA RICH Call now and find out just how easy it is to get started. Don't let this opportunity pass you by. If I can do this... so can you!! *EARN $3000-$5000 PER WEEK WITHIN 30-45 DAYS. *PART-TIME. FROM HOME. NO SELLING. *NO MEETINGS. NOT MLM. *FREE INFO 24 HOUR MESSAGE CALL 1-416-410-7530 rem - thc99@popmail.com From rem-conf Tue Nov 02 21:53:04 1999 From rem-conf-request@es.net Tue Nov 02 21:53:03 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 11itGF-0005Rt-00; Tue, 2 Nov 1999 21:47:07 -0800 Received: from 11-116.015.popsite.net ([198.79.106.116] helo=ygkxcwje.pgerman) by mail2.es.net with smtp (Exim 1.92 #1) id 11itG9-0005RT-00; Tue, 2 Nov 1999 21:47:02 -0800 To: ramus@es.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT From: dfkghdgdo@chgxubjbn.exit.de Date: Sun, 04 Jul 1999 10:46:58 -0800 Message-Id: Subject: FREE Pager-No Hidden Cost -ihwkx X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE PAGER Get a top of the Line Brand New pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check Put Free pagers on your kids Give one to your wife Paging America is going to give you a top of the line full featured pager in your choice of color for FREE. This top viewable display pager is one of the smallest and lightest pagers on the market today and holds up to 32 numeric messages, has 9 music alerts or silent vibration mode, flex technology which provides three times the battery life, message time and day stamping and smart alarm so you can set a daily or weekly reminder. This pager comes in black, teal (green) and blue. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. Airtime for this pager is only $9.95 per month billed monthly or only $8.95 per month if we bill your credit card or checking account each month. Just call the toll free number and we'll ship your Free pager to you immediately in your choice of color already programmed with a local telephone number for your town. For immediate delivery call Paging America 24 hours a day at 800-443-0596 To Be removed from our e-mail list call 888-248-2594 From rem-conf Wed Nov 03 02:43:18 1999 From rem-conf-request@es.net Wed Nov 03 02:43:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ixoP-0002hb-00; Wed, 3 Nov 1999 02:38:41 -0800 Received: from newmint.cern.ch [137.138.26.94] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ixoO-0002hE-00; Wed, 3 Nov 1999 02:38:40 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by newmint.cern.ch (8.9.3/8.9.3) with SMTP id LAA05317 for ; Wed, 3 Nov 1999 11:37:38 +0100 (MET) Received: from localhost by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA19830; Wed, 3 Nov 1999 11:37:37 +0100 Date: Wed, 3 Nov 1999 11:37:37 +0100 (MET) From: Daniel Davids To: List Mbone-WW -- Daniel Davids , rem-conf@es.net Subject: CERN MBone Announcement: Next LEPC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LEP Experiments Committee ========================= Tuesday 9 November 1999 Place: CERN Main Auditorium *** Times are UTC+1 *** Reports on the LEP machine -------------------------- 09:00 - 09:30 Status of LEP (Andy Butterworth) Reports on the LEP experiments ------------------------------ 09:30 - 10:00 OPAL (Patricia Ward) 10:00 - 10:30 ALEPH (Alain Blondel) 10:30 - 11:00 Coffee break 11:00 - 11:30 DELPHI (Jesus Marco) 11:30 - 12:00 L3 (Ghita Rahal-Callot) ---------------------------------------------------------- The MBONE Broadcast is Announced via 'sdr' as "CERN LEPC" The 'vat'&'vic' Applications will be Used with a 'ttl=127' Audio Addr 224.2.174.8 Port 31974 Video Addr 224.2.234.43 Port 53004 --------------------------------------- The Sessions are Recorded Using the 'wrtp' Applications They can be Downloaded from the following Web-Site: "http://csvod1.cern.ch/cgi-bin/nph-MBone-sessions/" --------------------------------------------------- In Case of Questions or Problems Please Contact: "multicast@noc.cern.ch" From rem-conf Wed Nov 03 08:41:27 1999 From rem-conf-request@es.net Wed Nov 03 08:41:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11j3He-00068a-00; Wed, 3 Nov 1999 08:29:14 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11j3Hd-00068Q-00; Wed, 3 Nov 1999 08:29:13 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id IAA23939; Wed, 3 Nov 1999 08:23:45 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 3 Nov 1999 16:29:12 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id IAA18061; Wed, 3 Nov 1999 08:29:11 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id IAA29596; Wed, 3 Nov 1999 08:31:18 -0800 (PST) Received: from zopf_nt-pc ([192.168.59.118]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id LAA15948; Wed, 3 Nov 1999 11:29:07 -0500 (EST) Message-Id: <4.2.0.58.19991103105910.00aadc90@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 03 Nov 1999 11:29:29 -0500 To: wp3audio@ctd.comsat.com From: Robert Zopf Subject: CNG Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, The main concerns regarding a new CNG scheme have been the following: * the creation of a variant of G.711 would reduce the interoperability of different implementations, both within H.323 and within other applications. * a CNG scheme that remains generic for use with any codec would be more useful than if it is specific to G.711. * the implications of breaking the existing CNG mechanism and proposing a new one should be carefully considered before moving forward. * defining a CNG scheme may in some way limit the flexibility of the design of VAD/DTX systems that it would operate with. * due ITU procedures should be in place and enough time should be given for interested parties to advance their proposals. * the IETF is currently advancing the draft RTP Profile to Draft Standard at the meeting next week in Washington, DC. The main objective of this CNG work proposed by Lucent is to define a means for H.323 to provide an acceptable level of quality using Comfort Noise in an interoperable fashion for codecs (especially G.711) without built-in CNG. In VoIP, the 3 main codecs being deployed are G.711, G.723.1, and G.729A. For sessions using G.723.1, or G.729A, the built-in CNG provides an acceptable level of quality during DTX operation. However, for G.711, there is no built-in CNG, and the mechanism within RTP must be used to signal DTX and describe the background noise. In this case, currently only the energy is available, and as a result, a predictable, reliable, acceptable level of quality across different background noise conditions is not possible, especially between different vendors equipment. Of course this problem also exists for other codecs without built-in CNG, such as G.722, G.726, G.727, G.728, etc. In light of all of the above, our proposal is to define an extension to the current "energy only" scheme. This extended definition may be used to further describe the background noise. However, it's full or partial use is up to the implementation. The first byte would represent the energy in exactly the same manner it is now in RTP. The presence of additional bytes would signal additional information, the meaning of which and decoding of its parameters we would define. Ideally, this additional information would not be codec or sampling rate specific so that the scheme could continue to be used as flexibly as it is now. The current method of signalling DTX and updating the CN information would remain the same as it is now (that is, the first CN packet identifies the start of the inactive segment, and the update rate of this information after this is implementation specific). Interested parties would propose bit-stream formats (and part of this would be to define how to properly encode/decode the bit-stream to and from the parameter set), and a "preferred" means of analysis and synthesis. This preferred means would be tested against the requirements set out in the ToR to verify that at least one implementation exists that meets the ToR. We will obtain guidance from SG12 on how to best test the CNG. Based on the results, the working party group would select the best candidate, and the bit-stream format and preferred implementation would make up an appendix that could be referenced for use in protocols such as RTP. Ideally, the Audio/Video Transport Working Group of the IETF could adopt the "extended" CN in the future. Please provide any comments by the end of the week. If this is an acceptable means of moving forward, we will send out a draft ToR reflecting this approach. Best Regards, Rob. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Zopf Principal Engineer Speech Technology Group Lucent Technologies, INS Phone : (732) 578-3207 Fax : (732) 578-3213 Email : zopf@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Wed Nov 03 09:11:10 1999 From rem-conf-request@es.net Wed Nov 03 09:11:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11j3vF-0007F6-00; Wed, 3 Nov 1999 09:10:09 -0800 Received: from ns.mosaid.com [207.236.95.98] by mail1.es.net with smtp (Exim 1.81 #2) id 11j3vB-0007Eu-00; Wed, 3 Nov 1999 09:10:08 -0800 Received: from email.mosaid.com by ns.mosaid.com via smtpd (for mail1.ES.NET [198.128.3.181]) with SMTP; 3 Nov 1999 17:09:59 UT Received: from mosaid.com (MOP412.mosaid.com [10.1.6.234]) by mosaid.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA01137; Wed, 3 Nov 1999 12:09:42 -0500 (EST) Message-ID: <38206C2A.670FFC68@mosaid.com> Date: Wed, 03 Nov 1999 12:08:58 -0500 From: Robert Wood Organization: MOSAID Technologies Inc. X-Mailer: Mozilla 4.61 [en]C-CCK-MCD MOSAID Technologies Inc. (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zopf@lucent.com CC: wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: CNG References: <4.2.0.58.19991103105910.00aadc90@basset.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colleagues, The beauty of the G.711 is that almost no processing is required and packetization delay can be minimized if desired. My issue with any further complication of VAD/CNG operation in G.711 is the increased complexity required to implement. mailto:rwood@mosaid.com From rem-conf Wed Nov 03 10:10:39 1999 From rem-conf-request@es.net Wed Nov 03 10:10:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11j4pM-0000do-00; Wed, 3 Nov 1999 10:08:08 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11j4pL-0000de-00; Wed, 3 Nov 1999 10:08:07 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id KAA08996; Wed, 3 Nov 1999 10:02:40 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 3 Nov 1999 18:08:07 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id KAA13043; Wed, 3 Nov 1999 10:08:06 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id KAA04363; Wed, 3 Nov 1999 10:10:12 -0800 (PST) Received: from aguilar_nt-pc ([192.168.59.113]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id NAA21855; Wed, 3 Nov 1999 13:08:04 -0500 (EST) Message-Id: <4.2.0.58.19991103124101.00b52650@basset.eng.ascend.com> X-Sender: gaguilar@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 03 Nov 1999 13:07:56 -0500 To: Robert Wood , zopf@lucent.com From: Gerard Aguilar Subject: Re: CNG Cc: wp3audio@ctd.comsat.com, rem-conf@es.net In-Reply-To: <38206C2A.670FFC68@mosaid.com> References: <4.2.0.58.19991103105910.00aadc90@basset.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is true that G.711 is very low complexity and adding any additional processing needed in a channel must be highly scrutinized. However, in real-world VoIP systems each "Channel" is actually running much more than G.711. In fact listed below is what typically runs within each G.711 channel with estimates of actual DSP complexity. 0 - 1 MIPS -- G.711 (HW/SW) 1 - 3 MIPS -- Fax/Modem Detect 1- 3 MIPS -- DTMF Detect/Regeneration 7 - 15 MIPS -- G.165/G.168 LEC 0.25 - 2 MIPS -- VAD/CNG 0.25 - 3 MIPS -- Packet Loss Recovery ---------------------------------------------------------- 10 MIPS - 27 MIPS Therefore, if one ELECTED to incorporate an enhanced 1 MIP CNG over what exists today within RFC 1890 it would only take between 4% - 10% of the complexity required to run an actual G.711 Channel. Gerard At 12:08 PM 11/03/1999 -0500, Robert Wood wrote: >Colleagues, > > The beauty of the G.711 is that almost no processing > is required and packetization delay can be minimized > if desired. > > My issue with any further complication of VAD/CNG > operation in G.711 is the increased complexity > required to implement. > >mailto:rwood@mosaid.com From rem-conf Wed Nov 03 11:41:39 1999 From rem-conf-request@es.net Wed Nov 03 11:41:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11j6FF-00022x-00; Wed, 3 Nov 1999 11:38:57 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11j6FE-00022n-00; Wed, 3 Nov 1999 11:38:56 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA26718; Wed, 3 Nov 1999 11:37:43 -0800 (PST) Date: Wed, 3 Nov 1999 11:39:23 -0800 (Pacific Standard Time) From: Stephen Casner To: Robert Zopf cc: wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: CNG In-Reply-To: <4.2.0.58.19991103105910.00aadc90@basset.eng.ascend.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I thank Rob Zopt for his message on Comfort Noise Generator (CNG) enhancements. Let me try to provide a bit of context for the AVT working group. Rob contacted me as a result of the working group last call announcement on advancing the revision of the RFC 1890 RTP Audio/Video Profile to Draft Standard. One of the additions in that revision is a Comfort Noise (CN) payload format which is a simple one-octet message specifying the noise level. Rob asked whether changes to the comfort noise specification would still be possible at this point, and if so, what form that should take. I had seen the proposal on the ITU SG16 mailing list to provide an enhanced CNG specification which included spectral shape in addition to level. In an earlier reply to messages from Rob and others about this proposal, I said that if the CN payload format/encoding as defined in the current A/V Profile draft is not useful as it stands, then it should be replaced with something that is useful before the draft revision of RFC 1890 is published as a new RFC. I agree with Rob that it would not be a good idea to add comfort noise functions to a modified version of the PCMU/A (G.711) payload format because that would likely impair interoperability and would require similar revisions to other payload formats to add comfort noise to them. Options include: - Extending the current CN defintion as Rob described in his message. The current "energy only" specification would still be valid, but additional spectral information could be added. Receivers would know from the payload length whether the additional info was present. Does this seem like a "safe" extension that would not cause problems for existing implementations of CN as in the draft? Note that CN has not been published in an RFC, but it has been in the sequence of draft revisions for at least two years. - Leaving the existing CN as is, but adding another CNG payload format for the enhanced generator. This would avoid any compatibility issues, and would provide an opportunity to express the noise energy in a different way. However, in H.323 it would require negotiation of both CN and CNG payload formats for backward compatibility with endpoints that only implement the existing CN. For either of these options, there is a question of whether it is possible to change the comfort noise specification in the revised profile draft, and if so, how. The answer is certainly yes because the working group can decide that this function should be addressed before the draft is submitted to the IESG for IETF-wide Last Call. On the other hand, the advancement of RTP to Draft Standard is long overdue, so we'd like to avoid introducing additional delay. There may be a compromise: ask for IESG Last Call on the main RTP spec, but hold off on the profile. The RTP spec cannot be published as an RFC until the profile is also ready, but my concern is that the RTP spec is large and somewhat significant and therefore the IESG review may take some time. I'd like to get that process started. A question for the ITU folks is how much time would be required to allow the enhanced CNG proposal to be completed and tested by the speech experts to make sure it works correctly before we standardize it. This notion is well accepted within IETF. If the consensus is that a new CNG payload format should be added (leaving the existing CN unchanged), then it would be possible for the new payload format to be defined in a separate RFC just as we expect the continuing development of additional payload format RFCs for new audio and video encodings. Perhaps we could/should add words to the CN definition in the current draft to say that enhanced comfort noise payload formats are in development and will be published in future RFCs. I'd like to discuss these questions as part of the review of the RTP spec and profile status in the AVT meeting at IETF next Wednesday. Rob will be attending to participate in that discussion. -- Steve From rem-conf Wed Nov 03 11:52:27 1999 From rem-conf-request@es.net Wed Nov 03 11:52:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11j6P8-0002Gr-00; Wed, 3 Nov 1999 11:49:10 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11j6P7-0002Fx-00; Wed, 3 Nov 1999 11:49:09 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA26933; Wed, 3 Nov 1999 11:47:28 -0800 (PST) Date: Wed, 3 Nov 1999 11:49:09 -0800 (Pacific Standard Time) From: Stephen Casner To: Robert Wood , Gerard Aguilar cc: wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: CNG In-Reply-To: <4.2.0.58.19991103124101.00b52650@basset.eng.ascend.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 3 Nov 1999, Robert Wood wrote: > The beauty of the G.711 is that almost no processing > is required and packetization delay can be minimized > if desired. > > My issue with any further complication of VAD/CNG > operation in G.711 is the increased complexity > required to implement. Note that the "MBone tools" vat and RAT have implemented PCMU (G.711) encoding for a long time without any comfort noise mechanism at all. Silence suppression is still possible -- the receiver does not require an indicator at the start of silence, it just runs out of data. With the definition of the CN payload format or an enhanced CNG payload format, it is still possible for simple systems to just process the PCMU payload format packets and ignore the CN packets if that level of performance is acceptable. This high level of interoperability is an advantage of keeping the existing audio encoding payload formats separate from CN. On Wed, 3 Nov 1999, Gerard Aguilar wrote: > Therefore, if one ELECTED to incorporate an enhanced 1 MIP CNG > over what exists today within RFC 1890 it would only take between > 4% - 10% of the complexity required to run an actual G.711 Channel. Please note that RFC 1890 did not define any comfort noise scheme, only the simple silence suppression I described above. -- Steve From rem-conf Thu Nov 04 08:00:08 1999 From rem-conf-request@es.net Thu Nov 04 08:00:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jP4R-0004Sy-00; Thu, 4 Nov 1999 07:45:03 -0800 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11jP4Q-0004So-00; Thu, 4 Nov 1999 07:45:02 -0800 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 4 Nov 1999 10:44:09 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8525681F.005648CC ; Thu, 4 Nov 1999 10:42:27 -0500 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Kevin_Bruemmer@nmss.com To: casner@cisco.com cc: Robert Zopf , wp3audio@ctd.comsat.com, rem-conf@es.net Message-ID: <8525681F.005647B2.00@notes4.nmss.com> Date: Thu, 4 Nov 1999 10:45:28 -0500 Subject: Re: CNG Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would like to make three points concerning CN: 1) Who has ever implemented the CN in a real system? Whether you completely squelch audio in between talk spurts or you add in an artificial static representation of white or colored noise makes no difference on audio quality. CN was and is an ill-conceived notion. Holding on to it for legacy reasons when nobody will likely defend it use doesn't make sense. I think that the CN type should be redefined. Anyone who does use it - please respond and defend its use. 2) One of the respondants to this string indicates that the current VAD/DTX/CNG in G.729 and G.723.1 work pretty well. While they seem to work ok under nominal conditions, they suffer from some flaws: a) The g.723.1 DTX scheme will stream SID packets when you send all very low energy (no energy) Careful analysis of equation A-10 in G.723.1, Annex A will show this to be true. b) Both G.729 and G.723.1 VAD algorithms were not adequately tested with lower levels of speech The consequences are that an annoying "swooshing" sound occurs when the VAD misdetects speech as nonspeech and codes a SID. c) The DTX decision logic is flawed. Low levels of non-stationary noise (power hum) can almost completely defeat the intended packet rate reduction during nonspeech periods. If there was to be a standard for a VAD/DTX/CNG scheme for G.711, it should be mindful of these flaws. 3) Should there be a similar VAD for G.726 as well? As we begin to understand that VoIP does not really mean "Internet" telephony, it means Internet Protocol Telephony, we see that people are moving away from the low bit rate vocoders because they are not robust to ambient or non-speech sounds, they do not transport DTMF they degrade in speakerphone calls, and they do not tandem well at all (conferencing). G.726 is low complexity and half the bit rate of G.711. No, it is not 6.4 or 8.0 kbps, but I don't believe that people will put up with the poor robustness of these speech coders unless they get something for it in return (like mobility as in digital cell phones). Kevin Bruemmer Stephen Casner on 11/03/99 02:39:23 PM To: Robert Zopf cc: wp3audio@ctd.comsat.com, rem-conf@es.net (bcc: Kevin Bruemmer) Subject: Re: CNG I thank Rob Zopt for his message on Comfort Noise Generator (CNG) enhancements. Let me try to provide a bit of context for the AVT working group. Rob contacted me as a result of the working group last call announcement on advancing the revision of the RFC 1890 RTP Audio/Video Profile to Draft Standard. One of the additions in that revision is a Comfort Noise (CN) payload format which is a simple one-octet message specifying the noise level. Rob asked whether changes to the comfort noise specification would still be possible at this point, and if so, what form that should take. I had seen the proposal on the ITU SG16 mailing list to provide an enhanced CNG specification which included spectral shape in addition to level. In an earlier reply to messages from Rob and others about this proposal, I said that if the CN payload format/encoding as defined in the current A/V Profile draft is not useful as it stands, then it should be replaced with something that is useful before the draft revision of RFC 1890 is published as a new RFC. I agree with Rob that it would not be a good idea to add comfort noise functions to a modified version of the PCMU/A (G.711) payload format because that would likely impair interoperability and would require similar revisions to other payload formats to add comfort noise to them. Options include: - Extending the current CN defintion as Rob described in his message. The current "energy only" specification would still be valid, but additional spectral information could be added. Receivers would know from the payload length whether the additional info was present. Does this seem like a "safe" extension that would not cause problems for existing implementations of CN as in the draft? Note that CN has not been published in an RFC, but it has been in the sequence of draft revisions for at least two years. - Leaving the existing CN as is, but adding another CNG payload format for the enhanced generator. This would avoid any compatibility issues, and would provide an opportunity to express the noise energy in a different way. However, in H.323 it would require negotiation of both CN and CNG payload formats for backward compatibility with endpoints that only implement the existing CN. For either of these options, there is a question of whether it is possible to change the comfort noise specification in the revised profile draft, and if so, how. The answer is certainly yes because the working group can decide that this function should be addressed before the draft is submitted to the IESG for IETF-wide Last Call. On the other hand, the advancement of RTP to Draft Standard is long overdue, so we'd like to avoid introducing additional delay. There may be a compromise: ask for IESG Last Call on the main RTP spec, but hold off on the profile. The RTP spec cannot be published as an RFC until the profile is also ready, but my concern is that the RTP spec is large and somewhat significant and therefore the IESG review may take some time. I'd like to get that process started. A question for the ITU folks is how much time would be required to allow the enhanced CNG proposal to be completed and tested by the speech experts to make sure it works correctly before we standardize it. This notion is well accepted within IETF. If the consensus is that a new CNG payload format should be added (leaving the existing CN unchanged), then it would be possible for the new payload format to be defined in a separate RFC just as we expect the continuing development of additional payload format RFCs for new audio and video encodings. Perhaps we could/should add words to the CN definition in the current draft to say that enhanced comfort noise payload formats are in development and will be published in future RFCs. I'd like to discuss these questions as part of the review of the RTP spec and profile status in the AVT meeting at IETF next Wednesday. Rob will be attending to participate in that discussion. -- Steve From rem-conf Thu Nov 04 08:55:27 1999 From rem-conf-request@es.net Thu Nov 04 08:55:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jQ4e-0005qg-00; Thu, 4 Nov 1999 08:49:20 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11jQ4d-0005qU-00; Thu, 4 Nov 1999 08:49:19 -0800 Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id 659774CE52; Thu, 4 Nov 1999 11:49:13 -0500 (EST) Received: from research.att.com (rvclibretto.research.att.com [135.207.16.117]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id LAA04655; Thu, 4 Nov 1999 11:49:25 -0500 (EST) Message-ID: <3821B927.E90BF9DB@research.att.com> Date: Thu, 04 Nov 1999 11:49:45 -0500 From: Richard V Cox X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kevin_Bruemmer@nmss.com Cc: casner@cisco.com, Robert Zopf , wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: CNG References: <8525681F.005647B2.00@notes4.nmss.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Comfort Noise has been used in Circuit Multiplication Equipment for years. Its precise implementation is left up to vendors of the equipment. I believe they just supply the noise level and insert white noise, but since this information is not public, I can only speculate. Listening to speech over a loudspeaker vs on a handset is what distinguishes whether CN is needed. In an office like mine, with lots of fan noise from computers and AC/heating system, I would not need CN for listening to speech on a loudspeaker unless the background noise level at the other end was very high. On the other hand, I believe that on a handset I would draw the opposite conclusion unless the background noise was very low at the other end. The issue of the VADs in G.723.1 and G.729 not working well for low level speech is immaterial as to whether CN is needed. If they really don't work well enough for real world conditions, they would need to be improved. So, put me down as being in favor of CN generally. Rich Cox Kevin_Bruemmer@nmss.com wrote: > I would like to make three points concerning CN: > > 1) Who has ever implemented the CN in a real system? Whether you completely > squelch audio > in between talk spurts or you add in an artificial static representation of > white or colored noise makes > no difference on audio quality. CN was and is an ill-conceived notion. > Holding on to it for legacy reasons > when nobody will likely defend it use doesn't make sense. I think that the > CN type should be redefined. > Anyone who does use it - please respond and defend its use. > > 2) One of the respondants to this string indicates that the current > VAD/DTX/CNG in G.729 and G.723.1 > work pretty well. While they seem to work ok under nominal conditions, > they suffer from some flaws: > a) The g.723.1 DTX scheme will stream SID packets when you send all > very low energy (no energy) > Careful analysis of equation A-10 in G.723.1, Annex A will show this > to be true. > b) Both G.729 and G.723.1 VAD algorithms were not adequately tested > with lower levels of speech > The consequences are that an annoying "swooshing" sound occurs when > the VAD misdetects > speech as nonspeech and codes a SID. > c) The DTX decision logic is flawed. Low levels of non-stationary > noise (power hum) can almost > completely defeat the intended packet rate reduction during nonspeech > periods. > If there was to be a standard for a VAD/DTX/CNG scheme for G.711, it should > be mindful of these flaws. > > 3) Should there be a similar VAD for G.726 as well? As we begin to > understand that VoIP does not really > mean "Internet" telephony, it means Internet Protocol Telephony, we see > that people are moving away from the > low bit rate vocoders because they are not robust to ambient or non-speech > sounds, they do not transport DTMF > they degrade in speakerphone calls, and they do not tandem well at all > (conferencing). G.726 is low > complexity and half the bit rate of G.711. No, it is not 6.4 or 8.0 kbps, > but I don't believe that people will put up > with the poor robustness of these speech coders unless they get something > for it in return (like mobility as in > digital cell phones). > > Kevin Bruemmer > > Stephen Casner on 11/03/99 02:39:23 PM > > To: Robert Zopf > cc: wp3audio@ctd.comsat.com, rem-conf@es.net (bcc: Kevin Bruemmer) > Subject: Re: CNG > > I thank Rob Zopt for his message on Comfort Noise Generator (CNG) > enhancements. Let me try to provide a bit of context for the AVT > working group. > > Rob contacted me as a result of the working group last call > announcement on advancing the revision of the RFC 1890 RTP Audio/Video > Profile to Draft Standard. One of the additions in that revision is a > Comfort Noise (CN) payload format which is a simple one-octet message > specifying the noise level. Rob asked whether changes to the comfort > noise specification would still be possible at this point, and if so, > what form that should take. > > I had seen the proposal on the ITU SG16 mailing list to provide an > enhanced CNG specification which included spectral shape in addition > to level. In an earlier reply to messages from Rob and others about > this proposal, I said that if the CN payload format/encoding as > defined in the current A/V Profile draft is not useful as it stands, > then it should be replaced with something that is useful before the > draft revision of RFC 1890 is published as a new RFC. > > I agree with Rob that it would not be a good idea to add comfort noise > functions to a modified version of the PCMU/A (G.711) payload format > because that would likely impair interoperability and would require > similar revisions to other payload formats to add comfort noise to > them. > > Options include: > > - Extending the current CN defintion as Rob described in his message. > The current "energy only" specification would still be valid, but > additional spectral information could be added. Receivers would > know from the payload length whether the additional info was > present. Does this seem like a "safe" extension that would not > cause problems for existing implementations of CN as in the draft? > Note that CN has not been published in an RFC, but it has been in > the sequence of draft revisions for at least two years. > > - Leaving the existing CN as is, but adding another CNG payload > format for the enhanced generator. This would avoid any > compatibility issues, and would provide an opportunity to express > the noise energy in a different way. However, in H.323 it would > require negotiation of both CN and CNG payload formats for > backward compatibility with endpoints that only implement the > existing CN. > > For either of these options, there is a question of whether it is > possible to change the comfort noise specification in the revised > profile draft, and if so, how. The answer is certainly yes because > the working group can decide that this function should be addressed > before the draft is submitted to the IESG for IETF-wide Last Call. > > On the other hand, the advancement of RTP to Draft Standard is long > overdue, so we'd like to avoid introducing additional delay. There > may be a compromise: ask for IESG Last Call on the main RTP spec, but > hold off on the profile. The RTP spec cannot be published as an RFC > until the profile is also ready, but my concern is that the RTP spec > is large and somewhat significant and therefore the IESG review may > take some time. I'd like to get that process started. > > A question for the ITU folks is how much time would be required to > allow the enhanced CNG proposal to be completed and tested by the > speech experts to make sure it works correctly before we standardize > it. This notion is well accepted within IETF. > > If the consensus is that a new CNG payload format should be added > (leaving the existing CN unchanged), then it would be possible for the > new payload format to be defined in a separate RFC just as we expect > the continuing development of additional payload format RFCs for new > audio and video encodings. Perhaps we could/should add words to the > CN definition in the current draft to say that enhanced comfort noise > payload formats are in development and will be published in future > RFCs. > > I'd like to discuss these questions as part of the review of the RTP > spec and profile status in the AVT meeting at IETF next Wednesday. > Rob will be attending to participate in that discussion. > > -- Steve From rem-conf Thu Nov 04 09:50:20 1999 From rem-conf-request@es.net Thu Nov 04 09:50:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jQvd-00073H-00; Thu, 4 Nov 1999 09:44:05 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11jQvb-000735-00; Thu, 4 Nov 1999 09:44:03 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id JAA03802; Thu, 4 Nov 1999 09:30:00 -0800 (PST) Message-Id: <3.0.3.32.19991104093000.00b5dc80@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 04 Nov 1999 09:30:00 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/10 Application Outsourcing: The Next Big Thing on the Internet -- Peter Newman, Ensim Corporation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Application Outsourcing: The Next Big Thing on the Internet Wednesday, November 10, 1999, 1:00-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Peter Newman Ensim Corporation The current model for application distribution is deeply flawed. Customers are forced to keep track of the latest version of each software, to size their desktop machines to have sufficient power to deal with anticipated application load, and to painfully recover from hardware failures. These problems disappear overnight when applications are outsourced to Application Service Providers (ASPs). Potentially, the shift of applications from desktops to ASPs is as powerful and disruptive as the introduction of the World Wide Web. However, ASPs too face severe scaling problems in providing outsourced services to tens of thousands of customers. In this talk, we will outline these problems and describe a novel approach to solving them. --------------- The seminar is broadcast live on the Internet Mbone and as a RealNetworks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Nov 04 11:57:02 1999 From rem-conf-request@es.net Thu Nov 04 11:57:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jStD-0001I9-00; Thu, 4 Nov 1999 11:49:43 -0800 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11jStC-0001Hm-00; Thu, 4 Nov 1999 11:49:42 -0800 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 4 Nov 1999 14:48:49 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8525681F.006CB0EA ; Thu, 4 Nov 1999 14:47:11 -0500 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Kevin_Bruemmer@nmss.com To: Richard V Cox cc: casner@cisco.com, Robert Zopf , wp3audio@ctd.comsat.com, rem-conf@es.net Message-ID: <8525681F.006CAF2A.00@notes4.nmss.com> Date: Thu, 4 Nov 1999 14:50:11 -0500 Subject: Re: CNG Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Richard: Perhaps I didn't do a good enough job in the first part of my email. The "CN" type, as it exists in RTP/RTCP is ill-conceived - not the notion of comfort noise. As far as DCME, you are perhaps more aware of how much this equipment is used anymore; my impression is that it is not. And - since the implementations are proprietary and each end of the equipment is designed by the same people, the notion of specifying it in a standard, doesn't apply. Kevin Richard V Cox on 11/04/99 11:49:45 AM To: Kevin Bruemmer cc: casner@cisco.com, Robert Zopf , wp3audio@ctd.comsat.com, rem-conf@es.net Subject: Re: CNG Comfort Noise has been used in Circuit Multiplication Equipment for years. Its precise implementation is left up to vendors of the equipment. I believe they just supply the noise level and insert white noise, but since this information is not public, I can only speculate. Listening to speech over a loudspeaker vs on a handset is what distinguishes whether CN is needed. In an office like mine, with lots of fan noise from computers and AC/heating system, I would not need CN for listening to speech on a loudspeaker unless the background noise level at the other end was very high. On the other hand, I believe that on a handset I would draw the opposite conclusion unless the background noise was very low at the other end. The issue of the VADs in G.723.1 and G.729 not working well for low level speech is immaterial as to whether CN is needed. If they really don't work well enough for real world conditions, they would need to be improved. So, put me down as being in favor of CN generally. Rich Cox Kevin_Bruemmer@nmss.com wrote: > I would like to make three points concerning CN: > > 1) Who has ever implemented the CN in a real system? Whether you completely > squelch audio > in between talk spurts or you add in an artificial static representation of > white or colored noise makes > no difference on audio quality. CN was and is an ill-conceived notion. > Holding on to it for legacy reasons > when nobody will likely defend it use doesn't make sense. I think that the > CN type should be redefined. > Anyone who does use it - please respond and defend its use. > > 2) One of the respondants to this string indicates that the current > VAD/DTX/CNG in G.729 and G.723.1 > work pretty well. While they seem to work ok under nominal conditions, > they suffer from some flaws: > a) The g.723.1 DTX scheme will stream SID packets when you send all > very low energy (no energy) > Careful analysis of equation A-10 in G.723.1, Annex A will show this > to be true. > b) Both G.729 and G.723.1 VAD algorithms were not adequately tested > with lower levels of speech > The consequences are that an annoying "swooshing" sound occurs when > the VAD misdetects > speech as nonspeech and codes a SID. > c) The DTX decision logic is flawed. Low levels of non-stationary > noise (power hum) can almost > completely defeat the intended packet rate reduction during nonspeech > periods. > If there was to be a standard for a VAD/DTX/CNG scheme for G.711, it should > be mindful of these flaws. > > 3) Should there be a similar VAD for G.726 as well? As we begin to > understand that VoIP does not really > mean "Internet" telephony, it means Internet Protocol Telephony, we see > that people are moving away from the > low bit rate vocoders because they are not robust to ambient or non-speech > sounds, they do not transport DTMF > they degrade in speakerphone calls, and they do not tandem well at all > (conferencing). G.726 is low > complexity and half the bit rate of G.711. No, it is not 6.4 or 8.0 kbps, > but I don't believe that people will put up > with the poor robustness of these speech coders unless they get something > for it in return (like mobility as in > digital cell phones). > > Kevin Bruemmer > > Stephen Casner on 11/03/99 02:39:23 PM > > To: Robert Zopf > cc: wp3audio@ctd.comsat.com, rem-conf@es.net (bcc: Kevin Bruemmer) > Subject: Re: CNG > > I thank Rob Zopt for his message on Comfort Noise Generator (CNG) > enhancements. Let me try to provide a bit of context for the AVT > working group. > > Rob contacted me as a result of the working group last call > announcement on advancing the revision of the RFC 1890 RTP Audio/Video > Profile to Draft Standard. One of the additions in that revision is a > Comfort Noise (CN) payload format which is a simple one-octet message > specifying the noise level. Rob asked whether changes to the comfort > noise specification would still be possible at this point, and if so, > what form that should take. > > I had seen the proposal on the ITU SG16 mailing list to provide an > enhanced CNG specification which included spectral shape in addition > to level. In an earlier reply to messages from Rob and others about > this proposal, I said that if the CN payload format/encoding as > defined in the current A/V Profile draft is not useful as it stands, > then it should be replaced with something that is useful before the > draft revision of RFC 1890 is published as a new RFC. > > I agree with Rob that it would not be a good idea to add comfort noise > functions to a modified version of the PCMU/A (G.711) payload format > because that would likely impair interoperability and would require > similar revisions to other payload formats to add comfort noise to > them. > > Options include: > > - Extending the current CN defintion as Rob described in his message. > The current "energy only" specification would still be valid, but > additional spectral information could be added. Receivers would > know from the payload length whether the additional info was > present. Does this seem like a "safe" extension that would not > cause problems for existing implementations of CN as in the draft? > Note that CN has not been published in an RFC, but it has been in > the sequence of draft revisions for at least two years. > > - Leaving the existing CN as is, but adding another CNG payload > format for the enhanced generator. This would avoid any > compatibility issues, and would provide an opportunity to express > the noise energy in a different way. However, in H.323 it would > require negotiation of both CN and CNG payload formats for > backward compatibility with endpoints that only implement the > existing CN. > > For either of these options, there is a question of whether it is > possible to change the comfort noise specification in the revised > profile draft, and if so, how. The answer is certainly yes because > the working group can decide that this function should be addressed > before the draft is submitted to the IESG for IETF-wide Last Call. > > On the other hand, the advancement of RTP to Draft Standard is long > overdue, so we'd like to avoid introducing additional delay. There > may be a compromise: ask for IESG Last Call on the main RTP spec, but > hold off on the profile. The RTP spec cannot be published as an RFC > until the profile is also ready, but my concern is that the RTP spec > is large and somewhat significant and therefore the IESG review may > take some time. I'd like to get that process started. > > A question for the ITU folks is how much time would be required to > allow the enhanced CNG proposal to be completed and tested by the > speech experts to make sure it works correctly before we standardize > it. This notion is well accepted within IETF. > > If the consensus is that a new CNG payload format should be added > (leaving the existing CN unchanged), then it would be possible for the > new payload format to be defined in a separate RFC just as we expect > the continuing development of additional payload format RFCs for new > audio and video encodings. Perhaps we could/should add words to the > CN definition in the current draft to say that enhanced comfort noise > payload formats are in development and will be published in future > RFCs. > > I'd like to discuss these questions as part of the review of the RTP > spec and profile status in the AVT meeting at IETF next Wednesday. > Rob will be attending to participate in that discussion. > > -- Steve From rem-conf Thu Nov 04 15:51:16 1999 From rem-conf-request@es.net Thu Nov 04 15:51:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jWcu-0004ZD-00; Thu, 4 Nov 1999 15:49:08 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11jWcs-0004Z3-00; Thu, 4 Nov 1999 15:49:06 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA25791; Thu, 4 Nov 1999 15:43:38 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 4 Nov 1999 23:49:05 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA26709; Thu, 4 Nov 1999 15:49:04 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA02148; Thu, 4 Nov 1999 15:51:10 -0800 (PST) Received: from zopf_nt-pc ([192.168.37.235]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA23410; Thu, 4 Nov 1999 18:48:58 -0500 (EST) Message-Id: <4.2.0.58.19991104182339.00ae1550@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 04 Nov 1999 18:49:52 -0500 To: Kevin_Bruemmer@nmss.com, casner@cisco.com From: Robert Zopf Subject: Re: CNG Cc: wp3audio@ctd.comsat.com, rem-conf@es.net In-Reply-To: <8525681F.005647B2.00@notes4.nmss.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 See my comments below. At 10:45 AM 11/04/1999 -0500, Kevin_Bruemmer@nmss.com wrote: >I would like to make three points concerning CN: > >1) Who has ever implemented the CN in a real system? Whether you completely >squelch audio >in between talk spurts or you add in an artificial static representation of >white or colored noise makes >no difference on audio quality. CN was and is an ill-conceived notion. >Holding on to it for legacy reasons >when nobody will likely defend it use doesn't make sense. I think that the >CN type should be redefined. > Anyone who does use it - please respond and defend its use. I too interpreted the above as CNG in general, but now from your latest email I understand that you mean the CN as it exists in the profile draft. Your question then is similar to Steve's, so we now have a two part question that is very relevant : Does anyone make use of the CN today as it is defined in the draft profile, and if so, would the proposed extension cause any problems ? So far, it seems the answer to both of parts is no. >2) One of the respondants to this string indicates that the current >VAD/DTX/CNG in G.729 and G.723.1 >work pretty well. While they seem to work ok under nominal conditions, >they suffer from some flaws: > a) The g.723.1 DTX scheme will stream SID packets when you send all >very low energy (no energy) > Careful analysis of equation A-10 in G.723.1, Annex A will show this >to be true. > b) Both G.729 and G.723.1 VAD algorithms were not adequately tested >with lower levels of speech > The consequences are that an annoying "swooshing" sound occurs when >the VAD misdetects > speech as nonspeech and codes a SID. > c) The DTX decision logic is flawed. Low levels of non-stationary >noise (power hum) can almost > completely defeat the intended packet rate reduction during nonspeech >periods. >If there was to be a standard for a VAD/DTX/CNG scheme for G.711, it should >be mindful of these flaws. I agree that this VAD causes some artifacts. However, I made this reference as a comparison for the quality of CNG that may be acceptable. If the G.729 VAD/DTX operates correctly, the comfort noise produced by the CNG algorithm is adequate. Remember, the proposal is for a means to communicate the CN information, not the VAD/DTX used. >3) Should there be a similar VAD for G.726 as well? As we begin to >understand that VoIP does not really >mean "Internet" telephony, it means Internet Protocol Telephony, we see >that people are moving away from the >low bit rate vocoders because they are not robust to ambient or non-speech >sounds, they do not transport DTMF >they degrade in speakerphone calls, and they do not tandem well at all >(conferencing). G.726 is low >complexity and half the bit rate of G.711. No, it is not 6.4 or 8.0 kbps, >but I don't believe that people will put up >with the poor robustness of these speech coders unless they get something >for it in return (like mobility as in >digital cell phones). Again, the VAD that is used is left to the implementation. The redefined CN could certainly be used with G.726 as well. Rob. >Stephen Casner on 11/03/99 02:39:23 PM > >To: Robert Zopf >cc: wp3audio@ctd.comsat.com, rem-conf@es.net (bcc: Kevin Bruemmer) >Subject: Re: CNG > > > > >I thank Rob Zopt for his message on Comfort Noise Generator (CNG) >enhancements. Let me try to provide a bit of context for the AVT >working group. > >Rob contacted me as a result of the working group last call >announcement on advancing the revision of the RFC 1890 RTP Audio/Video >Profile to Draft Standard. One of the additions in that revision is a >Comfort Noise (CN) payload format which is a simple one-octet message >specifying the noise level. Rob asked whether changes to the comfort >noise specification would still be possible at this point, and if so, >what form that should take. > >I had seen the proposal on the ITU SG16 mailing list to provide an >enhanced CNG specification which included spectral shape in addition >to level. In an earlier reply to messages from Rob and others about >this proposal, I said that if the CN payload format/encoding as >defined in the current A/V Profile draft is not useful as it stands, >then it should be replaced with something that is useful before the >draft revision of RFC 1890 is published as a new RFC. > >I agree with Rob that it would not be a good idea to add comfort noise >functions to a modified version of the PCMU/A (G.711) payload format >because that would likely impair interoperability and would require >similar revisions to other payload formats to add comfort noise to >them. > >Options include: > > - Extending the current CN defintion as Rob described in his message. > The current "energy only" specification would still be valid, but > additional spectral information could be added. Receivers would > know from the payload length whether the additional info was > present. Does this seem like a "safe" extension that would not > cause problems for existing implementations of CN as in the draft? > Note that CN has not been published in an RFC, but it has been in > the sequence of draft revisions for at least two years. > > - Leaving the existing CN as is, but adding another CNG payload > format for the enhanced generator. This would avoid any > compatibility issues, and would provide an opportunity to express > the noise energy in a different way. However, in H.323 it would > require negotiation of both CN and CNG payload formats for > backward compatibility with endpoints that only implement the > existing CN. > >For either of these options, there is a question of whether it is >possible to change the comfort noise specification in the revised >profile draft, and if so, how. The answer is certainly yes because >the working group can decide that this function should be addressed >before the draft is submitted to the IESG for IETF-wide Last Call. > >On the other hand, the advancement of RTP to Draft Standard is long >overdue, so we'd like to avoid introducing additional delay. There >may be a compromise: ask for IESG Last Call on the main RTP spec, but >hold off on the profile. The RTP spec cannot be published as an RFC >until the profile is also ready, but my concern is that the RTP spec >is large and somewhat significant and therefore the IESG review may >take some time. I'd like to get that process started. > >A question for the ITU folks is how much time would be required to >allow the enhanced CNG proposal to be completed and tested by the >speech experts to make sure it works correctly before we standardize >it. This notion is well accepted within IETF. > >If the consensus is that a new CNG payload format should be added >(leaving the existing CN unchanged), then it would be possible for the >new payload format to be defined in a separate RFC just as we expect >the continuing development of additional payload format RFCs for new >audio and video encodings. Perhaps we could/should add words to the >CN definition in the current draft to say that enhanced comfort noise >payload formats are in development and will be published in future >RFCs. > >I'd like to discuss these questions as part of the review of the RTP >spec and profile status in the AVT meeting at IETF next Wednesday. >Rob will be attending to participate in that discussion. > > -- Steve > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Zopf Principal Engineer Speech Technology Group Lucent Technologies, INS Phone : (732) 578-3207 Fax : (732) 578-3213 Email : zopf@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Thu Nov 04 15:52:16 1999 From rem-conf-request@es.net Thu Nov 04 15:52:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jWfa-0004dv-00; Thu, 4 Nov 1999 15:51:54 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11jWfZ-0004dj-00; Thu, 4 Nov 1999 15:51:53 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA26124; Thu, 4 Nov 1999 15:46:25 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 4 Nov 1999 23:51:52 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA27229; Thu, 4 Nov 1999 15:51:51 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA02270; Thu, 4 Nov 1999 15:53:59 -0800 (PST) Received: from zopf_nt-pc ([192.168.37.235]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA23586; Thu, 4 Nov 1999 18:51:49 -0500 (EST) Message-Id: <4.2.0.58.19991104185025.00b6fe30@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 04 Nov 1999 18:52:29 -0500 To: Stephen Casner From: Robert Zopf Subject: Re: CNG Cc: wp3audio@ctd.comsat.com, rem-conf@es.net In-Reply-To: References: <4.2.0.58.19991103105910.00aadc90@basset.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > >A question for the ITU folks is how much time would be required to >allow the enhanced CNG proposal to be completed and tested by the >speech experts to make sure it works correctly before we standardize >it. This notion is well accepted within IETF. The target is to have an appendix in February, but the schedule needs to be worked out. It may take longer. Rob. From rem-conf Fri Nov 05 06:10:50 1999 From rem-conf-request@es.net Fri Nov 05 06:10:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jk0v-0003VB-00; Fri, 5 Nov 1999 06:06:49 -0800 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11jk0t-0003V1-00; Fri, 5 Nov 1999 06:06:47 -0800 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 5 Nov 1999 09:05:54 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256820.004D4BB6 ; Fri, 5 Nov 1999 09:04:16 -0500 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: rem-conf@es.net Message-ID: <85256820.004D4AFE.00@notes4.nmss.com> Date: Fri, 5 Nov 1999 09:07:20 -0500 Subject: Re: CNG Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The primary need for a CN or CNG packet is for G711 which has (even for 5ms) a relatively large voice packet. Therefore, even a relatively large CN packet would allow a significant data reduction. This means that, after the energy info, a large type or version field could be attached allowing a variety of algorithms, each more complex than the one before, to be announced without significantly diiminshing the usefulness of the packet for data reduction. It seems to me that this means we don't have to agonize too much or too long on the issue, just come up with one or two relatively simple algorithms of a spectral nature that some early adopters can agree on and start reaping the data reduction benefits. From rem-conf Fri Nov 05 09:31:03 1999 From rem-conf-request@es.net Fri Nov 05 09:31:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11jn20-0005yY-00; Fri, 5 Nov 1999 09:20:08 -0800 Received: from mtiwmhc06.worldnet.att.net [204.127.131.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 11jn1x-0005xG-00; Fri, 5 Nov 1999 09:20:05 -0800 Received: from oemcomputer ([63.20.46.158]) by mtiwmhc06.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991105171628.TCUL24056@oemcomputer>; Fri, 5 Nov 1999 17:16:28 +0000 From: Birdhouse Windchimes To: Message-Id: <18161.236469.50568252 remnants@vintnershipi.net> Subject: Birdhouse Windchimes ; Fantastic Holiday Gifts ! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Fri, 5 Nov 1999 17:16:28 +0000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With every breeze, you'll enjoy these charming birdhouse windchimes. Approximately 6" long, crafted of wood with metal chimes, each one of these windchimes is hand painted and highly detailed. You'll love them all. Assorted designs, let us choose one for you. Birdhouse Windchimes If you would like us to email you our selections please place (CHIMES) in subject-line of the following address prov780@cs.com (All chimes are $12.00 including shipping within the United States) Outside the United States add $4.00 U.S. Dollars Please? Allow 3 weeks for delivery. Thank you all so much!! "Craft Care" Removel return with R in subject line From rem-conf Sat Nov 06 19:09:03 1999 From rem-conf-request@es.net Sat Nov 06 19:09:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11kISu-0004ti-00; Sat, 6 Nov 1999 18:54:00 -0800 Received: from gateway.mitel.ca (semimail.semird.mitel.com) [198.53.180.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 11kISt-0004rd-00; Sat, 6 Nov 1999 18:53:59 -0800 Received: from mitel.com (ras1_127.software.mitel.com [134.199.92.127]) by semimail.semird.mitel.com (8.9.3/8.9.3) with ESMTP id VAA13337; Sat, 6 Nov 1999 21:52:10 -0500 (EST) Message-ID: <3824E96E.45DEF049@mitel.com> Date: Sat, 06 Nov 1999 21:52:31 -0500 From: Alexander Tulai X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: wp3audio@ctd.comsat.com CC: rem-conf@es.net Subject: CNG for G.711 References: <8525681F.005647B2.00@notes4.nmss.com> <3821B927.E90BF9DB@research.att.com> Content-Type: multipart/mixed; boundary="------------CBEB5BFA77E995A6F9704B48" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------CBEB5BFA77E995A6F9704B48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------CBEB5BFA77E995A6F9704B48 Content-Type: text/plain; charset=us-ascii; name="cng.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cng.txt" Dear colleagues, I would like to answer a few questions related to CNG. 1) Why ONLY a noise energy level mechanism has been so far proposed as CNG for G.711 (both ATM and IP)? Simpler and more complex VAD and CNG algorithms have been used for a long time, so clearly not a lack of of knowledge in the field prevented more sophisticated mechanism to be adopted. a/u-law PCM coders are the most popular in the world. The a/u-law PCM coders are very cheap and no royalties have to be paid by the end user. The use of sophisticated speech compression algorithms (for example those in the ITU-T series G.72x) has been limited to applications where bandwidth was at a high premium. Even so , their use has been somehow limited by the the higher cost to the end user and the reduced capability of transporting tones (DTMF, modem, etc.). More recent speech compression algorithms have been adopted with their own VAD and CNG mechanism and the ratio between the computational power required by the coder and that required by the VAD/CNG is around 5:1 or higher. To implement a PCM to linear decoder or a linear to PCM coder requires around 30 cycles/frame on a popular C5x machine. This is roughly equivalent to 0.48 MIPS for a full Compander. Some DSPs have the capability to do these operations in 1 cycle (for example Mitel's Miliwat DSP core). To implement a VAD+CNG mechanism that requires around 2 MIPS leads us to the abberation where the ratio between the coder CPU requirements and the VAD/CNG requirements are around 1:4 or worst!! If someone has 2 MIPS to spare probably has 6 as well. And if 6 MIPS are available, why wouldn't one use a toll quality 32 kbps ADPCM algorithm with no silence supression ? RFC 1889 not only allows ADPCM, but it allows for changing coders on the fly to accomodate various bandwidth needs. So, now we see that a simple VAD/CNG was used simply because it made a lot of sense to use something on the same degree of complexity (i.e. low) with the PCM coders. 2) Does anybody use the CN level cell/packet mechanism ? Yes, we do. We support the existent draft-ietf-avt-profile-new-07.txt document and we want to see it approved as an RFC without any delay. 3) How about a more sophisticated CN, for example one based on noise spectral information ? We believe there is no need for standardizing such an algorithm neither by IETF or ITU-T. However, if enough support for the adoption of such an algorithm is voiced at the next ITU-T meeting in Geneva, we are prepared to participate in the activites for defining the terms of reference of a CNG algorithm for G.711 as well as making proposals for a candidate algorithm. I would be suprised if we would see at ITU-T just two proposals. 4) How fast should the work be done ? Well , there is no question dealing with CN for G.711 . I believe G.711 is too important for everybody. We need a separate question under SG16. The ITU-T procedures for standardization are strict and well defined. In this particular case many companies may have a high interest in following the work and contribuing to it. Work can be progressed through reflector groups but the Telecommuncation community cannot be properly informed without a general meeting in Geneva. We want to make sure that everybody in this world using PCM coders has a chance to take notice of the new work proposed and a chance to contribute. Regards, Alexander Tulai Mitel Corporation Ph: (613)592-2122 Fax: (613) 592-4784 alexander_tulai@mitel.com --------------CBEB5BFA77E995A6F9704B48-- From rem-conf Sun Nov 07 14:12:20 1999 From rem-conf-request@es.net Sun Nov 07 14:12:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11kaSU-0005LI-00; Sun, 7 Nov 1999 14:06:46 -0800 Received: from badlands.nodak.edu [134.129.111.66] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11kaSS-0005L8-00; Sun, 7 Nov 1999 14:06:44 -0800 Received: from lily (lily.ece.ndsu.NoDak.edu [134.129.123.95]) by badlands.NoDak.edu (8.9.3/8.9.3) with SMTP id PAA89024; Sun, 7 Nov 1999 15:36:55 -0600 Message-Id: <3.0.3.32.19991107154208.006cd138@badlands.nodak.edu> X-Sender: msyed@badlands.nodak.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 07 Nov 1999 15:42:08 -0600 To: invited7-Multimedia-Systems-igp:; From: Mahbubur Syed Subject: Multimedia Systems-CFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [sorry for any duplication of this message] Dear Colleague: Please find below a call for chapters on Multimedia Systems. I invite you to submit a chapter. Please also circulate the CFC to your colleagues and network. Thanks for your cooperation. Mahbubur Rahman Syed --------------------------><---------------------------------- CALL FOR BOOK CHAPTERS Submissions are invited for inclusion in a forthcoming book: "Design and Management of Multimedia Information Systems: Opportunities and Challenges" to be published by Idea Group Publishing, Hershey, USA, in 2000. Editor: Syed. M. Rahman, North Dakota State University, USA (on secondment from Monash University, Australia) The objective of this book is to compile together the state-of-the-art research, design, development, implementation and management experiences in multimedia systems both in stand alone and distributed environment. This book is aimed to promote the exchange of information and ideas between academia and industry, faculty, practitioners and students. It should also be useful to students as a text for courses in the area of multimedia systems. It will include chapters from professionals, researchers and the business community. Information for authors, including topic areas, chapter organisation guidelines and the submission procedure may be found at the following locations: http://venus.ece.ndsu.nodak.edu/~msyed/mmbook/index.html http://www.gscit.monash.edu.au/~rahman/mmbook/index.html IMPORTANT DATES Expression of Interest/proposal by: 15 December 1999 Feedback on the proposal: 22 December 1999 Full Chapter due by: 28 February 2000 Notification of Review Status: 1 May 2000 Revised Chapter due by: 5 June 2000 You may send email queries to: syed.rahman@infotech.monash.edu.au msyed@badlands.nodak.edu From rem-conf Sun Nov 07 16:21:15 1999 From rem-conf-request@es.net Sun Nov 07 16:21:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11kcXA-00075Q-00; Sun, 7 Nov 1999 16:19:44 -0800 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11kcX7-00075F-00; Sun, 7 Nov 1999 16:19:42 -0800 Received: (from lanoms99@localhost) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) id WAA18008; Sun, 7 Nov 1999 22:10:10 -0200 (EDT) Date: Sun, 7 Nov 1999 22:10:09 -0200 (EDT) From: "LANOMS'99" Subject: IEEE LANOMS99 - Final Program To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl In-Reply-To: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You can see the Final Program and to register on-line via Web. ************************************************************** * You are very welcome to participate in the * * * * IEEE LANOMS99 * * * * LATIN AMERICAN NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM * * * * http://www.lrg.ufsc.br/~lanoms99/ * * * * Rio Atlantica Hotel * * Rio de Janeiro - Brazil * * December 3-5, 1999 * ************************************************************** From rem-conf Mon Nov 08 01:48:55 1999 From rem-conf-request@es.net Mon Nov 08 01:48:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11klKO-0004F4-00; Mon, 8 Nov 1999 01:43:08 -0800 Received: from tokyo.ccrle.nec.de [195.37.70.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11klKM-0004EI-00; Mon, 8 Nov 1999 01:43:07 -0800 Received: from rain (rain.heidelberg.ccrle.nec.de [192.168.102.98]) by tokyo.ccrle.nec.de (8.8.8/3.6W980303HK) with SMTP id KAA13550; Mon, 8 Nov 1999 10:29:30 +0100 (CET) Message-ID: <004b01bf29ca$19aaf4b0$6266a8c0@heidelberg.ccrle.nec.de> From: "Sibille Gralka" To: , , , , , , , , , , , , , , , , , "atm2000" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: CFP: Conference on High Performance Switching Routing in June 2000 Date: Mon, 8 Nov 1999 10:17:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tokyo.ccrle.nec.de id KAA13550 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My sincere apology if you receive multiple copies of this CFP. Please feel free to pass the CFP to anyone who might be interested. Kind regards, Sibille GralkaCall For Papers ------------------------------------------------------------------------- Conference on High Performance Switching & Routing Joint IEEE ATM Workshop 2000 and 3rd International Conference on ATM (ICATM'2000) June 26-29, 2000 Crowne Plaza Hotel, Heidelberg, Germany Sponsored by the IEEE Communication Society Supported by: VDE, EC Information Society Technologies, EURESCOM GmbH, Alcatel SEL AG, Cisco Systems GmbH, Deutsche Telekom AG, Ericsson Eurolab Deutschland GmbH, IBM Deutschland GmbH, Lucent Technologies GmnH, NEC Europe Ltd., Siemens AG For a nicely formatted version of this Call for Papers as well as for any other information related to this event please check the conference website under URL: http://www.ccrle.nec.de/heidelberg/atm2000 Conference Scope A wide variety of ATM products have been developed for local and wide-area, private and public networks. First-generation ATM public services have been deployed on a global basis and efforts are underway to implement full-service, large-scale ATM networks. Wired (xDSL, HFC) and wireless (W-ATM) access networks enabling end-to-end ATM services are becoming available. Integration between ATM and IP evolves rapidly. Researchers and practitioners are studying issues like network design, network performance and traffic engineering, network reliability and survivability, charging and tariffing, quality of service and multicast support. At the same time next generation switching and routing technologies including IP over SONET/SDH or IP over WDM are being developed, converging cell and packet switching architectures. Driving applications for integrated networks become visible, namely Virtual Private Networks (VPN), Voice over Packet (VOP) and group communication services like conferencing and video on demand (VOD). They create new requirements on network architecture and management. The purpose of the conference is to share ideas, experiences, and information among researchers, developers, and service providers in the field of data, voice and multimedia communications using ATM and other high-speed switching and routing technologies, including Gigabit/Terabit switch/routers for optical networks. Original papers are hereby solicited on such topics as (but not limited to): 1. ATM Networks 1.1. ATM/WDM Networks 1.2. Broadband Access Networks (xDSL,HFC,PON) 1.3. Wireless / Mobile ATM 1.4. Satellite-Based ATM 1.5. ATM and UMTS/IMT2000 1.6. Interworking 2. ATM Switching 2.1. ATM Switch Architectures 2.2. Large-Scale Switch Implementations and Performance 2.3. Broadcasting/Multicasting 3. Signaling and Control 3.1. Broadband Signaling 3.2. Large-scale Call Processing Architectures. 3.3. PNNI, I-PNNI 3.4. QoS Routing 3.5. Signaling Interworking (ATM, PSTN, VoIP,...) 4. Traffic Engineering 4.1. ATM Traffic Modeling 4.2. Cell and Packet Level Scheduling 4.3. UBR,VBR, ABR, CBR Performance 4.4. Traffic Engineering 4.5. Network Design and Dimensioning 4.6. Network Optimization 5. ATM/IP Integration 5.1. IP/ATM Integration: MPLS, MPOA, ... 5.2. IP Multicasting over ATM 5.3. IPv6 over ATM 5.4. TCP over ATM 5.5. IP over ATM vs. native IP 6. Integrated Services, Multimedia 6.1. Native ATM Applications and Interfaces 6.2. QoS and CoS 6.3. IntServ and Diffserv 6.4. Video Coding and Transmission 6.5. VToA, VoP, VoIP 6.6. Multimedia Traffic Characteristics 7. Management and Control 7.1. Software Architectures for Switch/Router Control 7.2. Traffic Management Functions (UPC,CAC,...) 7.3. Tariffing, Charging and Accounting 7.4. Virtual Private Networks, VLANs,... 7.5. Network/VPN Security 7.6. Survivability, Fault Tolerance, Self-Healing,... 7.7. Network and Service Management 7.8. Service Provisioning 8. Gigabit/Terabit Routers 8.1. High-Speed Packet Switching and Routing 8.2. Switching & Routing for WDM 8.3. IP over SONET/SDH and IP over WDM 8.4. MPLS over WDM 8.5. Multicast Routing 9. Real User Networks 9.1. Operational Experience 9.2. User Experiences 9.3. Business Aspects 9.4. Network Evolution 10. Alternative Technologies 10.1. DTM 10.2. Photonic Switching 10.3. others Instructions for Authors: Send an electronic version of your submission to the address below. Submissions should be extended abstracts (2000 - 3000 words) summarizing original work. All the manuscripts must be written in English. The first page of each paper should contain the title of the paper, the authors' name(s), affiliation, address, telephone and fax numbers, e-mail of the author responsible for correspondence, a list of four keywords and categories from the above list as well as a summary of up to 100 words of the main achievements in your contribution. Electronic submissions are strongly encouraged. Acceptable formats are PDF, Postscript Level 2, RTF, FrameMaker Vs.5, Word 97. Please use A4 paper format when formatting your submission! Authors of accepted papers will later be required to submit an IEEE copyright form, please assure that you have all necessary authorizations in place. Typing instructions for accepted full papers can be downloaded from http://www.vde-verlag.de. All submitted papers should be sent to the following address: Dr. Heinrich J. St=FCttgen, General Chair IEEE ATM Workshop 2000 & ICATM 2000 Computer and Communcation Research Laboratories NEC Europe Ltd. Adenauerplatz 6 D-69115 Heidelberg, Germany Phone: +49 6221 905 11-0 Fax: +49 6221 905 11-55 E-mail: ATM2000@ccrle.nec.de Important Dates: Submission of extended abstract due: January 10th, 2000 (Ext. Abstracts of approx. 5 pages or 2500 words) Authors notified: March 15th, 2000 Final camera ready papers due: April 17th, 2000 (Final papers of max. 5000 Words or 10 Pages) Tutorials: On Monday, June 26th, 2000 the workshop will begin with two half day tutorials focusing on emerging technologies in the areas of ATM, WDM Switching, IP over WDM, Gigabit Routing, IP/ATM in UMTS/IMT2000, Multimedia Communication or related subjects. Researchers interested in proposing/presenting a tutorial at ATM 2000 should contact the workshop chair via email under ATM2000@ccrle.nec.de to inquire for details. Workshop Committees General Chair (IEEE ATM Workshop) Heinrich J. St=FCttgen, C&C Research Laboratories, NEC Europe Ltd., Heidelberg, Germany General Co-Chair (ICATM) Pascal Lorenz, University Haute Alsace, Colmar, France Technical Co-Chairs Jonathan Turner, Washington University, St.Louis, USA Naoaki Yamanaka, NTT Network System Laboratories, Tokyo, Japa Organizing Committee H. Besier, Deutsche Telekom AG, Germany H. Brueggemann, EURESCOM GmbH, Germany C. Carrelli, EURESCOM GmbH, Germany W. Frohberg, Alcatel SEL AG, Germany B. Jabbari, George Mason University, USA P. Kuehn, Stuttgart University, Germany R. Rompel (Treasurer), VDE, Germany F. Sass, Siemens AG & ATM Forum, Germany S. Schaller, NEC Europe Ltd., Germany IEEE ATM Workshop Advisory Board A. Casaca, IST/INESC, Portugal G. Copeland, CSC, USA J. P. Coudreuse, Mitsubishi, France M. Decina, CEFRIEL, Italy G. Dobrowski, Ficon Technologies, USA D. Dorman, Nortel Networks, Australia B. Goode, IBM, USA R. Guerin, Univ. of Pennsylvania, USA Y. Inoue, NTT, Japan B. Jabbari, G.Mason University, USA P. K=FChn, Univ. Stuttgart, Germany A. Leon-Garcia, Univ, of Toronto, Canada L. Mason, INRS-Telecom, Canada G. Pujolle, Lab. PRISM, France J. Roberts, France Telecom, France M. Schwartz, Columbia University, USA H. Stuettgen, NEC Europe, Germany S. Suzuki, NTT, Japan S. Tohme, ENST, France R. Vickers, NORTEL, Canada S. Walters, Telcordia, USA S. Weinstein, NEC America, USA Joint Technical Program Committee D. Awduche, UUNET, USA A. Baiocchi, Univ. Rome, Italy K. Begain, Mu'tah Univ., Jordan A. Benslimane, Tech. Univ. of Belfort, France B. Bing, University of Maryland, USA C. Blondia, Univ. of Antwerp, Belgium D. Boettle, Alcatel SEL, Germany D. Bonjour, France Telecom CNET, France T. Braun, Berne University,Switzerland B. Butscher, GMD FOKUS, Germany A. Choudhury, PMC-Sierra Inc., USA O. Casals, Univ. Politecnica Catalonia, Spain P. de Sousa, DG XIII, European Commission J. Ebersp=E4cher, Tech.Univ Munich, Germany W. Fischer, Cisco, Germany K.D. Grohs, Deutsche Telekom AG, Germany J. Hayes, Concordia University, Canada R.G. Herrtwich, DaimlerChrysler, Germany B. Hirosaki, NEC, Japan Z. Hulicki, Univ. of Cracow, Poland A. Jajszczyk, ITTI Ltd. and AGH, Poland M. Karol, Bell Labs, USA R. Keller, Ericsson Eurolab, Germany U. Killat, TU Hamburg Harburg, Germany D. Kofman, ENST, France S. Komandur, Lucent Technologies, USA S. Kumar, DARPA, USA G.S. Kuo, National Central Univ., Taiwan M.M. Lee, Dongshin University, Korea F. Le Faucheur, Cisco, France P. Lorenz, Univ. Haute Alsace, France Z. Mammeri, IRIT/Univ. P.Sabatier, France N. Mastorakis, Military Institute of Univ. Educ., Greece P. Morreale, Stevens Inst. of Techn., USA M. Murata, Osaka Univ., Japan M. Nunes, IST/INESC, Portugal G. Omidyar, CSC, USA M. Pullen, G.Mason Univ., USA M. Potts, Martel, Switzerland S. Rao, Telscom AG, Switzerland E. Rathgeb, Univ. Essen, Germany G. Reali, Univ. di Perugia, Italy S. Ritzenthaler, Newbridge, France H. Saito, NTT, Japan K. Sauer, Bosch AG, Germany D. Serpanos, ICS FORTH, Greece V. Trecordi, CEFRIEL, Italy D. Tsang, Hong Kong University Hong Kong P. van Mieghem, Delft University,Netherlands R. Wille-Fier, Siemens AG, Germany L. Wolf, Tech. Univ. Darmstadt, Germany A. Wolisz, Tech. Univ. Berlin, Germany F. Yegenoglu, COMSAT Labs, USA M. Zitterbart, TU Braunschweig, Germany From rem-conf Mon Nov 08 06:25:10 1999 From rem-conf-request@es.net Mon Nov 08 06:25:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11kpgf-0006wq-00; Mon, 8 Nov 1999 06:22:25 -0800 Received: from dns.irisa.fr [131.254.254.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11kpga-0006wg-00; Mon, 8 Nov 1999 06:22:20 -0800 Received: from sleigh.irisa.fr (sleigh.irisa.fr [131.254.43.8]) by dns.irisa.fr (8.9.3/8.9.3) with ESMTP id PAA00418; Mon, 8 Nov 1999 15:21:04 +0100 (MET) From: Jean-Marc.Jezequel@irisa.fr Date: Mon, 8 Nov 1999 14:12:19 +0100 Message-Id: <199911081312.OAA23375@sleigh.irisa.fr> To: Enterprise_Architecture_Patterns_and_Components@dns.irisa.fr Subject: TE2000 Call for Contribution X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list TOOLS Europe 2000 "Enterprise Architecture - Patterns - Components" Mont St Michel & St Malo, France June 5-8, 2000 http://www.tools.com/europe CALL FOR CONTRIBUTIONS (deadline 31st January 2000) (Please accept our apologies if you receive more than one copy. Please forward this message to colleagues you think might be interested.) TOOLS is the major international conference series devoted to applications of object-oriented technology. TOOLS Europe 2000 will be held in Le Mont St Michel, at the borderline of Normandy and Brittany in the north-west of France, and will continue the commitment to excellence of earlier TOOLS conferences in Europe, Australia, Asia and the USA. The proceedings will be published world-wide by the IEEE Computer Society. PAPERS TOOLS Europe 2000 is now soliciting papers on all aspects of object-oriented technology. All submitted papers will be refereed and assessed for technical quality and usefulness to practitioners and applied researchers. TOOLS Europe particularly welcomes papers that present general findings based upon industrial experience. Such papers will be judged by the quality of their contribution to industrial best-practice (rather than to the body of research knowledge). TUTORIALS and WORKSHOPS Tutorials and workshops form an important part of TOOLS conferences. TOOLS Europe 2000 is keen to receive proposals for tutorials, workshops and panels on topics. MORE DETAILS Please visit the conference website for more details. http://www.tools.com/europe From rem-conf Mon Nov 08 19:25:59 1999 From rem-conf-request@es.net Mon Nov 08 19:25:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11l1p5-00064X-00; Mon, 8 Nov 1999 19:19:55 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11l1oy-00064H-00; Mon, 8 Nov 1999 19:19:48 -0800 Received: from localhost (ssh.cisco.com [171.69.10.34]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA05578; Mon, 8 Nov 1999 19:18:34 -0800 (PST) Date: Mon, 8 Nov 1999 19:18:23 -0800 (Pacific Standard Time) From: Stephen Casner To: Bruce_Levens@nmss.com cc: rem-conf@es.net Subject: Re: CNG In-Reply-To: <85256820.004D4AFE.00@notes4.nmss.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 5 Nov 1999 Bruce_Levens@nmss.com wrote: > The primary need for a CN or CNG packet is for G711 which has (even for > 5ms) a relatively large voice packet. Therefore, even a relatively large > CN packet would allow a significant data reduction. True. The main value of VAD is not sending any packets at all, except perhaps for a comfort noise packet of some kind at the start of silence and occasionally during the silence. > This means that, after > the energy info, a large type or version field could be attached allowing > a variety of algorithms, each more complex than the one before, to be > announced without significantly diiminshing the usefulness of the packet > for data reduction. Here I don't agree. Interoperability is a key requirement, and allowing a plethora of algorithms would most likely impair interoperability. For H.323, one would probably need/want to negotiate compatibility of the comfort noise payload format. Negotiating the payload type to be used seems like the right way to do that. It would be harder to negotiate the embedded version value you suggest. If the requirement for negotiation is valid, then there would be no additional freedom to create new methods via that path than through dynamic RTP payload type binding to new algorithm descriptors (in whatever for is used for H.323 negotiation). -- Steve From rem-conf Mon Nov 08 20:35:59 1999 From rem-conf-request@es.net Mon Nov 08 20:35:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11l2yH-0007Do-00; Mon, 8 Nov 1999 20:33:29 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11l2yF-0007De-00; Mon, 8 Nov 1999 20:33:27 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id UAA02031; Mon, 8 Nov 1999 20:27:56 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Nov 1999 04:33:26 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id UAA08246; Mon, 8 Nov 1999 20:33:25 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id UAA04629; Mon, 8 Nov 1999 20:35:37 -0800 (PST) Received: from zopf_nt-pc ([192.168.37.233]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id XAA08295; Mon, 8 Nov 1999 23:33:17 -0500 (EST) Message-Id: <4.2.0.58.19991108201739.00b84100@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 08 Nov 1999 23:34:10 -0500 To: wp3audio@ctd.comsat.com From: Robert Zopf Subject: Re: CNG for G.711 Cc: rem-conf@es.net In-Reply-To: <3824E96E.45DEF049@mitel.com> References: <8525681F.005647B2.00@notes4.nmss.com> <3821B927.E90BF9DB@research.att.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_194611276==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_194611276==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed All, I would like to respond to Alexander's comments below in the context of the proposal on the table and the application it is intended for. Please see my comments below. At 09:52 PM 11/06/1999 -0500, Alexander Tulai wrote: >Dear colleagues, > >I would like to answer a few questions related to CNG. > >1) Why ONLY a noise energy level mechanism has been >so far proposed as CNG for G.711 (both ATM and IP)? > >More recent speech compression algorithms have >been adopted with their own VAD and CNG mechanism and >the ratio between the computational power required by >the coder and that required by the VAD/CNG is around 5:1 >or higher. >To implement a PCM to linear decoder or a linear to >PCM coder requires around 30 cycles/frame on a popular >C5x machine. This is roughly equivalent to 0.48 MIPS >for a full Compander. Some DSPs have the capability to do >these operations in 1 cycle (for example Mitel's Miliwat >DSP core). >To implement a VAD+CNG mechanism that requires around >2 MIPS leads us to the abberation where the ratio between >the coder CPU requirements and the VAD/CNG requirements >are around 1:4 or worst!! >If someone has 2 MIPS to spare probably has 6 as well. >And if 6 MIPS are available, why wouldn't one use a toll >quality 32 kbps ADPCM algorithm with no silence supression ? >RFC 1889 not only allows ADPCM, but it allows for changing >coders on the fly to accomodate various bandwidth needs. >So, now we see that a simple VAD/CNG was used simply >because it made a lot of sense to use something on the same >degree of complexity (i.e. low) with the PCM coders. From a previous email, we have : It is true that G.711 is very low complexity and adding any additional processing needed in a channel must be highly scrutinized. However, in real-world VoIP systems each "Channel" is actually running much more than G.711. In fact listed below is what typically runs within each G.711 channel with estimates of actual DSP complexity. 0 - 1 MIPS -- G.711 (HW/SW) 1 - 3 MIPS -- Fax/Modem Detect 1- 3 MIPS -- DTMF Detect/Regeneration 7 - 15 MIPS -- G.165/G.168 LEC 0.25 - 2 MIPS -- VAD/CNG 0.25 - 3 MIPS -- Packet Loss Recovery ---------------------------------------------------------- 10 MIPS - 27 MIPS Therefore, if one ELECTED to incorporate an enhanced 1 MIP CNG over what exists today within RFC 1890 it would only take between 4% - 10% of the complexity required to run an actual G.711 Channel. So the computational ratio is actually between 10:1 and 25:1 for the application that is of concern. The second issue is why would someone use G.711 with VAD/CNG instead of G.726 ? One must consider the application, that being a voice call over H.323 using an RTP/UDP/IP stack. In this situation, the header overhead is generally 40 bytes. Because of the overhead, the transmission rate plays a larger role in overall system bit-rate than the codec bit-rate. One must also consider the network over which the data is sent. Below is a table illustrating the effective bit rate over an ATM link (assuming 48 byte cell and 5 byte header for simplicity) for G.711 with/without VAD-CNG and G.726. This is only one example, but it does illustrate the benefits. Parameters : frame size = 5ms, Voice Activity Factor = 0.6 (very realistic for a two-way call), CNG update rate = 200ms, CNG payload size=6 bytes. Codec Frames/Packet Bit-Rate (No Vad) Bit-Rate (Vad) G.711 1 169600 102608 2 127200 77168 G726 1 169600 2 84800 For 1 frame/packet, both codecs require 2 ATM cells and the effective bit rate is the same. For G.711 with Vad, we see significant bit-rate savings. At 2 frames/packet, G726 provides a significant saving over G711 without Vad, but G.711 with Vad-CNG still provides a savings over G.726. Again, this is a simplified example, but it does show the value of using a VAD-CNG scheme. In conclusion, when G.711 with VAD-CNG is considered in VoIP, it can provide significant bit-rate savings, better quality, and lower complexity compared to G.726. >2) Does anybody use the CN level cell/packet mechanism ? >Yes, we do. >We support the existent draft-ietf-avt-profile-new-07.txt >document and we want to see it approved as an RFC without >any delay. The use of the proposed "enhanced" CN payload is not mandatory, and defaults back to the existing definition. If desired, the use of the enhancement provides additional quality with little or no extra payload overhead, at a fractional increase in overall complexity, and remains generic to be used with any codec, not just G.711. If Mitel has an RTP application in mind that uses only G.711 with a super fast VAD-DTX scheme and uses only energy for Comfort Noise, then it is still free to do so. The proposal in no way changes this. The enhanced CN payload has many advantages over the existing CN. There is still the opportunity for it to be part of the RTP profile, and it should be considered. >3) How about a more sophisticated CN, for example one based >on noise spectral information ? >We believe there is no need for standardizing such an algorithm >neither by IETF or ITU-T. >However, if enough support for the adoption of such an algorithm >is voiced at the next ITU-T meeting in Geneva, we are prepared >to participate in the activites for defining the terms of >reference of a CNG algorithm for G.711 as well as making proposals >for a candidate algorithm. >I would be suprised if we would see at ITU-T just two proposals. We look forward to proposals from all interested parties. >4) How fast should the work be done ? >Well , there is no question dealing with CN for G.711 . >I believe G.711 is too important for everybody. We need >a separate question under SG16. >The ITU-T procedures for standardization are strict and well >defined. In this particular case many companies may have a high >interest in following the work and contribuing to it. >Work can be progressed through reflector groups but the >Telecommuncation community cannot be properly informed without >a general meeting in Geneva. >We want to make sure that everybody in this world using PCM coders >has a chance to take notice of the new work proposed and a chance >to contribute. The issue was first brought up at the Q12-14/16 Rapporteur's meeting in Berlin in August 1999. Here is a summary of the issue after discussion by the complete group of experts : It was noted that RFC 1890 is ill-defined; it will be the second version of RFC 1890 that should be referred to. Its current status is pre-RFC (see "draft-ietf-avt-profile-new-06.ps"). It was noted that the IETF work is general to all sample based coders, while the proposal focused on G.711. There may be a need for non-G.711 work. It was agreed: 1) To communicate a liaison to the IETF indicating that an issue exists and that more work is needed. 2) To communicate our concerns to Q19. The general goal would be to work with the RTP editors and not produce additional standards unless necessary. A liaison statement was generated from this meeting and sent to Q19. This liaison was considered at the Q19-21/16 Rapporteur's meeting in Geneva in Sept. 1999. Here is the summary from the Q19 Rapporteur about the issue and what was decided by the group : Initiating study for CNG under DTX condition Following the request by the Rapporteur Q.13/16, the meeting agreed to start study on the Comfort Noise Generator for the speech codec without built-in CNG such as G.711. A target of this work will be an Appendix to G.711 that defines the CNG function. The first step was to draft a terms of reference to define the CNG algorithm. The meeting formed an ad-hoc group with chairman of Mr. Robert Zopf (Lucent Technologies), which proposed a draft Performance Requirement s and Objectives in AC-99-46. With respect to the quality, the chairman of Q.14/12 (Mr. Mark Parkins, AT&T) kindly offered co-operation in defining the quality assessment method for coding speech under DTX/CNG operation during the interim period after the September meeting by correspondence. The meeting agreed that the work should be proceeded in the correspondence group of chairmanship by Mr. Zopf under the meeting of Q.19/16, with help of Q.14/12 for quality issue. The correspondence group should continue following works: (1) Complete the Performance Requirement s and Objectives (2) Draft preliminary test methodology and ask Q.14/12 for comments (3) Complete the Test Methodology (4) Collect candidate algorithms for CNG (5) Performance assessment for the candidates (6) Select a candidate and define the algorithm (Draft Appendix to G.711) . The time schedule should be established as a part of Terms of Reference taking into account that the Appendix is strongly desired by WP2/16 and IETF as soon as possible. Expectation for the Appendix may be approval at the next SG16 meeting in February 2000. The issue has been properly addressed within the ITU, and the work is following the path laid out at the meeting by the Q19 Rapporteur and the WP3 Chairman. I am sorry to everyone for the long email. I hope that the work can now progress in a timely fashion. Best Regards, Rob. --=====================_194611276==_.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by drawbridge.ascend.com id UAA02031 All,

I would like to respond to Alexander's comments below in the context of the proposal on the table and the application it is intended for.
Please see my comments below.

At 09:52 PM 11/06/1999 -0500, Alexander Tulai wrote:

Dear colleagues,

I would like to answer a few questions related to CNG.

1) Why ONLY a noise energy level mechanism has been
so far proposed as CNG for G.711 (both ATM and IP)?

More recent speech compression algorithms have
been adopted with their own VAD and CNG mechanism and
the ratio between the computational power required by
the coder and that required by the VAD/CNG is around 5:1
or higher.
To implement a PCM to linear decoder or a linear to
PCM coder requires around 30 cycles/frame on a popular
C5x machine. This is roughly equivalent to 0.48 MIPS
for a full Compander. Some DSPs have the capability to do
these operations in 1 cycle (for example Mitel's Miliwat
DSP core).
To implement a VAD+CNG mechanism that requires around
2 MIPS leads us to the abberation where the ratio between
the coder CPU requirements and the VAD/CNG requirements
are around 1:4 or worst!!
If someone has 2 MIPS to spare probably has 6 as well.
And if 6 MIPS are available, why wouldn't one use a toll
quality 32 kbps ADPCM algorithm with no silence supression ?
RFC 1889 not only allows ADPCM, but it allows for changing
coders on the fly to accomodate various bandwidth needs.
So, now we see that a simple VAD/CNG was used simply
because it made a lot of sense to use something on the same
degree of complexity (i.e. low) with the PCM coders.

From a previous email, we have :

It is true that G.711 is very low complexity and
adding any additional processing needed in a channel
must be highly scrutinized.  However, in real-world VoIP
systems each "Channel" is actually running much more
than G.711.  In fact listed below is what typically runs
within each G.711 channel with estimates of actual DSP
complexity.

0 - 1 MIPS  -- G.711 (HW/SW)
1 - 3 MIPS  -- Fax/Modem Detect
1- 3 MIPS -- DTMF Detect/Regeneration
7 - 15 MIPS -- G.165/G.168 LEC
0.25 - 2 MIPS -- VAD/CNG
0.25 - 3 MIPS -- Packet Loss Recovery
----------------------------------------------------------
10 MIPS - 27 MIPS


Therefore, if one ELECTED to incorporate an enhanced 1 MIP CNG
over what exists today within RFC 1890 it would only take between
4% - 10% of the complexity required to run an actual G.711 Channel.

So the computational ratio is actually between 10:1 and 25:1 for the application that is of concern.

The second issue is why would someone use G.711 with VAD/CNG instead of G.726 ?

One must consider the application, that being a voice call over H.323 using an RTP/UDP/IP stack.  In this situation, the header overhead is generally 40 bytes. Because of the overhead, the transmission rate plays a larger role in overall system bit-rate than the codec bit-rate.  One must also consider the network over which the data is sent.  Below is a table illustrating the effective bit rate over an ATM link (assuming 48 byte cell and 5 byte header for simplicity) for G.711 with/without VAD-CNG and G.726.  This is only one example, but it does illustrate the benefits.

Parameters : frame size =3D 5ms, Voice Activity Factor =3D 0.6 (very realistic for a two-way call), CNG update rate =3D 200ms, CNG payload size=3D6 bytes.

Codec   Frames/Packet  &nb= sp;        Bit-Rate (No Vad)       Bit-Rate (Vad)

G.711       &nbs= p;   1      &= nbsp;                169600<= x-tab>        &nbs= p;         102608
        &nb= sp;       2  =          &nbs= p;         &n= bsp; 127200    &nb= sp;         &= nbsp;   77168
        &nb= sp;       
G726        = ;    1     &n= bsp;         =         16= 9600
        &nb= sp;       2  =          &nbs= p;         &n= bsp; 84800

For 1 frame/packet, both codecs require 2 ATM cells and the effective bit rate is the same.  For G.711 with Vad, we see significant bit-rate savings.  At 2 frames/packet, G726 provides a significant saving over G711 without Vad, but G.711 with Vad-CNG still provides a savings over G.726.

Again, this is a simplified example, but it does show the value of using a VAD-CNG scheme.

In conclusion, when G.711 with VAD-CNG is considered in VoIP, it can provide significant bit-rate savings, better quality, and lower complexity compared to G.726.



2) Does anybody use the CN level cell/packet mechanism ?
Yes, we do.
We support the existent draft-ietf-avt-profile-new-07.txt
document and we want to see it approved as an RFC without
any delay.

The use of the proposed "enhanced" CN payload is not mandatory, and defaults back to the existing definition.  If desired, the use of the enhancement  provides additional quality with little or no extra payload overhead, at a fractional increase in overall complexity, and remains generic to be used with any codec, not just G.711.  If Mitel has an RTP application in mind that uses only G.711 with a super fast VAD-DTX scheme and uses only energy for Comfort Noise, then it is still free to do so.  The proposal in no way changes this.

The enhanced CN payload has many advantages over the existing CN. There is still the opportunity for it to be part of the RTP profile, and it should be considered.


3) How about a more sophisticated CN, for example one based
on noise spectral information ?
We believe there is no need for standardizing such an algorithm
neither by IETF or ITU-T.
However, if enough support for the adoption of such an algorithm
is voiced at the next ITU-T meeting in Geneva, we are prepared
to participate in the activites for defining the terms of
reference of a CNG algorithm for G.711 as well as  making proposals
for a candidate algorithm.
I would be suprised if we would see at ITU-T just two proposals.

We look forward to proposals from all interested parties.


4) How fast should the work be done ?
Well , there is no question dealing with CN for G.711 .
I believe G.711 is too important for everybody. We need
a separate question under SG16.
The ITU-T procedures for standardization are strict and well
defined. In this particular case many companies may have a high
interest in following the work and contribuing to it.
Work can be progressed through reflector groups but the
Telecommuncation community cannot be properly informed without
a general meeting in Geneva.
We want to make sure that everybody in this world using PCM coders
has a chance to take notice of the new work proposed and a chance
to contribute.

The issue was first brought up at the Q12-14/16 Rapporteur's meeting in Berlin in August 1999.  Here is a summary of the issue after discussion by the complete group of experts :

It was noted that RFC 1890 is ill-define= d; it will be the second version of RFC 1890 that should be referred to. Its current status is pre-RFC (see =93draft-ietf-avt-profile-new-06.ps=94).&n= bsp; It was noted that the IETF work is general to all sample based coders, while the proposal focused on G.711.  There may be a need for non-G.711 work.

It was agreed:

1) To communicate a liaison to the IETF indicating that an issue exists and that more work is needed.
2) To communicate our concerns to Q19.

The general goal would be to work with the RTP editors and not produce additional standards unless necessary.

A liaison statement was generated from this meeting and sent to Q19.  This liaison was considered at the Q19-21/16 Rapporteur's meeting in Geneva in Sept. 1999.  Here is the summary from the Q19 Rapporteur about the issue and what was decided by the group :

    &= nbsp;   Initiating study for CNG under DTX condition
Following the request by the Rapporteur Q.13/16, the meeting agreed to start study on the Comfort Noise Generator for the speech codec without built-in CNG such as G.711. A target of this work will be an Appendix to G.711 that defines the CNG function. The first step was to draft a terms of reference to define the CNG algorithm. The meeting formed an ad-hoc group with chairman of Mr. Robert Zopf (Lucent Technologies), which proposed a draft Performance Requirement s and Objectives in AC-99-46. With respect to the quality, the chairman of Q.14/12 (Mr. Mark Parkins, AT&T) kindly offered co-operation in defining the quality assessment method for coding speech under DTX/CNG operation during the interim period after the September meeting by correspondence.
The meeting agreed that the work should be proceeded in the correspondence group of chairmanship by Mr. Zopf under the meeting of Q.19/16, with help of Q.14/12 for quality issue.  The correspondence group should continue following works:
(1)     Complete the Performance Requirement s and Objectives
(2)     Draft preliminary test methodology and ask Q.14/12 for comments
(3)     Complete the Test Methodology
(4)     Collect candidate algorithms for CNG
(5)     Performance assessment for the candidates
(6)     Select a candidate and define the algorithm (Draft Appendix to G.711) .

The time schedule should be established as a part of Terms of Reference taking into account that the Appendix is strongly desired by WP2/16 and IETF as soon as possible. Expectation for the Appendix may be approval at the next SG16 meeting in February 2000.

The issue has been properly addressed within the ITU, and the work is following the path laid out at the meeting by the Q19 Rapporteur and the WP3 Chairman.

I am sorry to everyone for the long email.  I hope that the work can now progress in a timely fashion.

Best Regards,

Rob.
--=====================_194611276==_.ALT-- From rem-conf Tue Nov 09 04:50:57 1999 From rem-conf-request@es.net Tue Nov 09 04:50:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lAcW-0003iI-00; Tue, 9 Nov 1999 04:43:32 -0800 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lAcU-0003i8-00; Tue, 9 Nov 1999 04:43:30 -0800 Received: from hogan (slip129-37-49-184.ca.us.prserv.net [129.37.49.184]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id NAA02464; Tue, 9 Nov 1999 13:42:55 +0100 (MET) Message-Id: <3.0.6.32.19991109144740.0083d680@cdt.luth.se> X-Sender: micke@cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 09 Nov 1999 14:47:40 +0100 To: ipng@sunroof.eng.sun.com, rem-conf@es.net, pilc@grc.nasa.gov, iptel@lists.research.bell-labs.com From: Mikael Degermark Subject: Robust Header Compression BOF agenda Cc: micke@basil.cdt.luth.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a revised agenda for the robust header compression BOF to be held today Tuesday. As this is the night of the social event, we will ignore the break and instead aim to finish 17.45 at the latest. ------------- Robust Header compression BOF (robhc) Tuesday, November 9 at 1545-1800 ========== CHAIRS: Mikael Degermark Stephen Pink DESCRIPTION: The cellular community is now standardizing the next generation cellular systems. These systems will use IP to deliver telephony to coming mobile phones, to allow end-to-end IP telephony. As cellular bandwith is expensive, radio spectrum efficiency is of outmost importance and thus the IP/UDP/RTP headers must be compressed over the air. 3GPP has specified the requirements for the needed header compression scheme and it has been shown that no current header compression scheme in the IETF can satisfy these requirements. CRTP [RFC-2508] is the closest candidate but is not sufficiently robust against errors on the link, i.e., CRTP cannot deliver acceptable performance at the anticipated error rates. It is likely that the number of users of cellular IP telephony will be larger than the current number of people using TCP/IP, therefore it is important that a suitable header compression scheme is developed. The BOF will outline the relevant properties of the cellular links, the requirements, and will explain why CRTP fails. One or more proposals for a suitable header compression scheme will be presented, and finally we will discuss if and how the IETF will work on standardizing a suitable header compression scheme. AGENDA 0. Introduction Mikael Degermark 1. 3GPP timeline Mats Nilsson 2. 3GPP requirements on robust header compression. Khiem Le, Nokia draft-degermark-hc-requirements-00.txt 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 5. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 6. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark From rem-conf Tue Nov 09 05:21:18 1999 From rem-conf-request@es.net Tue Nov 09 05:21:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lBCJ-0004oM-00; Tue, 9 Nov 1999 05:20:31 -0800 Received: from s2.smtp.oleane.net [195.25.12.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lBCB-0004mp-00; Tue, 9 Nov 1999 05:20:30 -0800 Received: from Dell (dyn-1-1-154.Vin.dialup.oleane.fr [195.25.4.154]) by s2.smtp.oleane.net with SMTP id OAA49063; Tue, 9 Nov 1999 14:19:58 +0100 (CET) Message-ID: <001201bf2ab5$02e6f1c0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: Media Gateway Control Conference Date: Tue, 9 Nov 1999 14:18:59 +0100 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF2ABD.5DC2DB60" 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_000D_01BF2ABD.5DC2DB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP, Megaco, H.248: performing seamless interoperation between IP and = PSTN networks. The international rendez-vous in Paris, 15-17 December 1999. More infos:=20 http://www.upperside.fr/bamgc.htm ------=_NextPart_000_000D_01BF2ABD.5DC2DB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MGCP, Megaco, H.248: performing seamless = interoperation=20 between IP and PSTN
networks. The international rendez-vous in Paris, = 15-17=20 December 1999.

More infos:
http://www.upperside.fr/bamgc.= htm
 
------=_NextPart_000_000D_01BF2ABD.5DC2DB60-- From rem-conf Tue Nov 09 06:39:43 1999 From rem-conf-request@es.net Tue Nov 09 06:39:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lCOw-0006Dy-00; Tue, 9 Nov 1999 06:37:38 -0800 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lCOu-0006Do-00; Tue, 9 Nov 1999 06:37:37 -0800 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3) with ESMTP id QAA07497; Tue, 9 Nov 1999 16:36:42 +0200 (EET) From: khiem.le@nokia.com Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA28783; Tue, 9 Nov 1999 16:36:40 +0200 (EET) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Tue, 9 Nov 1999 16:18:41 +0200 Message-ID: <8572CF1E2A95D211A1190008C7EAA2464F5BFD@daeis05nok> To: micke@cdt.luth.se, ipng@sunroof.eng.sun.com, rem-conf@es.net, pilc@grc.nasa.gov, iptel@lists.research.bell-labs.com Cc: micke@basil.cdt.luth.se Subject: RE: Robust Header Compression BOF agenda Date: Tue, 9 Nov 1999 16:18:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mikael, I think you forgot an item on the agenda. As we discussed and agreed, we are going to present a robust RTP header compression scheme. This is separate >from the 3GPP requirements item. Also, due to my schedule constraints, as discussed last week, would it be possible to reshuffle the items on the agenda as follows (items 1 and 2 back-to-back will save some time, i.e. together they should take less than 30 min): AGENDA 0. Introduction Mikael Degermark 1. 3GPP requirements on robust header compression. Chris Clanton, Nokia draft-degermark-hc-requirements-00.txt 2. A robust and efficient RTP header compression scheme Khiem Le, Nokia 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. 3GPP timeline Mats Nilsson 5. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 6. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 7. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark Thanks Khiem -----Original Message----- From: EXT Mikael Degermark [mailto:micke@cdt.luth.se] Sent: Tuesday, November 09, 1999 7:48 AM To: ipng@sunroof.eng.sun.com; rem-conf@es.net; pilc@grc.nasa.gov; iptel@lists.research.bell-labs.com Cc: micke@basil.cdt.luth.se Subject: Robust Header Compression BOF agenda This is a revised agenda for the robust header compression BOF to be held today Tuesday. As this is the night of the social event, we will ignore the break and instead aim to finish 17.45 at the latest. ------------- Robust Header compression BOF (robhc) Tuesday, November 9 at 1545-1800 ========== CHAIRS: Mikael Degermark Stephen Pink DESCRIPTION: The cellular community is now standardizing the next generation cellular systems. These systems will use IP to deliver telephony to coming mobile phones, to allow end-to-end IP telephony. As cellular bandwith is expensive, radio spectrum efficiency is of outmost importance and thus the IP/UDP/RTP headers must be compressed over the air. 3GPP has specified the requirements for the needed header compression scheme and it has been shown that no current header compression scheme in the IETF can satisfy these requirements. CRTP [RFC-2508] is the closest candidate but is not sufficiently robust against errors on the link, i.e., CRTP cannot deliver acceptable performance at the anticipated error rates. It is likely that the number of users of cellular IP telephony will be larger than the current number of people using TCP/IP, therefore it is important that a suitable header compression scheme is developed. The BOF will outline the relevant properties of the cellular links, the requirements, and will explain why CRTP fails. One or more proposals for a suitable header compression scheme will be presented, and finally we will discuss if and how the IETF will work on standardizing a suitable header compression scheme. AGENDA 0. Introduction Mikael Degermark 1. 3GPP timeline Mats Nilsson 2. 3GPP requirements on robust header compression. Khiem Le, Nokia draft-degermark-hc-requirements-00.txt 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 5. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 6. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark From rem-conf Tue Nov 09 10:40:00 1999 From rem-conf-request@es.net Tue Nov 09 10:39:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lG6v-0001dW-00; Tue, 9 Nov 1999 10:35:17 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lG6u-0001dM-00; Tue, 9 Nov 1999 10:35:16 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA10873; Tue, 9 Nov 1999 10:23:48 -0800 (PST) Message-Id: <3.0.3.32.19991109102347.00b5ec20@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 09 Nov 1999 10:23:47 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/10 Application Outsourcing: The Next Big Thing on the Internet -- Peter Newman, Ensim Corporation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Application Outsourcing: The Next Big Thing on the Internet Wednesday, November 10, 1999, 1:00-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Peter Newman Ensim Corporation The current model for application distribution is deeply flawed. Customers are forced to keep track of the latest version of each software, to size their desktop machines to have sufficient power to deal with anticipated application load, and to painfully recover from hardware failures. These problems disappear overnight when applications are outsourced to Application Service Providers (ASPs). Potentially, the shift of applications from desktops to ASPs is as powerful and disruptive as the introduction of the World Wide Web. However, ASPs too face severe scaling problems in providing outsourced services to tens of thousands of customers. In this talk, we will outline these problems and describe a novel approach to solving them. --------------- The seminar is broadcast live on the Internet Mbone and as a RealNetworks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Wed Nov 10 02:53:25 1999 From rem-conf-request@es.net Wed Nov 10 02:53:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lVIx-0002OE-00; Wed, 10 Nov 1999 02:48:43 -0800 Received: from bigmac.iq.co.za [196.28.191.3] by mail1.es.net with smtp (Exim 1.81 #2) id 11lVIj-0002JC-00; Wed, 10 Nov 1999 02:48:30 -0800 Received: from chairer [168.191.61.223] by bigmac.iq.co.za (SMTPD32-4.03) id AA84205042A; Tue, 09 Nov 1999 19:46:12 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Subject: Isn't It Time To Wipe Out Your Bills? Date: Tue, 09 Nov 1999 02:56:37 +0000 From: giants8@pmail.net To: malcforbes@estate.net Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list That's Right! We can SLASH your bills, from 40-80% off of what you owe. That's money that goes right back into your pocket! * WHAT WE DO: Negotiate with your creditors to SAVE you money! Relieve you from creditor phone calls. * Some types of debt we work on: CREDIT CARDS VENDORS SUPPLIERS LAWSUITS JUDGEMENTS MEDICAL BILLS INSURANCE BILLS LOANS * COST For a Limited Time Only, we will provide you with FREE CONSULTATION SERVICE! That's right! NO RESULTS - NO FEE! We will work on a contingency basis, our fee will be based on a percentage of the savings - if we can't help you SAVE money, there will be NO FEE! Our company has been saving individuals and businesses money for over 18 years. DON'T HESITATE - call our toll free number now for more information. There is no obligation! TOLL FREE NUMBER: 1(888)323-0855 (note: our 888 number is toll free, so please leave a brief message) To be removed from our list, simply click "reply" and put the words "Remove Debt Consolidation" in the subject line. Warning: If you do not put the words "Remove Debt Consolidation" in the subject line, you will not be removed. The process is automated. From rem-conf Wed Nov 10 05:29:55 1999 From rem-conf-request@es.net Wed Nov 10 05:29:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lXiP-0004fE-00; Wed, 10 Nov 1999 05:23:09 -0800 Received: from unica.udc.es [193.144.48.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lXiK-0004ez-00; Wed, 10 Nov 1999 05:23:07 -0800 Received: from udc.es (micro.udc.es [193.144.48.69]) by unica.udc.es (8.8.5/8.8.5) with ESMTP id PAA24724; Wed, 10 Nov 1999 15:27:22 -0100 (GMT) Message-ID: <38297221.CF5EF0AE@udc.es> Date: Wed, 10 Nov 1999 14:24:49 +0100 From: Nieves Pedreira Souto X-Mailer: Mozilla 4.5 [es] (WinNT; I) X-Accept-Language: es MIME-Version: 1.0 To: rem-conf@es.net, mbone@listserv.rediris.es Subject: MBONE: International Session Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by unica.udc.es id PAA24724 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Organization: Universidade da Coru=F1a Title: Workshop on Biomedical Engineering Advances Description: The present workshop arises as an answer to the need of showing the advances in Computing Sciences, including Software Engineering, Knowledge Engineering and Telematics, applied to Biomedical Problems Solving. Dates: from 8:00 h. November, 18 to 15:00 h. November, 19 (GMT) TTL > 48 =20 Bandwidth: 128 Kbps video + 39 Kbps audio=20 Session type: Audio and Video Contact: nieves@udc.es URL: http://rnasa.dc.fi.udc.es =20 --=20 Nieves Pedreira Souto Servicios Inform=E1ticos de Apoio =E1 Investigaci=F3n Telf.: 981.167000 ext.:1308 From rem-conf Wed Nov 10 15:13:50 1999 From rem-conf-request@es.net Wed Nov 10 15:13:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lgrS-0002oC-00; Wed, 10 Nov 1999 15:09:06 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11lgrQ-0002o2-00; Wed, 10 Nov 1999 15:09:05 -0800 Received: from dhcp46-lt119.lt.ietf.innovationslab.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Nov 1999 23:09:00 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id VAA00667 for ; Wed, 10 Nov 1999 21:39:40 GMT Message-Id: <199911102139.VAA00667@cperkins-d.cs.ucl.ac.uk> To: rem-conf@es.net Subject: Slides from AVT meeting Date: Wed, 10 Nov 1999 21:39:40 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could those presenters who have not already done so, please send me a copy of their slides, for inclusion in the minutes. Thanks, Colin From rem-conf Wed Nov 10 22:50:38 1999 From rem-conf-request@es.net Wed Nov 10 22:50:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lnym-00074i-00; Wed, 10 Nov 1999 22:45:08 -0800 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lnyl-00074Y-00; Wed, 10 Nov 1999 22:45:07 -0800 Received: from pigpen (ap01-014.mp.pi.se [195.7.86.14]) by mail.pi.se (8.8.8/8.8.8) with SMTP id HAA20891; Thu, 11 Nov 1999 07:42:31 +0100 (MET) From: "Gunnar Hellstrom" To: "Colin Perkins" , Cc: "Mickey Nasiri (ECS)" , "Text Telephone Forum" Subject: SV: Slides from AVT meeting RTP-Text discussion Date: Thu, 11 Nov 1999 11:41:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01BF2C39.A8A050E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <199911102139.VAA00667@cperkins-d.cs.ucl.ac.uk> 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_0000_01BF2C39.A8A050E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id HAA20891 Colin and all, I attach the slides for the RTP-Text discussion in two forms, Word and tx= t. Regards Gunnar -----Ursprungligt meddelande----- Fr=E5n: Colin Perkins [mailto:c.perkins@cs.ucl.ac.uk] Skickat: den 10 november 1999 22:40 Till: rem-conf@es.net =C4mne: Slides from AVT meeting Could those presenters who have not already done so, please send me a cop= y of their slides, for inclusion in the minutes. Thanks, Colin ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom@omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ------=_NextPart_000_0000_01BF2C39.A8A050E0 Content-Type: text/plain; name="RTP-text status nov-99.txt" Content-Disposition: attachment; filename="RTP-text status nov-99.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force AVT WG IETF Washington DC Gunnar Hellstr=F6m Nov 8-12 1999. Ian Rytina LM Ericsson Progress of draft-ietf-avt-rtp-text since the Oslo meeting Draft-ietf-avt-rtp-text-02.txt is the latest version of the RTP Payload = description for ITU-T T.140 Text Conversation. The draft was entered on Oct 22. The specification seems now stable and = the author now asks for the last call procedure to be initiated. Summary of discussions that has been held, and modifications done: Since July, the following discussions and modifications have taken place 1. Type of redundancy to use, FEC or RED? Agreed that it should be open = and not in the normative part, but RED recommended because of its = simplicity and the need to encourage interoperability. That is now = reflected in section 2.3 and in the "Recommended procedures" = section.3.2. 2. The need for this specification when IRC and TELNET CHAT are = available? Answer: There is a user need for an end-to-end = character-by-character internationally useful text conversation protocol = to flow directly between terminals and possible to use in multimedia = conversation environments like H.323 and SIP. 3. Proper procedure for MIME registration? The MIME registration section = (6.) added, and the whole draft sent for MIME registration as text/t140. 4. Clock frequency? Irrelevant for text - it is collected as the user = inputs text. But 1000 Hz specified now in section 2.1 5. Order of redundant data? For the recovery procedures to work, = redundant data must be inserted in age order and with one redundant = block from each transmitted packet. That is now clarified in section = 2.3. 6. Avoid double specification of fill character for missing data. The character 0x2607 "Lightning" is to be used in T.140 to mark a spot = where data is missing. In order to not cause double requirements, this = is now only mentioned in a should clause in RTP-Text, section 3.2. 7. Transmission during silent periods: To give the last characters = before a pause the same chance to redundancy recovery, redundant = transmission with empty primary data is recommended as many times as the = redundancy generations. (In one version, the Unicode sync character = 0xFEFF was specified.) See section 3.4. Author: Gunnar Hellstrom, gunnar.hellstrom@omnitor.se ------=_NextPart_000_0000_01BF2C39.A8A050E0 Content-Type: application/msword; name="RTP-text status nov-99.doc" Content-Disposition: attachment; filename="RTP-text status nov-99.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAADAAAAAAAAAAA EAAADQAAAAEAAAD+////AAAAAAsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAgAAAAAAAAwAA9AsAAA4UAAAAAAAAAAAAAAAAAAAAAAAA9AgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAPIAAAAAEgAA8gAAAPISAAAAAAAA8hIA AAAAAADyEgAAAAAAAPISAAAAAAAA8hIAABQAAAAGEwAAAAAAAAYTAAAAAAAABhMAAAAAAAAGEwAA AAAAAAYTAAAAAAAABhMAAAoAAAAQEwAACgAAAAYTAAAAAAAAHBMAAFMAAAAaEwAAAAAAABoTAAAA AAAAGhMAAAAAAAAaEwAAAAAAABoTAAAAAAAAGhMAAAAAAAAaEwAAAAAAABoTAAAAAAAAGhMAAAIA AAAcEwAAAAAAABwTAAAAAAAAHBMAAAAAAAAcEwAAAAAAABwTAAAAAAAAHBMAAAAAAABvEwAAWAAA AMcTAABHAAAAHBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8hIAAAAAAAAaEwAAAAAAAAAABwAIAAEA AQAaEwAAAAAAABoTAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoTAAAAAAAAGhMAAAAAAAAcEwAAAAAA ABoTAAAAAAAA8hIAAAAAAADyEgAAAAAAABoTAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoTAAAAAAAA GhMAAAAAAAAaEwAAAAAAABoTAAAAAAAAGhMAAAAAAADyEgAAAAAAABoTAAAAAAAA8hIAAAAAAAAa EwAAAAAAABoTAAAAAAAAAAAAAAAAAACAapMbqye/AQYTAAAAAAAABhMAAAAAAADyEgAAAAAAAPIS AAAAAAAA8hIAAAAAAADyEgAAAAAAABoTAAAAAAAAGhMAAAAAAAAaEwAAAAAAABoTAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNl CQkJCUFWVCBXRw1JRVRGIFdhc2hpbmd0b24gREMgCQkJCUd1bm5hciBIZWxsc3Ry9m0NTm92IDgt MTIgMTk5OS4JCQkJSWFuIFJ5dGluYQ0JCQkJCUxNIEVyaWNzc29uDQ0NDVByb2dyZXNzIG9mIGRy YWZ0LWlldGYtYXZ0LXJ0cC10ZXh0IHNpbmNlIHRoZSBPc2xvIG1lZXRpbmcNDURyYWZ0LWlldGYt YXZ0LXJ0cC10ZXh0LTAyLnR4dCBpcyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIFJUUCBQYXls b2FkIGRlc2NyaXB0aW9uIGZvciBJVFUtVCBULjE0MCBUZXh0IENvbnZlcnNhdGlvbi4NDVRoZSBk cmFmdCB3YXMgZW50ZXJlZCBvbiBPY3QgMjIuIFRoZSBzcGVjaWZpY2F0aW9uIHNlZW1zIG5vdyBz dGFibGUgYW5kIHRoZSBhdXRob3Igbm93IGFza3MgZm9yIHRoZSBsYXN0IGNhbGwgcHJvY2VkdXJl IHRvIGJlIGluaXRpYXRlZC4NDQ4NU3VtbWFyeSBvZiBkaXNjdXNzaW9ucyB0aGF0IGhhcyBiZWVu IGhlbGQsIGFuZCBtb2RpZmljYXRpb25zIGRvbmU6Cw1TaW5jZSBKdWx5LCB0aGUgZm9sbG93aW5n IGRpc2N1c3Npb25zIGFuZCBtb2RpZmljYXRpb25zIGhhdmUgdGFrZW4gcGxhY2UNDVR5cGUgb2Yg cmVkdW5kYW5jeSB0byB1c2UsIEZFQyBvciBSRUQ/IEFncmVlZCB0aGF0IGl0IHNob3VsZCBiZSBv cGVuIGFuZCBub3QgaW4gdGhlIG5vcm1hdGl2ZSBwYXJ0LCBidXQgUkVEIHJlY29tbWVuZGVkIGJl Y2F1c2Ugb2YgaXRzIHNpbXBsaWNpdHkgYW5kIHRoZSBuZWVkIHRvIGVuY291cmFnZSBpbnRlcm9w ZXJhYmlsaXR5LiBUaGF0IGlzIG5vdyByZWZsZWN0ZWQgaW4gc2VjdGlvbiAyLjMgYW5kIGluIHRo ZSCUUmVjb21tZW5kZWQgcHJvY2VkdXJlc5Qgc2VjdGlvbi4zLjIuCw1UaGUgbmVlZCBmb3IgdGhp cyBzcGVjaWZpY2F0aW9uIHdoZW4gSVJDIGFuZCBURUxORVQgQ0hBVCBhcmUgYXZhaWxhYmxlPyBB bnN3ZXI6IFRoZXJlIGlzIGEgdXNlciBuZWVkIGZvciBhbiBlbmQtdG8tZW5kIGNoYXJhY3Rlci1i eS1jaGFyYWN0ZXIgaW50ZXJuYXRpb25hbGx5IHVzZWZ1bCB0ZXh0IGNvbnZlcnNhdGlvbiBwcm90 b2NvbCB0byBmbG93IGRpcmVjdGx5IGJldHdlZW4gdGVybWluYWxzIGFuZCBwb3NzaWJsZSB0byB1 c2UgaW4gbXVsdGltZWRpYSBjb252ZXJzYXRpb24gZW52aXJvbm1lbnRzIGxpa2UgSC4zMjMgYW5k IFNJUC4LDVByb3BlciBwcm9jZWR1cmUgZm9yIE1JTUUgcmVnaXN0cmF0aW9uPyBUaGUgTUlNRSBy ZWdpc3RyYXRpb24gc2VjdGlvbiAoNi4pIGFkZGVkLCBhbmQgdGhlIHdob2xlIGRyYWZ0IHNlbnQg Zm9yIE1JTUUgcmVnaXN0cmF0aW9uIGFzIHRleHQvdDE0MC4LDUNsb2NrIGZyZXF1ZW5jeT8gSXJy ZWxldmFudCBmb3IgdGV4dCCWIGl0IGlzIGNvbGxlY3RlZCBhcyB0aGUgdXNlciBpbnB1dHMgdGV4 dC4gQnV0IDEwMDAgSHogc3BlY2lmaWVkIG5vdyBpbiBzZWN0aW9uIDIuMQ0ODU9yZGVyIG9mIHJl ZHVuZGFudCBkYXRhPyBGb3IgdGhlIHJlY292ZXJ5IHByb2NlZHVyZXMgdG8gd29yaywgcmVkdW5k YW50IGRhdGEgbXVzdCBiZSBpbnNlcnRlZCBpbiBhZ2Ugb3JkZXIgYW5kIHdpdGggb25lIHJlZHVu ZGFudCBibG9jayBmcm9tIGVhY2ggdHJhbnNtaXR0ZWQgcGFja2V0LiBUaGF0IGlzIG5vdyBjbGFy aWZpZWQgaW4gc2VjdGlvbiAyLjMuDQ1Bdm9pZCBkb3VibGUgc3BlY2lmaWNhdGlvbiBvZiBmaWxs IGNoYXJhY3RlciBmb3IgbWlzc2luZyBkYXRhLgtUaGUgY2hhcmFjdGVyIDB4MjYwNyCUTGlnaHRu aW5nlCBpcyB0byBiZSB1c2VkIGluIFQuMTQwIHRvIG1hcmsgYSBzcG90IHdoZXJlIGRhdGEgaXMg bWlzc2luZy4gSW4gb3JkZXIgdG8gbm90IGNhdXNlIGRvdWJsZSByZXF1aXJlbWVudHMsIHRoaXMg aXMgbm93IG9ubHkgbWVudGlvbmVkIGluIGEgc2hvdWxkIGNsYXVzZSBpbiBSVFAtVGV4dCwgc2Vj dGlvbiAzLjIuCw1UcmFuc21pc3Npb24gZHVyaW5nIHNpbGVudCBwZXJpb2RzOiBUbyBnaXZlIHRo ZSBsYXN0IGNoYXJhY3RlcnMgYmVmb3JlIGEgcGF1c2UgdGhlIHNhbWUgY2hhbmNlIHRvIHJlZHVu ZGFuY3kgcmVjb3ZlcnksIHJlZHVuZGFudCB0cmFuc21pc3Npb24gd2l0aCBlbXB0eSBwcmltYXJ5 IGRhdGEgaXMgcmVjb21tZW5kZWQgYXMgbWFueSB0aW1lcyBhcyB0aGUgcmVkdW5kYW5jeSBnZW5l cmF0aW9ucy4gKEluIG9uZSB2ZXJzaW9uLCB0aGUgVW5pY29kZSBzeW5jIGNoYXJhY3RlciAweEZF RkYgd2FzIHNwZWNpZmllZC4pIFNlZSBzZWN0aW9uIDMuNC4LDQ0NDUF1dGhvcjogR3VubmFyIEhl bGxzdHJvbSwgIGd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZQ0AAAAAAAAAAAAAAAD3AJHEAqEB AJzEAp3EAqSCLqXGQaaJBaeJBaiJBamJBaoAAIXUAAABCAAA//8AAAEAaAF4AP8BAAgAAAMAAAAB AGgBeAD/AQAIAAAEAAAAAQBoAXgA/wEACAAAAQAAAAEAaAF4AP8BAAgAAAMAAAABAGgBeAD/AQAI AAAEAAAAAQBoAXgA/wEACAAAAQAAAAEAaAF4AP8BAAgAAAMAAAABAGgBeAD/AQAIAAAEAAAAAQBo AXgAAAAAAC5vp7dvp7dvpwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAABSAwAA gwMAADYEAADDBAAABgUAAFEFAAB3BQAAZgYAAK0GAACaBwAAwQcAACoIAAA6CAAApQgAAL0IAABy CQAAsAkAAIMKAACmCgAAuwsAAPMLAAD0CwAA+QwAAAD9AP0A+/j9+P34/fj9+P34/fj9AP32AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQAFVYFjHAACVYEAA2McAAAXAAMAACoDAABS AwAAbwMAAIADAACBAwAAggMAAIMDAAC+AwAAvwMAADYEAAA3BAAAwAQAAMEEAADDBAAABwUAAFAF AABRBQAAZgYAAJoHAAAqCAAAowgAAKUIAABxCQAAcgkAAIMKAAC6CwAAuwsAALwLAAC9CwAA9AsA AP4AAAAAAAD+AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD6AAAAAAAA +AAAAAAAAPgAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA9gAAAAAAAPYAAAAAAAD2 AAAAAAAA0QAAAAAAANEAAAAAAADRAAAAAAAA0QAAAAAAAMwAAAAAAADRAAAAAAAAyQAAAAAAANEA AAAAAADRAAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAADQwA BAAADQwRaAEAACQAAA0BEdACE5j+DDQAAAEIAAD//wAAAQBoAXgAAAAAAC4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwUAAdACAAAAARAAAAEPAAABAgAAAQAAAAEBAB4OABEACAABAEsA DwAAAAAAHAAAQPH/AgAcAAZOb3JtYWwAAgAAAAYAYR0EYxgAIAABQAEAAgAgAAlIZWFkaW5nIDEA AAQAAQAIAQMAYxwAACIAAkABAAIAIgAJSGVhZGluZyAyAAAEAAIACAEFAFWBYxwAAAAAAAAAAAAA AAAAAAAAIgBBQPL/oQAiABZEZWZhdWx0IFBhcmFncmFwaCBGb250AAAAAAAAAAAAAAAeAEJAAQDy AB4ACUJvZHkgVGV4dAAAAgAPAAMAYxwAACIA/k8BAAIBIgALQm9keSBUZXh0IDIAAAIAEAAFAFWB YxwAAAAAAAD0CAAAAwAADAAAAQD/////AAMAAPkMAAAHAAADAAD0CwAACAD/QFMAFRKQAQAAVGlt ZXMgTmV3IFJvbWFuAAwQkAECAFN5bWJvbAALIpABAABBcmlhbAARMZABAABDb3VyaWVyIE5ldwAP ApABAgBXaW5nZGluZ3MAIgAEAAAAgBgA8BgFAACpAQAAAABeLDumXiw7plwsO6YCAAIAAABLAQAA YgcAAAEAAwAAAAQAgxAPAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAAAAAPAQAEcAAAATSUVURiBX YXNoaW5ndG9uIERDIAAAABBHdW5uYXIgSGVsbHN0cvZtEEd1bm5hciBIZWxsc3Ry9m0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAP7////9////DwAAAP7///8XAAAA/v////////// ///////////////////////////////+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////9SAG8AbwB0ACAARQBu AHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACAapMbqye/AQ4AAACAAwAAAAAA AlcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQ AAAAAAAAAAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA4UAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8EAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADcAQAAAAAAAAEAAAD+////AwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAP7///8LAAAADAAAAA0AAAD+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wMKAAD/////AAkC AAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAA AABXb3JkLkRvY3VtZW50LjYA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEgAAAAEA AACYAAAAAgAAAKAAAAADAAAAvAAAAAQAAADIAAAABQAAAOQAAAAGAAAA8AAAAAcAAAD8AAAACAAA AAwBAAAJAAAAKAEAABIAAAA0AQAACgAAAFwBAAALAAAAaAEAAAwAAAB0AQAADQAAAIABAAAOAAAA jAEAAA8AAACUAQAAEAAAAJwBAAATAAAApAEAAAIAAADkBAAAHgAAABQAAABJRVRGIFdhc2hpbmd0 b24gREMgAB4AAAABAAAAAAAAAB4AAAARAAAAR3VubmFyIEhlbGxzdHL2bQAAAAAeAAAAAQAAAAAA AAAeAAAAAQAAAAAAAAAeAAAABwAAAE5vcm1hbAAAHgAAABEAAABHdW5uYXIgSGVsbHN0cvZtAAAK AB4AAAACAAAAMgBEAB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFcFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADUAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAA AAAAwAAAAAAAAEYOAAAAV29yZC1kb2t1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAABAAAABwAAAADAAAAHgAAAACAAAA5AQAAB4AAAAIAAAAT21u aXRvcgADAAAADwAAAAMAAAADAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAABQAAABJRVRG IFdhc2hpbmd0b24gREMgAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaW5kb3dzIDk1AEUAQAAAAACMhkcAAAAA QAAAAACog7mqJ78BQAAAAAA0CgGrJ78BQAAAAAA0CgGrJ78BAwAAAAEAAAADAAAASwEAAAMAAABi BwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAA AAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACkAAAABwAAAAEAAABAAAAADwAA AEgAAAAFAAAAWAAAAAYAAABgAAAACwAAAGgAAAAQAAAAcAAAAAwAAAB4AAAAAgAAAOQEAAAeAAAA CAAAAE9tbml0b3IAAwAAAA8AAAADAAAAAwAAAAsAAAAAAAAACwAAAAAAAAAMEAAAAgAAAB4AAAAU AAAASUVURiBXYXNoaW5ndG9uIERDIAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0000_01BF2C39.A8A050E0-- From rem-conf Thu Nov 11 11:38:36 1999 From rem-conf-request@es.net Thu Nov 11 11:38:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11lzm1-00065o-00; Thu, 11 Nov 1999 11:20:45 -0800 Received: from wp17.iii.rmit.edu.au (WP17.ietec.com.au) [131.170.185.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11lzlx-000654-00; Thu, 11 Nov 1999 11:20:42 -0800 Received: from 171.218.51.115 ([171.218.51.115]) by WP17.ietec.com.au with Microsoft SMTPSVC(5.0.2124.15.0.2124.1); Fri, 12 Nov 1999 06:19:37 +1100 Message-ID: <000032ac4cc1$000039fd$0000086a@> To: From: los321@email.com Subject: Get your Free Mortgage Quote!! Date: Thu, 11 Nov 1999 13:12:15 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Homeowner, From: los321@email.com Bcc: Return-Path: los321@email.com X-OriginalArrivalTime: 11 Nov 1999 19:19:39.0185 (UTC) FILETIME=[B2C91210:01BF2C79] Date: 12 Nov 1999 06:19:39 +1100 If you are in debt or need extra cash, we can help you get the money you have been hoping for. Our FREE services have already helped thousands of homeowners, just like you, get super-low interest loans to consolidate bills, get out of debt, etc. To get your free loan quote click below http://3521945351@3521945350/users/morlo/loancqualify.html We are a top rated professional mortgage agency. Best of all, we offer the lowest interest rates available - and they can set you up with an incredibly low monthly payment! With Our Contacts, We Can Provide You with loans up to 135% of Your Home's Value! And even better, there are NO Advances or Upfront Fees of any kind! Here are just some of the ways you could put this cash to use: -> Home Improvements -> Credit Card Debt -> College Tuition -> Dream Vacation -> A New Car -> Start Your Own Business ...or whatever else you need - it's up to YOU. So if you're serious about improving your current financial position, you owe it to yourself to request your FREE Loan Evaluation. It's FREE and you've got nothing to lose. We take great pride in offering such prompt and quality service to you and your family. Click below to get your free loan quote http://3521945351@3521945350/users/morlo/loancqualify.html From rem-conf Thu Nov 11 16:18:43 1999 From rem-conf-request@es.net Thu Nov 11 16:18:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11m4Ke-00023H-00; Thu, 11 Nov 1999 16:12:48 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11m4Kb-000237-00; Thu, 11 Nov 1999 16:12:46 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id QAA25182; Thu, 11 Nov 1999 16:07:10 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 12 Nov 1999 00:12:42 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id QAA06090; Thu, 11 Nov 1999 16:12:41 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id QAA12408; Thu, 11 Nov 1999 16:14:54 -0800 (PST) Received: from zopf_nt-pc ([192.168.37.254]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id TAA23686; Thu, 11 Nov 1999 19:12:25 -0500 (EST) Message-Id: <4.2.0.58.19991111144838.00abe860@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 11 Nov 1999 19:12:48 -0500 To: wp3audio@ctd.comsat.com, rem-conf@es.net From: Robert Zopf Subject: CNG ToR Cc: meperkins@att.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_33968754==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_33968754==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Colleagues, Find attached an updated ToR. The main changes from the original draft include: * it now notes sampling rates other than 8.0 kHz * car noise is added as a background noise source * a complexity objective of less than 1.0 MIP is added to reflect the concerns about complexity. * compatibility with the current RTP profile is added (first byte represents the energy). * removal of a 16 bit fixed point bit exact implementation * removal of a frame size specification (the CNG should work with all frame sizes) * removal of CNG update rate - this is implementation specific * removal of bit-rate since this depends on the CNG update rate. The schedule is left blank for now. It can be addressed after the requirements have been agreed upon. In this way, the final requirements can be sent to Q.14/12 in order to finalize the test plan. Please provide comments so we can have the ToR finalized by the end of next week. Regards, Rob. --=====================_33968754==_ Content-Type: application/msword; name="Draft_CNG_ToR2.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Draft_CNG_ToR2.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAhAAAAAAAAAAA EAAASgAAAAEAAAD+////AAAAAIcAAACGAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////+ /wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACwAQAAEgAAAAEA AACYAAAAAgAAAKAAAAADAAAAxAAAAAQAAADQAAAABQAAAOwAAAAGAAAA+AAAAAcAAAAEAQAACAAA ABgBAAAJAAAAOAEAABIAAABEAQAACgAAAGABAAALAAAAbAEAAAwAAAB4AQAADQAAAIQBAAAOAAAA kAEAAA8AAACYAQAAEAAAAKABAAATAAAAqAEAAAIAAADkBAAAHgAAABsAAABUZW1wbGF0ZSBmb3Ig Y29udHJpYnV0aW9ucwAAHgAAAAEAAAAAZW1wHgAAABIAAABTaW1hbyBDYW1wb3MtTmV0bwBpYh4A AAABAAAAAGltYR4AAAABAAAAAGltYR4AAAALAAAATm9ybWFsLmRvdABzHgAAABcAAABBc2NlbmQg QXV0aG9yaXplZCBVc2VyAG8eAAAAAwAAADE4AGUeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMABz QAAAAAAQwyweAAAAQAAAAADOSEKjJL8BQAAAAAAaT11yJL8BQAAAAABUloaDLL8BAwAAAAIAAAAD AAAAJAIAAAMAAAA0DAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI ACss+a5gAQAAHAEAAA0AAAABAAAAcAAAAA8AAAB4AAAABAAAAIwAAAAFAAAAlAAAAAYAAACcAAAA EQAAAKQAAAAXAAAArAAAAAsAAAC0AAAAEAAAALwAAAATAAAAxAAAABYAAADMAAAADQAAANQAAAAM AAAA+wAAAAIAAADkBAAAHgAAAAwAAABDT01TQVQgTGFicwADAAAAAGIAAAMAAAAaAAAAAwAAAAYA AAADAAAA/A4AAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA ABsAAABUZW1wbGF0ZSBmb3IgY29udHJpYnV0aW9ucwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURf R1VJRAACAAAA5AQAAEEAAABOAAAAewBBADUAQQBEAEUAMwA2ADAALQA3ADYAQQBFAC0AMQAxAEQA MwAtAEEAOABEAEMALQAwADAAMQAwADUAQQA4AEEANQBBAEEARgB9AAAAAAAAAAAAAAAAAAAASVRV IFRlbGVjb21tdW5pY2F0aW9uIFN0YW5kYXJkaXphdGlvbiBTZWN0b3IHBwcNU3R1ZHkgR3JvdXAg MTYNUS4xOS0yMS8xNiANDQ1TT1VSQ0UqOgdRLjE5LzE2BwcHBwdUSVRMRToHVGVybXMgb2YgUmVm ZXJlbmNlIJYgQ29tZm9ydCBOb2lzZSBmb3IgUlRQIEF1ZGlvIGFuZCBWaWRlbyBDb25mZXJlbmNl cwcHBwcHDQ1JbnRyb2R1Y3Rpb24NDVRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgdGVybXMgb2Yg cmVmZXJlbmNlIGZvciBhIENvbWZvcnQgTm9pc2UgR2VuZXJhdGlvbiAoQ05HKSBzY2hlbWUgZm9y IHVzZSB3aXRoIG5hcnJvdyBiYW5kIGNvZGVjcyB3aXRob3V0IGJ1aWx0IGluIHNpbGVuY2UgY29t cHJlc3Npb24uDUJhY2tncm91bmQNDVRoZXJlIGlzIGFuIGltbWVkaWF0ZSBuZWVkIHRvIGRlZmlu ZSBhbiBpbXByb3ZlZCBDTkcgc2NoZW1lIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhbiBILjMyMyB2 b2ljZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gZm9yIHNwZWVjaCBjb2RlY3Mgd2l0aG91dCBhIGJ1 aWx0LWluIENORyBhbGdvcml0aG0gWzFdLiAgQ3VycmVudGx5IGluIHNlc3Npb25zIHVzaW5nIGEg Y29kZWMgd2l0aG91dCBidWlsdC1pbiBDTkcgY2FwYWJpbGl0aWVzLCB0aGUgb25seSBhdmFpbGFi bGUgZGVzY3JpcHRpb24gb2YgdGhlIGJhY2tncm91bmQgbm9pc2UgaXMgdGhlIGVuZXJneSBsZXZl bC4gIFRoZXJlIGlzIG5vIHJlY29tbWVuZGVkIG1lYW5zIG9mIGhvdyB0byByZWdlbmVyYXRlIGNv bWZvcnQgbm9pc2Ugb24gdGhlIHJlY2VpdmVyLiAgVGhpcyBmbGV4aWJpbGl0eSBhbGxvd3MgZm9y IG1hbnkgaW50ZXJwcmV0YXRpb25zIGFuZCBjb25zZXF1ZW50bHksIGFuIGluY29uc2lzdGVudCBh bmQgdW4tZ3VhcmFudGVlZCBsZXZlbCBvZiBxdWFsaXR5LiAgVGhlIHByZXNlbmNlIG9mIG9ubHkg dGhlIGVuZXJneSBhbHNvIGxpbWl0cyB0aGUgc3lzdGVtknMgb3ZlcmFsbCBwZXJmb3JtYW5jZS4N DUFzIGEgcmVzdWx0IG9mIHRoZSBhYm92ZSwgaXQgd2FzIGFncmVlZCB0byBzdGFydCBzdHVkeSBv biB0aGUgQ29tZm9ydCBOb2lzZSBHZW5lcmF0b3IgZm9yIHRoZSBzcGVlY2ggY29kZWMgd2l0aG91 dCBidWlsdC1pbiBDTkcgYXQgdGhlIFNlcHRlbWJlciAxOTk5IFEuMTkvMTYgUmFwcG9ydGV1cpJz IG1lZXRpbmcgaW4gR2VuZXZhLiAgQXMgYSBmaXJzdCBzdGVwIGluIHRoaXMgcHJvY2VzcywgdGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIHBlcmZvcm1hbmNlIGFuZCBjaGFyYWN0ZXJpc3RpY3Mg b2Ygc3VjaCBhIHN5c3RlbS4gIA1BcHBsaWNhdGlvbnMNDVRoZSBwcmltYXJ5IGFwcGxpY2F0aW9u IGlzIGZvciB1c2Ugd2l0aGluIEguMzIzIGZvciBuYXJyb3cgYmFuZCBjb2RlY3Mgd2l0aG91dCBh IGRlZmluZWQgQ05HIGFsZ29yaXRobS4gDVBlcmZvcm1hbmNlIFJlcXVpcmVtZW50cyAmIE9iamVj dGl2ZXMNUGFyYW1ldGVyB1JlcXVpcmVtZW50KHMpB09iamVjdGl2ZShzKQcHDVNwZWVjaCBxdWFs aXR5IGluIGNsZWFuIGNvbmRpdGlvbnMNBw1UcmFuc3BhcmVudAcHB1BlcmZvcm1hbmNlIGluIHRo ZSBwcmVzZW5jZSBvZiBiYWNrZ3JvdW5kIG5vaXNlOg0tIEJhYmJsZSBOb2lzZSBhdCBhIFNOUiBv ZiB4IGRCDS0gT2ZmaWNlIE5vaXNlIGF0IGFuIFNOUiBvZiB4IGRCDS0gTGluZSBOb2lzZSBhdCBh biBTTlIgb2YgeCBkQg0tIFN0cmVldCBOb2lzZSBhdCBhbiBTTlIgb2YgeCBkQgcNDUVxdWl2YWxl bnQgdG8gRy43MjkgQ05HMSwgeD0NRXF1aXZhbGVudCB0byBHLjcyOSBDTkcxLCB4PQ1FcXVpdmFs ZW50IHRvIEcuNzI5IENORzEsIHg9DUVxdWl2YWxlbnQgdG8gRy43MjkgQ05HMSwgeD0HDQ1FcXVp dmFsZW50IHRvIEcuNzExMg1FcXVpdmFsZW50IHRvIEcuNzExMg1FcXVpdmFsZW50IHRvIEcuNzEx Mg1FcXVpdmFsZW50IHRvIEcuNzExMg0HBw1Db21wbGV4aXR5Mw0HDTwgMS4wIE1JUFM0Bw1BcyBs b3cgYXMgcG9zc2libGUHBw1NZW1vcnkNLSBSQU0NLSBST00NBw0NPCAxLjAga3dvcmRzDTwgMi4w IGt3b3JkcwcNDUFzIGxvdyBhcyBwb3NzaWJsZQ1BcyBsb3cgYXMgcG9zc2libGUNBwcNRGVsYXkH DRNzeW1ib2wgMTYzIFxmICJTeW1ib2wiIFxzIDEwFKMVIDMgbXMNBw1BcyBsb3cgYXMgcG9zc2li bGUHBw1JbXBsZW1lbnRhdGlvbg0HDUJpdCBleGFjdCAxNi1iaXQgZml4ZWQtcG9pbnQHDQcHDVNh bXBsaW5nIFJhdGUHDTguMCBrSHoNBwcHDVBheWxvYWQgU2l6ZQ0HDU9jdGV0IE11bHRpcGxlNQcN QXMgbG93IGFzIHBvc3NpYmxlBwcNTm90ZXMNMS4gU2luY2UgRy43MjlBIGFuZCBHLjcyMy4xIGFy ZSB0aGUgb3RoZXIgcHJpbWFyeSBjb2RlY3MgdXNlZCBpbiBWb0lQLCB0aGUgcXVhbGl0eSBvZiB0 aGUgQ05HIHNob3VsZCBiZSBjb25zaXN0ZW50IHdpdGggdGhhdCBwcm9kdWNlZCBieSB0aGUgQ05H IG9mIHRoZXNlIGNvZGVjcy4NDTIuIFRoZSBwcm9wb3NlZCBDTkcgaXMgZXF1aXZhbGVudCB0byBH LjcxMS4NDTMuIENvbXBsZXhpdHkgb3BlcmF0aW5nIHdpdGggNW1zIGZyYW1lcy4NDTQuIFNpbmNl IEcuNzExIGlzIHRoZSBwcmltYXJ5IGNvZGVjIGluIFZvSVAgd2l0aG91dCBDTkcgY2FwYWJpbGl0 aWVzLCB0aGUgY29tcGxleGl0eSBvZiB0aGUgQ05HIGFuYWx5c2lzL3N5bnRoZXNpcyBzaG91bGQg YmUgaW4gdGhlIG9yZGVyIHRoZSBjb21wbGV4aXR5IG9mIEcuNzExLiANDTUuDVNjaGVkdWxlIA0N VEJELg0NUmVmZXJlbmNlcw0NWzFdIJNJc3N1ZXMgd2l0aCBHLjcxMSBTRC9DTkcslCBMaWFpc29u IFN0YXRlbWVudCwgRG9jdW1lbnQgQUMtOTktMDEwLCBTdHVkeSBHcm91cCAxNiBRLjE5LTIxLzE2 IFJhcHBvcnRldXIgTWVldGluZywgR2VuZXZhIDI3LTI5IFNlcHRlbWJlciAxOTk5Lg0NKiBQcmlu Y2lwYWwgY29udGFjdDoNTmFtZTogUm9iZXJ0IFpvcGYHVGVsOiAoNzMyKSA1NzgtMzIwNwcHQ29t cGFueTogTHVjZW50IFRlY2hub2xvZ2llcwdGYXg6ICg3MzIpIDU3OC0zMjEzBwcHRW1haWw6em9w ZkBsdWNlbnQuY29tBwcNDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAALQQAAC4E AAAvBAAAMAQAAEsEAABNBAAAUwQAAFQEAABWBAAAXwQAAGAEAABiBAAAaQQAALEEAACyBAAAtAQA AM0HAADnBwAATAgAAIoIAACaCQAAwAkAAMAKAADBCgAA3QoAAN4KAAD6CgAA+woAABcLAAAYCwAA MgsAADMLAABHCwAASAsAAFwLAABdCwAAcQsAAHILAACACwAAgQsAAI4LAACPCwAACAwAAAkMAAAl DAAAJgwAACcMAAAoDAAAxwwAAIsOAAAfDwAAIA8AAEkPAABMDwAApg8AAKcPAACoDwAAfCoAAH4q AAAGLQAACi0AABQtAAAWLQAARC0AAEgtAABSLQAAVC0AAHwtAAB6LgAAfC4AAPvz+wDwAPvq+/D7 8Pvw+/AA5d/lANnUztTO1M7UztTO1M7UztTO1M7UztTF1MXAxdQA1Lu4s7gA1ADUAOXf5d/l3+UA 1M4AAAAACENKEgBtSAAEAARDShIAAAgwShEAQ0oSAAAIT0oBAFFKAQAAEQNqAAAAAE9KAABRSgAA VQgBC0gqAU9KAABRSgAACE9KAABRSgAAAAs1CIFPSgAAUUoAAAtQSgMAbkgRBG8oAQhQSgMAbkgR BAALMEoRADUIgUNKGAAEQ0oYAAAPNQiBQ0oYAFBKAwBuSBEEBzUIgUNKGAAARgAEAAAtBAAALgQA AC8EAAAwBAAAPwQAAEsEAABMBAAATQQAAFYEAABeBAAAXwQAAGAEAABhBAAAYgQAAGkEAACwBAAA sQQAALIEAACzBAAAtAQAALUEAAC2BAAAwwQAAMQEAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AOAAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAA AAAAAAAAAAAA3QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA0QwAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA0TwBAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA0QwAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAN0AAAAAAAAAAAAA AAADAQAxJAEMAAAWJAEXJAEClmwACNYIAAKU/wgHKCMDAAAxJAEAGQAAFiQBFyQBApZsAAXWGAYB AAAGAQAABgEAAAYBAAAGAQAABgEAAAjWCAAClP/2GDYkAAQAADEkARYkAQAYAAQAAC0EAAAuBAAA LwQAADAEAAA/BAAASwQAAEwEAABNBAAAVgQAAF4EAABfBAAAYAQAAGEEAABiBAAAaQQAALAEAACx BAAAsgQAALMEAAC0BAAAtQQAALYEAADDBAAAxAQAAGMFAABuBQAAbwUAAMwHAADNBwAA/QgAAAoJ AAALCQAAdAkAAJoJAACkCQAAswkAAMAJAADBCQAAwgkAAOUJAADmCQAA5wkAAPMJAAD0CQAA9QkA ACYKAABGCgAAZwoAAIYKAACnCgAAqAoAAKkKAADGCgAA/f37AAAAAAD9/fv9/fv9/fv9/fsAAPj1 8vjv7Onm+PXy+OHc19POycS/urWxrKWgm5aRjIcACQMBBQoGy/7//wkDAQUKBsz+//8JAwEFCgbN /v//CQMBBQoG7v7//wkDAQUKBg3///8JAwEFCgYu////DAIQAAMBBQoGTv///wAJAwEFCgZ///// BwMBBoD///8JAwEFCgaB////CQMBBQoGjf///wkDAQUKBo7///8JAwEFCgaP////CQMBBQoGsv// /wkDAQUKBrP///8HAwEGtP///wkDAQUKBsH///8JAwEFCgbQ////CQMBBQoG2v///wUGlv3//wUG l/3//wUG9P///wUG9f///wUG8v///wUG8////wUCAQAFAAIDAQAEAwEFCjXEBAAAYwUAAG4FAABv BQAAzAcAAM0HAAD9CAAACgkAAAsJAAB0CQAAmgkAAKQJAACzCQAAwAkAAMEJAADCCQAA5QkAAOYJ AADnCQAA8wkAAPQJAAD8AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/AAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAAu9AAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAWJAEXJAEClmwABdYYBgEAAAYBAAAGAQAABgEAAAYBAAAG AQAACNZGAAOU/50LphevIwAAAAAMAQAADAEAAAwBAAAMAQAAAAAAAAwBAAD/////DAEAAAwBAAAA AAAADAEAAP////8MAQAADAEAAAAEAAAxJAEWJAEDAQAxJAEDAAAxJAEAFPQJAAD1CQAAJgoAAEYK AABnCgAAhgoAAKcKAACoCgAAqQoAAMYKAADjCgAAAAsAAB0LAAAeCwAAHwsAADQLAABJCwAAXgsA AHMLAAB0CwAAxgAGAAAAAAAAAAAAAMEAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAwQAAAAAAAAAA AAAAAMEAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAADB AAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAA AAAAAAAAAMEAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAA AADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABBAAMSQBFiQBAAQAADEkARYkAQA4AAAWJAEXJAEClmwABdYY BgEAAAYBAAAGAQAABgEAAAYBAAAGAQAACNZGAAOU/50LphevIwAAAAD/////AAAAAAAAAAAAAAAA AAAAAP////8AAAAAAAAAAAAAAAAAAAAA/////wAAAAAAAAAAAAAAAAATxgoAAOMKAAAACwAAHQsA AB4LAAAfCwAANAsAAEkLAABeCwAAcwsAAHQLAAB1CwAAdgsAAIILAACDCwAAhAsAAJALAACRCwAA pAsAAKULAACmCwAArQsAALMLAAC5CwAAugsAALsLAAC8CwAAyQsAANYLAADXCwAA2AsAAOsLAAD+ CwAA/wsAAAAMAAD69fDr5uHc19LNycS/urWwq6ainZiTjomEf3p1cGtmYVxYAAAHAwEGdf3//wkD AQUKBnb9//8JAwEFCgaJ/f//CQMBBQoGnP3//wkDAQUKBp39//8JAwEFCgae/f//CQMBBQoGq/3/ /wkDAQUKBrj9//8JAwEFCga5/f//CQMBBQoGuv3//wkDAQUKBrv9//8JAwEFCgbB/f//CQMBBQoG x/3//wkDAQUKBs79//8JAwEFCgbP/f//BwMBBtD9//8JAwEFCgbj/f//CQMBBQoG5P3//wkDAQUK BvD9//8JAwEFCgbx/f//CQMBBQoG8v3//wkDAQUKBv79//8JAwEFCgb//f//BwMBBgD+//8JAwEF CgYB/v//CQMBBQoGFv7//wkDAQUKBiv+//8JAwEFCgZA/v//CQMBBQoGVf7//wkDAQUKBlb+//8J AwEFCgZX/v//CQMBBQoGdP7//wkDAQUKBpH+//8JAwEFCgau/v//ACJ0CwAAdQsAAHYLAACCCwAA gwsAAIQLAACQCwAAkQsAAKQLAAClCwAApgsAAK0LAACzCwAAuQsAALoLAAC7CwAAvAsAAMkLAADW CwAA1wsAANgLAADrCwAA/gsAAP8LAAAADAAAAQwAAAcMAADkwAAAAAAAAAAAAAAA3wAAAAAAAAAA AAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADf AAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAORsAQAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3wAAAAAA AAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAA AADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3wAA AAAAAAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAOQQAQAAAAAA AAAAAADfAAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAAAEAAAxJAEWJAEAGgAAFiQBFyQBApZsAAXW GAYBAAAGAQAABgEAAAYBAAAGAQAABgEAAAjWCgADlP+dC6YXryMAGgAMAAABDAAABwwAAAgMAAAu DAAALwwAADAMAABDDAAARAwAAEUMAABUDAAAVQwAAFYMAABzDAAAdAwAAHUMAAB2DAAAdwwAAIUM AACGDAAAjgwAAI8MAACQDAAAkQwAAJIMAACfDAAAoAwAAKEMAACvDAAAsAwAALEMAACyDAAAxQwA AMYMAADHDAAAzQwAAG8NAABwDQAAnA0AAJ0NAAD69fDr5uHc2NPOycS/urWxrKeinZiTj4qFgHt5 eXl2dnQAcW5raGUAAAAFBiz///8FBlj///8FBln///8FBvv///8FAgEABQACAwEABAMBBQoAAgEB AAkDAQUKBtT8//8JAwEFCgbV/P//CQMBBQoG4vz//wkDAQUKBuP8//8HAwEG5Pz//wkDAQUKBuX8 //8JAwEFCgbm/P//CQMBBQoG7vz//wkDAQUKBu/8//8JAwEFCgb9/P//CQMBBQoG/vz//wcDAQb/ /P//CQMBBQoGAP3//wkDAQUKBgH9//8JAwEFCgYe/f//CQMBBQoGH/3//wkDAQUKBiD9//8JAwEF CgYv/f//CQMBBQoGMP3//wcDAQYx/f//CQMBBQoGRP3//wkDAQUKBkX9//8JAwEFCgZG/f//CQMB BQoGbP3//wkDAQUKBm39//8JAwEFCgZz/f//CQMBBQoGdP3//wAnBwwAAAgMAAAuDAAALwwAADAM AABDDAAARAwAAEUMAABUDAAAVQwAAFYMAABzDAAAdAwAAHUMAAB2DAAAdwwAAIUMAACGDAAAjgwA AI8MAACQDAAAkQwAAJIMAACfDAAAoAwAAKEMAACxDAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADfyAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAN9sAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAADf1AAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAGgAAFiQBFyQBApZsAAXWGAYBAAAGAQAABgEA AAYBAAAGAQAABgEAAAjWCgADlP+dC6YXryMABAAAMSQBFiQBABqxDAAAsgwAAMUMAADGDAAAxwwA AM0MAABvDQAAcA0AAJwNAACdDQAAxg0AAMcNAABrDgAAbA4AAG8OAAB5DgAAeg4AAH8OAACADgAA iw4AAIwOAAAeDwAAHw8AADQPAABGDwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADfAAAAAAAA AAAAAAAA3AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAA ANwAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAA AAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA3AAAAAAAAAAA AAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADc AAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAAAAABBAA MSQBFiQBAxAAMSQBAAEBAAMBADEkAQMAADEkAQAaAAAWJAEXJAEClmwABdYYBgEAAAYBAAAGAQAA BgEAAAYBAAAGAQAACNYKAAOU/50LphevIwAEAAAxJAEWJAEAGJ0NAADGDQAAxw0AAGsOAABsDgAA bw4AAHkOAAB6DgAAfw4AAIAOAACLDgAAjA4AAB4PAAAfDwAANA8AAEYPAABaDwAAWw8AAHgPAACM DwAAjQ8AAI4PAACkDwAApQ8AAKYPAACnDwAAqA8AAPz59gAA8wAAAPPw7QDr5+fl5+fl5+flAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgMBAAcCEAADAQUKAwIQAAUG qP///wUGqf///wUCAQAFAAUGAf///wUGAv///wUGK////wAaRg8AAFoPAABbDwAAeA8AAIwPAACN DwAAjg8AAKQPAAClDwAApg8AAKcPAACoDwAAfioAAAQtAAAGLQAAqC0AAKotAACwLQAAsi0AANwt AADeLQAA4C0AAOItAAAmLgAAKC4AACouAACmLgAA+gAAAAAAAAAAAAAAAO7IAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAO5gAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAO4AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAA AAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAA AAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA 5AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAADEkARYkAQABAAADAAAxJAEM AAAWJAEXJAEClmwACNYIAAK0ANoWkCQABBAAMSQBFiQBABogABxQAQAfsIUuILDCQSGwoAUisKAF I5AQBSSQEAUlsAAAcwBjAGgAZQBtAGUAIABmAG8AcgAgAHUAcwBlACAAdwBpAHQAaAAgAG8AbQBt AHUAbgBpAGMAYQB0AGkAbwBuACAAcwBlAHMAcwBpAG8AbgAgAGYAbwByACAADQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwuAACkLgAAsC4AAE4wAABQMAAA0DcA AGg4AABqOAAAujgAAL44AABSOQAAojoAAKQ6AACuPQAAsD0AACI+AAAsPgAAPj4AAHw+AAAEQgAA DkIAAFZEAABYRAAAOEYAADpGAAAISAAAQEoAABpMAAAWTgAAGE4AAB5QAAAgUAAAAlIAADpUAAA8 VAAAAPsA+wD79fv1+wD7APsA+wD7APsA+wD7+/v78vsA+/sA+wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEQ0oYAAALSCoBT0oAAFFKAAAIT0oAAFFKAAAipi4AAFAwAAAUNgAAzjcAANA3AADmNwAA KjgAAFQ4AABsOAAAbjgAAJI4AACUOAAAljgAAN44AABOOQAAUDkAAFI5AACkOgAAQDwAALA9AAAk PgAAJj4AACg+AAAqPgAA/AAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADlAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAytAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAAFiQBFyQBApZsAAXWGAYB AAAGAQAABgEAAAYBAAAGAQAABgEAAAjWCgADlP+dC6YXryMABBAAMSQBFiQBCAAACiYAC0YCADEk ARYkAQAEAAAxJAEWJAEAAQAAAwEAMSQBAwAAMSQBABdmAHIAYQBtAGUAIABzAGkAegBlAHMAIABh AG4AZAAgAHMAYQBtAHAAbABpAG4AZwAgAHIAYQB0AGUAcwAuAA0ARQB4AGEAYwB0ACAAaQBtAHAA bABlAG0AZQBuAHQAYQB0AGkAbwBuAHMAIABiAGEAcwBlAGQAIABvAG4AIAB0AGgAZQAgAHAAYQB5 AGwAbwBhAGQAIABmAG8AcgBtAGEAdAAgAGEAcgBlACAAbABlAGYAdAAgAHUAbgBzAHAAZQBjAGkA ZgBpAGUAZAAuACAAIABIAG8AdwBlAHYAZQByACwAIABhAG4AIABpAG0AcABsAGUAbQBlAG4AdABh AHQAaQBvAG4AIABtAGUAZQB0AGkAbgBnACAAdABoAGUAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQA cwAgAGEAbgBkACAAbwBiAGoAZQBjAHQAaQB2AGUAcwAgAGIAZQBsAG8AdwAgAHMAaABvAHUAbABk ACAAYgBlACAAZABlAG0AbwBuAHMAdAByAGEAdABlAGQAIABhAG4AZAAgAGQAZQBzAGMAcgBpAGIA ZQBkAC4ADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAaABlACAAcgBlAHEAdQBpAHIAZQBtAGUA bgB0AHMAIAANAA0ADQANAA0AUwBjAGgAZQBkAHUAbABlACAAIABHAGUAbgBlAHYAYQAgADIANwAt ADIAOQAgAFMAZQBwAHQAZQBtAGIAZQByACAAMQA5ADkAOQAuAA0ADQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKj4AACw+AAB6PgAAfD4AAAZCAAAIQgAACkIA AAxCAAAOQgAAWEQAADpGAAAISAAAPEoAAD5KAABASgAAGkwAABhOAAAgUAAAAlIAADxUAAD6AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADAAAxJAEABAAAMSQBFiQBABN8LgAApC4AALAuAABOMAAAUDAAANA3AABoOAAA ajgAALo4AAC+OAAAUjkAAKI6AACkOgAArj0AALA9AAAiPgAALD4AAD4+AAB8PgAABEIAAA5CAABW RAAAWEQAADhGAAA6RgAACEgAAEBKAAAaTAAAFk4AABhOAAAeUAAAIFAAAAJSAAAA+wD7APv1+/X7 APsA+wD7APsA+wD7APv7+/vy+wD7+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BENKGAAAC0gqAU9KAABRSgAACE9KAABRSgAAICo+AAAsPgAAej4AAHw+AAAGQgAACEIAAApCAAAM QgAADkIAAFhEAAA6RgAACEgAADxKAAA+SgAAQEoAABpMAAAYTgAAIFAAAAJSAAD6AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAwAAMSQBAAQAADEkARYkAQASPAAgADEADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0AGgAZQAgAGIAYQBjAGsAZwByAG8AdQBuAGQAIABu AG8AaQBzAGUAIABpAHMAIAByAGUAcAByAGUAcwBlAG4AdABlAGQAIABiAHkAIAB0AGgAZQAgAEMA TgAgAHAAYQB5AGwAbwBhAGQAIABkAGUAcwBjAHIAaQBiAGUAZAAgAGkAbgAgAFsAMgBdAC4AIAAg AFQAaABpAHMAIABwAGEAeQBsAG8AYQBkACAAcAByAG8AdgBpAGQAZQBzACAAbwBuAGwAeQAgAGEA IABkAGUAcwBjAHIAaQBwAHQAaQBvAG4AIABvAGYAIAAgAGEAbgBkACAAYQBzACAAcwB1AGMAaAAN AA0AYQAgAHUAZAB5ACAAbwBmACAAQwBvAG0AZgBvAHIAdAAgAE4AbwBpAHMAZQAgAEcAZQBuAGUA cgBhAHQAaQBvAG4AIABmAG8AcgAgAHMAcwBlACAAdwBpAHQAaABpAG4AIABIAC4AMwAyADMAIABm AG8AcgAgADgALgAwACAAawBIAHoAIABTAGEAbQBwAGwAaQBuAGcAIABSAGEAdABlAA0ADQAtACAA DQANAE8AdABoAGUAcgAgAFMAYQBtAHAAbABpAG4AZwAgAFIAYQB0AGUAcwANAA0ADQANAEQAZQBt AG8AbgBzAHQAcgBhAHQAZQAgAGMAYQBwAGEAYgBpAGwAaQB0AHkAIAB0AG8AIABvAHAAZQByAGEA dABlAA0ADQANAEYAbwByACAAZgB1AHIAdABoAGUAcgAgAHMAdAB1AGQAeQAuAFYAYQByAGkAYQBi AGwAZQBPAGMAdABlAHQAIABNAHUAbAB0AGkAcABsAGUANQAgAGEAdAAgADgALgAwACAAawBIAHoA IABzAGEAbQBwAGwAaQBuAGcADQBbADIAXQAgABwgUgBUAFAAIABQAHIAbwBmAGkAbABlACAAZgBv AHIAIABBAHUAZABpAG8AIABhAG4AZAAgAFYAaQBkAGUAbwAgAEMAbwBuAGYAZQByAGUAbgBjAGUA cwAgAHcAaQB0AGgAIABNAGkAbgBpAG0AYQBsACAAQwBvAG4AdAByAG8AbAAsACIAIABIAC4AIABT AGMAaAB1AGwAegByAGkAbgBuAGUAIAAsACAAUwAuACAAQwBhAHMAbgBlAHIALAAgAGQAcgBhAGYA dAAtAGkAZQB0AGYALQBhAHYAdAAtAHAAcgBvAGYAaQBsAGUALQBuAGUAdwAtADAANgAuAHQAeAB0 ACwAIABJAG4AdABlAHIAbgBlAHQAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABUAGEAcwBrACAA RgBvAHIAYwBlACwAIABKAHUAbgBlACAAMQA5ADkAOQAuACAATgBvAHQAZQA6ACAAdABoAGkAcwAg AGkAcwAgABwgdwBvAHIAawAgAGkAbgAgAHAAcgBvAGcAcgBlAHMAcwAdIC4ADQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ACAAMgA8ACAAMQAuADAAIABNAEkAUAANAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEALgAxADkALQAyADEALwAxADYAIAANAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASABIACgABAFsADwACAAAAAAAAADYAAEDx/wIANgAAAAYATgBv AHIAbQBhAGwAAAAIAAAAAyQDMSQAEABPSgIAUUoCAGtI5ARtSAkEPgABQAEAAgA+AAAACQBIAGUA YQBkAGkAbgBnACAAMQAAAA0AAQAGJAETpPAAFKQ8AAALADUIgUNKHABLSBwAAC4AAgABAAIALgAA AAkASABlAGEAZABpAG4AZwAgADIAAAAFAAIABiQBAAMANQiBAAAAAAAAAAAAAAAAAAAAPABBQPL/ oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAA AAAAAAAAADIA/g8BAPIAMgAAAAcASQBuAGYAbwBkAG8AYwAAAA0ADwAFJAENxgUAAacEAAAEAENK FgAuAB1AAQACAS4AAAANAEYAbwBvAHQAbgBvAHQAZQAgAFQAZQB4AHQAAAACABAAAAA8ACZAogAR ATwAAAASAEYAbwBvAHQAbgBvAHQAZQAgAFIAZQBmAGUAcgBlAG4AYwBlAAAABwBDShQASCoBAFIA AABbDwAAAAAAAAAAhwAAAIoAAAACAAAAAAD//wEAAAAAABAA//8CAAAAAAAAAAAAhwAAAIoAAAAA AAAAAAABAAAAAAAAAAAAWw8AAAUAACoAAAUA/////wIAAACEIf//AQAAAAAAgCH//wIAAAAAAAAA AAB8BwAA8AcAAC8IAACpCAAA2AgAACwJAAAtCQAAWw8AAAAAAAAAAQEAAAAAAQAAqQAAAQEAsAEA AQAAXAAAAQEAsAEAAQAARAAAAQEAAQAAAQAAAAAtAAAALgAAAC8AAAAwAAAAPwAAAEsAAABMAAAA VQAAAF0AAABeAAAAXwAAAGAAAABhAAAAaAAAAK8AAACwAAAAvQAAAL4AAAB8AQAAhwEAAIgBAAA4 AwAAOQMAAF4EAABrBAAAyAQAAO4EAADsBQAA7QUAAJYGAACXBgAAoQYAALAGAAC9BgAAvgYAAL8G AADiBgAA4wYAAOQGAADwBgAA8QYAAPIGAADzBgAAJAcAACUHAAA7BwAAWwcAAHwHAACbBwAAvAcA ANoHAADbBwAA8AcAAPEHAADyBwAA8wcAAPQHAAD1BwAAEggAAC8IAABMCAAAaQgAAIYIAACHCAAA qQgAAKoIAACrCAAArAgAAK0IAACuCAAAwwgAANgIAADtCAAAAgkAABcJAAAYCQAAKwkAACwJAAAt CQAALgkAADkJAABbCQAAcAkAAHEJAAByCQAAcwkAAH8JAACACQAAkgkAAJMJAACUCQAAnwkAAKAJ AACzCQAAtAkAALUJAAC8CQAAwgkAAMgJAADJCQAAygkAAMsJAADZCQAA5wkAAOgJAADpCQAA/AkA AA8KAAAQCgAAEQoAABIKAAAYCgAAGQoAAD8KAABACgAAQQoAAFQKAABVCgAAVgoAAGQKAABlCgAA bgoAAG8KAABwCgAAcQoAAH8KAAC3CgAAuAoAALkKAAC6CgAAxwoAAMgKAADJCgAA2AoAANkKAADs CgAA7QoAAO4KAAD0CgAAlgsAAJcLAADDCwAAxAsAAAEMAAACDAAAwwwAAMQMAABODQAAWA0AAF0N AABeDQAAaQ0AAGoNAAD8DQAA/Q0AANIOAADnDgAA+Q4AAA0PAAAODwAAKw8AAD8PAABADwAAQQ8A AFcPAABYDwAAXA8AABABAACKGAAAYMoCABABAABoCgAAYMoCAAAAAAAAAAAAYMoCAAABAABFIwAA UFMCAAABAABFIwAAYMoCAAABAABFIwAAYMoCAAABAABFIwAAUFMCABABAACcBgAAYMoCABABAABI GwAAYMoCAAAAAAAAAAAAYMoCABABAACcBgAAYMoCABABAABIGwAAYMoCAAAAAAAAAAAAYMoCABAB AACcBgAAYMoCABACAABIGwAAYMoCAAAAAAAAAAAAwJQFAAABAABFIwAAcEEDAAABAABFIwAAUFMC AAACAABFIwAAUFMCAAABAABFIwAAcEEDAAABAABFIwAAUFMCAAAFAABFIwAAUFMCAAABAABFIwAA UFMCAAADAABFIwAAUFMCAAABAABFIwAAcEEDAAABAABFIwAAUFMCAAABAABFIwAAcEEDAAADAABF IwAAUFMCAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA 8PkGAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAAEDseAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAAAAAAAAAAA4PMNAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAAAAAAAAAAAkKALAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAzJQCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA bDsHAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA8PkGAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAAAAAAAAAAAoKYEAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA 8PkGAAABAABFIwAAUFMCAAABAABFIwAAcEEDAAACAABFIwAAUFMCAAABAABFIwAAUFMCAAABAABF IwAAUFMCAAABAABFIwAAUFMCAAABAABFIwAAUFMCAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAAB AABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAcEEDAAABAABFIwAAUFMCAAABAABFIwAAUFMC AAABAABFIwAAcEEDAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAUFMCAAT/AABFIwAA wBEHAAABAABFIwAAyBcCAAABAABOFQAAyBcCAAABAADeDAAAyBcCAAAAAAAAAAAAyBcCAAABAABO FQAAyBcCAAABAADeDAAAyBcCAAAAAAAAAAAAyBcCAAABAABOFQAAyBcCAAABAADeDAAAyBcCAAAA AAAAAAAAyBcCAAABAABFIwAAyBcCAAAAAAA/AAAASwAAALAAAAC9AAAAvgAAAHwBAACIAQAAOAMA ADkDAABeBAAAawQAAMgEAADuBAAA7AUAAO0FAACWBgAAlwYAAKEGAACwBgAAvQYAAL4GAAC/BgAA 4gYAAOMGAADkBgAA8AYAAPEGAADyBgAA8wYAACQHAAAlBwAAOwcAAFsHAAB8BwAAmwcAALwHAADa BwAA2wcAAPAHAADxBwAA8gcAAPMHAAD0BwAA9QcAABIIAAAvCAAATAgAAGkIAACGCAAAhwgAAKkI AACqCAAAqwgAAKwIAACtCAAArggAAMMIAADYCAAA7QgAAAIJAAAXCQAAGAkAACsJAAAsCQAALQkA AC4JAAA5CQAAWwkAAHAJAABxCQAAcgkAAHMJAAB/CQAAgAkAAJIJAACTCQAAlAkAAJ8JAACgCQAA swkAALQJAAC1CQAAvAkAAMIJAADICQAAyQkAAMoJAADLCQAA2QkAAOcJAADoCQAA6QkAAPwJAAAP CgAAEAoAABEKAAASCgAAGAoAABkKAAA/CgAAQAoAAEEKAABUCgAAVQoAAFYKAABkCgAAZQoAAG4K AABvCgAAcAoAAHEKAAB/CgAAtwoAALgKAAC5CgAAugoAAMcKAADICgAAyQoAANgKAADZCgAA7AoA AO0KAADuCgAA9AoAAJYLAACXCwAAwwsAAMQLAAABDAAAAgwAAMMMAADEDAAATg0AAFgNAABdDQAA Xg0AAGkNAABqDQAA/A0AAP0NAABcDwAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAA AACAngAAAAAAAAAAAAAAAIAAAACACAAAAAEAAAAAAAAAAIAAAACAngAAAAAAAAAAAAAAAIAAAACA mAAAAAAAAAAAAAAAAICwAAAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAA AAAAAAAAAAAAAIB8AQAAmAAAAAAAAAAAAAAAAIB8AQAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAA AAAAAAAAAIBZBAAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIDDBAAAmAAAAAAAAAAA AAAAAIDDBAAAmAAAAAAAAAAAAAAAAIDDBAAAmAAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAA AAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAA AAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAABAAAAAAAAAAAIDDBAAAqQAAAAAAAAAA AAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAA AAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAA AAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAA AAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDDBAAAqQAA AAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQACIAAAAAAAAAAAAIDDBAAAqQACIAAA AQAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAA AAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAABAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAA AAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAA AAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAA AAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAA AAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAA AAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAA AAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAA AIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDD BAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAA qQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAqQAAAAAAAAAAAAAAAIDDBAAAmQAA AAAAAAAAAAAAAIDDBAAAmAAAAAAAAAAAAAAAAIDDBAAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAA AAAAAAAAAIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAAmAAAAAAAAAAA AAAAAIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAAmAAAAAAAAAAAAAAA AIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAAmAAAAAAAAAAAAAAAAIDpCgAACAAAAAEAAAAAAAAAAIAA AACAmAAAAAAAAAAAAAAAAIBJDQAAmAAAAAAAAAAAAAAAAIBJDQAAmgAAAAAAAAAAAAAAAIAAAACA mAAAAAAAAAAAAAAAAIBZDQAAmAAAAAAAAAAAAAAAAIBZDQAAmAAAAAAAAAAAAAAAAIBZDQAAmAAA AAAAAAAAAAAAAIBZDQAAAAQAAHwuAAAgUAAACQAAABkAAAAABAAAxAQAAPQJAAB0CwAABwwAALEM AABGDwAApi4AACo+AAAgUAAACgAAAAwAAAANAAAADwAAABEAAAASAAAAFAAAABoAAAAgAAAAAAQA AMYKAAAADAAAnQ0AAKgPAAALAAAADgAAABAAAAATAAAA//8QAAAABwBVAG4AawBuAG8AdwBuABAA RwB1AG4AbgBhAHIAIABIAGUAbABsAHMAdAByAPYAbQANAFAAYQB1AGwAIABFAC4AIABKAG8AbgBl AHMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAAQAaABhAHkA YQAOAFQAYQBrAGEAcwBoAGkAIABTAHUAegB1AGsAaQAMAFMAaQBtAGEAbwAgAEMAYQBtAHAAbwBz ABYASgBvAGEAbgAgACYAIABKAGUAcgByAHkAIABTAGgAcgBpAG0AcAB0AG8AbgAQAEQAZQBiAG8A cgBhAGgAIABCAHIAdQBuAGcAYQByAGQAEwBhAG4AdABvAG4AaQBhAHoAegBpACAAZwBpAG8AdgBh AG4AbgBhAA8AQQBsACAAUwB1AGEAcgBlAHoAIABEAGEAeQBhAG8AGQBNAGEAcgBpAGUAIABBAG4A dABvAGkAbgBlAHQAdABlACAAQgAuACAAUgBhAG0AbwBzAAkAVQBuAGIAZQBrAGEAbgBuAHQADgBT ACAASgAgAFQAcgBvAHcAYgByAGkAZABnAGUAEwBMAHUAYwBlAG4AdAAgAFQAZQBjAGgAbgBvAGwA bwBnAGkAZQBzABQAUgBvAG4AbgBpAGUAIABCAC4AIABUAHIAbwB3AGIAcgBpAGQAZwBlABkKAAA2 CgAAOAoAAFsPAAATOZT/lYAAAAAAzAMAANgDAAA1CwAAOQsAACkMAAAtDAAASA4AAFMOAABZDgAA Xw4AANIOAAD0DgAA+A4AAFwPAAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcAAAAAAHwCAADD AgAAWA0AAFwNAABIDgAAVQ4AANIOAABcDwAABwAaAAcAGgAHABoABwAHAP//FAAAABYAQQBzAGMA ZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgBJAEMAOgBcAHoAbwBwAGYAXABE AG8AYwBzAFwAaQB0AHUAXABzAHQAYQBuAGQAYQByAGQAaQB6AGEAdABpAG8AbgBfAGUAZgBmAG8A cgB0AHMAXABHADcAMQAxAF8AYwBuAGcAKABRADEAOQApAFwARAByAGEAZgB0AF8AQwBOAEcAXwBU AG8AUgAyAC4AZABvAGMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMA ZQByAC8AQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAg AG8AZgAgAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGEAcwBkABYAQQBzAGMAZQBuAGQA IABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgBJAEMAOgBcAHoAbwBwAGYAXABEAG8AYwBz AFwAaQB0AHUAXABzAHQAYQBuAGQAYQByAGQAaQB6AGEAdABpAG8AbgBfAGUAZgBmAG8AcgB0AHMA XABHADcAMQAxAF8AYwBuAGcAKABRADEAOQApAFwARAByAGEAZgB0AF8AQwBOAEcAXwBUAG8AUgAy AC4AZABvAGMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAC8A QwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAg AEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGEAcwBkABYAQQBzAGMAZQBuAGQAIABBAHUA dABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBj AG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBmAHQAXwBDAE4ARwBfAFQAbwBSADIA LgBhAHMAZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIASQBD ADoAXAB6AG8AcABmAFwARABvAGMAcwBcAGkAdAB1AFwAcwB0AGEAbgBkAGEAcgBkAGkAegBhAHQA aQBvAG4AXwBlAGYAZgBvAHIAdABzAFwARwA3ADEAMQBfAGMAbgBnACgAUQAxADkAKQBcAEQAcgBh AGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGQAbwBjABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8A cgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBl AHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBmAHQAXwBDAE4ARwBfAFQAbwBSADIALgBhAHMA ZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIALwBDADoAXABU AEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARAByAGEA ZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AYQBzAGQAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwBy AGkAegBlAGQAIABVAHMAZQByAEkAQwA6AFwAegBvAHAAZgBcAEQAbwBjAHMAXABpAHQAdQBcAHMA dABhAG4AZABhAHIAZABpAHoAYQB0AGkAbwBuAF8AZQBmAGYAbwByAHQAcwBcAEcANwAxADEAXwBj AG4AbABpAGMAYQB0AGkAbwBuAHMADQBUAGgAZQAgAG8AYgBqAGUAYwB0AGkAdgBlACAAbwBmACAA dABoAGkAcwAgAHcAbwByAGsAIABpAHMAIAB0AG8AIABkAGUAZgBpAG4AZQAgAGEAIABwAGEAeQBs AG8AYQBkACAAZgBvAHIAbQBhAHQAIAB0AGgAYQB0ACAAaQBzACAAZgBsAGUAeABpAGIAbABlACAA ZgBvAHIAIAB1AHMAZQAgAHcAaQB0AGgAIABhAG4AeQAgAGMAbwBkAGUAYwAgAHcAaQB0AGgAbwB1 AHQAIABiAHUAaQBsAHQALQBpAG4AIABDAE4ARwAgAGMAYQBwAGEAYgBpAGwAaQB0AGkAZQBzAC4A IAAgAEkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzACAAYgBhAHMAZQBkACAAbwBuACAAdABo AGUAIABwAGEAeQBsAG8AYQBkACAAZgBvAHIAbQBhAHQAIABzAGgAbwB1AGwAZAAgAGIAZQAgAGMA YQBwAGEAYgBsAGUAIABvAGYAIABvAHAAZQByAGEAdABpAG4AZwAgAGEAdAAgAG0AdQBsAHQAaQBw AGwAZQAgAA0ADQBDAG8AbQBwAGwAZQB4AGkAdAB5AA0AOAAuADAAIABrAEgAegAgAHMAYQBtAHAA bABpAG4AZwAgAHIAYQB0AGUALAAgADUAbQBzACAAZgByAGEAbQBlAHMADQBPAHQAaABlAHIAIABz AGEAbQBwAGwAaQBuAGcAIAByAGEAdABlAHMADQA8ACAAMQAuADAAIABNAEkAUABTADQADQANAEYA bwByACAAZgB1AHIAdABoAGUAcgAgAHMAdAB1AGQAeQANAA0ADQBBAHMAIABsAG8AdwAgAGEAcwAg AHAAbwBzAHMAaQBiAGwAZQA1ADUAIAA1AEMAbwBtAHAAYQB0AGkAYgBpAGwAaQB0AHkABwBGAGkA cgBzAHQAIABvAGMAdABlAHQAIABkAGUAcwBjAHIAaQBiAGUAcwAgAGUAbgBlAHIAZwB5ACAAbABl AHYAZQBsACAAYQBzACAAZABlAHMAYwByAGkAYgBlAGQAIABpAG4AIABbADIAXQAuAAcABwAHAHMA eQBuAHQAaABlAHMAaQBzACAAcwBoAG8AdQBsAGQAIABiAGUAIABjAG8AbQBwAGEAcgBhAGIAbABl ACAAdABvACAARgBvAHIAIABhAG4AIAA4AC4AMAAgAGsASAB6ACAAaQBtAHAAbABlAG0AZQBuAHQA YQB0AGkAbwBuACAAdwBpAHQAaAAgADUAbQBzACAAZgByAGEAbQBlAHMALgAgACAATwB0AGgAZQBy ACAAZgBvAHIAIAB1AHMAZQAgAGkAbgAgAFIAVABQACAAQQB1AGQAaQBvACAAYQBuAGQAIABWAGkA ZABlAG8AIABDAG8AbgBmAGUAcgBlAG4AYwBlAHMADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IABzAGEAbQBwAGwAaQBuAGcAIAByAGEAdABlAHMAIABhAG4AZAAgAGYAcgBhAG0AZQAgAHMAaQB6 AGUAcwAgAG0AYQB5ACAAcgBlAHEAdQBpAHIAZQAgAGEAZABkAGkAdABpAG8AbgBhAGwAIABtAGUA bQBvAHIAeQAgAGYAbwByACAAYgB1AGYAZgBlAHIAaQBuAGcALAAgAGUAdABjAC4ADQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABn ACgAUQAxADkAKQBcAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGQAbwBjABYAQQBzAGMA ZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQARQBNAFAAXABB AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBmAHQAXwBDAE4A RwBfAFQAbwBSADIALgBhAHMAZAADAHdSVT/YCPy1/w//D/8P/w//D/8P/w//D/8PAQDdIcVHYkEI k/8P/w//D/8P/w//D/8P/w//DwEA2wIhYR6ecor/D/8P/w//D/8P/w//D/8P/w8BAAQAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAQAtAAQAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAQAtAAgAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAQAtAAMAAADbAiFhAAAAAAAAAAAAAAAA3SHFRwAA AAAAAAAAAAAAAHdSVT8AAAAAAAAAAAAAAAD//////////////////wMAAAAAAAAAAAD/QFxcSiAA IAANAA0ADQANAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYQB0 ACAAYQBuACAAOAAuADAAIABrAEgAegAgAHMAYQBtAHAAbABpAG4AZwAgAHIAYQB0AGUAIAANAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBTlVT XEZMT1JJREEATmUwMDoAd2luc3Bvb2wASFAgTGFzZXJKZXQgNU1QAFxcSkFOVVNcRkxPUklEQQAA AAAAAAAAAAAAAAAAAAAAAQQBA5wAcAADYwEAAQABAAAAAAAAAAEADwBYAgIAAQBYAgIAAABMZXR0 ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA/////zcDAAAAAAAA//////////8AABEABgA8AAAA AgD//wAAAQD//wEAAQAAAP//AQADAP///////////////////////////////////////wAAAAAY AAAAAAAQJxAnECcAABAnAAAAAAAAAABcXEpBTlVTXEZMT1JJREEAAAAAAAAAAAAAAAAAAAAAAAEE AQOcAHAAA2MBAAEAAQAAAAAAAAABAA8AWAICAAEAWAICAAAATGV0dGVyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAgAP////83AwAAAAAAAP//////////AAARAAYAPAAAAAIA//8AAAEA//8BAAEAAAD/ /wEAAwD///////////////////////////////////////8AAAAAGAAAAAAAECcQJxAnAAAQJwAA AAAAAAAAA4ABAJQCAACUAgAAaG94AJwBnAGUAgAAAAAAAJQCAAAAAAAAARkAMSQBR8oTNQgBQ0oc AE9KAQBRSgEAbUgJBAEdAABGAQAxJAFHyhM1CAFDShwAT0oBAFFKAQBtSAkEAQgAAEYAADBKCgAB swAWJAFDJABFxoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGLKJwD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEQAAomAAtGAAAVxgYB1MLUwgABEwAKJgALRgAAFcYGAdTC1MIAQyQAARMACiYA C0YCABXGBgE/hGgBAEMkAAEaAABGAQBHyhM1CAFDShwAT0oBAFFKAQBtSAkEApwHAAAAAAAAPwAA AEoAAACwAAAAEAEAACQBAABPAQAAegEAAOoBAAADAgAAeAIAAIUCAACUAgAAngIAAKACAACzAgAA 1gIAAPECAADyAgAAAgMAAA4DAAA3AwAAOAMAADkDAABqAwAAbAMAAG4DAACNAwAAkgMAAJcDAACY AwAAXgQAAGEEAABqBAAAawQAAIsEAACfBAAA7QQAAO4EAAD8BAAALwUAAEAFAABlBQAAygUAANoF AADpBQAA6wUAAOwFAADtBQAAMwYAAD8GAABZBgAAagYAAJUGAACWBgAAlwYAAPIGAADzBgAAIwcA ACQHAAAlBwAAKAcAACkHAAA6BwAAmwcAAJ0HAAC7BwAAvAcAAL4HAADZBwAA2gcAANsHAADvBwAA 8AcAAPIHAADzBwAA9AcAAPUHAABoCAAAaQgAAIUIAACGCAAAhwgAAKgIAACrCAAArQgAAK4IAAAB CQAAAgkAABYJAAAXCQAAGAkAACoJAAArCQAALgkAADgJAAA5CQAAWgkAAFsJAABvCQAAcAkAAHIJ AABzCQAAdgkAAH0JAAB+CQAAfwkAAIAJAACRCQAAkwkAAJQJAACdCQAAngkAAJ8JAACyCQAAuwkA ANcJAADYCQAA5QkAAOYJAAA5CgAAOwoAAFUKAABlCgAAbQoAAHEKAAB+CgAAfwoAALYKAAC5CgAA yQoAANcKAADrCwAA/wsAAGsMAAB1DAAAeAwAAHsMAACLDAAAkQwAAKgMAADGDAAATQ0AAE4NAABX DQAAWA0AAN4NAAD7DQAA/A0AAP0NAAABDgAAAg4AAGEOAACCDgAArw4AAL4OAADPDgAA0A4AANEO AADSDgAAWQ8AAFoPAABbDwAAUAAACABAAABRAABOAAAAAFAAlggAQAAAUABsCQBAAABRACIqAAAA AFEAbAoAQAAAUQAARAAAAABQAMIKAEAAAFEASioAAAAAUQDiCwBAAABRAAAsAAAAAFEAAFAAAAAA UQAuLAAAAABRAEIsAAAAAFEARiwAAAAAUQBsLAAAAABRALIsAAAAAFEA6CwAAAAAUQBADQBAAABR AOosAAAAAFEARA8AQAAAUAACLQAAAABQAAQtAAAAAFEAmg8AQAAAUQAGLQAAAABRAPwPAEAAAFEA Ci0AAAAAUQBILQAAAABRAGQQAEAAAFEAUi0AAAAAUABuEABAAABRAPoRAEABAFEAADYAAAAAUAAU EgBAAwBRABYSAEAAAFEAVC0AAAAAUACWEgBAAABQABI2AAAAAFEAFDYAAAAAUQAwNgAAAABRAJY2 AAAAAFEAuDYAAAAAUQACNwAAAABRAAA8AAAAAFEAIDwAAAAAUQAAQgAAAABQAMw3AAAAAFAAPjwA AAAAUQBAPAAAAABRAMw8AAAAAFEA5DwAAAAAUQAAPgAAAABRAFg9AAAAAFAAzjcAAGQAIABuAG8A aQBzAGUAIABtAHUAcwB0ACAAYgBlAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAByAGEAZgB0 AC0AaQBlAHQAZgAtAGEAdgB0AC0AcAByAG8AZgBpAGwAZQAtAG4AZQB3AC0AMAA3AA0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABIACgABAFsA DwACAAAAAAAAADYAAEDx/wIANgAAAAYATgBvAHIAbQBhAGwAAAAIAAAAAyQDMSQAEABPSgIAUUoC AGtI5ARtSAkEPgABQAEAAgA+AAAACQBIAGUAYQBkAGkAbgBnACAAMQAAAA0AAQAGJAETpPAAFKQ8 AAALADUIgUNKHABLSBwAAC4AAgABAAIALgAAAAkASABlAGEAZABpAG4AZwAgADIAAAAFAAIABiQB AAMANQiBAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADIA/g8BAPIAMgAAAAcASQBuAGYAbwBk AG8AYwAAAA0ADwAFJAENxgUAAacEAAAEAENKFgAuAB1AAQACAS4AAAANAEYAbwBvAHQAbgBvAHQA ZQAgAFQAZQB4AHQAAAACABAAAAA8ACZAogARATwAAAASAEYAbwBvAHQAbgBvAHQAZQAgAFIAZQBm AGUAcgBlAG4AYwBlAAAABwBDShQASCoBAFIAAABbDwAAAAAAAAAAhwAAAIoAAAACAAAAAAD//wEA AAAAABAA//8CAAAAAAAAAAAAhwAAAIoAAAAAAAAAAAABAAAAAAAAAAAAWw8AAAUAACoAAAUA//// /wIAAACEIf//AQAAAAAAgiH//wIAAAAAAAAAAAB8BwAA8AcAAC8IAACpCAAA2AgAACwJAAAtCQAA Ww8AAAAAAAAAAQEAAAAAAQAAqQAAAQEAsAEAAQAAXAAAAQEAsAEAAQAARAAAAQEAAQAAAQAAAAAt AAAALgAAAC8AAAAwAAAAPwAAAEsAAABMAAAAVQAAAF0AAABeAAAAXwAAAGAAAABhAAAAaAAAAK8A AACwAAAAvQAAAL4AAAB8AQAAhwEAAIgBAAA4AwAAOQMAAF4EAABrBAAAyAQAAO4EAADsBQAA7QUA AJYGAACXBgAAoQYAALAGAAC9BgAAvgYAAL8GAADiBgAA4wYAAOQGAADwBgAA8QYAAPIGAADzBgAA JAcAACUHAAA7BwAAWwcAAHwHAACbBwAAvAcAANoHAADbBwAA8AcAAPEHAADyBwAA8wcAAPQHAAD1 BwAAEggAAC8IAABMCAAAaQgAAIYIAACHCAAAqQgAAKoIAACrCAAArAgAAK0IAACuCAAAwwgAANgI AADtCAAAAgkAABcJAAAYCQAAKwkAACwJAAAtCQAALgkAADkJAABbCQAAcAkAAHEJAAByCQAAcwkA AH8JAACACQAAkgkAAJMJAACUCQAAnwkAAKAJAACzCQAAtAkAALUJAAC8CQAAwgkAAMgJAADJCQAA ygkAAMsJAADZCQAA5wkAAOgJAADpCQAA/AkAAA8KAAAQCgAAEQoAABIKAAAYCgAAGQoAAD8KAABA CgAAQQoAAFQKAABVCgAAVgoAAGQKAABlCgAAbgoAAG8KAABwCgAAcQoAAH8KAAC3CgAAuAoAALkK AAC6CgAAxwoAAMgKAADJCgAA2AoAANkKAADsCgAA7QoAAO4KAAD0CgAAlgsAAJcLAADDCwAAxAsA AAEMAAACDAAAwwwAAMQMAABODQAAWA0AAF0NAABeDQAAaQ0AAGoNAAD8DQAA/Q0AANIOAADnDgAA +Q4AAA0PAAAODwAAKw8AAD8PAABADwAAQQ8AAFcPAABYDwAAXA8AABABAACKGAAAYMoCABABAABo CgAAYMoCAAAAAAAAAAAAYMoCAAABAABFIwAAUFMCAAABAABFIwAAYMoCAAABAABFIwAAYMoCAAAB AABFIwAAUFMCABABAACcBgAAYMoCABABAABIGwAAYMoCAAAAAAAAAAAAYMoCABABAACcBgAAYMoC ABABAABIGwAAYMoCAAAAAAAAAAAAYMoCABABAACcBgAAYMoCABACAABIGwAAYMoCAAAAAAAAAAAA wJQFAAABAABFIwAAcEEDAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAcEEDAAABAABF IwAAUFMCAAAFAABFIwAAUFMCAAABAABFIwAAUFMCAAADAABFIwAAUFMCAAABAABFIwAAcEEDAAAB AABFIwAAUFMCAAABAABFIwAAcEEDAAADAABFIwAAUFMCAAABAABFIwAAUFMCAAACAABFIwAAUFMC AAABAABFIwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA UFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA8PkGAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAC0AIABDAGEAcgAgAE4A bwBpAHMAZQAgAGEAdAAgAGEAbgAgAFMATgBSACAAbwBmACAAeAAgAGQAQgANAA0ADQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAADELAABQUwIAAAEA ADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIA AAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQ UwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADEL AABQUwIAAAAAAAAAAAAQOx4AAAEAADELAABQUwIAAAEAADELAABQUwIAAAIAADELAABQUwIAAAEA ADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIA EAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQ UwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAAAAAAAAADg8w0AAAEAADELAABQUwIAAAEAADEL AABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEA ADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIA AAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAAAAAAAAACQoAsAAAEAADELAABQ UwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAADMlAIAAAEAADELAABQUwIAAAEAADEL AABQUwIAAAEAADELAABQUwIAAAAAAAAAAABsOwcAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEA ADELAABQUwIAEAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAAAAAAAAADw+QYA AAEAADELAABQUwIAAAIAADELAABQUwIAAAEAADELAABQUwIAAAAAAAAAAACgpgQAAAEAADELAABQ UwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAEAEAADELAABQUwIAAAEAADEL AABQUwIAAAEAADELAABQUwIAAAAAAAAAAADw+QYAAAEAAEUjAABQUwIAAAEAAEUjAABwQQMAAAIA AEUjAABQUwIAAAEAAEUjAABQUwIAAAEAAEUjAABQUwIAAAEAAEUjAABQUwIAAAEAAEUjAABQUwIA AAEAAEUjAABQUwIAAAIAAEUjAABQUwIAAAEAAEUjAABQUwIAAAIAAEUjAABQUwIAAAEAAEUjAABw QQMAAAEAAEUjAABQUwIAAAEAAEUjAABQUwIAAAEAAEUjAABwQQMAAAEAAEUjAABQUwIAAAIAAEUj AABQUwIAAAEAAEUjAABQUwIAAAAAAAAAAAAAAAAAAAEAAEUjAADIFwIAAAEAAE4VAADIFwIAAAEA AN4MAADIFwIAAAAAAAAAAADIFwIAAAEAAE4VAADIFwIAAAEAAN4MAADIFwIAAAAAAAAAAADIFwIA AAEAAE4VAADIFwIAAAEAAN4MAADIFwIAAAAAAAAAAADIFwIAAAEAAEUjAADIFwIAAAAAAD8AAABL AAAAsAAAAL0AAAC+AAAAfAEAAIgBAAA4AwAAOQMAAF4EAABrBAAAyAQAAO4EAADsBQAA7QUAAJYG AACXBgAAoQYAALAGAAC9BgAAvgYAAL8GAADiBgAA4wYAAOQGAADwBgAA8QYAAPIGAADzBgAAJAcA ACUHAAA7BwAAWwcAAHwHAACbBwAAvAcAANoHAADbBwAA8AcAAPEHAADyBwAA8wcAAPQHAAD1BwAA EggAAC8IAABMCAAAaQgAAIYIAACHCAAAqQgAAKoIAACrCAAArAgAAK0IAACuCAAAwwgAANgIAADt CAAAAgkAABcJAAAYCQAAKwkAACwJAAAtCQAALgkAADkJAABbCQAAAQAAAP7///8DAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAA/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9wCQAAcQkAAHIJAABzCQAAfwkA AIAJAACSCQAAkwkAAJQJAACfCQAAoAkAALMJAAC0CQAAtQkAALwJAADCCQAAyAkAAMkJAADKCQAA ywkAANkJAADnCQAA6AkAAOkJAAD8CQAADwoAABAKAAARCgAAEgoAABgKAAAZCgAAPwoAAEAKAABB CgAAVAoAAFUKAABWCgAAZAoAAGUKAABuCgAAbwoAAHAKAABxCgAAfwoAALcKAAC4CgAAuQoAALoK AADHCgAAyAoAAMkKAADYCgAA2QoAAOwKAADtCgAA7goAAPQKAACWCwAAlwsAAMMLAADECwAAAQwA AAIMAADDDAAAxAwAAE4NAABYDQAAXQ0AAF4NAABpDQAAag0AAPwNAAD9DQAAXA8AAJ4AAAAAAAAA AAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgAgAAAABAAAAAAAA AACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAsAAAAJ4AAAAAAAAAAAAAAACA AAAAgJgAAAAAAAAAAAAAAACAfAEAAJgAAAAAAAAAAAAAAACAfAEAAJgAAAAAAAAAAAAAAACAfAEA AAgAAAABAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAXgQAAAgAAAABAAAAAAAAAACAAAAAgJgA AAAAAAAAAAAAAACAyAQAAJgAAAAAAAAAAAAAAACAyAQAAJgAAAAAAAAAAAAAAACAyAQAAJgAAAAA AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAA AAAAAACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQA AKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkA AAAQAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAA AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAA AAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQA AKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkA AAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAA AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAA AAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQA AKkAAiAAAAAAAAAAAACAyAQAAKkAAiAAAAEAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkA AAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAQ AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAA AAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQA AKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkA AAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAA AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAA AAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQA AKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkA AAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAKkAAAAA AAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAA AAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAA AACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACAyAQAAKkAAAAAAAAAAAAAAACA yAQAAKkAAAAAAAAAAAAAAACAyAQAAJkAAAAAAAAAAAAAAACAyAQAAJgAAAAAAAAAAAAAAACAyAQA AJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAAABQADITAEAFAFAANBMAQAAAUACoLQAA AABRAOoTAEAAAFAABEIAAAAAUAAGQgAAAABRAHwtAAAHAFEAgi0AAAcAUQCELQAABwBQAEoUAEAA AFEAqi0AAAAAUQAQFQBACQBQAK4tAAAAAFEAAEoAAAAAUQAESgAAAABQADpKAAAAAFAAsC0AAAsA UQCyLQAAAABQAEwVAEALAFAAThUAQAAAUAAiPgAAAABQACQ+AAAAAFAACEIAAAAAUABSFQBAAABQ ANotAAAAAFEAABYAQAcAUAA8SgAAAABQANwtAAAAAFEA4i0AAAAAUAA4FgBAAABQACY+AAAAAFAA CkIAAAAAUAA+FgBAAABQAOQWAEAAAFEAvBYAQAcAUADkFgBABwBQACQuAAAAAFEAKi4AAAAAUAAq PgAAAABQAOYWAEAAAFEA0DcAAAAAUADkNwAAAABRAOY3AAAAAFAAKDgAAAAAUQAqOAAAAABQAAIX AEANAFAABBcAQAAAUABSOAAAAABRAABMAAAAAFEAWjgAAAAAUQBoOAAAAABQAGo4AAAAAFAAbDgA AAAAUQBuOAAAAABQAB4XAEAAAFAAkDgAAAAAUQAGTAAAAABRAGg4AAAHAFAAkjgAAAAAUACUOAAA AABQAEYXAEAAAFAAWBcAQAAAUQC6OAAAAABQAJAXAEANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEgAKAAEAWwAPAAIAAAAAAAAANgAAQPH/ AgA2AAAABgBOAG8AcgBtAGEAbAAAAAgAAAADJAMxJAAQAE9KAgBRSgIAa0jkBG1ICQQ+AAFAAQAC AD4AAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAADQABAAYkAROk8AAUpDwAAAsANQiBQ0ocAEtIHAAA LgACAAEAAgAuAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAAUAAgAGJAEAAwA1CIEAAAAAAAAAAAAA AAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYA bwBuAHQAAAAAAAAAAAAAAAAAMgD+DwEA8gAyAAAABwBJAG4AZgBvAGQAbwBjAAAADQAPAAUkAQ3G BQABpwQAAAQAQ0oWAC4AHUABAAIBLgAAAA0ARgBvAG8AdABuAG8AdABlACAAVABlAHgAdAAAAAIA EAAAADwAJkCiABEBPAAAABIARgBvAG8AdABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAAH AENKFABIKgEAUgAAAFsPAAAAAAAAAACHAAAAigAAAAIAAAAAAP//AQAAAAAAEAD//wIAAAAAAAAA AACHAAAAigAAAAAAAAAAAAEAAAAAAAAAAABbDwAABQAAKgAABQD/////AgAAAIQh//8BAAAAAACA If//AgAAAAAAAAAAAHwHAADwBwAALwgAAKkIAADYCAAALAkAAC0JAABbDwAAAAAAAAABAQAAAAAB AACpAAABAQCwAQABAABcAAABAQCwAQABAABEAAABAQABAAABAAAAAC0AAAAuAAAALwAAADAAAAA/ AAAASwAAAEwAAABVAAAAXQAAAF4AAABfAAAAYAAAAGEAAABoAAAArwAAALAAAAC9AAAAvgAAAHwB AACHAQAAiAEAADgDAAA5AwAAXgQAAGsEAADIBAAA7gQAAOwFAADtBQAAlgYAAJcGAAChBgAAsAYA AL0GAAC+BgAAvwYAAOIGAADjBgAA5AYAAPAGAADxBgAA8gYAAPMGAAAkBwAAJQcAADsHAABbBwAA fAcAAJsHAAC8BwAA2gcAANsHAADwBwAA8QcAAPIHAADzBwAA9AcAAPUHAAASCAAALwgAAEwIAABp CAAAhggAAIcIAACpCAAAqggAAKsIAACsCAAArQgAAK4IAADDCAAA2AgAAO0IAAACCQAAFwkAABgJ AAArCQAALAkAAC0JAAAuCQAAOQkAAFsJAABwCQAAcQkAAHIJAABzCQAAfwkAAIAJAACSCQAAkwkA AJQJAACfCQAAoAkAALMJAAC0CQAAtQkAALwJAADCCQAAyAkAAMkJAADKCQAAywkAANkJAADnCQAA 6AkAAOkJAAD8CQAADwoAABAKAAARCgAAEgoAABgKAAAZCgAAPwoAAEAKAABBCgAAVAoAAFUKAABW CgAAZAoAAGUKAABuCgAAbwoAAHAKAABxCgAAfwoAALcKAAC4CgAAuQoAALoKAADHCgAAyAoAAMkK AADYCgAA2QoAAOwKAADtCgAA7goAAPQKAACWCwAAlwsAAMMLAADECwAAAQwAAAIMAADDDAAAxAwA AE4NAABYDQAAXQ0AAF4NAABpDQAAag0AAPwNAAD9DQAA0g4AAOcOAAD5DgAADQ8AAA4PAAArDwAA Pw8AAEAPAABBDwAAVw8AAFgPAABcDwAAEAEAAIoYAABgygIAEAEAAGgKAABgygIAAAAAAAAAAABg ygIAAAEAAEUjAABQUwIAAAEAAEUjAABgygIAAAEAAEUjAABgygIAAAEAAEUjAABQUwIAEAEAAJwG AABgygIAEAEAAEgbAABgygIAAAAAAAAAAABgygIAEAEAAJwGAABgygIAEAEAAEgbAABgygIAAAAA AAAAAABgygIAEAEAAJwGAABgygIAEAIAAEgbAABgygIAAAAAAAAAAADAlAUAAAEAAEUjAABwQQMA AAEAAEUjAABQUwIAAAIAAEUjAABQUwIAAAEAAEUjAABwQQMAAAEAAEUjAABQUwIAAAUAAEUjAABQ UwIAAAEAAEUjAABQUwIAAAMAAEUjAABQUwIAAAEAAEUjAABwQQMAAAEAAEUjAABQUwIAAAEAAEUj AABwQQMAAAMAAEUjAABQUwIAAAEAAEUjAABQUwIAAAIAAEUjAABQUwIAAAEAAEUjAABQUwIAAAEA ADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAAAAAAAAABQUwIAAAEAADELAABQUwIA AAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQ UwIAAAAAAAAAAADw+QYAAAEAADELAABQUwIAAAIAADELAABQUwIAAAEAADELAABQUwIAAAEAADEL AABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEA ADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIA AAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQUwIAAAEAADELAABQ UwIAAAEAADELAABQUwIAAAEAADELAABQUwIA7goAAJgAAAAAAAAAAAAAAACA7goAAJgAAAAAAAAA AAAAAACA7goAAJgAAAAAAAAAAAAAAACA7goAAJgAAAAAAAAAAAAAAACA7goAAJgAAAAAAAAAAAAA AACA7goAAJgAAAAAAAAAAAAAAACA7goAAJgAAAAAAAAAAAAAAACA7goAAJgAAAAAAAAAAAAAAACA 7goAAAgAAAABAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACATg0AAJgAAAAAAAAAAAAAAACATg0A AJoAAAAAAAAAAAAAAACAAAAAgJgAAAAAAAAAAAAAAACAXg0AAJgAAAAAAAAAAAAAAACAXg0AAJgA AAAAAAAAAAAAAACAXg0AAJgAAAAAAAAAAAAAAACAAAAAgAAEAAB8LgAAPFQAAAkAAAAZAAAAAAQA AMQEAAD0CQAAdAsAAAcMAACxDAAARg8AAKYuAAAqPgAAPFQAAAoAAAAMAAAADQAAAA8AAAARAAAA EgAAABQAAAAaAAAAIAAAAAAEAADGCgAAAAwAAJ0NAACoDwAACwAAAA4AAAAQAAAAEwAAAP//EAAA AAcAVQBuAGsAbgBvAHcAbgAQAEcAdQBuAG4AYQByACAASABlAGwAbABzAHQAcgD2AG0ADQBQAGEA dQBsACAARQAuACAASgBvAG4AZQBzABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBk ACAAVQBzAGUAcgAEAGgAYQB5AGEADgBUAGEAawBhAHMAaABpACAAUwB1AHoAdQBrAGkADABTAGkA bQBhAG8AIABDAGEAbQBwAG8AcwAWAEoAbwBhAG4AIAAmACAASgBlAHIAcgB5ACAAUwBoAHIAaQBt AHAAdABvAG4AEABEAGUAYgBvAHIAYQBoACAAQgByAHUAbgBnAGEAcgBkABMAYQBuAHQAbwBuAGkA YQB6AHoAaQAgAGcAaQBvAHYAYQBuAG4AYQAPAEEAbAAgAFMAdQBhAHIAZQB6ACAARABhAHkAYQBv ABkATQBhAHIAaQBlACAAQQBuAHQAbwBpAG4AZQB0AHQAZQAgAEIALgAgAFIAYQBtAG8AcwAJAFUA bgBiAGUAawBhAG4AbgB0AA4AUwAgAEoAIABUAHIAbwB3AGIAcgBpAGQAZwBlABMATAB1AGMAZQBu AHQAIABUAGUAYwBoAG4AbwBsAG8AZwBpAGUAcwAUAFIAbwBuAG4AaQBlACAAQgAuACAAVAByAG8A dwBiAHIAaQBkAGcAZQAZCgAANgoAADgKAABbDwAAEzmU/5WAAAAAAGEOAACCDgAA0g4AAFwPAAAH AAQABwAHAAAAAABZDgAAsA4AANIOAABcDwAABwAEAAcABwD//xQAAAAWAEEAcwBjAGUAbgBkACAA QQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIASQBDADoAXAB6AG8AcABmAFwARABvAGMAcwBc AGkAdAB1AFwAcwB0AGEAbgBkAGEAcgBkAGkAegBhAHQAaQBvAG4AXwBlAGYAZgBvAHIAdABzAFwA RwA3ADEAMQBfAGMAbgBnACgAUQAxADkAKQBcAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAu AGQAbwBjABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMA OgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABE AHIAYQBmAHQAXwBDAE4ARwBfAFQAbwBSADIALgBhAHMAZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQA aABvAHIAaQB6AGUAZAAgAFUAcwBlAHIASQBDADoAXAB6AG8AcABmAFwARABvAGMAcwBcAGkAdAB1 AFwAcwB0AGEAbgBkAGEAcgBkAGkAegBhAHQAaQBvAG4AXwBlAGYAZgBvAHIAdABzAFwARwA3ADEA MQBfAGMAbgBnACgAUQAxADkAKQBcAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGQAbwBj ABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQA RQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBm AHQAXwBDAE4ARwBfAFQAbwBSADIALgBhAHMAZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIA aQB6AGUAZAAgAFUAcwBlAHIALwBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQBy AHkAIABzAGEAdgBlACAAbwBmACAARAByAGEAZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AYQBzAGQA FgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAEkAQwA6AFwAegBv AHAAZgBcAEQAbwBjAHMAXABpAHQAdQBcAHMAdABhAG4AZABhAHIAZABpAHoAYQB0AGkAbwBuAF8A ZQBmAGYAbwByAHQAcwBcAEcANwAxADEAXwBjAG4AZwAoAFEAMQA5ACkAXABEAHIAYQBmAHQAXwBD AE4ARwBfAFQAbwBSADIALgBkAG8AYwAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUA ZAAgAFUAcwBlAHIALwBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABz AGEAdgBlACAAbwBmACAARAByAGEAZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AYQBzAGQAFgBBAHMA YwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAC8AQwA6AFwAVABFAE0AUABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEQAcgBhAGYAdABfAEMA TgBHAF8AVABvAFIAMgAuAGEAcwBkABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBk ACAAVQBzAGUAcgBJAEMAOgBcAHoAbwBwAGYAXABEAG8AYwBzAFwAaQB0AHUAXABzAHQAYQBuAGQA YQByAGQAaQB6AGEAdABpAG8AbgBfAGUAZgBmAG8AcgB0AHMAXABHADcAMQAxAF8AYwBuAGcAKABR ADEAOQApAFwARAByAGEAZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AZABvAGMAFgBBAHMAYwBlAG4A ZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAC8AQwA6AFwAVABFAE0AUABcAEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEQAcgBhAGYAdABfAEMATgBHAF8A VABvAFIAMgAuAGEAcwBkAAMAd1JVP9gI/LX/D/8P/w//D/8P/w//D/8P/w8BAN0hxUdiQQiT/w// D/8P/w//D/8P/w//D/8PAQDbAiFhHp5yiv8P/w//D/8P/w//D/8P/w//DwEABAAAABcAAAAAAAAA AAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAABAC0ABAAAABcAAAAAAAAAAAAAAAAA AAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAABAC0ACAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA AxAAAA+EaAERhJj+FcYFAAFoAQZvKAABAC0AAwAAANsCIWEAAAAAAAAAAAAAAADdIcVHAAAAAAAA AAAAAAAAd1JVPwAAAAAAAAAAAAAAAP//////////////////AwAAAAAAAAAAAP9AXFxKQU5VU1xG TE9SSURBAE5lMDA6AHdpbnNwb29sAEhQIExhc2VySmV0IDVNUABcXEpBTlVTXEZMT1JJREEAAAAA AAAAAAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8AWAICAAEAWAICAAAATGV0dGVy AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////83AwAAAAAAAP//////////AAARAAYAPAAAAAIA //8AAAEA//8BAAEAAAD//wEAAwD///////////////////////////////////////8AAAAAGAAA AAAAECcQJxAnAAAQJwAAAAAAAAAAXFxKQU5VU1xGTE9SSURBAAAAAAAAAAAAAAAAAAAAAAABBAED nABwAANjAQABAAEAAAAAAAAAAQAPAFgCAgABAFgCAgAAAExldHRlcgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIAD/////NwMAAAAAAAD//////////wAAEQAGADwAAAACAP//AAABAP//AQABAAAA//8B AAMA////////////////////////////////////////AAAAABgAAAAAABAnECcQJwAAECcAAAAA AAAAAAGAAQB+DgAAfg4AAGhveAABAAEAfg4AAAAAAABhDgAAAAAAAAEZADEkAUfKEzUIAUNKHABP SgEAUUoBAG1ICQQBHQAARgEAMSQBR8oTNQgBQ0ocAE9KAQBRSgEAbUgJBAEIAABGAAAwSgoAAbMA FiQBQyQARcaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiyicA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABEAAKJgALRgAAFcYGAdTC1MIAARMACiYAC0YAABXGBgHUwtTCAEMkAAETAAomAAtG AgAVxgYBP4RoAQBDJAABGgAARgEAR8oTNQgBQ0ocAE9KAQBRSgEAbUgJBAKoBwAAAAAAAD8AAABK AAAAsAAAABABAAAkAQAATwEAAHoBAADqAQAAAwIAAHgCAACFAgAAlAIAAJ4CAACgAgAAswIAANYC AADxAgAA8gIAAAIDAAAOAwAANwMAADgDAAA5AwAAagMAAGwDAABuAwAAjQMAAJIDAACXAwAAmAMA AF4EAABhBAAAagQAAGsEAACLBAAAnwQAAO0EAADuBAAA/AQAAC8FAABABQAAZQUAAMoFAADaBQAA 6QUAAOsFAADsBQAA7QUAADMGAAA/BgAAWQYAAGoGAACVBgAAlgYAAJcGAADyBgAA8wYAACMHAAAk BwAAJQcAACgHAAApBwAAOgcAAJsHAACdBwAAuwcAALwHAAC+BwAA2QcAANoHAADbBwAA7wcAAPAH AADyBwAA8wcAAPQHAAD1BwAAaAgAAGkIAACFCAAAhggAAIcIAACoCAAAqwgAAK0IAACuCAAAAQkA AAIJAAAWCQAAFwkAABgJAAAqCQAAKwkAAC4JAAA4CQAAOQkAAFoJAABbCQAAbwkAAHAJAAByCQAA cwkAAHYJAAB9CQAAfgkAAH8JAACACQAAkQkAAJMJAACUCQAAnQkAAJ4JAACfCQAAsgkAALsJAADX CQAA2AkAAOUJAADmCQAAOQoAADsKAABVCgAAZQoAAG0KAABxCgAAfgoAAH8KAAC2CgAAuQoAAMkK AADXCgAA6wsAAP8LAABrDAAAdQwAAHgMAAB7DAAAiwwAAJEMAACoDAAAxgwAAE0NAABODQAAVw0A AFgNAADeDQAA+w0AAPwNAAD9DQAAAQ4AAAIOAABhDgAAfg4AAIIOAACvDgAAvg4AAM8OAADQDgAA 0Q4AANIOAABZDwAAWg8AAFsPAABQAAAIAEAAAFEAAE4AAAAAUACWCABAAABQAGwJAEAAAFEAIioA AAAAUQBsCgBAAABRAABEAAAAAFAAwgoAQAAAUQBKKgAAAABRAOILAEAAAFEAACwAAAAAUQAAUAAA AABRAC4sAAAAAFEAQiwAAAAAUQBGLAAAAABRAGwsAAAAAFEAsiwAAAAAUQDoLAAAAABRAEANAEAA AFEA6iwAAAAAUQBEDwBAAABQAAItAAAAAFAABC0AAAAAUQCaDwBAAABRAAYtAAAAAFEA/A8AQAAA UQAKLQAAAABRAEgtAAAAAFEAZBAAQAAAUQBSLQAAAABQAG4QAEAAAFEA+hEAQAEAUQAANgAAAABQ ABQSAEADAFEAFhIAQAAAUQBULQAAAABQAJYSAEAAAFAAEjYAAAAAUQAUNgAAAABRADA2AAAAAFEA ljYAAAAAUQC4NgAAAABRAAI3AAAAAFEAADwAAAAAUQAgPAAAAABRAABCAAAAAFAAzDcAAAAAUAA+ PAAAAABRAEA8AAAAAFEAzDwAAAAAUQDkPAAAAABRAAA+AAAAAFEAWD0AAAAAUADONwAAAABQADIT AEAFAFAANBMAQAAAUACoLQAAAABRAOoTAEAAAFAABEIAAAAAUAAGQgAAAABRAHwtAAAHAFEAgi0A AAcAUQCELQAABwBQAEoUAEAAAFEAqi0AAAAAUQAQFQBACQBQAK4tAAAAAFEAAEoAAAAAUQAESgAA AABQADpKAAAAAFAAsC0AAAsAUQCyLQAAAABQAEwVAEALAFAAThUAQAAAUAAiPgAAAABQACQ+AAAA AFAACEIAAAAAUABSFQBAAABQANotAAAAAFEAABYAQAcAUAA8SgAAAABQANwtAAAAAFEA4i0AAAAA UAA4FgBAAABQACY+AAAAAFAACkIAAAAAUAA+FgBAAABQAOQWAEAAAFEAvBYAQAcAUADkFgBABwBQ ACQuAAAAAFEAKi4AAAAAUAAqPgAAAABQAOYWAEAAAFEA0DcAAAAAUADkNwAAAABRAOY3AAAAAFAA KDgAAAAAUQAqOAAAAABQAAIXAEANAFAABBcAQAAAUABSOAAAAABRAABMAAAAAFEAWjgAAAAAUQBo OAAAAABQAGo4AAAAAFAAbDgAAAAAUQBuOAAAAABQAB4XAEAAAFAAkDgAAAAAUQAGTAAAAABRAGg4 AAAHAFAAkjgAAAAAUACUOAAAAABQAEYXAEAAAFAAWBcAQAAAUQC6OAAAAABQAJAXAEAAAFEAvDgA AAAAUACqFwBAAABRAL44AAAAAFAAVBgAQAAAUADsGABAAABRAE4uAAAAAFAAGhkAQAAAUQDCOAAA AABQANw4AAAAAFEA3jgAAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAAEDseAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAAAAAAAAAAA4PMNAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAA UFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAAAAAAAAAAAkKALAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAzJQCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA bDsHAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAx CwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA8PkGAAABAAAxCwAAUFMCAAACAAAxCwAAUFMCAAAB AAAxCwAAUFMCAAAAAAAAAAAAoKYEAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMC AAABAAAxCwAAUFMCABABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAABAAAxCwAAUFMCAAAAAAAAAAAA 8PkGAAABAABFIwAAUFMCAAABAABFIwAAcEEDAAACAABFIwAAUFMCAAABAABFIwAAUFMCAAABAABF IwAAUFMCAAABAABFIwAAUFMCAAABAABFIwAAUFMCAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAAB AABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAcEEDAAABAABFIwAAUFMCAAABAABFIwAAUFMC AAABAABFIwAAcEEDAAABAABFIwAAUFMCAAACAABFIwAAUFMCAAABAABFIwAAUFMCAAT/AABFIwAA wBEHAAABAABFIwAAyBcCAAABAABOFQAAyBcCAAABAADeDAAAyBcCAAAAAAAAAAAAyBcCAAABAABO FQAAyBcCAAABAADeDAAAyBcCAAAAAAAAAAAAyBcCAAABAABOFQAAyBcCAAABAADeDAAAyBcCAAAA AAAAAAAAyBcCAAABAABFIwAAyBcCAAAAAAA/AAAASwAAALAAAAC9AAAAvgAAAHwBAACIAQAAOAMA ADkDAABeBAAAawQAAMgEAADuBAAA7AUAAO0FAACWBgAAlwYAAKEGAACwBgAAvQYAAL4GAAC/BgAA 4gYAAOMGAADkBgAA8AYAAPEGAADyBgAA8wYAACQHAAAlBwAAOwcAAFsHAAB8BwAAmwcAALwHAADa BwAA2wcAAPAHAADxBwAA8gcAAPMHAAD0BwAA9QcAABIIAAAvCAAATAgAAGkIAACGCAAAhwgAAKkI AACqCAAAqwgAAKwIAACtCAAArggAAMMIAADYCAAA7QgAAAIJAAAXCQAAGAkAACsJAAAsCQAALQkA AC4JAAA5CQAAWwkAAHAJAABxCQAAcgkAAHMJAAB/CQAAgAkAAJIJAACTCQAAlAkAAJ8JAACgCQAA swkAALQJAAC1CQAAvAkAAMIJAADICQAAyQkAAMoJAADLCQAA2QkAAOcJAADoCQAA6QkAAPwJAAAP CgAAEAoAABEKAAASCgAAGAoAABkKAAA/CgAAQAoAAEEKAABUCgAAVQoAAFYKAABkCgAAZQoAAG4K AABvCgAAcAoAAHEKAAB/CgAAtwoAALgKAAC5CgAAugoAAMcKAADICgAAyQoAANgKAADZCgAA7AoA AO0KAADuCgAA9AoAAJYLAACXCwAAwwsAAMQLAAABDAAAAgwAAMMMAADEDAAATg0AAFgNAABdDQAA Xg0AAGkNAABqDQAA/A0AAP0NAABcDwAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAA AACAngAAAAAAAAAAAAAAAIAAAACACAAAAAEAAAAAAAAAAIAAAACAngAAAAAAAAAAAAAAAIAAAACA mAAAAAAAAAAAAAAAAICwAAAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIB8AQAAmAAA AAAAAAAAAAAAAIB8AQAAmAAAAAAAAAAAAAAAAIB8AQAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAA AAAAAAAAAIBeBAAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIDIBAAAmAAAAAAAAAAA AAAAAIDIBAAAmAAAAAAAAAAAAAAAAIDIBAAAmAAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAA AAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAA AAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAABAAAAAAAAAAAIDIBAAAqQAAAAAAAAAA AAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAA AAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAA AAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAA AAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDIBAAAqQAA AAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQACIAAAAAAAAAAAAIDIBAAAqQACIAAA AQAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAA AAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAABAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAA AAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAA AAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAA AAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAA AAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAA AAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAA AAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAA AIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDI BAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAA qQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAqQAAAAAAAAAAAAAAAIDIBAAAmQAA AAAAAAAAAAAAAIDIBAAAmAAAAAAAAAAAAAAAAIDIBAAAngAAAAAAAAAAAAAAAIAAAACAmAAAAAAA AAAAAAAAAIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAAmAAAAAAAAAAA AAAAAIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAAmAAAAAAAAAAAAAAA AIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAAmAAAAAAAAAAAAAAAAIDuCgAACAAAAAEAAAAAAAAAAIAA AACAmAAAAAAAAAAAAAAAAIBODQAAmAAAAAAAAAAAAAAAAIBODQAAmgAAAAAAAAAAAAAAAIAAAACA mAAAAAAAAAAAAAAAAIBeDQAAmAAAAAAAAAAAAAAAAIBeDQAAmAAAAAAAAAAAAAAAAIBeDQAAmAAA AAAAAAAAAAAAAIBeDQAAAAQAAHwuAAACUgAACQAAABkAAAAABAAAxAQAAPQJAAB0CwAABwwAALEM AABGDwAApi4AACo+AAACUgAACgAAAAwAAAANAAAADwAAABEAAAASAAAAFAAAABoAAAAgAAAAAAQA AMYKAAAADAAAnQ0AAKgPAAALAAAADgAAABAAAAATAAAA//8QAAAABwBVAG4AawBuAG8AdwBuABAA RwB1AG4AbgBhAHIAIABIAGUAbABsAHMAdAByAPYAbQANAFAAYQB1AGwAIABFAC4AIABKAG8AbgBl AHMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMAZQByAAQAaABhAHkA YQAOAFQAYQBrAGEAcwBoAGkAIABTAHUAegB1AGsAaQAMAFMAaQBtAGEAbwAgAEMAYQBtAHAAbwBz ABYASgBvAGEAbgAgACYAIABKAGUAcgByAHkAIABTAGgAcgBpAG0AcAB0AG8AbgAQAEQAZQBiAG8A cgBhAGgAIABCAHIAdQBuAGcAYQByAGQAEwBhAG4AdABvAG4AaQBhAHoAegBpACAAZwBpAG8AdgBh AG4AbgBhAA8AQQBsACAAUwB1AGEAcgBlAHoAIABEAGEAeQBhAG8AGQBNAGEAcgBpAGUAIABBAG4A dABvAGkAbgBlAHQAdABlACAAQgAuACAAUgBhAG0AbwBzAAkAVQBuAGIAZQBrAGEAbgBuAHQADgBT ACAASgAgAFQAcgBvAHcAYgByAGkAZABnAGUAEwBMAHUAYwBlAG4AdAAgAFQAZQBjAGgAbgBvAGwA bwBnAGkAZQBzABQAUgBvAG4AbgBpAGUAIABCAC4AIABUAHIAbwB3AGIAcgBpAGQAZwBlABkKAAA2 CgAAOAoAAFsPAAATOZT/lYAAAAAA0g4AAFwPAAAHAAcAAAAAANIOAABcDwAABwAHAP//FAAAABYA QQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgBJAEMAOgBcAHoAbwBw AGYAXABEAG8AYwBzAFwAaQB0AHUAXABzAHQAYQBuAGQAYQByAGQAaQB6AGEAdABpAG8AbgBfAGUA ZgBmAG8AcgB0AHMAXABHADcAMQAxAF8AYwBuAGcAKABRADEAOQApAFwARAByAGEAZgB0AF8AQwBO AEcAXwBUAG8AUgAyAC4AZABvAGMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQA IABVAHMAZQByAC8AQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBh AHYAZQAgAG8AZgAgAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGEAcwBkABYAQQBzAGMA ZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgBJAEMAOgBcAHoAbwBwAGYAXABE AG8AYwBzAFwAaQB0AHUAXABzAHQAYQBuAGQAYQByAGQAaQB6AGEAdABpAG8AbgBfAGUAZgBmAG8A cgB0AHMAXABHADcAMQAxAF8AYwBuAGcAKABRADEAOQApAFwARAByAGEAZgB0AF8AQwBOAEcAXwBU AG8AUgAyAC4AZABvAGMAFgBBAHMAYwBlAG4AZAAgAEEAdQB0AGgAbwByAGkAegBlAGQAIABVAHMA ZQByAC8AQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAg AG8AZgAgAEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGEAcwBkABYAQQBzAGMAZQBuAGQA IABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQARQBNAFAAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBmAHQAXwBDAE4ARwBfAFQA bwBSADIALgBhAHMAZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBl AHIASQBDADoAXAB6AG8AcABmAFwARABvAGMAcwBcAGkAdAB1AFwAcwB0AGEAbgBkAGEAcgBkAGkA egBhAHQAaQBvAG4AXwBlAGYAZgBvAHIAdABzAFwARwA3ADEAMQBfAGMAbgBnACgAUQAxADkAKQBc AEQAcgBhAGYAdABfAEMATgBHAF8AVABvAFIAMgAuAGQAbwBjABYAQQBzAGMAZQBuAGQAIABBAHUA dABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAvAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBj AG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAHIAYQBmAHQAXwBDAE4ARwBfAFQAbwBSADIA LgBhAHMAZAAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIALwBD ADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAA RAByAGEAZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AYQBzAGQAFgBBAHMAYwBlAG4AZAAgAEEAdQB0 AGgAbwByAGkAegBlAGQAIABVAHMAZQByAEkAQwA6AFwAegBvAHAAZgBcAEQAbwBjAHMAXABpAHQA dQBcAHMAdABhAG4AZABhAHIAZABpAHoAYQB0AGkAbwBuAF8AZQBmAGYAbwByAHQAcwBcAEcANwAx ADEAXwBjAG4AZwAoAFEAMQA5ACkAXABEAHIAYQBmAHQAXwBDAE4ARwBfAFQAbwBSADIALgBkAG8A YwAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIALwBDADoAXABU AEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAARAByAGEA ZgB0AF8AQwBOAEcAXwBUAG8AUgAyAC4AYQBzAGQAAwB3UlU/2Aj8tf8P/w//D/8P/w//D/8P/w// DwEA3SHFR2JBCJP/D/8P/w//D/8P/w//D/8P/w8BANsCIWEennKK/w//D/8P/w//D/8P/w//D/8P AQAEAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEALQAEAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEALQAIAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEALQADAAAA2wIhYQAAAAAAAAAA AAAAAN0hxUcAAAAAAAAAAAAAAAB3UlU/AAAAAAAAAAAAAAAA//////////////////8DAAAAAAAA AAAA/0BcXEpBTlVTXEZMT1JJREEATmUwMDoAd2luc3Bvb2wASFAgTGFzZXJKZXQgNU1QAFxcSkFO VVNcRkxPUklEQQAAAAAAAAAAAAAAAAAAAAAAAQQBA5wAcAADYwEAAQABAAAAAAAAAAEADwBYAgIA AQBYAgIAAABMZXR0ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA/////zcDAAAAAAAA//////// //8AABEABgA8AAAAAgD//wAAAQD//wEAAQAAAP//AQADAP////////////////////////////// /////////wAAAAAYAAAAAAAQJxAnECcAABAnAAAAAAAAAABcXEpBTlVTXEZMT1JJREEAAAAAAAAA AAAAAAAAAAAAAAEEAQOcAHAAA2MBAAEAAQAAAAAAAAABAA8AWAICAAEAWAICAAAATGV0dGVyAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAgAP////83AwAAAAAAAP//////////AAARAAYAPAAAAAIA//8A AAEA//8BAAEAAAD//wEAAwD///////////////////////////////////////8AAAAAGAAAAAAA ECcQJxAnAAAQJwAAAAAAAAAAA4ABAJQCAACUAgAAaG94AAEAAQCUAgAAAAAAAJQCAAAAAAAAARkA MSQBR8oTNQgBQ0ocAE9KAQBRSgEAbUgJBAEdAABGAQAxJAFHyhM1CAFDShwAT0oBAFFKAQBtSAkE AQgAAEYAADBKCgABswAWJAFDJABFxoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGLKJwD//wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAomAAtGAAAVxgYB1MLUwgABEwAKJgALRgAAFcYGAdTC 1MIAQyQAARMACiYAC0YCABXGBgE/hGgBAEMkAAEaAABGAQBHyhM1CAFDShwAT0oBAFFKAQBtSAkE ApwHAAAAAAAAPwAAAEoAAACwAAAAEAEAACQBAABPAQAAegEAAOoBAAADAgAAeAIAAIUCAACUAgAA ngIAAKACAACzAgAA1gIAAPECAADyAgAAAgMAAA4DAAA3AwAAOAMAADkDAABqAwAAbAMAAG4DAACN AwAAkgMAAJcDAACYAwAAXgQAAGEEAABqBAAAawQAAIsEAACfBAAA7QQAAO4EAAD8BAAALwUAAEAF AABlBQAAygUAANoFAADpBQAA6wUAAOwFAADtBQAAMwYAAD8GAABZBgAAagYAAJUGAACWBgAAlwYA APIGAADzBgAAIwcAACQHAAAlBwAAKAcAACkHAAA6BwAAmwcAAJ0HAAC7BwAAvAcAAL4HAADZBwAA 2gcAANsHAADvBwAA8AcAAPIHAADzBwAA9AcAAPUHAABoCAAAaQgAAIUIAACGCAAAhwgAAKgIAACr CAAArQgAAK4IAAABCQAAAgkAABYJAAAXCQAAGAkAACoJAAArCQAALgkAADgJAAA5CQAAWgkAAFsJ AABvCQAAcAkAAHIJAABzCQAAdgkAAH0JAAB+CQAAfwkAAIAJAACRCQAAkwkAAJQJAACdCQAAngkA AJ8JAACyCQAAuwkAANcJAADYCQAA5QkAAOYJAAA5CgAAOwoAAFUKAABlCgAAbQoAAHEKAAB+CgAA fwoAALYKAAC5CgAAyQoAANcKAADrCwAA/wsAAGsMAAB1DAAAeAwAAHsMAACLDAAAkQwAAKgMAADG DAAATQ0AAE4NAABXDQAAWA0AAN4NAAD7DQAA/A0AAP0NAAABDgAAAg4AAGEOAACCDgAArw4AAL4O AADPDgAA0A4AANEOAADSDgAAWQ8AAFoPAABbDwAAUAAACABAAABRAABOAAAAAFAAlggAQAAAUABs CQBAAABRACIqAAAAAFEAbAoAQAAAUQAARAAAAABQAMIKAEAAAFEASioAAAAAUQDiCwBAAABRAAAs AAAAAFEAAFAAAAAAUQAuLAAAAABRAEIsAAAAAFEARiwAAAAAUQBsLAAAAABRALIsAAAAAFEA6CwA AAAAUQBADQBAAABRAOosAAAAAFEARA8AQAAAUAACLQAAAABQAAQtAAAAAFEAmg8AQAAAUQAGLQAA AABRAPwPAEAAAFEACi0AAAAAUQBILQAAAABRAGQQAEAAAFEAUi0AAAAAUABuEABAAABRAPoRAEAB AFEAADYAAAAAUAAUEgBAAwBRABYSAEAAAFEAVC0AAAAAUACWEgBAAABQABI2AAAAAFEAFDYAAAAA UQAwNgAAAABRAJY2AAAAAFEAuDYAAAAAUQACNwAAAABRAAA8AAAAAFEAIDwAAAAAUQAAQgAAAABQ AMw3AAAAAFAAPjwAAAAAUQBAPAAAAABRAMw8AAAAAFEA5DwAAAAAUQAAPgAAAABRAFg9AAAAAFAA zjcAAAAAUAAyEwBABQBQADQTAEAAAFAAqC0AAAAAUQDqEwBAAABQAARCAAAAAFAABkIAAAAAUQB8 LQAABwBRAIItAAAHAFEAhC0AAAcAUABKFABAAABRAKotAAAAAFEAEBUAQAkAUACuLQAAAABRAABK AAAAAFEABEoAAAAAUAA6SgAAAABQALAtAAALAFEAsi0AAAAAUABMFQBACwBQAE4VAEAAAFAAIj4A AAAAUAAkPgAAAABQAAhCAAAAAFAAUhUAQAAAUADaLQAAAABRAAAWAEAHAFAAPEoAAAAAUADcLQAA AABRAOItAAAAAFAAOBYAQAAAUAAmPgAAAABQAApCAAAAAFAAPhYAQAAAUADkFgBAAABRALwWAEAH AFAA5BYAQAcAUAAkLgAAAABRACouAAAAAFAAKj4AAAAAUADmFgBAAABRANA3AAAAAFAA5DcAAAAA UQDmNwAAAABQACg4AAAAAFEAKjgAAAAAUAACFwBADQBQAAQXAEAAAFAAUjgAAAAAUQAATAAAAABR AFo4AAAAAFEAaDgAAAAAUABqOAAAAABQAGw4AAAAAFEAbjgAAAAAUAAeFwBAAABQAJA4AAAAAFEA BkwAAAAAUQBoOAAABwBQAJI4AAAAAFAAlDgAAAAAUABGFwBAAABQAFgXAEAAAFEAujgAAAAAUACQ FwBAAABRALw4AAAAAFAAqhcAQAAAUQC+OAAAAABQAFQYAEAAAFAA7BgAQAAAUQBOLgAAAABQABoZ AEAAAFEAwjgAAAAAUADcOAAAAABRAN44AAAAAFAATDkAAAAAUAAiGQBAAABRAF4uAAAAAFAAYBkA QAAAUQB8LgAAAABQAIgbAEAAAFEAUjkAAAAAUQAARgAAAABRAAZGAAAAAFEADEYAAAAAUQAsRgAA AABRAGY5AAAAAFAAoBwAQAAAUQCUOQAAAABQANwcAEAAAFEALD4AAAAAUADyHABADwBQAPQcAEAA AFEAPj4AAAAAUAB4PgAAAABQAKQuAAAAAFEApi4AAAAAUQCuLgAAAABRALAuAAAAAFEAbi8AAAAA UQCwLwAAAABRAAowAAAAAFEAKDAAAAAAUQBKMAAAAABRAEwwAAAAAFAATh8AQAAAUAA+HgBAAABQ AEwfAEAAAFAATh8AQAAABAAAAEcWkAEAAAICBgMFBAUCAwSHAgAAAAAAAAAAAAAAAAAAnwAAAAAA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAA EAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHAgAAAAAAAAAA AAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAA3NZABgAACCwYJBwIFCAIEAQAAAAAABwgQAAAAAAAA AAAAAgAAAAAALf8z/yAAtDC3MMMwrzAAACIABADAAIgYAADQAgAAaAEAAAAARwo7Jt1bO4a5Czsm EQDXAAAAJAIAADQMAAACAAYAAAAEAAMQGgAAAAAAAAAAAAAAAgABAAAAAQAAAAAAAAAhAwAAAIQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAfjAAABEAGQBkAAAAGQAAAPwOAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADRDgAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAQC//8SAAAAAAAAABoAVABlAG0AcABsAGEAdABlACAAZgBvAHIAIABjAG8AbgB0 AHIAaQBiAHUAdABpAG8AbgBzAAAAAAAAABEAUwBpAG0AYQBvACAAQwBhAG0AcABvAHMALQBOAGUA dABvABYAQQBzAGMAZQBuAGQAIABBAHUAdABoAG8AcgBpAHoAZQBkACAAVQBzAGUAcgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAKJgALRgAAFcYGAdTC1MIAARMACiYA C0YAABXGBgHUwtTCAEMkAAETAAomAAtGAgAVxgYBP4RoAQBDJAABGgAARgEAR8oTNQgBQ0ocAE9K AQBRSgEAbUgJBAJ4BwAAAAAAALEAAAASAQAAJgEAAFEBAAB8AQAA7AEAAAUCAAB6AgAAhwIAAJsC AACdAgAAsAIAANMCAADuAgAA7wIAAP8CAAALAwAANAMAADUDAAA2AwAAZwMAAGkDAABrAwAAigMA AI8DAACUAwAAlQMAAFsEAABeBAAAZwQAAGgEAACIBAAAnAQAAOoEAADrBAAA+QQAACwFAAA9BQAA YgUAAMcFAADXBQAA5gUAAOgFAADpBQAA6gUAADAGAAA8BgAAVgYAAGcGAACSBgAAkwYAAJQGAADv BgAA8AYAACAHAAAhBwAAIgcAACUHAAAmBwAANwcAAJgHAACaBwAAuAcAALkHAAC7BwAA7KXBAHEA CQQAAOwSvwAAAAAAABAAAAAAAAQAAKgPAAAOAGJqYmp0K3QrAAAAAAAAAAAAAAAAAAAAAAAACQQW AABUAAAWQQEAFkEBANIOAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8PAAAAAAAAAAAA //8PAAAAAAAAAAAA//8PAAAAAAAAAAAAAAAAAAAAAABdAAAAAAAAAAAAAAAAALIBAACyAQAACgAA ALwBAAAMAAAA+AEAAAAAAAD4AQAAAAAAAPgBAAAUAAAAAAAAAAAAAAB4AgAAdAoAACQZAAAAAAAA JBkAAAAAAAAkGQAAAAAAACQZAAAUAAAAOBkAAEwAAADsDAAAAAAAAPYuAADuAAAAvBsAABYAAADS GwAAAAAAANIbAAAAAAAA0hsAAAAAAADSGwAAAAAAANIbAAAAAAAA0hsAAAAAAADSGwAAAAAAAI8j AAACAAAAkSMAAAAAAACRIwAAAAAAAJEjAAAvAAAAwCMAAAwBAADMJAAADAEAANglAAAkAAAA5C8A APQBAADYMQAArAAAAPwlAAD6CAAAAAAAAAAAAAAAAAAAAAAAAPgBAAAAAAAA0hsAAAAAAAAAAAAA AAAAAAAAAAAAAAAA0hsAAAAAAADSGwAAAAAAANIbAAAAAAAA0hsAAAAAAAD8JQAAAAAAAPIbAAAA AAAA+AEAAAAAAAD4AQAAAAAAANIbAAAAAAAAAAAAAAAAAADSGwAAAAAAAKgZAAAUAgAA8hsAAAAA AADyGwAAAAAAAPIbAAAAAAAA0hsAABAAAAD4AQAAAAAAANIbAAAAAAAA+AEAAAAAAADSGwAAAAAA AI8jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwCAAAYAAAAJAIAAFQAAADIAQAAGAAAAOABAAAYAAAA +AEAAAAAAAD4AQAAAAAAANIbAAAAAAAAjyMAAAAAAADyGwAAYgYAAPIbAAAAAAAAVCIAAFYAAABD IwAAQAAAAPgBAAAAAAAA+AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAI8jAAAAAAAA0hsAAAAAAACEGQAAJAAAAED58YGDLL8B7AwA ADgMAAAkGQAAAAAAAOIbAAAQAAAAgyMAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQA IABFAG4AdAByAHkAAACAAGAAYABgAGAAQABQAEAAYABgAIAAYABgAFAAUABAAFAAgACwAGAAsAAW AAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAACgzpAx+Ru/AUD58YGDLL8BiQAAAIAE AAAwAEAAMQBUAGEAYgBsAGUAAACgAFAAYACAAEAAoABgAFAAgABQAFAAYABgAGAAMABgAFAAUABg ALAAsACwAFAAcABwAA4AAgD///////////////9gAGAAQABAAEAAQACAAHAAgACAAAAAAAAAAAAA AAAAAAAAAABSAAAAhDIAAGAAYABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAACAAYABgAGAAYABg AGAAYACAAGAAYABgAGAAYABgAGAAYAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAAAAVAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAOABAAAAAAAA//////////8D AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA AAASAAAAEwAAABQAAAAVAAAAHgAAAP////81AAAAGQAAABwAAAD/////FwAAADoAAABGAAAAHwAA ACAAAAAbAAAAIgAAAEAAAAD/////JQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAA LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADkAAAA2AAAAOAAAADsAAAAYAAAAPAAAADcAAAAd AAAAPQAAAD4AAAA/AAAAUAAAAFEAAAD//////////////////////////yEAAAD///////////// ///+//////////////////////////////98AAAA/v///1MAAABUAAAAVQAAAGEAAAD///////// /////////////////////////////////////////////////2IAAABjAAAAZAAAAGUAAABmAAAA ZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1 AAAAdgAAAP7///94AAAAAgAAAIUAAAD9/////f///30AAAB+AAAA/v////////////////////// //////////////7///////////////////+KAAAAiwAAAP7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////wAAUQC8OAAAAABQ AKoXAEAAAFEAvjgAAAAAUABUGABAAABQAOwYAEAAAFEATi4AAAAAUAAaGQBAAABRAMI4AAAAAFAA 3DgAAAAAUQDeOAAAAABQAEw5AAAAAFAAIhkAQAAAUQBeLgAAAABQAGAZAEAAAFEAfC4AAAAAUACI GwBAAABRAFI5AAAAAFEAAEYAAAAAUQAGRgAAAABRAAxGAAAAAFEALEYAAAAAUQBmOQAAAABQAKAc AEAAAFEAlDkAAAAAUADcHABAAABRACw+AAAAAFAA8hwAQA8AUAD0HABAAABRAD4+AAAAAFAAeD4A AAAAUACkLgAAAABRAKYuAAAAAFEAri4AAAAAUQCwLgAAAABRAG4vAAAAAFEAsC8AAAAAUQAKMAAA AABRACgwAAAAAFEASjAAAAAAUQBMMAAAAABQAE4fAEAAAFAAPh4AQAAAUABMHwBAAABQAE4fAEAA AAQAAABHFpABAAACAgYDBQQFAgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAA TgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAA AAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAA QQByAGkAYQBsAAAANzWQAYAAAgsGCQcCBQgCBAEAAAAAAAcIEAAAAAAAAAAAAAIAAAAAAC3/M/8g ALQwtzDDMK8wAAAiAAQAQQCIGAAA0AIAAGgBAAAAAEcKOybdWzuGuQs7JhAA1wAAACQCAAA0DAAA AgAGAAAABAADEBoAAAAAAAAAAAAAAAIAAQAAAAEAAAAAAAAAIQMAAACEAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAApQbAB7QAtACAAD4wAAARABkAZAAAABkAAAD8DgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhQIAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAv// EgAAAAAAAAAaAFQAZQBtAHAAbABhAHQAZQAgAGYAbwByACAAYwBvAG4AdAByAGkAYgB1AHQAaQBv AG4AcwAAAAAAAAARAFMAaQBtAGEAbwAgAEMAYQBtAHAAbwBzAC0ATgBlAHQAbwAWAEEAcwBjAGUA bgBkACAAQQB1AHQAaABvAHIAaQB6AGUAZAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAIgAAAPIvAABgAGAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAgAGAAYABgAGAAYABgAGAA gABgAGAAYABgAGAAYABgAGAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB8AAAAAE4AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADgAQAAAAAAAAAAUABMOQAAAABQACIZ AEAAAFEAXi4AAAAAUABgGQBAAABRAHwuAAAAAFAAiBsAQAAAUQBSOQAAAABRAABGAAAAAFEABkYA AAAAUQAMRgAAAABRACxGAAAAAFEAZjkAAAAAUACgHABAAABRAJQ5AAAAAFAA3BwAQAAAUQAsPgAA AABQAPIcAEAPAFAA9BwAQAAAUQA+PgAAAABQAHg+AAAAAFAApC4AAAAAUQCmLgAAAABRAK4uAAAA AFEAsC4AAAAAUAAAVAAAAABRAKgvAAAAAFEAsC8AAAAAUQAKMAAAAABRACgwAAAAAFEASjAAAAAA UQBMMAAAAABQAE4fAEAAAFAAPh4AQAAAUABMHwBAAABQAE4fAEAAAAQAAABHFpABAAACAgYDBQQF AgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz JpABAAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAANzWQAYAA AgsGCQcCBQgCBAEAAAAAAAcIEAAAAAAAAAAAAAIAAAAAAC3/M/8gALQwtzDDMK8wAAAiAAQAAQCI GAAA0AIAAGgBAAAAAEcKOybeWzuGuQs7JhIA2AAAACQCAAA0DAAAAgAGAAAABAADEBoAAAAAAAAA AAAAAAIAAQAAAAEAAAAAAAAAIQMAAACEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QA tACAAB4wAAARABkAZAAAABkAAAD8DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAYQ4AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAv//EgAAAAAAAAAaAFQAZQBtAHAA bABhAHQAZQAgAGYAbwByACAAYwBvAG4AdAByAGkAYgB1AHQAaQBvAG4AcwAAAAAAAAARAFMAaQBt AGEAbwAgAEMAYQBtAHAAbwBzAC0ATgBlAHQAbwAWAEEAcwBjAGUAbgBkACAAQQB1AHQAaABvAHIA aQB6AGUAZAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAABgADAAYABQAFAAYACwALAAsABQ AHAAcAAOAAIBBwAAAP//////////YABgAEAAQABAAEAAgABwAIAAgAAAAAAAAAAAAAAAAAAAAAAA QQAAAPovAABgAGAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAgAGAAYABgAGAAYABgAGAAgABg AGAAYABgAGAAYABgAGAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAB/AAAAAFIAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADgAQAAAAAAAOylwQBxAAkEAAD8EL8AAAAA AAAQAAAAAAAEAACoDwAADgBiamJqdCt0KwAAAAAAAAAAAAAAAAAAAAAAAAkEFgAAVgAAFkEBABZB AQDSDgAAiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//DwAAAAAAAAAAAP//DwAAAAAAAAAA AP//DwAAAAAAAAAAAAAAAAAAAAAAXQAAAAAAAAAAAAAAAACyAQAAsgEAAAoAAAC8AQAADAAAAPgB AAAAAAAA+AEAAAAAAAD4AQAAFAAAAAAAAAAAAAAAeAIAAHQKAAAkGQAAAAAAACQZAAAAAAAAJBkA AAAAAAAkGQAAFAAAADgZAABMAAAA7AwAAAAAAAAaLwAA7gAAALwbAAAWAAAA0hsAAAAAAADSGwAA AAAAANIbAAAAAAAA0hsAAAAAAADSGwAAAAAAANIbAAAAAAAA0hsAAAAAAACnIwAAAgAAAKkjAAAA AAAAqSMAAAAAAACpIwAALwAAANgjAAAMAQAA5CQAAAwBAADwJQAAJAAAAAgwAAD0AQAA/DEAAKwA AAAUJgAABgkAAAAAAAAAAAAAAAAAAAAAAAD4AQAAAAAAANIbAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANIbAAAAAAAA0hsAAAAAAADSGwAAAAAAANIbAAAAAAAAFCYAAAAAAAAKHAAAAAAAAPgBAAAAAAAA +AEAAAAAAADSGwAAAAAAAAAAAAAAAAAA0hsAAAAAAACoGQAAFAIAAAocAAAAAAAAChwAAAAAAAAK HAAAAAAAANIbAAAcAAAA+AEAAAAAAADSGwAAAAAAAPgBAAAAAAAA0hsAAAAAAACnIwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAMAgAAGAAAACQCAABUAAAAyAEAABgAAADgAQAAGAAAAPgBAAAAAAAA+AEA AAAAAADSGwAAAAAAAKcjAAAAAAAAChwAAGIGAAAKHAAAAAAAAGwiAABWAAAAWyMAAEAAAAD4AQAA AAAAAPgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACnIwAAAAAAANIbAAAAAAAAhBkAACQAAABQSiuhgyy/AewMAAA4DAAAJBkAAAAA AADuGwAAHAAAAJsjAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5 AAAAgABgAGAAYABgAEAAUABAAGAAYACAAGAAYABQAFAAQABQAIAAsABgALAAFgAFAf////////// AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAoM6QMfkbvwFQSiuhgyy/AYwAAACABAAAMABAADEAVABh AGIAbABlAAAAoABQAGAAgABAAKAAYABQAIAAUABQAGAAYABgADAAYABQAFAAYACwALAAsABQAHAA cAAOAAIBBwAAAP//////////YABgAEAAQABAAEAAgABwAIAAgAAAAAAAAAAAAAAAAAAAAAAAUgAA AIQyAABgAGAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAgAGAAYABgAGAAYABgAGAAgABgAGAA YABgAGAAYABgAGAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACCAAAAAFYAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADgAQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAPgBAAAAAAAAAQBDAG8A bQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABIAAgAHAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA agAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgABAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAgDG3bHIk vwGAMbdsciS/AQAAAAAAAAAAAAAAADAAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wEAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAPAyAAAAAAAAgQAAAP7///+DAAAAAgAAAIgAAAD/ /////f////3////+////////////////////jQAAAI4AAAD+//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wMAAAAEAAAABQAAAAYA AAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAA ABUAAAAeAAAAFwAAADUAAAAZAAAAGgAAADoAAAD//////////0YAAAAfAAAAIAAAABYAAAAiAAAA QAAAAEEAAAD///////////////////////////////////////////////////////////////// /////////////////////////zYAAAA4AAAAOwAAABgAAAD/////NwAAAB0AAAD///////////// ////////IwAAAP7///9DAAAARAAAAEUAAABHAAAAIQAAAEgAAABJAAAASwAAAP7///9MAAAATQAA AE4AAABPAAAAVgAAAP//////////UwAAAFQAAABVAAAAYQAAAFcAAABYAAAAWQAAAFoAAABbAAAA XAAAAF0AAABeAAAAXwAAAGAAAAB/AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABq AAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAA/v////// ////////////////////////////////////////gAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAPgBAAAAAAAAAQBDAG8AbQBw AE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA AgABAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAA AAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgABAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAgDG3bHIkvwGA MbdsciS/AQAAAAAAAAAAAAAAADAAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQgAAAKgyAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAA AAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRv Y3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAA AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuYAEA ABwBAAANAAAAAQAAAHAAAAAPAAAAeAAAAAQAAACMAAAABQAAAJQAAAAGAAAAnAAAABEAAACkAAAA FwAAAKwAAAALAAAAtAAAABAAAAC8AAAAEwAAAMQAAAAWAAAAzAAAAA0AAADUAAAADAAAAPsAAAAC AAAA5AQAAB4AAAAMAAAAQ09NU0FUIExhYnMAAwAAAABiAAADAAAAGgAAAAMAAAAGAAAAAwAAAPwO AAADAAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAbAAAAVGVt cGxhdGUgZm9yIGNvbnRyaWJ1dGlvbnMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAA mAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAA AOQEAABBAAAATgAAAHsAQQA1AEEARABFADMANgAwAC0ANwA2AEEARQAtADEAMQBEADMALQBBADgA RABDAC0AMAAwADEAMAA1AEEAOABBADUAQQBBAEYAfQAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALABAAASAAAAAQAAAJgAAAACAAAA oAAAAAMAAADEAAAABAAAANAAAAAFAAAA7AAAAAYAAAD4AAAABwAAAAQBAAAIAAAAGAEAAAkAAAA4 AQAAEgAAAEQBAAAKAAAAYAEAAAsAAABsAQAADAAAAHgBAAANAAAAhAEAAA4AAACQAQAADwAAAJgB AAAQAAAAoAEAABMAAACoAQAAAgAAAOQEAAAeAAAAGwAAAFRlbXBsYXRlIGZvciBjb250cmlidXRp b25zAAAeAAAAAQAAAABlbXAeAAAAEgAAAFNpbWFvIENhbXBvcy1OZXRvAGliHgAAAAEAAAAAaW1h HgAAAAEAAAAAaW1hHgAAAAsAAABOb3JtYWwuZG90AHMeAAAAFwAAAEFzY2VuZCBBdXRob3JpemVk IFVzZXIAbx4AAAADAAAAMTcAZR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAHNAAAAAAMr/CB4A AABAAAAAAM5IQqMkvwFAAAAAABpPXXIkvwFAAAAAAA7TYoMsvwEDAAAAAgAAAAMAAAAkAgAAAwAA ADQMAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAA RhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAA AAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuYAEAABwB AAANAAAAAQAAAHAAAAAPAAAAeAAAAAQAAACMAAAABQAAAJQAAAAGAAAAnAAAABEAAACkAAAAFwAA AKwAAAALAAAAtAAAABAAAAC8AAAAEwAAAMQAAAAWAAAAzAAAAA0AAADUAAAADAAAAPsAAAACAAAA 5AQAAB4AAAAMAAAAQ09NU0FUIExhYnMAAwAAAABiAAADAAAAGgAAAAMAAAAGAAAAAwAAAPwOAAAD AAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAbAAAAVGVtcGxh dGUgZm9yIGNvbnRyaWJ1dGlvbnMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAmAAA AAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQE AABBAAAATgAAAHsAQQA1AEEARABFADMANgAwAC0ANwA2AEEARQAtADEAMQBEADMALQBBADgARABD AC0AMAAwADEAMAA1AEEAOABBADUAQQBBAEYAfQAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAA AAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALABAAASAAAAAQAAAJgAAAACAAAAoAAA AAMAAADEAAAABAAAANAAAAAFAAAA7AAAAAYAAAD4AAAABwAAAAQBAAAIAAAAGAEAAAkAAAA4AQAA EgAAAEQBAAAKAAAAYAEAAAsAAABsAQAADAAAAHgBAAANAAAAhAEAAA4AAACQAQAADwAAAJgBAAAQ AAAAoAEAABMAAACoAQAAAgAAAOQEAAAeAAAAGwAAAFRlbXBsYXRlIGZvciBjb250cmlidXRpb25z AAAeAAAAAQAAAABlbXAeAAAAEgAAAFNpbWFvIENhbXBvcy1OZXRvAGliHgAAAAEAAAAAaW1hHgAA AAEAAAAAaW1hHgAAAAsAAABOb3JtYWwuZG90AHMeAAAAFwAAAEFzY2VuZCBBdXRob3JpemVkIFVz ZXIAbx4AAAADAAAAMTgAZR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAHNAAAAAABDDLB4AAABA AAAAAM5IQqMkvwFAAAAAABpPXXIkvwFAAAAAAFSWhoMsvwEDAAAAAgAAAAMAAAAkAgAAAwAAADQM AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --=====================_33968754==_-- From rem-conf Fri Nov 12 05:40:25 1999 From rem-conf-request@es.net Fri Nov 12 05:40:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11mGqc-0000jl-00; Fri, 12 Nov 1999 05:34:38 -0800 Received: from (diaserv.diakonie.de) [195.125.231.11] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11mGqY-0000jG-00; Fri, 12 Nov 1999 05:34:34 -0800 Received: from default (98C9C4CD.ipt.aol.com [152.201.196.205]) by diaserv.diakonie.de (8.8.8/8.8.8) with SMTP id OAA03462; Fri, 12 Nov 1999 14:41:21 +0100 From: sgidshfds@mailr.com Message-Id: <199911121341.OAA03462@diaserv.diakonie.de> To: dsdaufds@hotbot.com Subject: The answer to cancer has been known!!! Date: Fri, 12 Nov 1999 04:00:53 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_22FA_00002477.00000C64" X-Priority: 3 X-MSMail-Priority: Normal Reply-To: none4me@angelfire.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------=_NextPart_000_22FA_00002477.00000C64 Content-Type: text/html; There are many web sites out there that are showing that the answer to cancer has been known. The evidence shows that when a person adds bitter seeds to their diet which contain the vitamin B17, the possibilities of contracting cancer is very slim. The evidence also shows that even after a person has been diagnosed with cancer, simply adding seeds and vitamin B17 to their diet can shrink the tumors and will protect the rest of the persons body. Some of these companies have hundreds of success records posted right on their web site with phone numbers and addresses for others to contact. In almost all of the cases that these websites record, blood pressure is lowered and blood sugar levels improve.
The websites show that a person should not only depend on the B17 and Seeds, but also clearly states that individuals should include other nutritious immune system building foods in their diet.\~It also shows that a person who still decides to stay on chemo and takes the apricot seeds live many times longer then if they took the chemo alone.
The FDA has made it very difficult for companies to advertise information concerning Vitamin B17 and the Apricot seeds.
If this is your first time ordering, order one of the packages which includes one bottle of the B17, one pound of the apricot seeds, the book, the video, the journal and complete instructions

Call our office for the web site location.

You may order by credit card by calling 800-395-7379

Book: World Without Cancer, by Edward Griffin
Contains most of what's mentioned in the videotape 'World Without Cancer' and much more on studies that were covered up and great scientist who where arrested when they began telling others about the truth with vitamin B17. Highly annotated for the serious student who wants to research the information for himself. Contains studies on Amygdalin (vitamin B17, laetrile) that were conducted at the famous cancer institute, Sloan Kettering and covered up. Full explanation of the politics of cancer from Mr. Edward Griffin.

Videotape: "World Without Cancer" Length 55 min.
By Edward Griffin. Features how the answer to cancer has always been known and was pushed out of the U.S. This video will blow you away. It brings to light in an organized and simple to understand fashion the politics of cancer, the scandal, the biologics scientifics, the cultures that have never had a case of cancer and some success stories...including my own which was featured on Inside Edition's Extra in 1996. $19.95

Apricot Kernels
These seeds have the highest content of B-17 on earth. These are not the same as the ones that are sometimes found in the health food stores. The ones in the health food store are sun- dried. Sun dried kernels are not effective, that's why they're allowed to be sold in U.S. stores without problem. Our kernels are fresh, chewable and bitter and a necessity in out diet. Dr. Krebs says 7 per day for absolute prevention. As therapy for existing cancer, between 20 and 50 per day is recommended. Although they are bitter, they must be integrated into our diets. Stores do not sell fresh apricot seeds because of what the FDA did years ago. $12.95 per pound, approx. 860 seeds per pound already cracked out of the shell.

Vitamin B-17
Fruit seed extract is called Amygdalin, Vitamin B17 or Laetrile. We carry this vitamin in tablet form in 100mg and 500mg quantities. They are 99% pure fruit seed extract from Cyto Pharm of Mexico. Cyto Pharma of Mexico are the pioneers of the seed extraction of Vitamin B17 for over 20 years.. They are the only ones who have followed Dr. Krebs exact specifications for the production of vitamin B17. For prevention the 100mg capsules are recommended by Dr. Krebs, one or two per day; If existing cancer is the case, between 2000-4000mg for the first 30 days is recommended along with 2-5 seeds per hour (waking hours). $95 per 100 500 mg tablets. $34 per 100 of the 100 mg tablets.

Call if you have questions and we'll give you a web site that has all the info.

To complain to UUNET about blocking this information on the web please complain to the security dept. of UUNET at 800-488-6384. Please ask for the security dept. and for John Bradshore. He has unethically censored out the web sites that talk of apricot seeds. Or e-mail abuse@uunet.net



===========Remove Requests==================
\\\\|||//
(@@)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____Please pardon the intrusion_|____|______|
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 & a method of removal.
To be removed mailto:None4me@angelfire.com
and type your email address in the subject line.OR call (877) 810-1218


 From rem-conf Sat Nov 13 04:51:53 1999 From rem-conf-request@es.net Sat Nov 13 04:51:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11mcS4-0002wA-00; Sat, 13 Nov 1999 04:38:44 -0800 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11mcRy-0002vu-00; Sat, 13 Nov 1999 04:38:39 -0800 Received: (from lanoms99@localhost) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) id KAA13022; Sat, 13 Nov 1999 10:34:45 -0200 (EDT) Date: Sat, 13 Nov 1999 10:34:45 -0200 (EDT) From: "LANOMS'99" Subject: IEEE LANOMS99 - Special prices for Academics To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl In-Reply-To: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MEMBERS NON- IEEE,SBC,SBT MEMBERS Symposium - Academics 190 220 Symposium - Professionals 290 350 Symposium - Students 60 70 1 Tutorial - Academics 80 100 1 Tutorial - Professionals 125 150 2 Tutorials - Academics 150 170 2 Tutorials - Professionals 225 250 Proceedings (until Nov. 26) 30 30 Please, see the Final Program and Register via Web. ************************************************************** * You are very welcome to participate in the * * * * IEEE LANOMS99 * * * * LATIN AMERICAN NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM * * * * http://www.lrg.ufsc.br/~lanoms99/ * * * * Rio Atlantica Hotel * * Rio de Janeiro - Brazil * * December 3-5, 1999 * ************************************************************** From rem-conf Sat Nov 13 10:42:47 1999 From rem-conf-request@es.net Sat Nov 13 10:42:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11mi1i-0005eF-00; Sat, 13 Nov 1999 10:35:54 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 11mi1h-0005e5-00; Sat, 13 Nov 1999 10:35:53 -0800 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhpeo08923 for ; Sat, 13 Nov 1999 18:40:16 GMT Received: from dynamicsoft.com (1Cust17.tnt3.freehold.nj.da.uu.net [63.25.172.17]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id NAA07229 for ; Sat, 13 Nov 1999 13:35:49 -0500 (EST) Message-ID: <382DB015.BD2C512A@dynamicsoft.com> Date: Sat, 13 Nov 1999 13:38:13 -0500 From: Jonathan Rosenberg Organization: Dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: [Fwd: RTP Packetization] Content-Type: multipart/mixed; boundary="------------4959C43537771C97BD87CE67" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------4959C43537771C97BD87CE67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this question is best addressed by avt.. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------4959C43537771C97BD87CE67 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from wodc7mr4.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: paleoalterdial.UU.NET [192.48.96.22]) id QQhpcj12011 for ; Sat, 13 Nov 1999 04:28:30 GMT Received: from lists.research.bell-labs.com by wodc7mr4.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lists.research.bell-labs.com [135.180.161.172]) id QQhpcj25908 for ; Sat, 13 Nov 1999 04:26:36 GMT Received: by lists.research.bell-labs.com (Postfix) id BFDFB52E6; Fri, 12 Nov 1999 23:25:27 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E3F8F5304; Fri, 12 Nov 1999 23:25:26 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.6.32.19991113093916.009b0050@192.168.2.1> X-Sender: ramana@192.168.2.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 13 Nov 1999 09:39:16 To: iptel@lists.research.bell-labs.com From: Ramana Yarlagadda Subject: RTP Packetization Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk X-Mozilla-Status2: 00000000 Hi all, In section 6.2.1/H225v2 it is mentioned as : For audio algorithms such as G.723 which use more than one size of audio frame, audio frame boundaries within each packet shall be signalled in-band to the audio channel. If we consider it from RTP point of view, then in a RTP packet there can be various combinations of the silence and voice frames. Let's consider one RTP packet like this: . so, audio frame boundaries can be 1. between two voice frames or 2. between voice frame and a non-voice frame. 3. or both 1 and 2. My question is exactely which of the above mentioned audio boundaries, according to the section 6.2.1/h225v2 needs to be signalled in the RTP packet? And, the boubndaries are to be signalled in-band, it means we have to add the boundary signalling in the RTP payload itself. am I correct? If we are going to put the boundary signalling inside the RTP payload, and this sort of signalling is H323 specific thing. then I think it will create some interoperability problems with RTP implementations other than H323. -Thanks in advance. -ramana --------- This message came from the IETF IPTEL Working Group Mailing List. --------------4959C43537771C97BD87CE67-- From rem-conf Sun Nov 14 17:35:34 1999 From rem-conf-request@es.net Sun Nov 14 17:35:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nAtl-0001rI-00; Sun, 14 Nov 1999 17:25:37 -0800 Received: from fastnet-cache.friday-ad.co.uk [212.42.162.152] by mail1.es.net with esmtp (Exim 1.81 #2) id 11nAtd-0001pL-00; Sun, 14 Nov 1999 17:25:29 -0800 Received: from fastnet-cache.friday-ad.co.uk (1Cust209.tnt1.raleigh.nc.da.uu.net [63.24.184.209]) by fastnet-cache.friday-ad.co.uk (8.8.5/8.8.5) with SMTP id BAA26851; Mon, 15 Nov 1999 01:17:29 GMT From: 62630496@awwww.com Date: Sun, 14 Nov 99 18:33:24 EST To: nbvnvb@ghgfhfghfgh.com Subject: Low price dental optical plan for you or your family Message-ID: <4534543534.9789798899898> Reply-To: rtretretreter@awwww.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, We work with a group of your local doctors and dentists and are offering a Dental - Optical Plan that runs approximately $3 a week for an individual and $4 a week for the entire family with no limit to the number of children. Would you like our office to furnish you with the details? Call Toll-Free 1-800-497-0195 "Refer to the K600 offer." *If your state is listed below then we currently do not service your area. ************************************************* We are linked to plenty of web sites that offer free subscriptions to our mailing list. You may JOIN or LEAVE this list at any time by following the simple instructions that can be found at the end of this email. You are on our mailing list because you have subscribed at one of our associate web sites, sent us email or we have a previous online relationship. Marketing Service Co. Customer Service Department 1-800-204-7441 to be removed mailto:none@vetech1.com *Not available for Alaska Washington D.C. Hawaii Maine Montana New Hampshire Rhode Island South Dakota Vermont Washington Wyoming From rem-conf Mon Nov 15 10:26:40 1999 From rem-conf-request@es.net Mon Nov 15 10:26:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nQi2-00020n-00; Mon, 15 Nov 1999 10:18:34 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11nQi1-00020d-00; Mon, 15 Nov 1999 10:18:33 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA26206; Mon, 15 Nov 1999 10:03:29 -0800 (PST) Message-Id: <3.0.3.32.19991115100327.00b52100@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 15 Nov 1999 10:03:27 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/17 Operational Multicast Network Management -- Radhika Malpani, HP Labs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Operational Multicast Network Management Wednesday November 17, 1999 1:00-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Radhika Malpani HP Labs Despite the increased need for IP multicast, driven by the popularity of applications like multimedia events and data distribution services, its deployment has not been widespread. Surprisingly, the lack of appropriate network management tools for IP multicast has proven to be a major barrier for its deployment. While a few diagnotic tools do exist today, these usually require expert knowledge and understanding of multicast protocols.Unlike unicast, where domain knowledge and management experience is considerable, in the multicast domain few people have the requisite multicast knowledge. This is especially true in the NOCs (Network Operations Center), where multicast management experience is practically non-existent This talk will describe the results of research at HP Laboratories into the management needs of multicast network operators. It will describe a prototype multicast network management system we've built that is aimed at network operators and discuss how it can be used to manage multicast networks. This prototype is currently used at HP and other sites to manage the multicast networks and some of our preliminary experiences with the prototype will be discussed. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Mon Nov 15 11:59:26 1999 From rem-conf-request@es.net Mon Nov 15 11:59:24 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 11nSBQ-0003tf-00; Mon, 15 Nov 1999 11:53:00 -0800 Received: from abd71a10.ipt.aol.com ([171.215.26.16] helo=localhost) by mail2.es.net with smtp (Exim 1.92 #1) id 11nSBN-0003tV-00; Mon, 15 Nov 1999 11:52:57 -0800 From: Subject: We need book,software,prod reviewers, keep after review post - iNet News Date: Mon, 15 Nov 1999 11:28:58 Message-Id: <814.641791.682314@localhost> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list iNet News Nov 1999 (for reviewers and prospects only) INet Reviews needs book, software & product reviewers. You may request any virtually title or consumer product. Titles are shipped directly to you with the freight paid from the publisher or manufacturer. You write a brief review and post it to our web site. After you write brief review you keep all review titles. For your review starter information kit send an email message with the words STARTER 1114G39 in the message subject line to wendyhilton@thehelm.com The starter kit contains complete information plus a 70 page list of review products others have received. WIN A FREE $300 HP Digital Camera or a $600 Sony DVD player.Drawing every 30 days. The winning odds last month were 1 in 489. This message is directed for iNet reviewers and referrals only. If you received this message by mistake, reply with the single word REMOVE to have your name removed from our email message database. If you have trouble responding to this email message, please send a Self Addressed Stamped Envelope to iNet Reviews, 4015 Holcomb Bridge Road, Ste 350-905, Norcross, GA 30092 and we will send you the starter kit info. From rem-conf Mon Nov 15 13:32:36 1999 From rem-conf-request@es.net Mon Nov 15 13:32:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nTdy-0004pW-00; Mon, 15 Nov 1999 13:26:34 -0800 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 11nTdw-0004pM-00; Mon, 15 Nov 1999 13:26:32 -0800 Received: from nmsnotes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 15 Nov 1999 16:25:37 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8525682A.00758BFD ; Mon, 15 Nov 1999 16:23:55 -0500 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Vincent_Virgilio@nmss.com To: rem-conf@es.net Message-ID: <8525682A.00758A97.00@notes4.nmss.com> Date: Mon, 15 Nov 1999 15:25:06 -0600 Subject: Re: [Fwd: RTP Packetization] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If the subject is about how to pack and unpack one or more frames of encoded media in a single RTP payload, then I think that the RTP audio profile addressed this already. The method varies across vocoders; for G.723.1 there is a dibit in the first byte of each encoded frame which indicates the frame's length. G729A is different; the profile specifies the constraint that G729A payloads must consist of one or more active frames followed by zero or one SIDs, which also permits a unique parsing of the payload. These may be the in-band codings to which H225 refers. Seems to me, however, that they are more out-of-band -- in-band instead to the audio profile. It is hard to imagine how this would break any robust RTP implementations. Vince Virgilio Jonathan Rosenberg on 11/13/99 12:38:13 PM To: rem-conf@es.net cc: (bcc: Vincent Virgilio) Subject: [Fwd: RTP Packetization] this question is best addressed by avt.. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com Received: from wodc7mr4.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: paleoalterdial.UU.NET [192.48.96.22]) id QQhpcj12011 for ; Sat, 13 Nov 1999 04:28:30 GMT Received: from lists.research.bell-labs.com by wodc7mr4.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: lists.research.bell-labs.com [135.180.161.172]) id QQhpcj25908 for ; Sat, 13 Nov 1999 04:26:36 GMT Received: by lists.research.bell-labs.com (Postfix) id BFDFB52E6; Fri, 12 Nov 1999 23:25:27 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E3F8F5304; Fri, 12 Nov 1999 23:25:26 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.6.32.19991113093916.009b0050@192.168.2.1> X-Sender: ramana@192.168.2.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 13 Nov 1999 09:39:16 To: iptel@lists.research.bell-labs.com From: Ramana Yarlagadda Subject: RTP Packetization Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk X-Mozilla-Status2: 00000000 Hi all, In section 6.2.1/H225v2 it is mentioned as : For audio algorithms such as G.723 which use more than one size of audio frame, audio frame boundaries within each packet shall be signalled in-band to the audio channel. If we consider it from RTP point of view, then in a RTP packet there can be various combinations of the silence and voice frames. Let's consider one RTP packet like this: . so, audio frame boundaries can be 1. between two voice frames or 2. between voice frame and a non-voice frame. 3. or both 1 and 2. My question is exactely which of the above mentioned audio boundaries, according to the section 6.2.1/h225v2 needs to be signalled in the RTP packet? And, the boubndaries are to be signalled in-band, it means we have to add the boundary signalling in the RTP payload itself. am I correct? If we are going to put the boundary signalling inside the RTP payload, and this sort of signalling is H323 specific thing. then I think it will create some interoperability problems with RTP implementations other than H323. -Thanks in advance. -ramana --------- This message came from the IETF IPTEL Working Group Mailing List. From rem-conf Tue Nov 16 03:14:59 1999 From rem-conf-request@es.net Tue Nov 16 03:14:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ngQ4-000384-00; Tue, 16 Nov 1999 03:05:04 -0800 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ngQ3-00037M-00; Tue, 16 Nov 1999 03:05:03 -0800 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id 0B9FCBEB0C for ; Tue, 16 Nov 1999 12:03:51 +0100 (MET) Received: by localhost with Microsoft MAPI; Tue, 16 Nov 1999 12:00:04 +0100 Message-ID: <01BF302A.1E1A6830.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "rem-conf@es.net" Subject: Firewalls and Mbone... Date: Tue, 16 Nov 1999 12:00:03 +0100 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 9 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi; Has anyone had any experience trying to get Mbone applications functioning behind a Firewall. Especially applications such as SDR, VIC and RAT. I'm interested in information dealing with Cisco's PIX and Checkpoint's Firewall-1. Thanks Chris From rem-conf Tue Nov 16 04:00:20 1999 From rem-conf-request@es.net Tue Nov 16 04:00:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nhF3-0004C3-00; Tue, 16 Nov 1999 03:57:45 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11nhF1-0004Bt-00; Tue, 16 Nov 1999 03:57:43 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12808; Tue, 16 Nov 1999 06:57:31 -0500 (EST) Message-Id: <199911161157.GAA12808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-interop-00.txt Date: Tue, 16 Nov 1999 06:57:30 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Audio/Video Profile Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-profile-interop-00.txt Pages : 5 Date : 15-Nov-99 It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-interop-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-interop-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-interop-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991115114435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-interop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-interop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991115114435.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 16 11:13:56 1999 From rem-conf-request@es.net Tue Nov 16 11:13:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nnyu-0000UN-00; Tue, 16 Nov 1999 11:09:32 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11nnyt-0000UD-00; Tue, 16 Nov 1999 11:09:31 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id LAA07376; Tue, 16 Nov 1999 11:03:55 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 16 Nov 1999 19:09:29 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id LAA11185; Tue, 16 Nov 1999 11:09:29 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id LAA12801; Tue, 16 Nov 1999 11:11:47 -0800 (PST) Received: from zopf_nt-pc ([192.168.59.125]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id OAA26302; Tue, 16 Nov 1999 14:09:26 -0500 (EST) Message-Id: <4.2.0.58.19991116134330.00ae9610@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 16 Nov 1999 14:10:25 -0500 To: wp3audio@ctd.comsat.com, rem-conf@es.net From: Robert Zopf Subject: CNG Complexity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All, In order to accurately measure the complexity of candidate algorithms, Lucent proposes that all algorithms be submitted using the basic operators used in G.729. There is an updated basic operator library with the ability to count WMOPS (sent out on the reflector on 08/09/99 by Simao) that could be used to measure the complexity of candidate algorithms. We propose that if more than one candidate meets the requirements, that the selection then be based on the WMOPS. The worst case WMOPS would be used for a 5ms frame with the CN analysis/synthesis operating every frame (VAD=0, and CN updated every frame). Other proposals ? Since the complexity requirement is currently stated in MIPS, we should change it to WMOPS. Does anyone have a mapping from WMOPS (as in the basic op library) to MIPS on a typical fixed-point DSP ? Rob. From rem-conf Tue Nov 16 12:59:12 1999 From rem-conf-request@es.net Tue Nov 16 12:59:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11npM7-0001zz-00; Tue, 16 Nov 1999 12:37:35 -0800 Received: from drawbridge.ascend.com [198.4.92.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11npM6-0001zo-00; Tue, 16 Nov 1999 12:37:34 -0800 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id MAA19487 for ; Tue, 16 Nov 1999 12:31:55 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 16 Nov 1999 20:37:30 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id MAA06278 for ; Tue, 16 Nov 1999 12:37:29 -0800 (PST) Received: from basset.eng.ascend.com (basset.eng.ascend.com [192.168.19.2]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id MAA16353 for ; Tue, 16 Nov 1999 12:39:48 -0800 (PST) Received: from zopf_nt-pc ([192.168.59.125]) by basset.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id PAA08606 for ; Tue, 16 Nov 1999 15:37:28 -0500 (EST) Message-Id: <4.2.0.58.19991116153606.00b80240@basset.eng.ascend.com> X-Sender: rzopf@basset.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 16 Nov 1999 15:38:26 -0500 To: rem-conf@es.net From: Robert Zopf Subject: Please see ITU reflector for CNG work Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Following Steve's advice, I will continue the discussion of CNG only on the ITU reflector. Regards, Rob. >Date: Tue, 16 Nov 1999 11:51:29 -0800 (Pacific Standard Time) >From: Stephen Casner >To: Robert Zopf >Subject: Re: CNG Complexity >Sender: casner@cisco.com > >Rob, > >It isn't a problem, but I would advise that you need not keep rem-conf >in the loop for your discussion of candidate algorithms and complexity >measures, etc. I suspect that the folks with expertise in this area >might already be participating in ITU as well as IETF. > >It would be useful to keep us posted on progress and when questions >about packet format or compatibility arise. > -- Steve From rem-conf Tue Nov 16 14:43:51 1999 From rem-conf-request@es.net Tue Nov 16 14:43:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nr9c-0003oM-00; Tue, 16 Nov 1999 14:32:48 -0800 Received: from (max.poly.edu) [128.238.32.105] (icme2000) by mail1.es.net with esmtp (Exim 1.81 #2) id 11nr9b-0003oC-00; Tue, 16 Nov 1999 14:32:47 -0800 Received: (from icme2000@localhost) by max.poly.edu (8.8.7/8.8.7) id LAA32161; Tue, 16 Nov 1999 11:05:22 -0500 Date: Tue, 16 Nov 1999 11:05:22 -0500 Message-Id: <199911161605.LAA32161@max.poly.edu> From: icme2000@penguin.poly.edu Bcc: Subject: IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA AND EXPO To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA AND EXPO JULY 30 -- AUGUST 2, 2000, NEW YORK CITY http://www.ieee-multimedia.poly.edu -----------------CALL FOR PAPERS-------------------- International Conference on Multimedia & Expo 2000 is the first IEEE multimedia conference that will take place in joint collaboration with four IEEE societies. The same four IEEE societies that have recently launched the IEEE Transactions on Multimedia, namely the Circuits and Systems Society, the Computer Society, the Signal Processing Society and the Communications Society have again come together in making this one-of-a-kind conference a reality. The goal is to unify all IEEE as well as non-IEEE multimedia related activities under the common umbrella of ICME 2000 -- the millennium multimedia meeting. It is expected that this will become a yearly event as the flagship Multimedia conference of the IEEE. New York City (the Big Apple) is uniquely suited for this first-time event in view of its large concentration of high tech Industries, first-rate academic institutions and numerous small multimedia companies. The intent is to blend the traditional IEEE conference framework into an Expo by providing the industry an opportunity to showcase products. Authors should submit a four-page manuscript in double-column format including authors' names, affiliations and a short abstract. Only electronic submission (in postscript format) will be accepted. Electronic submission procedure will be made available at the conference web site: http://www.ieee-multimedia.poly.edu Topics covered include but are not limited to the following: * Signal processing for media integration * Components and technologies for multimedia systems * Human-machine interface and interaction * Multimedia databases and file systems * Multimedia communication and networking * System integration * Applications * STDS standards and related issues Once accepted, the authors will be asked to prepare a four-page camera ready paper to appear in the conference proceedings and CD-ROM proceedings. Proposals for special sessions and half-day or full-day tutorial courses may be submitted to the respective chairs before the respective deadlines. Visit the conference web site for further information. DEADLINES December 1, 1999 Submission of regular papers February 1, 2000 Proposals for special sessions, panels, tutorials, demos March 1, 2000 Notification of acceptance for papers March 15, 2000 Notification of acceptance for proposals April 1, 2000 Paper camera-ready copy due CONFERENCE COMMITTEE General Chair: Sankar Basu, IBM sankar@watson.ibm.com Finance Chair: Peter Westerink, IBM Technical Program Co-Chairs: Tsuhan Chen, Carnegie Mellon Jeff H. Derby, IBM Peiya Liu, Siemens Chung-Sheng Li, IBM Special Sessions: Raj Acharya, SUNY, Buffalo Chalapathy Neti, IBM Tutorials: Rama Chellappa, U. Maryland Alexandros Eleftheriadis, Columbia Plenaries: S. Y. Kung, Princeton U. Shih-Fu Chang, Columbia U. Demos/Exhibits: Yao Wang, NY Polytechnic U. Publicity: Jelena Kovacevic, Bell Labs Ed Wong, NY Polytechnic Publications: Y. Q. Shi, NJIT Bhuvana Ramabhadran, IBM Registration: Junehwa Song, IBM Local Arrangements: Goran Djuknic, Lucent Tech. Ravi Rao, IBM Atul Puri, AT&T Electronic Media: Raj Kumar Rajendran, Columbia University Nasir Memon, Polytechnic University European Liaison: Alberto Del Bimbo, U. Florence Martin Vetterli, EPFL Far East Liaison: Masahito Hirakawa, Hiroshima U. Sadaoki Furui, Tokyo Inst. Tech. Steering Committee: Tadao Ichikawa, Hiroshima U. Rama Chellappa, U. Maryland Gary W. Cobb, Dell Alberto Del Bimbo, U. Florence Jeff H. Derby, IBM Alexander D. Gelman, Panasonic Yih-Fang Huang, U. Notre Dame Chung-Sheng Li, IBM Peiya Liu, Siemens Antonio Ortega, USC Dipankar Raychaudhuri, NEC Bing Sheu, Avanti Corporation John A. Sorensen, TU Denmark Advisory Committee: Richard Cox, AT&T Ed Deprettere, Delft U. Tech. Cesar Gonzales, IBM Scott Kirkpatrick, IBM Michael Picheny, IBM  From rem-conf Tue Nov 16 16:33:01 1999 From rem-conf-request@es.net Tue Nov 16 16:33:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11nsyF-0005aL-00; Tue, 16 Nov 1999 16:29:11 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11nsyE-0005aB-00; Tue, 16 Nov 1999 16:29:10 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id QAA04694; Tue, 16 Nov 1999 16:18:44 -0800 (PST) Message-Id: <3.0.3.32.19991116161843.00b56220@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 16 Nov 1999 16:18:43 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/17 Operational Multicast Network Management -- Radhika Malpani, HP Labs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Operational Multicast Network Management Wednesday November 17, 1999 1:00-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Radhika Malpani HP Labs Despite the increased need for IP multicast, driven by the popularity of applications like multimedia events and data distribution services, its deployment has not been widespread. Surprisingly, the lack of appropriate network management tools for IP multicast has proven to be a major barrier for its deployment. While a few diagnotic tools do exist today, these usually require expert knowledge and understanding of multicast protocols.Unlike unicast, where domain knowledge and management experience is considerable, in the multicast domain few people have the requisite multicast knowledge. This is especially true in the NOCs (Network Operations Center), where multicast management experience is practically non-existent This talk will describe the results of research at HP Laboratories into the management needs of multicast network operators. It will describe a prototype multicast network management system we've built that is aimed at network operators and discuss how it can be used to manage multicast networks. This prototype is currently used at HP and other sites to manage the multicast networks and some of our preliminary experiences with the prototype will be discussed. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Nov 18 10:05:59 1999 From rem-conf-request@es.net Thu Nov 18 10:05:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11oVn1-0001Sq-00; Thu, 18 Nov 1999 09:56:11 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11oVn0-0001RL-00; Thu, 18 Nov 1999 09:56:10 -0800 Received: from tmima-homepc (tmima-dsl5.cisco.com [144.254.211.46]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id JAA26463; Thu, 18 Nov 1999 09:54:30 -0800 (PST) Message-Id: <4.1.19991118024030.01aeaa50@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Nov 1999 09:54:22 -0800 To: GeeVarghese John , casner@cisco.com, micke@cdt.luth.se From: Tmima Koren Subject: Re: Extensions to CRTP Cc: brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net In-Reply-To: <38344FBF.BE0A0E4D@miel.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1458145722==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_1458145722==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:13 PM 11/18/99 -0500, you wrote: > > Steve, Tmima & all, > > This is regarding the ietf draft - Extensions to CRTP : > draft-koren-avt-crtp-enhance-00.txt > I have few doubts and could you please clarrify these points .. > > In the section 1. COMPRESSED_UDP packet "T bit" .. > > It is stated that CUDP packet reset the deltaT value to 0 and > therefore T bit avoids the need to send deltaT in the next CRTP. > > Q1) My doubt is If the entire original RTP header is the in the CUDP packet > why to > send the delta also with the original header .. > why can't the decompressor findout the new delta to be used > from the RTP header in the CUDP packet itself, Is it not redundancy ? > > Also You have stated that > > >> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes > in the > >> compressor state need to be synchronized. Sending multiple packets will > increase the > >> probability of delivery of the synchronized state in the event of packet > loss. > > Why do we need to send multiple packet and how it will increase the > probability even > if you send more CUDP packets, as long as the decomperssor look at the seq > number > and detect packet loss it should send a CONTEXT_STATE packet. > > If the draft reference you made was for loss of more than 16 packets from the > same flow, > and the possible wrong decompression of headers .. > twice algorithm should detect this (But twice algo is not used if checksum is > 0) > So here what exactly the limit could be , the sequence number space 1..16 > Since this draft address the use of this algo over ATM/AAL5 links I think > sequence number space 1..16 may not be sufficient. > Some notations: dt deltaT FH FULL_HEADER CR COMPRESSED_RTP CR+ COMPRESSED_RTP with deltaT (dt) CU COMPRESSED_UDP CU+ COMPRESSED_UDP with dt CS CONTEXT_STATE I'll use an example The sender sends a sample every 10 ms Using CRTP, the sequence of packets will be: seq# Time pkt type 1 10 FH 2 20 CR+ dt=10 3 30 CR ... 10 100 CR At this point this side stops talking. Talking resumes at time 200 11 200 CR+ dt=100 12 210 CR+ dt=10 13 220 CR .... With the extension of T-bit in CU, we can send: 11' 200 CU+ dt=10 12' 210 CR ... We are trying to adopt CRTP to links that have some loss of packets and a long round trip time (RT) We want to avoid the decompressor getting out of sync and having to send CS because this will cause loss of many packets for this stream due to the long RT. Let's check what happens if some packets are lost 1. packet 4 was lost The decompressor will use the 'twice' and will stay in sync 2. packet 11 was lost The decompressor is out of sync 3. packet 11' was lost The decompressor is out of sync We see that there is a weak point in the compression at the beginning of a talk spurt We try to correct this by sending multiple CU+ 11" 200 CU+ dt=10 12" 210 CU+ dt=10 13" 220 CR ... If the decompressor received any of 11" or 12" , he is still in sync How many CU+ do we want to send at the beginning of a talk spurt? This depends on the quality of the link (which is good but not perfect). If we know that on this link we may lose at most 2 packets in a row, we'll send 3 CU+ at the beginning of a talk spurt The decompressor will stay in sync as long as he received at least one of the CU+ > > > > Q2) Can you explain the use of "The NON-RTP stream flag" for this algorithm The compressor knows that this stream is a non-RTP stream, but he still wants to compress the stream. The compressor will have to use CU only. If the compressor can pass a hint to the decompressor that this is not an RTP stream, the decompressor will save only the IP and UDP headers for this context, and will not save the extra context of the RTP header (that does not exist here) and will not try to calculate the deltas and other RTP-related calculations > > Q3) Section III : Acknowledgement to a new compressed stream > > Context Invalidation was one point which I had pointed out to Steve/tmima > long time back .. > I am having those mails with me .. > > But, (i) Do we need ACCEPT and REJECT packet ?? > Having a NACK mechnism sounds reasonable .. > I feel there shouldnt be both .. > But what compressor is supposed to do after sending the first FULL_HEADER > packet > when compressor waiting for the ACCEPT or REJECT > should it queue the packets till the reply/or timeout > or Should it send the compressed packets assuming the decompressor will drop > if there are > REJECT state at the decompressor side. > > But (ii) what about the backword compatibility issue because this > ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508 > > As per the current proposal we need to send ACCEPT/REJECT packet for every > FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption .. > Draft talks about FULL_HEADER retransmit as well .. The REJECT packet is useful when the decompressor runs out of resources. The compressor initiates compression of a stream by sending a FH. With CRTP today the decompressor can send a CS to invalidate the context, but the compressor does not know the reason and will attempt to compress this stream again. A REJECT will notify the compressor that the decompressor cannot handle compresstion of additional streams at this moment. An implementation that was not enhanced to use REJECT will still use CS to invalidate the context each time the compressor attempts to compress the stream. The compressor continues to send the compressed packets of the stream until he receives CS or REJECT The intent is to make the ACCEPT/REJECT packet optional - an optimization. Tmima > > More questions after discussing these points .. > Please answer the questions ................... > > > Regards > > GVJ > > > -- > --------------------------------------------------------------------------- > Geevarghese John, DataCom Group, > Motorola India Electronics Ltd, > "The Senate", No-33 A, > Ulsoor Road, > Bangalore - 42. > Phone : 91-80-5598615 Xnt-4005 > E-mail : gvjohn@miel.mot.com > -------------------------------------------------------------------------- > ----- > -------------------------------------------------------------------------- > ----- > --=====================_1458145722==_.ALT Content-Type: text/html; charset="us-ascii"
At 02:13 PM 11/18/99 -0500, you wrote:
Steve, Tmima  & all,

This is regarding the ietf draft - Extensions to CRTP  : draft-koren-avt-crtp-enhance-00.txt
I have few doubts and could you please clarrify these points ..

In the section 1. COMPRESSED_UDP packet "T bit" ..

It is stated that CUDP packet reset the deltaT value to 0 and
therefore T bit avoids the need to send deltaT in the next CRTP.

Q1) My doubt is If the entire original RTP header is the in the CUDP packet why to
send the delta also with the original header ..
why can't the decompressor findout the new delta to be used
from the RTP header in the  CUDP packet itself, Is it not redundancy ?

Also You have stated that

>> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes in the
>> compressor state need to be synchronized. Sending multiple packets will increase the
>> probability of delivery of the synchronized state in the event of packet loss.

Why do we need to send multiple packet  and how it will increase the probability even
if you send more CUDP packets, as long as the decomperssor look at the seq number
and detect  packet loss  it should send a CONTEXT_STATE packet.

If the draft reference you made was for loss of more than 16 packets >from the same flow,
and the possible wrong decompression of headers ..
twice algorithm should detect this (But twice algo is not used if checksum is 0)
So here what exactly the limit could be , the sequence number space 1..16
Since this draft address the use of this algo over ATM/AAL5 links  I think
sequence number space 1..16 may not be sufficient.
 

Some notations:
dt         deltaT
FH        FULL_HEADER
CR       COMPRESSED_RTP
CR+     COMPRESSED_RTP with deltaT (dt)
CU       COMPRESSED_UDP
CU+     COMPRESSED_UDP with dt
CS       CONTEXT_STATE    

I'll use an example
The sender sends a sample every 10 ms
Using CRTP, the sequence of packets will be:

seq#   Time     pkt type
1        10         FH
2        20         CR+    dt=10
3        30         CR
...
10      100       CR

At this point this side stops talking. Talking resumes at time 200

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR
....

With the extension of T-bit in CU, we can send:

11'     200       CU+    dt=10
12'     210       CR
...

We are trying to adopt CRTP to links that have some loss of packets and a long round trip time (RT)
We want to avoid the decompressor getting out of sync and having to send CS because this will cause loss of many packets for this stream due to the long RT.

Let's check what happens if some packets are lost
1. packet 4 was lost
    The decompressor will use the 'twice' and will stay in sync
2. packet 11 was lost
    The decompressor is out of sync
3. packet 11'  was lost
    The decompressor is out of sync

We see that there is a weak point in the compression at the beginning of a talk spurt
We try to correct this by sending multiple CU+

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR
...

If the decompressor received any of 11"  or 12" ,  he is still in sync

How many CU+ do we want to send at the beginning of a talk spurt?
This depends on the quality of the link (which is good but not perfect).
If we know that on this link we may lose at most 2 packets in a row, we'll send 3 CU+ at the beginning of a talk spurt
The decompressor will stay in sync as long as he received at least one of the CU+ 


 

Q2) Can you explain the use of  "The NON-RTP stream flag" for this algorithm

The compressor knows that this stream is a non-RTP stream, but he still wants to compress the stream. The compressor will have to use CU only. If the compressor can pass a hint to the decompressor that this is not an RTP stream, the decompressor will save only the IP and UDP headers for this context, and will not save the extra context of the RTP header (that does not exist here) and will not try to calculate the deltas and other RTP-related calculations


Q3) Section III : Acknowledgement to a new compressed stream

Context Invalidation was one point which I had pointed out to Steve/tmima long time back ..
I am having those mails with me ..

But, (i) Do we need ACCEPT and REJECT packet  ??
Having a NACK mechnism sounds reasonable ..
I feel there shouldnt be both ..
But what compressor is supposed to do after sending the first FULL_HEADER packet
when compressor waiting for the ACCEPT or REJECT
should it queue the packets till the reply/or timeout
or Should it send the compressed packets assuming the decompressor will drop if there are
REJECT state at the decompressor side.

But (ii) what about the backword compatibility issue because this ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508

As per the current proposal we need to send ACCEPT/REJECT packet for every
FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption ..
Draft talks about FULL_HEADER retransmit as well ..

The REJECT packet is useful when the decompressor runs out of resources. The compressor initiates compression of a stream by sending a FH. With CRTP today the decompressor can send a CS to invalidate the context, but the compressor does not know the reason and will attempt to compress this stream again. A REJECT will notify the compressor that the decompressor cannot handle compresstion of additional streams at this moment.
An implementation that was not enhanced to use REJECT will still use CS to invalidate the context each time the compressor attempts to compress the stream.
The compressor continues to send the compressed packets of the stream until he receives CS or REJECT
The intent is to make the ACCEPT/REJECT packet optional - an optimization.

Tmima


More questions after discussing these points ..
Please answer the questions ...................
 

Regards

GVJ
 

-- ---------------------------------------------------------------------------
Geevarghese John,   DataCom Group,
Motorola India Electronics Ltd,
"The Senate", No-33 A,
Ulsoor Road,
Bangalore - 42.
Phone  : 91-80-5598615  Xnt-4005
E-mail : gvjohn@miel.mot.com
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
 

--=====================_1458145722==_.ALT-- From rem-conf Thu Nov 18 22:58:09 1999 From rem-conf-request@es.net Thu Nov 18 22:58:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ohrI-0000eg-00; Thu, 18 Nov 1999 22:49:24 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ohrG-0000eH-00; Thu, 18 Nov 1999 22:49:22 -0800 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id XAA22740; Thu, 18 Nov 1999 23:49: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 XAA22407; Thu, 18 Nov 1999 23:49:04 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id MAA04219; Fri, 19 Nov 1999 12:22:44 +0530 (IST) Message-ID: <38358615.D8679DA0@miel.mot.com> Date: Fri, 19 Nov 1999 12:17:09 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, gvjohn@miel.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> Content-Type: multipart/alternative; boundary="------------273F322522180A003FD42464" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------273F322522180A003FD42464 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, My comments to you answers are added below .. Please have a look at that // Tmima Koren wrote: > > At 02:13 PM 11/18/99 -0500, you wrote: > >> Steve, Tmima & all, >> >> This is regarding the ietf draft - Extensions to CRTP : >> draft-koren-avt-crtp-enhance-00.txt >> I have few doubts and could you please clarrify these points .. >> >> In the section 1. COMPRESSED_UDP packet "T bit" .. >> >> It is stated that CUDP packet reset the deltaT value to 0 and >> therefore T bit avoids the need to send deltaT in the next CRTP. >> >> Q1) My doubt is If the entire original RTP header is the in the CUDP >> packet why to >> send the delta also with the original header .. >> why can't the decompressor findout the new delta to be used >> from the RTP header in the CUDP packet itself, Is it not redundancy >> ? >> >> Also You have stated that >> >> >> Multiple COMPRESSED_UDP packets may be sent by the compressor >> when changes in the >> >> compressor state need to be synchronized. Sending multiple >> packets will increase the >> >> probability of delivery of the synchronized state in the event of >> packet loss. >> >> Why do we need to send multiple packet and how it will increase the >> probability even >> if you send more CUDP packets, as long as the decomperssor look at >> the seq number >> and detect packet loss it should send a CONTEXT_STATE packet. >> >> If the draft reference you made was for loss of more than 16 packets >> from the same flow, >> and the possible wrong decompression of headers .. >> twice algorithm should detect this (But twice algo is not used if >> checksum is 0) >> So here what exactly the limit could be , the sequence number space >> 1..16 >> Since this draft address the use of this algo over ATM/AAL5 links I >> think >> sequence number space 1..16 may not be sufficient. > > > Some notations: > dt deltaT > FH FULL_HEADER > CR COMPRESSED_RTP > CR+ COMPRESSED_RTP with deltaT (dt) > CU COMPRESSED_UDP > CU+ COMPRESSED_UDP with dt > CS CONTEXT_STATE > > I'll use an example > The sender sends a sample every 10 ms > Using CRTP, the sequence of packets will be: > > seq# Time pkt type > 1 10 FH > 2 20 CR+ dt=10 > 3 30 CR > ... > 10 100 CR > > At this point this side stops talking. Talking resumes at time 200 > > 11 200 CR+ dt=100 > 12 210 CR+ dt=10 > 13 220 CR > .... > > With the extension of T-bit in CU, we can send: > > 11' 200 CU+ dt=10 > 12' 210 CR > ... > > We are trying to adopt CRTP to links that have some loss of packets > and a long round trip time (RT) > We want to avoid the decompressor getting out of sync and having to > send CS because this will cause loss of many packets for this stream > due to the long RT. > > Let's check what happens if some packets are lost > 1. packet 4 was lost > The decompressor will use the 'twice' and will stay in sync > 2. packet 11 was lost > The decompressor is out of sync > 3. packet 11' was lost > The decompressor is out of sync > > We see that there is a weak point in the compression at the beginning > of a talk spurt > We try to correct this by sending multiple CU+ > > 11" 200 CU+ dt=10 > 12" 210 CU+ dt=10 > 13" 220 CR Here, I think you assumed that 12" packet will reach the compessor with timestamp 210. But, unfortunately if it was lost what you get is 13" and time stamp 220. In that case again you have send dt again with your CU+ after sending CU+ with dt 10. In this type of situation processing due to delta encoding was double and you send two delta encoded bytes in two different packets insteadof one You might have assumed that MOST of the case packet loss doesnot happen .. But I feel that is also purely dependant on the network where this algorithm is executing .. > > ... > > If the decompressor received any of 11" or 12" , he is still in sync I think this is not correct, If the decompressor receives 12" insted of 11", he is not in sync because of link seq number mismatch and will send a CONTEXT_STATE packet. This will lead to FH sending from compressor to decompressor .. > > > How many CU+ do we want to send at the beginning of a talk spurt? > This depends on the quality of the link (which is good but not > perfect). > If we know that on this link we may lose at most 2 packets in a row, > we'll send 3 CU+ at the beginning of a talk spurt Looks OK, but How do we decide on the number of packet loss ? Packet loss can be due to link quality and/or network congestion etc .. If the loss was due network congestion or similar factor, behaviour vary >from time to time .. So here also CU+ is giving disadvantage instead of the benifits expected. > > The decompressor will stay in sync as long as he received at least one > of the CU+ I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from decompressor to compressor because of the link seq number mismatch ..Is nt it ? > I will include rest of the questions in another mail .. Please reply back .. Rgds GVJ --------------273F322522180A003FD42464 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

My comments to you answers are added below  ..
Please have a look at that  //

Tmima Koren wrote:

 
At 02:13 PM 11/18/99 -0500, you wrote:
Steve, Tmima  & all,

This is regarding the ietf draft - Extensions to CRTP  : draft-koren-avt-crtp-enhance-00.txt
I have few doubts and could you please clarrify these points ..

In the section 1. COMPRESSED_UDP packet "T bit" ..

It is stated that CUDP packet reset the deltaT value to 0 and
therefore T bit avoids the need to send deltaT in the next CRTP.

Q1) My doubt is If the entire original RTP header is the in the CUDP packet why to
send the delta also with the original header ..
why can't the decompressor findout the new delta to be used
from the RTP header in the  CUDP packet itself, Is it not redundancy ?

Also You have stated that

>> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes in the
>> compressor state need to be synchronized. Sending multiple packets will increase the
>> probability of delivery of the synchronized state in the event of packet loss.

Why do we need to send multiple packet  and how it will increase the probability even
if you send more CUDP packets, as long as the decomperssor look at the seq number
and detect  packet loss  it should send a CONTEXT_STATE packet.

If the draft reference you made was for loss of more than 16 packets >from the same flow,
and the possible wrong decompression of headers ..
twice algorithm should detect this (But twice algo is not used if checksum is 0)
So here what exactly the limit could be , the sequence number space 1..16
Since this draft address the use of this algo over ATM/AAL5 links  I think
sequence number space 1..16 may not be sufficient.


Some notations:
dt         deltaT
FH        FULL_HEADER
CR       COMPRESSED_RTP
CR+     COMPRESSED_RTP with deltaT (dt)
CU       COMPRESSED_UDP
CU+     COMPRESSED_UDP with dt
CS       CONTEXT_STATE

I'll use an example
The sender sends a sample every 10 ms
Using CRTP, the sequence of packets will be:

seq#   Time     pkt type
1        10         FH
2        20         CR+    dt=10
3        30         CR
...
10      100       CR

At this point this side stops talking. Talking resumes at time 200

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR
....

With the extension of T-bit in CU, we can send:

11'     200       CU+    dt=10
12'     210       CR
...

We are trying to adopt CRTP to links that have some loss of packets and a long round trip time (RT)
We want to avoid the decompressor getting out of sync and having to send CS because this will cause loss of many packets for this stream due to the long RT.

Let's check what happens if some packets are lost
1. packet 4 was lost
    The decompressor will use the 'twice' and will stay in sync
2. packet 11 was lost
    The decompressor is out of sync
3. packet 11'  was lost
    The decompressor is out of sync

We see that there is a weak point in the compression at the beginning of a talk spurt
We try to correct this by sending multiple CU+

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR

Here, I think you assumed that 12"  packet will reach the compessor with
timestamp 210. But, unfortunately if it was lost what you get is 13" and time stamp 220.
In that case again you have send dt again with your CU+ after sending CU+ with dt 10.
In this type of situation processing due to delta encoding was double and you send two
delta encoded bytes in two different packets insteadof one
You might have assumed that MOST of  the case packet loss doesnot happen ..
But I feel that is also purely dependant on the network where this algorithm is executing ..
 
...

If the decompressor received any of 11"  or 12" ,  he is still in sync

I think this is not correct, If the decompressor receives 12" insted of 11",
he is not in sync because of link seq number mismatch and
will send a CONTEXT_STATE packet.
This will lead to FH sending from compressor to decompressor ..
 

How many CU+ do we want to send at the beginning of a talk spurt?
This depends on the quality of the link (which is good but not perfect).
If we know that on this link we may lose at most 2 packets in a row, we'll send 3 CU+ at the beginning of a talk spurt

Looks OK, but How do we decide on the number of packet loss ?
Packet loss can be due to link quality and/or network congestion etc ..
If the loss was due network congestion or similar factor, behaviour vary from time to time ..
So here also CU+ is giving disadvantage instead of the benifits expected.
 
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?
 
I will include rest of the questions in another mail ..
Please reply back ..

Rgds
GVJ
 
 
  --------------273F322522180A003FD42464-- From rem-conf Thu Nov 18 23:27:08 1999 From rem-conf-request@es.net Thu Nov 18 23:27:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11oiO0-0001dL-00; Thu, 18 Nov 1999 23:23:12 -0800 Received: from motgate2.mot.com [136.182.1.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11oiNy-0001dB-00; Thu, 18 Nov 1999 23:23:11 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id AAA22365; Fri, 19 Nov 1999 00:23:02 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id AAA29515; Fri, 19 Nov 1999 00:22:55 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id MAA08655; Fri, 19 Nov 1999 12:56:36 +0530 (IST) Message-ID: <38358E06.C3F08940@miel.mot.com> Date: Fri, 19 Nov 1999 12:51:02 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren , casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, gvjohn@miel.mot.com, pazhynnr@cig.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> Content-Type: multipart/alternative; boundary="------------44AB1B42F5C07FDF6CBF0C1E" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------44AB1B42F5C07FDF6CBF0C1E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, Please neglect my previous mail, this is the correct mail .. I pasted my answers at the wrong place which might confuse those who read .. GVJ GeeVarghese John wrote: > Hi, > > My comments to you answers are added below .. > Please have a look at that // > > Tmima Koren wrote: > >> >> At 02:13 PM 11/18/99 -0500, you wrote: >> >> > Steve, Tmima & all, >> > >> > This is regarding the ietf draft - Extensions to CRTP : >> > draft-koren-avt-crtp-enhance-00.txt >> > I have few doubts and could you please clarrify these points .. >> > >> > In the section 1. COMPRESSED_UDP packet "T bit" .. >> > >> > It is stated that CUDP packet reset the deltaT value to 0 and >> > therefore T bit avoids the need to send deltaT in the next CRTP. >> > >> > Q1) My doubt is If the entire original RTP header is the in the >> > CUDP packet why to >> > send the delta also with the original header .. >> > why can't the decompressor findout the new delta to be used >> > from the RTP header in the CUDP packet itself, Is it not >> > redundancy ? >> > >> > Also You have stated that >> > >> > >> Multiple COMPRESSED_UDP packets may be sent by the compressor >> > when changes in the >> > >> compressor state need to be synchronized. Sending multiple >> > packets will increase the >> > >> probability of delivery of the synchronized state in the event >> > of packet loss. >> > >> > Why do we need to send multiple packet and how it will increase >> > the probability even >> > if you send more CUDP packets, as long as the decomperssor look at >> > the seq number >> > and detect packet loss it should send a CONTEXT_STATE packet. >> > >> > If the draft reference you made was for loss of more than 16 >> > packets from the same flow, >> > and the possible wrong decompression of headers .. >> > twice algorithm should detect this (But twice algo is not used if >> > checksum is 0) >> > So here what exactly the limit could be , the sequence number space >> > 1..16 >> > Since this draft address the use of this algo over ATM/AAL5 links >> > I think >> > sequence number space 1..16 may not be sufficient. >> >> >> Some notations: >> dt deltaT >> FH FULL_HEADER >> CR COMPRESSED_RTP >> CR+ COMPRESSED_RTP with deltaT (dt) >> CU COMPRESSED_UDP >> CU+ COMPRESSED_UDP with dt >> CS CONTEXT_STATE >> >> I'll use an example >> The sender sends a sample every 10 ms >> Using CRTP, the sequence of packets will be: >> >> seq# Time pkt type >> 1 10 FH >> 2 20 CR+ dt=10 >> 3 30 CR >> ... >> 10 100 CR >> >> At this point this side stops talking. Talking resumes at time 200 >> >> 11 200 CR+ dt=100 >> 12 210 CR+ dt=10 >> 13 220 CR >> .... >> >> With the extension of T-bit in CU, we can send: >> >> 11' 200 CU+ dt=10 >> 12' 210 CR > Here, I think you assumed that 12' packet will reach the compessor with timestamp 210. But, unfortunately if it was lost what you get is 13' and time stamp 220. In that case again you have send dt again with your CU+ after sending CU+ with dt 10. In this type of situation processing due to delta encoding was double and you send two delta encoded bytes in two different packets insteadof one You might have assumed that MOST of the case packet loss doesnot happen .. But I feel that is also purely dependant on the network where this algorithm is executing .. And also are you not loosing the bandwidth saving by sending CU+ instead of CR because you send the complete RTP hdr + delta encoded deltaT byte in CU+. >> >> ... >> >> We are trying to adopt CRTP to links that have some loss of packets >> and a long round trip time (RT) >> We want to avoid the decompressor getting out of sync and having to >> send CS because this will cause loss of many packets for this stream >> due to the long RT. >> >> Let's check what happens if some packets are lost >> 1. packet 4 was lost >> The decompressor will use the 'twice' and will stay in sync >> 2. packet 11 was lost >> The decompressor is out of sync >> 3. packet 11' was lost >> The decompressor is out of sync >> >> We see that there is a weak point in the compression at the >> beginning of a talk spurt >> We try to correct this by sending multiple CU+ >> >> 11" 200 CU+ dt=10 >> 12" 210 CU+ dt=10 >> 13" 220 CR > >> >> ... >> >> If the decompressor received any of 11" or 12" , he is still in >> sync > I think this is not correct, If the decompressor receives 12" insted of 11", he is not in sync because of link seq number mismatch and will send a CONTEXT_STATE packet. This will lead to FH sending from compressor to decompressor .. > > >> >> >> How many CU+ do we want to send at the beginning of a talk spurt? >> This depends on the quality of the link (which is good but not >> perfect). >> If we know that on this link we may lose at most 2 packets in a row, >> we'll send 3 CU+ at the beginning of a talk spurt > Looks OK, but How do we decide on the number of packet loss ? Packet loss can be due to link quality and/or network congestion etc .. If the loss was due network congestion or similar factor, behaviour vary >from time to time .. So here also CU+ is giving disadvantage instead of the benifits expected. >> >> The decompressor will stay in sync as long as he received at least >> one of the CU+ > I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from decompressor to compressor because of the link seq number mismatch ..Is nt it ? > > >> > > I will include rest of the questions in another mail .. > Please reply back .. > > Rgds > GVJ > > > --------------44AB1B42F5C07FDF6CBF0C1E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, Please neglect my previous mail, this is the correct mail ..
I pasted my answers at the wrong place which might confuse those who read ..

GVJ

GeeVarghese John wrote:

Hi,

My comments to you answers are added below  ..
Please have a look at that  //

Tmima Koren wrote:

 
At 02:13 PM 11/18/99 -0500, you wrote:
Steve, Tmima  & all,

This is regarding the ietf draft - Extensions to CRTP  : draft-koren-avt-crtp-enhance-00.txt
I have few doubts and could you please clarrify these points ..

In the section 1. COMPRESSED_UDP packet "T bit" ..

It is stated that CUDP packet reset the deltaT value to 0 and
therefore T bit avoids the need to send deltaT in the next CRTP.

Q1) My doubt is If the entire original RTP header is the in the CUDP packet why to
send the delta also with the original header ..
why can't the decompressor findout the new delta to be used
from the RTP header in the  CUDP packet itself, Is it not redundancy ?

Also You have stated that

>> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes in the
>> compressor state need to be synchronized. Sending multiple packets will increase the
>> probability of delivery of the synchronized state in the event of packet loss.

Why do we need to send multiple packet  and how it will increase the probability even
if you send more CUDP packets, as long as the decomperssor look at the seq number
and detect  packet loss  it should send a CONTEXT_STATE packet.

If the draft reference you made was for loss of more than 16 packets >from the same flow,
and the possible wrong decompression of headers ..
twice algorithm should detect this (But twice algo is not used if checksum is 0)
So here what exactly the limit could be , the sequence number space 1..16
Since this draft address the use of this algo over ATM/AAL5 links  I think
sequence number space 1..16 may not be sufficient.


Some notations:
dt         deltaT
FH        FULL_HEADER
CR       COMPRESSED_RTP
CR+     COMPRESSED_RTP with deltaT (dt)
CU       COMPRESSED_UDP
CU+     COMPRESSED_UDP with dt
CS       CONTEXT_STATE

I'll use an example
The sender sends a sample every 10 ms
Using CRTP, the sequence of packets will be:

seq#   Time     pkt type
1        10         FH
2        20         CR+    dt=10
3        30         CR
...
10      100       CR

At this point this side stops talking. Talking resumes at time 200

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR
....

With the extension of T-bit in CU, we can send:

11'     200       CU+    dt=10
12'     210       CR

Here, I think you assumed that 12'  packet will reach the compessor with
timestamp 210. But, unfortunately if it was lost what you get is 13' and time stamp 220.
In that case again you have send dt again with your CU+ after sending CU+ with dt 10.
In this type of situation processing due to delta encoding was double and you send two
delta encoded bytes in two different packets insteadof one
You might have assumed that MOST of  the case packet loss doesnot happen ..
But I feel that is also purely dependant on the network where this algorithm is executing ..

And also are you not loosing the bandwidth saving by sending CU+ instead of CR
because  you send the complete RTP hdr + delta encoded deltaT byte in CU+.
 

 
...

We are trying to adopt CRTP to links that have some loss of packets and a long round trip time (RT)
We want to avoid the decompressor getting out of sync and having to send CS because this will cause loss of many packets for this stream due to the long RT.

Let's check what happens if some packets are lost
1. packet 4 was lost
    The decompressor will use the 'twice' and will stay in sync
2. packet 11 was lost
    The decompressor is out of sync
3. packet 11'  was lost
    The decompressor is out of sync

We see that there is a weak point in the compression at the beginning of a talk spurt
We try to correct this by sending multiple CU+

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR

 
...

If the decompressor received any of 11"  or 12" ,  he is still in sync

I think this is not correct, If the decompressor receives 12" insted of 11",
he is not in sync because of link seq number mismatch and
will send a CONTEXT_STATE packet.
This will lead to FH sending from compressor to decompressor ..
 
 

How many CU+ do we want to send at the beginning of a talk spurt?
This depends on the quality of the link (which is good but not perfect).
If we know that on this link we may lose at most 2 packets in a row, we'll send 3 CU+ at the beginning of a talk spurt

Looks OK, but How do we decide on the number of packet loss ?
Packet loss can be due to link quality and/or network congestion etc ..
If the loss was due network congestion or similar factor, behaviour vary from time to time ..
So here also CU+ is giving disadvantage instead of the benifits expected.
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?
 
 
 
I will include rest of the questions in another mail ..
Please reply back ..

Rgds
GVJ
 
 
 


  --------------44AB1B42F5C07FDF6CBF0C1E-- From rem-conf Sun Nov 21 00:42:42 1999 From rem-conf-request@es.net Sun Nov 21 00:42:41 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 11pSHP-0007B1-00; Sun, 21 Nov 1999 00:23:27 -0800 Received: from [202.104.205.6] (helo=royou) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 11pSHK-0007Ar-00; Sun, 21 Nov 1999 00:23:25 -0800 From: "superabcd" To: Subject: ´óÁ¿¹©Ó¦»ÆÓñʯ Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 21 Nov 1999 16:19:23 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ´óÁ¿¹©Ó¦»ÆÓñʯ ½­ÃÅÊÐÃ÷ÀÖ¿ª·¢ÓÐÏÞ¹«Ë¾±¦Ê¯³§ÊÇרҵµÄ±¦Ê¯Éú²ú ³§¼Ò£¬³¤ÆÚ´óÁ¿¹©Ó¦ÖÊÓżÛÁ®°×»ÆÓñʯ³ÉÆ·£¬ÊʺÏÉú²ú ¸÷ÀàÊÖÊΡ¢Í·ÊΡ¢ÐØÕë¼°Ë¿½í¿ÛµÈ×°ÊÎÆ·£¬³ÉÆ·ÓÐÔ²ÐΡ¢ ÍÖÔ²ÐΡ¢Ë®µÎÐΡ¢éÏé­ÐΡ¢Õý·½ÐΡ¢³¤·½ÐΣ¬¹æ¸ñÆëÈ«£¬ »õÔ´³äÔ££¬¿É³Ð½Ó¶©µ¥£¬»¶Ó­À´ÈËÀ´µçǢ̸ҵÎñ¡£ µØÖ·£º¹ã¶«Ê¡½­ÃÅÊÐÅîÀ³Â·Æ½°²Àï23ºÅ µç»°£¨86£©750-3311638 £¨86£©750-3311938 µç×ÓÓÊÏ䣺mailto:minglebaoshi@163.net ÍøÖ·£ºhttp://www.huali-cn.com/mingle/ ¡ª¡ª¡ª¡ª¡ª¡¡The message was sent by Super Mass Mail¡¡¡ª¡ª¡ª¡ª¡ª Download from The Worldfax Network.¡¡http://www.worldfax.net Start send worldwide free fax and(or) get free website advertising now! From rem-conf Sun Nov 21 08:03:58 1999 From rem-conf-request@es.net Sun Nov 21 08:03:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11pZNI-0000PZ-00; Sun, 21 Nov 1999 07:58:00 -0800 Received: from server04.ccim.be (ccim.be) [194.78.32.244] by mail1.es.net with smtp (Exim 1.81 #2) id 11pZNC-0000PO-00; Sun, 21 Nov 1999 07:57:59 -0800 Received: from [38.26.242.114] by ccim.be (SMTPD32-3.04) id ABC2C6502F6; Sun, 21 Nov 1999 17:20:18 +0100 From: "Kevin" Subject: You Can Too To: succeed29ik@es.net X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sun, 21 Nov 1999 09:41:43 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *** URGENT *** ACCEPT CREDIT CARDS =46OR YOUR BUSINESS AND INCREASE YOUR PRO=46ITS 30%-50% ! INTERNET STORE=46RONT HOMEBASED OR MAIL ORDER BUSINESSES WE SPECIALIZE IN HELPING THE SMALL BUSINESS OWNER! AND YOUR =46IRST AND LAST MONTH LEASE PAYMENT IS =46REE YOU CAN GET STARTED =46OR ONLY $9.95 !!! I=46 YOU CALL IN THE NEXT =46IVE DAYS YOU WILL RECEIVE: NO APPLICATION =46EE NO PROGRAMMING =46EE DON'T =46ORGET TO ASK ABOUT OUR WEB HOSTING AND DESIGN PACKAGE= !!! CALL (888) 264-9272 OUR HOURS O=46 BUSINESS ARE 9AM - 6PM MST ///////////////////////////////////////////////////////////////////// / Please remove at mailto:kbaz@wongfaye.com?subject=3Dremove //////////////////////////////////////////////////////////////////////= From rem-conf Mon Nov 22 01:37:47 1999 From rem-conf-request@es.net Mon Nov 22 01:37:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ppm2-0000hT-00; Mon, 22 Nov 1999 01:28:38 -0800 Received: from zeus.tvn.cl (tvn.cl) [200.28.48.50] (fwuser) by mail1.es.net with esmtp (Exim 1.81 #2) id 11pply-0000gm-00; Mon, 22 Nov 1999 01:28:34 -0800 Received: from 200.28.48.50 by tvn.cl (8.8.8+Sun/SMI-SVR4) id GAA04554; Mon, 22 Nov 1999 06:22:20 -0300 (CDT) From: LongDistance@flatrate.fsnet.co.uk Message-Id: <199911220922.GAA04554@tvn.cl> To: LongxDistance@excite.com Date: Mon, 22 Nov 99 00:30:23 EST Subject: Re:UNLIMITED Long Distance? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IMAGINE! UNLIMITED Long Distance Calling for only $35/month flat rate! We're in a pre launch! It was bound to happen... there is a new telephone company offering UNLIMITED US Domestic Long Distance Calling for a flat rate of $35 per month... no computer required... phone to phone... "pin drop" quality. FREE Demo and rep information available: Please Hit Reply and leave us your : Name & e-mail address, very Important , NO information will be sent without your e-mail Address. We use an automated system that responds only to your e-mail address. (you will receive your requested information within 24-72 hours) Thank you! Imagine being able to make UNLIMITED Long Distance calls for only $35 a month? :::::::::::::»§«:*´`³¤³´`*:»§«::::::::::::: Making Dreams Come True! :::::::::::::»§«:*´`³¤³´`*:»§«::::::::::::: This "Hot", new, technology will also allow you to (realistically) make $2-5,000 in less than 30 days part-time! _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ If you have received this message in error, please reply with the word remove in the subject. _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ From rem-conf Mon Nov 22 02:07:25 1999 From rem-conf-request@es.net Mon Nov 22 02:07:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11pqGE-0001V4-00; Mon, 22 Nov 1999 01:59:50 -0800 Received: from (post.netchina.com.cn) [202.94.1.48] by mail1.es.net with smtp (Exim 1.81 #2) id 11pqFg-0001U5-00; Mon, 22 Nov 1999 01:59:21 -0800 Received: (qmail 16605 invoked from network); 22 Nov 1999 10:00:54 -0000 Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227) by 202.94.1.48 with SMTP; 22 Nov 1999 10:00:54 -0000 Message-ID: <38391384.895CF0A@netchina.com.cn> Date: Mon, 22 Nov 1999 17:57:25 +0800 From: Robert Tan Reply-To: tjsh@netchina.com.cn Organization: Tan Junsheng X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Dear Sir: This is my discussion article. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir: This is my discussion article. The title: Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter The details: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc Sincerely, Robert Tan 11.22 Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter The Next Era Web of Multimedia Data-stream Transmission Solution of the Internet! By Robert Tan Update: 1999. 11. 22 For the many more format and definite of standard of digital film and video, digital audio and the other multimedia data stream of tomorrow, the existing network technology including the modern internet webs will be fabulous and difficult to transmit it for us. The Endpoint Congestion almost resistant our viewer area full of the entire world, We would need the straightway link of the multi-media data-stream in real-time for us. Would you like to get a lower cost & more effective digital signal channel in a wide-bandwidth or broadband hybrid coax cable system? For the FTTX, HFC networks, especially in the HFC networks with the 256QAM or 64VSB digital modulation technology systems, the SSB-ASK or the VSB-ASK technology transmission systems would be used normally. The Flash Bandwidth 1KHZ to 100MHz digital control a variable frequency bandwidth, it is high-performance anti-alias & reconstruction (FBW) filter, it will be able to provide a variable multiplex sub-frequency band in any broadband HFC system. With the FDM assistant digital carry system and SSB or VSB signal channel, a group of FBW filters will provide separate multi-frequency bands in spectrum without any cross talking and distortion by a large frequency range in a high-speed high- effective transmission system. In a FTTX or HFC web, this digital controlled signal channel would have a very large frequency spectrum changed dynamic range. For a large client group, such as the Broadband Cable Internet Access or HFC users, one of them would like to get a variable data speed according to the applications of his needed. It will provide a lot of digital control frequency bandwidth which is separated one another in HFC transmission system, and it will more effective for the "hot clients", such as the VOD video clients or the other high-code rate users and high-speed data stream user's applications. The FBW will improve the speed of the data stream, diminish the amount of the spare resource seizing of "Cool Clients", reduce the calculations of the DSP processor of the center web main switching system and the branch switching system. Reduce the CPU utilities of the applications in all of client communication adapter and its cost of produce is very important. The "Cool Clients" mains the IP telephone users or the other lower speed code rate audio applications. Anyway, the speed of the up-stream data and down-stream data speed could be changed to any value you needed, and the changing degree will be very smoothly and very simply in writing one or two bytes in the command system of communication web switcher. By the high-speed frequency variable characteristic, if the FBW filter were used in your FTTX or HFC switching system, the upward and downward data stream speed could be managed and attempted by your command system. So that, the transmission bandwidth will be able to adjusted to your needed in any time within one millionth second. The real-time will be very more improved and more effective on the communication main roads such as FTTX and HFC system, transmission controlling system will completely control the data stream in real-time. Dear Technology Research and Development Administrator: I am an electronic engineer in the field of Analog and Digital filters researching and designing. I had been a DSP engineer for ten years. My development field is electronic circuits -- digital and analog hardware designing and researching in applications of Digital Signal Processing. My works contains the frequency spectrum analysis, digital audio and digital video systems, noise spectrum controlling and processing, and the other military applications. I have researched and designed several kind of analog and digital anti-alias & reconstruction filters. A few years before, in my R&D works, I find the special frequency of the filters is usually fixed, it could be very difficult to change the cutoff frequency of the low-pass anti-alias & reconstruction filter. But the fixed filter could not suit the target of my technical applications. If we want to get several special frequency of the filters, we must to use several different fixed filters or instead of fixed filter with switching capacity filter or digital filter, such as IIR or FIR filter, and their frequency must be variable in order to change the analysis frequency. It is very important for the spectrum analysis system and the digital random real time vibrated controlling system. But, in this way, we must pay for digital IIR or FIR filter, it is very expensive in the price, take a large space for the DSP chips and its outside memory banks to install it. So, we would get into much troubles and complex questions from a simple problem. However, we have the switching capacity technologies, and the product of up to 8th order filters is a very normally used. But the switching capacity filter will have a high noise and low frequency range, and it has a non-exactly special frequency, generally. The special frequency of most of the switching capacity filters is from 1/95 to 1/105 times of its main switching clock and it is difficult to improve its accuracy. Actually, the switching capacity filter circuit is very difficult to adjust and use in applications. Anywise, its order is normally below 8th order, and the special frequency and bandwidth of the switching capacity filters is below to 50KHz, and the amplitude response is not exactly yet, the dynamic range of the amplitude is very low, normally, it is below the 48dB. Except of frequency range from 0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not usefully, it is normally being used in the speech processing circuit and the other lower frequency band processing systems. Attention, all of this analysis is not including the phase noise of the main switching clock and the noise of clock feed through yet. The others, it is difficult to get much more analysis frequency bands or special frequency points for the switching capacity filters, it is especially for the higher frequency band which is approached to the top frequency point. All of these characteristics of the switching capacity filters will restrict its applications in the area of modern digital communications. The others method of the filters designing is the contact-time analog filter .I have found some method. It could make many transfer functions. Such as the elliptical function, Chebyshev function and Butterworth function, but there is some interesting things here, it is that the same circuit frame could be built into many transfer functions, and it would have programmable (digital controlled) special frequency. Changing special frequency on line is available. It could get the very wide frequency range, very quickly to change the used band, and the digital controlled circuit is very directly and simply, the special frequency step is very smoothly (because the Frequency is controlled by long bit Digital multiplier). In that points, integrate the FBW filter circuit technology is very useful for the digital controlling and processing systems. Because of the Digital Controlling Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8 or 12 bits long Digital Multiplier and a few chips of high-speed amplifiers. The other, this filter technology is used with a few exactitude resistors and exactitude capacitors also. For example, an 8th order elliptical filter need 8chips of dual Digital Multiplier and several chips high bandwidth amplifiers, 8chips exactitude capacitors and several chips exactitude resisters. If it is possible, integrating all the Digital Multiplier and amplifiers into one chip or one plastic package (mixed circuit), place all the exactitude resistors and capacitors out of the package. It will be finest filter and very easy to used and could be re-designed agilely by the customers and the OEMs. The parameter of the filters is depending on the value of the resistors and the capacitors. Its value could be designed by the customs freely and calculated by constant functions directly, and that is very simply. And then, the FBW filters would be very usefully in the FTTX or HFC networks. For working with the 256QAM or 64VSB modulation technology and any narrow-band transmission technology systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV and VOD systems, it would compress the used frequency bandwidth in mostly extent. Because of the WAN systems in any nations will be depending on the "Tree structures" as the main road in the webs in the future. The frequency source is very expensive in this web, It would be welcomed in the Internet web digital information transmission, exchanging and switching technology area, DSP area and digital communications area, such as MAN and WAN coax cable webs or the FTTX system applications. Any way, the most of modern networking transmission mode is TDM. It is very suitable for the text material or media, because of it is a fixed media in size, and it is the fixed continue time in length and generation procedure. But the most of multimedia is not to be suitable with that. The data stream of voice and video will have no constant size to be forecasted has no constant procedure time. It is only have a constant and fixed bandwidth of media data stream. Because of your interesting points is onto the generations and the procedures of the video or audio information of thus material or the news, such as the high quality digital cinema, digital musicale and so on. Certainly, you could take the any multimedia information and any moving picture on you desktop through the Internet Web. It will be appeared the true alive world with you in any site you can go! So that, the only one of best way of the media data streams transmission and exchanging is the FDM mode with the SSB-ASK or VSB-ASK technology, it should be working with the QAM or VSB- ASK digital modulation technology in the future Internet webs. FBW filter would be used in most of switchers and routers, which is depending on the FDM technologies. For the cable TV systems STB (set top box), video & audio servers in Broadband Cable Internet Access, cable modems or the client-end adapters in the most of family users and the most of business cable users in the world will need a very great deal of broadband web transmission bandwidth. Because of that, in any modern home-electronic equipment, such as the Internet officers, shopping's and the VOD or the other broadband information electronics, its using method would be depending on the FDM switching technologies. So that, the "Online Home-Electronics" or the other Internet accessing products which is used in people's homes would be simply to operate and easy to use. And it must be depend on the simply low-layer hardware equipment and protocols of the webs, such as the VOD systems and the STB terminals in the Broadband Cable Internet Access or HFC networks. The FBW technology would provide us more applicable and useable method in the physics layer of the public HFC networks, its FDM applications in a broadband web get us in a lower building price, more effective than the other technology. Such as the Broadband Cable Internet Access webs, HFC networks, FTTX networks, and the other and the other WAN public broadband networks would have a very great applications of the FBW filters. The others, using a Flash-Band-width filter will help you get in to a fully data stream bandwidth management of any expensive data-link channels and the very expensive communication data stream bandwidth, such as the communication data-link of the satellite communication systems, and the ocean bottom communication systems. FBW filter will control the any leased data-stream bandwidth in dynamic mode within a very large frequency range, a large range of signal frequency bandwidth and data-stream speed in any time for a communication administration and operation system. It will change the bandwidth with you leased data stream very imminently within several microsecond, improve your expensive bandwidth of data-stream transmission channel, save your leased payment and money cost for any customers of digital communications and any Tele-communication operating and service company. It will hold any important transmission of data-stream in smoothly and take it freely. So, in this system, any interrupt of your communication data stream will be never. The Digital Control Flash Bandwidth Filter specifications: (1) General details: Frequency range: 0.1Hz--100MHz Useable frequency range: 0.1Hz--100MHz(at least) Special frequency step: 0.001Hz-1000KHz Transfer functions: Elliptical, Butterworth, Chebyshev, and Bassel function. And the others contacted-time filters. Available filter type: Low-pass filter, High-pass filter, Notch filter, Band-pass filter and All-pass filter. Noise Level: -160dB(max) (Only depend on the number of the used amplifiers.) Order range: 2nd--12th(Depend on the sensitivity of the transfer functions.) Filter switching time: Less than 300nS (Filter Setting time is 200nS) Useful Range: Anti-alias filters, Reconstruction filters. (2) Pass Band Specifications: Frequency selectable range: 100Hz--100MHz (Depend on the performance of the selected amplifiers) Special Frequency steps: 1Hz-1000KHz Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of the filter.) Ripple: 0.01--1.0dB (Only depend on the filter function and the passband ripple designed.) (3) Pass to Stop Band: Drop speed of Interim-band Cut-off: 180db/oct (8th order elliptical function with 0.05dB pass-band ripple) (4) Stop Band: Amplitude min drop: 120db(8th elliptical filter for example) Frequency range: 0.1Hz--100MHz (Depend on the amplifiers and the Digital Multiplier specifications) (5) Digital Control specifications: Digital component is used (8 bit, 10bit, 12bit, and 16bit is available). The special frequency is (N1/N2) * Frequency (ref). (The N1, N2 is the Digital component input byte, from 8bit to 16 bit.) The Frequency (ref) is form 10Hz to 10MHz. (This parameter is depends on one RC time constant.) High speed and voltage feedback high-bandwidth operation amplifiers are required. (6) Requirement: (The filter section of 8th order) Digital component: 8 chips (Selections depend on the frequency range) High-performance Amplifiers: 12 to 24 chips (Selections depend on the frequency) Capacitors or inductors: 8 chips (exactitude degree value is 1% to 0.1%) Resistors: 16-36 chips (exactitude degree value is 1% to 0.1%) (7) Group delay: Depend on the function of the filter designed, filter phase response designed, and the filter order. (8) Filter switching time: Less than 300nS (Filter Setting time is 200nS) The Comparisons of the 4 kinds active Filters For example: 8th order filter Switching Capacity Filter Digital Filter (FIR or IIR Filter) Traditional Fixed Analog Frequency Filter Digital controlling FBW filter Noise Level or (THD+N) Value: Highest -48db Lower -70db Very Low -160db Very Low -120db Filter Dynamic Range The Value: Little 50db Middle 70db Very Large 160db Large 100db Real-time active frequency The range of the value: Narrow 200Hz to 300KHz Wide 0.001Hz to 50KHz Very Wide 0.1Hz to 1MHz Very wide 0.001Hz to 100MHz The Outside in advance Anti-alias & Reconstruction assistant filter requirement The degree of assistant filter Quality Required 2nd to 4th order anti-alias & reconstruction assistant outside filter Required 4th to 6th order anti-alias & reconstruction assistant outside filter Not required. ---------- Not required ---------- The Precision of the special frequency: The ability of on-line changing the filter special frequency &Method Low. +/-3% Very easy (Changing the switching clock) High +/-3% Very difficult (Change a new programs and parameters ) Very high 0.1% Very difficult. (Changing the system time constant) Very high 0.1% Easy(Writing digital word to the filter control port) The complex degree of the filter system designing &The used space Simple Small Very complex Very large Simple Middle Middle Middle The price for produce a filter &The difficult degree of the applications Very low $10~50 Easy Very high $300~600 Difficult Low $30~90 Easy Middle $50~100 Middle Anti-alias & Reconstruction filter Performance: (1)Pass Band Ripple &Dynamic Range: (2)Stop Band Rejection (3)Interim Band Dropping Slope: Low Quality & Low Price. +/-0.2db 50db 55db 50db/oct Normal or High Quality & High price +/-0.01db 70db 70db 130db/oct Normal Quality & Low Price +/-0.01db 120db 120db 180db/oct High Quality & & Middle Price. +/-0.01db 110db 120db 180db/oct Online/offline Changing of highest/lowest special frequency rate & Range: &changing time: All available 1000 times 300Hz to 300KHz 10mS(Time of PLL tracking & locked) Offline available Not available Not available Not available (Reboot DSP & A/D system) Offline available 1000 times Not available Not available All available 100000 times 1KHz to 100MHz 160nS (TTL 2 bytes writing time) Filter online reconstruction setting time (The total time of filter frequency switched) 10mS Not available Not available 300nS Group delay and the phase response: Producer design only. Linear or Producer design only. Producer design only. Producer & User design is available. Equality data stream speed or comported speed of its TxDAC : &Butterworth 8th filter (Broadband channel HFC usable signal dynamic range is about 50dB): 4.8Kbps to 4.8Mbps (600SPS to 600KSPS) 8bit TxDAC Constant 400Kbps (50KSPS) 8bit TxDAC Constant 800Mbps (100MSPS) 8bit TxDAC 16Kbps to 1600Mbps (2KSPS to 200MSPS) 8bit TxDAC Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in SSB/VSB mode of technology (Data speed of Base Band): Carrier signal RF full-band tie up: Difficult to be used with the 256QAM and 64VSB. (High Level Phase Noise) 4.8Kbps(Min) 4.8Mbps(Max) 384Hz to 384KHz Difficult to be used in variable data-speed transmission or receiving system Difficult to be used in variable data-speed transmission or receiving system With 256QAM: 8Kbps(Min) 800Mbps (Max) With 64VSB: 12Kbps(Min) 1200Mbps (Max). 1.28KHz to 128MHz For the HFC Specialty signal TV Channel: 40dB Eb/N 6MHz Full-band 64VSB model @1KHz-6MHz Data-rate: With 64VSB: 9.375Kbps (Min) 56.25Mbps (Max) Contact Address: No.2 Buliding Room1007, Mudanyuan Beili, Haidian District Beijing P. R. China, Post Code: 100083 Name: Tan Junsheng (Robert Tan) Tele: 8610-82076834, 86-13701070213(Mobile) E-mail: Tjsh@netchina.com.cn or tanjun@hotmail.com Homepage: http://www.cnindex.net/~tjsh Details Remind: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html From rem-conf Mon Nov 22 05:01:42 1999 From rem-conf-request@es.net Mon Nov 22 05:01:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11pt2m-0003OJ-00; Mon, 22 Nov 1999 04:58:08 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11pt2k-0003O9-00; Mon, 22 Nov 1999 04:58:06 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Nov 1999 12:57:59 +0000 To: rem-conf@es.net Subject: AVT slides from Washington DC Date: Mon, 22 Nov 1999 12:57:58 +0000 Message-ID: <1304.943275478@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Copies of the slides presented in the last AVT meeting are now available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/IETF46/slides/ Colin From rem-conf Mon Nov 22 10:54:38 1999 From rem-conf-request@es.net Mon Nov 22 10:54:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11pyWb-0007KE-00; Mon, 22 Nov 1999 10:49:17 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11pyWa-0007K0-00; Mon, 22 Nov 1999 10:49:16 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id KAA10092; Mon, 22 Nov 1999 10:47:30 -0800 (PST) Message-Id: <4.1.19991122104601.038605e0@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 22 Nov 1999 10:48:17 -0800 To: GeeVarghese John , Tmima Koren , casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, gvjohn@miel.mot.com, pazhynnr@cig.mot.com From: Tmima Koren Subject: Re: Extensions to CRTP In-Reply-To: <38358E06.C3F08940@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_434372375==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_434372375==_.ALT Content-Type: text/plain; charset="us-ascii" At 12:51 PM 11/19/99 -0500, GeeVarghese John wrote: > > Sorry, Please neglect my previous mail, this is the correct mail .. > I pasted my answers at the wrong place which might confuse those who read .. > > GVJ > > GeeVarghese John wrote: >> >> Hi, >> >> My comments to you answers are added below .. >> Please have a look at that // >> >> Tmima Koren wrote: >>> >>> >>> At 02:13 PM 11/18/99 -0500, you wrote: >>>> >>>> Steve, Tmima & all, >>>> >>>> This is regarding the ietf draft - Extensions to CRTP : >>>> draft-koren-avt-crtp-enhance-00.txt >>>> I have few doubts and could you please clarrify these points .. >>>> >>>> In the section 1. COMPRESSED_UDP packet "T bit" .. >>>> >>>> It is stated that CUDP packet reset the deltaT value to 0 and >>>> therefore T bit avoids the need to send deltaT in the next CRTP. >>>> >>>> Q1) My doubt is If the entire original RTP header is the in the CUDP packet >>>> why to >>>> send the delta also with the original header .. >>>> why can't the decompressor findout the new delta to be used >>>> from the RTP header in the CUDP packet itself, Is it not redundancy ? >>>> >>>> Also You have stated that >>>> >>>> >> Multiple COMPRESSED_UDP packets may be sent by the compressor when >>>> changes in the >>>> >> compressor state need to be synchronized. Sending multiple packets will >>>> increase the >>>> >> probability of delivery of the synchronized state in the event of >>>> packet loss. >>>> >>>> Why do we need to send multiple packet and how it will increase the >>>> probability even >>>> if you send more CUDP packets, as long as the decomperssor look at the seq >>>> number >>>> and detect packet loss it should send a CONTEXT_STATE packet. >>>> >>>> If the draft reference you made was for loss of more than 16 packets from >>>> the same flow, >>>> and the possible wrong decompression of headers .. >>>> twice algorithm should detect this (But twice algo is not used if checksum >>>> is 0) >>>> So here what exactly the limit could be , the sequence number space 1..16 >>>> Since this draft address the use of this algo over ATM/AAL5 links I think >>>> sequence number space 1..16 may not be sufficient. >>> >>> >>> >>> Some notations: >>> dt deltaT >>> FH FULL_HEADER >>> CR COMPRESSED_RTP >>> CR+ COMPRESSED_RTP with deltaT (dt) >>> CU COMPRESSED_UDP >>> CU+ COMPRESSED_UDP with dt >>> CS CONTEXT_STATE >>> >>> I'll use an example >>> The sender sends a sample every 10 ms >>> Using CRTP, the sequence of packets will be: >>> >>> seq# Time pkt type >>> 1 10 FH >>> 2 20 CR+ dt=10 >>> 3 30 CR >>> ... >>> 10 100 CR >>> >>> At this point this side stops talking. Talking resumes at time 200 >>> >>> 11 200 CR+ dt=100 >>> 12 210 CR+ dt=10 >>> 13 220 CR >>> .... >>> >>> With the extension of T-bit in CU, we can send: >>> >>> 11' 200 CU+ dt=10 >>> 12' 210 CR >> > > > Here, I think you assumed that 12' packet will reach the compessor with > timestamp 210. But, unfortunately if it was lost what you get is 13' and time > stamp 220. > In that case again you have send dt again with your CU+ after sending CU+ > with dt 10. > In this type of situation processing due to delta encoding was double and you > send two > delta encoded bytes in two different packets insteadof one > You might have assumed that MOST of the case packet loss doesnot happen .. > But I feel that is also purely dependant on the network where this algorithm > is executing .. > > And also are you not loosing the bandwidth saving by sending CU+ instead of > CR > because you send the complete RTP hdr + delta encoded deltaT byte in CU+. > >> >>> >>> >>> ... >>> >>> We are trying to adopt CRTP to links that have some loss of packets and a >>> long round trip time (RT) >>> We want to avoid the decompressor getting out of sync and having to send CS >>> because this will cause loss of many packets for this stream due to the >>> long RT. >>> >>> Let's check what happens if some packets are lost >>> 1. packet 4 was lost >>> The decompressor will use the 'twice' and will stay in sync >>> 2. packet 11 was lost >>> The decompressor is out of sync >>> 3. packet 11' was lost >>> The decompressor is out of sync >>> >>> We see that there is a weak point in the compression at the beginning of a >>> talk spurt >>> We try to correct this by sending multiple CU+ >>> >>> 11" 200 CU+ dt=10 >>> 12" 210 CU+ dt=10 >>> 13" 220 CR >>> >>> ... >>> >>> If the decompressor received any of 11" or 12" , he is still in sync >> > > I think this is not correct, If the decompressor receives 12" insted of 11", > he is not in sync because of link seq number mismatch and > will send a CONTEXT_STATE packet. > This will lead to FH sending from compressor to decompressor .. >> >> >>> >>> >>> >>> How many CU+ do we want to send at the beginning of a talk spurt? >>> This depends on the quality of the link (which is good but not perfect). >>> If we know that on this link we may lose at most 2 packets in a row, we'll >>> send 3 CU+ at the beginning of a talk spurt >> > > Looks OK, but How do we decide on the number of packet loss ? > Packet loss can be due to link quality and/or network congestion etc .. > If the loss was due network congestion or similar factor, behaviour vary from > time to time .. > So here also CU+ is giving disadvantage instead of the benifits expected. >> >>> >>> >>> The decompressor will stay in sync as long as he received at least one of >>> the CU+ >> > > I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from > > decompressor to compressor because of the link seq number mismatch ..Is nt it > ? The decompressor should be in sync after receiving a CU+. There is no reason for a CS Tmima > > >> >> >>> >>> >> >> I will include rest of the questions in another mail .. >> Please reply back .. >> >> Rgds >> GVJ >> >> >> > > > --=====================_434372375==_.ALT Content-Type: text/html; charset="us-ascii" At 12:51 PM 11/19/99 -0500, GeeVarghese John wrote:
Sorry, Please neglect my previous mail, this is the correct mail ..
I pasted my answers at the wrong place which might confuse those who read ..

GVJ

GeeVarghese John wrote:
Hi,

My comments to you answers are added below  ..
Please have a look at that  //

Tmima Koren wrote:
 
At 02:13 PM 11/18/99 -0500, you wrote:
Steve, Tmima  & all,

This is regarding the ietf draft - Extensions to CRTP  : draft-koren-avt-crtp-enhance-00.txt
I have few doubts and could you please clarrify these points ..

In the section 1. COMPRESSED_UDP packet "T bit" ..

It is stated that CUDP packet reset the deltaT value to 0 and
therefore T bit avoids the need to send deltaT in the next CRTP.

Q1) My doubt is If the entire original RTP header is the in the CUDP packet why to
send the delta also with the original header ..
why can't the decompressor findout the new delta to be used
from the RTP header in the  CUDP packet itself, Is it not redundancy ?

Also You have stated that

>> Multiple COMPRESSED_UDP packets may be sent by the compressor when changes in the
>> compressor state need to be synchronized. Sending multiple packets will increase the
>> probability of delivery of the synchronized state in the event of packet loss.

Why do we need to send multiple packet  and how it will increase the probability even
if you send more CUDP packets, as long as the decomperssor look at the seq number
and detect  packet loss  it should send a CONTEXT_STATE packet.

If the draft reference you made was for loss of more than 16 packets >from the same flow,
and the possible wrong decompression of headers ..
twice algorithm should detect this (But twice algo is not used if checksum is 0)
So here what exactly the limit could be , the sequence number space 1..16
Since this draft address the use of this algo over ATM/AAL5 links  I think
sequence number space 1..16 may not be sufficient.


Some notations:
dt         deltaT
FH        FULL_HEADER
CR       COMPRESSED_RTP
CR+     COMPRESSED_RTP with deltaT (dt)
CU       COMPRESSED_UDP
CU+     COMPRESSED_UDP with dt
CS       CONTEXT_STATE

I'll use an example
The sender sends a sample every 10 ms
Using CRTP, the sequence of packets will be:

seq#   Time     pkt type
1        10         FH
2        20         CR+    dt=10
3        30         CR
...
10      100       CR

At this point this side stops talking. Talking resumes at time 200

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR
....

With the extension of T-bit in CU, we can send:

11'     200       CU+    dt=10
12'     210       CR

Here, I think you assumed that 12'  packet will reach the compessor with
timestamp 210. But, unfortunately if it was lost what you get is 13' and time stamp 220.
In that case again you have send dt again with your CU+ after sending CU+ with dt 10.
In this type of situation processing due to delta encoding was double and you send two
delta encoded bytes in two different packets insteadof one
You might have assumed that MOST of  the case packet loss doesnot happen ..
But I feel that is also purely dependant on the network where this algorithm is executing ..

And also are you not loosing the bandwidth saving by sending CU+ instead of CR
because  you send the complete RTP hdr + delta encoded deltaT byte in CU+.
 
 
...

We are trying to adopt CRTP to links that have some loss of packets and a long round trip time (RT)
We want to avoid the decompressor getting out of sync and having to send CS because this will cause loss of many packets for this stream due to the long RT.

Let's check what happens if some packets are lost
1. packet 4 was lost
    The decompressor will use the 'twice' and will stay in sync
2. packet 11 was lost
    The decompressor is out of sync
3. packet 11'  was lost
    The decompressor is out of sync

We see that there is a weak point in the compression at the beginning of a talk spurt
We try to correct this by sending multiple CU+

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR
 
...

If the decompressor received any of 11"  or 12" ,  he is still in sync
I think this is not correct, If the decompressor receives 12" insted of 11",
he is not in sync because of link seq number mismatch and
will send a CONTEXT_STATE packet.
This will lead to FH sending from compressor to decompressor ..
 
 

How many CU+ do we want to send at the beginning of a talk spurt?
This depends on the quality of the link (which is good but not perfect).
If we know that on this link we may lose at most 2 packets in a row, we'll send 3 CU+ at the beginning of a talk spurt
Looks OK, but How do we decide on the number of packet loss ?
Packet loss can be due to link quality and/or network congestion etc ..
If the loss was due network congestion or similar factor, behaviour vary >from time to time ..
So here also CU+ is giving disadvantage instead of the benifits expected.
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?

The decompressor should be in sync after receiving a CU+. There is no reason for a CS
Tmima

 
 
 
I will include rest of the questions in another mail ..
Please reply back ..

Rgds
GVJ
 
 
 

 

--=====================_434372375==_.ALT-- From rem-conf Tue Nov 23 01:28:08 1999 From rem-conf-request@es.net Tue Nov 23 01:28:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qC4L-0006aU-00; Tue, 23 Nov 1999 01:17:01 -0800 Received: from hts.on.ca [206.47.33.2] by mail1.es.net with smtp (Exim 1.81 #2) id 11qC4K-0006a3-00; Tue, 23 Nov 1999 01:17:00 -0800 Received: from mail.tor.mailerwebmachine235.com by hts.on.ca;Tue, 23 Nov 1999 09:24:01 GMT From: To: Date: Wed, 24 Nov 1999 20:23:19 Message-Id: <37.790516.619968@mail.tor.mailerwebmachine235.com> Subject: Get online today accepting credit cards. Our company even allows you to accept government cards. 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 BECOME A VIRTUAL MERCHANT! 100% ON LINE "REAL TIME" SEAMLESS E-COMMERCE CREDIT CARD SYSTEM WILL PUMP UP YOUR WEBSTORE BUSINESS VOLUME! INTERNET AND DIRECT MARKETING PROS KNOW THAT CUSTOMER'S ON THE WEB WILL SPEND 2.5 TIMES AS MUCH BEING ABLE TO PAY WITH A CREDIT CARD AS OPPOSED TO CASH! A SECURE "SSL" SERVER BASED PLATFORM THAT WILL LEND IMMEDIATE CREDIBILITY TO YOUR ON-LINE STORE! FAST APPROVALS AND SET UP! LOWEST ON LINE PROCESSING RATES AVAILABLE! NO APPLICATION OR SET UP FEES!! TRUE MERCHANT SERVICES / SYSTEM OWNERSHIP PROGRAM! COME ENJOY THE TOTAL CARDSERVICE EXPERIENCE TODAY!!!!! For further information please call 877 205 9117. _________________________________________________________________ _________________________________________________________________ Have a product or service to market on the internet? Try our bulk email service today! Check out our introductory offer today ! 150,000 emails sent advertising your product or service for only $295.00! Want to bulk email yourself? Call 877 205 9117 TODAY and check out our latest bulk email programs today! Want bulk email freindly web hosting? Give us a call today! Professional Express System Holdings Inc Montreal Quebec 877 205 9117 From rem-conf Tue Nov 23 02:27:55 1999 From rem-conf-request@es.net Tue Nov 23 02:27:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qD4o-00010P-00; Tue, 23 Nov 1999 02:21:34 -0800 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qD4m-00010D-00; Tue, 23 Nov 1999 02:21:33 -0800 Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA11805; Tue, 23 Nov 1999 11:21:29 +0100 (MET) Received: by lms001.lu.erisoft.se id LAA14358; Tue, 23 Nov 1999 11:21:27 +0100 (MET) Message-ID: <022101bf359c$6a476f60$2bb08496@e00008639f5da.epl.ericsson.se> From: "Lars-Erik Jonsson" To: "GeeVarghese John" , "Tmima Koren" , , , , , , , Subject: T-bit extension for CRTP Date: Tue, 23 Nov 1999 11:20:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id LAA11805 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a number of comments both to what is said in the draft (draft-koren-crtp-enhance-00.txt) and to the previous discussions about i= t. All are included below: - Draft: The purpose Tmima: In the draft you state that you need this to be able to do periodi= c refreshing of the context when CRTP is used over links with large RTT. However, in the previous discussion you are only talking about what happe= ns after silence periods. I think you should clarify what you are really aim= ing for, maybe the draft should also talk about the implications after silenc= e periods. - Draft: Packet types for refreshing In the draft it is stated that there are TWO packet types that can be use= d to periodically refresh the context of an IPv4 CRTP decompressor, FULL_HEADER and COMPRESSED_UDP packets. This is not really correct. For IPv4, the COMPRESSED_UDP packet does NOT refresh the context completely, because the IP-ID is communicated as a delta. The COMPRESSED_NON_TCP pack= et type should instead be used with IPv4. For IPv6, the two packet types(C_NON_TCP and C_UDP) carries the same information and are identical= in size. - Discussion: GeeVarghese Q1 >Q1) My doubt is If the entire original RTP header is the in the CUDP pac= ket why to >send the delta also with the original header .. >why can't the decompressor findout the new delta to be used >from the RTP header in the CUDP packet itself, Is it not redundancy ? The decompressor can NOT find out the delta for sure, because its context could have been invalid when the C_UDP was received. So, if the intention= is to have the delta "correctly" set (not reset to 0) after a C_UDP, then yo= u must include it. The question is whether this is advantageous compared to the current solution, sending the delta in subsequent C_RTP. - Discussion: GeeVarghese about multiple packets >Why do we need to send multiple packet and how it will increase the probability even >if you send more CUDP packets, as long as the decomperssor look at the s= eq number >and detect packet loss it should send a CONTEXT_STATE packet. Yes, but if the RTT is large, the update procedure would take a long time. If Twice is used (requires UDP checksum and should be used carefully), lo= ss of packets that DO NOT change the decompressor context could be handled without discarding additional packets. On the other hand, if packets that= DO change the context are lost, Twice would fail and subsequent packets must= be discarded while waiting for a refresh. If context update information was repeated in more then one packet, a higher tolerance against packet loss could be achieved. - Discussion: The example >Some notations: >dt deltaT >FH FULL_HEADER >CR COMPRESSED_RTP >CR+ COMPRESSED_RTP with deltaT (dt) >CU COMPRESSED_UDP >CU+ COMPRESSED_UDP with dt >CS CONTEXT_STATE >I'll use an example >The sender sends a sample every 10 ms >Using CRTP, the sequence of packets will be: >seq# Time pkt type >1 10 FH >2 20 CR+ dt=3D10 >3 30 CR >... >10 100 CR >At this point this side stops talking. Talking resumes at time 200 >11 200 CR+ dt=3D100 >12 210 CR+ dt=3D10 >13 220 CR >.... >With the extension of T-bit in CU, we can send: >11' 200 CU+ dt=3D10 >12' 210 CR >... When I look at the two different solutions 11+12 and 11'+12' I can not really see the big advantage of 11'+12'. First of all, the latter require= s more overhead. While 11 would have a 3 octet header, the 11' header would= be at least 15 octets large. The idea is certainly to have the context completely refreshed, but that could not be achieved with CU+ because it does not include the IP ID in absolute terms. IF you want to refresh the context with a CU packet as packet #11, you could also still use the old = CU and send the dt-value in the next compressed packet, it would require one octet less in the CU and one more in the CR(+). Also the dt information could be repeated in more than one CR-packet for use with "sophisticated Twice". - Discussion: GeeVarghese about FH >I think this is not correct, If the decompressor receives 12" insted of 11", >he is not in sync because of link seq number mismatch and >will send a CONTEXT_STATE packet. >This will lead to FH sending from compressor to decompressor .. Not necessarily a FULL_HEADER, a COMPRESSED_NON_TCP would be a better choice. - Discussion: GeeVarghese and Koren about CONTEXT_UPDATE >>I think any of the CU+ loss will lead to CONTEXT_STATE packet generatio= n from >>decompressor to compressor because of the link seq number mismatch ..Is= nt it ? >The decompressor should be in sync after receiving a CU+. There is no reason for a CS As the CRTP RFC says: "Note, however, that there is a nontrivial risk of = an incorrect positive indication. It may be advisable to request a FULL_HEAD= ER or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds." The UDP checksum is rather weak, so especially if you use more complex "twice= " solutions, the advice above should be followed, meaning that a CONTEXT_ST= ATE packet should be sent. Regards!! /Lars-Erik -------------------------------------------------------------- Lars-Erik Jonsson, M.Sc. Voice Processing and Radio Network Research Ericsson Erisoft AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Mobile: +46 70 365 20 58 Fax: +46 920 20 20 99 Home: +46 920 999 57 From rem-conf Tue Nov 23 05:34:52 1999 From rem-conf-request@es.net Tue Nov 23 05:34:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qG17-0003K4-00; Tue, 23 Nov 1999 05:29:57 -0800 Received: from 01-060.025.popsite.net (server02) [209.119.188.60] by mail1.es.net with smtp (Exim 1.81 #2) id 11qG15-0003Ju-00; Tue, 23 Nov 1999 05:29:56 -0800 From: To: Date: Tue, 23 Nov 1999 03:47:02 Message-Id: <384.382595.621379@server02> Subject: Wealth Creation And Freedom 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 Do you have the desire to retire in 2-3 years with Real Financial Independence and Freedom? We don't want to waste your time...or ours. If you have a work ethic that is above the norm, and a burning desire to be successful and wealthy, keep reading. If not, delete this message. If you know what your goals are and are looking for a way to take you there that won't take half of your lifetime, then call me.  I'm short on time, but happy to help if you are serious about being among the wealthiest and best informed in the new millennium. And please, only call if you truly desire wealth and knowledge. REGARDLESS OF AGE OR DEBT LOAD NOT MLM OR FRANCHISE 24 hour recorded message: 800-320-9895 ext. 5433 "A burning desire to be and do is the starting point from which the dreamer must take off."    Napoleon Hill From rem-conf Tue Nov 23 08:56:19 1999 From rem-conf-request@es.net Tue Nov 23 08:56:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qJ8U-0005pE-00; Tue, 23 Nov 1999 08:49:46 -0800 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qJ8S-0005p4-00; Tue, 23 Nov 1999 08:49:45 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id JAA25193; Tue, 23 Nov 1999 09:49:17 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA25777; Tue, 23 Nov 1999 09:49:09 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id WAA03734; Tue, 23 Nov 1999 22:22:49 +0530 (IST) Message-ID: <383B58AF.2DE7EFBD@miel.mot.com> Date: Tue, 23 Nov 1999 22:17:03 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> Content-Type: multipart/alternative; boundary="------------FBCBB89BB0AB9919535664A3" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------FBCBB89BB0AB9919535664A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> >> >> >> The decompressor will stay in sync as long as he received at >> >> least one of the CU+ >> > >> I think any of the CU+ loss will lead to CONTEXT_STATE packet >> generation from >> decompressor to compressor because of the link seq number mismatch >> ..Is nt it ? > > > The decompressor should be in sync after receiving a CU+. There is no > reason for a CS > Tmima Tmima, Could you please explain, how IP id variance should be treated in this case ? For IP id field first order difference is sent as delta in CUDP with I bit set. In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated .. and also I am not still convinced with the advantage of CU+ over CR+ after the silence period. Could you please explain your point ..(please ref my previous mail) Please reply . Rgds GVJ --------------FBCBB89BB0AB9919535664A3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?


The decompressor should be in sync after receiving a CU+. There is no reason for a CS
Tmima

Tmima,

Could you please explain, how IP id variance should be treated in this case ?
For IP id field  first order difference is sent as delta in CUDP with I bit set.
In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated ..

and also I am not still convinced with the advantage of CU+ over CR+ after
the  silence period. Could you please explain your point  ..(please ref my previous mail)

Please reply .

Rgds

GVJ --------------FBCBB89BB0AB9919535664A3-- From rem-conf Wed Nov 24 04:09:39 1999 From rem-conf-request@es.net Wed Nov 24 04:09:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qb3M-0000Av-00; Wed, 24 Nov 1999 03:57:40 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qb3L-0000Al-00; Wed, 24 Nov 1999 03:57:39 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08121; Wed, 24 Nov 1999 06:57:36 -0500 (EST) Message-Id: <199911241157.GAA08121@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-rtpsample-06.txt Date: Wed, 24 Nov 1999 06:57:36 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sampling of the Group Membership in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-06.txt Pages : 11 Date : 23-Nov-99 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. NOTE: This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the binning algorithm which is a part of the specification. This declaration is being made pursuant to the provisions of IETF IPR Policy , Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-06.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-rtpsample-06.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-rtpsample-06.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: <19991123091046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991123091046.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Nov 24 11:13:38 1999 From rem-conf-request@es.net Wed Nov 24 11:13:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qhio-00047b-00; Wed, 24 Nov 1999 11:04:54 -0800 Received: from mail1.radix.net [207.192.128.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qhim-00047R-00; Wed, 24 Nov 1999 11:04:52 -0800 Received: from TheOTG.com (p2.a7.du.radix.net [207.192.132.2]) by mail1.radix.net (8.9.3/8.9.3) with ESMTP id MAA28763; Wed, 24 Nov 1999 12:24:21 -0500 (EST) Message-ID: <383C2035.EA906733@TheOTG.com> Date: Wed, 24 Nov 1999 12:28:22 -0500 From: "John Weiler, OBJECTive Technology Group" Organization: Interoperability Clearinghouse 703-768-0400 X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: info@e-interop.com Subject: Draft Announcement for Initial Interop. Clearinghouse Press Release Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.radix.net id MAA28763 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi again, I wanted to let you know that the Interoperability Clearinghouse (ICH) has greatly accelerated its Architecture Validation Program (AVP) for interoperable E-Business & Information Infrastructure frameworks. The ICH is preparing its initial press release in conjunction with industry=92s largest IT standards group, ISVs, integrators and domain implementers. If your organization is interested in participating in this launch scheduled for January, 2000, please review the following materials and get back to us ASAP, so we can discuss engagement options. If you are not the appropriate individual to represent your organization=92s interest for this effort, please forward this ICH notice to those who should be apprised of this collaborative architecture initiative. Below is a summary of some of our recent developments that will be incorporated into our January 2000 announcement. - ICH, in cooperation with the AFCEA, AFEI, IAC, and ITAA has established four E-Business blue ribbon panels for OSD AT&L and OSD C3I. The Software Quality and Interoperability working group has concluded its interim report (www.eccwg.org). Other ICH co-sponsored working groups include Information Assurance, Performance Measurements and Incentives. Participation options are open. - Due to growing demand for the ICH, OSD C3I recently concluded an extensive validation of the ICH collaborative initiative. Copies are available for prospective ICH partners. - A Defense Architecture Immersion Program is beginning with Navy, DIA, DFAS, and DoD solution providers. Focus is on directory services, web application servers, and information assurance. - OSD C3I has commissioned a Defense@OOTS seminar (www.TheOTG.com) set for March 2000. Co-sponsors include OMG, ICH, IBM, other distributed computing experts. Sponsorships are still open. - The Distributed Component-based Architecture Modeling (DCAM) IRAD team is expanding to address Information Assurance architecture modeling building on earlier R&D successes sponsored by DARPA. - AF Scientific Advisory Board references ICH as means of dealing with COTS software in its annual recommendations to the Secretary of the AF. - Dep. Of Commerce Architecture Validation Program: Frameworks addressing Web based infrastructure, PKI and Enterprise Directory services - Health Information Infrastructure (HII): Developing and Validating architecture frameworks for Government Wide Computer-based Patient Record (VA, DoD, HHS). - DOJ sponsored Justice Architecture Initiative: Cooperative effort with states to define common infrastructure frameworks. - Multi-State Architecture Validation Program began with kickoff at NASIRE conference. - Resubmission of Interoperability proposal to Federal CIO Council. - CDC has concluded a Data Warehousing mini-session in cooperation with TRW with great success. Due to the confidential nature of our Telecom and Finance Domain Architecture initiatives, we will only be able to discuss under non- disclosure. Participation Options; To help domain implementers accelerate the adoption of leading edge technologies, the ICH has instituted its industry support Architecture Validation Program. Below are ways disparate organizations can contribute to the refinement of these domain architecture models; - SDOs: Have standards abstracted and validated through mapping of specifications to product implementations. The evidence of viable standards can be found in real implementations. - Vendors: Have products offerings modeled and validated into domain architecture for multi-client applications. Technology focus areas include: Web development environments, Web Application Servers, Middleware, Directory Services, PKI, Object Persistence, Data Management, Component Models and Enterprise Resource Management. - Integrators: Support technology research and validation efforts. Document domain and technical experience for best practices repository. - Domain Users: Engage Architecture Validation Program. Co-develop and validate interoperable frameworks for secure, Internet based architectures. Architecture mentoring services available. - All: Join ICH domain working groups, collaborative IR&D project to develop knowledge repository, participate in Industry@IT- Architectures forums. Those organizations who have already begun to engage this collaborative architecture validation initiative include; Component Source, DARPA, Defense Medical, Defense Finance, Defense Intelligence Agency, Department of Justice, EDS, IBM, IEEE, Lockheed Martin, Microsoft, Object Management Group, US Navy, Bell Atlantic, NSTL, Open Applications Group, Open GIS, Office of the Secretary of Defense, Patent Trademark Office, TINA-C, TRW, State of Missouri, Federal E-Commerce Consortium (ITAA, CommerceNET, IAC, AFCEA, AFEI) For those interested in being part of our 2000 press release, submit your approved quote before December 15, 1999. Below is the set of quotes already supplied by our prospective partners in this global effort. IBM: " IBM, will continue to be an influential force in promoting open systems and interoperability, and as such, sees the Interoperability Clearinghouse as one of the more significant initiatives in defining the road map to enterprise computing. Our support of this initiative is further evidence of our commitment to open, standards based IT". SUN MICROSYSTEMS: =93Sun applauds the efforts of the OMG, OTG and DARPA in developing an =91Interoperability Clearinghouse=92 tool. This ambitio= us project will help to evangelize what Sun has been saying for so long. =91Open systems are the best way to protect IT investments.=92 =94 MICROSOFT: =93The Interoperability Clearinghouse initiative promises to be a means for IT professionals to make informed decisions in this complex area. Microsoft welcomes the efforts of the ICH initiative and looks forward to it becoming a useful tool for understanding Interoperability of IT products=94 LOCKHEED MARTIN: =93This initiative complements several on going COTS efforts within Lockheed Martin Corp., and we recognize the potential value that the (Interoperability Clearinghouse) effort will bring to industry=94 OPEN APPLICATIONS GROUP: =93We at the Open Applications Group are interested in this initiative and will incorporate our specifications and testing results into the ICH once built.=94 OBJECT MANAGEMENT GROUP: =93As one of the leading advocates of open systems and interoperability, the OMG believes that the Interoperability Clearinghouse initiative will help users realize the benefits from our combined efforts.=94 For more information, please call 703-768-4975 or email info@e-interop.com. http://www.E-interop.com (Interoperability Clearinghouse link) http://www.gcn.com/vol18_no24/enterprise/313-1.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://206.144.247.65/archives/gcn/1999/February8/1c.htm http://206.144.247.65/archives/gcn/1999/March29/16.htm http://www.healthcare-informatics.com/issues/1999/05_99/standards.htm http://www.omg.org/techprocess/meetings/ic.html john From rem-conf Wed Nov 24 12:59:45 1999 From rem-conf-request@es.net Wed Nov 24 12:59:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qjT3-0005r3-00; Wed, 24 Nov 1999 12:56:45 -0800 Received: from hts.on.ca [206.47.33.2] by mail1.es.net with smtp (Exim 1.81 #2) id 11qjT2-0005ly-00; Wed, 24 Nov 1999 12:56:44 -0800 Received: from mail.tor.mailerwebmachine235.com by hts.on.ca;Wed, 24 Nov 1999 21:03:44 GMT From: To: Date: Fri, 26 Nov 1999 08:03:59 Message-Id: <515.690680.743580@mail.tor.mailerwebmachine235.com> Subject: get your own 5 meg web site for only 11.95 per month. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Why pay over $19.00 a month or more for web space? Call PES CONSOLIDATED ENTERPRISES Today AT 1 888 248 0765. SAVE BIG MONEY ON WEB HOSTING WITH PES CONSOLIDATED ENTERPRISES AND PAY ONLY $11.95 PER MONTH FOR YOUR WEB SITE. OUR SPECIAL PRICE INCLUDES HAVING YOUR OWN DOMAIN WITH 5 megs of web space! WE offer high-speed multiple backbone connections! WITH every domain you get: - 5 meg web site - front page 2000 EXTENSIONS - customized cgi bins & a lot more! All for only $11.95 per month! *set up charges are only $39.95 Simply park your domain with us, upload your data and you are all ready on the web. Stop overpaying for your web site and host with PES CONSOLIDATED ENTERPRISES TODAY! Need A web site designed? Just give us a call TODAY! We will be more than happy to quote you a price on what it will take to get your business on the web today! If you are calling within the United States please call 18882480765. If you reside outside of the United States please call 514 221 2032 for more information. All web sites hosted by us are pre-paid for the year with a 10 day money back guarantee! A $39.95 setup fee applies for each new domain set up with us. to unsubcribe from our list please email listservce988@hyun.purple.co.kr PES CONSOLIDATED ENTERPRISES INC Montreal Quebec 514 221 2032 From rem-conf Wed Nov 24 15:24:44 1999 From rem-conf-request@es.net Wed Nov 24 15:24:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qlii-00007s-00; Wed, 24 Nov 1999 15:21:04 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qlih-000067-00; Wed, 24 Nov 1999 15:21:03 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id PAA07025; Wed, 24 Nov 1999 15:19:25 -0800 (PST) Message-Id: <4.1.19991124103940.01ec4b60@jindo.cisco.com> Message-Id: <4.1.19991124103940.01ec4b60@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 24 Nov 1999 15:19:29 -0800 To: GeeVarghese John , Tmima Koren From: Tmima Koren Subject: Re: Extensions to CRTP Cc: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com In-Reply-To: <383B58AF.2DE7EFBD@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19711203==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_19711203==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote: > > >> >>> >>>> >>>>> >>>>> >>>>> The decompressor will stay in sync as long as he received at least one of >>>>> the CU+ >>>> >>> >>> I think any of the CU+ loss will lead to CONTEXT_STATE packet generation >>> from >>> decompressor to compressor because of the link seq number mismatch ..Is nt >>> it ? >> >> >> >> The decompressor should be in sync after receiving a CU+. There is no reason >> for a CS >> Tmima > > Tmima, > > Could you please explain, how IP id variance should be treated in this case ? > > For IP id field first order difference is sent as delta in CUDP with I bit > set. > In this case, if there is a CU+ packet loss how IP ID delta encoding should > be treated .. Usually the IP id will not increment uniformly in packets of an RTP stream (the host sends packets other then the RTP streams, silence periods). This means that if we want to compress a stream, we might have to send a new deltaID often, maybe in each packet. This will increase the size of the packets. To optimize the compression, the host can assign IP id's to the packets of each stream in a constant increment. This keeps the deltaID constant for each stream. The advantage of a CU+ packet is that in one packet we restore all RTP-related parameters at the decompressor. The sequence of: CU followed by a CR+ is very vulnerable: the CU zeroes the deltaT, so if the CR+ was lost, the decompressor is out of sync. The CU+ does not restore the IP id. But if the implementation keeps the deltaID constant.. After a silence period, the sequence number will still increment by 1 and the IP id by deltaID: there is no reason to skip RTP sequence numbers or IP id's. deltaT is the only difference that is not correct for the first packet after a silence period. To optimize CRTP over lossy links 1. Use a constant deltaID 2. Check udp checksum 3. Use CU+ as necessary > > and also I am not still convinced with the advantage of CU+ over CR+ after > the silence period. Could you please explain your point ..(please ref my > previous mail) Let's say that the characteristics of the link is that we may lose at most 1 packet in a row If we use: 11 200 CR+ dt=100 12 210 CR+ dt=10 13 220 CR If 11 is lost, the decompressor does not have the correct RTP timestamp for packet 12. If 12 is lost, the decompressor has a wrong deltaT. In both cases the decompressor is out of sync. This is a very weak sequence to use after a silence period. If instead we use: 11" 200 CU+ dt=10 12" 210 CU+ dt=10 13" 220 CR In this case If one of 11" or 12" is lost, the decompressor remains in sync. So this is a very strong sequence Tmima > > Please reply . > > Rgds > > GVJ --=====================_19711203==_.ALT Content-Type: text/html; charset="us-ascii" At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote:

 
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?


The decompressor should be in sync after receiving a CU+. There is no reason for a CS
Tmima
Tmima,

Could you please explain, how IP id variance should be treated in this case ?
For IP id field  first order difference is sent as delta in CUDP with I bit set.
In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated ..

Usually the IP id will not increment uniformly in packets of an RTP stream (the host sends packets other then the RTP streams, silence periods).
This means that if we want to compress a stream, we might have to send a new deltaID often, maybe in each packet. This will increase the size of the packets.
To optimize the compression, the host can assign IP id's to the packets of each stream in a constant increment.
This keeps the deltaID constant for each stream.

The advantage of a CU+ packet is that in one packet we restore all RTP-related parameters at the decompressor.
The sequence of:  CU followed by a CR+  is very vulnerable: the CU zeroes the deltaT, so if the CR+ was lost, the decompressor is out of sync.
The CU+ does not restore the IP id. But if the implementation keeps the deltaID constant..

After a silence period, the sequence number will still increment by 1 and the IP id by deltaID: there is no reason to skip RTP sequence numbers or IP id's. deltaT is the only difference that is not correct for the first packet after a silence period.

To optimize CRTP over lossy links
1. Use a constant deltaID
2. Check udp checksum
3. Use CU+ as necessary


and also I am not still convinced with the advantage of CU+ over CR+ after
the  silence period. Could you please explain your point  ..(please ref my previous mail)

Let's say that the characteristics of the link is that we may lose at most 1 packet in a row
If we use:

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR

If 11 is lost, the decompressor does not have the correct RTP timestamp for packet 12.
If 12 is lost, the decompressor has a wrong deltaT.
In both cases the decompressor is out of sync.
This is a very weak sequence to use after a silence period.

If instead we use:

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR

In this case If one of 11" or 12" is lost, the decompressor remains in sync. So this is a very strong sequence

Tmima


Please reply .

Rgds

GVJ

--=====================_19711203==_.ALT-- From rem-conf Wed Nov 24 16:05:13 1999 From rem-conf-request@es.net Wed Nov 24 16:05:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qmN4-00015l-00; Wed, 24 Nov 1999 16:02:46 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qmN2-00015T-00; Wed, 24 Nov 1999 16:02:44 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id QAA08443; Wed, 24 Nov 1999 16:01:07 -0800 (PST) Message-Id: <4.1.19991124152142.00af0e00@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 24 Nov 1999 16:01:49 -0800 To: "Lars-Erik Jonsson" , "GeeVarghese John" , "Tmima Koren" , , , , , , , From: Tmima Koren Subject: Re: T-bit extension for CRTP In-Reply-To: <022101bf359c$6a476f60$2bb08496@e00008639f5da.epl.ericsson. se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:20 AM 11/23/99 +0100, Lars-Erik Jonsson wrote: >I have a number of comments both to what is said in the draft >(draft-koren-crtp-enhance-00.txt) and to the previous discussions about it. >All are included below: > > >- Draft: The purpose > >Tmima: In the draft you state that you need this to be able to do periodic >refreshing of the context when CRTP is used over links with large RTT. >However, in the previous discussion you are only talking about what happens >after silence periods. I think you should clarify what you are really= aiming >for, maybe the draft should also talk about the implications after silence >periods. Thanks, I'll clarify this point. The idea is that once the deltas are set at the decompressor and you are= sending CR packets, if you lose packets you can recover using 'twice'. But if you try to change a delta by sending a CR+ or CU, and if this packet= is lost, the decompressor cannot recover using 'twice'. A silence period is just an example of a time when you need to change the= deltaT.=20 > > >- Draft: Packet types for refreshing > >In the draft it is stated that there are TWO packet types that can be used >to periodically refresh the context of an IPv4 CRTP decompressor, >FULL_HEADER and COMPRESSED_UDP packets. This is not really correct. For >IPv4, the COMPRESSED_UDP packet does NOT refresh the context completely, >because the IP-ID is communicated as a delta. The COMPRESSED_NON_TCP packet >type should instead be used with IPv4. For IPv6, the two packet >types(C_NON_TCP and C_UDP) carries the same information and are identical= in >size. You are right - I'll correct this A FH does not refresh the context: it starts a new context And a CU+ restores all RTP-related parameters at the decompressor. The IP id= is not restored. I checked the COMPRESSED_NON_TCP packet and I can't use it to fully refresh= the state at the decompressor: it will set the deltaT to zero. I think I'll propose an additional change to the CU packet: In a CU packet the M and S bits are always 0. I propose that if the M bit is set instead of the I bit, then the packet= carries the full IP id and not only the delta IP id. Tmima > > >- Discussion: GeeVarghese Q1 > >>Q1) My doubt is If the entire original RTP header is the in the CUDP= packet >why to >>send the delta also with the original header .. >>why can't the decompressor findout the new delta to be used >>from the RTP header in the CUDP packet itself, Is it not redundancy ? > >The decompressor can NOT find out the delta for sure, because its context >could have been invalid when the C_UDP was received. So, if the intention= is >to have the delta "correctly" set (not reset to 0) after a C_UDP, then you >must include it. The question is whether this is advantageous compared to >the current solution, sending the delta in subsequent C_RTP. > > >- Discussion: GeeVarghese about multiple packets > >>Why do we need to send multiple packet and how it will increase the >probability even >>if you send more CUDP packets, as long as the decomperssor look at the seq >number >>and detect packet loss it should send a CONTEXT_STATE packet. > >Yes, but if the RTT is large, the update procedure would take a long time. >If Twice is used (requires UDP checksum and should be used carefully), loss >of packets that DO NOT change the decompressor context could be handled >without discarding additional packets. On the other hand, if packets that= DO >change the context are lost, Twice would fail and subsequent packets must= be >discarded while waiting for a refresh. If context update information was >repeated in more then one packet, a higher tolerance against packet loss >could be achieved. > > >- Discussion: The example > >>Some notations: >>dt deltaT >>FH FULL_HEADER >>CR COMPRESSED_RTP >>CR+ COMPRESSED_RTP with deltaT (dt) >>CU COMPRESSED_UDP >>CU+ COMPRESSED_UDP with dt >>CS CONTEXT_STATE > >>I'll use an example >>The sender sends a sample every 10 ms >>Using CRTP, the sequence of packets will be: > >>seq# Time pkt type >>1 10 FH >>2 20 CR+ dt=3D10 >>3 30 CR >>... >>10 100 CR > >>At this point this side stops talking. Talking resumes at time 200 > >>11 200 CR+ dt=3D100 >>12 210 CR+ dt=3D10 >>13 220 CR >>.... > >>With the extension of T-bit in CU, we can send: > >>11' 200 CU+ dt=3D10 >>12' 210 CR >>... > >When I look at the two different solutions 11+12 and 11'+12' I can not >really see the big advantage of 11'+12'. First of all, the latter requires >more overhead. While 11 would have a 3 octet header, the 11' header would= be >at least 15 octets large. The idea is certainly to have the context >completely refreshed, but that could not be achieved with CU+ because it >does not include the IP ID in absolute terms. IF you want to refresh the >context with a CU packet as packet #11, you could also still use the old CU >and send the dt-value in the next compressed packet, it would require one >octet less in the CU and one more in the CR(+). Also the dt information >could be repeated in more than one CR-packet for use with "sophisticated >Twice". > > >- Discussion: GeeVarghese about FH > >>I think this is not correct, If the decompressor receives 12" insted of >11", >>he is not in sync because of link seq number mismatch and >>will send a CONTEXT_STATE packet. >>This will lead to FH sending from compressor to decompressor .. > >Not necessarily a FULL_HEADER, a COMPRESSED_NON_TCP would be a better >choice. > > >- Discussion: GeeVarghese and Koren about CONTEXT_UPDATE > >>>I think any of the CU+ loss will lead to CONTEXT_STATE packet generation >from >>>decompressor to compressor because of the link seq number mismatch ..Is= nt >it ? > >>The decompressor should be in sync after receiving a CU+. There is no >reason for a CS > >As the CRTP RFC says: "Note, however, that there is a nontrivial risk of an >incorrect positive indication. It may be advisable to request a FULL_HEADER >or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds." The >UDP checksum is rather weak, so especially if you use more complex "twice" >solutions, the advice above should be followed, meaning that a= CONTEXT_STATE >packet should be sent. > > >Regards!! >/Lars-Erik > >-------------------------------------------------------------- >Lars-Erik Jonsson, M.Sc. >Voice Processing and Radio Network Research >Ericsson Erisoft AB >Box 920, S-971 28 Lule=E5, Sweden >E-mail: lars-erik.jonsson@ericsson.com >Phone: +46 920 20 21 07 >Mobile: +46 70 365 20 58 >Fax: +46 920 20 20 99 >Home: +46 920 999 57 > > > > From rem-conf Wed Nov 24 20:49:39 1999 From rem-conf-request@es.net Wed Nov 24 20:49:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qqey-0003mv-00; Wed, 24 Nov 1999 20:37:32 -0800 Received: from hd2.vsnl.net.in (hd2.dot.net.in) [202.54.30.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qqet-0003ml-00; Wed, 24 Nov 1999 20:37:30 -0800 Received: from hyd.chiplogic.com ([203.197.20.100]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id KAA09318 for ; Thu, 25 Nov 1999 10:07:18 +0530 (IST) Received: from chiplogic.com ([192.168.2.56]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id KAA01153 for ; Thu, 25 Nov 1999 10:04:41 +0530 Message-ID: <383CBEFC.F83A472B@chiplogic.com> Date: Thu, 25 Nov 1999 10:15:48 +0530 From: Rafiq Shaikh X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "rem-conf@es.net" Subject: [Fwd: RTP measuring] Content-Type: multipart/mixed; boundary="------------1F1353D56A8EBAC6C2EF1076" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------1F1353D56A8EBAC6C2EF1076 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think these questions can be better answered on this list. Regards, -Rafiq. --------------1F1353D56A8EBAC6C2EF1076 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from localhost (localhost [127.0.0.1]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id UAA31192 for ; Wed, 24 Nov 1999 20:58:28 +0530 Received: from cougar.chiplogic.com by fetchmail-4.5.8 POP3 for (single-drop); Wed, 24 Nov 1999 20:58:29 IST Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA26878; Wed, 24 Nov 1999 07:01:11 -0800 (PST) Received: by lists.research.bell-labs.com (Postfix) id 8AE8052BB; Wed, 24 Nov 1999 09:59:33 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0F33952D5; Wed, 24 Nov 1999 09:59:32 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <00a701bf36a1$8f4d36e0$6531a38d@see.plym.ac.uk> From: "Bogdan Ghita" To: Subject: RTP measuring Date: Wed, 24 Nov 1999 17:30:09 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01BF36A1.8E774940" 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 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01BF36A1.8E774940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I have three questions related to RTP/RTCP. 1. Are there any tools for monitoring RTP/RTCP (free or commercial)? I = am interested especially in RTP analysis, and not RTCP parsing. And, if = there are, which are their capabilities? In order to restrict the range of replies, I must mention that I've = already found: - Hammer VoIP Test System - analysing all the parameters (drop packets, = jitter, delay) within a VoIP call - HP Internet Advisor - similar (for these two commercial packages, I couldn't get more information = about what actually is monitored) - rtpmon, which is free, but, in spite of its name, it is an RTCP = monitor. 2. Can anybody explain me what is the structure of a compound RTCP = packet? I know, from the RTP specification, that it looks like this: if encrypted: random 32-bit integer | |[------- packet -------][----------- packet -----------][-packet-] | | receiver reports chunk chunk V item item item item -------------------------------------------------------------------- |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why] |R[ |# report # 1 # 2 ][ |# |# ][ ## ] |R[ |# # # ][ |# |# ][ ## ] |R[ |# # # ][ |# |# ][ ## ] -------------------------------------------------------------------- |<------------------ UDP packet (compound packet) --------------->| #: SSRC/CSRC The question is, as I couldn't understand the figure: how is the above = figure packetised in UDP packets (is it 'line-by-line') ?=20 3. Are there any standards for encrypting RTP/RTCP (in relation with = H.323) ? Besides inserting the 32-bit integer in the RTCP packet and = using DES there is nothing else specified. Thank you very much Best regards Bogdan Ghita ------=_NextPart_000_00A4_01BF36A1.8E774940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,

I = have three=20 questions related to RTP/RTCP.
1. Are there any  tools for = monitoring=20 RTP/RTCP (free or commercial)? I am interested especially in RTP = analysis, and=20 not RTCP parsing. And, if there are, which are their capabilities?
In = order=20 to restrict the range of replies, I must mention that I've already = found:
-=20 Hammer VoIP Test System - analysing all the parameters (drop packets, = jitter,=20 delay) within a VoIP call
- HP Internet Advisor - similar
(for = these two=20 commercial packages, I couldn't get more information about what actually = is=20 monitored)
- rtpmon, which is free, but, in spite of its name, it is = an RTCP=20 monitor.

2. Can anybody explain me what is the structure of a = compound=20 RTCP packet? I know, from the RTP specification, that it looks like=20 this:


if encrypted: random 32-bit integer
|
|[------- = packet=20 -------][----------- packet -----------][-packet-]
|
| receiver = reports=20 chunk chunk
V item item item=20 item
-----------------------------------------------------------------= ---
|R[SR|#=20 sender #site#site][SDES|# CNAME PHONE |#CNAME = LOC][BYE##why]
|R[  |#=20 report #  1 #  2 ][   =20 |#            = ;=20 |#         ][   = ##  =20 ]
|R[  |#        = #   =20 #    ][   =20 |#            = ;=20 |#         ][   = ##  =20 ]
|R[  |#        = #   =20 #    ][   =20 |#            = ;=20 |#         ][   = ##  =20 ]
--------------------------------------------------------------------=
|<------------------=20 UDP packet (compound packet) --------------->|
#: = SSRC/CSRC

The=20 question is, as I couldn't understand the figure: how is the above = figure=20 packetised in UDP packets (is it 'line-by-line') ?
 
3. Are there any standards for = encrypting=20 RTP/RTCP (in relation with H.323) ? Besides inserting the 32-bit integer = in the=20 RTCP packet and using DES there is nothing else specified.


Thank you very = much
Best regards
Bogdan Ghita
 
------=_NextPart_000_00A4_01BF36A1.8E774940-- --------- This message came from the IETF IPTEL Working Group Mailing List. --------------1F1353D56A8EBAC6C2EF1076-- From rem-conf Thu Nov 25 00:07:47 1999 From rem-conf-request@es.net Thu Nov 25 00:07:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qtrd-0006qK-00; Thu, 25 Nov 1999 00:02:49 -0800 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qtrb-0006qA-00; Thu, 25 Nov 1999 00:02:47 -0800 Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA15441; Thu, 25 Nov 1999 09:02:42 +0100 (MET) Received: by lms001.lu.erisoft.se id JAA20143; Thu, 25 Nov 1999 09:02:37 +0100 (MET) Message-ID: <016a01bf371b$3d9ff100$2bb08496@e00008639f5da.epl.ericsson.se> From: "Lars-Erik Jonsson" To: "GeeVarghese John" , "Tmima Koren" Cc: , , , , , , , Subject: Re: Extensions to CRTP Date: Thu, 25 Nov 1999 09:01:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id JAA15441 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> =3D GVJ > =3D Tmima >>Could you please explain, how IP id variance should be treated in this case ? >>For IP id field first order difference is sent as delta in CUDP with I bit set. >>In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated .. >Usually the IP id will not increment uniformly in packets of an RTP stre= am (the host sends packets other >then the RTP streams, silence periods). >This means that if we want to compress a stream, we might have to send a new deltaID often, maybe in each >packet. This will increase the size of = the packets. >To optimize the compression, the host can assign IP id's to the packets = of each stream in a constant >increment. >This keeps the deltaID constant for each stream. >The advantage of a CU+ packet is that in one packet we restore all RTP-related parameters at the >decompressor. >The sequence of: CU followed by a CR+ is very vulnerable: the CU zeroe= s the deltaT, so if the CR+ was lost, >the decompressor is out of sync. >The CU+ does not restore the IP id. But if the implementation keeps the deltaID constant.. Yes, IF the deltaID was constant. But you can never expect it to be.....s= o the compression should handle non-constant deltaID's also (without too mu= ch overhead). >After a silence period, the sequence number will still increment by 1 an= d the IP id by deltaID: there is no >reason to skip RTP sequence numbers or= IP id's. deltaT is the only difference that is not correct for the first >packet after a silence period. Yes, and therefore the additional overhead introduced by sending CU (or C= U+) packets seems to me indefensible. What you relly want is to send somethin= g more than just ONE packet with a different deltaT and avoid the situation below: ... ... N+1: deltaT=3D10 N+2: deltaT=3D100 N+3: deltaT=3D10 N+4: deltaT=3D10 ... ... Because a loss of packet N+2 would NOT be recoverable with Twice. That is the point? Right?? I think (even if I do not trust Twice to be reliable, both due to the weak UDP checksum and to the fact that the checksum will = not always be present) it would be nice to have a better way to do this, but = I think it could be done cheaper than by sending full RTP header++...=3D) >To optimize CRTP over lossy links >1. Use a constant deltaID Do not expect it to be constant. To do so, you either need to change the IP-stacks OR you must violate the end-to-end integrity of the packets and reassign the ID "somewhere" in the path.....=3D( >2. Check udp checksum The Twice idea makes some sence, BUT you should not expect the checksum t= o be enabled. It is up to the application to decide whether to use it (and = you can not expect the application to know that it is needed for header compression purposes). >3. Use CU+ as necessary Even if I am a little bit sceptical to some of your arguments, I still th= ink it is a good idea to improve the CU packet type and make it more flexible= , especially since there are "unused" bits in it. Cheers!! /Lars-Erik -------------------------------------------------------------- Lars-Erik Jonsson, M.Sc. Voice Processing and Radio Network Research Ericsson Erisoft AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Mobile: +46 70 365 20 58 Fax: +46 920 20 20 99 Home: +46 920 999 57 From rem-conf Thu Nov 25 02:42:53 1999 From rem-conf-request@es.net Thu Nov 25 02:42:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qwIl-0000yR-00; Thu, 25 Nov 1999 02:38:59 -0800 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qwIj-0000yG-00; Thu, 25 Nov 1999 02:38:58 -0800 Received: from tua.cdt.luth.se (tua.cdt.luth.se [130.240.64.43]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id LAA06770; Thu, 25 Nov 1999 11:35:10 +0100 (MET) Message-Id: <3.0.6.32.19991125113536.009e5c50@basil.cdt.luth.se> X-Sender: micke@basil.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 25 Nov 1999 11:35:36 +0100 To: "Lars-Erik Jonsson" From: Mikael Degermark Subject: Re: Extensions to CRTP Cc: "GeeVarghese John" , "Tmima Koren" , , , , , , , , In-Reply-To: <016a01bf371b$3d9ff100$2bb08496@e00008639f5da.epl.ericsson. se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I also think it is a good idea to make CRTP more robust. We cannot, however, expect that it can be made good enough for the more severe cases (e.g., cellular) unless rather radical=20 modifications are done. The place to ponder such modifications is the robhc WG, which will be announced shortly.=20 Micke Degermark At 09:01 1999-11-25 +0100, Lars-Erik Jonsson wrote: >>> =3D GVJ >> =3D Tmima > >>>Could you please explain, how IP id variance should be treated in this >case ? >>>For IP id field first order difference is sent as delta in CUDP with I >bit set. >>>In this case, if there is a CU+ packet loss how IP ID delta encoding >should be treated .. > > >>Usually the IP id will not increment uniformly in packets of an RTP stream >(the host sends packets other >then the RTP streams, silence periods). >>This means that if we want to compress a stream, we might have to send a >new deltaID often, maybe in each >packet. This will increase the size of= the >packets. >>To optimize the compression, the host can assign IP id's to the packets of >each stream in a constant >increment. >>This keeps the deltaID constant for each stream. > > >>The advantage of a CU+ packet is that in one packet we restore all >RTP-related parameters at the >decompressor. >>The sequence of: CU followed by a CR+ is very vulnerable: the CU zeroes >the deltaT, so if the CR+ was lost, >the decompressor is out of sync. >>The CU+ does not restore the IP id. But if the implementation keeps the >deltaID constant.. > > >Yes, IF the deltaID was constant. But you can never expect it to be.....so >the compression should handle non-constant deltaID's also (without too much >overhead). > >>After a silence period, the sequence number will still increment by 1 and >the IP id by deltaID: there is no >reason to skip RTP sequence numbers or= IP >id's. deltaT is the only difference that is not correct for the first >>packet after a silence period. > > >Yes, and therefore the additional overhead introduced by sending CU (or= CU+) >packets seems to me indefensible. What you relly want is to send something >more than just ONE packet with a different deltaT and avoid the situation >below: >... >... >N+1: deltaT=3D10 >N+2: deltaT=3D100 >N+3: deltaT=3D10 >N+4: deltaT=3D10 >... >... >Because a loss of packet N+2 would NOT be recoverable with Twice. That is >the point? Right?? I think (even if I do not trust Twice to be reliable, >both due to the weak UDP checksum and to the fact that the checksum will= not >always be present) it would be nice to have a better way to do this, but I >think it could be done cheaper than by sending full RTP header++...=3D) > >>To optimize CRTP over lossy links >>1. Use a constant deltaID > >Do not expect it to be constant. To do so, you either need to change the >IP-stacks OR you must violate the end-to-end integrity of the packets and >reassign the ID "somewhere" in the path.....=3D( > >>2. Check udp checksum > >The Twice idea makes some sence, BUT you should not expect the checksum to >be enabled. It is up to the application to decide whether to use it (and= you >can not expect the application to know that it is needed for header >compression purposes). > >>3. Use CU+ as necessary > > >Even if I am a little bit sceptical to some of your arguments, I still= think >it is a good idea to improve the CU packet type and make it more flexible, >especially since there are "unused" bits in it. > > > >Cheers!! >/Lars-Erik > > >-------------------------------------------------------------- >Lars-Erik Jonsson, M.Sc. >Voice Processing and Radio Network Research >Ericsson Erisoft AB >Box 920, S-971 28 Lule=E5, Sweden >E-mail: lars-erik.jonsson@ericsson.com >Phone: +46 920 20 21 07 >Mobile: +46 70 365 20 58 >Fax: +46 920 20 20 99 >Home: +46 920 999 57 > > > > > From rem-conf Thu Nov 25 05:11:14 1999 From rem-conf-request@es.net Thu Nov 25 05:11:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11qyUK-0002XL-00; Thu, 25 Nov 1999 04:59:04 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 11qyUI-0002XB-00; Thu, 25 Nov 1999 04:59:03 -0800 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id FAA16663; Thu, 25 Nov 1999 05:57:54 -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 FAA15528; Thu, 25 Nov 1999 05:57:45 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id SAA17064; Thu, 25 Nov 1999 18:31:27 +0530 (IST) Message-ID: <383DC57E.9D1FAA52@miel.mot.com> Date: Thu, 25 Nov 1999 18:25:50 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> Content-Type: multipart/alternative; boundary="------------3314A3E2131FFCA19337BE73" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------3314A3E2131FFCA19337BE73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima, Thanks for the reply and I have added some more comments on the CU+ packets in this mail. I read the first mail from "Lars-Erik Jonsson", and your reply to that, Good you are changing the CU+ with IP ID but you may not need to set M bit there, by settting deltaT bit you can encode both deltaT and IP ID, because you need both values... I have added whatever comments I have about CU+, please read that below According to me CU+ with IP ID also will not give a robust solution. Reason stated below. I think we should windup our discussion on CU + with this mail unless someone else is interested. If you want to reply to me please ..If you want more clarrification on my point I will reply back. My next mail will address few things about ACCEPT/REJECT packet use, you & team proposed. Please reply to that mail. My comments on CU+ are : Point 1.1: IP ID can be assigned by an host in three ways a) sequence number in ascending order with variace 1 b) random number c) sequence number with variance n (n >1) I am not aware of any other implementation ..(May be possible) IF the IP id variance is not in the ascending order, CU+ will have problem. You expect that, host will implement this while transmitting the RTP packets. I dont know how many (non compliant) people will change this for the new proposal came in "extending CRTP". Or you are agreed for IP ID in CU+, it is a positive move. Point # 1.2 Infact looking at the sequence number of CUDP packets helps to get rid of IP id sync problem which we discussed . (What I meant is if CUDP came in with a non expected link seqnumber, decompressor send out a CS packet to compressor to synchronise the context) This will take care all issues with the IP id variance (variance in any manner random, ascending order). If we extend CRTP with the new extension you proposed, we may loose this synchronization chance between compressor and decompressor, because we are NOT expected to look at CUDP+ (or CU+) link sequence number to synchronize anymore as far as IP ID variance is concerned. Otherwise CU+ packet should always carry IP ID field then we can avoid looking at sequnce number but not in the case with CU packet. What is your comment about CUDP with extension co-exist? Should it look for link seq number match further also ? Point #2 One solution to IP ID prolem you stated as "Twics Algo" Solution to this problem could be using twice algorithm. But "twice" algorithm is not mandatory. There are implementations without preserving UDP checksum. In this case I dont have an answer. May be we have to force a standard that everyone should implement UDP checksum while transmitting out. I dont know how many people will do that. Point #3.1 In our discussion we have addressed two kinds of packet loss 1) RTP packet loss in the network before reaching compessor (Say L1) 2) Compressed packet loss sent from compressor to decompressor (Say L2) In a lossy environment (L1), we end up in sending more number of encoded bytes with CU+ than what we used to send with CR+. Because in CU+ we encode deltaT of the next expected RTP packet, with the current packet. I can understand your point that source generate with same periodic time gap for each packet within a talkburst. But the carrier network is IP datagram service and (+ link lossy nature). So should we rely on the possible network behaviour or should we, on the source behaviour. If L2 is greater than L1 then you claimed advantage of CU+ sync between compressor and decompressor can be achieved. But What is the likely chance for L2 > L1 ? Only for some specific lossy links. Point # 3.2 As far as I know CRTP use some heuristic mechanism to identify a RTP flow. It is not a definite mechanism. In this case does it make sense to send the deltaT of the next expected packet. Consider L1 case mentioned above. Not only that, assume the time gap between talkburst is (T1) and time gap between inter packet arrival of same session is T2. Consider a case of, If we have identified a non-RTP flow as RTP flow and started compression with our heuristics how do we determine when to send CU+. Will we end up in sending continuous CU+ ? we may .. There need not be talkburst gap with some what high definite gap when compare to interpacket gap of the same session... (See Pt # 4 on CU+ size comparison with CR+) Point #4 Size of the CU+ is more than CR+ because of the compressed RTP header .. in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts). In old CRTP, Assume that for some situation we have to encode RTP seq number and Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq number + 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes). Over a lossy link (L2), which is particular to the link, advantage of CU+ is missing. Continuous sending of CU+ for a talk burst may avoid send CS from decompressor to compressor. But What kind of loss is more likey L1 or L2. My personal comment to CU+ is May be we can claim some advantage only if the stated assumptions (about packet loss (L1 < L2), twice algo..etc) are met .. That also with the modification of IP ID inside the CU+ packet. Thanks & Rgds GVJ Tmima Koren wrote: > At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote: > >> >> >> >> >> >> >> >> The decompressor will stay in sync as long as he received at >> >> >> least one of the CU+ >> >> > >> >> I think any of the CU+ loss will lead to CONTEXT_STATE packet >> >> generation from >> >> decompressor to compressor because of the link seq number >> >> mismatch ..Is nt it ? >> > >> > The decompressor should be in sync after receiving a CU+. There is >> > no reason for a CS >> > Tmima >> >> Tmima, >> >> Could you please explain, how IP id variance should be treated in >> this case ? >> For IP id field first order difference is sent as delta in CUDP >> with I bit set. >> In this case, if there is a CU+ packet loss how IP ID delta encoding >> should be treated .. > > > Usually the IP id will not increment uniformly in packets of an RTP > stream (the host sends packets other then the RTP streams, silence > periods). > This means that if we want to compress a stream, we might have to send > a new deltaID often, maybe in each packet. This will increase the size > of the packets. > To optimize the compression, the host can assign IP id's to the > packets of each stream in a constant increment. > This keeps the deltaID constant for each stream. > > The advantage of a CU+ packet is that in one packet we restore all > RTP-related parameters at the decompressor. > The sequence of: CU followed by a CR+ is very vulnerable: the CU > zeroes the deltaT, so if the CR+ was lost, the decompressor is out of > sync. > The CU+ does not restore the IP id. But if the implementation keeps > the deltaID constant.. > > After a silence period, the sequence number will still increment by 1 > and the IP id by deltaID: there is no reason to skip RTP sequence > numbers or IP id's. deltaT is the only difference that is not correct > for the first packet after a silence period. > > To optimize CRTP over lossy links > 1. Use a constant deltaID > 2. Check udp checksum > 3. Use CU+ as necessary > > > >> and also I am not still convinced with the advantage of CU+ over CR+ >> after >> the silence period. Could you please explain your point ..(please >> ref my previous mail) > > > Let's say that the characteristics of the link is that we may lose at > most 1 packet in a row > If we use: > > 11 200 CR+ dt=100 > 12 210 CR+ dt=10 > 13 220 CR > > If 11 is lost, the decompressor does not have the correct RTP > timestamp for packet 12. > If 12 is lost, the decompressor has a wrong deltaT. > In both cases the decompressor is out of sync. > This is a very weak sequence to use after a silence period. > > If instead we use: > > 11" 200 CU+ dt=10 > 12" 210 CU+ dt=10 > 13" 220 CR > > In this case If one of 11" or 12" is lost, the decompressor remains in > sync. So this is a very strong sequence > > Tmima > > > >> Please reply . >> >> Rgds >> >> GVJ > - --------------3314A3E2131FFCA19337BE73 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima,

Thanks for the reply and I have added some more comments on the CU+ packets in this
mail. I read the first mail from "Lars-Erik Jonsson", and your reply to that, Good
you are changing the CU+ with IP ID but you may not need to set M bit there,
by settting deltaT bit you can encode both deltaT and IP ID, because you need both values...
I have added whatever comments I have about CU+,  please read that below
According to me CU+ with IP ID also will not give a robust solution.
Reason stated below.

I think we should windup our discussion on CU + with this mail unless someone else is
interested. If you want to reply to me please ..If you want more clarrification on my point
I will reply back.

My next mail will address few things about ACCEPT/REJECT
packet use, you & team proposed. Please reply to that mail.

My comments on CU+ are :

Point 1.1:

IP ID can be assigned by an host in three ways
a) sequence number in ascending order with variace 1
b) random number
c) sequence number with variance n (n >1)

I am not aware of any other implementation ..(May be possible)
IF the IP id variance is not in the ascending order,
CU+ will have problem. You expect that, host will implement this
while transmitting the RTP packets. I dont know how many (non compliant) people
will change this for the new proposal came in "extending CRTP".
Or you are agreed for IP ID in CU+, it is a positive move.

Point # 1.2

Infact looking at the sequence number of CUDP packets helps to  get rid of
IP id sync problem which we discussed .  (What I meant is if CUDP came in with a
non expected link seqnumber, decompressor send out a CS packet to
compressor to synchronise the context)
This will take care all issues with the IP id variance (variance in any manner random, ascending order).
If we extend CRTP with the new extension you proposed,
we may loose this synchronization chance between compressor and decompressor,
because we are NOT expected to look at CUDP+ (or CU+) link sequence number
to synchronize anymore as far as IP ID variance is concerned.
Otherwise CU+ packet should always carry IP ID field then we can avoid
looking at sequnce number but not in the case with CU packet.

What is your comment about CUDP with extension co-exist?
Should it look for link seq number match further also  ?

Point #2

One solution to IP ID prolem you stated as "Twics Algo"
Solution to this problem could be using twice algorithm.
But "twice" algorithm is not mandatory. There are implementations
without preserving UDP checksum. In this case I dont have an answer.
May be we have to force a standard that everyone should implement
UDP checksum while transmitting out. I dont know how many people will do that.

Point #3.1

In our discussion we have addressed two kinds of packet loss

1)  RTP packet loss in the network before reaching compessor (Say L1)
2) Compressed packet loss sent from compressor to decompressor (Say L2)
 

In a lossy environment (L1), we end up in sending more number of encoded bytes
with CU+ than what we used to send with CR+.
Because in CU+ we encode deltaT of the next expected RTP packet, with the current packet.
I can understand your point that source generate with same periodic time gap for
each packet within a talkburst. But the carrier network is IP datagram service and
(+ link lossy nature). So should we rely on the possible network behaviour or should we, on the source behaviour.

If L2 is greater than L1 then you claimed advantage of CU+ sync between compressor
and decompressor can be achieved.

But What is the likely chance for L2 >  L1 ?
Only for some specific lossy links.

Point # 3.2

As far as I know CRTP use some heuristic mechanism to identify a RTP flow.
It is not a definite mechanism. In this case  does it make sense to
send the deltaT of the next expected packet. Consider L1 case mentioned above.
Not only that, assume the time gap between talkburst is (T1) and time gap between
inter packet arrival of same session is T2. Consider a case of,
If we have identified a non-RTP flow as RTP flow and started compression
with our heuristics how do we determine when to send CU+.
Will we end up in sending continuous CU+ ?  we may ..
There need not be talkburst gap with some what high definite gap
when  compare to interpacket gap of the same session...
(See Pt # 4 on CU+ size comparison with CR+)
 

Point #4

Size of the CU+ is more than CR+ because of the compressed RTP header ..
in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts).
In old CRTP, Assume that for some situation we have to encode RTP seq number and
Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq number
+ 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes).
Over a lossy link (L2), which is particular to the link, advantage of CU+ is missing.

Continuous sending of CU+ for a talk burst may avoid send CS from decompressor to
compressor. But What kind of loss is more likey L1 or L2.
 

My personal comment to CU+ is

May be we can claim some advantage only if
the stated assumptions (about packet loss (L1 < L2),  twice algo..etc) are met ..
That also with the modification of IP ID inside the CU+  packet.

Thanks & Rgds

GVJ

Tmima Koren wrote:

 At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote:
 
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?

The decompressor should be in sync after receiving a CU+. There is no reason for a CS
Tmima

Tmima,

Could you please explain, how IP id variance should be treated in this case ?
For IP id field  first order difference is sent as delta in CUDP with I bit set.
In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated ..


Usually the IP id will not increment uniformly in packets of an RTP stream (the host sends packets other then the RTP streams, silence periods).
This means that if we want to compress a stream, we might have to send a new deltaID often, maybe in each packet. This will increase the size of the packets.
To optimize the compression, the host can assign IP id's to the packets of each stream in a constant increment.
This keeps the deltaID constant for each stream.

The advantage of a CU+ packet is that in one packet we restore all RTP-related parameters at the decompressor.
The sequence of:  CU followed by a CR+  is very vulnerable: the CU zeroes the deltaT, so if the CR+ was lost, the decompressor is out of sync.
The CU+ does not restore the IP id. But if the implementation keeps the deltaID constant..

After a silence period, the sequence number will still increment by 1 and the IP id by deltaID: there is no reason to skip RTP sequence numbers or IP id's. deltaT is the only difference that is not correct for the first packet after a silence period.

To optimize CRTP over lossy links
1. Use a constant deltaID
2. Check udp checksum
3. Use CU+ as necessary
 
 

and also I am not still convinced with the advantage of CU+ over CR+ after
the  silence period. Could you please explain your point  ..(please ref my previous mail)


Let's say that the characteristics of the link is that we may lose at most 1 packet in a row
If we use:

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR

If 11 is lost, the decompressor does not have the correct RTP timestamp for packet 12.
If 12 is lost, the decompressor has a wrong deltaT.
In both cases the decompressor is out of sync.
This is a very weak sequence to use after a silence period.

If instead we use:

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR

In this case If one of 11" or 12" is lost, the decompressor remains in sync. So this is a very strong sequence

Tmima
 
 

Please reply .

Rgds

GVJ

- --------------3314A3E2131FFCA19337BE73-- From rem-conf Thu Nov 25 09:34:46 1999 From rem-conf-request@es.net Thu Nov 25 09:34:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11r2ji-0004zx-00; Thu, 25 Nov 1999 09:31:14 -0800 Received: from s2.smtp.oleane.net [195.25.12.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 11r2jh-0004zn-00; Thu, 25 Nov 1999 09:31:13 -0800 Received: from Dell (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by s2.smtp.oleane.net with SMTP id SAA00228; Thu, 25 Nov 1999 18:30:55 +0100 (CET) Message-ID: <000a01bf376a$a4898440$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: VoDSL 2000 conference CFP Date: Thu, 25 Nov 1999 18:29:33 +0100 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BF3773.04CD66C0" 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_0007_01BF3773.04CD66C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The VoDSL 2000 conference CFP will soon be completed. We are happy to = register the leaders of this new technology next March in Paris. Don't = hesitate to propose a paper. Service providers are especially invited to = speak. =20 http://www.upperside.fr/bavodsl.htm ------=_NextPart_000_0007_01BF3773.04CD66C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0007_01BF3773.04CD66C0-- From rem-conf Thu Nov 25 09:53:51 1999 From rem-conf-request@es.net Thu Nov 25 09:53:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11r34y-0005p3-00; Thu, 25 Nov 1999 09:53:12 -0800 Received: from hts.on.ca [206.47.33.2] by mail1.es.net with smtp (Exim 1.81 #2) id 11r34w-0005hc-00; Thu, 25 Nov 1999 09:53:10 -0800 Received: from mail.tor.mailerwebmae235.com by hts.on.ca;Thu, 25 Nov 1999 18:00:03 GMT From: To: Date: Sat, 27 Nov 1999 05:00:50 Message-Id: <347.644909.112624@mail.tor.mailerwebmae235.com> Subject: accept credit cards on line today. our system also accepts government charges 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 BECOME A VIRTUAL MERCHANT! 100% ON LINE "REAL TIME" SEAMLESS E-COMMERCE CREDIT CARD SYSTEM WILL PUMP UP YOUR WEBSTORE BUSINESS VOLUME! INTERNET AND DIRECT MARKETING PROS KNOW THAT CUSTOMER'S ON THE WEB WILL SPEND 2.5 TIMES AS MUCH BEING ABLE TO PAY WITH A CREDIT CARD AS OPPOSED TO CASH! A SECURE "SSL" SERVER BASED PLATFORM THAT WILL LEND IMMEDIATE CREDIBILITY TO YOUR ON-LINE STORE! FAST APPROVALS AND SET UP! LOWEST ON LINE PROCESSING RATES AVAILABLE! NO APPLICATION OR SET UP FEES!! TRUE MERCHANT SERVICES / SYSTEM OWNERSHIP PROGRAM! COME ENJOY THE TOTAL CARDSERVICE EXPERIENCE TODAY!!!!! For further information please call 877 205 9117. _________________________________________________________________ ________________________________ Have a product or service to market on the internet? Try our bulk email service today! Check out our introductory offer today ! 150,000 emails sent advertising your product or service for only $295.00! Want to bulk email yourself? Call 877 205 9117 TODAY and check out our latest bulk email programs today! Want bulk email freindly web hosting? Give us a call today! Professional Express System Holdings Inc Montreal Quebec 877 205 9117 From rem-conf Thu Nov 25 19:23:17 1999 From rem-conf-request@es.net Thu Nov 25 19:23:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rBu8-0002u4-00; Thu, 25 Nov 1999 19:18:36 -0800 Received: from 1cust87.tnt3.daytona-beach.fl.da.uu.net (earthlink.net) [63.21.73.87] by mail1.es.net with smtp (Exim 1.81 #2) id 11rBu5-0002tu-00; Thu, 25 Nov 1999 19:18:34 -0800 From: To: rem-conf@es.net Subject: Is this you ? Date: Thu, 25 Nov 1999 22:26:43 Message-Id: <226.80949.35252@earthlink.net> Reply-To: getaway@aol.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Click Here

Click Here

From: Linda Johnson/ Director of online promotions- 800 454-3902 ext 300

Get-Aways Travel Online Promotions division

Re: Dear internet user, You are eligible for this offer based on an opt-in list that you have subscribed to for a 6 Days and 5 Nights Disney/Daytona Florida Vacation at 75% off the everyday retail price.

800-454-3902 x300

GET-AWAYS, INC. 400 Mobile Ave. Suite B-9 Camarillo, CA. 93010

Get-A-ways Travel Service is a full service travel agency A.R.C. #05-568474

Click Here

PS: This is not spam, you have received this offer based on an opt-in list that you have subscribed to.  To be removed send blank reply.

 

From rem-conf Fri Nov 26 04:33:03 1999 From rem-conf-request@es.net Fri Nov 26 04:33:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rKT0-0000NX-00; Fri, 26 Nov 1999 04:27:10 -0800 Received: from florida.melco.co.jp [192.218.140.46] by mail1.es.net with esmtp (Exim 1.81 #2) id 11rKSx-0000NN-00; Fri, 26 Nov 1999 04:27:08 -0800 Received: by florida.melco.co.jp (3.7W-florida) id VAA22825; Fri, 26 Nov 1999 21:27:02 +0900 (JST) Received: by mailgw.melco.co.jp (3.7W-mailgw) id VAA00822; Fri, 26 Nov 1999 21:27:04 +0900 (JST) Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id VAA25027; Fri, 26 Nov 1999 21:27:03 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id VAA06432; Fri, 26 Nov 1999 21:27:27 +0900 (JST) Received: from masuya by islgw.isl.melco.co.jp (8.8.8/3.6W) id VAA07383; Fri, 26 Nov 1999 21:30:19 +0900 (JST) Message-ID: <00b801bf3809$83615b40$1f044a0a@isl.melco.co.jp> From: "Norihito Takatori" To: Subject: Question about the MPEG-4 SL Payload Format Date: Fri, 26 Nov 1999 21:26:49 +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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all, I am implementing a RTP system in compliance with I-D $B!H(Bdraft-ietf-avt-rtp-mpeg4-01.txt$B!I(B. In the draft, it is written that Sequence Number is derived from the sequenceNumber field of the SL packet by adding a constant random offset. I have a question as regards the Sequence Number. My understanding is that when a RTP client issues $B!H(BSEEK$B!I(B operation from current position to a previous position (e.g. 0 position) , the Sequence Number should return the previous Sequence Number. On the other hand, it is written that the sequence number increments by one for each RTP data packet sent in RFC1889. Which should I comply with ? Also, I guess that the same problem will occur as regards the timestamp. Thanks. --------------------------------- Norihito Takatori E-mail: takatori@isl.melco.co.jp Information$B!!(BTechnology$B!!(BR$B!u(BD$B!!(BCenter Mitsubishi Electric Corporation TEL: +81-467-41-2103, FAX: +81-467-41-2137 From rem-conf Fri Nov 26 11:25:26 1999 From rem-conf-request@es.net Fri Nov 26 11:25:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rQqL-0004D5-00; Fri, 26 Nov 1999 11:15:41 -0800 Received: from pneumatic-tube.sgi.com [204.94.214.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11rQqJ-0004Cv-00; Fri, 26 Nov 1999 11:15:39 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02135; Fri, 26 Nov 1999 11:12:38 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA82275; Fri, 26 Nov 1999 11:11:11 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA01387; Fri, 26 Nov 1999 11:11:07 -0800 From: "Ram Kordale" Message-Id: <9911261111.ZM1385@relic.engr.sgi.com> Date: Fri, 26 Nov 1999 11:11:07 -0800 In-Reply-To: "Norihito Takatori" "Question about the MPEG-4 SL Payload Format" (Nov 26, 9:26pm) References: <00b801bf3809$83615b40$1f044a0a@isl.melco.co.jp> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Norihito Takatori" , Subject: Re: Question about the MPEG-4 SL Payload Format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Generally speaking, the sequence number of consecutive RTP packets should either stay the same (allowing for deliberate repeated packets) or be incremented. This mechanism is used to gracefully handle problems arising from "non-ideal" networks. On the other hand, since the timestamp reflects the sampling instant of the first octet in the RTP data packet, the timestamp of an RTP packet after a reposition can indeed be lower. Ram On Nov 26, 9:26pm, Norihito Takatori wrote: > Subject: Question about the MPEG-4 SL Payload Format > Hello all, > > I am implementing a RTP system in compliance with I-D > $B!H(Bdraft-ietf-avt-rtp-mpeg4-01.txt$B!I(B. In the draft, it is written that > Sequence Number is derived from the sequenceNumber field of the SL > packet by adding a constant random offset. > I have a question as regards the Sequence Number. My understanding is > that when a RTP client issues $B!H(BSEEK$B!I(B operation from current position > to a previous position (e.g. 0 position) , the Sequence Number should > return the previous Sequence Number. > On the other hand, it is written that the sequence number increments > by one for each RTP data packet sent in RFC1889. > Which should I comply with ? > Also, I guess that the same problem will occur as regards the > timestamp. > > Thanks. > > --------------------------------- > Norihito Takatori > E-mail: takatori@isl.melco.co.jp > Information$B!!(BTechnology$B!!(BR$B!u(BD$B!!(BCenter > Mitsubishi Electric Corporation > TEL: +81-467-41-2103, FAX: +81-467-41-2137 > >-- End of excerpt from Norihito Takatori -- Ram Kordale Advanced Media Products From rem-conf Fri Nov 26 20:02:10 1999 From rem-conf-request@es.net Fri Nov 26 20:02:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rYyh-0000XN-00; Fri, 26 Nov 1999 19:56:51 -0800 Received: from md2.vsnl.net.in [202.54.6.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11rYye-0000XD-00; Fri, 26 Nov 1999 19:56:48 -0800 Received: from 78017707 ([203.197.149.43]) by md2.vsnl.net.in (8.9.3/8.9.3) with SMTP id JAA27943 for ; Sat, 27 Nov 1999 09:32:17 +0530 (IST) Message-Id: <199911270402.JAA27943@md2.vsnl.net.in> X-Sender: sangit@md2.vsnl.net.in (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sat, 27 Nov 1999 09:40:34 +0530 To: rem-conf@es.net From: Ashwin Desai Subject: Mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sirs, We would like to subscribe to yr mailing list on videophones and videoconfenecing. We are an internet, intramet and communication products and services company in India. We request you to register us . Thanks & Regards. Ashwin Desai A & T Network Systems 1-B, American Mission Lane, Kamarajar Road, Madurai - 625 009. TN INDIA. Ph : 0091- 452 - 726457 / 720832 Fax : 0091- 452 - 726950 From rem-conf Fri Nov 26 20:49:29 1999 From rem-conf-request@es.net Fri Nov 26 20:49:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rZlF-0001Vs-00; Fri, 26 Nov 1999 20:47:01 -0800 Received: from (royou) [202.104.205.6] by mail1.es.net with smtp (Exim 1.81 #2) id 11rZlC-0001Va-00; Fri, 26 Nov 1999 20:46:59 -0800 From: "»ªÁ¢·þÎñ" To: Subject: ÄãÀë²»¿ª¡°Çǵǡ± Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 23 Nov 1999 12:41:26 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ÇǵÇÎÀԡΪ̨ÍåÊÀÒý¹ú¼ÊÓÐÏÞ¹«Ë¾ËùÉú²úµÄһϵÁвúÆ·, Ö÷ÒªÉú²ú ÎÀÉú¼ä¼°³ø·¿Óø÷ʽÁúÍ·¼°Åä¼þ£¬ÆäÖаüÀ¨Ò»°ÙÓàÖÖ°´÷ã¸×רÓø߼¶ÁúÍ·£¬ ¹ã·ºÎªÈ«ÊÀ½ç¸ß¼¶ÂùݲÉÓᣠÇǵÇÎÀÔ¡¿îʽ¶à¡¢±ê×¼¸ß¡¢¼Û¸ñ´óÖÚ»¯£¬ÔÚÈ«¹úÉèÓÐ40¼ÒÌØÔ¼¾­ÏúÉÌ£¬ Ϊ¿Í»§Ìṩ×îÍêÉƵÄÊÛºó·þÎñ£¬²¢ÎªÏû·ÑÕßÌṩÁ˳¤´ïÎåÄêµÄ²úÆ·ÖÊÁ¿±£ Ö¤¡£ »¶Ó­Ê¹ÓÃÇǵÇÎÀÔ¡¡£ ´ó½¹¤³§:±¦¼á(½­ÃÅ)ˮůÆ÷²ÄÓÐÏÞ¹«Ë¾ ÍøÖ·:http://www.joden.com.cn/ ¡ª¡ª¡ª¡ª¡ª¡¡The message was sent by Super Mass Mail¡¡¡ª¡ª¡ª¡ª¡ª Download from The Worldfax Network.¡¡http://www.worldfax.net Start send worldwide free fax and(or) get free website advertising now! From rem-conf Sat Nov 27 07:27:55 1999 From rem-conf-request@es.net Sat Nov 27 07:27:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rjXC-0000tn-00; Sat, 27 Nov 1999 07:13:10 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11rjXA-0000tc-00; Sat, 27 Nov 1999 07:13:09 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 27 Nov 1999 15:13:04 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id PAA01147; Sat, 27 Nov 1999 15:08:25 GMT Message-Id: <199911271508.PAA01147@cperkins-d.cs.ucl.ac.uk> To: Norihito Takatori cc: rem-conf Subject: Re: Question about the MPEG-4 SL Payload Format In-Reply-To: Message from Norihito Takatori of "Fri, 26 Nov 1999 21:26:49 +0900." <00b801bf3809$83615b40$1f044a0a@isl.melco.co.jp> Date: Sat, 27 Nov 1999 15:08:25 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Norihito Takatori writes: >I am implementing a RTP system in compliance with I-D >draft-ietf-avt-rtp-mpeg4-01.txt. In the draft, it is written that Sequence >Number is derived from the sequenceNumber field of the SL packet by adding >a constant random offset. I have a question as regards the Sequence >Number. My understanding is that when a RTP client issues SEEK operation >from current position to a previous position (e.g. 0 position) , the >Sequence Number should return the previous Sequence Number. On the other >hand, it is written that the sequence number increments by one for each >RTP data packet sent in RFC1889. Which should I comply with ? Also, I >guess that the same problem will occur as regards the timestamp. This is actually a generic issue when streaming from a file, rather than an MPEG-4 specific issue. The RTP sequence number must be incremented by one for each packet sent. If packets are sent with a previous sequence number, the receiver may discard them as duplicates (and the RTCP statistics will be incorrect). Receivers use the RTP timestamp to determine when to playout media data. If this jumps backwards as a result of a seek operation, this indicates to the receiver that the data is old - has arrived too late for playout - and should be discarded. The result is that you should remap the sequence number and timestamp to be a contiguous sequence when seeking, as if the data were a single continuous stream. Colin From rem-conf Sat Nov 27 17:18:06 1999 From rem-conf-request@es.net Sat Nov 27 17:18:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11rsm2-0000rb-00; Sat, 27 Nov 1999 17:05:06 -0800 Received: from (nerikes.se) [192.121.240.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11rslz-0000r9-00; Sat, 27 Nov 1999 17:05:04 -0800 Received: from LocalHost ([208.168.196.106]) by nagate.nerikes.se with SMTP id <115204>; Tue, 28 Nov 2000 01:59:45 +0100 X-Mailer: Mozilla 3.57 [en] (Win95; I) X-Via: <451i2rjne47rdw5.271119991953@LocalHost>$(@}# MessageID: <451i2rjne47rdw5.271119991953@LocalHost> Content-Type: text/plain X-In-Response-To: 0EDB8C0F7 X-Accept-Language: en Subject: !YOUR INTERNET FORTUNE... MIME-Version: 1.0 From: To: Date: Sat, 27 Nov 1999 20:53:34 +0100 X-See-Also: 0B7E428DC Message-Id: <00Nov28.015945cet.115204@nagate.nerikes.se> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list EARN LIMITLESS RESIDUAL INCOME FROM INTERNET COMMERCE!! CALL 888-277-7691 TODAY! We are seeking qualified representatives for our new Internet-based technology company, which is financed by a well-known, 15-year-old public corporation. This parent corporation generates about $1.5 billion-per-year in gross revenue, and its top representatives earn from $1,000,000 to almost $3,000,000 per year! Conservative estimates predict that in 5 - 10 years our technology company will generate between $10 and $20 billion per year, with our TOP REPRESENTATIVES earning ALMOST UNIMAGINABLY HIGH INCOMES of at least TEN TIMES GREATER than those of the parent company!! Many INTERNET FORTUNES will be created over the next 5 years.. ONE OF THEM MIGHT AS WELL BE YOURS!!! Almost everyone who is aware of the rapid growth of the Internet has at some time envisioned themselves: - Making huge profits from an Internet-based business, - Working entirely from home, - Spending quality time with their families, and - Forever leaving behind the boss, the office, and the daily commute. - If you have too, then please read on! CONSIDER THE FOLLOWING: - Today, only 18% of North Americans have Internet access in their homes. - However, Internet use is doubling every 100 days! In it's first major study of the economic effect of the Internet, the U.S. Commerce Department said that Internet traffic is doubling every 100 days and Electronic Commerce should reach $300 Billion by 2002! - There are 85,000 new Internet customers logging on daily! - Many different sources have predicted that Internet Commerce will increase at least twenty-fold in the next 5 years, and that within 10 years, standard retailing of products will largely be replaced by online selling! - Experts are predicting that computer sales will drop drastically over the next few years because most homes will be logging onto the net using simpler, less expensive Internet Access Devices. - Some companies are already generating massive revenue by directing their customers to welcome or portal pages that display ads and banners tempting them to shop online. For example, during 1998, America Online generated 3.2 billion dollars of revenue through its entry page. ADDITIONALLY: Market research has shown the more services (such as Internet, long distance, cellular phone, and paging services) one company can provide to the same customer, the longer they are likely to retain that customer. - If they provide one service, they have less than a 50% chance of keeping that customer for one year. - However, if they provide two services, they have a 75% chance of keeping that customer for 5 years. - Finally, of a company can provide three or more services to one customer, they have a 90% chance of keeping that customer for AT LEAST 10 YEARS! THEREFORE: The race is on! Today all major telecommunications companies are competing to: - Secure their share of the Internet marketplace by acquiring new Internet users and capturing their online dollars, - Keep those customers for the next several years by offering them multiple services in addition to Internet access, and - Ultimately generate huge profits when E-Commerce explodes and their customer base spends 40 dollars for every 1 they are spending today! NOW, IMAGINE IF YOU COULD: - Sell Internet service. - Sell your customers an Internet Access Device to connect to that service. - Profit every month from every Internet account. - Direct every customer, every time they log on, to your own Online Supermall wehre they could purchase every imaginable product or service. - Profit from every online purchase made by every customer. - Earn enormous residual profits from all business generated by a potentially huge network of others who you recruit to dupicate your efforts, and thus - Capture your share of the E-Commerce now and make a fortune as it grows. "A wonderful idea for large company" you say, "but a fairy tale for me.." NOT ANY MORE! Our company is already "leveling the playing field" and can provide all the resources and tools you need to help you start our Internet Business and position yourself today to make a fortune from the Internet explosion! We are a rapidly-Growing technology company that is owned and financed by a 15-year-old international billion-dollar company that is publicly traded on the NYSE. We offer a uniquely stable ground floor opportunity, because our company is backed by an established business with a Dunn & Bradstreet credit rating of 5A1, the highest rating available to any business!! We are currently seeking qualified individuals to independently market our rapidly-growing nationwide Internet and telecommunications services and our state-of-the-art Internet Access Device throughout the entire United States and, in the near future, Canadian and Japanese markets! WE ARE SEEKING INDIVIDUALS WHO ARE: - Excited by the possibility of creating their own Internet fortune. - Understand why they must begin establishing their Internet presence today in order to do so. - Are willing to take immediate action and use our extensive resources and support to rapidly build their own business. - Are able to invest between $500 and $1000 to start their business. - Are serious about starting now! PLEASE NOTE: Our company is structured using a network marketing model similar to that of our 15-year-old parent company. This allows any individual to start his or her own business without a huge initial investment and makes our extensive resources and technology available to all who wish to use them. However, we only want serious, motivated individuals to consider joining our company and do not want our network marketing structure and relatively low start-up cost to attract the casually interested. HOWEVER: If you ARE serious, this is TRULY THE CHANCE OF A LIFETIME (and perhaps your only real chance) to "MAKE IT BIG" on the Internet! We can provide you with the following products and technology to successfully compete in the Internet marketplace: NATIONWIDE INTERNET ACCESS We offer our customers state-of-the-art Internet access through a high-speed backbone. We have over 2500 dial-in numbers that make us locally available anywhere in the country. THE WORLD'S BEST-SELLING INTERNET SCREEN PHONE We have exclusive rights to market the first and most popular Internet Access Device in the world! With this compact unit the average user can be online, surfing the web, and sending and retrieving email within 10 minutes of taking it out of the box!! This device is available now and is selling rapidly. AN EXTENSIVE E-COMMERCE WEBSITE We are rapidly developing a comprehensive online store where our customers will be able to purchase virtually any product or service they need! We already have hundreds of thousands of products and services as well as direct links to several affiliate sites, and we are adding new items every day! All transactions are carried out on our secure servers and all products are shipped promptly. A PORTAL PAGE LEADING TO OUR E-COMMERCE WEBSITE We have designed an entry page to the web so that every time any of your customers or representatives logs on to the Internet to check their email or to access a website, they view this page which displays banners and ads directing them to our E-Commerce Store! And, you profit every time one of your customers or representatives makes an online purchase! MULTIPLE TELECOMMUNICATIONS SERVICES We can keep our customers by offering them multiple, state-of-the-art telecommunications services, including long distance telephone service, cellular service, digital and alpha-numeric pager accounts, web hosting, an online university, and more! Furthermore, as more and more services deregulate, such as local telephone service and utilities, we will be competing for all of them! A COMPREHENSIVE TRAINING WEBSITE The two top representatives in our organization have designed a detailed training site which clearly and objectively describes how to build a successful business. This website contains essential information on prospecting, recruiting, training new members, and acquiring new customers. Most importantly, as your business grows, it will dramatically decrease the time you spend training your representatives and free valuable time for you to continue building your organization. SO, AS A REPRESENTATIVE, YOU CAN PROVIDE INDIVIDUALS WITH: 1) An Internet account. 2) A convenient device with which to access the web. 3) An E-Commerce site at which to shop. 4) Direction to that E-Commerce site every time they log on. 5) Multiple other telecommunications services. ALL THE NECESSARY TOOLS YOU NEED TO: - CAPTURE A SIGNIFICANT PERCENTAGE OF NEW INTERNET USERS, - PROFIT FROM ALL E-COMMERCE THEY GENERATE, and - RAPIDLY EXPAND YOUR BUSINESS TO KEEP UP WITH INTERNET GROWTH. CLEARLY, IF YOU STARTED NOW AND OVER THE NEXT FEW YEARS CAPTURED EVEN A TINY AMOUNT OF THE E-COMMERCE PROFITS ON THE INTERNET, YOU WOULD CREATE A RESIDUAL INCOME OF TRULY STAGGERING PROPORTIONS!! REMEMBER!! - Our parent company has, over the last 15 years, created annual incomes of $152,098.00 to $649,550.15 for over 1,000 individuals. - Its representatives have a millionaires' circle and a 10-million- dollar circle. - It did, as a whole, over $1.5 billion in sales last year. - The revenue ultimately generated by our new company, which will ride the ensuing tidal wave of Internet Commerce, WILL LIKELY SURPASS THAT OF THE PARENT COMPANY BY AT LEAST 10 TIMES!! DON'T MISS YOUR CHANCE TO PARTICIPATE IN THE FORTUNES THAT ARE GOING TO BE CREATED! LET US HELP YOU START BUILDING.. CALL TOLL FREE 1-888-277-7691 TODAY!! PLEASE NOTE: If you choose to leave your full mailing address, you will receive, free of charge or obligation, A VIDEOTAPE OUTLINING OUR REMARKABLE OPPORTUNITY! CALL 1-888-277-7691! From rem-conf Mon Nov 29 04:07:09 1999 From rem-conf-request@es.net Mon Nov 29 04:07:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11sPQG-0002m5-00; Mon, 29 Nov 1999 03:56:48 -0800 Received: from lrg-gw.lrg.ufsc.br [150.162.63.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11sPQ9-0002ls-00; Mon, 29 Nov 1999 03:56:42 -0800 Received: (from lanoms99@localhost) by lrg-gw.lrg.ufsc.br (8.8.8/8.8.8) id BAA17073; Mon, 29 Nov 1999 01:34:14 -0200 (EDT) Date: Mon, 29 Nov 1999 01:34:14 -0200 (EDT) From: "LANOMS'99" Subject: IEEE LANOMS99 - THANK YOU VERY MUCH To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, MariaLuisa.Rossari@CSELT.IT, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl In-Reply-To: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The organizers of the IEEE LANOMS99 want to say THANK YOU VERY MUCH for your attention and contribution associated with the realization of the First IEEE LANOMS. ************************************************************** * You are very welcome to participate in the * * * * IEEE LANOMS99 * * * * LATIN AMERICAN NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM * * * * http://www.lrg.ufsc.br/~lanoms99/ * * * * Rio Atlantica Hotel * * Av. Atlantica, 2964 - Copacabana * * Rio de Janeiro - Brazil * * December 3-5, 1999 * ************************************************************** From rem-conf Mon Nov 29 06:32:46 1999 From rem-conf-request@es.net Mon Nov 29 06:32:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11sRkb-0004lI-00; Mon, 29 Nov 1999 06:25:57 -0800 Received: from www400.infomagic.com [208.128.17.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 11sRkY-0004l8-00; Mon, 29 Nov 1999 06:25:55 -0800 Received: from yorktown ([209.142.10.67]) by www400.InfoMagic.com (Netscape Mail Server v2.02) with SMTP id AAB518; Mon, 29 Nov 1999 07:28:40 -0700 Message-Id: <3.0.1.32.19991129060442.00b90210@www400.infomagic.com> X-Sender: ian@www400.infomagic.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 29 Nov 1999 06:04:42 -0800 To: "LANOMS'99" ,activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu,alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp,apc@ee.nthu.edu.tw,apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg,apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr,apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu,atm@bbn.com,atm@sun.com,bd_email@inesc.pt, bm-list1@cs.ucdavis.edu,cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk,ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu,cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov,cnom@maestro.bellcore.com, cnon@maestro.bellcore.com,commsoft@cc.belcore.com, commsoft@cc.bellcore.com,comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org,comsoc-chapters@IEEE.ORG,comsoc-gicb@IEEE.ORG, comswtc@gmu.edu,cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at,cpmsoc-gicb@IEEE.ORG, ctc-members@redbank.tinac.com,dbword@cs.wisc.edu,ekpark@cstp.umkc.edu, end2end-interest@isi.edu,engp5273@leonis.nus.sg,enternet@bbn.com, events@teco.edu,fokus-user@fokus.gmd.de,f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu,gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu,g-troup@ccrc.wustl.edu,heads@hpovua.org, hipparch@entropy.inria.fr,hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr,ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu,ieeetcpc@ccvm.sunysb.edu,ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be,im-oc@doc.ic.ac.uk, int-serv@isi.edu,isadsoc@fokus.gmd.de,issll@mercury.lcs.mit.edu, itc@fokus.gmd.de,itc@IEEE.ORG,kia@usl.edu,MariaLuisa.Rossari@cselt.it, members@hpovua.org,members@tmforum.org,mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu,multicomm@cc.bellcore.com, multicomm@research.panasonic.com,nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr,Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu,osimcast@bbn.com, performance@haven.epm.ornl.gov,prs@masi.ibp.fr,qos-iso@mci.org.uk, qosws@dstc.edu.au,rem-conf@es.net,reres@laas.fr,s.low@ee.mu.oz.au, sb.all@IEEE.ORG,sc6wg4@ntd.comsat.com,sig-dce@opengroup.org, sigmedia@bellcore.com,tccc@IEEE.ORG,tchen@seas.smu.edu, testnet@canarie.ca,tm_member@ns.ieice.or.jp,wwlu@IEEE.ORG, xtprelay@cs.concordia.ca,lyko@kt.agh.edu.pl From: Ian@NC-Labs.com (Ian Nandhra) Subject: Re: IEEE LANOMS99 - THANK YOU VERY MUCH In-Reply-To: References: <199910231940.RAA14214@lrg-gw.lrg.ufsc.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thank you very much for SPAMMING assorted people with your email. Aside >from the SPAM, you have also included a visible distribution list with the email. MAYBE YOU SHOULD ATTEND YOUR OWN SYMPOSIUM AND LEARN AT LEAST **SOMETHING** ABOUT EMAIL AND THE INTERNET. Pathetic! At 01:34 AM 11/29/99 -0200, LANOMS'99 wrote: >The organizers of the IEEE LANOMS99 want to say THANK YOU VERY >MUCH for your attention and contribution associated with the >realization of the First IEEE LANOMS. > >************************************************************** >* You are very welcome to participate in the * >* * >* IEEE LANOMS99 * >* * >* LATIN AMERICAN NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM * >* * >* http://www.lrg.ufsc.br/~lanoms99/ * >* * >* Rio Atlantica Hotel * >* Av. Atlantica, 2964 - Copacabana * >* Rio de Janeiro - Brazil * >* December 3-5, 1999 * >************************************************************** > > -- Ian Nandhra Phone : 209 533 4559 NC Laboratories Inc. FAX : 209 532 1578 Suite 17-107, 18711 Tiffeni Drive, email : ian@nc-labs.com Twain Harte, CA 95383, USA. http//www.nc-labs.com From rem-conf Mon Nov 29 10:13:31 1999 From rem-conf-request@es.net Mon Nov 29 10:13:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11sVE9-0007nK-00; Mon, 29 Nov 1999 10:08:41 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 11sVE8-0007nA-00; Mon, 29 Nov 1999 10:08:40 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id JAA09790; Mon, 29 Nov 1999 09:59:33 -0800 (PST) Message-Id: <3.0.3.32.19991129095934.00b5b4a0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 29 Nov 1999 09:59:34 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 12/1 The Berkeley-MIT Citywalk Project: Towards Highly Interactive, Large-Scale Acquired Models --Richard Bukowski, Computer Science Division - EECS, U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar The Berkeley-MIT Citywalk Project: Towards Highly Interactive, Large-Scale Acquired Models Wednesday December 1, 1999 1:00-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Richard Bukowski Computer Science Division - EECS, U.C. Berkeley Over the last year, groups at Berkeley and MIT have been working together to merge the Berkeley Firewalk/Architectural Walkthrough system with the MIT Citywalk city scanning project. The result is a system that combines the highly interactive, simulation-enriched Berkeley visualization tools with real-world data acquired by the MIT Argus probe and reconstructed into exterior models of the as-built MIT campus. Our goal is to provide an integrated system that has the ability to visualize models several orders of magnitude larger than those we have previously rendered (i.e. the Soda Hall interior), as well as to allow multiple distributed users to interact with and run simulations on those models in a shared virtual world, and to store and index semantic information about those models. Because our models are derived from real-world data, they can be applied to real-world problems such as site and building lifecycle management, construction management, building plan evaluation, and fire safety training. This talk will present background and preliminary work on extending the Walkthrough's database and systems to handle both outdoor environments and distributed, multi-user database interaction and editing. These extensions achieve these goals while preserving the viewpoint and data management systems that allow Walkthrough to present huge, interactive models at real-time frame rates. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Nov 30 02:39:00 1999 From rem-conf-request@es.net Tue Nov 30 02:38:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11skbD-0000cp-00; Tue, 30 Nov 1999 02:33:31 -0800 Received: from homesh.lnk.telstra.net (thehsn.com) [139.130.12.192] by mail1.es.net with smtp (Exim 1.81 #2) id 11skbA-0000cf-00; Tue, 30 Nov 1999 02:33:28 -0800 Received: from colleen.aucom.com.au ([203.33.171.252]) by thehsn.com ( IA Mail Server Version: 3.1.2. Build: 1061 ) ) ; 20 Nov 1999 10:42:50 UT Received: from mryan ([203.33.171.32]) by colleen.aucom.com.au (8.8.7/8.8.7) with SMTP id XAA07183 for ; Sat, 20 Nov 1999 23:14:06 +1100 Message-ID: <002d01bf333d$30063cc0$20ab21cb@aucom.com.au> From: "mannatech mailing list" To: Subject: [ mannatech mailing list ] "Something New & Natural" Date: Sat, 20 Nov 1999 20:53:45 +1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BF3399.561B3620" 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-Errors-To: dave@thehsn.com REPLY-TO: "mannatech mailing list" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BF3399.561B3620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Something New & Natural" Hello, My name is Dr Mark Ryan and I welcome you to view my website (which is still in its infancy). If you find anything of interest and =20 would like more information, please do not hesitate to leave a message. VISIT OUR WEBSITE AT: http://www.thehsn.com to unsubscribe from this list unsubscribe@thehsn.com This e-mail conforms with all US regulations. If you would not like to=20 receive future e-mails please use the unsubscribe link above. ------=_NextPart_000_0028_01BF3399.561B3620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
"Something New & Natural"
 
Hello,
 
My name is Dr Mark Ryan and I welcome you to view my = website=20 (which
is still in its infancy). If you find anything of interest = and =20
would like more information, please do not hesitate to leave a=20 message.
 
VISIT OUR WEBSITE AT:   http://www.thehsn.com
 
to unsubscribe from this list unsubscribe@thehsn.com<= /DIV>
 
 
This e-mail conforms with all US regulations. If you = would not=20 like to
receive future e-mails please use the unsubscribe = link=20 above.
------=_NextPart_000_0028_01BF3399.561B3620-- From rem-conf Tue Nov 30 04:08:53 1999 From rem-conf-request@es.net Tue Nov 30 04:08:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11sluO-0001jW-00; Tue, 30 Nov 1999 03:57:24 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11sluN-0001jM-00; Tue, 30 Nov 1999 03:57:23 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04824; Tue, 30 Nov 1999 06:57:21 -0500 (EST) Message-Id: <199911301157.GAA04824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps Date: Tue, 30 Nov 1999 06:57:20 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-03.txt,.ps Pages : 28 Date : 29-Nov-99 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-tones-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-tones-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991129130338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991129130338.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Nov 30 14:10:49 1999 From rem-conf-request@es.net Tue Nov 30 14:10:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11svLO-00077w-00; Tue, 30 Nov 1999 14:01:54 -0800 Received: from betelgeuse.concentric.net [207.155.183.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 11svLM-00077m-00; Tue, 30 Nov 1999 14:01:53 -0800 Received: from pfoypc ([139.85.47.243]) by betelgeuse.concentric.net (8.8.5/) id RAA18873; Tue, 30 Nov 1999 17:01:51 -0500 (EST) [ConcentricHost MX Server] Received: by localhost with Microsoft MAPI; Tue, 30 Nov 1999 17:01:18 -0500 Message-ID: <01BF3B54.85473030.foy01@qwestinternet.net> From: Patrick Foy Reply-To: "foy01@qwestinternet.net" To: "'rem-conf@es.net'" Subject: RTP Setup Signaling Date: Tue, 30 Nov 1999 17:01:17 -0500 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 I am working on a project that is required to support RTP and RTCP. I've read a lot about RTP in general, but I still have not found any information about setting up the RTP session. I am assuming (for the sake of this discussion) that RTP is not used with any other standards like H.323 or RSVP. Is there some setup signaling used so that the receiver is informed of the port numbers (RTP and RTCP) that were decided for the session? I read some document on the Internet that said Session Description Protocol (SDP) was used to communicate the port numbers. However, I wasn't convince that this protocol was being used in applications like LiveMedia or Netmeeting. Any information that you can share concerning the setup signaling will be appreciated. From rem-conf Tue Nov 30 15:32:31 1999 From rem-conf-request@es.net Tue Nov 30 15:32:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11swi1-0000f5-00; Tue, 30 Nov 1999 15:29:21 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11swi0-0000ev-00; Tue, 30 Nov 1999 15:29:20 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Nov 1999 23:29:15 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id XAA11827; Tue, 30 Nov 1999 23:28:27 GMT Message-Id: <199911302328.XAA11827@cperkins-d.cs.ucl.ac.uk> To: "foy01@qwestinternet.net" cc: "'rem-conf@es.net'" Subject: Re: RTP Setup Signaling In-Reply-To: Message from Patrick Foy of "Tue, 30 Nov 1999 17:01:17 EST." <01BF3B54.85473030.foy01@qwestinternet.net> Date: Tue, 30 Nov 1999 23:28:27 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Patrick Foy writes: >I am working on a project that is required to support RTP and RTCP. I've >read a lot about RTP in general, but I still have not found any information >about setting up the RTP session. > >I am assuming (for the sake of this discussion) that RTP is not used with >any other standards like H.323 or RSVP. Is there some setup signaling used >so that the receiver is informed of the port numbers (RTP and RTCP) that >were decided for the session? > >I read some document on the Internet that said Session Description Protocol >(SDP) was used to communicate the port numbers. However, I wasn't convince >that this protocol was being used in applications like LiveMedia or >Netmeeting. > >Any information that you can share concerning the setup signaling will be >appreciated. There is no built-in signalling in RTP, some other protocol must be used. Applications use something like H.323, SIP, RTSP or SAP to setup the RTP session. These protocols convey session descriptions, often in SDP format. Colin From rem-conf Tue Nov 30 17:47:54 1999 From rem-conf-request@es.net Tue Nov 30 17:47:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11sykw-0002M9-00; Tue, 30 Nov 1999 17:40:30 -0800 Received: from lambda.cheju.ac.kr [203.253.214.18] by mail1.es.net with smtp (Exim 1.81 #2) id 11sykr-0002Iu-00; Tue, 30 Nov 1999 17:40:26 -0800 Received: by lambda.cheju.ac.kr; id AA03944; Wed, 1 Dec 1999 10:37:36 +0900 Date: Wed, 1 Dec 1999 10:37:36 +0900 Message-Id: <9912010137.AA03944@lambda.cheju.ac.kr> From: joy799@email.com Reply-To: joy799@email.com To: joy799@email.com Subject: energy, and using it in a positive way, X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Finally... A Dream Come True. The product that over 100 Million people have been waiting for! Formulated to enhance peoples sexual experience naturally. We have the SAFE alternative to Viagra, "that Works." for both Women and Men Whats in it for You ? We ask that You visit our site- http://216.237.152.177 and see for your self. The general response, which continues to flood back to us, suggests that when we are aware of our sexual energy, and using it in a positive way, we are more likely to become more effective in all aspects of our lives. The most obvious benefits connected with feeling sexual, is that we feel content and secure. Our lives are enriched when we are expressing and satisfying our natural and healthy desires. Thank you and have a GREAT Day ______________________________________________________________________________ If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" to:flw66@email.com and this software will automatically block you from their future mailings. You MUST put Remove in the Subject line otherwise your message will be Deleted and our software won't recognize your remove request ********************************************************************************* From rem-conf Tue Nov 30 20:18:59 1999 From rem-conf-request@es.net Tue Nov 30 20:18:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11t16c-00046j-00; Tue, 30 Nov 1999 20:11:02 -0800 Received: from hd2.vsnl.net.in (hd2.dot.net.in) [202.54.30.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11t16b-000456-00; Tue, 30 Nov 1999 20:11:01 -0800 Received: from hyd.chiplogic.com ([203.197.20.104]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id JAA15359; Wed, 1 Dec 1999 09:40:51 +0530 (IST) Received: from localhost (ramana@localhost) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id JAA23305; Wed, 1 Dec 1999 09:28:32 +0530 X-Authentication-Warning: hyd.chiplogic.com: ramana owned process doing -bs Date: Wed, 1 Dec 1999 09:28:30 +0530 (IST) From: Ramana Yarlagadda To: Patrick Foy cc: "'rem-conf@es.net'" Subject: Re: RTP Setup Signaling In-Reply-To: <01BF3B54.85473030.foy01@qwestinternet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Patrcik, In H323 umberalla standards H245 is used to setup an RTP session -cheers -ramana On Tue, 30 Nov 1999, Patrick Foy wrote: > I am working on a project that is required to support RTP and RTCP. I've > read a lot about RTP in general, but I still have not found any information > about setting up the RTP session. > > I am assuming (for the sake of this discussion) that RTP is not used with > any other standards like H.323 or RSVP. Is there some setup signaling used > so that the receiver is informed of the port numbers (RTP and RTCP) that > were decided for the session? > > I read some document on the Internet that said Session Description Protocol > (SDP) was used to communicate the port numbers. However, I wasn't convince > that this protocol was being used in applications like LiveMedia or > Netmeeting. > > Any information that you can share concerning the setup signaling will be > appreciated. >