From rem-conf Thu Jul 01 01:14:57 1999 From rem-conf-request@es.net Thu Jul 01 01:14:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zbvz-0003m4-00; Thu, 1 Jul 1999 01:11:03 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zbvy-0003ls-00; Thu, 1 Jul 1999 01:11:02 -0700 Received: from sj-dial-3-21.cisco.com (sj-dial-3-21.cisco.com [171.68.180.22]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id BAA22209; Thu, 1 Jul 1999 01:10:00 -0700 (PDT) Date: Thu, 1 Jul 1999 01:09:55 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Four drafts for AVT 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 submitted four Internet-Drafts for AVT which should be in the pipeline. They are also available from: ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-new-04.ps ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-new-04.txt ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-profile-new-06.ps ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-profile-new-06.txt ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtp-mime-00.txt ftp://ftpeng.cisco.com/casner/outgoing/draft-ietf-avt-rtcp-bw-00.txt The first one is the RTP spec, where the changes were only minor fixes. This time Section 12 is not missing from the .txt version. The second is the RTP Audio/Video Profile. The main change there was to the wording of the reference to the separate draft on registering payload format (encoding) names as MIME subtypes. That reference needs to be non-normative since the other draft won't be ready to go to Draft Standard yet. See if the wording still conveys the right message. I also removed some encoding names/descriptions for which we really did not have any specification of the payload format, and probably no implementations. The rtp-mime draft is a significant revision of the very rough draft for the MIME subtype registration that we discussed in Minneapolis. I think this draft is more or less complete now, and would greatly appreciate your comments. The last one is a writeup of the SDP extension to add RTCP bandwidth modifier keywords for the b= line. There was no draft in Minneapolis, but I described what was needed. We decided there that the value for these keywords should be in b/s rather than a fractional kb/s (either of which would be in conflict with the SDP spec). Again, comments appreciated. -- Steve From rem-conf Thu Jul 01 06:28:59 1999 From rem-conf-request@es.net Thu Jul 01 06:28:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zgoS-0006Vt-00; Thu, 1 Jul 1999 06:23:36 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10zgoQ-0006VN-00; Thu, 1 Jul 1999 06:23:34 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Jul 1999 14:23:30 +0100 To: rem-conf@es.net Subject: AVT agenda for Oslo cc: agenda@ietf.org Date: Thu, 01 Jul 1999 14:23:30 +0100 Message-ID: <3079.930835410@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Enclosed is the preliminary agenda for the AVT working group meeting in Oslo. Please send comments/corrections to Steve and I as soon as possible. Colin Audio/Video Transport WG A G E N D A Wednesday, 14 July at 09:00-11:30 ================================= - Status and progress since last meeting (Casner) 10 - SSRC sampling - Guidelines - QCELP - Update on RTP specification and audio/video profile (Casner) 20 draft-ietf-avt-rtp-new-04.txt, .ps draft-ietf-avt-profile-new-06.txt, .ps draft-ietf-avt-rtp-mime-00.txt draft-ietf-avt-rtcp-bw-00.txt - RTP interoperability statement and testing strategies draft-ietf-avt-rtp-interop-00.txt (Perkins) 10 draft-ietf-avt-rtptest-00.txt (Perkins) 10 draft-ietf-avt-rtcptest-01.txt (Rosenberg) 10 Discussion 10 - RTP MIB draft-ietf-avt-rtp-mib-05.txt (Baugher) 5 - RTP Payload for DTMF tones draft-ietf-avt-tones-01.txt (Petrack) 10 - RTP Payload for Generic FEC draft-ietf-avt-fec-06.txt (Rosenberg) 5 - MPEG4 payload format Report from New York meeting - RTP Payload for MPEG-4 with Scaleable & Flexible Error Resiliency draft-guillemot-genrtp-01.txt (Wesner) 20 - RTP Payload for DV video draft-ietf-avt-dv-video-00.txt (Kobayashi) 10 - RTP encapsulation for 12-bit DV audio draft-kobayashi-dv-audio12-00.txt (Kobayashi) 10 Thursday, 15 July at 15:30-17:30 ================================ - RTP Payload for AAC audio draft-kretschmer-mpeg2aac-00.txt (?) (Kretschmer) 10 - RTP Payload for real-time pointers draft-civanlar-rtp-pointer-00.txt (Civanlar) 10 - RTP Payload for Text Conversation (Hellström) 10 - Header compression for RTP/UDP/IP over cellular links draft-degermark-crtp-cellular-00.txt, .ps (Degermark) 20 - Multiplexing header-compressed RTP over PPP draft-pazhyannur-avt-pppmux-00.txt (Pazhyannur) 10 - Tunneled Compressed RTP draft-wing-avt-tcrtp-00.txt (Koren) 10 - A Taxonomy of Feedback for Multicast 10 draft-hnrs-rmt-avt-feedback-00.txt (Rosenberg) - Profile for unicast RTCP 10 (Casner) - Discussion of new profiles/feedback mechanisms 10 - RTP payload for virtual worlds draft-stewart-avt-00.txt (Stewart) 15 From rem-conf Thu Jul 01 09:23:59 1999 From rem-conf-request@es.net Thu Jul 01 09:23:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zjYU-00010B-00; Thu, 1 Jul 1999 09:19:18 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zjYU-000101-00; Thu, 1 Jul 1999 09:19:18 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id LAA29509 for ; Thu, 1 Jul 1999 11:19:04 -0500 (CDT)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA08596 for ; Thu, 1 Jul 1999 11:16:00 -0500 (CDT)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2448.0) id ; Thu, 1 Jul 1999 11:18:45 -0500 Message-ID: <51F347B016ADD011963200805FC145620437F22E@email1.wes.mot.com> From: Ali Irfan-FIA225 To: rem-conf@es.net, ietf-ppp@merit.edu Cc: PAZHYANNUR RAJESH-QA6283 Subject: Internet draft: Multiplexing Compressed RTP/UDP Packets in a PPP Frame Date: Thu, 1 Jul 1999 11:18:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have submitted an Internet draft which is of interest to the AVT and the PPPext groups. We will be making a 10 minute presentation about the draft to the AVT group on Thursday, 15th July during the 15:30-17:30 session. Comments on the draft are welcomed. Details: Title: Multiplexing Compressed RTP/UDP Packets in a PPP Frame Author: Rajesh Pazhyannur and Irfan Ali Filename: draft-pazhyannur-avt-pppmux-00.txt Pages: 7 Date: 22-June-99 Abstract This draft proposes a scheme to increase the capacity of low-speed transmission links, T-1/E-1 or smaller, to transport low-bit rate voice applications over PPP. Given the relatively small payload size of the voice packets (average of 8 bytes for certain cellular networks) protocol overheads due to PPP, IP, UDP, and RTP are significant in determining the link capacity. The scheme proposed here is to multiplex compressed RTP/UDP packets into a single PPP frame. As a result, the PPP overhead (5-7 bytes) is distributed over multiple compressed RTP/UDP packets. You can get the draft at http://www.ietf.org/internet-drafts/draft-pazhyannur-avt-pppmux-00.txt Irfan Ali & Rajesh Pazhyannur From rem-conf Thu Jul 01 15:52:02 1999 From rem-conf-request@es.net Thu Jul 01 15:52:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10zpTj-0004lM-00; Thu, 1 Jul 1999 15:38:47 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 10zpTg-0004lC-00; Thu, 1 Jul 1999 15:38:44 -0700 Received: from uggla (ap01-031.mp.pi.se [195.7.86.31]) by mail.pi.se (8.8.8/8.8.8) with SMTP id AAA21915; Fri, 2 Jul 1999 00:38:27 +0200 (MET DST) Message-Id: <3.0.1.32.19990702003637.00740324@mail.pi.se> X-Sender: au1042@mail.pi.se X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 02 Jul 1999 00:36:37 +0200 To: rem-conf@es.net From: Gunnar Hellstrom Subject: RTP for text conversation for discussion in Oslo Cc: textphone@lsv.pi.se (Text Telephone Forum) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_930861397==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_930861397==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am sorry to clobber your mail, but here is an IETF draft for discussion on the Thursday AVT session in Oslo, attached to this mail.=20 The topic is RTP format for text conversation data, needed for H.323 Annex= G. I did not succeed to put it in any FTP area this time. This is a later version of a draft that was distributed a week ago. The main difference is that when redundant data is used, it is now coded according to RFC 2198. It is better than invent a new mechanism. A Security section is also added. Best regards Gunnar Hellstr=F6m --=====================_930861397==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hellstrom-avt-rtp-text-00.txt" Internet Engineering Task Force AVT WG Internet Draft Gunnar= Hellstr=F6m draft-hellstrom-avt-rtp-text-00.txt L M Ericsson June 25, 1999 Expires: Dec 25, 1999 RTP Payload for Text Conversation STATUS OF THIS MEMO This document is an Internet-Draft and it is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html Distribution of this document is unlimited. ABSTRACT This memo describes how to carry text conversation session contents in= RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1].=20 Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation= services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the= risk of text loss caused by packet loss. The redundancy coding follows RFC= 2198. 1 Introduction This memo defines a payload type for carrying text conversation session= =20 contents in RTP packets. Text conversation session contents are specified= in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. Text in text conversation sessions= is =20 Hellstr=F6m [Page 1] Internet Draft sent as soon as it is available, or with a small delay of up to=20 0.5 seconds for buffering. The text is supposed to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per= second or less. Therefore, the expected number of characters to transmit is low. Only one or a few new characters are expected to be transmitted with each packet. T.140 specifies that text and other T.140 elements shall be transmitted= in =20 ISO 10 646-1 code with UTF-8 transformation. That makes it easy to= implement internationally useful applications, and to handle the text in modern =20 information technology environments.=20 =20 T.140 requires the transport channel to provide characters without duplication and in original order.=20 Text conversation users expect that text will be delivered with no or a= low level of lost information. If lost information can be replaced with a= special=20 marker, the willingness to accept loss is expected to be higher. =20 Therefore a mechanism based on RTP is specified here. It gives text= arrival =20 in correct order, without duplications, with an optional possibility to = =20 repeat data for redundancy to lower the risk of loss, and a mechanism= that=20 reveals loss and therefore can insert a marker for lost text in the= received stream. Since packet overhead is usually much larger than the T.140= contents, the increase in channel load by the redundancy scheme is minimal.=20 2. Usage of RTP When an unreliable transport of T.140 text session data in the Internet= is selected, RTP with payload as described in this specification should be= used. T.140 data is submitted for transmission in a numer of complete protocol= data units (a T140block consisting of one or more T140 PDU:s). The most common T140 PDU is a character of ISO 10646 text, UTF-8 coded, submitted from= T.140 without any extra framing. =20 A text conversation RTP packet contains an RTP header, a Payload Header, optional redundant data fields, and the new (primary) T.140 data field. =20 2.1 RTP packet header =20 Each RTP packet starts with a fixed RTP header. The following fields of= the RTP fixed header are used for T.140 text streams: Payload Type (PT): If redundancy is used, the Payload Type shall indicate= redundancy according to RFC 2198. If no redundnacy is used, the Payload= Type shall specify the primary T.140 text payload format.=20 Sequence number: The Sequence Number shall be increased with one for= each new transmitted packet. It is used for detection of packet loss and= packets out of order, and can be used in the process of retrieval of redundant= text,=20 reordering of text and marking missing text. Hellstr=F6m [Page 2] Internet Draft =20 Timestamp: The RTP Timestamp encodes the approximate sampling instance of= =20 the primary text in the packet. No packets should use the same timestamp. 2.2 Additional headers When redundant data is used, additional headers specify the redundant text= fields. They are specified according to RFC 2198 and use payload type= "redundant T.140 data". 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra framing.= The primary T.140 data is identified with the payload type "primary T.140= data".=20 The transmitting station may select a number of T.140 block generations= to retransmit in each packet. A higher number introduces better protection against loss of text. If network conditions are not known, it is= recommended to use two generations. A maximum of 6 generations may be specified. 3. Procedures Based on the information in the received packets, the receiver can: -reorder received text out of order. -mark where text is missing because of packet loss. -compensate for lost packets by using redundant data. ---note-procedure description for insertion in a protocol spec-------- Procedure =20 On reception, the RTP sequence number is compared with the sequence= number of the last correctly received packet.=20 If they are consecutive, only the most recent t140block is submitted from= the packet to T.140.=20 Compensation for lost packets. =20 If there is a gap in the RTP sequence numbers, older t140blocks are= retrieved from the packet up to the point where the sequence number is consecutive= to the last correctly received packet or no more t140block is available in= the received packet. If there is still a gap in the sequence, one T.140 missing data marker ( Unicode character 2607 "Lightning") is inserted, UTF-8 coded,= replacing each missing t140block. =20 All t140blocks retrieved in this way are submitted to the receiving T.140 instance. Hellstr=F6m [Page 3] Internet Draft Expires 25 Dec 1999 Compensation for packets out of order. For protection against packets arriving out of order, the following= procedure may be implemented in the receiver. If analysis of a received packet reveals gaps in the sequence, the= received packet can be kept in a buffer before submission to the T.140 layer.=20 If a packet arrives with a t140block belonging to the gap, the gap is= filled with the contents of this block.=20 If all gaps are filled or the packet is kept in the buffer for 0.5= seconds, valid T140blocks in the buffered packet are retrieved and submitted to= the T.140 layer. For each t140block still missing, a T.140 missing data= marker (Unicode character 2607 "Lightning") is inserted. =20 --------- end of note ------------------------------------------------ 4. Security Considerations The same security considerations as for RFC 2198 apply. 5 Authors Address Gunnar Hellstr=F6m L M Ericsson Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 6 Bibliography [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application. Hellstr=F6m [Page 4] --=====================_930861397==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------------------------------------------------ Gunnar Hellstr=F6m Omnitor AB Alsn=F6gatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Video +46 8 556 002 05 Text (V.18) +46 8 556 002 05 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom@omnitor.se WWW: www.omnitor.se ------------------------------------------------ --=====================_930861397==_-- From rem-conf Fri Jul 02 04:27:01 1999 From rem-conf-request@es.net Fri Jul 02 04:27:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1101Rk-0002DA-00; Fri, 2 Jul 1999 04:25:32 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 1101Rj-0002Cu-00; Fri, 2 Jul 1999 04:25:31 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04592; Fri, 2 Jul 1999 07:24:28 -0400 (EDT) Message-Id: <199907021124.HAA04592@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mpeg2aac-00.txt Date: Fri, 02 Jul 1999 07:24:27 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MPEG-2 AAC Streams Author(s) : M. Kretschmer, A. Basso, M. Civanlar, S. Quackenbush, J. Snyder Filename : draft-ietf-avt-rtp-mpeg2aac-00.txt Pages : 8 Date : 01-Jul-99 This document describes a payload format for transporting MPEG-2 AAC encoded data using RTP. MPEG-2 AAC is a recent standard from ISO/IEC for the coding of multi-channel audio data. Several services provided by RTP are beneficial for MPEG-2 AAC encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-2 AAC data with other real-time data types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg2aac-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mpeg2aac-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mpeg2aac-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: <19990701143534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg2aac-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg2aac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990701143534.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 02 04:27:01 1999 From rem-conf-request@es.net Fri Jul 02 04:27:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1101Sl-0002Dk-00; Fri, 2 Jul 1999 04:26:35 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 1101Sk-0002DC-00; Fri, 2 Jul 1999 04:26:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04630; Fri, 2 Jul 1999 07:25:31 -0400 (EDT) Message-Id: <199907021125.HAA04630@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-00.txt Date: Fri, 02 Jul 1999 07:25:30 -0400 Sender: nsyracus@ns.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-00.txt Pages : 23 Date : 01-Jul-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-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-tones-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-tones-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: <19990701143546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990701143546.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 02 04:27:01 1999 From rem-conf-request@es.net Fri Jul 02 04:27:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1101OH-0002B9-00; Fri, 2 Jul 1999 04:21:57 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 1101OG-0002Av-00; Fri, 2 Jul 1999 04:21:57 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04489; Fri, 2 Jul 1999 07:20:53 -0400 (EDT) Message-Id: <199907021120.HAA04489@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-format-guidelines-03.txt,.ps Date: Fri, 02 Jul 1999 07:20:53 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Guidelines for Writers of RTP Payload Format Specifications Author(s) : M. Handley, C. Perkins Filename : draft-ietf-avt-rtp-format-guidelines-03.txt,.ps Pages : 9 Date : 01-Jul-99 This document provides general guidelines aimed at assisting the authors of RTP [9] Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-format-guidelines-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-rtp-format-guidelines-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-rtp-format-guidelines-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: <19990701143513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-format-guidelines-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990701143513.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 02 07:07:25 1999 From rem-conf-request@es.net Fri Jul 02 07:07:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1103sx-0005HN-00; Fri, 2 Jul 1999 07:01:47 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1103sw-0005HD-00; Fri, 2 Jul 1999 07:01:46 -0700 Received: from cirque (cirque.cdt.luth.se [130.240.64.78]) by basil.cdt.luth.se (8.8.8/8.7.3) with SMTP id QAA20679; Fri, 2 Jul 1999 16:01:43 +0200 (MET DST) Message-Id: <3.0.6.32.19990702160329.00ac53c0@mailhost.cdt.luth.se> X-Sender: micke@mailhost.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 02 Jul 1999 16:03:29 +0200 To: rem-conf@es.net From: Mikael Degermark Subject: Drafts for AVT Cc: micke@cdt.luth.se, Lars-Erik.Jonsson@ericsson.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, We've looked at the problem of doing IP telephony over cellular links, and will present some work on header compression over cellular links in the AVT WG in Oslo. On cellular links, bandwidth is very expensive, and it is necessary to compress headers to be able to compete with circuit-switched systems. However, CRTP does not appear to work well over cellular links as we show in http://www.ietf.org/internet-drafts/draft-degermark-crtp-cellular-00.txt http://www.ietf.org/internet-drafts/draft-degermark-crtp-cellular-00.ps In fact, CRTP does not appear to deliver performance high enough to make IP telephony to cellular phones economically feasible. To alleviate this problem we played around with other header compression schemes and came up with one that performs very well. It is described in http://www.ietf.org/internet-drafts/draft-jonsson-robust-hc-00.txt http://www.ietf.org/internet-drafts/draft-jonsson-robust-hc-00.ps Comments are welcome! Cheers Mikael Degermark http://www.cdt.luth.se/~micke From rem-conf Fri Jul 02 07:28:27 1999 From rem-conf-request@es.net Fri Jul 02 07:28:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1104HO-00069U-00; Fri, 2 Jul 1999 07:27:02 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1104HN-00069K-00; Fri, 2 Jul 1999 07:27:01 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Jul 1999 15:26:57 +0100 To: rem-conf@es.net Subject: Working group last call on generic FEC payload format Date: Fri, 02 Jul 1999 15:26:54 +0100 Message-ID: <3069.930925614@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two week working group last call on the RTP payload format for generic forward error correction (draft-ietf-avt-fec-06.txt). If no comments requiring substantive changes are received in the next two weeks (by 16th July), this draft will be submitted for publication as a standards track RFC. Note that Jonathan Rosenberg will make a brief presentation on this draft in the AVT meeting in Oslo on Wednesday 14th July. Colin From rem-conf Fri Jul 02 07:51:35 1999 From rem-conf-request@es.net Fri Jul 02 07:51:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1104eD-000734-00; Fri, 2 Jul 1999 07:50:37 -0700 Received: from ns.koganei.wide.ad.jp (happy.koganei.wide.ad.jp) [203.178.148.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 1104e8-00072u-00; Fri, 2 Jul 1999 07:50:34 -0700 Received: from localhost (eeyore.koganei.wide.ad.jp [203.178.148.70]) by happy.koganei.wide.ad.jp (8.9.3/8.9.3) with ESMTP id XAA10717; Fri, 2 Jul 1999 23:50:23 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) To: nv91-tob@nada.kth.se Cc: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-dv-video-00.txt In-Reply-To: References: <199906291120.HAA08367@ietf.org> X-Mailer: Mew version 1.94b37 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <19990702234942L.ikob@koganei.wide.ad.jp> Date: Fri, 02 Jul 1999 23:49:42 +0900 From: ikob X-Dispatcher: imput version 990623(IM117) Lines: 125 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks for your comments, = From: Tobias =D6brink Subject: Re: I-D ACTION:draft-ietf-avt-dv-video-00.txt Date: Wed, 30 Jun 1999 19:11:57 +0200 (MET DST) Message-ID: = nv91-tob> = nv91-tob> In section 4.1 RTP header usage: nv91-tob> = nv91-tob> Timestamp: 32-bit 90 kHz timestamp representing the time at= which nv91-tob> the first data in the frame was sampled. = nv91-tob> = nv91-tob> This statement may lead to the conclusion that the sampling ti= me for nv91-tob> the first frame (maybe obtained from the CIP header as nv91-tob> described in appendix A) should be used as the initial value o= f the nv91-tob> timestamp field. To avoid unneccessary confusion I would like = to add nv91-tob> the following paragraph from the new RTP draft: nv91-tob> = nv91-tob> The initial value of the timestamp SHOULD be random, as for= the nv91-tob> sequence number. nv91-tob> = We will mention the initial timestamp value issue in the next ID. nv91-tob> = nv91-tob> In section 4.2 DV data encapsulation into RTP payload: nv91-tob> = nv91-tob> Therefore, if VAUX/AAUX information is not nv91-tob> transmitted in the stream, the equivalent parameters essent= ial to nv91-tob> playout MUST be provided by some out of band means beyond t= he nv91-tob> scope of this document. nv91-tob> : nv91-tob> : nv91-tob> : nv91-tob> Therefore, if the RTP receiver nv91-tob> is feeding the DV stream to a device that requires AAUX nv91-tob> information and VAUX DIF blocks, the receiver MUST be able = to nv91-tob> generate AAUX within audio DIF blocks and VAUX DIF blocks f= or the nv91-tob> device using the parameters provided out of band. nv91-tob> = nv91-tob> I interpret this as, to comply with the spec, the receiver nv91-tob> implementation MUST retrieve, by some unknown out-of-band-mech= anism, nv91-tob> the information needed to recreate the VAUX and AAUX DIF block= s. = nv91-tob> If that's the case won't we end up with non-interoperable nv91-tob> implementations using proprietary out-of-band-mechanisms? = nv91-tob> Maybe we should at least state a default out-of-band-mechanism= as a nv91-tob> minimal requirement that have to be used by all implementation= s. The nv91-tob> dynamic payload type assignment using SDP in section 5 comes t= o mind. nv91-tob> = Does the comment mean you think the profile document should assume the default out-of-band session description mechanism ? = nv91-tob> = nv91-tob> In section 5.2 SDP description for bundled stream: = nv91-tob> = nv91-tob> The audio format parameter seems quite detailed. How to find o= ut the = nv91-tob> values for those parameters if you're about to announce a sess= ion in nv91-tob> sdr or writing a SDP-file for a program that haven't yet start= ed? Do you think RTP session can be started with an insufficient session description information or without the session description ? Or you think the draft should describes as: The host must not start RTP session without the sufficient session information exchange. = nv91-tob> Aren't there any standardized combinations of those nv91-tob> parameters? = nv91-tob> At least , and the number of cha= nnels = nv91-tob> only can occur in a few different combinations. nv91-tob> Maybe the same applies to some of the other parameters as well= ? nv91-tob> = Blue book (DV specification) offers some limited combinations as "basic standard". But, I think the payload description should be designe= d that will accord any combination of coding parameters. ikob@koganei.wide.ad.jp From rem-conf Fri Jul 02 07:55:56 1999 From rem-conf-request@es.net Fri Jul 02 07:55:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1104jB-0007Qc-00; Fri, 2 Jul 1999 07:55:45 -0700 Received: from motgate2.mot.com [129.188.136.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 1104jA-0007QL-00; Fri, 2 Jul 1999 07:55:44 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id JAA13990 for ; Fri, 2 Jul 1999 09:56:49 -0500 (CDT)] Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA11242 for ; Fri, 2 Jul 1999 09:55:39 -0500 (CDT)] Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2580.0) id ; Fri, 2 Jul 1999 09:55:32 -0500 Message-ID: <57B7E404C641D211A39A0008C7A4FBA702746F@s-il02-q.comm.mot.com> From: Avasthi Pradeep-CCOF59 To: rem-conf@es.net Subject: remove rem-conf@es.net [ccof59@email.mot.com] Date: Fri, 2 Jul 1999 09:55:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe rem-conf@es.net [ccof59@email.mot.com] remove rem-conf@es.net [ccof59@email.mot.com] From rem-conf Fri Jul 02 12:26:05 1999 From rem-conf-request@es.net Fri Jul 02 12:26:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1108t7-0002LX-00; Fri, 2 Jul 1999 12:22:17 -0700 Received: from evl.evl.uic.edu (evl.uic.edu) [131.193.48.80] by mail1.es.net with smtp (Exim 1.81 #2) id 1108t6-0002LN-00; Fri, 2 Jul 1999 12:22:16 -0700 Received: from JJLAPTOP.reston.mci.net ([166.45.18.34]) by evl.uic.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id OAA02433; Fri, 2 Jul 1999 14:21:40 -0500 Message-Id: <199907021921.OAA02433@evl.uic.edu> X-Sender: jj@evl.uic.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 02 Jul 1999 15:18:54 -0400 To: a00khl00@nchc.gov.tw From: John Jamison Subject: Re: request for Mbone feed Cc: Markus Buchhorn , Jan-Ming Ho , rem-conf@es.net, jj@startap.net, Sheng-Hsiung Huang , chinfu@iis.sinica.edu.tw, Chia-Hui Wang , Lih-Hsiang Chen , feng@iis.sinica.edu.tw, Kenny Huang , kthomp@mci.net In-Reply-To: <377734C5.B4CC3BB2@sinica.edu> References: <3.0.32.19990628160524.0099a8b0@acsys.anu.edu.au> 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 Ken, The STAR TAP is planning on setting up an IPv4 service later this month and should have a multicast service up and running latter this summer. Your best bet is to get a multicast feed from the vBNS now and when the STAR TAP router's multicast service is up and running you can cut over. I have spoken to Kevin Thompson (kthomp@mci.net) about this and he is more than happy to work with you to set up multicast peering beteen TANnet and vBNS. Please contact Kevin via email at: kthomp@mci.net. Regards, JJ At 04:39 PM 6/28/99 +0800, Kenny Huang wrote: >Dear ALL and JJ, > >I met JJ at the STARTAP Advisory Committee and briefed the mbone >issue to him already. Ken Lin at NCHC (a00khl00@nchc.gov.tw) will >be the primary contact in Taiwan. Please contact Ken Lin for=20 >mbone implementation, and keep me in the communication loop. > >Regards > >--=20 > Kenny Huang =B6=C0=B3=D3=B6=AF Tel= 886-2-2789-9492 > Head, Communication & Network Services Fax 886-2-2783-6444 > Academia Sinica huangk@sinica.edu.tw > http://www.sinica.edu.tw > > > >Markus Buchhorn wrote: >>=20 >> At 09:19 21/06/99 +0800, Jan-Ming Ho wrote: >> > >> >We are representing Taiwan to seek for Mbone feed to our Academic= Network, >> >Taiwan Academic Network, or TANET for short. We had long been suffering >> >a low bandwidth connecting to international internet traffic. But, we >> >recently upgrade our connection to the US by a T3 lease line. We >> >appreciate it very much if we could have any institute here to provide >> >us with permanent MBONE feed. We will run a permanent mbone root for >> >the academic family including universities in Taiwan. We are also >> >willing to transit this MBONE traffic to nearby countries based on the >> >availability of physical connections and bandwidth. >>=20 >> Since Taiwan/TANet now has a direct connection to the STARTAP in Chicago >> I'd suggest getting an MBONE feed from there - contact John Jamison >> (jj@startap.net), who may or may not be the right person, (sorry John!= :-)) >> but should be able to point you to the right person. APAN and SingaREN= also >> get their MBONE feeds off the vBNS through STARTAP. >>=20 >> Cheers, >> Markus >>=20 >> >Jan-Ming Ho, PhD >> >Associate Editor, IEEE Transaction on Multimedia >> >Research Fellow (O) 886-2-2788-3799 x1803 >> >IIS, Academis Sinica (F) 886-2-2788-3799 x1606, = 886-2-2782-4814 >> >Nankang, Taipei email: hoho@iis.sinica.edu.tw >> >Taiwan URL: = http://www.iis.sinica.edu.tw/~hoho >> > http://www.iis.sinica.edu.tw/CCL >> > http://twstudy.sinica.edu.tw >> > >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D >> > >> > >> > >> > >> > >> Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 >> email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 >> Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 >=20 From rem-conf Fri Jul 02 12:38:03 1999 From rem-conf-request@es.net Fri Jul 02 12:38:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11096N-0002zm-00; Fri, 2 Jul 1999 12:35:59 -0700 Received: from (ismailia.ie-eg.com) [194.79.119.18] by mail1.es.net with smtp (Exim 1.81 #2) id 11096M-0002zZ-00; Fri, 2 Jul 1999 12:35:58 -0700 Received: from aaa [193.227.12.41] by ismailia.ie-eg.com (SMTPD32-4.06) id A57341101C0; Fri, 02 Jul 1999 22:39:31 +0200 Message-ID: <000b01bec4c3$247ea920$290ce3c1@aaa.ie-eg.com> From: "Tamer Ragab" To: Subject: Date: Fri, 2 Jul 1999 21:22:27 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01BEC4D0.FBE84EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.37 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.37 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_002E_01BEC4D0.FBE84EE0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Dear Sir/Madam I have the pleasure to introduce myself Name : Tamer M.Ragab Present Occupation : Demonstrator at Faculty of Education,Suez Canal = University=20 El-Arish, EGYPT Qualification : B. Sc. in Math & Computer Science (1996) ,Science = Faculty Interests : Distance Learning I kindly ask you if I could get more details about the Distance Learning = program you offer=20 Hoping to hear from you as soon as possible Thanking you in advance My e-mail : Tamer00@hotmail.com ------=_NextPart_000_002E_01BEC4D0.FBE84EE0 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam
I = have the pleasure=20 to introduce myself
Name : Tamer M.Ragab
Present Occupation : = Demonstrator=20 at Faculty of Education,Suez Canal University
El-Arish,=20 EGYPT
Qualification : B. Sc. in Math & Computer Science (1996) = ,Science=20 Faculty
Interests : Distance Learning
I kindly ask you if I could = get more=20 details about the Distance Learning program you offer
Hoping to hear = from=20 you as soon as possible
Thanking you in advance
My e-mail : Tamer00@hotmail.com
 
 
------=_NextPart_000_002E_01BEC4D0.FBE84EE0-- From rem-conf Fri Jul 02 14:24:42 1999 From rem-conf-request@es.net Fri Jul 02 14:24:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 110Akl-0004tV-00; Fri, 2 Jul 1999 14:21:47 -0700 Received: from mumrik.nada.kth.se [130.237.226.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 110Aki-0004tL-00; Fri, 2 Jul 1999 14:21:44 -0700 Received: from localhost (nv91-tob@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id XAA06725; Fri, 2 Jul 1999 23:21:23 +0200 (MET DST) Date: Fri, 2 Jul 1999 23:21:23 +0200 (MET DST) From: =?ISO-8859-1?Q?Tobias_=D6brink?= To: ikob cc: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-dv-video-00.txt In-Reply-To: <19990702234942L.ikob@koganei.wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mumrik.nada.kth.se id XAA06725 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 2 Jul 1999, ikob wrote: > From: Tobias =D6brink > > nv91-tob> In section 4.2 DV data encapsulation into RTP payload: > nv91-tob>=20 > nv91-tob> Therefore, if VAUX/AAUX information is not > nv91-tob> transmitted in the stream, the equivalent parameters essen= tial to > nv91-tob> playout MUST be provided by some out of band means beyond = the > nv91-tob> scope of this document. > nv91-tob> : > nv91-tob> : > nv91-tob> : > nv91-tob> Therefore, if the RTP receiver > nv91-tob> is feeding the DV stream to a device that requires AAUX > nv91-tob> information and VAUX DIF blocks, the receiver MUST be able= to > nv91-tob> generate AAUX within audio DIF blocks and VAUX DIF blocks = for the > nv91-tob> device using the parameters provided out of band. > nv91-tob>=20 > nv91-tob> I interpret this as, to comply with the spec, the receiver > nv91-tob> implementation MUST retrieve, by some unknown out-of-band-mec= hanism, > nv91-tob> the information needed to recreate the VAUX and AAUX DIF bloc= ks.=20 > nv91-tob> If that's the case won't we end up with non-interoperable > nv91-tob> implementations using proprietary out-of-band-mechanisms?=20 > nv91-tob> Maybe we should at least state a default out-of-band-mechanis= m as a > nv91-tob> minimal requirement that have to be used by all implementatio= ns. The > nv91-tob> dynamic payload type assignment using SDP in section 5 comes = to mind. > nv91-tob>=20 >=20 > Does the comment mean you think the profile document should assume the > default out-of-band session description mechanism ? I don't want to change anything in the RTP audio/video profile, but I think there should be a default out-of-band mechanism specified in=20 the payload specification document. According to the RTP audio/video profile there are two main mechanisms for dynamic payload type assignment, so I agree it's not a good idea to force all DV payload implementations to use one of them.=20 > nv91-tob>=20 > nv91-tob> In section 5.2 SDP description for bundled stream:=20 > nv91-tob>=20 > nv91-tob> The audio format parameter seems quite detailed. How to > nv91-tob> find out the values for those parameters if you're about > nv91-tob> to announce a session in sdr or writing a SDP-file for a > nv91-tob> program that haven't yet started? >=20 > Do you think RTP session can be started with an insufficient session > description information or without the session description ? > Or you think the draft should describes as: >=20 > The host must not start RTP session without the sufficient session > information exchange. Only in the case "when the RTP receiver is feeding the DV stream to a device that requires AAUX information and VAUX DIF blocks, because=20 then the receiver MUST be able to generate AAUX within audio DIF blocks and VAUX DIF blocks for the device. I don't know how to do that without getting all the parameters (that I assume is a part of the session information). Since there's a MUST in there, I'd also like to have a default out-of-band mechanism to turn to to get those parameters from, but it's not necessary ofcourse. In other cases I see no problem to start a RTP session complying with the current draft RTP payload specification for DV format video, without sufficient session information (i.e. relying on default parameters if we can agree on a set of them). Also, if I know that the sender doesn't omit VAUX and AAUX information I don't need to generate AAUX and VAUX and I won't need any out-of-band mechanism other than for the usual RTP/UDP/IP parameters (address, port, payload type, ttl,...). > nv91-tob> Aren't there any standardized combinations of those > nv91-tob> parameters?=20 > nv91-tob> At least , and the number of ch= annels=20 > nv91-tob> only can occur in a few different combinations. > nv91-tob> Maybe the same applies to some of the other parameters as wel= l? >=20 > Blue book (DV specification) offers some limited combinations as > "basic standard". But, I think the payload description should be design= ed > that will accord any combination of coding parameters. I respect that. Does those "basic standard" combinations include values on language, audio mode et.c.?=20 /Tobias .........................................................................= ... Tobias =D6brink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: tobias@it.kth.se URL: http://www.it.kth.se/~nv91-tob/ See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html From rem-conf Fri Jul 02 15:39:18 1999 From rem-conf-request@es.net Fri Jul 02 15:39:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 110BtP-00064o-00; Fri, 2 Jul 1999 15:34:47 -0700 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 110BtM-00064e-00; Fri, 2 Jul 1999 15:34:45 -0700 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id SAA10449 for ; Fri, 2 Jul 1999 18:34:43 -0400 (EDT) Message-ID: <377D6B3B.8C3A10A9@comet.columbia.edu> Date: Fri, 02 Jul 1999 18:45:31 -0700 From: "Andrew T. Campbell" Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: MOMUC99 CFP: Submission deadline fast approaching Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sirius.ctr.columbia.edu id SAA10449 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues: Please find attached the 2nd CFP for the 6th IEEE*=20 International Workshop on Mobile Multimedia=20 Communications (MOMUC99), November 15-17, 1999 http://cwc.ucsd.edu/momuc99/ Please note that the submission deadline is fast approaching: Full papers are due *July 25*, 1999 Position papers are due: September 1, 1999 MOMUC99 will be held in San Diego, a city with=20 vibrant wireless industries; it follows the very successful=20 and interactive workshops held in Tokyo '93, Bristol '95,=20 Princeton '96, Seoul'97, and Berlin' 98. =20 Join us for this exiting event! --=20 Andrew http://comet.columbia.edu/~campbell 2nd CALL FOR PAPERS AND DEMOS 6th IEEE* International Workshop on Mobile Multimedia Communications=20 =20 MOMUC99 http://cwc.ucsd.edu/momuc99/ November 15-17, 1999 =20 Hyatt Islandia on=20 San Diego's Mission Bay San Diego, California Sponsored by IEEE Communications Society*=20 Technical Committees on Computer Communications=20 Multimedia Communications=20 Internet and Personal Communications=20 In co-operation with the=20 ACM SIGCOMM*, ACM SIGMOBILE*=20 Center for Wireless Communications,=20 University of California, San Diego and the=20 Center for Telecommunications Research,=20 Columbia University =20 Objectives The Sixth IEEE* International Workshop on Mobile Multimedia=20 Communications (MOMUC'99) will provide an international forum=20 for the discussion of research in wireless and mobile multimedia=20 communications. The workshop, to be held in San Diego, a city with=20 vibrant wireless industries, will bring together researchers,=20 developers and practitioners working in all facets of advanced=20 mobile multimedia communications. The scope of MOMUC'99 will=20 include broadband wireless networking for data and multimedia,=20 mobile multimedia systems and applications together with associated=20 mobile computing devices, video processing and enabling software=20 technologies.=20 In the past the workshop has been cross-disciplinary, small and=20 well focused, consisting of keynote speakers, panels and solicited contributions with the emphasis on innovation. As a result, a=20 considerable amount of time is devoted to informal discussion. The Sixth IEEE International Workshop on Mobile Multimedia=20 Communications will be limited to 150 participants.=20 Previous events include: Tokyo '93, Bristol '95, Princeton '96, Seoul '97, and Berlin' 98.=20 Best student paper prize of $500 from=20 C&C Research Laboratories, NEC USA=20 Scope Authors are invited to submit previously unpublished full research=20 papers, short position papers and outlines for demonstration prototypes.=20 Suggested focus areas include:=20 =B7 High-speed wireless modem and radio techniques=20 =B7 Medium access/data link control=20 =B7 Handoff signaling systems=20 =B7 Power management issues=20 =B7 Wireless network management & service control=20 =B7 Signal processing techniques=20 =B7 Software radios=20 =B7 Next generation mobile Internet=20 =B7 Multimedia satellite communications=20 =B7 Mobile multimedia ad hoc networks=20 =B7 Advances in cellular systems=20 =B7 Piconet technologies =B7 Quality of Service in wireless and mobile networks =B7 Experimental systems=20 =B7 Mobile computing devices=20 =B7 Internetworking of wired and wireless networks =B7 Mobile multimedia applications and platforms =B7 Distributed systems and mobile multimedia communications =B7 Adaptive mobile systems =B7 Enabling software technologies for mobile systems=20 =B7 Programmable and active mobile networks=20 =B7 Wireless transport services and protocols=20 =B7 Video compression, including MPEG-4=20 =B7 Mobile agent technology Submissions We request authors to submit their draft papers in electronic=20 format. Accepted full papers and position papers will=20 be published by IEEE as workshop proceedings.=20 Full papers due: July 25, 1999.=20 Position papers due: September 1, 1999.=20 Notification of acceptance: September 13, 1999.=20 Camera Ready Due: October 1, 1999=20 Full papers are limited to 25 pages=20 (11 pt. fonts and double space). Position papers are limited to 3 pages=20 (11 pt. fonts and single space).=20 If electronic submission is not possible, please follow the=20 instructions at the end of this page. =20 The submission procedure requires that (a) you send your=20 complete draft paper by ftp and (b) you send the cover page=20 information accompanying your submission by e-mail to=20 momuc99@comet.columbia.edu.=20 Please read all instructions on this page before=20 attempting a submission. =20 -Draft Paper Format Your paper must consist of one single file,=20 including the figures. When preparing the document, please use common fonts and, if possible,=20 US letter page format to facilitate the printing. =20 The following file formats are being accepted: Postscript (PS),=20 Portable Document Format (PDF), and MS Word.=20 Compression of the postscript files using the compress=20 or gzip commands is advisable. =20 -Draft Paper Naming Scheme =20 When transferring the file to our host use the=20 following naming scheme: =20 _..[.gz | .Z]=20 Examples: =20 Smith_Adam.1205.ps (Postscript file transferred at 12:05 your time) =20 Smith_Adam.2012.ps.gz (gzip-compressed Postscript file transferred at 20:12) =20 Smith_Adam.0747.pdf (PDF file transferred at 7:47 your time) =20 Smith_Adam.0841.doc (MS Word file transferred at 8:41 your time) =20 -Submitting the Draft Paper=20 Transfer your draft paper to our server=20 (ftp.comet.columbia.edu) using anonymous ftp as follows: =20 1.ftp ftp.comet.columbia.edu=20 2.enter anonymous as user name=20 3.enter as password=20 4.cd pub/momuc/incoming=20 5.binary=20 6.put =20 7.quit=20 Note that the directory pub/momuc/incoming is write only=20 (i.e., it cannot be listed). =20 -Preparing the Cover Page=20 Prepare a cover page in plain text (ASCII) containing=20 he following information: =20 Managing author's name, affiliation, postal=20 address, phone number, fax number, e-mail address=20 Paper Title=20 Name and affiliation of author(s)=20 Keywords=20 Format of the submitted paper (Postscript, PDF, etc.)=20 Statement, if you would like to participate in the=20 contention for the best student paper award.=20 -Submitting the Cover Page =20 Send the cover page accompanying your submission by e-mail to=20 momuc99@comet.columbia.edu. =20 - If Electronic Submission is not Possible =20 In case electronic submission is not possible,=20 authors should send six copies of their draft paper to : =20 Andrew T. Campbell MOMUC99=20 Department of Electrical Engineering and Center for Telecommunications Research=20 1312 Seeley W. Mudd Bldg. Columbia University, New York, NY 10025-6699, USA=20 campbell@comet.columbia.edu Workshop Committee Steering Committee: D. Goodman (Rutgers University) D. Raychaudhuri (NEC, Princeton) H. Tominaga (Waseda University Tokyo) =20 General Chair: =20 Anthony Acampora (UC San Diego) Program Co-Chairs: Andrew T. Campbell (Columbia University) George C. Polyzos (UC San Diego) Program Committee: Yoshihiko Akaiwa (Kyushu University) B. R. Badrinath (Rutgers) Victor Bahl (Microsoft Research) Hari Balakrishnan (MIT) Vaduvur Bharghavan (UIUC) Giuseppe Bianchi (Palermo University) Kalyan Basu (Nortel Networks) Ernst Bonek (TU Wien) Shih-Fu Chang (Columbia University) Franco Davoli (U. di Genoa) Julio Escobar, (Senacyt) James Freebersyser (ONR) Mario Gerla (UCLA)=20 Zygmunt Haas (Cornell University) Jon Inoyue (Intel) Rajeev Jain (UCLA) Anthony Joseph (UC Berkeley) Gunnar Karlsson (Royal Inst. of Tech.) Mark Karol (Lucent) K. S. Kwak (University Seoul) Khiem Le (Nokia) Petri Mahonen (VTT) Gerald Maguire (KTH Stockholm) Maximilian Ott (NEC) Steve Pink (Lulea University) Tom La Porta (Lucent) Albert Stienstra (Phillips) Masahiro Umehira (NTT) Adam Wolisz (TU Berlin) Local Organization Committee: Michael Kounavis and Javier Gomez, Columbia University Carol K. Tohsaku, San Diego State University Correspondence momuc99@comet.columbia.edu =20 Location IEEE MOMUC99 will be held in the Hyatt Islandia on San Diego's Mission Bay (*pending) From rem-conf Fri Jul 02 20:12:20 1999 From rem-conf-request@es.net Fri Jul 02 20:12:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 110GAQ-0000j0-00; Fri, 2 Jul 1999 20:08:38 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 110GAP-0000ig-00; Fri, 2 Jul 1999 20:08:37 -0700 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA19367; Fri, 2 Jul 1999 20:07:35 -0700 (PDT) Date: Fri, 2 Jul 1999 20:07:32 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Last call on draft-ietf-avt-rtp-format-guidelines-03.txt Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The the AVT working group: In April, after the Minneapolis meeting, there was a two-week working group last call on draft-ietf-avt-rtp-format-guidelines-01.txt for publication as Best Current Practice. No comments were received, but the draft did not include the required Security Considerations section. The draft has been revised to include that: Title : Guidelines for Writers of RTP Payload Format Specifications Author(s) : M. Handley, C. Perkins Filename : draft-ietf-avt-rtp-format-guidelines-03.txt,.ps Pages : 9 Date : 01-Jul-99 (Not sure what happened to -02, and the .ps wasn't there when I looked, but never mind.) To give time for comments on the Security Considerations section, the working group last call will continue until our meeting in Oslo on July 14. If there are no objections, the request for IESG Last Call for publication as BCP will be issued from Oslo. -- Steve From rem-conf Sat Jul 03 18:56:05 1999 From rem-conf-request@es.net Sat Jul 03 18:56:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 110bAd-0002Bh-00; Sat, 3 Jul 1999 18:34:15 -0700 Received: from badlands.nodak.edu [134.129.111.66] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 110bAc-0002BX-00; Sat, 3 Jul 1999 18:34:14 -0700 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 UAA30430; Sat, 3 Jul 1999 20:09:31 -0500 Message-Id: <3.0.3.32.19990703201023.006a0d68@badlands.nodak.edu> X-Sender: msyed@badlands.nodak.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 03 Jul 1999 20:10:23 -0500 To: "MMC7@IRMA.Anchorage":; From: Mahbubur Syed Subject: Multimedia Computing and Information Management - CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_931068623==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_931068623==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague: My apologies if you received this email more than once. Please find attached a call for paper. I am also attching a pdf version of the CFP. It will be highly appreciated, if you take the trouble also to circulate among interested faculty and your network. Best Regards. Thanks. Syed M Rahman *****CALL FOR PAPERS************ MULTIMEDIA COMPUTING (MMC) track IRMA 2000 International Conference May 21-24, 2000 at Anchorage Hilton Hotel Anchorage, Alaska, USA ***TRACK CHAIR*** Syed Mahbubur Rahman Department of Electrical and Computer Engineering, North Dakota State University, Fargo, USA (On secondment from Gippsland School of Computing and Information Technology, Monash University, Australia.) Email: msyed@badlands.nodak.edu, syed.rahman@infotech.monash.edu.au ***TRACK URL*** For details please visit the following URL: http://www.ece.ndsu.nodak.edu/~msyed/irmamm/index.html ***IMPORTANT DATES*** Submission Deadline October 8, 1999 Notification of Acceptance/Rejection November 19, 1999 Final Submission Due January 14, 2000 Early Registration Ends April 3, 2000 ***TOPICS*** Multimedia technology has the potential to evolve the paradigm of end user computing, from the interactive text and graphics model that has developed since 1950s, into one more compatible with the digital electronic world of the next century. This track will present papers and panels designed to help professionals gain an understanding and perspective on MMC. The Multimedia Computing Track encourages the submission of quality papers and panel workshop proposals dealing with (but not limited to) the following topics: * Multimedia-specific technologies (e.g., DVI, CD-I, JPEG, MPEG) * Multimedia platforms and peripherals * Multimedia and communications (e.g., WAN, LAN, ISDN, fibre optics) * Graphics, audio, and video hardware and software technologies * Operating systems * Authoring tools, languages * Design and development (software engineering, CASE, multi/cross platform consideration) * Media preparation and integration * Research issues (interface design, end user performance, etc.) * MMC and information systems * Training and education issues related to MMC * MMC applications (e.g., commercial, home, entertainment, etc.) * Issues concerned with legal, copyright, standard matters * Related emerging technologies (e.g., HDTV, parallel processing, virtual systems, hypermedia) * Global issues (e.g., development, distribution, manufacturing, etc.) ***SUBMISSION CATEGORIES*** # Full Length Submissions # Reaseach-in-progress Submission # Panel, Workshop, Tutorial and symposium submissions Please visit Track URL for more detail information ***SUBMISSION GUIDELINES*** # Manuscript must not exceed 4000 words for full length submissions; 500-1000 words for research-in-progress summary/proposal; and 1000-2000 words for panel, workshop, tutorial and symposium proposals. # Must be accompanied by a separate cover letter with the title 'SUBMISSION FOR MULTIMEDIA TRACK', EVERY AUTHOR(S) NAME, ADDRESS, TEL. AND FAX NUMBERS, E-MAIL AND FULL AFFILIATION. All correspondence will be sent to the first author unless otherwise specified. # Submitted papers must not currently be under review by any other publication or conference. # Submitters must provide their e-mail address where the acknowledgment will be forwarded. # The number of submissions by an author (including joint authorship) is limited to a maximum of two submissions. # All submissions should be submitted electronically in either MS Word '97 or rich text format (RTF). (Note: If you do not receive an e-mail acknowledgment one week after your electronic submissions, please contact the program chair. submissions (indicate MULTIMEDIA COMPUTING Track in your submission) to: Mehdi Khosrowpour, Program Chair 2000 IRMA INTERNATIONAL CONFERENCE 1331 E. Chocolate Avenue, Hershey, PA 17033-1117, U.S.A. Tel: (717) 533-8879 * Fax: (717) 533-8661 Email: mehdi@irma-international.org --=====================_931068623==_ Content-Type: application/msword; name="IRMAcall1.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IRMAcall1.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOQAAAAAAAAAA EAAAOwAAAAEAAAD+////AAAAADgAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAAFR8AAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAMDAAABZBAQAWQQEAEhsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAMwCAAAAAAAAzAIAAMwC AAAAAAAAzAIAAAAAAAAcAwAAAAAAABwDAAAAAAAAHAMAABQAAAAAAAAAAAAAADADAAAAAAAAMAMA AAAAAAAwAwAAAAAAADADAAAAAAAAMAMAABwAAABMAwAAJAAAADADAAAAAAAAxhcAACwCAAB8AwAA AAAAAHwDAAAAAAAAfAMAAAAAAAB8AwAAAAAAAHwDAAAAAAAAPwgAAAAAAAA/CAAAAAAAAD8IAAAA AAAA4xQAAAIAAADlFAAAAAAAAOUUAAAAAAAA5RQAAGgAAABNFQAAIAEAAG0WAAAgAQAAjRcAACQA AADyGQAA9AEAAOYbAAC8AAAAsRcAABUAAAAAAAAAAAAAAAAAAAAAAAAAHAMAAAAAAAA/CAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAtBwAAEgEAAD8IAAAAAAAAPwgAAAAAAAA/CAAAAAAAALEXAAAAAAAA pwgAAAAAAADMAgAAAAAAAMwCAAAAAAAAfAMAAAAAAAAAAAAAAAAAAHwDAACxAwAAfAMAAAAAAACn CAAAAAAAAKcIAAAAAAAApwgAAAAAAAA/CAAANAAAAMwCAAA4AAAAfAMAAAAAAAAcAwAAAAAAAHwD AAAAAAAA4xQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAMAAAAAAAAwAwAAAAAAAMwCAAAAAAAAzAIA AAAAAADMAgAAAAAAAMwCAAAAAAAAPwgAAAAAAADjFAAAAAAAAKcIAADmBQAApwgAAAAAAACNDgAA igEAAGoTAABXAQAABAMAABgAAAAcAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4xQAAAAAAAB8AwAAAAAAAHADAAAMAAAAIDf8q7/B vgEwAwAAAAAAADADAAAAAAAAcwgAADQAAADBFAAAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACENB TEwgRk9SIFBBUEVSUw0NU3VibWlzc2lvbiBEZWFkbGluZTogT2N0b2JlciA4LCAxOTk5DQ0IDU11 bHRpbWVkaWEgQ29tcHV0aW5nIChNTUMpDVRyYWNrIG9mDTIwMDAgSW5mb3JtYXRpb24gUmVzb3Vy Y2VzIE1hbmFnZW1lbnQgQXNzb2NpYXRpb24gSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlDQ1NYXkg MjEtMjQsIDIwMDANYXQgQW5jaG9yYWdlIEhpbHRvbiBIb3RlbCANQW5jaG9yYWdlLCBBbGFza2Es IFVTQQ0NCFRSQUNLIENIQUlSDSANU3llZCBNYWhidWJ1ciBSYWhtYW4NRGVwYXJ0bWVudCBvZiBF bGVjdHJpY2FsIGFuZCBDb21wdXRlciBFbmdpbmVlcmluZywgTm9ydGggRGFrb3RhIFN0YXRlIFVu aXZlcnNpdHksIEZhcmdvLCBVU0ENKE9uIHNlY29uZG1lbnQgZnJvbSBHaXBwc2xhbmQgU2Nob29s IG9mIENvbXB1dGluZyBhbmQgSW5mb3JtYXRpb24gVGVjaG5vbG9neSwgTW9uYXNoIFVuaXZlcnNp dHksIEF1c3RyYWxpYS4pDUVtYWlsOiBtc3llZEBiYWRsYW5kcy5ub2Rhay5lZHUsIHN5ZWQucmFo bWFuQGluZm90ZWNoLm1vbmFzaC5lZHUuYXUNCA1UUkFDSyBDT1ZFUkFHRQ0NTXVsdGltZWRpYSB0 ZWNobm9sb2d5IGhhcyB0aGUgcG90ZW50aWFsIHRvIGV2b2x2ZSB0aGUgcGFyYWRpZ20gb2YgZW5k IHVzZXIgY29tcHV0aW5nLCBmcm9tIHRoZSBpbnRlcmFjdGl2ZSB0ZXh0IGFuZCBncmFwaGljcyBt b2RlbCB0aGF0IGhhcyBkZXZlbG9wZWQgc2luY2UgMTk1MHMsIGludG8gb25lIG1vcmUgY29tcGF0 aWJsZSB3aXRoIHRoZSBkaWdpdGFsIGVsZWN0cm9uaWMgd29ybGQgb2YgdGhlIG5leHQgY2VudHVy eS4gVGhpcyB0cmFjayB3aWxsIHByZXNlbnQgcGFwZXJzIGFuZCBwYW5lbHMgZGVzaWduZWQgdG8g aGVscCBwcm9mZXNzaW9uYWxzIGdhaW4gYW4gdW5kZXJzdGFuZGluZyBhbmQgcGVyc3BlY3RpdmUg b24gTU1DLg0IDVJFQ09NTUVOREVEIFRPUElDUw0NVGhlIE11bHRpbWVkaWEgQ29tcHV0aW5nIFRy YWNrIGVuY291cmFnZXMgdGhlIHN1Ym1pc3Npb24gb2YgcXVhbGl0eSBwYXBlcnMgYW5kIHBhbmVs IHdvcmtzaG9wIHByb3Bvc2FscyBkZWFsaW5nIHdpdGggKGJ1dCBub3QgbGltaXRlZCB0bykgdGhl IGZvbGxvd2luZyB0b3BpY3M6DQ1NdWx0aW1lZGlhLXNwZWNpZmljIHRlY2hub2xvZ2llcyAoZS5n LiwgRFZJLCBDRC1JLCBKUEVHLCBNUEVHKQ1NdWx0aW1lZGlhIHBsYXRmb3JtcyBhbmQgcGVyaXBo ZXJhbHMNTXVsdGltZWRpYSBhbmQgY29tbXVuaWNhdGlvbnMgKGUuZy4sIFdBTiwgTEFOLCBJU0RO LCBmaWJyZSBvcHRpY3MpDUdyYXBoaWNzLCBhdWRpbywgYW5kIHZpZGVvIGhhcmR3YXJlIGFuZCBz b2Z0d2FyZSB0ZWNobm9sb2dpZXMNT3BlcmF0aW5nIHN5c3RlbXMNQXV0aG9yaW5nIHRvb2xzLCBs YW5ndWFnZXMNRGVzaWduIGFuZCBkZXZlbG9wbWVudCAoc29mdHdhcmUgZW5naW5lZXJpbmcsIENB U0UsIG11bHRpL2Nyb3NzIHBsYXRmb3JtIGNvbnNpZGVyYXRpb24pDU1lZGlhIHByZXBhcmF0aW9u IGFuZCBpbnRlZ3JhdGlvbgdSZXNlYXJjaCBpc3N1ZXMgKGludGVyZmFjZSBkZXNpZ24sIGVuZCB1 c2VyIHBlcmZvcm1hbmNlLCBldGMuKQ1NTUMgYW5kIGluZm9ybWF0aW9uIHN5c3RlbXMNVHJhaW5p bmcgYW5kIGVkdWNhdGlvbiBpc3N1ZXMgcmVsYXRlZCB0byBNTUMNTU1DIGFwcGxpY2F0aW9ucyAo ZS5nLiwgY29tbWVyY2lhbCwgaG9tZSwgZW50ZXJ0YWlubWVudCwgZXRjLikNSXNzdWVzIGNvbmNl cm5lZCB3aXRoIGxlZ2FsLCBjb3B5cmlnaHQsIHN0YW5kYXJkIG1hdHRlcnMNUmVsYXRlZCBlbWVy Z2luZyB0ZWNobm9sb2dpZXMgKGUuZy4sIEhEVFYsIHBhcmFsbGVsIHByb2Nlc3NpbmcsIHZpcnR1 YWwgc3lzdGVtcywgaHlwZXJtZWRpYSkNR2xvYmFsIGlzc3VlcyAoZS5nLiwgZGV2ZWxvcG1lbnQs IGRpc3RyaWJ1dGlvbiwgbWFudWZhY3R1cmluZywgZXRjLikHBwgNSU1QT1JUQU5UIERBVEVTDQ0N U3VibWlzc2lvbiBEZWFkbGluZSAJCQkJCU9jdG9iZXIgOCwgCQkxOTk5DU5vdGlmaWNhdGlvbiBv ZiBBY2NlcHRhbmNlL1JlamVjdGlvbgkJCU5vdmVtYmVyIDE5LAkJMTk5OQ1GaW5hbCBTdWJtaXNz aW9uIER1ZQkJCQlKYW51YXJ5IDE0LCAJCTIwMDANRWFybHkgUmVnaXN0cmF0aW9uIEVuZHMJCQkJ QXByaWwgMywgCQkyMDAwDQ1BbGwgY29uZmVyZW5jZSBwYXJ0aWNpcGFudHMgKHByZXNlbnRlcnMs IHBhbmVsaXN0cywgZXRjKSBtdXN0IHJlZ2lzdGVyIGZvciB0aGUgY29uZmVyZW5jZS4NDQgNU1VC TUlTU0lPTiBDQVRFR09SSUVTDQ0oVG9wIG9mIHRoZSBjb3ZlciBwYWdlIHNob3VsZCBjb250YWlu IFNVQk1JU1NJT04gRk9SIE1VTFRJTUVESUEgVFJBQ0sgYXMgYSBoZWFkaW5nKQ0NRlVMTCBMRU5H VEggU1VCTUlTU0lPTlMtIFRob3NlIGluZGl2aWR1YWxzIGludGVyZXN0ZWQgbWF5IHN1Ym1pdCBh IGZ1bGwgbGVuZ3RoIChub3QgdG8gZXhjZWVkIDQwMDAgd29yZHMpLCBvcmlnaW5hbCwgYW5kIHBy ZXZpb3VzbHkgdW5wdWJsaXNoZWQsIGNvbmNlcHR1YWwgb3IgZW1waXJpY2FsIHJlc2VhcmNoIG1h bnVzY3JpcHQgZm9yIHJldmlldyBhbmQgZGVjaXNpb24uIEFjY2VwdGVkIHBhcGVycyB3aWxsIGJl IHB1Ymxpc2hlZCBpbiB0aGUgY29uZmVyZW5jZSBwcm9jZWVkaW5ncyBpbiB0aGVpciBlbnRpcmV0 eSBvciBhcyBhIDE1MDAtMzUwMCB3b3JkIG1pbmktcGFwZXIsIGFzIHJlY29tbWVuZGVkIGJ5IHRo ZSByZXZpZXdlcnMuIEhpZ2ggcXVhbGl0eSBwYXBlcnMgd2lsbCBiZSBjb25zaWRlcmVkIGZvciBm dXJ0aGVyIHJldmlldyBhbmQgcG9zc2libGUgaW5jbHVzaW9uIGluIHRoZSBJbmZvcm1hdGlvbiBS ZXNvdXJjZSBNYW5hZ2VtZW50IEpvdXJuYWwsIEpvdXJuYWwgb2YgRW5kIFVzZXIgQ29tcHV0aW5n LCBKb3VybmFsIG9mIERhdGFiYXNlIE1hbmFnZW1lbnQsIEpvdXJuYWwgb2YgR2xvYmFsIEluZm9y bWF0aW9uIE1hbmFnZW1lbnQgb3IgUmV2aWV3IG9mIEFjY291bnRpbmcgSW5mb3JtYXRpb24gU3lz dGVtcy4gSW4gYWRkaXRpb24sIHRoZSBiZXN0IHBhcGVyIGluIHRlcm1zIG9mIHF1YWxpdHkgYW5k IHN1aXRhYmlsaXR5IHRvIHRoZSB0aGVtZSBvZiB0aGUgY29uZmVyZW5jZSB3aWxsIGJlIGF3YXJk ZWQgdGhlIJNCZXN0IFBhcGVylCBBd2FyZC4NUkVTRUFSQ0gtSU4tUFJPR1JFU1MgU1VCTUlTU0lP TlMtIFRob3NlIGluZGl2aWR1YWxzIGludGVyZXN0ZWQgbWF5IHN1Ym1pdCByZXNlYXJjaCBwYXBl ciBwcm9wb3NhbHMgKGFic3RyYWN0cykgb3IgYSBzdW1tYXJ5IG9mIHRlbnRhdGl2ZSByZXN1bHRz IG9mIHRoZSBzdHVkeSB0byBkYXRlIGluIDUwMC0xMDAwIHdvcmRzIGJ5IE9jdG9iZXIgOCwgMTk5 OS4gQXV0aG9ycyBvZiBhY2NlcHRlZCBwcm9wb3NhbHMvc3VtbWFyaWVzIGFyZSBhc2tlZCB0byBm b3J3YXJkIGEgMTUwMC0zNTAwIHdvcmRzIG1pbmktcGFwZXIgYnkgSmFudWFyeSAxNCwgMjAwMCBm b3IgaW5jbHVzaW9uIGluIHRoZSBjb25mZXJlbmNlIHByb2NlZWRpbmdzLg1QQU5FTCwgV09SS1NI T1AsIFRVVE9SSUFMLCBBTkQgU1lNUE9TSVVNIFNVQk1JU1NJT05TIJYgSW5kaXZpZHVhbHMgaW50 ZXJlc3RlZCBpbiBjb25kdWN0aW5nIGEgcGFuZWwsIHdvcmtzaG9wLCBzeW1wb3NpdW0gb3IgdHV0 b3JpYWwgZGVhbGluZyB3aXRoIHRlY2hub2xvZ2ljYWwsIG1hbmFnZXJpYWwsIHByb2Zlc3Npb25h bCwgdGVhY2hpbmcsIHNvY2lldGFsLCBuYXRpb25hbCBvciBpbnRlcm5hdGlvbmFsIGlzc3VlcyBv ZiBpbmZvcm1hdGlvbiB0ZWNobm9sb2d5IG1hbmFnZW1lbnQgYXJlIGludml0ZWQgdG8gc3VibWl0 IGEgNTAwLTEwMDAgd29yZCBwcm9wb3NhbCBjb3ZlcmluZyB0aGUgb2JqZWN0aXZlcywgaXNzdWVz IHRvIGJlIGNvdmVyZWQsIGFuZCB0aGUgbmFtZXMvYWRkcmVzc2VzIG9mIGFueSBvdGhlciBwYW5l bCwgd29ya3Nob3AsIHR1dG9yaWFsL3N5bXBvc2l1bSBtZW1iZXJzLiBNZXRob2Qgb2YgcHJlc2Vu dGF0aW9uIGlzIGF0IHRoZSBzdWJtaXR0ZXKScyBkaXNjcmV0aW9uLCBob3dldmVyIHRoZSBzdWJt aXR0ZXIgaGFzIHRoZSByZXNwb25zaWJpbGl0eSBmb3IgcHJvdmlkaW5nIGhpcy9oZXIgb3duIHBh cnRpY2lwYW50cyAoc3VjaCBhcyBwYW5lbCBtZW1iZXJzKS4gQWxsIGFjY2VwdGVkIHByb3Bvc2Fs cyB3aWxsIGFwcGVhciBpbiB0aGUgY29uZmVyZW5jZSBwcm9jZWVkaW5ncy4gKE5vdGU6IEFsbCBw YW5lbCwgd29ya3Nob3AsIHR1dG9yaWFsL3N5bXBvc2l1bSBtZW1iZXJzIG11c3QgcmVnaXN0ZXIg YW5kIHBheSBmb3IgdGhlIGNvbmZlcmVuY2UuIFBhbmVsIHByZXNlbnRlcnMgc2hvdWxkIGtub3cg dGhhdCBkdXJpbmcgdGhlIGNvbmZlcmVuY2UsIGFuIG92ZXJoZWFkIHByb2plY3RvciBhbmQgc2Ny ZWVuIHdpbGwgYmUgcHJvdmlkZWQgYnkgdGhlIGFzc29jaWF0aW9uIGZvciBlYWNoIHByZXNlbnRh dGlvbi4gQW55IGFkZGl0aW9uYWwgZXF1aXBtZW50IG5lZWRlZCBmb3IgdGhlIHBhbmVsLCB3b3Jr c2hvcCwgdHV0b3JpYWwgb3Igc3ltcG9zaXVtIGlzIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBw cmVzZW50ZXIgYW5kIGl0IHdpbGwgYmUgaGlzIG9yIGhlciByZXNwb25zaWJpbGl0eSB0byBwcm92 aWRlIHRoZSBleHRyYSBlcXVpcG1lbnQuIA0NCFNVQk1JU1NJT04gR1VJREVMSU5FUw0NTWFudXNj cmlwdCBtdXN0IG5vdCBleGNlZWQgNDAwMCB3b3JkcyBmb3IgZnVsbCBsZW5ndGggc3VibWlzc2lv bnM7IDUwMC0xMDAwIHdvcmRzIGZvciByZXNlYXJjaC1pbi1wcm9ncmVzcyBzdW1tYXJ5L3Byb3Bv c2FsOyBhbmQgMTAwMC0yMDAwIHdvcmRzIGZvciBwYW5lbCwgd29ya3Nob3AsIHR1dG9yaWFsIGFu ZCBzeW1wb3NpdW0gcHJvcG9zYWxzLg1NdXN0IGJlIGFjY29tcGFuaWVkIGJ5IGEgc2VwYXJhdGUg Y292ZXIgbGV0dGVyIHdpdGggdGhlIHRpdGxlICdTdWJtaXNzaW9uIGZvciBNdWx0aW1lZGlhIFRy YWNrJywgZXZlcnkgYXV0aG9yKHMpIG5hbWUsIGFkZHJlc3MsIHRlbC4gYW5kIGZheCBudW1iZXJz LCBlLW1haWwgYW5kIGZ1bGwgYWZmaWxpYXRpb24uIEFsbCBjb3JyZXNwb25kZW5jZSB3aWxsIGJl IHNlbnQgdG8gdGhlIGZpcnN0IGF1dGhvciB1bmxlc3Mgb3RoZXJ3aXNlIHNwZWNpZmllZC4NU3Vi bWl0dGVkIHBhcGVycyBtdXN0IG5vdCBjdXJyZW50bHkgYmUgdW5kZXIgcmV2aWV3IGJ5IGFueSBv dGhlciBwdWJsaWNhdGlvbiBvciBjb25mZXJlbmNlLg1TdWJtaXR0ZXJzIG11c3QgcHJvdmlkZSB0 aGVpciBlLW1haWwgYWRkcmVzcyB3aGVyZSB0aGUgYWNrbm93bGVkZ21lbnQgd2lsbCBiZSBmb3J3 YXJkZWQuDVRoZSBudW1iZXIgb2Ygc3VibWlzc2lvbnMgYnkgYW4gYXV0aG9yIChpbmNsdWRpbmcg am9pbnQgYXV0aG9yc2hpcCkgaXMgbGltaXRlZCB0byBhIG1heGltdW0gb2YgdHdvIHN1Ym1pc3Np b25zLg1BbGwgc3VibWlzc2lvbnMgc2hvdWxkIGJlIHN1Ym1pdHRlZCBlbGVjdHJvbmljYWxseSBp biBlaXRoZXIgTVMgV29yZCAnOTcgb3IgcmljaCB0ZXh0IGZvcm1hdCAoUlRGKS4gKE5vdGU6IElm IHlvdSBkbyBub3QgcmVjZWl2ZSBhbiBlLW1haWwgYWNrbm93bGVkZ21lbnQgb25lIHdlZWsgYWZ0 ZXIgeW91ciBlbGVjdHJvbmljIHN1Ym1pc3Npb25zLCBwbGVhc2UgY29udGFjdCB0aGUgcHJvZ3Jh bSBjaGFpci4NCA1MT0NBVElPTg0NQW5jaG9yYWdlIGlzIGEgY29zbW9wb2xpdGFuIGNpdHkgb2Yg Z2xhc3Mtd2FsbGVkIGhpZ2gtcmlzZXMsIGZvdXItZGlhbW9uZCBob3RlbHMgYW5kIHdvcmxkLWNs YXNzIGVudGVydGFpbm1lbnQsIHN1cnJvdW5kZWQgYnkgTm9ydGggQW1lcmljYSdzIGdyZWF0ZXN0 IHdpbGRlcm5lc3Mgc2hvdy4gVmlzaXRvcnMgd2lsbCBmaW5kIGEgd2lkZSB2YXJpZXR5IG9mIGJp Zy1jaXR5IGFtZW5pdGllcyB3aXRoIHNtYWxsLXRvd24gZnJpZW5kbGluZXNzLiBEaW5pbmcgYW5k IHNob3BwaW5nIGFyZSBlYXN5IHdpdGggbW9yZSB0aGFuIDMwMCBwbGFjZXMgdG8gZWF0IGFuZCBk cmluaywgcGx1cyBodW5kcmVkcyBvZiBzaG9wcyBhbmQgZG96ZW5zIG9mIGVuY2xvc2VkIG1hbGxz IGluY2x1ZGluZyBzb21lIGZhY3Rvcnkgb3V0bGV0cy4gU2N1bHB0ZWQgYnkgZ2xhY2llcnMgYW5k IHNlYXMsIHRoZSBBbmNob3JhZ2UgYXJlYSBpcyBhIHdvbmRlcmxhbmQgb2YgbWFqZXN0aWMgZmpv cmRzIGFuZCBmb3Jlc3RlZCB2YWxsZXlzLCB3aGVyZSB0aGUgTm9ydGhlcm4gTGlnaHRzIHJpcHBs ZSBhbmQgc2hpbW1lciBpbiB0aGUgc2t5IGFuZCB0aGUgdGVycmFpbiBpcyB2YXJpZWQgZW5vdWdo IHRvIHByb3ZpZGUgYWR2ZW50dXJlcyBmb3IgdGhlIGhlYXJ0eSBhbmQgdGhlIG5vdC1zby1oZWFy dHkuDQ1BdXRob3JzIG9mIGFjY2VwdGVkIG1hbnVzY3JpcHRzIGFuZCBwcm9wb3NhbHMgd2lsbCBi ZSBhc2tlZCB0byBwcm92aWRlIHRoZSBmaW5hbCBjb3B5IG9mIHN1Ym1pc3Npb24gaW4gTVMgV29y ZCc5NyBvciBSVEYgZm9ybWF0IGVsZWN0cm9uaWNhbGx5LiBBdXRob3JzIG9mIGFjY2VwdGVkIHBh cGVycyAoYXQgbGVhc3Qgb25lIHBlcnNvbikgbXVzdCByZWdpc3RlciBhbmQgYXR0ZW5kIHRoZSBj b25mZXJlbmNlLg0NU2VuZCBhbGwgaW5xdWlyaWVzIGFuZCBzdWJtaXNzaW9ucyAoaW5kaWNhdGlu ZyBNdWx0aW1lZGlhIENvbXB1dGluZyBUcmFjayBpbiBhbGwgeW91ciBjb3JyZXNwb25kZW5jZXMp IHRvOg1NZWhkaSBLaG9zcm93cG91ciwgUHJvZ3JhbSBDaGFpcg0yMDAwIElSTUEgSU5URVJOQVRJ T05BTCBDT05GRVJFTkNFDTEzMzEgRS4gQ2hvY29sYXRlIEF2ZW51ZSwgSGVyc2hleSwgUEEgMTcw MzMtMTExNywgVS5TLkEuDVRlbDogKDcxNykgNTMzLTg4NzkgKiBGYXg6ICg3MTcpIDUzMy04NjYx ICogRW1haWw6IG1laGRpQGlybWEtaW50ZXJuYXRpb25hbC5vcmcNVmlzaXQgd2Vic2l0ZXM6IGh0 dHA6Ly93d3cuZWNlLm5kc3Uubm9kYWsuZWR1L35tc3llZC9pcm1hbW0vaW5kZXguaHRtbA1odHRw Oi8vd3d3LmlybWEtaW50ZXJuYXRpb25hbC5vcmcNDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABBAAAEQQAABIEAAA3 BAAAOAQAADkEAAA6BAAAVQQAAF4EAACpBAAAqgQAAOsEAADsBAAA7QQAAO4EAAD6BAAA/AQAABAF AAARBQAA2wUAAB8GAAAgBgAAIQYAADAGAAAxBgAAmwcAAJwHAACdBwAAsAcAALEHAABRCAAAUggA AIALAACBCwAA8+/r5+Tb2NLOyuTCwOS3s+SpoZuVt+Sz5I5+5HvkdG1mXwAAAAAAAAAAAAAAAAAA AAAMQ0oQAE9KBABRSgQAAAxDShYAT0oEAFFKBAAADENKFABPSgMAUUoDAAAMQ0oWAE9KAwBRSgMA AARDShwAAB8DagAAAAA1CIFCKghDShAAT0oGAFFKBgBVCAFtSAAEDENKFABPSgQAUUoEAAALQioB T0oEAFFKBAALQioBT0oFAFFKBQAONQiBQioJT0oEAFFKBAAAEjUIgUIqCUNKHABPSgQAUUoEAAAH QioIQ0ocABEDagAAAABDShAAVQgBbUgABANCKgsONQiBQioMT0oDAFFKAwAAB0IqC0NKHgAHQioK Q0ocAAtCKgxPSgMAUUoDAARDSggAABEDagAAAABDSggAVQgBbUgABARDShAAAAdCKg1DShwAB0Iq DUNKEAAHQioIQ0ooABcDagAAAAA1CIFCKghDSigAVQgBbUgABAAiAAQAABEEAAASBAAANwQAADgE AAA6BAAAVQQAAF4EAACpBAAAqgQAALoEAADVBAAA7AQAAO0EAAD6BAAA/AQAABEFAABuBQAA2wUA AB8GAAAhBgAAMAYAADEGAACbBwAAnQcAALAHAACxBwAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADuAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA5wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGAAABEgADAAAD JAMAAQIAAAUBAA6Ekf4PhJj+AAEBAAMAAAMkAQABEAAAAQ8AABoABAAAEQQAABIEAAA3BAAAOAQA ADoEAABVBAAAXgQAAKkEAACqBAAAugQAANUEAADsBAAA7QQAAPoEAAD8BAAAEQUAAG4FAADbBQAA HwYAACEGAAAwBgAAMQYAAJsHAACdBwAAsAcAALEHAABRCAAAUggAAJEIAAC2CAAA+QgAADcJAABJ CQAAZAkAALwJAADeCQAAHQoAADkKAABmCgAApQoAAN4KAAA7CwAAgAsAAIELAACDCwAAkwsAAJQL AACVCwAAwAsAAPoLAAAlDAAAUAwAAFEMAACsDAAArQwAAK8MAADFDAAAxgwAABoNAAAbDQAAJBAA AIsRAADtFQAA7hUAAAUWAAAGFgAAzhYAANEXAAAtGAAAhhgAAPYYAADeGQAA4BkAAOkZAADqGQAA hRwAAIYcAABwHQAAcR0AANwdAAD9HQAAIB4AAFkeAACpHgAA8B4AABIfAAATHwAAFB8AABUfAAD9 +/sAAPj4+AAAAAAA9QAAAAAAAPUA8wDwAAAA6+vr6+vr6+vr6+vr6+vr6QD1AAAAAAAAAAAAAOfn 5+fn5+fn5+fn5+fn5+fn5+fnAAAAAOcAAOfnAOfnAAAAAAAAAAAAAAAAAAACAQEAAgMBAAkDAQUK CA4ACQEFAgYABQUDAhIABQICAAUBBQIBAAUAAwIQAAMCDwAAWbEHAABRCAAAUggAAJEIAAC2CAAA +QgAADcJAABJCQAAZAkAALwJAADeCQAAHQoAADkKAABmCgAApQoAAN4KAAA7CwAAgAsAAIELAACD CwAAkwsAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAA AADiAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMgAAAAAAAAA AAAAAADIAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAA ugAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAECAAAF AAANxgUAAQAAgA4AABYkARckAQKWbAAHlJEMCNYIAAK0AHIViioMAAAKJgALRg4AD4R6ARYkAQ3G BAHQAgAADQAACiYAC0YOAA+EegEWJAENxgcB0AIBKNsGAA0AAAomAAtGDgAPhGgBFiQBDcYHAdAC ATzxBgwAAAomAAtGDgAPhGgBFiQBDcYEAdACAAMAAAMkAwAUgQsAAIILAACDCwAAkwsAAJULAABQ DAAAUQwAAKwMAACtDAAArgwAAK8MAADFDAAAxgwAABoNAAAbDQAAMg0AADMNAAAkEAAARBAAAEUQ AABGEAAAihEAAIsRAAC/EQAAwhEAAOsVAADtFQAA7hUAAO8VAAAFFgAABhYAAAwXAAB/FwAA3hkA AN8ZAADgGQAA6RkAAOoZAACFHAAAhhwAAHAdAABxHQAAoB0AALodAADcHQAA8uvn5N3a69fO18vI wsi4sOu466nrqbip66nIoMva65jrjdrn2uuG69p8cnwAAAAAEjUIgUIqCUNKFgBPSgYAUUoGAAAS NQiBQioLQ0oWAE9KBgBRSgYAAAxDShAAT0oEAFFKBAAAFANqAAAAAEIqCENKEABVCAFtSAAEAA81 CIFDShQAT0oEAFFKBAARA2oAAAAAQ0oQAFUIAW1IAAQMQ0oWAE9KBABRSgQAAA9CKg1DShQAT0oE AFFKBAASNQiBQioNQ0oUAE9KBABRSgQAAAo1CIFCKglDShYAAARDSggAAARDShwAABEDagAAAABD ShwAVQgBbUgABARDSgQAAARDShAAAAxDShYAT0oDAFFKAwAABENKDAAAB0IqCENKHAAMQ0oUAE9K BABRSgQAABkDagAAAABDShQAT0oEAFFKBABVCAFtSAAEACyTCwAAlAsAAJULAADACwAA+gsAACUM AABQDAAAUQwAAKwMAACtDAAArwwAAMUMAADGDAAAGg0AABsNAAAkEAAAixEAAO0VAADuFQAABRYA AAYWAADOFgAA0RcAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADwAAAAAAAAAAAA AAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADWAAAAAAAA AAAAAAAA8AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAA AMsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAMkAwomAAtGCgAA AQAAAAEEAAAGAAADJAMKJgALRgkAAAYAAAMkAwomAAtGBwAABgAAAyQDCiYAC0YIAAMAAAMkAQAB AwADAAADJAMHAAADJAMPhHYCEYTQAgUAAAMkAxGE0AIAFtEXAAAtGAAAhhgAAPYYAADeGQAA4BkA AOkZAADqGQAAhRwAAIYcAABwHQAAcR0AANwdAAD9HQAAIB4AAFkeAACpHgAA8B4AABIfAAATHwAA FB8AABUfAAD4AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADjAAAAAAAAAAAA AAAA4AAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAOAA AAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADbAAAAAAAA AAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAA ANsAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAAMAAAMkAQABBQADAAADJAMABgAAAyQDCiYAC0YNAAAGAAADJAMKJgAL RgoAAAYAAAMkAwomAAtGDAAABgAAAyQDCiYAC0YLAAAV3B0AABIfAAAUHwAAFR8AAPkA+QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADENKFgBPSgMAUUoDAAMuAAkwBBIwACZQAQAfsNAvILDgPSGw0AIi sNACI5DQAiSQ0AIlsAAAF7AAABiwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEwAKAAEAWwAPAAIAAAAAAAAAKAAAQPH/ AgAoAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAIAENKGABtSAkMOAABQAEAAgA4AAAACQBIAGUAYQBk AGkAbgBnACAAMQAAAAsAAQADJAEGJAFAJgAABwA1CIFDSjAAAEAAAkABAAIAQAAAAAkASABlAGEA ZABpAG4AZwAgADIAAAALAAIAAyQBBiQBQCYBAA8ANQiBQ0ooAE9KBgBRSgYAAEIAA0ABAAIAQgAA AAkASABlAGEAZABpAG4AZwAgADMAAAALAAMAAyQBBiQBQCYCABIANQiBQioIQ0ooAE9KBgBRSgYA QgAEQAEAAgBCAAAACQBIAGUAYQBkAGkAbgBnACAANAAAAAsABAADJAEGJAFAJgMAEgA1CIFCKghD SiAAT0oGAFFKBgA8AAVAAQACADwAAAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAACwAFAAMkAQYkAUAm BAALADUIgU9KBgBRSgYAAEIABkABAAIAQgAAAAkASABlAGEAZABpAG4AZwAgADYAAAALAAYAAyQB BiQBQCYFABIANQiBQioIQ0okAE9KBgBRSgYAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUA bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADIAPkABAPIAMgAA AAUAVABpAHQAbABlAAAABQAPAAMkAQAPADUIgUNKNABPSgYAUUoGAAAsAEpAAQACASwAAAAIAFMA dQBiAHQAaQB0AGwAZQAAAAUAEAADJAEAAwA1CIEAKABVQKIAEQEoAAAACQBIAHkAcABlAHIAbABp AG4AawAAAAYAPioBQioCLgBCQAEAIgEuAAAACQBCAG8AZAB5ACAAVABlAHgAdAAAAAUAEgADJAMA BABDShYAAAAAAAEAAAAVGwAA/////wAAAAABAP////8AAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAAQAAAAAAAAAAAj//wAAAAAAAAAAFRsAAAYAADAAAAAA/////wAEAACBCwAA 3B0AABUfAAAQAAAAFAAAABcAAAAABAAAsQcAAJMLAADRFwAAFR8AABEAAAATAAAAFQAAABYAAAAA BAAAFR8AABIAAAAPAADwRAAAAAAABvAYAAAAAggAAAIAAAAPAAAAAQAAAAEAAAAQAAAAEAAa8QQA AAAA//8AQAAe8RAAAAAAAAAAMzMAAICAgAD3AAAQAA8AAvBcAwAAEAAI8AgAAAAKAAAADwQAAA8A A/D6AgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE 8E4AAAASAArwCAAAAAMEAAAACgAAUwAL8B4AAACBAQCAgAC/ARAAEADAAYCAAAD/AQgACAC/AyAA IAAAABDwBAAAAAAAAAAAABHwBAAAAA0AAAAPAATwZgAAABIACvAIAAAABQQAAAAKAACTAAvwNgAA AIEB//8AAL8BEAAQAMABMzMAAP8BCAAIAAUCWNb+/wYCWNb+/z8CAgACAL8CAAAIAL8DIAAgAAAA EPAEAAAAAQAAAAAAEfAEAAAADQAAAA8ABPBCAAAAEgAK8AgAAAAGBAAAAAoAADMAC/ASAAAAgQEA gIAAvwEQABAAvwMgACAAAAAQ8AQAAAACAAAAAAAR8AQAAAASAAAADwAE8EIAAAASAArwCAAAAAkE AAAACgAAMwAL8BIAAACBAQCAgAC/ARAAEAC/AyAAIAAAABDwBAAAAAMAAAAAABHwBAAAABYAAAAP AATwQgAAABIACvAIAAAACgQAAAAKAAAzAAvwEgAAAIEBAICAAL8BEAAQAL8DIAAgAAAAEPAEAAAA BAAAAAAAEfAEAAAAFgAAAA8ABPBCAAAAEgAK8AgAAAALBAAAAAoAADMAC/ASAAAAgQEAgIAAvwEQ ABAAvwMgACAAAAAQ8AQAAAAHAAAAAAAR8AQAAAAmAAAADwAE8EIAAAASAArwCAAAAA0EAAAACgAA MwAL8BIAAACBAQCAgAC/ARAAEAC/AyAAIAAAABDwBAAAAAYAAAAAABHwBAAAACcAAAAPAATwQgAA ABIACvAIAAAADgQAAAAKAAAzAAvwEgAAAIEBAICAAL8BEAAQAL8DIAAgAAAAEPAEAAAABQAAAAAA EfAEAAAAIQAAAA8ABPBCAAAAEgAK8AgAAAAPBAAAAAoAADMAC/ASAAAAgQEAgIAAvwEQABAAvwMg ACAAAAAQ8AQAAAAIAAAAAAAR8AQAAAAOAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAAAAAAOAAAAO0AAAAf AgAAmwMAAIEHAACtCAAA7hEAAN4VAAAVGwAAAwQAAHAIAADy////gB8AADICAAB0AAAAAAAFBAAA AAAAAAUAAAAwKgAApQUAAHQAAAAAAAYEAADQCwAAEwAAANAdAABjAQAAdAAAAAAACQQAANALAACa AAAA0B0AABwCAAB0AAAAAAAKBAAA0AsAAHYAAADQHQAAIQIAAHQAAAAAAA4EAADQCwAA0QAAANAd AACBAgAAdAAAAAAADQQAAGAMAADy////0B0AAKIBAAB0AAAAAAALBAAAYAwAABEAAADQHQAAMQEA AHQAAAAAAA8EAABgDAAAngAAANAdAAD9AQAAdAAAAAAAAAAAANwZAADhGQAA4hkAAO0ZAACvGgAA txoAABIbAAAWGwAABwAcAAcAHAAHABwABwAHAAAAAAALCAAADggAAEYMAABLDAAAEBUAAFgVAAAS GwAAFhsAAAcAGgAHABoABwAaAAcABwD//xQAAAAcAEUAbABlAGMAdAByAGkAYwBhAGwAIABFAG4A ZwBpAG4AZQBlAHIAaQBuAGcAIABEAGUAcAB0AC4AKABDADoAXABPAHQAaABlAHIAcwBcAEMAbwBu AGYAZQByAGUAbgBjAGUAcwBcAEkAUgBNAEEAXABJAFIATQBBAGMAYQBsAGwAMQAuAGQAbwBjABwA RQBsAGUAYwB0AHIAaQBjAGEAbAAgAEUAbgBnAGkAbgBlAGUAcgBpAG4AZwAgAEQAZQBwAHQALgAo AEMAOgBcAE8AdABoAGUAcgBzAFwAQwBvAG4AZgBlAHIAZQBuAGMAZQBzAFwASQBSAE0AQQBcAEkA UgBNAEEAYwBhAGwAbAAxAC4AZABvAGMAHABFAGwAZQBjAHQAcgBpAGMAYQBsACAARQBuAGcAaQBu AGUAZQByAGkAbgBnACAARABlAHAAdAAuACgAQwA6AFwATwB0AGgAZQByAHMAXABDAG8AbgBmAGUA cgBlAG4AYwBlAHMAXABJAFIATQBBAFwASQBSAE0AQQBjAGEAbABsADEALgBkAG8AYwAcAEUAbABl AGMAdAByAGkAYwBhAGwAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABEAGUAcAB0AC4ANQBDADoA XABEAGUAcAB0AGIAYQBjAGsAdQBwAFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5 ACAAcwBhAHYAZQAgAG8AZgAgAEkAUgBNAEEAYwBhAGwAbAAxAC4AYQBzAGQAHABFAGwAZQBjAHQA cgBpAGMAYQBsACAARQBuAGcAaQBuAGUAZQByAGkAbgBnACAARABlAHAAdAAuACgAQwA6AFwATwB0 AGgAZQByAHMAXABDAG8AbgBmAGUAcgBlAG4AYwBlAHMAXABJAFIATQBBAFwASQBSAE0AQQBjAGEA bABsADEALgBkAG8AYwAcAEUAbABlAGMAdAByAGkAYwBhAGwAIABFAG4AZwBpAG4AZQBlAHIAaQBu AGcAIABEAGUAcAB0AC4ANQBDADoAXABEAGUAcAB0AGIAYQBjAGsAdQBwAFwAVwBvAHIAZABcAEEA dQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEkAUgBNAEEAYwBhAGwAbAAx AC4AYQBzAGQAHABFAGwAZQBjAHQAcgBpAGMAYQBsACAARQBuAGcAaQBuAGUAZQByAGkAbgBnACAA RABlAHAAdAAuACgAQwA6AFwATwB0AGgAZQByAHMAXABDAG8AbgBmAGUAcgBlAG4AYwBlAHMAXABJ AFIATQBBAFwASQBSAE0AQQBjAGEAbABsADEALgBkAG8AYwAcAEUAbABlAGMAdAByAGkAYwBhAGwA IABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABEAGUAcAB0AC4ANQBDADoAXABEAGUAcAB0AGIAYQBj AGsAdQBwAFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8A ZgAgAEkAUgBNAEEAYwBhAGwAbAAxAC4AYQBzAGQAHABFAGwAZQBjAHQAcgBpAGMAYQBsACAARQBu AGcAaQBuAGUAZQByAGkAbgBnACAARABlAHAAdAAuADUAQwA6AFwARABlAHAAdABiAGEAYwBrAHUA cABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJ AFIATQBBAGMAYQBsAGwAMQAuAGEAcwBkABwARQBsAGUAYwB0AHIAaQBjAGEAbAAgAEUAbgBnAGkA bgBlAGUAcgBpAG4AZwAgAEQAZQBwAHQALgAoAEMAOgBcAE8AdABoAGUAcgBzAFwAQwBvAG4AZgBl AHIAZQBuAGMAZQBzAFwASQBSAE0AQQBcAEkAUgBNAEEAYwBhAGwAbAAxAC4AZABvAGMADgD+//// //////8P/w//D/8P/w//D/8P/w//DwEA7AGeEf7Npqz/DwAAAAAAAAAAAAAAAAAAAAABABkMszMk KIgB/w8AAAAAAAAAAAAAAAAAAAAAAQCIP6Q0oiDc2/8PAAAAAAAAAAAAAAAAAAAAAAEAdVzlQ5hT 4k3/DwAAAAAAAAAAAAAAAAAAAAABAA5THErA6r5u/w8AAAAAAAAAAAAAAAAAAAAAAQAUHKpSmFPi Tf8PAAAAAAAAAAAAAAAAAAAAAAEA1TRvXZhT4k3/DwAAAAAAAAAAAAAAAAAAAAABAJs5jV26v7Rh /w8AAAAAAAAAAAAAAAAAAAAAAQBWSM9faFBaKP8PAAAAAAAAAAAAAAAAAAAAAAEAJH0yZRjehLf/ DwAAAAAAAAAAAAAAAAAAAAABABw4s2aYU+JN/w8AAAAAAAAAAAAAAAAAAAAAAQA+Wdxmthkk7f8P AAAAAAAAAAAAAAAAAAAAAAEAlHfxdcDqvm7/DwAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABACoAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+ FcYFAAFoAQZDShgAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+E aAERhJj+FcYFAAFoAQZDShAAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA DxAAAA+EaAERhJj+FcYFAAFoAQZDShIAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShgAT0oGAFFKBgBvKAABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oHAFFKBwBvKAABAG7w AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oHAFFKBwBv KAABAG7wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oH AFFKBwBvKAABAG7wAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+E0AIRhJj+FcYFAAHQAgZD ShIAT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYF AAFoAQZDShAAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAER hJj+FcYFAAFoAQZDShAAT0oHAFFKBwBvKAABAG7wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAA AA+EaAERhJj+FcYFAAFoAQZDShgAT0oHAFFKBwBvKAABALbwAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShgAT0oGAFFKBgBvKAABALfwDgAAAP7///8AAAAAPKP9 AQEAAACUd/F1AAAAAAAAAAAAAAAADlMcSgAAAAAAAAAAAAAAAD5Z3GYAAAAAAAAAAAAAAADsAZ4R AAAAAAAAAAAAAAAAiD+kNAAAAAAAAAAAAAAAABkMszMAAAAAAAAAAAAAAAAkfTJlAAAAAAAAAAAA AAAAmzmNXQAAAAAAAAAAAAAAAHVc5UMAAAAAAAAAAAAAAAAcOLNmAAAAAAAAAAAAAAAAFByqUgAA AAAAAAAAAAAAANU0b10AAAAAAAAAAAAAAABWSM9fAAAAAAAAAAAAAAAA/////2yj/QFgAC4AAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//////////// ////////////////////////////////////////////////////////////DgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD/QEhQIERlc2tKZXQgMTYwMEMgQ29sb3JTbWFydABcXFZFTlVT XGVlb19ocDE2MDBjAEhQIERlc2tKZXQgMTYwMEMgQ29sb3JTbWFydABIUCBEZXNrSmV0IDE2MDBD IENvbG9yU21hcnQASFAgRGVza0pldCAxNjAwQyBDb2xvclNtYXJ0AAAAAAAKAyEERADbAAMHAAAB AAEAAAAAAAAAAQAHAP3/AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAQBAAAAAAQAI 4f8BAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAC8AvAIAAP9//3//AAMAAAACAAEAAgABAAIAAQABAAIAAAAAAAAAAAAAAAAAAAAAAAAAAgAB AAEAAQADCgAAAAAAAAAASFAgRGVza0pldCAxNjAwQyBDb2xvclNtYXJ0AAAAAAAKAyEERADbAAMH AAABAAEAAAAAAAAAAQAHAP3/AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAQBAAAAA AQAI4f8BAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAC8AvAIAAP9//3//AAMAAAACAAEAAgABAAIAAQABAAIAAAAAAAAAAAAAAAAAAAAAAAAA AgABAAEAAQADCgAAAAAAAAAAA4ABAPkAAAD5AAAAZFb9AVUBVQH5AAAAAAAAAPkAAAAAAAAAAhAA AAAAAAAAFRsAAGAAAAgAQAAACAAAAEcWkAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAA AAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAA AAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAA AAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAABNFpABAAACBAYDBQUFAgMDBwAAAAAAAAAAAAAA AAAAAJMAAAAAAAAAQwBlAG4AdAB1AHIAeQAgAFMAYwBoAG8AbwBsAGIAbwBvAGsAAABHIpABAAoA AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAASABlAGwAdgBlAHQAaQBjAGEAAABBAHIA aQBhAGwAAABjIpABABEAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAASABlAGwAdgBl AHQAaQBjAGEALQBOAGEAcgByAG8AdwAAAEEAcgBpAGEAbAAgAE4AYQByAHIAbwB3AAAANSaQAQAA AgsGBAMFBAQCBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAFQAYQBoAG8AbQBhAAAARQaQAQIAAQEG AQEBAQEBAQAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAE0AbwBuAG8AdAB5AHAAZQAgAFMAbwByAHQA cwAAACIABABBCIgYAADQAgAAaAEAAAAAp+I2JqjkNial5DYmHwBGAAAA6gMAAFIWAAABAAsAAAAE AIMQLwAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAACBAgAAAIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAAGkbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAA ACIASQBUACAAaQBuACAAQQBzAGkAYQAgAFAAYQBjAGkAZgBpAGMAIABDAG8AdQBuAHQAcgBpAGUA cwAgAFQAcgBhAGMAawAAAAAAAAALAFMAeQBlAGQAIABSAGEAaABtAGEAbgAcAEUAbABlAGMAdABy AGkAYwBhAGwAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABEAGUAcAB0AC4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAAr J7PZMAAAALgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADMAAAABAAAANgAAAAFAAAA7AAAAAYA AAD4AAAABwAAAAQBAAAIAAAAGAEAAAkAAABAAQAAEgAAAEwBAAAKAAAAaAEAAAsAAAB0AQAADAAA AIABAAANAAAAjAEAAA4AAACYAQAADwAAAKABAAAQAAAAqAEAABMAAACwAQAAAgAAAOQEAAAeAAAA IwAAAElUIGluIEFzaWEgUGFjaWZpYyBDb3VudHJpZXMgVHJhY2sAcx4AAAABAAAAAFQgaR4AAAAM AAAAU3llZCBSYWhtYW4AHgAAAAEAAAAAeWVkHgAAAAEAAAAAeWVkHgAAAAsAAABOb3JtYWwuZG90 AAAeAAAAHQAAAEVsZWN0cmljYWwgRW5naW5lZXJpbmcgRGVwdC4AVHJhHgAAAAMAAAAzMQBjHgAA ABMAAABNaWNyb3NvZnQgV29yZCA4LjAAaUAAAAAAJGXHCQAAAEAAAAAAdgwev8G+AUAAAAAAwm9X fMG+AUAAAAAASFaJv8G+AQMAAAABAAAAAwAAAOoDAAADAAAAUhYAAAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF 1c3VnC4bEJOXCAArLPmucAEAACwBAAANAAAAAQAAAHAAAAAPAAAAeAAAAAQAAACUAAAABQAAAJwA AAAGAAAApAAAABEAAACsAAAAFwAAALQAAAALAAAAvAAAABAAAADEAAAAEwAAAMwAAAAWAAAA1AAA AA0AAADcAAAADAAAAAsBAAACAAAA5AQAAB4AAAASAAAATW9uYXNoIFVuaXZlcnNpdHkAYwADAAAA AFQAAAMAAAAvAAAAAwAAAAsAAAADAAAAaRsAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAA AAAACwAAAAAAAAAeEAAAAQAAACMAAABJVCBpbiBBc2lhIFBhY2lmaWMgQ291bnRyaWVzIFRyYWNr AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAJgAAAADAAAAAAAAACAAAAABAAAANgAA AAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADgAQgBBADAA QwA3ADgAMAAtAEYAQQA3ADIALQAxADEARAAwAC0AQgA5AEEAOQAtADAAMAAwADAAQwAwAEIAMAAx ADMARgA5AH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAP AAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA/v///xoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA/v///ykAAAAqAAAAKwAA ACwAAAAtAAAALgAAAC8AAAD+////MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAAP7////9//// OgAAAP7////+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgGDAIDQAAAAEA AAD//wUAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAILmGYHzBvgFA2AOsv8G+ ATwAAACAAAAAAAAAADEAVABhAGIAbABlAAAAfwIAAAAAAAAAAGAAYAAAAAAAAAAAAASRAAAyAAAA DgAAAA4AAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAQAAAAAAAAAFAAAAA0AAgAA AAAAsAh/AoYAAPAAAAAAGQAAAKIcAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8PAAAAZOt9 AtoKJGXrCiRlEQskZUILJGUAAAAAQAAAAJEAAKAAAAAAMDAAALQIfwIFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAD/////AAAAAAIAAAC0CH8CKAACAQIAAAAE AAAA/////wAAAAAOAAAAAQAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAEAAALAZ/AgUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAA4AAIB////////////////AAAAAL0BAKA8AEAAzNpNAAjVA0gAAAAAAAAAAAAAAAAAAAAA MAAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACAYMAgNAAAAAQAAABIAAgEBAAAABgAAAP////8AAAAA/wAAAAwLfwJw1gNIAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAYABg AAAAAAAAAAAABJEAADIAAAAOAAAADgAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAQNgDrL/BvgFA2AOsv8G+AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAGO59AgAAAAAAAAAAAAAAAAAAAAAsBn8CZgAA8AAAAACQfxdl4At/AkgE2wAAAAAA//////// ////////awkCAAAAAADAAAAAAAAARlgE2wAAAAAAsF79AQAAAAAAAAAAHQAAoJzyfwK4Y0cAAQAA AP7///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAP7/ AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABN U1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --=====================_931068623==_-- From rem-conf Tue Jul 06 01:08:31 1999 From rem-conf-request@es.net Tue Jul 06 01:08:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111PyC-0003Ym-00; Tue, 6 Jul 1999 00:48:48 -0700 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 111PyB-0003Xz-00; Tue, 6 Jul 1999 00:48:47 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.9.3/8.9.3) with SMTP id JAA27782 for ; Tue, 6 Jul 1999 09:47:44 +0200 (MET DST) Received: by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA12632; Tue, 6 Jul 1999 09:47:44 +0200 Message-Id: <199907060747.AA12632@dxcoms.cern.ch> Subject: CERN MBone Announcement: Next LHCC To: rem-conf@es.net (List Mbone-WW) Date: Tue, 6 Jul 1999 09:47:44 +0200 (MET DST) From: "Daniel Davids CERN/IT" Reply-To: daniel.davids@cern.ch X-Mailer: ELM [version 2.4 PL25] 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 CERN is pleased to announce the MBONE broadcast of the LARGE HADRON COLLIDER COMMITTEE =============================== Thursday 8 July 1999 Place: CERN Council Chamber *** Times are UTC+2 *** 09.00-10.00 ALICE Inner Tracking System TDR The broadcast is announced via sdr as "CERN LHCC". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact: multicast@noc.cern.ch From rem-conf Tue Jul 06 04:22:59 1999 From rem-conf-request@es.net Tue Jul 06 04:22:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111TGO-0005t1-00; Tue, 6 Jul 1999 04:19:48 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 111TGM-0005sr-00; Tue, 6 Jul 1999 04:19:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25843; Tue, 6 Jul 1999 07:18:42 -0400 (EDT) Message-Id: <199907061118.HAA25843@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mime-00.txt Date: Tue, 06 Jul 1999 07:18:42 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : MIME Type Registration of RTP Payload Formats Author(s) : S. Casner, P. Hoschka Filename : draft-ietf-avt-rtp-mime-00.txt Pages : 17 Date : 02-Jul-99 This document defines the procedure to register RTP Payload Formats as audio or video MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mime-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: <19990702133034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990702133034.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 06 04:29:30 1999 From rem-conf-request@es.net Tue Jul 06 04:29:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111TPP-0006L0-00; Tue, 6 Jul 1999 04:29:07 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 111TPN-0006If-00; Tue, 6 Jul 1999 04:29:05 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26027; Tue, 6 Jul 1999 07:28:02 -0400 (EDT) Message-Id: <199907061128.HAA26027@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtcp-bw-00.txt Date: Tue, 06 Jul 1999 07:28:01 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : SDP Bandwidth Modifiers for RTCP Bandwidth Author(s) : S. Casner Filename : draft-ietf-avt-rtcp-bw-00.txt Pages : 6 Date : 02-Jul-99 This document defines an extension to the Session Description Pro- tocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a Real-Time Transport Protocol (RTP) session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-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-rtcp-bw-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-rtcp-bw-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: <19990702133142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-bw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-bw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990702133142.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 06 04:29:31 1999 From rem-conf-request@es.net Tue Jul 06 04:29:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111TPI-0006Kj-00; Tue, 6 Jul 1999 04:29:00 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 111TPH-0006IU-00; Tue, 6 Jul 1999 04:28:59 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26015; Tue, 6 Jul 1999 07:27:55 -0400 (EDT) Message-Id: <199907061127.HAA26015@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-04.txt,.ps Date: Tue, 06 Jul 1999 07:27:55 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-04.txt,.ps Pages : 100 Date : 02-Jul-99 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-new-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990702133126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990702133126.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 06 04:29:31 1999 From rem-conf-request@es.net Tue Jul 06 04:29:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111TPC-0006KO-00; Tue, 6 Jul 1999 04:28:54 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 111TPB-0006IP-00; Tue, 6 Jul 1999 04:28:53 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26003; Tue, 6 Jul 1999 07:27:49 -0400 (EDT) Message-Id: <199907061127.HAA26003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-06.txt,.ps Date: Tue, 06 Jul 1999 07:27:49 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-new-06.txt,.ps Pages : 37 Date : 02-Jul-99 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-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-profile-new-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-profile-new-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: <19990702133111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990702133111.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 06 04:57:10 1999 From rem-conf-request@es.net Tue Jul 06 04:57:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111TpZ-0000jl-00; Tue, 6 Jul 1999 04:56:09 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 111TpY-0000jX-00; Tue, 6 Jul 1999 04:56:08 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26573; Tue, 6 Jul 1999 07:55:04 -0400 (EDT) Message-Id: <199907061155.HAA26573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-multiplexing-rtp-00.txt Date: Tue, 06 Jul 1999 07:55:03 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Multiplexing Scheme for RTP Flows between Access Routers Author(s) : K. El-Khatib, G. Luo, G. Bochmann Filename : draft-ietf-avt-multiplexing-rtp-00.txt Pages : 12 Date : 02-Jul-99 This draft proposes a light-weight data driven approach for multiplexing low bit rate RTP streams at the edge router of the Internet in order to reduce the RTP/UDP/IP header overhead associated with each RTP stream. Audio packets from different sources in a local access network destined to different users in the same remote access network are multiplexed into one packet, with the original RTP/UDP/IP header of each packet replaced with a mini-header (2 bytes), resulting in a reduction of the overhead. The de-multiplexing capability of the peer routers is determined in a very simple way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-multiplexing-rtp-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-multiplexing-rtp-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-multiplexing-rtp-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: <19990704115457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-multiplexing-rtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-multiplexing-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990704115457.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 06 10:26:44 1999 From rem-conf-request@es.net Tue Jul 06 10:26:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111Yrr-0005GF-00; Tue, 6 Jul 1999 10:18:51 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 111Yrp-0005G0-00; Tue, 6 Jul 1999 10:18:50 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 6 Jul 1999 17:23:20 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 852567A6.005EF3E5 ; Tue, 6 Jul 1999 13:17:08 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: Henning Schulzrinne , Scott.Petrack@metatel.com, rem-conf@es.net Message-ID: <852567A6.005EF212.00@notes4.nmss.com> Date: Tue, 6 Jul 1999 13:18:33 -0400 Subject: inband dtmf/tones proposal 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'm still trying to get a handle on this new dtmf/tones proposal. It is only the redundancy issue that is perplexing. There appears to be too much freedom in the spec to guarantee that a receiver can unravel what is missing and apply the redundancy to fill it in. If there is only one train of sequence numbers then things are probably okay, but the spec seems to allow more than one train (that is one for voice and another for dtmf). If there will be synchronization between voice packets and dtmf/tone packets so that they use a common period, then again, there appears to be no problem, but, again, the spec seems to allow different periods (should instead of shall). (The redundancy proposal suffers from additional problems such as ignoring the different look-ahead specs of the various vocoders but that is a separate issue.) The spec is also not clear on whether voice and dtmf/tone can overlap in time. If this happens, what is done with the sequence numbers and how is a receiver to know what has been missed and fill it in? It appears that voice redundancy does not have to be used in conjunction with dtmf/tone redundancy. That is to say, only dtmf/tone packets would incorporate redundancy and voice packets would not be required to do so. Is this your intention? Are all of these sorts of parameters (number of sequence number trains for example) to be negotiated prior to the start of communication? Any thoughts on these issues would be appreciated because we are considering architecting our products to be consistent with these proposals. From rem-conf Wed Jul 07 07:57:11 1999 From rem-conf-request@es.net Wed Jul 07 07:57:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111syV-0002YX-00; Wed, 7 Jul 1999 07:47:03 -0700 Received: from vanessa.diee.unica.it [192.167.131.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 111syK-0002YN-00; Wed, 7 Jul 1999 07:46:56 -0700 Received: from gwen.diee.unica.it (gwen.diee.unica.it [192.167.131.77]) by vanessa.diee.unica.it (8.9.1/8.9.1) with SMTP id QAA08424; Wed, 7 Jul 1999 16:27:11 +0100 (WETDST) Message-Id: <3.0.1.32.19990707164617.0069305c@vanessa.diee.unica.it> X-Sender: pv2000@vanessa.diee.unica.it X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 07 Jul 1999 16:46:17 +0200 To: osimcast@bbn.com, sc6wg4@ntd.comsat.com, xtp-relay@cs.concordia.ca, reres@laas.fr, prs@masi.ibp.fr, comswtc@gmu.ed, multicomm@cc.bellcore.com, giga@tele.pitt.edu, itc@ieee.org, isadsoc@fokus.gmd.de, ctc-members@redbank.tinac.com, ieee_rtc_list@cs.tamu.edu, enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, comsoc.bog@tab.ieee.org, sigmedia@bellcore.com, comsoc.tac@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, BM-List1@cs.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cost237-transport@comp.lancs.ac.uk, testnet@canarie.ca, itc@fokus.gmd.de, f-troup@codex.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf@es.net, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, epr@infotest.com, golshani@asu.edu, ni@cps.msu.edu, park@cstp.umkc.edu, tcp-over-satellite@achtung.sp.trw.com, udlr@sophia.inria.fr, knom@nile.postech.ac.kr, han-announce@news.postech.ac.kr, han-net-announce@news.postech.ac.kr, info@nmf.org, comsoc-cii@ieee.org, ifip-nm@bbn.com, nmf-objects@nmf.org, ietf@venera.isi.edu, fli@ee.pdx.edu, itu-adv-video@ferrari.iterated.com, itu-sg16@mailbag.cps.intel.com, mux-sys@fzi.de, H323IMPLEMENTORS@mailbag.cps.intel.com, mpeg-video@amalia.img.lx.it.pt, mpeg4_robust@ukraine.mot.com, gen-sys@fzi.de, sound@pascal.acm.org, tccc@cs.umass.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, de@de.epfl.ch, di@di.epfl.ch, IPMULTICAST@stardust.com, rem-conf@es.net From: pv2000 Subject: Packet Video 2000 - Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ===================================================================== PRELIMINARY CALL FOR PAPERS ====================================================================== PACKET VIDEO 2000 The 10th International Packet Video Workshop Date: 1-2 May 2000 Venue: Forte Village Resort, Cagliari, Italy Web site: http://www.diee.unica.it/pv2000/ Organization: Francesco G.B. De Natale and Daniele D. Giusto, University of Cagliari Technical sponsors: EURASIP, IEEE Signal Processing Society (IMDSP and MMSP Technical Committees) ====================================================================== The tenth edition of the International Packet Video Workshop (PV 2000) will be held at the Forte Village Resort, Cagliari, Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applicatons are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to seeing you in Sardinia in May 2000 for what will be a most rewarding and exciting experience! ====================================================================== TECHNICAL PROGRAM Chairs: Leonardo Chiariglione, CSELT, Turin Maurizio Decina, Cefriel and Polytechnic of Milan The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization Interstream synchronization for multiple video presentations Performance modeling and evaluation Picture quality evaluation Rate control for VBR video International Standards: MPEG-4, MPEG-7, H.263, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ====================================================================== Best Paper Award The author of the best paper will receive a $250 prize and a diploma suitable for framing. ====================================================================== Please submit an electronic manuscript written in HTML, not exceeding 7 Mbytes and 10 printed pages. We will produce a CD-ROM containing all the accepted papers. Electronic components accompanying your submission are strongly encouraged. Submit your work in ONE of the following forms: 1) a set of HTML files organized in a single directory OR 2) as a URL (you must have the rights to all the material there, and guarantee stability of the files until the conference). to: pv2000@diee.unica.it Detailed instructions for authors and help with manuscript preparation with HTML can be found on the conference web page. Deadlines: paper submission: December 15, 1999, notification of acceptance: February 29, 2000 final paper delivery: March 31, 2000 ====================================================================== Publication and local arrangements Luigi Atzori Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi, 19 09123 Cagliari, Italy gigi@diee.unica.it From rem-conf Wed Jul 07 15:14:09 1999 From rem-conf-request@es.net Wed Jul 07 15:14:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 111zrT-0007O1-00; Wed, 7 Jul 1999 15:08:15 -0700 Received: from auemail1.lucent.com (auemlsrv.firewall.lucent.com) [192.11.223.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 111zrS-0007Nr-00; Wed, 7 Jul 1999 15:08:14 -0700 Received: from mtgbcs.ho.lucent.com (h135-17-195-99.lucent.com [135.17.195.99]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA09159 for ; Wed, 7 Jul 1999 18:08:08 -0400 (EDT) Received: from hobcs2.ho.lucent.com by mtgbcs.ho.lucent.com (8.8.8+Sun/EMS-1.4.1 sol2) id SAA05310; Wed, 7 Jul 1999 18:09:49 -0400 (EDT) Received: by hobcs2.ho.lucent.com (SMI-8.6/EMS-L sol2) id SAA15235; Wed, 7 Jul 1999 18:09:46 -0400 Date: Wed, 7 Jul 1999 18:09:46 -0400 Message-Id: <199907072209.SAA15235@hobcs2.ho.lucent.com> From: tgl@mtgbcs.ho.lucent.com (Terry G Lyons) To: rem-conf@es.net Cc: tlyons@holmdel.exchange.lucent.com (Terry G Lyons) Subject: Re: draft-ietf-avt-tones-00.txt Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There are inconsistencies and ambiguities in draft-ietf-avt-tones-00.txt that should be repaired. They show up in a consideration of DTMF events, MIME type "audio/dtmf", sections 1 to 2.7, on pages 1-9. Apologies for not having scrutinized the rest of the draft carefully. #1. Delete section 2.6 "Compact Reliability Scheme" This reads like an alternative that was considered but eventually rejected, "A more compact representation could be achieved ...". It is the payload format of 2.3, not 2.6, that is used in the examples of sections 2.5 and 5. This particular text -- "... a fixed sampling rate, so choosing a value that depends on frame interval of the surrounding codec is not recommended" -- contradicts what is said in section 2.1, 3rd paragraph -- "SHOULD use the same sequence number and time-stamp base as the regular audio channel". (Mention of duration and offset covering 8 seconds shows that 2.6 is really talking about time-stamp units, not sampling rates). It is time to remove section 2.6 from the draft. #2. Change "digit" to "event" in section 2.5 figure and general text "event" is how the field is labeled in the figures of sections 2.3 and 5. "event" is also used in the headings and titles of Tables 1 and 3-6. Uses of "digit" in the text should mostly be generalized to "event". #3. Ambiguity about the end of a DTMF event This is a long topic. How well can a receiver reproduce the tones that were detected at the transmitter and converted to DTMF payload packets? Pauses between tones are significant. It is important not only to start playing out tones accurately but also to end each tone punctually. As it stands now there is no explicit indication of the end of an event and the beginning of a pause. This must be inferred from two packets in sequence (modulo packet losses), in ways that are not documented in the draft, hence subject to inconsistent interpretations and possible misoperation. Why does it matter? See section 1, 3rd paragraph, concerning the "RTP trunk" application: "This is particularly relevant where duration and timing matter, as in the carriage of DTMF signals." And the last paragraph of section 2.3: "Some applications, such as gateways into the GSTN, care about both delays and digit duration." The ambiguity occurs after the end of one event and before the next event begins (since "pause" is not considered an event in Table 1). Section 2.3 next to last paragraph says: "If there has been no new digit in the last interval, the digit SHOULD be retransmitted three times (or until the next event is recognized) to ensure some measure of reliability for the last event." [Note: RE-transmitted 3 times means transmitted a total of 4 times, right?] The 3 repetitions of one event have the SAME time-stamp and duration values. All that differs is the packet sequence number (adjusted for any audio packets being redundantly transmitted in the same stream, per section 2.1, 6th para; such audio packets would have advancing time-stamps, although the interleaved DTMF packets would be stuck at the time-stamp when the last event began). Receiving only the first of the 4 copies, can it be concluded that an event has ended? - Not if its duration extends all the way to the packet interval boundary. - Nor if the receiver is uncertain about the interval, which is left rather vague by section 2.3's "... SHOULD start transmitting event packets as soon as it recognizes an event and every 50 ms thereafter or the packet interval for the audio codec used for this session, if known. (Precise spacing between event packets is not necessary.)" - Nor if a new event may begin before the interval expires, because then a transmitter not using the redundancy mechanism of RFC 2198 would have to send out two packets quickly in one interval (separately: end-event1, start-event2); this also makes the time of end-event1 indeterminate. Taking full advantage of 4 transmissions for redundancy would require a receiver to add extra delay equal to 3 intervals at the end of each event. To keep durations accurate would then require equal delay to be inserted at the start of each event. There is also an impact on synchronizing to the decoding and playout of audio, if that matters. PROPOSAL: A more robust design would give receivers an explicit indication in a single packet that the event within it had ended. This can be done by setting the marker bit of the RTP header to 1 at event end, otherwise 0. (And keeping the marker set to 1 for the 3 retransmissions.) As RFC 1889 section 5.1 says, the use of the marker bit is for each profile to define. Tones is a large enough topic to rank as a profile. #4. State clearly that section 2.4 reliability is optional It now begins: "To achieve reliability even when the network loses packets, the audio redundancy mechanism described in RFC 2198 [6] is used." This should be changed to "MAY BE used". If, on the contrary, RFC 2198 were always to be required, why bother to mention the alternative reliability mechanism of 3 retransmissions in section 2.3? - terry.g.lyons@lucent.com +1 732 817-6016 From rem-conf Wed Jul 07 15:29:03 1999 From rem-conf-request@es.net Wed Jul 07 15:29:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11208s-0000L7-00; Wed, 7 Jul 1999 15:26:14 -0700 Received: from auemail1.lucent.com (auemlsrv.firewall.lucent.com) [192.11.223.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 11208r-0000Kx-00; Wed, 7 Jul 1999 15:26:13 -0700 Received: from mtgbcs.ho.lucent.com (h135-17-195-99.lucent.com [135.17.195.99]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA16611 for ; Wed, 7 Jul 1999 18:26:13 -0400 (EDT) Received: from hobcs2.ho.lucent.com by mtgbcs.ho.lucent.com (8.8.8+Sun/EMS-1.4.1 sol2) id SAA08748; Wed, 7 Jul 1999 18:27:57 -0400 (EDT) Received: by hobcs2.ho.lucent.com (SMI-8.6/EMS-L sol2) id SAA15574; Wed, 7 Jul 1999 18:27:54 -0400 Date: Wed, 7 Jul 1999 18:27:54 -0400 Message-Id: <199907072227.SAA15574@hobcs2.ho.lucent.com> From: tgl@mtgbcs.ho.lucent.com (Terry G Lyons) To: rem-conf@es.net Cc: tlyons@holmdel.exchange.lucent.com (Terry G Lyons) Subject: Re: draft-ietf-avt-profile-new-06.txt Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The new version, on the road to Draft Standard, makes an unnecessary change in the time-stamp unit for the audio encoding G.722, from 8000 to 16000 Hz. This is not listed in section 9 "Changes from RFC 1890". The change is inconsistent with prior implementations that comply with RFC 1890, such as Table B-2/H.225.0(1998) part of the H.323 suite. PROPOSAL: Restore the clock rate of G.722 to 8000 Hz as it was. The raw sampling rate at a microphone is a distinct concept from the time-stamp unit for encoded audio. The two need not be the same, as G.722 demonstrates. Its encoder spits out one octet every 1/8000 sec, which cannot be further subdivided in time. --------------------------------------------------- Quoted from Request for Comments: 1890 RTP Profile for Audio and Video Conferences with Minimal Control 6. Payload Type Definitions Table 2 defines this profile's static payload type values for the PT field of the RTP data header. ... PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) _______________________________________________________________ 9 G722 A 8000 1 Table 2: Payload types (PT) for standard audio and video encodings --------------------------------------------------- Quoted from draft-ietf-avt-profile-new-06.txt RTP Profile for Audio and Video Conferences with Minimal Control 6 Payload Type Definitions Tables 4 and 5 define this profile's static payload type values for the PT field of the RTP data header. PT encoding media type clock rate channels name (Hz) ___________________________________________________ 9 G722 A 16000 1 Table 4: Payload types (PT) for audio encodings --------------------------------------------------- - terry.g.lyons@lucent.com +1 732 817-6016 From rem-conf Wed Jul 07 16:40:02 1999 From rem-conf-request@es.net Wed Jul 07 16:40:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1121Fz-0001YO-00; Wed, 7 Jul 1999 16:37:39 -0700 Received: from bobcat.aciri.org [192.150.187.27] by mail1.es.net with esmtp (Exim 1.81 #2) id 1121Fy-0001YE-00; Wed, 7 Jul 1999 16:37:38 -0700 Received: from bobcat.aciri.org (localhost [127.0.0.1]) by bobcat.aciri.org (8.9.2/8.9.2) with ESMTP id QAA40608; Wed, 7 Jul 1999 16:37:36 -0700 (PDT) (envelope-from hodson@bobcat.aciri.org) Message-Id: <199907072337.QAA40608@bobcat.aciri.org> To: casner@cisco.com, schulzrinne@cs.columbia.edu, rem-conf@es.net Reply-To: O.Hodson@cs.ucl.ac.uk Subject: comment on draft-ietf-avt-profile-new-06.txt Date: Wed, 07 Jul 1999 16:37:36 -0700 From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The latest avt profile draft again has no payload formats are specified for the 2,3,5 bits per sample coding of G726 ADPCM. There are only two issues - the packetization interval and the sample packing order. Both are trivial but should be stated for the sake interoperability. 20 ms packetization interval is common for most sample based coders and results in all G726 encoding formats being byte aligned. The sample packing order is slightly complicated because the existing G726-32 packs samples in the order s1-s0-s3-s2 and there is no obvious extension to 3 and 5 bit per sample schemes since they do not align a single octet boundary. The other sample based encodings pack samples in the order with which they were generated. If there is no objection >from the list I would like to propose that the 2,3, and 5 bit per sample encodings are packed in the order of sample generation and we leave the 4 bits per sample as is. At least one application already incorporates these codecs, not because they are cutting edge, but because source code is publicly available and (relatively) unencumbered. - Orion From rem-conf Wed Jul 07 17:36:01 1999 From rem-conf-request@es.net Wed Jul 07 17:36:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11228C-0002hB-00; Wed, 7 Jul 1999 17:33:40 -0700 Received: from oslab.kyunghee.ac.kr [163.180.121.61] by mail1.es.net with esmtp (Exim 1.81 #2) id 11228B-0002h1-00; Wed, 7 Jul 1999 17:33:39 -0700 Received: from vxworks (vxworks.kyunghee.ac.kr [163.180.129.109]) by oslab.kyunghee.ac.kr (8.9.2/8.9.0) with SMTP id JAA00492 for ; Thu, 8 Jul 1999 09:28:21 +0900 (KST) Message-ID: <002f01bec8da$a0f83780$6d81b4a3@kyunghee.ac.kr> From: "Chan Gyun Jeong" To: Subject: Some questions about RTSP Date: Thu, 8 Jul 1999 09:41:33 +0900 Organization: Kyung Hee Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, all. I am Chan Gyun Jeong who is a master student majoring in Computer Engineering, Kyung Hee University, Seoul, South Korea. Nowadays, I am interested in Real-time Transport Protocol(RTP) and Real-Time Streaming Protocol(RTSP). I also have been developing a VOD system using RTP and RTSP. I have some problems that I can't understand. That is how VOD server could notify to clients when the media file reaches end of the file? I think that this notification makes the client change playing state, so the client can report the playing state to the end user like Real Player. I really need this functions. However, RTSP does not provides this notification method according to RFC 2326. Is there any notificaiton method that I haven't found yet in RTSP? Otherwise, do I have to solve this problem with RTCP BYE message? please let me know how to solve this problem. Thank you in advance. ------------------------------------------------------------------- Jeong, Chan Gyun (Dept. of Computer Engineering at KyungHee Univ.) [Web page] http://oslab.kyunghee.ac.kr/~cgjeong/ [E-mail] cgjeong@oslab.kyunghee.ac.kr < For more information about me, contact to me. > From rem-conf Wed Jul 07 18:41:15 1999 From rem-conf-request@es.net Wed Jul 07 18:41:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11239g-0003pJ-00; Wed, 7 Jul 1999 18:39:16 -0700 Received: from redale.cisco.com [171.69.95.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11239f-0003p8-00; Wed, 7 Jul 1999 18:39:15 -0700 Received: from cisco.com ([171.71.147.147]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA20149; Wed, 7 Jul 1999 18:37:35 -0700 (PDT) Message-ID: <3783FF7B.62CF0AB7@cisco.com> Date: Wed, 07 Jul 1999 18:31:39 -0700 From: Anup Rao X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Chan Gyun Jeong CC: rem-conf@es.net, confctrl@isi.edu Subject: Re: Some questions about RTSP References: <002f01bec8da$a0f83780$6d81b4a3@kyunghee.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chan Gyun Jeong wrote: > > Hello, all. > > I am Chan Gyun Jeong who is a master student majoring in > Computer Engineering, Kyung Hee University, Seoul, South Korea. > > Nowadays, I am interested in Real-time Transport Protocol(RTP) > and Real-Time Streaming Protocol(RTSP). > I also have been developing a VOD system using RTP and > RTSP. First things first, this question is best addressed to the list : confctrl@isi.edu. > I have some problems that I can't understand. That is how VOD server > could notify to clients when the media file reaches end of the file? > > I think that this notification makes the client change playing state, so the > client can report the playing state to the end user like Real Player. I really > need this functions. The way to do this is to have the client issue a DESCRIBE request first, to get a (SDP) description of the clip. The SDP description has a range parameter - see Section C.1.5. This parameter specifies the total length of the clip. The client should keep an mapping between RTP timestamps and NPT(normal play time). (Appendix B explains all this). So, when a received RTP timestamp maps to a NPT value >= whats asked for(or > than the total NPT range of the clip), the end has been reached. In case the presentation is a "live" one, SDP can specify the range in absolute time, so the client knows when the feed is over. Finally, in the case where it is not known beforehand how long the feed is - a RTCP BYE seems a reasonable way of doing it. Relying on the RTSP control channel may not always work, since it may be long gone. -Anup Rao. From rem-conf Thu Jul 08 15:15:09 1999 From rem-conf-request@es.net Thu Jul 08 15:15:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112MJn-00067G-00; Thu, 8 Jul 1999 15:06:59 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 112MJl-000670-00; Thu, 8 Jul 1999 15:06:57 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 88A821E018 for ; Thu, 8 Jul 1999 18:06:53 -0400 (EDT) Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id SAA09687; Thu, 8 Jul 1999 18:06:52 -0400 (EDT) Message-ID: <028e01bec98e$241d6dc0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: Cc: "Mathias Kretschmer" Subject: AAC-RTP payload format Date: Thu, 8 Jul 1999 18:06:33 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028B_01BEC96C.9CB7E160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_028B_01BEC96C.9CB7E160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please find attached the correct version of the I-D AAC MPEG-2 RTP payload format specification. The version on the IETF repository ( draft-ietf-avt-rtp-mpeg2aac-00.txt ) is not the correct one. all the best -Andrea Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com ------=_NextPart_000_028B_01BEC96C.9CB7E160 Content-Type: text/plain; name="draft-kretschmer-mpeg2aac-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-kretschmer-mpeg2aac-01.txt" Internet Engineering Task Force Kretschmer-AT&T/Basso-AT&T INTERNET DRAFT Civanlar-AT&T/Quackenbush-AT&T File:draft-kretschmer-mpeg2aac-01.txt Snyder-AT&T June 25, 1999 Expires: December 25, 1999 =20 RTP Payload Format for MPEG-2 AAC Streams 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. Abstract This document describes a payload format for transporting MPEG-2 AAC encoded data using RTP. MPEG-2 AAC is a recent standard from ISO/IEC for the coding multi-channel audio data. Several services provided by RTP are beneficial for MPEG-2 AAC encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-2 AAC data with other real-time streams . Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 1] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 1. Introduction The ISO/IEC MPEG-2 Advanced Audio Coding (AAC) [1] technology delivers unsurpassed multichannel audio quality at rates at or below 64 kbps/channel. It has a flexible bitstream syntax that supports from 1 to 48 audio channels, up to 16 subwoofer channels and up to 16 embedded data channels. AAC supports a wide range of sampling frequencies (from 16 kHz to 96 kHz) which enables it to have an extremely wide range of bitrates. This permits it to support applications ranging from professional or home theater sound systems to Internet music broadcast systems. The benefits of using RTP for MPEG-2 AAC data stream transport include: i. Ability to synchronize MPEG-2 AAC streams with other RTP payloads ii. Monitoring MPEG-2 AAC delivery performance through RTCP iii. Combining MPEG-2 AAC and other real-time data streams received from multiple end-systems into a set of consolidated streams through RTP mixers =20 iv. Converting data types, etc. through the use of RTP translators. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 1.1 Overview of MPEG-2 AAC AAC combines the coding efficiencies of a high resolution filter bank, a powerful model of audio perception, backward-adaptive prediction, joint channel coding, and Huffman coding to delivering excellent signal compression. In 1998 the MPEG Audio subgroup tested the family of MPEG audio coders (see http://www.tnt.uni-hannover.de/project/mpeg/ audio/public/w2006.pdf). The test results indicate that for a stereo signal, AAC at 96 kb/s has audio quality comparable to MPEG-3 Layer 3 ("mp3") at 128 kb/s. Therefore at equivalent quality levels, AAC offers approximately 1/3 greater compression than Layer 3. AAC is a block oriented, variable rate coding algorithm, which means that the AAC encoder reads 1024 samples of the input signal file and writes a variable number of compressed output bits that represent that block of input data. A sample can be one or more channels. Rate control can be used in the encoder such that the output bit rate is averaged to a predetermined rate, as would be required for constant-rate communication channels. Each block of AAC compressed bits is called a "raw data block", and it has the nice property that it can be decoded "stand-alone", that is, without knowledge of information in prior bitstream blocks. This is ideal for packet communication channels, in that if the payload of a packet is a single Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 2] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 raw data block, packet framing facilitates encoder and decoder synchronization and, most importantly, loss of a single packet does not impair the decodability of adjacent packets. 1.2 Bitstream Syntax As already stated, a raw data block represents audio data for a time period of 1024 samples and may also contain related information and other data. The syntax of an AAC bitstream is as follows: =3D> =20 =3D> [] where indicates the AAC bitstream, indicates intermediate tokens, indicates terminal tokens and [] indicates one or more occurance. is a token that indicates the end of a raw_data_block and is a variable length token that forces the total length of a raw_data_block to be an integral number of byes. In general, intermediate tokens are not an integral number of bytes in length. The tokens are a string of bits of varying length, and can be any of the following: represent a single audio channel represent a stereo presentation (2 = channels) a mechanism for multi-channel compression represent a special effects channel represent "user data" a mechanism for describing the bitstream=20 content a mechanism to use bits (for constant rate channels) The above can occur several times in a single raw_data_block. For example, the raw_data_block for a 5.1 surround sound signal would be: =20 ... corresponding to the center, left and right, left surround and right surround and effects channels. Multiple occurances of the are dis-ambiguated by means of a unique 4-bit id inside the . Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 3] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 2. Issues covered by this Payload Format 2.1 Repair Information to reconstruct lost AAC Frames A smart AAC decoder can mitigate the effects of lost packets using techniques such as interpolation in the spectral domain. However if the raw_data_block in a packet is perceptually very meaningful and also highly unpredictable (e.g. the onset of a symbol crash) then the encoder may choose to send repair information associated with that raw_data_block. We will call RepairData the variable size array containing such information. The RepairData in a given packet is typically associated with a raw_data_block that will be decoded in the future. The association between the raw_data_block and the RepairData can obtained by means of a specific field called RSEQ. The syntax of the RepairData and the AAC raw_data_block is the same. In practice, the RepairData can be a highly compressed monophonic version of the signal being transmitted. For example, an AAC stereo signal coded to an average rate of 96 kb/s corresponds to a raw_data_block size of 279 bytes. A RepairData version of that block, compressed to 16 kb/s would be 46 bytes. Given that perceptually critical blocks might occur only once per 100 or more blocks, the average rate imposed by the RepairData is very low. The usage of the RepairData information is similar to the one proposed = in[4]. RepairData MAY be provided for every frame but its provision is OPTIONAL, in general. 2.2 Fragmentation of AAC Frames Since it is advantagous to put one AAC raw_data_block per packet, it is desirable to try to limit the size of the AAC raw_data_block to less than the path-MTU. If this is not possible, the raw_data_block can be fragmented across several packets. In this case, the raw_data_block can be fragmented at boundaries and the LEN field used to indicate the length of the to within a byte and the UBITS field used to indicate the length of the to a bit. The LEN and UBITS information allows re-assembly of the raw_data_block without knowledge of the syntax of the bits within each in the raw_data_block. Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 4] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 2.3 Priority of AAC Frames Priority information is very important for AAC streaming over lossy channels since it allows to handle adaptively packet losses and/or given bandwidth constraints. Four priority levels are defined: 0 1 2 3. The priority level expresses the perceptual entropy of the AAC frame. Priority information is coded for every AAC frame in the Priority Quantifier (PQ) which is 2 bit in length. For a given RTP packet such PQs are organized in a Priority vector. 2.4 Interleaving of AAC Frames Instead of using a static interleaving scheme (i.e. 7x7) only frames with the same priority MUST be grouped. The sequence numbers SEQ of the AAC frames and RSEQ of REPAIRDATA are used to restore the actual order on the receiver side. Hence, the interleaving scheme does not have to be defined rigidly. 2.5 Example RTP Packet Sequence The example below shows how a sequence of AAC frames (a...p) with assigned priorities (0=3Dlow, 3=3Dhigh) MAY be grouped. =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | 0 | 2 | 3 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proposed interleaving/grouping of AAC frames and assigned RepairData R(x) being sent within the following RTP packet: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |a g j|b h k|c i l| d | e | f | m q | n | o | p | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | |R(d) |R(e) |R(f) | |R(n) |R(o) |R(p) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 5] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 3. RTP AAC Payload Format The AAC specific RTP payload consists of a 32 or 64 bit header, a RepairData array which is variable in size containing information needed to reconstruct lost AAC frames and a variable number of AAC frames. The header contains a vector of Priority Quantizers (PQ) specifying the priority of the current and previous packets to the decoder to reconstruct the original signal. The X bit specifies if the header contains 12 or 28 PQs.=20 REPAIRLEN specifies the length of the RepairData array expressed in 32bit words. REPAIRLEN MUST be set to 0 if the RepairData array is empty. Every REPAIRDATA array (AAC frame) is preceded by a sequence number SEQ (RSEQ) and a length specifier LEN (RLEN). In case of fragmented AAC frames UBITS specifies the number of unused bits in the last byte since frame fragments may not be byte aligned. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|REPAIRLEN |PRI VECTOR | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PRI VECTOR (continued), if X=3D=3D1 | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ |RSEQ |RLEN |REPAIRDATA 1 | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . | Repair | . | Data | . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |RSEQ |RLEN |REPAIRDATA N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ |SEQ |LEN |UBITS |AAC FRAME 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . | | . | | . | AAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = Frames | |SEQ |LEN |UBITS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |AAC FRAME N | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 6] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 PRI VECTOR: Priority vector. It contains either 12 or 28=20 Priority Quantifiers (PQ). The size of a PQ element is 2 bits. Hence, four different priority levels can be assigned to=20 an RTP packet. 0 means low and 3 means high priority. =20 The first PQ refers to the current packet. The following PQs refer to the most recent previous packets.=20 So, the vector looks like this: {PQ(t), PQ(t-1), PQ(t-2)...} X: Vector Extension, the priority vector uses 56 instead of 24 bits. Hence, another 32bit word is required. REPAIRLEN: The total number of 32bit words containing Repair=20 Data for previous frames. If REPAIRLEN=3D0 then there is no repair information.=20 RSEQ: The SEQ number of the AAC frame REPAIRDATA belongs to. RLEN: The length in bytes of REPAIRDATA. =20 REPAIRDATA: An 8bit aligned data array containing repair information.=20 This information can be ignored and is not mandatory. It should contain information that helps the decoder to=20 reconstruct a lost frame as close to the original as=20 possible. =20 SEQ: 8 bit. The sequence number of the AAC frame.=20 The application has to make sure that the sequence numbers of=20 interleaved frames to not overlap. LEN: 12 bit. The length of the actual AAC frame UBITS: 4 bit. The number of unused bits in the last byte of the AAC frame if the frame is fragmented.=20 3.1 RTP Header Fields Usage: The RTP header fields are used as follows: Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen. Marker (M) bit: Set to one to mark the last fragment (or only fragment) of an AAC frame. Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 7] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 Extension (X) bit: Defined by the RTP profile used. Timestamp (TS): 32-bit 90K Hz timestamp representing presentation time of the AAC frame. Same for all packets that make up the fragmented AAC frame.Timestamps are recommended to start at a random value for security reasons. SSRC: set as described in RFC1889 [2]. CC and CSRC fields are used as described in RFC 1889 [2]. 4. References [1] ISO/IEC 13818-7 Advanced Audio Coding (AAC) [2] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport Protocol for Real Time Applications RFC 1889, Internet Engineering Task Force, January 1996. [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [4] Perkins,Kouvelas,Hodson,Hardman,Handley,Bolot,Vega-Garcia, Fosse-Parisis RTP Payload for Redundant Audio Data=20 draft-ietf-avt-redundancy-revised-00.txt Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 8] =0CINTERNET-DRAFT RTP Payload Format for MPEG-2 AAC Streams June = 1999 5. Authors' Addresses Mathias Kretschmer AT&T Labs - Research 180 Park Ave. Florham Park, NJ 07932 USA e-mail: mathias@research.att.com Andrea Basso AT&T Labs - Research 100 Schultz Drive Red Bank, NJ 07701 USA e-mail: basso@research.att.com M. Reha Civanlar AT&T Labs - Research 100 Schultz Drive Red Bank, NJ 07701 USA e-mail: civanlar@research.att.com Schuyler R. Quackenbush AT&T Labs - Research 180 Park Ave. Florham Park, NJ 07932 USA e-mail: srq@research.att.com James H. Snyder AT&T Labs - Research 180 Park Ave. Florham Park, NJ 07932 USA e-mail: jhs@research.att.com Kretschmer/Basso/Civanlar/Quackenbush/Snyder [Page = 9] ------=_NextPart_000_028B_01BEC96C.9CB7E160-- From rem-conf Fri Jul 09 08:08:34 1999 From rem-conf-request@es.net Fri Jul 09 08:08:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112cB8-0006RF-00; Fri, 9 Jul 1999 08:03:06 -0700 Received: from hoemail1.lucent.com (hoemlsrv.firewall.lucent.com) [192.11.226.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 112cB7-0006R2-00; Fri, 9 Jul 1999 08:03:05 -0700 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA20335 for ; Fri, 9 Jul 1999 11:02:54 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Jul 1999 11:02:54 -0400 Message-ID: From: "Lyons, Terry G (Terry)" To: rem-conf@es.net Cc: "Lyons, Terry G (Terry)" Subject: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt Date: Fri, 9 Jul 1999 11:02:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is one other point to be corrected, which may be the source of the confusion: Table 1 should list G.722 as "frame" not "sample". G.722 operates on 2 audio samples at a time, producing 6 bits for the lower frequency subband and 2 bits for the upper subband. The G.722 frame is a single octet. Each encodes a fixed-length 125us block of audio. - terry.g.lyons@lucent.com +1 732 817 6016 > ---------- > From: tgl@mtgbcs.ho.lucent.com[SMTP:tgl@mtgbcs.ho.lucent.com] > Sent: Wednesday, July 07, 1999 6:27 PM > To: rem-conf@es.net > Cc: Lyons, Terry G (Terry) > Subject: Re: draft-ietf-avt-profile-new-06.txt > > The new version, on the road to Draft Standard, makes an unnecessary > change in the time-stamp unit for the audio encoding G.722, from 8000 > to 16000 Hz. This is not listed in section 9 "Changes from RFC 1890". > The change is inconsistent with prior implementations that comply with > RFC 1890, such as Table B-2/H.225.0(1998) part of the H.323 suite. > > PROPOSAL: Restore the clock rate of G.722 to 8000 Hz as it was. > > The raw sampling rate at a microphone is a distinct concept from the > time-stamp unit for encoded audio. The two need not be the same, as > G.722 demonstrates. Its encoder spits out one octet every 1/8000 sec, > which cannot be further subdivided in time. > > --------------------------------------------------- > Quoted from Request for Comments: 1890 > RTP Profile for Audio and Video Conferences with Minimal Control > > 6. Payload Type Definitions > > Table 2 defines this profile's static payload type values for the PT > field of the RTP data header. ... > > PT encoding audio/video clock rate channels > name (A/V) (Hz) (audio) > _______________________________________________________________ > 9 G722 A 8000 1 > > Table 2: Payload types (PT) for standard audio and video encodings > > --------------------------------------------------- > Quoted from draft-ietf-avt-profile-new-06.txt > RTP Profile for Audio and Video Conferences with Minimal Control > > 6 Payload Type Definitions > > Tables 4 and 5 define this profile's static payload type values for > the PT field of the RTP data header. > > PT encoding media type clock rate channels > name (Hz) > ___________________________________________________ > 9 G722 A 16000 1 > > Table 4: Payload types (PT) for audio encodings > > --------------------------------------------------- > > - terry.g.lyons@lucent.com +1 732 817-6016 > > From rem-conf Fri Jul 09 08:55:34 1999 From rem-conf-request@es.net Fri Jul 09 08:55:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112cyZ-0007YS-00; Fri, 9 Jul 1999 08:54:11 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 112cyW-0007YI-00; Fri, 9 Jul 1999 08:54:09 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jul 9 11:52:28 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA11345; Fri, 9 Jul 1999 11:52:22 -0400 (EDT) Message-ID: <37861AB6.EDE4019B@cs.columbia.edu> Date: Fri, 09 Jul 1999 11:52:22 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "Lyons, Terry G (Terry)" CC: rem-conf@es.net Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RTP does not care what the internal implementation of the codec is. G.722 states (pg. 1) that it transmit an "audio signal which is coded using 14 bits with 16 kHz sampling". That it happens to be converted into an octet emitted at 8,000 bytes/second is not relevant, as then any codec emitting 8,000 bytes/second would have an RTP clockrate of 8,000, which is clearly not intended. G.722, by any definition that I have heard, is a sample-based codec, as it operates on individual samples, not frames. Is is a SB-ADPCM codec, and ADPCM codec are classic examples of sample-based codecs. Thus, I believe that the old value of 8,000 Hz is plain technically wrong. If there's a large installed base, then we need to deal with this on an exception basis, but otherwise, the correct value is 16 kHz, sample-based. Henning From rem-conf Fri Jul 09 08:56:33 1999 From rem-conf-request@es.net Fri Jul 09 08:56:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112d0f-0007f6-00; Fri, 9 Jul 1999 08:56:21 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 112d0X-0007dT-00; Fri, 9 Jul 1999 08:56:20 -0700 Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Fri Jul 9 11:55:38 EDT 1999 Received: from localhost by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id LAA13109; Fri, 9 Jul 1999 11:55:38 -0400 (EDT) Date: Fri, 9 Jul 1999 11:55:38 -0400 (EDT) From: Ethendranath Bommaiah X-Sender: ethen@chair To: rem-conf@es.net, confctrl@isi.edu cc: Sanjoy Paul Subject: RTP support for Real Media ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I was wondering if Real G2 server supports RTP for real media (.rm and .ra) ? We have noticed that it does support RTP for other media like .au and .mpeg. However, with .rm and .ra the server returns "Protocol not supported" error for the SETUP message with transport set to RTP/AVP/TCP. We are using Real G2 server 6.0. Does Real plan to support RTP for .rm and .ra media in the future ? Or, is there a newer version that supports RTP already ? Any pointers will be greatly appreciated. Thanks, Ethen From rem-conf Fri Jul 09 09:21:23 1999 From rem-conf-request@es.net Fri Jul 09 09:21:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112dNB-0001Pt-00; Fri, 9 Jul 1999 09:19:37 -0700 Received: from ha1.rdc1.nj.home.com (mail.rdc1.nj.home.com) [24.3.128.66] (imail) by mail1.es.net with esmtp (Exim 1.81 #2) id 112dNA-0001Pj-00; Fri, 9 Jul 1999 09:19:36 -0700 Received: from streamcenter.com ([24.6.232.137]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990709161935.GGPQ6625.mail.rdc1.nj.home.com@streamcenter.com>; Fri, 9 Jul 1999 09:19:35 -0700 Message-ID: <3786203E.3EAA0461@streamcenter.com> Date: Fri, 09 Jul 1999 12:15:58 -0400 From: ravi narayan Organization: streamCENTER Inc X-Mailer: Mozilla 4.61 [en]C-AtHome0405 (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ethendranath Bommaiah CC: rem-conf@es.net, confctrl@isi.edu, Sanjoy Paul Subject: Re: RTP support for Real Media ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ethendranath Bommaiah wrote: > > I was wondering if Real G2 server supports RTP for real media (.rm and > .ra) ? We have noticed that it does support RTP for other media like > .au and .mpeg. However, with .rm and .ra the server returns "Protocol > not supported" error for the SETUP message with transport set to > RTP/AVP/TCP. We are using Real G2 server 6.0. > > Does Real plan to support RTP for .rm and .ra media in the future ? > Or, is there a newer version that supports RTP already ? > >from what i have seen, and heard from real, the answer to your question is "no". real does not support RTP for realmedia files. from talking to them, i get the feeling that they do not plan to support realmedia over RTP. the reason they cite is that RDT (their own data transport protocol now referred to as RDP i think) is tuned for the special needs of realmedia files. --ravi From rem-conf Fri Jul 09 09:25:29 1999 From rem-conf-request@es.net Fri Jul 09 09:25:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112dSb-0001kb-00; Fri, 9 Jul 1999 09:25:13 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 112dSa-0001ic-00; Fri, 9 Jul 1999 09:25:12 -0700 Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with ESMTP id SAA24668; Fri, 9 Jul 1999 18:24:24 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id SAA17491; Fri, 9 Jul 1999 18:23:52 +0200 (MET DST) Date: Fri, 9 Jul 1999 18:23:52 +0200 (MET DST) Message-Id: <199907091623.SAA17491@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Henning Schulzrinne Cc: "Lyons, Terry G (Terry)" , rem-conf@es.net Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt In-Reply-To: <37861AB6.EDE4019B@cs.columbia.edu> References: <37861AB6.EDE4019B@cs.columbia.edu> Mime-Version: 1.0 (generated by tm-edit 7.90) Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne writes: > G.722, by any definition that I have heard, is a sample-based codec My dim memory seems to say the ADPCM processing is done at an 8 kHz rate on each of the two sub-bands (produced by quadrature mirror filtering). Which I think is what Terry was talking about. On the other hand, we are not using a 50 Hz clock for GSM, neither are we using 13.5 MHz for video. So who cares? > Thus, I believe that the old value of 8,000 Hz is plain technically > wrong. If there's a large installed base, then we need to deal with this > on an exception basis, but otherwise, the correct value is 16 kHz, > sample-based. This is a major, interoperability-damaging change, so put the document back to field 1 (proposed standard), then. Or strike G.722 and put it into a separate standards track document -- then you can even introduce a G722-Terry and a G722-Henning. Or just put in a footnote*) that you think 8000 is kind of wrong, but not wrong enough to be changed. Gruesse, Carsten *) There are no footnotes in RFCs. Never mind. From rem-conf Fri Jul 09 09:25:46 1999 From rem-conf-request@es.net Fri Jul 09 09:25:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112dSs-0001lX-00; Fri, 9 Jul 1999 09:25:30 -0700 Received: from ihemail1.lucent.com (ihemlsrv.firewall.lucent.com) [192.11.222.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 112dSq-0001ky-00; Fri, 9 Jul 1999 09:25:29 -0700 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12336 for ; Fri, 9 Jul 1999 12:25:27 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 9 Jul 1999 12:25:27 -0400 Message-ID: From: "Lyons, Terry G (Terry)" To: Henning Schulzrinne Cc: rem-conf@es.net, "Lyons, Terry G (Terry)" Subject: RE: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt Date: Fri, 9 Jul 1999 12:25:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, My concern is to maintain alignment with H.225.0 as well as the original RFC 1890. If specs are published with different clock rates, there is bound to be confusion and misoperation. 8 kHz works fine; let's stick with it. The full text from which you quote is: Figure 1/G.722 identifies the main functional parts of the 64 kbit/s (7 kHz) audio codec as follows: i) 64 kbit/s (7 kHz) audio encoder comprising: - a transmit audio part which converts an audio signal to a uniform digital signal which is coded using 14 bits with 16 kHz sampling; - a SB-ADPCM encoder which reduces the bit rate to 64 kbit/s. The "transmit audio part" is an internal functional block that feeds the "SB-ADPCM encoder" functional block. The two together make up the G.722 audio encoder. It is not possible to map individual 16 kHz samples 1-1 to outputs. Samples are processed in pairs by the SB-ADPCM encoder. That is why the description as a "frame" encoder fits better. In the encoder principles in section 3, you'll see that there is a distinction of indexes "j" for 16 kHz and indexes "n" for 8 kHz. To get output x-out[n] you need to compute on pairs x-in[j-1] and x-in[j]. I don't dispute your description of plain ADPCM, eg. G.726, as "sample". But G.722 SB-ADPCM is different because of the frequency transform to separately encode the high and low subbands. - terry.g.lyons@lucent.com +1 732 817 6016 > ---------- > From: Henning Schulzrinne[SMTP:hgs@cs.columbia.edu] > Sent: Friday, July 09, 1999 11:52 AM > To: Lyons, Terry G (Terry) > Cc: rem-conf@es.net > Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt > > RTP does not care what the internal implementation of the codec is. > G.722 states (pg. 1) that it transmit an "audio signal which is coded > using 14 bits with 16 kHz sampling". That it happens to be converted > into an octet emitted at 8,000 bytes/second is not relevant, as then any > codec emitting 8,000 bytes/second would have an RTP clockrate of 8,000, > which is clearly not intended. > > G.722, by any definition that I have heard, is a sample-based codec, as > it operates on individual samples, not frames. Is is a SB-ADPCM codec, > and ADPCM codec are classic examples of sample-based codecs. > > Thus, I believe that the old value of 8,000 Hz is plain technically > wrong. If there's a large installed base, then we need to deal with this > on an exception basis, but otherwise, the correct value is 16 kHz, > sample-based. > > Henning > From rem-conf Fri Jul 09 12:27:40 1999 From rem-conf-request@es.net Fri Jul 09 12:27:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112gHp-0005E2-00; Fri, 9 Jul 1999 12:26:17 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 112gHo-0005Ds-00; Fri, 9 Jul 1999 12:26:16 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id MAA05481 for ; Fri, 9 Jul 1999 12:26:15 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.1b+Sun/SMI-SVR4) id MAA06263 for rem-conf@es.net; Fri, 9 Jul 1999 12:26:14 -0700 (PDT) Date: Fri, 9 Jul 1999 12:26:14 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199907091926.MAA06263@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Re: RTP support for Real Media ? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>from what i have seen, and heard from real, the answer to your question >>is "no". real does not support RTP for realmedia files. from talking to >>them, i get the feeling that they do not plan to support realmedia over >>RTP. the reason they cite is that RDT (their own data transport protocol >>now referred to as RDP i think) is tuned for the special needs of >>realmedia files. But Real is supporting the other direction, i.e. you can receive "MBone" sessions using G2... it'll even send RTCP. -Kevin From rem-conf Fri Jul 09 12:27:50 1999 From rem-conf-request@es.net Fri Jul 09 12:27:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112gGw-0005DQ-00; Fri, 9 Jul 1999 12:25:22 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 112gGv-0005DG-00; Fri, 9 Jul 1999 12:25:21 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id MAA05440; Fri, 9 Jul 1999 12:25:17 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.1b+Sun/SMI-SVR4) id MAA06226 for ; Fri, 9 Jul 1999 12:25:16 -0700 (PDT) Date: Fri, 9 Jul 1999 12:25:16 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199907091925.MAA06226@jackson.cs.ucsb.edu> To: ethen@dnrc.bell-labs.com, ravi@streamcenter.com Subject: Re: RTP support for Real Media ? Cc: confctrl@ISI.EDU, rem-conf@es.net, sanjoy@dnrc.bell-labs.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Fri Jul 09 18:29:15 1999 From rem-conf-request@es.net Fri Jul 09 18:29:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 112lq7-0001Lx-00; Fri, 9 Jul 1999 18:22:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 112lq5-0001Ln-00; Fri, 9 Jul 1999 18:22:01 -0700 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Jul 9 21:20:30 EDT 1999 Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA20430; Fri, 9 Jul 1999 21:20:29 -0400 (EDT) Message-ID: <37869FDD.11B62A49@cs.columbia.edu> Date: Fri, 09 Jul 1999 21:20:29 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "Lyons, Terry G (Terry)" CC: rem-conf@es.net Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list First, I agree that to minimize confusion, we may need to keep the old 8 kHz sampling rate. However, I disagree with the technical characterization of the sample rate, so this should probably be marked as a historical aberration rather than something that should be done for other subband codecs. Frame vs. sample: the QMF operates on the 16 kHz-sampled signal, splits it into two subbands, which are then subsampled at 8 kHz (since they are each bw-limited to 8 kHz). There is no requirement that I can see that the number of input samples is a multple of two, which would be an indication of a frame-based codec. Indeed, the QMF FIR filter operates over a range of 22 samples (pg. 15), but in an overlapping fashion, not as a block. I could be wrong here, but subband codecs are generally treated in the literature along with all the other sample-based codecs. Henning From rem-conf Sat Jul 10 10:04:44 1999 From rem-conf-request@es.net Sat Jul 10 10:04:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1130V6-0007GH-00; Sat, 10 Jul 1999 10:01:20 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 1130V5-0007Fr-00; Sat, 10 Jul 1999 10:01:19 -0700 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 KAA07303; Sat, 10 Jul 1999 10:00:17 -0700 (PDT) Date: Sat, 10 Jul 1999 10:00:10 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Modify avg_rtp_size calculation? Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: Since RFC 1890, the RTCP transmission interval algorithm in the RTP spec has included an estimator for the average RTCP packet size, maintained in the variable avg_rtcp_size. This average is calculated across all RTCP packets both sent and received. If one node sends longer packets, or multiple packets at once, then it will be consuming more than its fair share of the RTCP bandwidth. That could be fixed by having each node average only the packets it sends. The problem with making that change is that the interval calculated by different nodes might then vary significantly, causing the nodes with the longer interval to be timed out by nodes with shorter intervals. Should we leave the algorithm as is and ignore the potential for unfairness, or should we try to figure out some way to make the change work? -- Steve From rem-conf Sat Jul 10 10:04:47 1999 From rem-conf-request@es.net Sat Jul 10 10:04:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1130Vg-0007GT-00; Sat, 10 Jul 1999 10:01:56 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 1130Vf-0007G7-00; Sat, 10 Jul 1999 10:01:55 -0700 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 KAA07325; Sat, 10 Jul 1999 10:00:53 -0700 (PDT) Date: Sat, 10 Jul 1999 10:00:46 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Change G722 codec to 16000 Hz clock? Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: In the RTP A/V Profile RFC 1890, and therefore in H.225.0 (part of H.323) where RFC 1890 is incorporated, the RTP timestamp clock frequency for the G722 payload format / encoding was listed as 8000 Hz. In fact, the sampling frequency for G.722 is 16000 Hz since it is a 0 - 7 kHz codec. Therefore, in the draft revisions of the profile, the G722 entry in Table 1 and Table 4 has been changed to 16000. Terry Lyons has asked that the draft revisions be reverted back to 8000 for consistency with the 1890 and H.225.0 (which is important). Terry notes that G.722 produces octets at 8000 Hz, where each octet contains a two-bit high-band sample and a 6-bit low-band sample. So in some sense, 8000 would be the natural rate for processing of G722. On the other hand, Henning Schulzrinne believes this would fundamentally violate the notion of RTP clock rate = sample rate for audio codecs (excepting MPEG). If there are commercial implementations, we probably have to leave it at 8000, but clearly mark it as an exception due to a mistake, not because it is the technically right thing to do. Also, if you wanted to be able to switch between L16 or PCMU at 16000 and G.722 depending upon the bandwidth constraint, the inaccurate switch in clock frequencies might cause trouble. So, I'd like to hear comments on what we should do in this case. Has anyone implemented G722 encoding? -- Steve From rem-conf Sat Jul 10 10:04:47 1999 From rem-conf-request@es.net Sat Jul 10 10:04:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1130Tl-0007FT-00; Sat, 10 Jul 1999 09:59:57 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 1130Tj-0007FI-00; Sat, 10 Jul 1999 09:59:55 -0700 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 JAA07274; Sat, 10 Jul 1999 09:58:54 -0700 (PDT) Date: Sat, 10 Jul 1999 09:58:46 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Revision of SSRC collision algorithm? Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: There are a few questions raised just recently regarding the RTP spec and profile which we need to discuss in Oslo. To preview those questions, I'm sending a few messages, one question per each. In addition, Henning Schulzrinne already sent a message about the static payload type assigned to the CN (Comfort Noise) payload type, which is also in this list of recent questions. [Sorry these are so late -- I tried to send them when I first arrived in Oslo on Tuesday, but couldn't get a modem connection to work.] Henning Schulzrinne proposes that the SSRC collision algorithm be modified, and that the pseudo-code which describes it be replaced with pseudo-C. Henning suggests that a mobile phone sending RTP may just change its IP address as it moves, rather than using mobile IP mechanisms. This could work because the RTP SSRC and SDES information uniquely identifies the source, even if it changes IP addresses. (An address change could also happen at a gateway if, for example, routing or redundancy fallback occurs and packets come from a different interface.) The SSRC collision algorithm requires that the SSRC identifier be changed if the transport address changes in order to avoid the address change being considered a collision. Henning proposes instead that when a host changes its address it should leave the SSRC identifier unchanged and that the spec should say that receivers SHOULD keep packets from the new address and discard packets from the old address when this "collision" of addresses with the same SSRC identifier is detected. The spec says an implementation MUST include an algorithm similar to the one described in Section 8.2. The algorithm shown in pseudo-code keeps the packets from the old address and discards those from the new address which is the "right" approach for a genuine collision, based on the assumption that one wants to continue hearing the valid source that one was hearing before. If this event was an address change, the new source would be accepted once the old source timed out because no more packets were received. This is not intended to require that the policy be to ignore the new source. A different policy may be chosen and still have the algorithm be similar; I added a phrase about this in the most recent draft. Regarding replacing the existing pseudo-code with pseudo-C, the syntax I used in writing the existing algorithm was taken from an example provided at the time by the RFC Editor. The reason for the pseudo code is that Internet Standards are not supposed to include code (because they are supposed to specify what happens on the wire, not how to implement the protocol). I can get a new reading on this from the AD and the RFC Editor. -- Steve From rem-conf Sat Jul 10 10:04:47 1999 From rem-conf-request@es.net Sat Jul 10 10:04:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1130UH-0007G5-00; Sat, 10 Jul 1999 10:00:29 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 1130UG-0007FJ-00; Sat, 10 Jul 1999 10:00:28 -0700 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 JAA07281; Sat, 10 Jul 1999 09:59:27 -0700 (PDT) Date: Sat, 10 Jul 1999 09:59:19 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Distinct UDP ports for layered encodings? Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: The RTP spec says that UDP ports MUST be distinct for layered codings, but the SDP spec says this is illegal if the addresses differ. Here is the section from the RTP spec: It is RECOMMENDED that layered encoding applications (see Section 2.4) use a set of contiguous port numbers. The port numbers MUST be distinct because of a widespread deficiency in existing operating systems that prevents use of the same port with multiple multicast addresses, and for unicast, there is only one permissible address. Thus for layer n, the data port is P + 2n, and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct because multicast routing and group membership are managed on an address granularity. However, allocation of contiguous IP multicast addresses cannot be assumed because some groups may require different scopes and may therefore be allocated from different address ranges. And from the SDP spec: It is illegal for both multiple addresses to be specified in the "c=" field and for multiple ports to be specified in the "m=" field in the same session description. This is clearly a conflict. How should we resolve it? -- Steve From rem-conf Sat Jul 10 16:09:15 1999 From rem-conf-request@es.net Sat Jul 10 16:09:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1136C3-0004en-00; Sat, 10 Jul 1999 16:06:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 1136C2-0004ed-00; Sat, 10 Jul 1999 16:06:02 -0700 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Sat Jul 10 19:04:04 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.180]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA14985; Sat, 10 Jul 1999 19:04:03 -0400 (EDT) Message-ID: <3787D197.AFB2D850@dnrc.bell-labs.com> Date: Sat, 10 Jul 1999 19:04:55 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Revision of SSRC collision algorithm? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > > The SSRC collision algorithm requires that the SSRC identifier be > changed if the transport address changes in order to avoid the address > change being considered a collision. > > Henning proposes instead that when a host changes its address it > should leave the SSRC identifier unchanged and that the spec should > say that receivers SHOULD keep packets from the new address and > discard packets from the old address when this "collision" of > addresses with the same SSRC identifier is detected. I like this, but I have a question on the new mechanism. Why discard packets from the old address? Basically, if we don't even look at the transport address, just the SSRC, no change will be seen at all. Thus, packets from the "old" address can be used if they haven't come too late, and same with new ones. This assumes that the SN/TS space does not change when the transport address changes. For a mobile host, thats reasonable, no? On a related note, I think it does make sense to look at the transport address when an SSRC collision is detected (by means of SDES CNAME). In that case, the source transport address can be used to determine which of the two colliding hosts the media is from. The differentiation will fail if one of the colliding hosts is mobile and its transport address changes after the collision; but, this is a temporary condition - it should send a BYE and rejoin with a new SSRC. > Regarding replacing the existing pseudo-code with pseudo-C, the syntax > I used in writing the existing algorithm was taken from an example > provided at the time by the RFC Editor. The reason for the pseudo > code is that Internet Standards are not supposed to include code > (because they are supposed to specify what happens on the wire, not > how to implement the protocol). I can get a new reading on this from > the AD and the RFC Editor. But doesn't the new draft standard already have C code for the reconsideration stuff? The FEC draft has C code also... -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Jul 10 17:32:05 1999 From rem-conf-request@es.net Sat Jul 10 17:32:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1137RU-0005iu-00; Sat, 10 Jul 1999 17:26:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 1137RS-0005if-00; Sat, 10 Jul 1999 17:26:02 -0700 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Sat Jul 10 20:24:23 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.180]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA15336; Sat, 10 Jul 1999 20:24:23 -0400 (EDT) Message-ID: <3787E46A.E56C01BE@dnrc.bell-labs.com> Date: Sat, 10 Jul 1999 20:25:14 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Modify avg_rtp_size calculation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It does raise an interesting sort-of-DOS attack - I can ignore the RTCP rules, and send very large RTCP packets very frequently. This will tend to skew the average RTCP size estimates, causing the estimate to approach the size of the large packets I send. With a large estimate, the interval used by every other participant becomes large. This allows me, in effect, to slow down RTCP transmissions for everyone else in the group. Of course, I can also spoof lots of different SSRC and achieve the same effect... The DoS attacks aside, I'd be inclined not to change anything to fix the problem you describe. Fairness doesn't seem that important in this context; certainly its not worth any substantial changes to the algorithms. I suspect that fixing this might require a per-user average RTCP size to be maintained at each participant, and this will affect all of our other timing mechanisms. -Jonathan R. Stephen Casner wrote: > > To the AVT working group: > > Since RFC 1890, the RTCP transmission interval algorithm in the RTP > spec has included an estimator for the average RTCP packet size, > maintained in the variable avg_rtcp_size. This average is calculated > across all RTCP packets both sent and received. > > If one node sends longer packets, or multiple packets at once, then it > will be consuming more than its fair share of the RTCP bandwidth. > That could be fixed by having each node average only the packets it > sends. > > The problem with making that change is that the interval calculated by > different nodes might then vary significantly, causing the nodes with > the longer interval to be timed out by nodes with shorter intervals. > > Should we leave the algorithm as is and ignore the potential for > unfairness, or should we try to figure out some way to make the change > work? > -- Steve -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sun Jul 11 20:23:38 1999 From rem-conf-request@es.net Sun Jul 11 20:23:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113WWu-0001VP-00; Sun, 11 Jul 1999 20:13:20 -0700 Received: from proxy4.ba.best.com [206.184.139.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 113WWt-0001VF-00; Sun, 11 Jul 1999 20:13:19 -0700 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id UAA21833; Sun, 11 Jul 1999 20:12:38 -0700 (PDT) Message-Id: <3.0.5.16.19990711185634.08ef3bc8@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Sun, 11 Jul 1999 18:56:34 To: "Andrea Basso" From: Ross Finlayson Subject: Re: AAC-RTP payload format Cc: , "Mathias Kretschmer" In-Reply-To: <028e01bec98e$241d6dc0$6c82cf87@pcbasso.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Some comments on this draft ("draft-kretschmer-mpeg2aac-01.txt"): Unfortunately I found the draft rather confusing. This was due in part to my unfamiliarity with AAC (compared to regular MPEG audio), but also due to the fact that the draft doesn't make it particularly clear how the data that would make up an outgoing RTP packet would be produced by an implementation. In particular, which parts of this data would come directly from the AAC data stream, and which parts would be *derived* from the AAC data stream (& how)? The draft should have referenced RFC 2250 - the existing RTP payload format for MPEG - if only to explain why it is inappropriate for MPEG-2 AAC. Presumably the main (only?) reason why RFC 2250 cannot be used is that AAC frames look different from regular MPEG audio frames, and so a receiver could not reliably distinguish them. One desireable property of RFC 2250, however, is that an implementation can send (or receive) RTP-encapsulated MPEG audio data without having to know *anything* about its structure - only where the frame boundaries are. This makes it very easy for a RTP implementation to stream from/to MPEG audio data (whether streamed, or in a file). Is this property also true of your proposed format? The draft does not make this clear. How much would an implementation of your proposed format need to know about the internal structure of AAC data? In particular, where does the "repair data" come from? Does this come directly from the AAC data, or does it need to be 'generated' from the AAC data in some way? Again, the draft does not make this clear. It would be *really* desirable to have a RTP payload format for AAC that does not require an implementation to have a detailed knowledge of AAC internals. Perhaps, however, knowledge of AAC internals is necessary for including the "repair data"? If so, then perhaps two payload formats could be defined: a simple, non-repairing payload format (that doesn't require knowledge of AAC internals), and more complex, reparing format (that does)?? Other, more specific comments about the draft: Sections 1. and 1.1 contain too much 'marketing' language inappropriate for a protocol spec. In particular, the word "unsurpassed" in section 1. should be removed, as should the whole first paragraph of section 1.1. The draft refers to both AAC "raw data blocks" and "frames". How are these related (or are they the same)? Section 1.2, paragraph 2 "byes" should be "bytes" Section 1.2 Is the detailed expansion of the "" token relevant to the RTP packetization? Section 2.1 "symbol crash" should be "cymbal crash" Ross. From rem-conf Mon Jul 12 03:09:30 1999 From rem-conf-request@es.net Mon Jul 12 03:09:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113czA-0001Px-00; Mon, 12 Jul 1999 03:06:56 -0700 Received: from dialup26-43.net-star.net (machine1024) [206.135.73.43] by mail1.es.net with smtp (Exim 1.81 #2) id 113cz7-0001Pn-00; Mon, 12 Jul 1999 03:06:53 -0700 From: fueled@prontomail.com To: rem-conf@es.net Subject: FAILING FUEL STORAGE TANKS - Millennium Update Date: Mon, 12 Jul 1999 02:51:02 -0700 X-Sender: fueled@prontomail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list THIS FREE SERVICE ANNOUNCEMENT CAN SAVE YOUR COMPANY THOUSANDS. Please forward to the responsible party for evaluation. Fact: Power Plants in the year 2000 can shut down without warning. Back up systems & Fuel in them need to be serviced prior to the Millennium. Fact: 60 percent of all underground fuel storage tanks will fail in time of emergency. Our Fuel Sampling & Visual Analysis is a free service we offer for your peace of mind & protection. Fuel Filtration if needed is surprisingly inexpensive. CALL A.F.F.S. TODAY (800) 850-8680 Visit our website for full details. http://www.advancedfuel.com/freefuel_analysis.html Advanced Fuel Filtration Systems follows EPA guidelines and your own rejuvenated fuel is guaranteed to meet or exceed The American Society of Testing And Materials' Bottom Sediment and Water Test. REMOVES: This is a one time mailing and it is not necessary to reply for removal. You may subscribe to future newsletters that highlight industry news by calling the above number. From rem-conf Mon Jul 12 07:12:36 1999 From rem-conf-request@es.net Mon Jul 12 07:12:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113gm4-0006aE-00; Mon, 12 Jul 1999 07:09:40 -0700 Received: from is1-50.antd.nist.gov (is1-55.antd.nist.gov) [129.6.50.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 113gm3-0006a4-00; Mon, 12 Jul 1999 07:09:39 -0700 Received: from pion.ncsl.nist.gov (pion.ncsl.nist.gov [129.6.55.125]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA18607; Mon, 12 Jul 1999 10:02:42 -0400 (EDT) Received: (from wchang@localhost) by pion.ncsl.nist.gov (8.8.8/8.8.8) id KAA07000; Mon, 12 Jul 1999 10:08:00 -0400 (EDT) Date: Mon, 12 Jul 1999 10:08:00 -0400 (EDT) Message-Id: <199907121408.KAA07000@pion.ncsl.nist.gov> To: rem-conf@es.net Subject: tunneling between two subnets From: wchang@nist.gov (Wo Chang, x3439) X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear All, I must overlook something, somehow I can't tunnel multicast between a subnet with another subnet behind a firewall. I tested mrouted3.8 between two regular subnets and ran fine with vic and vat. But, then when I try to do the same setup with a subnet which sits behind a firewall, I can't see any activity >from either vic, vat, or srd. According to mrinfo, both subnets do see each others' tunnel and they are up. When I do the mtrace, I can see the reverse path from the remote host back to my host, but with 0 Lost/Sent and 0 pps for PctRate. When I do the map-mbone, I do see the tunnel between the two subnets. When I do the tcpdump on rtp, I only see the rtp traffic from my host to the firewall subnet but not the other way around. We later enable the multicast on the firewall router, but still no use. I tried to use metric 4 (since there are about 4 hops away) with threshold 64, no go. Then I tried with metric 1 with threshold 128, still no go. So, am I missing something? Thanks in advanced for any helps and pointers. Best regards, --Wo Chang From rem-conf Mon Jul 12 08:32:32 1999 From rem-conf-request@es.net Mon Jul 12 08:32:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113i0r-0000sB-00; Mon, 12 Jul 1999 08:29:01 -0700 Received: from gateway-gw.pictel.com (gateway.pictel.com) [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 113i0o-0000s1-00; Mon, 12 Jul 1999 08:29:00 -0700 Received: from pictel.com (roadrunner [140.242.64.4]) by gateway.pictel.com (8.9.2/8.9.2) with SMTP id LAA14099; Mon, 12 Jul 1999 11:28:54 -0400 (EDT) Received: from bonk.pictel.com by pictel.com (4.1/SMI-4.1) id AA07454; Mon, 12 Jul 99 11:28:05 EDT Received: from PPPtonyc by bonk.pictel.com (SMI-8.6/SMI-4.1) id LAA09929; Mon, 12 Jul 1999 11:28:02 -0400 Message-Id: <3.0.32.19990712112915.006bed88@bonk.pictel.com> X-Sender: tonyc@bonk.pictel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 Jul 1999 11:29:17 -0400 To: Henning Schulzrinne , "Lyons, Terry G (Terry)" From: Tony Crossman Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The G.722 sample rate/time stamp should remain at 8kHz. This is for reasons of backward compatibility, and a suitable explanation of the reason should be included for clarity. Of course, the time stamp should have been 16kHz, but this was a simple error which needs to be noted and maintained. If it important that the H.323 experts are made aware of this situation. All future coders which oprerate at a sample rate of 16kHz should also use 16kHz for the time stamp. Note, the recently Determined ITU wideband coder at 24 and 32 kbit/s will require a 16kHz time stamp if we follow the spirit of the RTP specifications. Tony Crossman At 01:20 AM 7/10/99 +0000, Henning Schulzrinne wrote: > > > > >First, I agree that to minimize confusion, we may need to keep the old 8 >kHz sampling rate. However, I disagree with the technical >characterization of the sample rate, so this should probably be marked >as a historical aberration rather than something that should be done for >other subband codecs. > >Frame vs. sample: the QMF operates on the 16 kHz-sampled signal, splits >it into two subbands, which are then subsampled at 8 kHz (since they are >each bw-limited to 8 kHz). There is no requirement that I can see that >the number of input samples is a multple of two, which would be an >indication of a frame-based codec. Indeed, the QMF FIR filter operates >over a range of 22 samples (pg. 15), but in an overlapping fashion, not >as a block. > >I could be wrong here, but subband codecs are generally treated in the >literature along with all the other sample-based codecs. > >Henning > > > > From rem-conf Mon Jul 12 13:33:52 1999 From rem-conf-request@es.net Mon Jul 12 13:33:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113mio-0007Og-00; Mon, 12 Jul 1999 13:30:42 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 113mii-0007OW-00; Mon, 12 Jul 1999 13:30:36 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA22829; Mon, 12 Jul 1999 16:30:35 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA28329; Mon, 12 Jul 1999 16:30:34 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <378A5064.C9F7CFE0@cs.columbia.edu> Date: Mon, 12 Jul 1999 16:30:28 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Modify avg_rtp_size calculation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > > To the AVT working group: > > Since RFC 1890, the RTCP transmission interval algorithm in the RTP > spec has included an estimator for the average RTCP packet size, > maintained in the variable avg_rtcp_size. This average is calculated > across all RTCP packets both sent and received. > > If one node sends longer packets, or multiple packets at once, then it > will be consuming more than its fair share of the RTCP bandwidth. > That could be fixed by having each node average only the packets it > sends. I agree with Jonathan that fairness isn't a prime consideration here. Longer RTCP packets would occur in two situations: - very verbose SDES information; in that case, it would probably be better for the sender to stagger the SDES information; - longer receiver list, e.g., because the receiver has been around longer than the rest or other network weirdness (e.g., TTL induced). Since this information is valuable for others, I don't see why it should be sending less frequently. > > The problem with making that change is that the interval calculated by > different nodes might then vary significantly, causing the nodes with > the longer interval to be timed out by nodes with shorter intervals. > > Should we leave the algorithm as is and ignore the potential for > unfairness, or should we try to figure out some way to make the change > work? > -- Steve -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Jul 12 14:19:40 1999 From rem-conf-request@es.net Mon Jul 12 14:19:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113nSk-000141-00; Mon, 12 Jul 1999 14:18:10 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 113nSi-00012K-00; Mon, 12 Jul 1999 14:18:08 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id F24B81E003; Mon, 12 Jul 1999 17:18:03 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA27790; Mon, 12 Jul 1999 17:18:03 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA00290; Mon, 12 Jul 1999 14:18:02 -0700 (PDT) Message-Id: <199907122118.OAA00290@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: wchang@nist.gov Subject: Re: tunneling between two subnets Cc: rem-conf@es.net Date: Mon, 12 Jul 1999 14:18:01 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You probably aren't passing IP protocol 4 packets through the firewall. You described exactly the symptoms of passing only IGMP and not IP-in-IP. Bill From rem-conf Mon Jul 12 14:40:34 1999 From rem-conf-request@es.net Mon Jul 12 14:40:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113nlp-0001yW-00; Mon, 12 Jul 1999 14:37:53 -0700 Received: from is1-50.antd.nist.gov (is1-55.antd.nist.gov) [129.6.50.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 113nln-0001yC-00; Mon, 12 Jul 1999 14:37:51 -0700 Received: from pion.ncsl.nist.gov (pion.ncsl.nist.gov [129.6.55.125]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id RAA27556; Mon, 12 Jul 1999 17:30:53 -0400 (EDT) Received: (from wchang@localhost) by pion.ncsl.nist.gov (8.8.8/8.8.8) id RAA07919; Mon, 12 Jul 1999 17:36:13 -0400 (EDT) Date: Mon, 12 Jul 1999 17:36:13 -0400 (EDT) Message-Id: <199907122136.RAA07919@pion.ncsl.nist.gov> To: fenner@research.att.com Subject: Re: tunneling between two subnets Cc: rem-conf@es.net From: wchang@nist.gov (Wo Chang, x3439) X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Bill, Thanks for your response, and I think you're right! I'll check the router to make sure I have the Protocol 4 enable. Thanks again! --Wo Chang > From rem-conf-request@es.net Mon Jul 12 17:19 EDT 1999 > From: Bill Fenner > MIME-Version: 1.0 > To: wchang@nist.gov > Subject: Re: tunneling between two subnets > Cc: rem-conf@es.net > Date: Mon, 12 Jul 1999 14:18:01 -0700 > Versions: dmail (solaris) 2.2c/makemail 2.8t > X-Mailing-List: > X-Loop: rem-conf@es.net > Precedence: list > Status: RO > X-Status: > X-Keywords: > X-UID: 123 > > > You probably aren't passing IP protocol 4 packets through the > firewall. You described exactly the symptoms of passing only > IGMP and not IP-in-IP. > > Bill > > From rem-conf Mon Jul 12 14:41:59 1999 From rem-conf-request@es.net Mon Jul 12 14:41:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113npW-0002AX-00; Mon, 12 Jul 1999 14:41:42 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 113npV-0002AK-00; Mon, 12 Jul 1999 14:41:41 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id OAA25630 for ; Mon, 12 Jul 1999 14:41:35 -0700 Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Mon, 12 Jul 1999 14:41:32 -0700 Received: from [17.219.108.32] (rara1ppp24.apple.com [17.219.108.32]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id OAA05096 for ; Mon, 12 Jul 1999 14:41:29 -0700 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <3.0.32.19990712112915.006bed88@bonk.pictel.com> Date: Mon, 12 Jul 1999 14:40:50 -0700 To: rem-conf@es.net From: Dave Singer Subject: Re: G.722 frame -- Re: draft-ietf-avt-profile-new-06.txt Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I tend to agree that the static payload should remain anomalous. However, perhaps there should also be a payload name for G722 and authors encouraged to map another payload type to that name at 16kHz, as a preferred alternative. Perhaps it is even time to encourage explicit mappings for even the current static types, with a view to permitting over-riding or even retiring the static types down the road? David Singer Apple Computer/QuickTime From rem-conf Mon Jul 12 14:56:54 1999 From rem-conf-request@es.net Mon Jul 12 14:56:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113o3B-0003UH-00; Mon, 12 Jul 1999 14:55:49 -0700 Received: from sunblast.eng.usf.edu [131.247.14.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 113o3A-0003U7-00; Mon, 12 Jul 1999 14:55:48 -0700 Received: from localhost (padhye@localhost [127.0.0.1]) by sunblast.eng.usf.edu (8.8.8/8.8.7) with ESMTP id RAA27910 for ; Mon, 12 Jul 1999 17:55:45 -0400 (EDT) Date: Mon, 12 Jul 1999 17:55:44 -0400 (EDT) From: Chinmay Padhye X-Sender: padhye@sunblast To: rem-conf@es.net Subject: RTCP Question. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello: I had a question regarding the information present in a RTCP packet. Incase FEC is used to protect a voice stream against loss, then does the receiver send the loss rate after reconstruction or does it send loss rate before reconstruction. How will a sender know how effective its redundancy sheme is? Thanks for the help. Sincerely, Chinmay V. P. From rem-conf Mon Jul 12 21:03:40 1999 From rem-conf-request@es.net Mon Jul 12 21:03:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113tgS-0003EE-00; Mon, 12 Jul 1999 20:56:44 -0700 Received: from (hotmail.com) [12.29.42.61] by mail1.es.net with smtp (Exim 1.81 #2) id 113tgQ-0003E4-00; Mon, 12 Jul 1999 20:56:42 -0700 From: To: rem-conf@es.net Subject: Confidential Date: Tue, 13 Jul 1999 00:09:43 Message-Id: <671.274933.446538@unknown> Reply-To: parsolutions@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ParNet Solutions, Inc. would like to welcome all new readers of our informative and exciting corporate stock reports! If you would like to be removed from this mailing list, please e-mail us at plzdelete@hotmail.com and type REMOVE in the subject line. Please read our disclaimer at the bottom of the page. Today, we would like to share with you a new client of ours, which looks to have a very exciting future and some real potential! How would you have liked to own Papa Johns Pizza (NASDAQ-PZZA) in 1995, at the time a little known pizza company, at $3 dollars per share and have it soar to over $45 dollars per share in only 3 years! A gain of 1500%! A major winner! How about leading on-line grocer Peapod (NASDAQ-PPOD) at $2 11/16 early this year only to have it soar to over $15 ½! A gain of over 500%! Who wouldn't have wanted to own these major winners, but as the saying goes hindsight is always 20/20.We would like to now share with you a little foresight. Take the red-hot pizza industry, over $35 billion per year and the new and exciting on-line grocery business, combine the two under one corporate umbrella and you've got something exciting! The company that has done just that is Prime Marketing, Inc., OTCBB-PMMI currently traded at only $.53 bid by $.625 offer, trading just off the 52 week low of $.50 and no where near the high of $5 ½. This company is poised to make a run at that 52 week high of $5 ½ which would be a move in excess of 800%! Potentially there is a tremendous opportunity to profit. Prime Marketing, Inc. (PMMI) currently operates two divisions. The first is their rapidly growing pizza company, Sicilian Crust, Inc. The Sicilian Crust, Inc. manufactures and distributes Par Baked Sicilian Pizza Crust and related products to numerous major supermarket giants on the East Coast, primarily the Tri-state area, including King Kullen, ShopRite, Pathmark, Western Beef, Grady's American Grill also Giants Stadium (home of the NY Giants and Jets), SplishSplash Water Parks, AdventureLand Theme parks and many many more! The Sicilian Crust has sold over $1,000,000.00 in Pizza in their first full 12 months of production! The company just finished a major expansion of their NY facility and increase capacity 5 fold. The company plans to launch nationally in the 4th quarter, which will have a dramatic effect on their revenues! Growth looks to be staggering! Check out their web-site and order pizza on-line at www.siciliancrust.com. The second division gives Prime Marketing the dot COM play in the on-line grocer division, www.foodsoftheworld.net was recently launched to rave reviews! The site focuses on offering people access to high quality specialty and ethnic foods delivered to their doorsteps nationwide! The on-line grocer sector is as hot as any on the net and the niche that Prime Marketing (PMMI) has found currently faces minimal competition and should allow them to get a foot hold in the specialty industry. Amazon.com (NASDAQ-AMZN) just invested $40 million in Homegrocer.com, this is the next boom industry and Prime Marketing (PMMI) is in the right place at the right time! This is an exciting opportunity and this stock looks poised for tremendous movement over the next few months, as always do your homework and good luck! If you would like to be removed from our mailing list please e-mail us at plzdelete@hotmail.com . If you have questions or comments please e-mail us at parsolutions@hotmail.com . Disclaimer: Parnet Solutions, Inc. is an independent electronic publication, any and all information disseminated by ParNet Solutions, Inc. is provided by our clients and believed to be factual, however ParNet Solutions makes no guarantees as to the accuracy of this information. ParNet Solutions, Inc. accepts no responsibility for "flames", threats, or other repercussions you may receive from recipients of your e-mail or your isp or hosting service when using our bulk e-mail services. It is the client's responsibility to research and understand your ISP's or hosting service's policies on bulk e-mail before using this service. It also remains the client's responsibility to make sure your mailing is in compliance with any local or state laws in regards to bulk e-mail. ParNet Solutions, Inc. is paid to disseminate information and in compliance with certain regulatory agencies will disclose the compensation of certain clients. (Stated Below) ParNet Solutions, Inc. has received 2000 shares of free trading stock of Prime Marketing, Inc., a publicly traded company, as compensation for the dissemination of certain corporate developments to the public. The information published has been provided by the company or its affiliates and is believed to be factual, however ParNet makes no guarantees as to the accuracy of this information. In no way should the publishing of this or any information be misconstrued as a solicitation to buy or sell any security or product, but simply for informational purposes. From rem-conf Tue Jul 13 00:41:10 1999 From rem-conf-request@es.net Tue Jul 13 00:41:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113x9S-0001kp-00; Tue, 13 Jul 1999 00:38:54 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 113x9R-0001kQ-00; Tue, 13 Jul 1999 00:38:53 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 13 Jul 1999 08:38:45 +0100 To: Chinmay Padhye cc: rem-conf@es.net Subject: Re: RTCP Question. In-reply-to: Your message of "Mon, 12 Jul 1999 17:55:44 EDT." Date: Tue, 13 Jul 1999 08:38:44 +0100 Message-ID: <534.931851524@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Chinmay Padhye writes: > I had a question regarding the information present in a RTCP >packet. Incase FEC is used to protect a voice stream against loss, then >does the receiver send the loss rate after reconstruction or does it send >loss rate before reconstruction. Before reconstruction. > How will a sender know how effective its redundancy sheme is? I don't think there is a clear way of knowing that from RTCP RR packets as they stand. One could envisage an extension to RTCP which made this available, if it became necessary. Colin From rem-conf Tue Jul 13 02:17:32 1999 From rem-conf-request@es.net Tue Jul 13 02:17:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 113yfF-0004pN-00; Tue, 13 Jul 1999 02:15:49 -0700 Received: from dfssl.exchange.microsoft.com [131.107.88.59] by mail1.es.net with esmtp (Exim 1.81 #2) id 113yfE-0004oO-00; Tue, 13 Jul 1999 02:15:48 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.7) id <341DY8DL>; Tue, 13 Jul 1999 02:13:30 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: 'Stephen Casner' , rem-conf@es.net Subject: RE: Distinct UDP ports for layered encodings? Date: Tue, 13 Jul 1999 02:13:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.7) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > The port numbers MUST be > distinct because of a widespread deficiency in existing operating > systems that prevents use of the same port with multiple multicast > addresses, and for unicast, there is only one permissible address. I don't think there is any particular reason why one MUST use different port numbers for unicast. RTP certainly allows multiple unicast flows to be sent to the same port number, as long as the SSRC is different for each flow. I don't think there are any operating system problems that would force one to use different ports for unicast. However, it is quite correct that there are OS reasons why the ports should be different when using multiple multicast groups. It does not look like the SDP spec gives a good justification for why different ports would not be allowed. So my suggestion is that we consider revising the SDP spec. Anders From rem-conf Tue Jul 13 03:28:29 1999 From rem-conf-request@es.net Tue Jul 13 03:28:27 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 113zlq-0005FI-00; Tue, 13 Jul 1999 03:26:42 -0700 Received: from sfr-tgn-sfn-vty10.as.wcom.net ([216.192.33.10] helo=machine1024) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 113zln-0005F8-00; Tue, 13 Jul 1999 03:26:40 -0700 From: fueled@prontomail.com To: rem-conf@es.net Subject: FAILING FUEL STORAGE TANKS - Millennium Update Date: Tue, 13 Jul 1999 03:13:18 -0700 X-Sender: fueled@prontomail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list THIS FREE SERVICE ANNOUNCEMENT CAN SAVE YOUR COMPANY THOUSANDS. Please forward to the responsible party for evaluation. Fact: Power Plants in the year 2000 can shut down without warning. Back up systems & Fuel in them need to be serviced prior to the Millennium. Fact: 60 percent of all underground fuel storage tanks will fail in time of emergency. Our Fuel Sampling & Visual Analysis is a free service we offer for your peace of mind & protection. Fuel Filtration if needed is surprisingly inexpensive. CALL A.F.F.S. TODAY (800) 850-8680 Visit our website for full details. http://www.advancedfuel.com/freefuel_analysis.html Advanced Fuel Filtration Systems follows EPA guidelines and your own rejuvenated fuel is guaranteed to meet or exceed The American Society of Testing And Materials' Bottom Sediment and Water Test. REMOVES: This is a one time mailing and it is not necessary to reply for removal. You may subscribe to future newsletters that highlight industry news by calling the above number. From rem-conf Tue Jul 13 05:45:09 1999 From rem-conf-request@es.net Tue Jul 13 05:45:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1141qP-0003ND-00; Tue, 13 Jul 1999 05:39:33 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 1141qN-0003Mj-00; Tue, 13 Jul 1999 05:39:31 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 26DD01E003; Tue, 13 Jul 1999 08:39:30 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA10312; Tue, 13 Jul 1999 08:39:28 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id FAA04323; Tue, 13 Jul 1999 05:39:28 -0700 (PDT) Message-Id: <199907131239.FAA04323@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: anderskl@exchange.microsoft.com Subject: RE: Distinct UDP ports for layered encodings? Cc: casner@cisco.com, rem-conf@es.net Date: Tue, 13 Jul 1999 05:39:28 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >It does not look like the SDP spec gives a good justification for why >different ports would not be allowed. So my suggestion is that we consider >revising the SDP spec. My recollection is that it was unclear how to interpret multiple ports with multiple addresses (e.g. do you use all ports on all addresses or certain ports with certain addresses or ...) so we punted completely. It may be that a straightforward interpretation is possible (e.g. if there are the same number of ports specified as addresses then you pair up ports and addresses 1-1, else you punt). Bill From rem-conf Tue Jul 13 06:04:37 1999 From rem-conf-request@es.net Tue Jul 13 06:04:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11429S-0004Ab-00; Tue, 13 Jul 1999 05:59:14 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11429R-00040R-00; Tue, 13 Jul 1999 05:59:13 -0700 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 FAA06160; Tue, 13 Jul 1999 05:58:05 -0700 (PDT) Date: Tue, 13 Jul 1999 05:57:56 -0700 (Pacific Daylight Time) From: Stephen Casner To: "Anders Klemets (Exchange)" cc: rem-conf@es.net Subject: RE: Distinct UDP ports for layered encodings? In-Reply-To: Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 13 Jul 1999, Anders Klemets (Exchange) wrote: > I don't think there is any particular reason why one MUST use different port > numbers for unicast. RTP certainly allows multiple unicast flows to be sent > to the same port number, as long as the SSRC is different for each flow. I > don't think there are any operating system problems that would force one to > use different ports for unicast. See section 5.2 for general arguments why not to do multiplexing of different RTP sessions using the SSRC id. But specifically for the layered encodings, the spec says: For layered encodings transmitted on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution. When a source discovers that it has collided, it transmits an RTCP BYE message on only the base layer but changes the SSRC identifier to the new value in all layers. So the RTP sessions need to be kept unique, which means separate ports. Or the above gets changed. > However, it is quite correct that there are OS reasons why the ports should > be different when using multiple multicast groups. OK, given they are different for mcast, then unicast should behave the same way. > It does not look like the SDP spec gives a good justification for why > different ports would not be allowed. So my suggestion is that we consider > revising the SDP spec. Perhaps we can have this be the start of the draft that Mark Handley suggested to contain SDP spec errors and updates. Probably this would say someting following Bill Fenner's suggestion of 1-1 mapping or punt. -- Steve From rem-conf Tue Jul 13 07:28:33 1999 From rem-conf-request@es.net Tue Jul 13 07:28:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1143PS-0000JO-00; Tue, 13 Jul 1999 07:19:50 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1143PQ-0000Iy-00; Tue, 13 Jul 1999 07:19:48 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 13 Jul 1999 15:19:16 +0100 To: rem-conf@es.net Subject: Revised AVT agenda Date: Tue, 13 Jul 1999 15:19:16 +0100 Message-ID: <1380.931875556@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Enclosed is a revised agenda for the audio/video transport working group meeting in Olso. We have an additional presentation on multiplexing in the Thursday session, and the order of presentation during that session has changed to accomodate clashes with other working groups. Please note that we are very short of time, and would appreciate those presenting to be as brief as possible. Colin Audio/Video Transport WG A G E N D A Wednesday, 14 July at 09:00-11:30 ================================= - Status and progress since last meeting (Casner) 10 - SSRC sampling - Guidelines - QCELP - Update on RTP specification and audio/video profile (Casner) 20 draft-ietf-avt-rtp-new-04.txt, .ps draft-ietf-avt-profile-new-06.txt, .ps draft-ietf-avt-rtp-mime-00.txt draft-ietf-avt-rtcp-bw-00.txt - RTP interoperability statement and testing strategies draft-ietf-avt-rtp-interop-00.txt (Perkins) 10 draft-ietf-avt-rtptest-00.txt (Perkins) 10 draft-ietf-avt-rtcptest-01.txt (Rosenberg) 10 Discussion 10 - RTP MIB draft-ietf-avt-rtp-mib-05.txt (Baugher) 5 - RTP Payload for DTMF tones draft-ietf-avt-tones-00.txt (Petrack) 10 - RTP Payload for Generic FEC draft-ietf-avt-fec-06.txt (Rosenberg) 5 - Report on intermin meeting on transport of MPEG-4 (Civanlar) 5 - RTP Payload for MPEG-4 with Scaleable & Flexible Error Resiliency draft-guillemot-genrtp-01.txt (Wesner) 20 - RTP Payload for DV video draft-ietf-avt-dv-video-00.txt (Kobayashi) 10 - RTP encapsulation for 12-bit DV audio draft-kobayashi-dv-audio12-00.txt (Kobayashi) 10 Thursday, 15 July at 15:30-17:30 ================================ - A Taxonomy of Feedback for Multicast draft-hnrs-rmt-avt-feedback-00.txt (Rosenberg) 10 - Profile for unicast RTCP (Casner) 10 - Discussion of new profiles/feedback mechanisms 5 - Header compression for RTP/UDP/IP over cellular links draft-degermark-crtp-cellular-00.txt, .ps (Degermark) 20 draft-jonsson-robust-hc-00.txt - Multiplexing header-compressed RTP over PPP draft-pazhyannur-avt-pppmux-00.txt (Pazhyannur) 10 - Tunneled Compressed RTP draft-wing-avt-tcrtp-00.txt (Koren) 10 - Multiplexing scheme for RTP flows between Access Routers draft-ietf-avt-multiplexing-rtp-00.txt (El-Khatib) 10 - RTP Payload for AAC audio draft-kretschmer-mpeg2aac-00.txt (?) (Kretschmer) 10 - RTP Payload for real-time pointers draft-civanlar-rtp-pointer-00.txt (Civanlar) 10 - RTP Payload for Text Conversation draft-hellstrom-avt-rtp-text-00.txt (Hellström) 10 - RTP payload for virtual worlds draft-stewart-avt-00.txt (Stewart) 15 From rem-conf Tue Jul 13 09:17:07 1999 From rem-conf-request@es.net Tue Jul 13 09:17:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1145BW-0004OY-00; Tue, 13 Jul 1999 09:13:34 -0700 Received: from dfssl.exchange.microsoft.com [131.107.88.59] by mail1.es.net with esmtp (Exim 1.81 #2) id 1145BU-0004NL-00; Tue, 13 Jul 1999 09:13:32 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.7) id <341DZBFH>; Tue, 13 Jul 1999 09:11:10 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: 'Stephen Casner' Cc: rem-conf@es.net Subject: RE: Distinct UDP ports for layered encodings? Date: Tue, 13 Jul 1999 09:10:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.7) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > For layered encodings transmitted on separate RTP sessions (see > Section 2.4), a single SSRC identifier space SHOULD be used across > the sessions of all layers and the core (base) layer SHOULD be used > for SSRC identifier allocation and collision resolution. OK, since the spec says that one "SHOULD" use the same SSRC on all layers, it actually means that they "may" be different. And if the SSRC's are different, then it is no longer necssary to transmit each layer to a different port, when using unicast. Therefore, I suggest that the text in the RTP spec which says that different layers "MUST" be sent on different ports, be changed to "SHOULD" for unicast RTP. For multicast RTP, there are indeed specific operating system problems that require the use of "MUST". But those problems don't apply to unicast RTP. I don't think it is good to impose these kinds of restrictions on the usage of unicast RTP, unless there is a good reason. Anders From rem-conf Tue Jul 13 09:22:53 1999 From rem-conf-request@es.net Tue Jul 13 09:22:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1145Jl-0004l8-00; Tue, 13 Jul 1999 09:22:05 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 1145Jk-0004kd-00; Tue, 13 Jul 1999 09:22:04 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 31F834CE01; Tue, 13 Jul 1999 12:22:03 -0400 (EDT) Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id MAA26279; Tue, 13 Jul 1999 12:22:01 -0400 (EDT) Message-ID: <007901becd4b$c98f3700$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: "Ross Finlayson" Cc: , "Mathias Kretschmer" , , Subject: Re: AAC-RTP payload format Date: Tue, 13 Jul 1999 12:21:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ross, thanks for your comments. >Unfortunately I found the draft rather confusing. This was due in part to >my unfamiliarity with AAC (compared to regular MPEG audio), but also due to >the fact that the draft doesn't make it particularly clear how the data >that would make up an outgoing RTP packet would be produced by an >implementation. In particular, which parts of this data would come >directly from the AAC data stream, and which parts would be *derived* from >the AAC data stream (& how)? While the AAC frames, referred also as "AAC raw_data_blocks" in the draft come from the AAC stream, the piority information and the priority vector is computed by the encoder/packetizer and are not integral part of the AAC stream. Note while priority of the AAC frames is an intrinsic property of the AAC stream, these priorities can be computed differently. There are four AAC frame types: long (L) , short (S) , start (T) , and stop (P). Start frames are used to transition smoothly from long frames to short ones, and stop frames are used to transition smoothly from short frames to long ones. An example algorithm for computing the frame priorities is the following. In the following very simple scheme, we use only three priority levels: low, mid, and high. High priority frames comprise all shorts, stops, and starts. Mid priority frames comprise long frames adjacent to start frames or stop frames. Low priority frames are those adjacent only to other long frames. An example: sequence no: 012345678 frames: LLLTSPLLL priorities: llmhhhmll where: L == long frame T == start frame S == short frame P == stop frame l == low priority m == mid priority h == high priority We believe that, just as there are many MP3 implementations with many different levels of quality, so could different implementors create different methods for identifying "priority" as well as repair information in AAC. Thus it is important that the payload format has placeholders to carry effectively the priority as well as the repair information leaving their optional usage to the specific implementation. We plan to add an appendix to the draft with a description of algorithms (as the one mentioned) for priority and repair information computation. >The draft should have referenced RFC 2250 - the existing RTP payload format >for MPEG - if only to explain why it is inappropriate for MPEG-2 AAC. >Presumably the main (only?) reason why RFC 2250 cannot be used is that AAC >frames look different from regular MPEG audio frames, and so a receiver >could not reliably distinguish them. > >One desireable property of RFC 2250, however, is that an implementation can >send (or receive) RTP-encapsulated MPEG audio data without having to know >*anything* about its structure - only where the frame boundaries are. This >makes it very easy for a RTP implementation to stream from/to MPEG audio >data (whether streamed, or in a file). > >Is this property also true of your proposed format? The draft does not >make this clear. How much would an implementation of your proposed format >need to know about the internal structure of AAC data? In particular, >where does the "repair data" come from? Does this come directly from the >AAC data, or does it need to be 'generated' from the AAC data in some way? >Again, the draft does not make this clear. > >It would be *really* desirable to have a RTP payload format for AAC that >does not require an implementation to have a detailed knowledge of AAC >internals. Perhaps, however, knowledge of AAC internals is necessary for >including the "repair data"? If so, then perhaps two payload formats could >be defined: a simple, non-repairing payload format (that doesn't require >knowledge of AAC internals), and more complex, reparing format (that does)?? I agree with you on this. A reference with RFC 2250 will be added in the next version of the draft. I think we do not need two separate payloads definitions if in the current draft the priority information is made optional as the repair information is. Andrea Basso Jim Snyder From rem-conf Tue Jul 13 09:31:51 1999 From rem-conf-request@es.net Tue Jul 13 09:31:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1145Rn-000659-00; Tue, 13 Jul 1999 09:30:23 -0700 Received: from mercury.sun.com [192.9.25.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 1145Rm-00064y-00; Tue, 13 Jul 1999 09:30:22 -0700 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02382; Tue, 13 Jul 1999 09:30:21 -0700 (PDT) Received: from valathar (valathar.Eng.Sun.COM [129.146.122.176]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id JAA17950; Tue, 13 Jul 1999 09:30:19 -0700 (PDT) Date: Tue, 13 Jul 1999 09:30:20 -0700 (PDT) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: RE: Distinct UDP ports for layered encodings? To: Stephen Casner Cc: "Anders Klemets (Exchange)" , rem-conf@es.net In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > On Tue, 13 Jul 1999, Anders Klemets (Exchange) wrote: > > I don't think there is any particular reason why one MUST use different port > > numbers for unicast. RTP certainly allows multiple unicast flows to be sent > > to the same port number, as long as the SSRC is different for each flow. I > > don't think there are any operating system problems that would force one to > > use different ports for unicast. By doing this, this leads to the interpretation that one could mix audio and video on the same RTP session. This was something that we are trying to avoid. > > See section 5.2 for general arguments why not to do multiplexing of > different RTP sessions using the SSRC id. But specifically for the > layered encodings, the spec says: > > For layered encodings transmitted on separate RTP sessions (see > Section 2.4), a single SSRC identifier space SHOULD be used across > the sessions of all layers and the core (base) layer SHOULD be used > for SSRC identifier allocation and collision resolution. When a > source discovers that it has collided, it transmits an RTCP BYE > message on only the base layer but changes the SSRC identifier to the > new value in all layers. > > So the RTP sessions need to be kept unique, which means separate > ports. Or the above gets changed. I like the wording just the way it is. Steve Mccanne and I thought about this for awhile when we first proposed the changes. The simplest and easiest solution was to use different ports with the same SSRC. This allowed one to easily identify which layer and where it belonged without complicating implementation with alot of complicated code. You knew exactly which layer was which. > > > However, it is quite correct that there are OS reasons why the ports should > > be different when using multiple multicast groups. > > OK, given they are different for mcast, then unicast should behave the > same way. For simplicity, I believe multicast and unicast should behave the same way. This way you have the chance of building interoperable applications. Especially, if the specification is written as such. > > > It does not look like the SDP spec gives a good justification for why > > different ports would not be allowed. So my suggestion is that we consider > > revising the SDP spec. > > Perhaps we can have this be the start of the draft that Mark Handley > suggested to contain SDP spec errors and updates. Probably this would > say someting following Bill Fenner's suggestion of 1-1 mapping or > punt. > -- Steve > > > Michael F. Speer Staff Socket Scientist Networking and Security Group Sun Microsystems Laboratories Sun Microsystems, Inc Phone: +1-650-786-6368 Fax: +1-650-786-6445 email: speer@eng.sun.com From rem-conf Tue Jul 13 12:10:20 1999 From rem-conf-request@es.net Tue Jul 13 12:10:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1147h5-0003b1-00; Tue, 13 Jul 1999 11:54:19 -0700 Received: from fsa.enel.ucalgary.ca [136.159.102.5] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1147h4-0003ar-00; Tue, 13 Jul 1999 11:54:18 -0700 Received: from lela (lela [136.159.102.29]) by fsa.enel.ucalgary.ca (8.8.8/8.8.8) with SMTP id MAA11197 for ; Tue, 13 Jul 1999 12:54:11 -0600 (MDT) From: "Dr. Armin Eberlein" Reply-To: Sender: "Dr. Armin Eberlein" To: Subject: remove A.Eberlein@swansea.ac.uk Date: Tue, 13 Jul 1999 13:00:36 -0600 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Disposition-Notification-To: "Dr. Armin Eberlein" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove A.Eberlein@swansea.ac.uk From rem-conf Tue Jul 13 12:23:14 1999 From rem-conf-request@es.net Tue Jul 13 12:23:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11486W-0004zq-00; Tue, 13 Jul 1999 12:20:36 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11486V-0004zb-00; Tue, 13 Jul 1999 12:20:35 -0700 Received: from robla ([172.23.100.75]) by prognet.com (8.9.2/8.9.0) with SMTP id MAA30412; Tue, 13 Jul 1999 12:20:28 -0700 (PDT) Message-Id: <4.1.19990712105142.034bb1c0@mail.real.com> Message-Id: <4.1.19990712105142.034bb1c0@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 12 Jul 1999 11:37:37 -0700 To: ravi narayan , Ethendranath Bommaiah From: Rob Lanphier Subject: Re: RTP support for Real Media ? Cc: rem-conf@es.net, confctrl@isi.edu, Sanjoy Paul In-Reply-To: <3786203E.3EAA0461@streamcenter.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:15 AM 7/9/99 , ravi narayan wrote: >Ethendranath Bommaiah wrote: >> >> I was wondering if Real G2 server supports RTP for real media (.rm and >> .ra) ? We have noticed that it does support RTP for other media like >> .au and .mpeg. However, with .rm and .ra the server returns "Protocol >> not supported" error for the SETUP message with transport set to >> RTP/AVP/TCP. We are using Real G2 server 6.0. >> >> Does Real plan to support RTP for .rm and .ra media in the future ? >> Or, is there a newer version that supports RTP already ? >> > >from what i have seen, and heard from real, the answer to your question >is "no". real does not support RTP for realmedia files. from talking to >them, i get the feeling that they do not plan to support realmedia over >RTP. the reason they cite is that RDT (their own data transport protocol >now referred to as RDP i think) is tuned for the special needs of >realmedia files. That's correct. We had floated a proposal for an optimized packet format as part of the original RTSP proposal back in 1996, but the group decided (rightly) that it didn't belong in the RTSP spec, and should be a separate proposal. Given the arguments that were floating around at that time about the relative merits of compressing RTP headers independently from the IP/UDP layer, we decided to drop this proposal. So, this indicates that perhaps we should dust off this proposal (and update with what we are currently doing). If this is the consensus, we'll be glad to follow up with this. Thoughts? Rob From rem-conf Tue Jul 13 12:23:17 1999 From rem-conf-request@es.net Tue Jul 13 12:23:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11486X-000501-00; Tue, 13 Jul 1999 12:20:37 -0700 Received: from imap1.glue.umd.edu [128.8.10.159] by mail1.es.net with esmtp (Exim 1.81 #2) id 11486W-0004zg-00; Tue, 13 Jul 1999 12:20:36 -0700 Received: from dsp11.eng.umd.edu (root@dsp11.eng.umd.edu [129.2.94.34]) by imap1.glue.umd.edu (8.9.3/8.9.3) with ESMTP id PAA14320 for ; Tue, 13 Jul 1999 15:20:31 -0400 (EDT) Received: from dsp11.eng.umd.edu (sendmail@localhost [127.0.0.1]) by dsp11.eng.umd.edu (8.9.3/8.9.3) with SMTP id PAA26607 for ; Tue, 13 Jul 1999 15:20:30 -0400 (EDT) Received: from localhost by dsp11.eng.umd.edu (8.9.3/8.9.3) with ESMTP id PAA26603 for ; Tue, 13 Jul 1999 15:20:29 -0400 (EDT) X-Authentication-Warning: dsp11.eng.umd.edu: jsong owned process doing -bs Date: Tue, 13 Jul 1999 15:20:29 -0400 (EDT) From: Song Jie X-Sender: jsong@dsp11.eng.umd.edu To: rem-conf@es.net Subject: Remove Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove jsong@eng.umd.edu From rem-conf Tue Jul 13 13:07:14 1999 From rem-conf-request@es.net Tue Jul 13 13:07:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1148np-0007QZ-00; Tue, 13 Jul 1999 13:05:21 -0700 Received: from iserv.intelsat.int [164.86.102.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 1148nn-0007Q4-00; Tue, 13 Jul 1999 13:05:20 -0700 Received: from pc1.adm.intelsat.int ([164.86.36.12]) by iserv.intelsat.int (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-49113U1000L2S100) with ESMTP id AAA24909 for ; Tue, 13 Jul 1999 16:13:31 -0400 Received: (from smap@localhost) by pc1.adm.intelsat.int (8.8.6 (PHNE_14041)/8.6.10) id QAA14128 for ; Tue, 13 Jul 1999 16:04:14 -0400 (EDT) X-Authentication-Warning: pc1.adm.intelsat.int: smap set sender to using -f Received: from admexc1b.adm.intelsat.int(164.86.33.18) by pc1 via smap (V2.1) id xma014078; Tue, 13 Jul 99 20:03:13 GMT Received: by admex1.adm.intelsat.int with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jul 1999 16:03:13 -0400 Message-ID: <490B4C213EC8D211851F00105A29CA5A0149CB30@admex1.adm.intelsat.int> From: matthew.halsey@intelsat.int To: rem-conf@es.net Subject: RE: remove A.Eberlein@swansea.ac.uk Date: Tue, 13 Jul 1999 16:03:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please advise how to be removed. I have found myself receiving considerable spamming since being included in this listserv. Matthew Halsey Technical Manager, Internet Business Development INTELSAT (202) 944 7510 matthew.halsey@intelsat.int -----Original Message----- From: Dr. Armin Eberlein [mailto:eberlein@enel.ucalgary.ca] Sent: Tuesday, July 13, 1999 3:01 PM To: rem-conf@es.net Subject: remove A.Eberlein@swansea.ac.uk remove A.Eberlein@swansea.ac.uk From rem-conf Tue Jul 13 13:48:17 1999 From rem-conf-request@es.net Tue Jul 13 13:48:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1149Rw-0001ue-00; Tue, 13 Jul 1999 13:46:48 -0700 Received: from server34.aitcom.net (ensim.com) [208.234.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 1149Rv-0001uU-00; Tue, 13 Jul 1999 13:46:47 -0700 Received: from ensim.com ([170.1.220.2]) by ensim.com (8.8.8/8.8.5) with ESMTP id QAA30180; Tue, 13 Jul 1999 16:46:08 -0400 Message-ID: <378BA67C.4A95260D@ensim.com> Date: Tue, 13 Jul 1999 13:50:05 -0700 From: Jean Bolot Organization: Ensim X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: Chinmay Padhye , rem-conf@es.net Subject: Re: RTCP Question. References: <534.931851524@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > How will a sender know how effective its redundancy sheme is? > > I don't think there is a clear way of knowing that from RTCP RR packets > as they stand. One could envisage an extension to RTCP which made this > available, if it became necessary. > > Colin In unicast, the sender can, given channel characteristics (loss rate and jitter) and encodings/FEC used in the recent past, estimate which packets got lost at the destination (both from channel loss and from delay exceeding max playout time) and infer from that a measure of audio/video/etc quality. Things are a bit trickier in multicast... -Jean ------------------------------------------------ Jean Bolot 650 210 0302 Ensim Corp. -- "Enabling services on your net" ------------------------------------------------ From rem-conf Tue Jul 13 15:00:53 1999 From rem-conf-request@es.net Tue Jul 13 15:00:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114AZD-00050z-00; Tue, 13 Jul 1999 14:58:23 -0700 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 114AZC-00050Y-00; Tue, 13 Jul 1999 14:58:22 -0700 Received: from mg-20425418-61.ricochet.net (mg-20425418-61.ricochet.net [204.254.18.61]) by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id OAA02411; Tue, 13 Jul 1999 14:53:39 -0700 (PDT) Message-Id: <3.0.5.16.19990713134131.3f3739fe@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 13 Jul 1999 13:41:31 To: "Andrea Basso" From: Ross Finlayson Subject: Re: AAC-RTP payload format Cc: , "Mathias Kretschmer" , , In-Reply-To: <007901becd4b$c98f3700$6c82cf87@pcbasso.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >While the AAC frames, referred also as "AAC raw_data_blocks" in the draft >come from the AAC stream, the piority information and the priority vector is >computed by the encoder/packetizer and are not integral part of the AAC >stream. >Note while priority of the AAC frames is an intrinsic property of the AAC >stream, these priorities can be computed differently. Thanks for the note. While I'm still somewhat confused by this, I imagine that future revisions of the draft will clarify things. In any case, I think it's very important that the following two properties - true for other MPEG/RTP formats - will also hold true for any AAC/RTP format: 1/ Given any *preencoded* AAC stream (e.g., one that's stored in a file), a sender always has enough information to be able to generate a compliant sequence of AAC/RTP packets, and 2/ Given any compliant sequence of AAC/RTP packets, a receiver always has enough information (from the packets, and perhaps from other side information such as a SDP description) to be able to generate a valid AAC stream (for immediate or later decoding). Ross. From rem-conf Tue Jul 13 15:09:40 1999 From rem-conf-request@es.net Tue Jul 13 15:09:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114AjS-0005ZF-00; Tue, 13 Jul 1999 15:08:58 -0700 Received: from sunblast.eng.usf.edu [131.247.14.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 114AjR-0005Yk-00; Tue, 13 Jul 1999 15:08:57 -0700 Received: from localhost (padhye@localhost [127.0.0.1]) by sunblast.eng.usf.edu (8.8.8/8.8.7) with ESMTP id SAA22427; Tue, 13 Jul 1999 18:08:48 -0400 (EDT) Date: Tue, 13 Jul 1999 18:08:48 -0400 (EDT) From: Chinmay Padhye X-Sender: padhye@sunblast To: Jean Bolot cc: Colin Perkins , rem-conf@es.net Subject: Re: RTCP Question. In-Reply-To: <378BA67C.4A95260D@ensim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > > > I don't think there is a clear way of knowing that from RTCP RR packets > > as they stand. One could envisage an extension to RTCP which made this > > available, if it became necessary. > > > > Colin > > In unicast, the sender can, given channel characteristics (loss > rate and jitter) and encodings/FEC used in the recent past, > estimate which packets got lost at the destination (both from > channel loss and from delay exceeding max playout time) > and infer from that a measure of audio/video/etc quality. > Things are a bit trickier in multicast... > -Jean > Consider this situation. -> Network is losing packets randomly at 10% loss rate. -> The receiver RTCP RR report will contain this information. -> Now the sender adds redundancy to the voice stream. -> Lets assume network still loses 10% i.e. no change in the network conditions. -> Since redundancy was added at the sender the receiver will now experience packet loss much lesser than 10%. Hence at this point will the receiver send a) The new loss rate after reconstruction, which will be much lesser than 10% or b) The loss rate before reconstruction, which will still be around 10%. For case a) the sender now knows that the redundancy added is beneficial and can make appropriate choices. For case b) the sender still does not know how his redundancy scheme is working. Please clarify this for me. Sincerely, Chinmay V. P. From rem-conf Tue Jul 13 15:12:49 1999 From rem-conf-request@es.net Tue Jul 13 15:12:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114Amk-0005my-00; Tue, 13 Jul 1999 15:12:22 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 114Amj-0005mn-00; Tue, 13 Jul 1999 15:12:21 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 13 Jul 1999 23:12:09 +0100 To: Chinmay Padhye cc: Jean Bolot , rem-conf@es.net Subject: Re: RTCP Question. In-reply-to: Your message of "Tue, 13 Jul 1999 18:08:48 EDT." Date: Tue, 13 Jul 1999 23:12:09 +0100 Message-ID: <2275.931903929@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Chinmay Padhye writes: > >> > >> > I don't think there is a clear way of knowing that from RTCP RR packets >> > as they stand. One could envisage an extension to RTCP which made this >> > available, if it became necessary. >> > >> > Colin >> >> In unicast, the sender can, given channel characteristics (loss >> rate and jitter) and encodings/FEC used in the recent past, >> estimate which packets got lost at the destination (both from >> channel loss and from delay exceeding max playout time) >> and infer from that a measure of audio/video/etc quality. >> Things are a bit trickier in multicast... >> -Jean >> > >Consider this situation. > >-> Network is losing packets randomly at 10% loss rate. >-> The receiver RTCP RR report will contain this information. > >-> Now the sender adds redundancy to the voice stream. >-> Lets assume network still loses 10% i.e. no change in the network > conditions. >-> Since redundancy was added at the sender the receiver will now >experience packet loss much lesser than 10%. Hence at this point will the >receiver send > >a) The new loss rate after reconstruction, which will be much lesser than >10% or > >b) The loss rate before reconstruction, which will still be around 10%. > >For case a) the sender now knows that the redundancy added is beneficial >and can make appropriate choices. >For case b) the sender still does not know how his redundancy scheme is >working. > >Please clarify this for me. The receiver sends (b), the loss rate before reconstruction. Colin From rem-conf Tue Jul 13 16:17:23 1999 From rem-conf-request@es.net Tue Jul 13 16:17:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114Bld-0001Ij-00; Tue, 13 Jul 1999 16:15:17 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 114Blc-0001IZ-00; Tue, 13 Jul 1999 16:15:17 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id EBF964CE02; Tue, 13 Jul 1999 19:15:15 -0400 (EDT) Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id TAA09851; Tue, 13 Jul 1999 19:15:14 -0400 (EDT) Message-ID: <002e01becd85$84b436a0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: "Ross Finlayson" Cc: , "Mathias Kretschmer" , , Subject: Re: AAC-RTP payload format Date: Tue, 13 Jul 1999 19:14:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ross, I am a bit confused by your concern. >>While the AAC frames, referred also as "AAC raw_data_blocks" in the draft >>come from the AAC stream, the piority information and the priority vector is >>computed by the encoder/packetizer and are not integral part of the AAC >>stream. >>Note while priority of the AAC frames is an intrinsic property of the AAC >>stream, these priorities can be computed differently. > >Thanks for the note. While I'm still somewhat confused by this, I imagine >that future revisions of the draft will clarify things. In any case, I >think it's very important that the following two properties - true for >other MPEG/RTP formats - will also hold true for any AAC/RTP format: > >1/ Given any *preencoded* AAC stream (e.g., one that's stored in a file), a >sender always has enough information to be able to generate a compliant >sequence of AAC/RTP packets, and >2/ Given any compliant sequence of AAC/RTP packets, a receiver always has >enough information (from the packets, and perhaps from other side >information such as a SDP description) to be able to generate a valid AAC >stream (for immediate or later decoding). Actually given that the priority and the repair information is *optional* and it is not vital for the decoding of the AAC stream but helps in its recovery in presence of packet losses a decoder will be always able to depacketize and decode the stream by ignoring the optional repair/priority info. From rem-conf Tue Jul 13 16:52:35 1999 From rem-conf-request@es.net Tue Jul 13 16:52:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114CKu-0002ng-00; Tue, 13 Jul 1999 16:51:44 -0700 Received: from server34.aitcom.net (ensim.com) [208.234.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 114CKt-0002nH-00; Tue, 13 Jul 1999 16:51:43 -0700 Received: from ensim.com ([170.1.220.2]) by ensim.com (8.8.8/8.8.5) with ESMTP id TAA21690; Tue, 13 Jul 1999 19:51:28 -0400 Message-ID: <378BD1ED.9090DDC3@ensim.com> Date: Tue, 13 Jul 1999 16:55:25 -0700 From: Jean Bolot Organization: Ensim X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chinmay Padhye CC: Colin Perkins , rem-conf@es.net Subject: Re: RTCP Question. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chinmay Padhye wrote: > Consider this situation. > > -> Network is losing packets randomly at 10% loss rate. > -> The receiver RTCP RR report will contain this information. > > -> Now the sender adds redundancy to the voice stream. > -> Lets assume network still loses 10% i.e. no change in the network > conditions. > -> Since redundancy was added at the sender the receiver will now > experience packet loss much lesser than 10%. Hence at this point will the > receiver send > > a) The new loss rate after reconstruction, which will be much lesser than > 10% or > > b) The loss rate before reconstruction, which will still be around 10%. > > For case a) the sender now knows that the redundancy added is beneficial > and can make appropriate choices. > For case b) the sender still does not know how his redundancy scheme is > working. > > Please clarify this for me. The receiver sends (b). Note that the sender can then use this information to estimate the loss rate after reconstruction - essentially it would simulate a channel with loss rate given by (b), and apply that model to the stream of main+FEC info it is sending. In fact, this is the idea behind choosing the optimal allocation of main and FEC information: the optimal allocation is that which yields the largest utility (audio quality in this case) at the destination given estimated channel characteristics (loss rate in this case), bandwidth constraints (computed using some algorithm based on ECN, TCP-friendliness, or whatever), and max tolerable additional caused by FEC coding. Refer to our paper with Don Towsley in this year's Infocom for details ftp://ftp-sop.inria.fr/rodeo/bolot/99.Audio_fec.ps.gz -Jean ------------------------------------------------ Jean Bolot 650 210 0302 Ensim Corp. -- "Enabling services on your net" ------------------------------------------------ From rem-conf Tue Jul 13 17:38:14 1999 From rem-conf-request@es.net Tue Jul 13 17:38:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114D1u-0005Ai-00; Tue, 13 Jul 1999 17:36:10 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 114D1s-0005AY-00; Tue, 13 Jul 1999 17:36:08 -0700 Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Tue Jul 13 20:35:11 EDT 1999 Received: from localhost by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id UAA17340; Tue, 13 Jul 1999 20:35:14 -0400 (EDT) Date: Tue, 13 Jul 1999 20:35:14 -0400 (EDT) From: Ethendranath Bommaiah X-Sender: ethen@chair To: Rob Lanphier cc: ravi narayan , rem-conf@es.net, confctrl@isi.edu, Sanjoy Paul Subject: Re: RTP support for Real Media ? In-Reply-To: <4.1.19990712105142.034bb1c0@mail.real.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > That's correct. We had floated a proposal for an optimized packet format > as part of the original RTSP proposal back in 1996, but the group decided > (rightly) that it didn't belong in the RTSP spec, and should be a separate > proposal. Given the arguments that were floating around at that time about > the relative merits of compressing RTP headers independently from the > IP/UDP layer, we decided to drop this proposal. > > So, this indicates that perhaps we should dust off this proposal (and > update with what we are currently doing). If this is the consensus, we'll > be glad to follow up with this. > > Thoughts? > Rob Thanks for the response. I was wondering if you could also support plain RTP along with the above mentioned compressed RTP header approach (which I presume is proprietary). Also, would it be possible for you to make your current approach public (in the form of a draft proposal, perhaps) ? Thanks, Ethen From rem-conf Tue Jul 13 17:46:01 1999 From rem-conf-request@es.net Tue Jul 13 17:46:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114DB5-00061x-00; Tue, 13 Jul 1999 17:45:39 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 114DB4-00061f-00; Tue, 13 Jul 1999 17:45:38 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA00546; Tue, 13 Jul 1999 20:45:33 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id UAA04471; Tue, 13 Jul 1999 20:45:28 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <378BDDA2.E1202A03@cs.columbia.edu> Date: Tue, 13 Jul 1999 20:45:22 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Revision of SSRC collision algorithm? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > > > Henning proposes instead that when a host changes its address it > should leave the SSRC identifier unchanged and that the spec should > say that receivers SHOULD keep packets from the new address and > discard packets from the old address when this "collision" of > addresses with the same SSRC identifier is detected. > > The spec says an implementation MUST include an algorithm similar to > the one described in Section 8.2. The algorithm shown in pseudo-code > keeps the packets from the old address and discards those from the new > address which is the "right" approach for a genuine collision, based > on the assumption that one wants to continue hearing the valid source > that one was hearing before. If this event was an address change, the > new source would be accepted once the old source timed out because no > more packets were received. I should add one motivation to this mobility case: If done appropriately, hand-off in this manner can be significantly faster than with mobile IP, even with binding updates. However, this would make it useless in the mobility case above, since the timeout can take minutes. Note that the case of mobility can be readily distinguished, if the implementation wants to bother: in a collision, you will get both "old" and "new" IP addresses in some alternation, in the mobility case, you will get only the "new" address until the next address change, typically many seconds away. However, given the rarity of this situation, that it is not needed for interoperability and since it is unlikely to be widely implemented, I don't think this needs to be specified in the draft. Given that this revision is for Draft status, relaxing requirements seems the safer thing to do. I doubt that many (any?) existing implementations discard packets as is. Also, for unicast, collisions can't happen under normal circumstances (if one is mixing different unicast streams, one should choose different destination ports), so discarding packets seems unnecessary to begin with. > > This is not intended to require that the policy be to ignore the new > source. A different policy may be chosen and still have the algorithm > be similar; I added a phrase about this in the most recent draft. > > Regarding replacing the existing pseudo-code with pseudo-C, the syntax > I used in writing the existing algorithm was taken from an example > provided at the time by the RFC Editor. The reason for the pseudo > code is that Internet Standards are not supposed to include code > (because they are supposed to specify what happens on the wire, not > how to implement the protocol). I can get a new reading on this from > the AD and the RFC Editor. With both the current pseudo-code and more C-like code, the same behavior is specified, so the "what happens on the wire" argument doesn't seem to apply. However, code has the advantage that you can actually check it. I would want to include nothing that ties down an implementation to any operating system, just allows to allow the use of tools. (If it increases the number of implementations that actually use collision handling, so much the better.) > -- Steve -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Jul 14 04:23:08 1999 From rem-conf-request@es.net Wed Jul 14 04:23:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114N1G-0007OE-00; Wed, 14 Jul 1999 04:16:10 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with esmtp (Exim 1.81 #2) id 114N1F-0007Nl-00; Wed, 14 Jul 1999 04:16:09 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <3Y0THH5V>; Wed, 14 Jul 1999 04:13:36 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: "'Michael F. Speer'" , Stephen Casner Cc: rem-conf@es.net Subject: RE: Distinct UDP ports for layered encodings? Date: Wed, 14 Jul 1999 04:13:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > By doing this, this leads to the interpretation that one could mix audio > and video on the same RTP session. This was something that we are trying > to avoid. Sure, but the RTP spec nevertheless allows this. I just checked section 5.2, and it exactly supports my argument. >From section 5.2 in the latest RTP Internet Draft: Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. This actually means that it is allowed to send unlayered streams to the same port. So, why is it that that the spec says that layered streams "MUST" be sent to distinct ports? I think this is inconsistent. I don't think that it is reasonable to have different rules for layered streams vs. unlayered streams. So, the "MUST" qualifier ought to be changed to a "SHOULD". Anders From rem-conf Wed Jul 14 08:59:36 1999 From rem-conf-request@es.net Wed Jul 14 08:59:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114RNy-0004Ja-00; Wed, 14 Jul 1999 08:55:54 -0700 Received: from aix10.segi.ulg.ac.be [139.165.32.133] by mail1.es.net with esmtp (Exim 1.81 #2) id 114RNx-0004JD-00; Wed, 14 Jul 1999 08:55:53 -0700 Received: from georges.montefiore.ulg.ac.be (georges.montefiore.ulg.ac.be [139.165.16.1]) by aix10.segi.ulg.ac.be (8.9.1a/8.9.1a) with SMTP id RAA16764 for ; Wed, 14 Jul 1999 17:55:39 +0200 Received: from [139.165.11.13] by georges.montefiore.ulg.ac.be (8.6.10/ULG-7.9) with ESMTP id RAA13161 for at Wed, 14 Jul 1999 17:55:39 +0200 Received: from yamamoto@[139.165.11.16] by valvert.montefiore.ulg.ac.be (8.6.10/ULG-7.9) with ESMTP id RAA20872 for at Wed, 14 Jul 1999 17:55:27 +0200 Sender: yamamoto@run.montefiore.ulg.ac.be Message-ID: <378CB264.C9C46A8F@run.montefiore.ulg.ac.be> Date: Wed, 14 Jul 1999 17:53:08 +0200 From: Lidia Yamamoto X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686) X-Accept-Language: ja, en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Distinct UDP ports for layered encodings? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, For me it seems that the restriction on multiple multicast addresses using the same port number is not only an implementation restriction, but it is also important to ensure 1 to n multiplexing from the network layer to the transport layer (we may use one IP address (unicast or multicast) with several ports, but not vice-versa), instead of n to n multiplexing. So maybe it is a feature rather than a bug. This would be one more argument for keeping the RTP specification and changing SDP. I think the main point is that SDP syntax makes it difficult to express media in a hierarchical way. I think it would be more clear, for example, if we had something like this (for simplification, the examples do not show all the details of the SDP syntax): # example with one hierarchical media (e.g. layered video with 3 layers) # using the same IP address and TTL for the 3 sub-media m=hierarchical 3 # meaning three sub-media within one c=IPaddr1/TTL1 # meaning IPaddress 1 and TTL1 will be used for the three # sub-media # the next 3 media descriptions will describe each sub-media m=video port1 m=video port2 m=video port3 # example with 2 layers, each using different IP addresses, ports and TTLs. m=hierarchical 2 m=video port1 c=IPaddr1/TTL1 m=video port2 c=IPaddr2/TTL2 # illegal: m=hierarchical 2 m=video port1 c=IPaddr1/TTL1 m=video port1 c=IPaddr2/TTL2 # multiple hierarchical levels, for more exotic applications: m=hierarchical 2 m=audio port1 m=hierarchical 2 m=video port2 m=application port3 Something like this would make the matching of transport addresses with network addresses clear in SDP, and it could be used in more generic applications, instead of only patching SDP to work with layered transmission. Lidia. "Anders Klemets (Exchange)" wrote: > > By doing this, this leads to the interpretation that one could mix audio > > and video on the same RTP session. This was something that we are trying > > to avoid. > > Sure, but the RTP spec nevertheless allows this. I just checked section > 5.2, and it exactly supports my argument. > > >From section 5.2 in the latest RTP Internet Draft: > > Separate audio and video streams SHOULD NOT be carried in a single > RTP session and demultiplexed based on the payload type or SSRC > fields. > > This actually means that it is allowed to send unlayered streams to the same > port. So, why is it that that the spec says that layered streams "MUST" be > sent to distinct ports? I think this is inconsistent. I don't think that > it is reasonable to have different rules for layered streams vs. unlayered > streams. So, the "MUST" qualifier ought to be changed to a "SHOULD". > > Anders From rem-conf Wed Jul 14 23:42:15 1999 From rem-conf-request@es.net Wed Jul 14 23:42:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114f9X-0003Ya-00; Wed, 14 Jul 1999 23:37:55 -0700 Received: from hyperb.holontech.com (post.holontech.com) [206.204.78.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 114f9V-0003YK-00; Wed, 14 Jul 1999 23:37:53 -0700 Received: from mom.holontech.com by post.holontech.com (8.7.5/SMI-4.1) id XAA29054; Wed, 14 Jul 1999 23:36:32 -0700 (PDT) Received: by mom.holontech.com with Internet Mail Service (5.0.1460.8) id <38MQCFL9>; Wed, 14 Jul 1999 23:39:13 -0700 Message-ID: <1162BE4AB70ED111A648006097BDDB85821379@mom.holontech.com> From: Mark Llacuna To: rem-conf@es.net Subject: HEader compression questions ( RTP ) Date: Wed, 14 Jul 1999 23:39:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello everyone, I have a few questions as to how an implementation of RTP header compression would behave in case an out-of-order packet is received. The RFC (2508) specifies that if for example the first three compressed packets were OK but instead of the fourth packet, the fifth packet was received by the decompressor, the decompressor would invalidate the context and send a CONTEXT_STATE packet. The question therefore is: a) does the decompressor keep the first three packets? b) does the compressor send the fourth packet ( based on the sequence number in the CONTEXT STATE packet )? and resend the fifth packet? c) if for example, there are several packets ( say 5,6,7,8 ) that were received in the interim ( before a new FULL HEADER ) is received, what is the heuristic used for resending a CONTEXT_STATE packet? Or do you actually just set a timer until a FULL_HEADER is received and resend a CONTEXT-STATE? d) in case you use timers for c), what would be a recommended timeout period? Any answers would be really useful. Regards, Joey Salanga From rem-conf Wed Jul 14 23:51:03 1999 From rem-conf-request@es.net Wed Jul 14 23:51:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114fKq-0003kx-00; Wed, 14 Jul 1999 23:49:36 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 114fKp-0003kn-00; Wed, 14 Jul 1999 23:49:35 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id BAA05197 for ; Thu, 15 Jul 1999 01:49:35 -0500 (CDT)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with SMTP id BAA28022 for ; Thu, 15 Jul 1999 01:49:25 -0500 (CDT)] Received: from miel.mot.com (pc84156.miel.mot.com) by hpux4.miel.mot.com with SMTP id AA17453 (5.67b/IDA-1.6 for rem-conf@es.net); Thu, 15 Jul 1999 12:10:34 +0500 Message-Id: <378DFC83.A856769A@miel.mot.com> Date: Thu, 15 Jul 1999 12:21:39 -0300 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: rem-conf@es.net Subject: [Fwd: [Fwd: Header Compression Error Recovery]] Content-Type: multipart/mixed; boundary="------------AD4A40619275D7F80B7C8C90" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------AD4A40619275D7F80B7C8C90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------AD4A40619275D7F80B7C8C90 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by ganga.miel.mot.com with SMTP (8.7.1/8.7.1) id KAA04756; Thu, 15 Jul 1999 10:53:37 +0530 (IST) Received: from miel.mot.com (pc84156.miel.mot.com) by hpux4.miel.mot.com with SMTP id AA10846 (5.67b/IDA-1.6 for gvjohn@ganga.miel.mot.com); Thu, 15 Jul 1999 10:53:28 +0500 Message-Id: <378DEA71.AF02E76A@miel.mot.com> Date: Thu, 15 Jul 1999 11:04:33 -0300 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: Anand Kumar Goenka , iptel@lists.research.bell-labs.com, mllacuna@x.holontech.com, gvjohn@miel.mot.com Subject: Re: [Fwd: Header Compression Error Recovery] References: <378DE396.3C42ED62@miel.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mozilla-Status2: 00000000 Hi Joey, Answre to your problem with your example : If decompressor receives fifth pkt insted of fourth it needs to invalidate the context (RFC 2508) by sending CONTEXT_STATE packet. Once the context is invalidated what is acceptable to this context is a FULL_HEADER packet (or terminate the context if there is no FULL_HEADER). If the context is waiting for the FULL_HEADER packet and mean while compressed packets arrive, those pkts will be rejected by the decompressor. or other implementation could be save the other pkts (5,6,7,8) and wait for pkt 4 for a period of n units. (But there are many issues to resolve then) If it does not receive pkt 4 within this period then invalidate the context. Once the context has been invalidated next acceptable pkt is FULL_HEADER. Second part of the question .. How long you should wait for a FULL_HEADER pkt ? For this prblme there can be a timer based soln or counter of number of compressed pkt based soln. Second soln may be more attractive. Prblm with timer soln is you canot predict when the source will send you next RTP pkt. With the second soln, if you receive n compressed pkts after invalidating the context you could resend the CONTEXT_STATE pkt. I donot want to suggest any number for the timeout period .. Hope my answers will help you .. More doubts are welcome .. You could subscibe to rem-conf@es.net also for more answers. Rgds GVJ Anand Kumar Goenka wrote: > I gues u could answer this question . ... > > Anand(K.G.) > > ------------------------------------------------------------------------ > > Subject: Header Compression Error Recovery > Date: Wed, 14 Jul 1999 17:28:05 -0700 > From: Mark Llacuna > To: "'iptel@lists.research.bell-labs.com'" > > Hello everyone, > > I have a few questions as to how an implementation of RTP header > compression would behave in case an out-of-order packet is received. The > RFC (2508) specifies that if for example the first three compressed packets > were OK but instead of the fourth packet, the fifth packet was received by > the decompressor, the decompressor would invalidate the context and send a > CONTEXT_STATE packet. The question therefore is: > > a) does the decompressor keep the first three packets? > b) does the compressor send the fourth packet ( based on the > sequence number in the CONTEXT STATE packet )? and resend the fifth packet? > c) if for example, there are several packets ( say 5,6,7,8 ) that > were received in the interim ( before a new FULL HEADER ) is received, what > is the heuristic used for resending a CONTEXT_STATE packet? Or do you > actually just set a timer until a FULL_HEADER is received and resend a > CONTEXT-STATE? > d) in case you use timers for c), what would be a recommended > timeout period? > > Any answers would be really useful. > > Regards, > Joey Salanga > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------------AD4A40619275D7F80B7C8C90-- From rem-conf Thu Jul 15 02:00:55 1999 From rem-conf-request@es.net Thu Jul 15 02:00:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114hLq-0005dk-00; Thu, 15 Jul 1999 01:58:46 -0700 Received: from (seeyes.seeyes.co.in) [202.54.67.82] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 114hLn-0005da-00; Thu, 15 Jul 1999 01:58:44 -0700 Received: from seeyes.co.in ([10.1.5.146]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id OAA13564; Thu, 15 Jul 1999 14:40:58 +0530 Message-ID: <378DA3C3.AC371F81@seeyes.co.in> Date: Thu, 15 Jul 1999 14:32:59 +0530 From: Venkata Narasimha Murthy Nanduri X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "rem-conf@es.net" , GeeVarghese John Subject: CRTP using frame relay Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, 1) Do U have any idea about the implementation of RTP/UDP/IP header compression using Frame relay as the link level protocol? 2) Are there any protocol numbers defined for CRTP compressed packets(COMPRESSED_RTP_8, COMPRESSED_UDP_8, etc) for frame relay? They have been defined for PPP in RFC 2509.. Answers to any of the questions will be useful.. Thanks in advance Murthy NVN From rem-conf Thu Jul 15 02:06:44 1999 From rem-conf-request@es.net Thu Jul 15 02:06:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114hTG-0006Be-00; Thu, 15 Jul 1999 02:06:26 -0700 Received: from (seeyes.seeyes.co.in) [202.54.67.82] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 114hTC-0006An-00; Thu, 15 Jul 1999 02:06:23 -0700 Received: from seeyes.co.in ([10.1.5.146]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id OAA13637; Thu, 15 Jul 1999 14:48:38 +0530 Message-ID: <378DA592.79ED2206@seeyes.co.in> Date: Thu, 15 Jul 1999 14:40:42 +0530 From: Venkata Narasimha Murthy Nanduri X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "rem-conf@es.net" , GeeVarghese John Subject: Reg. extension header in CRTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, While sending the COMPRESSED_RTP packet, in RFC2508, it has been mentioned that an addional byte will be transmitted if MSTI = 1111. The additional byte is mentioned in the packet format as four bits M', S', T', I' and 4 bits as CC. In the explanation it has been given that the first nibble(M', S', T', I') corresponds to the real values of the four bits MSTI. What is exactly meant by M', S', T', I'? What is meant by the real values of MSTI? Thanks Murthy NVN From rem-conf Thu Jul 15 02:19:58 1999 From rem-conf-request@es.net Thu Jul 15 02:19:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114hfg-0006zR-00; Thu, 15 Jul 1999 02:19:16 -0700 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 114hff-0006zH-00; Thu, 15 Jul 1999 02:19:15 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id EAA03802 for ; Thu, 15 Jul 1999 04:19:14 -0500 (CDT)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with SMTP id EAA25377 for ; Thu, 15 Jul 1999 04:19:09 -0500 (CDT)] Received: from miel.mot.com (pc84156.miel.mot.com) by hpux4.miel.mot.com with SMTP id AA25532 (5.67b/IDA-1.6 for rem-conf@es.net); Thu, 15 Jul 1999 14:40:08 +0500 Message-Id: <378E1F91.35B3A7FF@miel.mot.com> Date: Thu, 15 Jul 1999 14:51:13 -0300 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: Venkata Narasimha Murthy Nanduri , rem-conf@es.net Subject: Re: [Fwd: Header Compression Error Recovery] References: <378DE396.3C42ED62@miel.mot.com> <378DEA71.AF02E76A@miel.mot.com> <378DA29E.2008BD4F@seeyes.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Answer to your questions .. Venkata Narasimha Murthy Nanduri wrote: > Hi John, > > If we consider that first three packets have been received by the receiver, fourth one > missing and fifth onwards fine... > > Then as per my understanding, we are planning to do this way. Is it correct? > > 1) Since 4th packet is not received by the decompressor, it will invalidate the context > and send the Context state packet to the compressor, with the CID and the sequence > number of the latest received packet in sequnce (i.e., 3.) drop the packets with seq. > number greater than four for that context until a FULL_HEADER packet is received for > that context. this is correct > > > 2) Now, as the context state packet is received by the compressor, it should send the > missing packet > (i.e., packet with seq. no 4) in FULL_HEADER format and the remaining packets of the > context as stored in the context table at the compressor table. > I dont know, why you need to resent the pkt which is lost ... That means CRTP is taking care of retransmission Is it correct ? rather I would say when the compressor module receives a CONTEXT_STATE packet it can send the next pkt of the flow as the FULL_HEADER packet with link sequence number 4 in the example and all consecutive pkts as compressed pkts. I think retransmission should be done by upperlayer protocols. > > Could you please let me know whether this email is from Bangalore office or Hyderabad > office of Motorola? Bangalore office > Rgds GVJ From rem-conf Thu Jul 15 02:31:24 1999 From rem-conf-request@es.net Thu Jul 15 02:31:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114hqJ-0007jC-00; Thu, 15 Jul 1999 02:30:15 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 114hqH-0007iL-00; Thu, 15 Jul 1999 02:30:13 -0700 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id EAA20684 for ; Thu, 15 Jul 1999 04:30:13 -0500 (CDT)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with SMTP id EAA28706 for ; Thu, 15 Jul 1999 04:30:08 -0500 (CDT)] Received: from miel.mot.com (pc84156.miel.mot.com) by hpux4.miel.mot.com with SMTP id AA26429 (5.67b/IDA-1.6 for rem-conf@es.net); Thu, 15 Jul 1999 14:51:07 +0500 Message-Id: <378E2224.1C152B29@miel.mot.com> Date: Thu, 15 Jul 1999 15:02:12 -0300 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: Venkata Narasimha Murthy Nanduri Cc: "rem-conf@es.net" Subject: Re: Reg. extension header in CRTP References: <378DA592.79ED2206@seeyes.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, What I understant is If we need to send the CC value to decompressor we set 1111 for the first MSTI nibble and keep the extra one byte to encode real delta values of MSTI. and next 4 bits to store the new CC value. By setting 1111 for the MSTI bits we are indicating that CC value is encoded in the compressed pkt. Rgds GVJ Venkata Narasimha Murthy Nanduri wrote: > Hi, > > While sending the COMPRESSED_RTP packet, in RFC2508, it has been > mentioned that an addional byte will be transmitted if MSTI = 1111. The > additional byte is mentioned in the packet format as four bits M', S', > T', I' and 4 bits as CC. > In the explanation it has been given that the first nibble(M', S', T', > I') corresponds to the real values of the four bits MSTI. > What is exactly meant by M', S', T', I'? > What is meant by the real values of MSTI? > > Thanks > Murthy NVN From rem-conf Thu Jul 15 04:01:45 1999 From rem-conf-request@es.net Thu Jul 15 04:01:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114jEu-0001DP-00; Thu, 15 Jul 1999 03:59:44 -0700 Received: from (seeyes.seeyes.co.in) [202.54.67.82] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 114jEr-0001DF-00; Thu, 15 Jul 1999 03:59:42 -0700 Received: from seeyes.co.in ([10.1.5.146]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id QAA14876; Thu, 15 Jul 1999 16:41:46 +0530 Message-ID: <378DC016.7CAB883B@seeyes.co.in> Date: Thu, 15 Jul 1999 16:33:51 +0530 From: Venkata Narasimha Murthy Nanduri X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: GeeVarghese John CC: rem-conf@es.net Subject: Re: [Fwd: Header Compression Error Recovery] References: <378DE396.3C42ED62@miel.mot.com> <378DEA71.AF02E76A@miel.mot.com> <378DA29E.2008BD4F@seeyes.co.in> <378E1F91.35B3A7FF@miel.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi John, Yes, As I have mentioned, CRTP does the retransmission. If we don't retransmit the lost packets, there is no necessity for the compressor to store the packets that are transmitted. Let us take the scenario at compressor seq no:1;CID:1, FULL_HEADER sent and stored in a table seq no:2;CID:1, COMPRESSED_UDP sent and stored in a table seq no:3;CID:1, COMPRESSED_RTP sent and stored in a table seq no:4;CID:1, COMPRESSED_UDP sent and stored in a table seq no:5;CID:1, COMPRESSED_RTP sent and stored in a table seq no:6;CID:1, COMPRESSED_UDP sent and stored in a table seq no:7;CID:1, COMPRESSED_RTP sent and stored in a table seq no:8;CID:1, COMPRESSED_UDP sent and stored in a table seq no:9;CID:1, COMPRESSED_RTP sent and stored in a table seq no:10;CID:1, COMPRESSED_UDP sent and stored in a table Now If the fourth packet(packet with seq. no 4) could not reach the decompressor, A context state packet has been received by the compressor indicating that the packet with seq. no 4 is missing.. Then as per u, the compressor should send the next packet of the flow(seq. no 11 as per above data ) as full header packet by changing the seq. no from 11 to 4 and transmit the remaining packets as compressed packets. But because of this, the packes from seq. no 4 to 10 are lost( Is this what U intended to say?) But if u take the case, where the compressor, sends the seq.no 4 packet as full header and remaining packets after that are sent as they are stored in the table at the comressor side. This way, we will not be losing any packets.. As far as the retransmission by the upper layer protocols are concerned, that can be managed by the compressor part of CRTP itself like this: 1) Since the compressor stores the compressed and uncompressed packets transmitted in a table... It can form an IP packet( like the upper layer protocols) if full header packet has to be transmitted. It can form the packet format of COMPRESSED_UDP or COMPRESSED_RTP if required to transmit.. Please send your comments along.. Murthy NVN GeeVarghese John wrote: > Hi, > > Answer to your questions .. > > Venkata Narasimha Murthy Nanduri wrote: > > > Hi John, > > > > If we consider that first three packets have been received by the receiver, fourth one > > missing and fifth onwards fine... > > > > Then as per my understanding, we are planning to do this way. Is it correct? > > > > 1) Since 4th packet is not received by the decompressor, it will invalidate the context > > and send the Context state packet to the compressor, with the CID and the sequence > > number of the latest received packet in sequnce (i.e., 3.) drop the packets with seq. > > number greater than four for that context until a FULL_HEADER packet is received for > > that context. > > this is correct > > > > > > > 2) Now, as the context state packet is received by the compressor, it should send the > > missing packet > > (i.e., packet with seq. no 4) in FULL_HEADER format and the remaining packets of the > > context as stored in the context table at the compressor table. > > > > I dont know, why you need to resent the pkt which is lost ... > That means CRTP is taking care of retransmission > Is it correct ? > rather I would say > when the compressor module receives a CONTEXT_STATE packet > it can send the next pkt of the flow as the FULL_HEADER packet with link > sequence number 4 in the example and all consecutive pkts as compressed pkts. > I think retransmission should be done by upperlayer protocols. > > > > > Could you please let me know whether this email is from Bangalore office or Hyderabad > > office of Motorola? > > Bangalore office > > > > > Rgds > > GVJ From rem-conf Thu Jul 15 08:11:33 1999 From rem-conf-request@es.net Thu Jul 15 08:11:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114n4I-00004z-00; Thu, 15 Jul 1999 08:05:02 -0700 Received: from motnt05-240.postnet.com (unknown) [209.96.70.240] by mail1.es.net with smtp (Exim 1.81 #2) id 114n4E-00003x-00; Thu, 15 Jul 1999 08:04:58 -0700 From: Subject: Internet Detective Software...Find Anyone/Anything ! ! ! Date: Thu, 15 Jul 1999 10:00:23 Message-Id: <367.449443.876973@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GET "CYBER-SPY INTERNET DETECTIVE SOFTWARE"!! This message is a result of an opt-in marketing campaign. To stop your subscription to our services, see end of message cyberspydetective.com 1717 S Brentwood STL MO 63144 708-401-0369 cyberspy44@mailandnews.com FIND OUT ANYTHING ABOUT ANYONE USING THE NET!! http://www.cyberspydetective.com/ - Find college roommates, old girlfriends/boyfriends - Create a map with directions right to a person's door - Get anyone's bank account information - Credit reports - Driver's records "CYBER-SPY INTERNET DETECTIVE SOFTWARE" HAS POWER!! http://www.cyberspydetective.com/ OUR DATABASE ACCESS FUNCTIONS INCLUDE: - Hacker sites!! (learn the trade underground) - Illegal software piracy sites (free downloads!!) - Anarchist sites (loads of information files) - Government databases - ...and much more!! http://www.cyberspydetective.com/ FIND OUT ALMOST ANYTHING ABOUT ANYBODY!! - Friends - Enemies - Businesses - Your Boss ....Even You!! BE AMAZED (and maybe even scared) AT THE INFO!! USE THE SOFTWARE PRIVATE INVESTIGATORS USE!! GET THE POWER YOU WANT....WE HAVE THE SOFTWARE. GET IT HERE: http://www.cyberspydetective.com/ http://www.cyberspydetective.com/ http://www.cyberspydetective.com/ To cancel your subscription, use our online form: http://www.cyberspydetective.com/cleanlist.html From rem-conf Thu Jul 15 09:19:26 1999 From rem-conf-request@es.net Thu Jul 15 09:19:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114o9Z-0001KP-00; Thu, 15 Jul 1999 09:14:33 -0700 Received: from mail.nps.navy.mil [131.120.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 114o9Y-0001KF-00; Thu, 15 Jul 1999 09:14:32 -0700 Received: from cs.nps.navy.mil (slippc11.cs.nps.navy.mil [131.120.1.190]) by mail.nps.navy.mil (8.9.3/8.9.3) with ESMTP id JAA06141 for ; Thu, 15 Jul 1999 09:16:28 -0700 (PDT) Message-ID: <378E0891.9D6B26C7@cs.nps.navy.mil> Date: Thu, 15 Jul 1999 09:13:06 -0700 From: Francisco Afonso X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf Subject: RTP Monitor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RFC1889 defines "Monitor" as "an application that receives RTP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current quality of service for distribution monitoring, fault diagnostics and long-term statistics". In my master thesis I am working on a RTP Monitor written in Java using Sun's Java Media Framework. Could anyone send me references to RTP monitor applications ? Francisco Afonso Naval Postgraduate School From rem-conf Thu Jul 15 09:45:29 1999 From rem-conf-request@es.net Thu Jul 15 09:45:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 114ocA-0002EF-00; Thu, 15 Jul 1999 09:44:06 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 114oc9-0002E2-00; Thu, 15 Jul 1999 09:44:05 -0700 Received: from real.com (ietfpc14.ietf.uninett.no [128.39.28.64]) by prognet.com (8.9.2/8.9.0) with ESMTP id JAA17360 for ; Thu, 15 Jul 1999 09:44:03 -0700 (PDT) Message-ID: <378E108C.FC62FE88@real.com> Date: Thu, 15 Jul 1999 18:47:08 +0200 From: Virginia Thomas X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP Interoperability Bake-Off Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RealNetwoks is interested in participating in RTP interoperability testing as was discussed in yesterday's AVT meeting. We have currently tested G2 with vic/vat and the ICAST server ( which I believe is based on vic/vat) and ICAST viewer. I am interested in knowing how, when, where, this event might take place. Thanks, - Virginia From rem-conf Fri Jul 16 16:35:26 1999 From rem-conf-request@es.net Fri Jul 16 16:35:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 115HMm-0000IN-00; Fri, 16 Jul 1999 16:26:08 -0700 Received: from tesla.comm.utoronto.ca (tesla.comm.toronto.edu) [128.100.11.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 115HMl-0000ID-00; Fri, 16 Jul 1999 16:26:07 -0700 Received: from riemann.comm (riemann.comm [128.100.11.18]) by tesla.comm.toronto.edu (8.9.0/8.9.0) with ESMTP id TAA08571; Fri, 16 Jul 1999 19:24:02 -0400 (EDT) From: Hassan Naser Received: (from hnaser@localhost) by riemann.comm (8.9.0/8.9.0) id TAA09281; Fri, 16 Jul 1999 19:23:54 -0400 (EDT) Message-Id: <199907162323.TAA09281@riemann.comm> Subject: H.GCP draft? To: rem-conf@es.net Date: Fri, 16 Jul 1999 19:23:53 -0400 (EDT) Cc: confctrl@isi.edu X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone have the ITU.T Draft Recomm. H.GCP? Anything that relates to, or describes the (GCP) protocol is also welcome. Thanks Hassan Naser hnaser@comm.utoronto.ca From rem-conf Fri Jul 16 22:56:32 1999 From rem-conf-request@es.net Fri Jul 16 22:56:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 115NOY-0003Go-00; Fri, 16 Jul 1999 22:52:22 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 115NOW-0003Ge-00; Fri, 16 Jul 1999 22:52:20 -0700 Received: from uggla (ap03-115.mp.pi.se [195.7.87.115]) by mail.pi.se (8.8.8/8.8.8) with SMTP id HAA20661; Sat, 17 Jul 1999 07:52:15 +0200 (MET DST) Message-Id: <3.0.1.32.19990717075003.0077fdcc@mail.pi.se> X-Sender: au1042@mail.pi.se X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 17 Jul 1999 07:50:03 +0200 To: rem-conf@es.net From: Gunnar Hellstrom Subject: draft-hellstrom-avt-rtp-text-01.txt Result of Oslo discussion. Cc: textphone@lsv.pi.se (Text Telephone Forum), mickey.nasiri@etx.ericsson.se Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_932183403==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_932183403==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The draft rtp specification for text conversation was discussed in IETF AVT last Thursday in Oslo.=20 It was regarded quite stable. Before settling it completely, I want to discuss a few issues: 1. Timestamp clock frequency. I had put a low figure 10 Hz in the specification. It was questioned and proposed that a figure of some thousands should be selected.=20 I am willing to accept that, and propose that 1000 Hz is used. A millisecond per tick is a handy figure.=20 This will however lead to the timestamp offset in the redundancy data headers that use only 14 bits, flip around in only 16 seconds. If correct timing information is wanted, the data flush procedure described in next section should be used. 2. Retransmission of text before a pause. Text does not flow continously, but only when a user enter text. Therefore, a recommended procedure could specify that for the redundancy scheme, it is advisable to send the ISO 10646 synch character FEFF after some inactivity timer to flush out redundant data - see section 3.4.=20 3. Recommended procedures section. In the draft that accompanies this mail, section 3 documents the recommended procedures for using the payload format. Does the group want it to be kept there or shall it be moved to the specification specifying use of this RTP Payload? ( The first user being H.323 Annex G)=20 Any other comments are welcome. A new version of the document is attached. ( what habits do you have regarding marking modifications between versions in the text formatted documents? ) Gunnar Hellstr=F6m --=====================_932183403==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hellstrom-avt-rtp-text-01.txt" Internet Engineering Task Force AVT WG Internet Draft Gunnar= Hellstr=F6m draft-hellstrom-avt-rtp-text-01.txt L M Ericsson July 17, 1999 Expires: Jan 17, 2000 RTP Payload for Text Conversation STATUS OF THIS MEMO This document is an Internet-Draft and it is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html Distribution of this document is unlimited. ABSTRACT This memo describes how to carry text conversation session contents in= RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1].=20 Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation= services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the= risk of text loss caused by packet loss. The redundancy coding follows RFC= 2198. Hellstr=F6m [Page 1] Internet Draft 1 Introduction This memo defines a payload type for carrying text conversation session= =20 contents in RTP packets. Text conversation session contents are specified= in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. Text in text conversation sessions= is sent as soon as it is available, or with a small delay of up to=20 0.5 seconds for buffering. The text is supposed to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per= second or less. Therefore, the expected number of characters to transmit is low. Only one or a few new characters are expected to be transmitted with each packet. T.140 specifies that text and other T.140 elements shall be transmitted= in =20 ISO 10 646-1 code with UTF-8 transformation. That makes it easy to= implement internationally useful applications, and to handle the text in modern =20 information technology environments. The most common T140 PDU is a= character of ISO 10646 text, UTF-8 coded, submitted from T.140 without any extra= framing.=20 =20 T.140 requires the transport channel to provide characters without duplication and in original order.=20 Text conversation users expect that text will be delivered with no or a= low level of lost information. If lost information can be replaced with a= special=20 marker, the willingness to accept loss is expected to be higher. =20 Therefore a mechanism based on RTP is specified here. It gives text= arrival =20 in correct order, without duplications, with an optional possibility to = =20 repeat data for redundancy to lower the risk of loss, and a mechanism= that=20 reveals loss and therefore can insert a marker for lost text in the= received stream. Since packet overhead is usually much larger than the T.140= contents, the increase in channel load by the redundancy scheme is minimal.=20 2. Usage of RTP When an unreliable transport of T.140 text session data in a packet= network is selected, RTP with payload as described in this specification should be= used. T.140 data is submitted for transmission in a number of complete protocol= data units (T140 PDU). A T140block contains one or more T140 PDU:s.=20 =20 A text conversation RTP packet contains an RTP header, a Payload Header, optional redundant data fields, and the new (primary) T.140 data field. =20 2.1 RTP packet header =20 Each RTP packet starts with a fixed RTP header. The following fields of= the RTP fixed header are used for T.140 text streams: Hellstr=F6m [Page 2] Internet Draft =20 Payload Type (PT): Payload type allocation is dynamic. If redundancy is= used, the Payload Type shall indicate redundancy ("RED") according to RFC 2198= [3]. If no redundancy is used, the Payload Type shall specify the primary T.140 data "T140" payload format.=20 Sequence number: The Sequence Number shall be increased with one for each new transmitted packet. It is used for detection of packet loss and= packets out of order, and can be used in the process of retrieval of redundant= text,=20 reordering of text and marking missing text. Timestamp: The RTP Timestamp encodes the approximate sampling instance of = =20 the primary text in the packet. A clock frequency of 1000 Hz shall be= used.=20 No sequential packets should use the same timestamp.=20 2.2 Additional headers When redundant data is used, additional headers specify the redundant=20 text fields. They are specified according to RFC 2198 and use dynamic=20 payload type "T140". 2.3 T.140 Text structure T.140 text is UTF-8 coded as specified in T.140 with no extra framing.= When using the format with redundant data, the transmitting entity may select= a number of T.140 block generations to retransmit in each packet. A higher= =20 number introduces better protection against loss of text.=20 A maximum of 6 generations may be used. 3. Proposed procedures This section contains proposed procedures for usage of the payload= format. Based on the information in the received packets, the receiver can: -reorder received text out of order. -mark where text is missing because of packet loss. -compensate for lost packets by using redundant data. 3.1 Proposed basic procedure =20 On reception, the RTP sequence number is compared with the sequence= number of the last correctly received packet.=20 If they are consecutive, only the most recent t140block is retrieved from= the received packet to the receiving T.140 instance.=20 3.2 Proposed procedure for compensation for lost packets. For reduction of data loss in case of packet loss, redundant data may be included in the packets. If network conditions are not known, it is recommended to use two= generations of T.140 blocks in the packets. If there is a gap in the RTP sequence= numbers,=20 and redundancy coded T.140blocks are available in the packet, older=20 Hellstr=F6m [Page 3] Internet Draft =09 t140blocks are retrieved from the packet up to the point where the=20 sequence number is consecutive to the last correctly received packet=20 or no more t140block are available in the received packet. If there is still a gap in the sequence, one T.140 missing data marker ( Unicode character 2607 "Lightning") is inserted, UTF-8 coded, replacing each missing t140block. =20 All t140blocks retrieved in this way are submitted to the receiving T.140 instance. 3.3 Proposed procedure for compensation for packets out of order. For protection against packets arriving out of order, the following= procedure may be implemented in the receiver. If analysis of a received packet reveals gaps in the sequence, the= received packet can be kept in a buffer before submission to the T.140 layer.=20 If a packet arrives with a t140block belonging to the gap, the gap is= filled with the contents of this block.=20 If all gaps are filled or the packet is kept in the buffer for 0.5= seconds, valid T140blocks in the buffered packet are retrieved and submitted to= the T.140 layer. For each t140block still missing, a T.140 missing data= marker (Unicode character 2607 "Lightning") is inserted.=20 3.4 Transmission during "silent periods" when redundancy is used. When using the redundancy transmission scheme, and there is nothing more to transmit from T.140, the latest t140block has a risk of getting old=20 before it is transmitted as redundant data. The result is less useful protection against packet loss at the end of a text input sequence.=20 For cases where this should be avoided, the ISO 10 646 synchronization character FEFF may be transmitted (UTF-8 coded) after some time of inactivity.=20 4. Examples This is an example of a T140 RTP packet without redundancy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC=3D0 |M| T140 dyn PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (1000Hz) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + T140 encoded data (PT=3Ddynamic) + | =20 | + +---------------+ | | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Hellstr=F6m [Page 4] Internet Draft =09 This is an example of an RTP packet with two t140 blocks using redundancy coding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC=3D0 |M| "RED" PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding "P" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| T140 dyn. PT| timestamp offset of "R" | "R" block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| T140 dyn. PT| | +-+-+-+-+-+-+-+-+ + | | + "R" T140 encoded redundant data (PT=3Ddynamic T140) + | (6 bytes, not to scale) | + +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | "P" T140 encoded primary data (PT=3Ddynamic T140) | + (4 bytes, not to scale) + + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Security Considerations. Since the intention of the described payload format is to carry text in= a text conversation, security measures in the form of encryption is of importance. The amount of data in a text conversation session is low and= =20 therefore any encryption method may be selected and applied to T.140 session contents or to the whole RTP packets.=20 When redundant data is included, the same security considerations as for RFC 2198 apply.=20 6. Author's Address Gunnar Hellstr=F6m L M Ericsson Sweden e-mail: gunnar.hellstrom@omnitor.se Tel: +46 708 204 288 Fax: +46 8 556 002 06 Hellstr=F6m [Page 5] Internet Draft Expires 17 Jan 2000 7 References [1] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,=20 "Real Time Transport Protocol", RFC 1889. [3] C. Perkins, I. Kouvelas, V. Hardman, M. Handley, and J. Bolot, "RTP payload for redundant audio data," RFC 2198, Internet Engineering Task Force, Sept. 1997. Hellstr=F6m [Page 6] --=====================_932183403==_ Content-Type: text/plain; charset="us-ascii" ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom@omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06 --=====================_932183403==_-- From rem-conf Tue Jul 20 15:17:51 1999 From rem-conf-request@es.net Tue Jul 20 15:17:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 116i1u-0002ZJ-00; Tue, 20 Jul 1999 15:06:30 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 116i1s-0002Yx-00; Tue, 20 Jul 1999 15:06:28 -0700 Received: from rtp-dial-1-10.cisco.com (rtp-dial-1-10.cisco.com [161.44.116.10]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA01825; Tue, 20 Jul 1999 15:05:21 -0700 (PDT) Date: Tue, 20 Jul 1999 15:05:04 -0700 (Pacific Daylight Time) From: Stephen Casner To: O.Hodson@cs.ucl.ac.uk cc: rem-conf@es.net Subject: Re: comment on draft-ietf-avt-profile-new-06.txt In-Reply-To: <199907072337.QAA40608@bobcat.aciri.org> 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 Orion, A somewhat delayed follow-up: > The latest avt profile draft again has no payload formats are > specified for the 2,3,5 bits per sample coding of G726 ADPCM. There > are only two issues - the packetization interval and the sample > packing order. Both are trivial but should be stated for the sake > interoperability. Actually, there is a difference in this profile draft. Since no payload format has been specified for the 2,3,5 bits per sample coding of G726 ADPCM, only the name "G726-32" is included and the others have been removed. Similarly, G.727 was removed entirely. > 20 ms packetization interval is common for most sample based coders > and results in all G726 encoding formats being byte aligned. That's fine; it's not all that important a parameter anyway (it is mostly just a recommendation). > The sample packing order is slightly complicated because the existing > G726-32 packs samples in the order s1-s0-s3-s2 and there is no obvious > extension to 3 and 5 bit per sample schemes since they do not align a > single octet boundary. The other sample based encodings pack samples > in the order with which they were generated. If there is no objection > from the list I would like to propose that the 2,3, and 5 bit per > sample encodings are packed in the order of sample generation and we > leave the 4 bits per sample as is. Actually, I believe you are just not recognizing that the G726-32 format is packed in little-endian order. I don't have the G.726 reference accessible at the moment, but perhaps it specifies this little-endian packing. There is a straightforward extension to this method for packing the samples of other sizes: you start at the LSB end of a byte, and put in bits from the LSB end of the sample. If the whole sample doesn't fit into a byte, the MSB's of the sammple go into the LSB's of the next byte. > At least one application already incorporates these codecs, not > because they are cutting edge, but because source code is publicly > available and (relatively) unencumbered. This application includes all of the sample sizes? -- Steve From rem-conf Wed Jul 21 08:54:12 1999 From rem-conf-request@es.net Wed Jul 21 08:54:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 116yai-0002lc-00; Wed, 21 Jul 1999 08:47:32 -0700 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 116yah-0002hK-00; Wed, 21 Jul 1999 08:47:31 -0700 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id LAA25084 for ; Wed, 21 Jul 1999 11:46:25 -0400 (EDT) Received: from woodr (woodr@woodr.cae.mitel.com [134.199.88.96]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with SMTP id LAA06423 for ; Wed, 21 Jul 1999 11:46:24 -0400 (EDT) Sender: woodr@Mitel.COM Message-ID: <3795EAE6.1505@mitel.com> Date: Wed, 21 Jul 1999 11:44:38 -0400 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/785) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTCP Sender reports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I hope someone can help me with the following questions: 1.) Can a compund RTCP packet contain multiple SRs. Only multiple RRs are discussed in the spec. 2.) Is the 5 second per RTCP on a per channel basis. i.e. if I'm sourcing 25 streams, say, should I be sending one RTCP SR packet every 5 seconds, or one every 1/5th of a second? 3.) For multiple bi-directional channels, can a compund RTCP packet contain multiple sender info sections and report blocks? Anxious bosses of inquiring minds want to know ;^) [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Wed Jul 21 09:36:35 1999 From rem-conf-request@es.net Wed Jul 21 09:36:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 116zKD-0005yO-00; Wed, 21 Jul 1999 09:34:33 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 116zKC-0005yE-00; Wed, 21 Jul 1999 09:34:32 -0700 Received: from duke (duke [128.111.49.49]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id JAA16491; Wed, 21 Jul 1999 09:34:16 -0700 (PDT) Date: Wed, 21 Jul 1999 09:34:15 -0700 (PDT) From: "David B. Makofske" X-Sender: davidm@duke To: Robert Wood cc: rem-conf@es.net Subject: Re: RTCP Sender reports In-Reply-To: <3795EAE6.1505@mitel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Robert, Unless something has changed since I last read the RTP specification, RTP was not intended to demultiplex multiple streams on the same "channel". What you usually see is each stream is given its own data channel (mcast address and port) and own control channel (by convention usually the same mcast address and the +1 port). Therefore if you were sourcing 2 audio channels and 1 video channel, you would also have 3 RTCP channels, each one corresponding to one of the data channels. So there would never be a need for a compound sender report, the source would send a single sender report on each RTCP channel which would correspond to one and only one of the data channels. The application or applications sourcing these streams would do a separate calculation on the frequency of RTCP packets based on on each individual channel. I hope that helps! - David Makofske On Wed, 21 Jul 1999, Robert Wood wrote: > Hi, > I hope someone can help me with the following questions: > > 1.) Can a compund RTCP packet contain multiple SRs. Only > multiple RRs are discussed in the spec. > > 2.) Is the 5 second per RTCP on a per channel basis. i.e. > if I'm sourcing 25 streams, say, should I be sending > one RTCP SR packet every 5 seconds, or one every 1/5th > of a second? > > 3.) For multiple bi-directional channels, can a compund > RTCP packet contain multiple sender info sections > and report blocks? > > Anxious bosses of inquiring minds want to know ;^) > > [\] Robert Wood > > The St. Lawrence river - fresh, warm, visible diving. > > mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ > > From rem-conf Wed Jul 21 22:12:08 1999 From rem-conf-request@es.net Wed Jul 21 22:12:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117AyJ-0002dJ-00; Wed, 21 Jul 1999 22:00:43 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 117AyG-0002cU-00; Wed, 21 Jul 1999 22:00:40 -0700 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Thu Jul 22 00:58:41 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.215]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA07703; Thu, 22 Jul 1999 00:58:48 -0400 (EDT) Message-ID: <3796A545.36EB2549@dnrc.bell-labs.com> Date: Thu, 22 Jul 1999 00:59:49 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Wood CC: rem-conf@es.net Subject: Re: RTCP Sender reports References: <3795EAE6.1505@mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Robert Wood wrote: > > Hi, > I hope someone can help me with the following questions: > > 1.) Can a compund RTCP packet contain multiple SRs. Only > multiple RRs are discussed in the spec. By definition, a sender in an RTP session is generating a single media stream. It sends RTCP packets for the stream it generates, which means one SR per RTCP packet. > > 2.) Is the 5 second per RTCP on a per channel basis. i.e. > if I'm sourcing 25 streams, say, should I be sending > one RTCP SR packet every 5 seconds, or one every 1/5th > of a second? That depends what you mean by channel. If each of the 25 streams is a separate RTP session (separate session means different address/port), the RTCP interval is independent for each stream. For each sender, RTCP would be generated, on average, once every 5 seconds. Note that RTCP transmission is randomized and is not with a fixed 5 second period. If, however, there is a single RTP multicast session, and the 25 streams are 25 separate senders in the same session, the RTCP bandwidth is divided among them. This means that the average RTCP period from each increases, possibly by a factor of 25 (it could be less depending on whether the avg RTCP packet size divided by the RTCP sender bandwidth is more or less than 5 seconds). > > 3.) For multiple bi-directional channels, can a compund > RTCP packet contain multiple sender info sections > and report blocks? Assuming "multiple bi-directional channels" means multiple unicast sessions between the same endpoints, no. RTCP feedback is for the session it is sent on. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jul 22 04:17:24 1999 From rem-conf-request@es.net Thu Jul 22 04:17:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117GpE-0002D9-00; Thu, 22 Jul 1999 04:15:44 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 117GpD-0002Ch-00; Thu, 22 Jul 1999 04:15:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11319; Thu, 22 Jul 1999 07:14:39 -0400 (EDT) Message-Id: <199907221114.HAA11319@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-05.txt Date: Thu, 22 Jul 1999 07:14:39 -0400 Sender: nsyracus@ns.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-05.txt Pages : 10 Date : 21-Jul-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-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtpsample-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990721075436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990721075436.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jul 22 04:17:24 1999 From rem-conf-request@es.net Thu Jul 22 04:17:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117Gp5-0002Cy-00; Thu, 22 Jul 1999 04:15:35 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 117Gp3-0002Ce-00; Thu, 22 Jul 1999 04:15:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11302; Thu, 22 Jul 1999 07:14:29 -0400 (EDT) Message-Id: <199907221114.HAA11302@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-fec-07.txt Date: Thu, 22 Jul 1999 07:14:29 -0400 Sender: nsyracus@ns.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 : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-07.txt Pages : 22 Date : 21-Jul-99 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-fec-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-fec-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990721075419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990721075419.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jul 22 06:33:37 1999 From rem-conf-request@es.net Thu Jul 22 06:33:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117IwJ-0004Du-00; Thu, 22 Jul 1999 06:31:11 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 117IwI-0004Dk-00; Thu, 22 Jul 1999 06:31:10 -0700 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id DFAC04CE21; Thu, 22 Jul 1999 09:31:02 -0400 (EDT) Received: from uxmal (uxmal.research.att.com [135.207.27.95]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id JAA03910; Thu, 22 Jul 1999 09:31:02 -0400 (EDT) Message-ID: <061c01bed446$6fe3ec80$5f1bcf87@research.att.com> From: "Timur Friedman" To: , "Robert Wood" References: <3795EAE6.1505@mitel.com> Subject: Re: RTCP Sender reports Date: Thu, 22 Jul 1999 09:30:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Robert Wood wrote: > 1.) Can a compund RTCP packet contain multiple SRs. Only > multiple RRs are discussed in the spec. As others have pointed out, a sender only reports on itself, qua sender, once. Nonetheless, the short definitions of SR and RR (6.1) do make it reasonable to wonder what a sender should do in order to send more than 31 reception report blocks: SR: Sender report, for transmission and reception statistics from participants that are active senders RR: Receiver report, for reception statistics from participants that are not active senders On its face this means that RRs should not be sent by active senders. This appears to contradict the later statements (6.1, 6.4) that RRs may be stacked after an initial SR. A close textual reading is necessary to conclude without contradiction that even though RRs are "for" reception statistics from participants that are not active servers, they can be "for" other things as well. These SR and RR definitions are likely the place most people look to remind themselves of the purpose of these packets, as they are the first time SRs and RRs are mentioned in the spec. It would be good if they were not misleading in this way. I suggest the following wording: RR: Receiver report, for reception statistics from participants that are not active senders, and for supplementary reception statistics from any participant -- Timur Friedman http://www.cs.umass.edu/~friedman From rem-conf Thu Jul 22 06:53:31 1999 From rem-conf-request@es.net Thu Jul 22 06:53:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117JFV-0004xV-00; Thu, 22 Jul 1999 06:51:01 -0700 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 117JFU-0004u0-00; Thu, 22 Jul 1999 06:51:00 -0700 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id JAA17826; Thu, 22 Jul 1999 09:49:52 -0400 (EDT) Received: from woodr (woodr@woodr.cae.mitel.com [134.199.88.96]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with SMTP id JAA04350; Thu, 22 Jul 1999 09:49:51 -0400 (EDT) Sender: woodr@Mitel.COM Message-ID: <37972115.42B1@mitel.com> Date: Thu, 22 Jul 1999 09:48:05 -0400 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/785) MIME-Version: 1.0 To: Timur Friedman CC: rem-conf@es.net Subject: Re: RTCP Sender reports References: <3795EAE6.1505@mitel.com> <061c01bed446$6fe3ec80$5f1bcf87@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Timur Friedman wrote: > > Robert Wood wrote: > > 1.) Can a compund RTCP packet contain multiple SRs. Only > > multiple RRs are discussed in the spec. > > As others have pointed out, a sender only reports on itself, qua sender, > once. Nonetheless, the short definitions of SR and RR (6.1) do make it > reasonable to wonder what a sender should do in order to send more than 31 > reception report blocks: > > SR: Sender report, for transmission and reception statistics > from participants that are active senders > > RR: Receiver report, for reception statistics from participants > that are not active senders > > On its face this means that RRs should not be sent by active senders. This > appears to contradict the later statements (6.1, 6.4) that RRs may be > stacked after an initial SR. A close textual reading is necessary to > conclude without contradiction that even though RRs are "for" reception > statistics from participants that are not active servers, they can be "for" > other things as well. > > These SR and RR definitions are likely the place most people look to remind > themselves of the purpose of these packets, as they are the first time SRs > and RRs are mentioned in the spec. It would be good if they were not > misleading in this way. I suggest the following wording: > > RR: Receiver report, for reception statistics from participants > that are not active senders, and for supplementary > reception statistics from any participant So, in the case I'm considering, multiple phone calls, I will only generate SRs and never an RR ? [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Thu Jul 22 08:34:45 1999 From rem-conf-request@es.net Thu Jul 22 08:34:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117KoX-0006gg-00; Thu, 22 Jul 1999 08:31:17 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 117KoW-0006gW-00; Thu, 22 Jul 1999 08:31:16 -0700 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 183134CE29; Thu, 22 Jul 1999 11:31:10 -0400 (EDT) Received: from uxmal (uxmal.research.att.com [135.207.27.95]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id LAA10742; Thu, 22 Jul 1999 11:31:09 -0400 (EDT) Message-ID: <065401bed457$37b318c0$5f1bcf87@research.att.com> From: "Timur Friedman" To: "Robert Wood" Cc: References: <3795EAE6.1505@mitel.com> <061c01bed446$6fe3ec80$5f1bcf87@research.att.com> <37972115.42B1@mitel.com> Subject: Re: RTCP Sender reports Date: Thu, 22 Jul 1999 11:31:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Robert Wood wrote: > So, in the case I'm considering, multiple phone calls, I will > only generate SRs and never an RR ? If each participant is a data sender then each will generate an SR. A participant would only generate an RR in the case where it had to report on more than 31 other senders. Under those circumstances (not, I imagine, what you are envisioning with respect to telephone calls), it would generate an SR followed by one or more RRs to handle the additional reports. -- Timur Friedman http://www.cs.umass.edu/~friedman From rem-conf Thu Jul 22 09:07:33 1999 From rem-conf-request@es.net Thu Jul 22 09:07:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117LKo-0007Vb-00; Thu, 22 Jul 1999 09:04:38 -0700 Received: from (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 117LKm-0007VE-00; Thu, 22 Jul 1999 09:04:36 -0700 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id MAA01957; Thu, 22 Jul 1999 12:02:51 -0400 (EDT) Received: from woodr (woodr@woodr.cae.mitel.com [134.199.88.96]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with SMTP id MAA08081; Thu, 22 Jul 1999 12:02:50 -0400 (EDT) Sender: woodr@Mitel.COM Message-ID: <3797403F.6DF@mitel.com> Date: Thu, 22 Jul 1999 12:01:03 -0400 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/785) MIME-Version: 1.0 To: Timur Friedman CC: rem-conf@es.net Subject: Re: RTCP Sender reports References: <3795EAE6.1505@mitel.com> <061c01bed446$6fe3ec80$5f1bcf87@research.att.com> <37972115.42B1@mitel.com> <065401bed457$37b318c0$5f1bcf87@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list So, having looked at this issue, in my application, it looks like I only have to bother with SR packets. I wonder if anyone is actually using RTCP. I know Microsoft's netwmeeting product generates them, but does even it use them? I can imagine a lot of products coming forth which will generate RTCP but not actually do anything with received RTCP packets. [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Thu Jul 22 09:41:04 1999 From rem-conf-request@es.net Thu Jul 22 09:41:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117Lmx-0000Ss-00; Thu, 22 Jul 1999 09:33:43 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 117Lmw-0000Sd-00; Thu, 22 Jul 1999 09:33:42 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id A17DB4CE2F; Thu, 22 Jul 1999 12:33:30 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA01555; Thu, 22 Jul 1999 12:33:27 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA23084; Thu, 22 Jul 1999 09:33:27 -0700 (PDT) Message-Id: <199907221633.JAA23084@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: robert_wood@mitel.com Subject: Re: RTCP Sender reports Cc: rem-conf@es.net References: <3795EAE6.1505@mitel.com> <061c01bed446$6fe3ec80$5f1bcf87@research.att.com> <37972115.42B1@mitel.com> <065401bed457$37b318c0$5f1bcf87@research.att.com> <3797403F.6DF@mitel.com> Date: Thu, 22 Jul 1999 09:33:26 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RTP monitors like UCB's "rtpmon" (ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/) use RTCP. Bill From rem-conf Thu Jul 22 15:12:25 1999 From rem-conf-request@es.net Thu Jul 22 15:12:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117R1c-0004aI-00; Thu, 22 Jul 1999 15:09:12 -0700 Received: from hopper.math.uwaterloo.ca [129.97.78.132] (bmukherj) by mail1.es.net with esmtp (Exim 1.81 #2) id 117R1a-0004a8-00; Thu, 22 Jul 1999 15:09:11 -0700 Received: from localhost (bmukherj@localhost) by hopper.math.uwaterloo.ca (8.8.8/8.8.8) with SMTP id SAA26707 for ; Thu, 22 Jul 1999 18:09:09 -0400 (EDT) Date: Thu, 22 Jul 1999 18:09:09 -0400 (EDT) From: Biswaroop Mukherjee 8-| To: rem-conf@es.net Subject: RTP Algorithms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As far as I could tell the RTP and RTCP specs do not specify control mechanisms or algorithms. Does someone know of any paper which describes the specific algorithms used in an implementation for things like, when to send in the next packet of data or what to do when a certain type of sender report arrives. --Biswaroop Mukherjee http://www.cs.uwaterloo.ca/~bmukherj From rem-conf Thu Jul 22 16:03:47 1999 From rem-conf-request@es.net Thu Jul 22 16:03:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117RrO-0005yu-00; Thu, 22 Jul 1999 16:02:42 -0700 Received: from tesla.comm.utoronto.ca (tesla.comm.toronto.edu) [128.100.11.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 117RrN-0005yk-00; Thu, 22 Jul 1999 16:02:41 -0700 Received: from riemann.comm (riemann.comm [128.100.11.18]) by tesla.comm.toronto.edu (8.9.0/8.9.0) with ESMTP id TAA03013; Thu, 22 Jul 1999 19:00:26 -0400 (EDT) From: Hassan Naser Received: (from hnaser@localhost) by riemann.comm (8.9.0/8.9.0) id TAA26658; Thu, 22 Jul 1999 19:00:17 -0400 (EDT) Message-Id: <199907222300.TAA26658@riemann.comm> Subject: MGCP source code? To: rem-conf@es.net Date: Thu, 22 Jul 1999 19:00:15 -0400 (EDT) Cc: owner-confctrl@ISI.EDU X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Is there any MGCP source code available for Linux? Thanks Hassan Naser Dept. of Electrical & Computer Eng. University of Toronto, Toronto, Ontario, M5S-3G4 Canada Work: (416) 978 4829 Fax: (416) 978 4425 Email: hnaser@nal.utoronto.ca From rem-conf Thu Jul 22 16:51:50 1999 From rem-conf-request@es.net Thu Jul 22 16:51:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117Saz-0007JS-00; Thu, 22 Jul 1999 16:49:49 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 117Sax-0007Is-00; Thu, 22 Jul 1999 16:49:47 -0700 Received: from BMRC.Berkeley.EDU (opus.CS.Berkeley.EDU [128.32.131.116]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id QAA23039; Thu, 22 Jul 1999 16:49:46 -0700 (PDT) Message-ID: <3797AE1B.9E8F8179@BMRC.Berkeley.EDU> Date: Thu, 22 Jul 1999 16:49:47 -0700 From: "Lawrence A. Rowe" Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mbone@ISI.EDU, rem-conf Subject: Mbone/Real playback Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi - We have experimented a bit with this technology. Here are some interesting facts and/or features. 1. Yes, you can play an Mbone stream (h.261/pcm) using the player. But it can be only one video source. 2. You can play two concurrent video streams using the G2/SMIL player. The two streams can be regular G2 streams or one or both can be Mbone streams. I've attached example Smil files below. I also included the modified sdp file needed to play the Mbone stream. Audio works correctly in the dual streams in that the audio tracks from the two streams are mixed before being played. 3. A company in Mass, named Bitcasting, has implemented a G2 server side plug-in that allows live and on-demand broadcasting of MPEG streams. Specifically, you can play stored MPEG1 streams using the standard G2 player if you have purchased their server plug-in. To see an amazing demo, check out www.bitcasting.com. Bitcasting also sells a live encoder option but you have to use a particular board that is relatively expensive. They will also stream stored MPEG2 streams, but you have to use a hardware decoder. We are experimenting with various combinations of Mbone, G2, and G2/SMIL sessions for the Berkeley MIG Seminar that will begin again on Wed Aug 25, 1999. Watch this list for further announcements. My hope is that later in the fall we will offer MPEG1 on-demand replay of selected talks along with synchronized slides using either SMIL or possibly a Javascript based replay client. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry --- Dual G2 Streams in SMIL ----- G2 and Mbone SMIL ---- dbs.sdp file mentioned in G2/Mbone example v=0 o=pbhuang 1 1 IN IP4 169.229.12.73 s=Satellite i=The satellite link in Soda Hall, University of California, Berkeley e=Paul Huang c=IN IP4 239.255.124.168/1 t=0 0 a=type:broadcast m=video 49256 RTP/AVP 31 c=IN IP4 239.255.124.168/1 m=audio 28366 RTP/AVP 00 c=IN IP4 239.255.53.104/1 --- From rem-conf Fri Jul 23 04:12:47 1999 From rem-conf-request@es.net Fri Jul 23 04:12:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117d86-0000az-00; Fri, 23 Jul 1999 04:04:42 -0700 Received: from smtp.salixtech.com (salix.com) [38.220.190.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 117d84-0000aW-00; Fri, 23 Jul 1999 04:04:41 -0700 Received: from computer ([10.1.1.148]) by gateway.salix.com with SMTP id <27778>; Fri, 23 Jul 1999 06:55:30 -0400 Reply-To: From: "Hung Bui" To: "'Hassan Naser'" , Subject: RE: MGCP source code? Date: Fri, 23 Jul 1999 07:03:12 -0400 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199907222300.TAA26658@riemann.comm> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Message-Id: <99Jul23.065530edt.27778@gateway.salix.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please check www.vovida.com. -----Original Message----- From: Hassan Naser [mailto:hnaser@comm.toronto.edu] Sent: Thursday, July 22, 1999 7:00 PM Hi Is there any MGCP source code available for Linux? Hassan Naser Dept. of Electrical & Computer Eng. University of Toronto, Toronto, Ontario, M5S-3G4 Canada Work: (416) 978 4829 Fax: (416) 978 4425 Email: hnaser@nal.utoronto.ca ========= =========== Hung Bui mailto:hvb@salix.com ============ Consultant http://www.salix.com ============ SALIX Technologies, Inc. == ==== == 904 Wind River Lane TEL: (301) 417-0017 == Suite 101 FAX: (301) 990-6400 === Gaithersburg, MD 20878 The statements contained herein are strictly those of their author, and unless otherwise specifically indicated should not be attributed to SALIX(r) or its management. From rem-conf Fri Jul 23 04:25:56 1999 From rem-conf-request@es.net Fri Jul 23 04:25:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117dQI-0001AQ-00; Fri, 23 Jul 1999 04:23:30 -0700 Received: from (artemis.rus.uni-stuttgart.de) [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 117dQG-00018l-00; Fri, 23 Jul 1999 04:23:29 -0700 Received: from ksat22 (ksat22.rus.uni-stuttgart.de [129.69.13.26]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id NAA05727; Fri, 23 Jul 1999 13:22:22 +0200 (MET DST) env-from (wesner@rus.uni-stuttgart.de) From: "Stefan Wesner" To: "Jonathan Rosenberg" Cc: "Rem-Conf" , "Paul Christ" , "Christine Guillemot" , "Jerome. Vieron" Subject: Problems with Generic FEC and Redundant Audio Encoding ? Date: Fri, 23 Jul 1999 13:21:46 +0200 Message-ID: <000e01bed4fd$8ca60ee0$1a0d4581@ksat22.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by artemis.rus.uni-stuttgart.de id NAA05727 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have question concerning the usage of the GenericFEC in conjunction wit= h the redundant audio format (section 11 in the draft). In section 8 it is described that the FEC operation is applied to (beside others) to the X bit and the CC bits. And that the Extension and CSRC Lis= t is supposed to be part of the payload and is therefore protected together with the payload. So the FEC payload will potentially consists of Xtensio= n data, CSRC List and media payload header and data. In section 11 it is nothing said where to place the X bit and the CC bits for the case of usage of FEC with redundant audio. The reconstruction process says that for the reconstructing the FEC packe= t the X bit and the CC bit should be copied from the RTP packet that contai= ned the primary encoding and the fec as secondary data. I think it is not appropriate to assume that the CC bits and the X bit ar= e the same for this FEC RTP packet and for the RTP packet that contains the media and the FEC. Possibly "wrong" CC bits and X bit will lead to wrong results. I try to make an example: Assuming the extension is switched "on" for the current RTP packet (with = the data+fec) the X bit will be set to 1. The previous RTP packets had the X = bit set to 0. So the result of a XOR operation would have been also 0. Doing = the proposed procedure will result in a FEC packet with X bit set to 1. In th= e recovery array the X bit will be also "1". The interpretation of the byte array will assume a header extension and will therefore not be able to interpret the recovery array correctly. So the mechanism for redundant audio works only for the case CC bits are "0000" and X bit =3D "0". Do I miss something ? Kind regards, Stefan Wesner. -- University Stuttgart computer centre Stefan Wesner Communication Systems & BelW=FC development Allmandring 3a mailto:wesner@rus.uni-stuttgart.de 70550 Stuttgart Tel.: +49 711 685 4275 Fax.: +49 711 678 8363 From rem-conf Fri Jul 23 20:43:43 1999 From rem-conf-request@es.net Fri Jul 23 20:43:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 117saa-0005CA-00; Fri, 23 Jul 1999 20:35:08 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 117saY-0005C0-00; Fri, 23 Jul 1999 20:35:06 -0700 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jul 23 23:33:13 EDT 1999 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by scummy; Fri Jul 23 23:30:29 EDT 1999 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by grubby; Fri Jul 23 22:59:27 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by grubby; Fri Jul 23 22:40:13 EDT 1999 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by scummy; Fri Jul 23 22:13:16 EDT 1999 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by grubby; Fri Jul 23 21:36:10 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by grubby; Fri Jul 23 21:12:31 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Fri Jul 23 20:48:59 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Fri Jul 23 20:34:31 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Fri Jul 23 20:09:55 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Fri Jul 23 19:51:09 EDT 1999 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by scummy; Fri Jul 23 19:34:08 EDT 1999 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by scummy; Fri Jul 23 19:12:16 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.239]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA22414; Fri, 23 Jul 1999 19:08:49 -0400 (EDT) Message-ID: <3798F63D.B470827E@dnrc.bell-labs.com> Date: Fri, 23 Jul 1999 19:09:49 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Wesner CC: Rem-Conf , Paul Christ , Christine Guillemot , "Jerome. Vieron" Subject: Re: Problems with Generic FEC and Redundant Audio Encoding ? References: <000e01bed4fd$8ca60ee0$1a0d4581@ksat22.rus.uni-stuttgart.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are correct. As defined, the mechanism for encapsulating the FEC in the redundant encodings payload could cause the CC and X bits to be mis-constructed if they are not all zeroes. I see two ways to fix this: 1. Specify that when used with redundant encodings, the FEC must be used across packets without extension or CC bits set. 2. Specify that when used with redundant encodings, packets with extension and CC bits set must have the extension and CSRC list removed, and the bits set to zero, before computing the FEC. However, the packet itself can be sent with the extension and CSRC list included. This basically means that if recovered, it will be recovered without the extension and CSRC list. I tend to prefer (2). Whatever the change we decide, I will fold it in as part of the overall revision to reflect comment received during IESG last call, which this draft is now in. Thanks, Jonathan R. Stefan Wesner wrote: > > Hi, > > I have question concerning the usage of the GenericFEC in conjunction with > the redundant audio format (section 11 in the draft). > > In section 8 it is described that the FEC operation is applied to (beside > others) to the X bit and the CC bits. And that the Extension and CSRC List > is supposed to be part of the payload and is therefore protected together > with the payload. So the FEC payload will potentially consists of Xtension > data, CSRC List and media payload header and data. > > In section 11 it is nothing said where to place the X bit and the CC bits > for the case of usage of FEC with redundant audio. > > The reconstruction process says that for the reconstructing the FEC packet > the X bit and the CC bit should be copied from the RTP packet that contained > the primary encoding and the fec as secondary data. > > I think it is not appropriate to assume that the CC bits and the X bit are > the same for this FEC RTP packet and for the RTP packet that contains the > media and the FEC. > > Possibly "wrong" CC bits and X bit will lead to wrong results. > > I try to make an example: > Assuming the extension is switched "on" for the current RTP packet (with the > data+fec) the X bit will be set to 1. The previous RTP packets had the X bit > set to 0. So the result of a XOR operation would have been also 0. Doing the > proposed procedure will result in a FEC packet with X bit set to 1. In the > recovery array the X bit will be also "1". The interpretation of the byte > array will assume a header extension and will therefore not be able to > interpret the recovery array correctly. > > So the mechanism for redundant audio works only for the case CC bits are > "0000" and X bit = "0". > > Do I miss something ? > > Kind regards, > > Stefan Wesner. > -- > University Stuttgart computer centre > Stefan Wesner Communication Systems & BelWü development > Allmandring 3a mailto:wesner@rus.uni-stuttgart.de > 70550 Stuttgart Tel.: +49 711 685 4275 Fax.: +49 711 678 8363 -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Jul 24 23:32:35 1999 From rem-conf-request@es.net Sat Jul 24 23:32:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118HcN-0001dj-00; Sat, 24 Jul 1999 23:18:39 -0700 Received: from smtp.efortress.com (mailrelay.efortress.com) [205.181.175.207] by mail1.es.net with esmtp (Exim 1.81 #2) id 118HcL-0001dZ-00; Sat, 24 Jul 1999 23:18:38 -0700 Received: from eastmail.com ([192.41.69.179]) by mailrelay.efortress.com (Pro-8.9.3/Pro-8.9.3) with SMTP id CAA06353; Sun, 25 Jul 1999 02:18:18 -0400 (EDT) From: spynow616@eastmail.com Message-Id: <199907250618.CAA06353@mailrelay.efortress.com> Date: 7/21/99 8:22:32 PM Pacific Daylight Time Reply-To: spynow616@eastmail.com To: spynow616@eastmail.com Subject: >>> Warning - Don't Get Ripped Off !!! <<< X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There have been some dishonest people who have copied this advertisement in an attempt to sell their own "cheap imitation" of the Internet Spy & You program. Don't be misled by other offers for $15 and $22 programs being advertised on the net... you get what you pay for, and there's only ONE "Internet Spy & You" program!!! Please see disclaimers at the end of this mailing. <><><><><><><><><><><><><><><><><><><><><> Welcome to another... ListBott "Opt-In" broadcast. <><><><><><><><><><><><><><><><><><><><><> Dear Subscriber, We have been FORCED TO LIMIT OUR DISTRIBUTION after July 28th !!! Don't miss this very limited time opportunity to get the software that will allow you to become the ultimate "Super Snoop" on anyone !!! Get The SOFTWARE They Want BANNED In All COUNTRIES!!! "THE INTERNET SPY AND YOU" SHOWS YOU HOW TO GET THE FACTS ON ANYONE!!! You now have just 4 days left to get the software they want banned in every country !!! Why? Because these secrets were never intended to reach your eyes... Plus, this is a VERY LIMITED TIME OFFER !!! Get the facts on anyone using the Internet! Locate Missing Persons, find Lost Relatives, obtain Addresses and Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public Record databases. Find out SECRETS about your relatives, friends, enemies, and everyone else! -- even your spouse with the new, INTERNET SPY AND YOU!!! It's absolutely astounding! Here's what you can learn: License plate number! Get anyone's name and address with just a license plate number! (Find that girl you met in traffic!) Driving record! Get anyone's driving record Social security number! Trace anyone by social security number! Address! Get anyone's address with just a name! Unlisted phone numbers! Get anyone's phone number with just a name - even unlisted numbers! Locate! Long lost friends, relatives, a past lover who broke your heart! E-mail! Send anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private investigators use (all on the Internet) secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! (Dig up old skeletons) Criminal search-background check! Find out about your daughters boyfriend! (or her husband) Find out! If you are being investigated! Neighbors! Learn all about your mysterious neighbors! Find out what they have to hide! People you work with! Be astonished by what you'll learn about people you work with! Education verification! Did he really graduate college? Find out! Internet Spy and You Software will help you discover ANYTHING about anyone, with clickable hyperlinks, no typing in Internet addresses! Just insert the floppy disk and Go! You will be shocked and amazed by the secrets that can be discovered about absolutely everyone! Find out the secrets they don't want you to know! About others, about yourself! It's INCREDIBLE what you can find out using the Internet Spy and You and the Internet! You'll be riveted to your computer screen! Get the software they're trying to ban! ACT NOW, Before it's too late! LIMITED TIME OFFER -- THIS SPECIAL SOFTWARE OFFER EXPIRES IN JUST 96 HOURS!!! ORDER TODAY!!! Only $45.95 U.S. (Postage Paid) Only $39.95 U.S. (If paying with Cash or Money Order.) We will RUSH YOU our Internet Spy and You software so you can begin discovering all the secrets you ever wanted to know! You can know EVERYTHING about ANYONE with our Internet Spy and You Software. Works with all browsers and all versions of AOL! ORDER TODAY !!! Send Only $45.95 U.S. (Postage Paid) OR, Only $39.95 U.S. (If paying with Cash or Money Order.) Sorry, NO PERSONAL OR BUSINESS CHECKS will be accepted. (ORDERS OUTSIDE THE USA, ADD $25.00) (ALL SOFTWARE PACKAGES SHIPPED WITHIN 48 HOURS) DON'T WAIT TO GET STARTED... here's what to do: STEP 1 - Compose a new message using the order form text below STEP 2 - Type or print your order information into the order form section STEP 3 - Print your completed order, then mail to the address below >>> Order Toll-Free <<< OPTIONAL, you may choose to place your order on our secure voicemail system by calling 1-800-242-0363 Ext 1940 >>> Order By Mail <<< (Must be called-in or postmarked "on" or "before" 7/28/99) Send to: Network Innovations Authorization: 1096-A10 1393 West 9000 South Suite 171 West Jordan, Utah 84088 U.S.A. >>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<< We have been forced to limit the distribution of this resource. Orders received or postmarked AFTER 7/28/99, will be returned. Sorry, there will be NO exceptions!!! >>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<< >>> Mail-in Order Form <<< Auth: 1096-A10 Name: Address: City: State: Zip: Method of payment: [ ] Visa [ ] MasterCard [ ] American Express Credit Card#: Exp Date: YOUR SIGNATURE HERE:_______________________________ We cannot process your credit card payment without your signature! [ ] Credit Card Orders $45.95!!! [ ] Money Order mail in orders -- only $39.95!!! [ ] Cash mail in orders -- only $39.95!!! WE DO NOT ACCEPT PERSONAL CHECKS!!! "Products & Services For Doing Business On The Net" (SORRY, NO MAC VERSION AVAILABLE AT THIS TIME.) NOTE: THIS PROGRAM WILL NOT WORK ON WINDOWS 3.11 AND OLDER REFUNDS: Since this is "information" on disk, we cannot issue a refund after your order is shipped, only a replacement if necessary. DISCLAIMER: The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use its resources. ************************************************************************************************** This mailing is done by an independent marketing company. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E-mail. No wasted paper! To be removed from this listserver, address book, please call us toll-free at 1-800-242-0363 Ext 1940 and we'll promptly honor your remove request. From rem-conf Sun Jul 25 04:32:40 1999 From rem-conf-request@es.net Sun Jul 25 04:32:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118M9z-0000pb-00; Sun, 25 Jul 1999 04:09:39 -0700 Received: from munin.cenacle.se (domino1.cenacle.se) [195.100.101.136] by mail1.es.net with esmtp (Exim 1.81 #2) id 118M3M-0007bd-00; Sun, 25 Jul 1999 04:02:49 -0700 Received: from pokj09h ([209.114.165.43]) by domino1.cenacle.se (Lotus Domino Build 166.1) with SMTP id 1999072512582686:3307 ; Sun, 25 Jul 1999 12:58:26 +0200 To: jh88@aol.com From: Subject: Your International License X-MIMETrack: Itemize by SMTP Server on domino1/Cenacle(Release 5.0 (Intl)|30 March 1999) at 99/07/25 12:58:28, Serialize by Router on domino1/Cenacle(Release 5.0 (Intl)|30 March 1999) at 99/07/25 12:58:59, Serialize complete at 99/07/25 12:58:59 Date: Sun, 25 Jul 1999 10:58:28 GMT Message-ID: X-Priority: 3 (Normal) MIME-Version: 1.0 content-length: 699 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 From rem-conf Mon Jul 26 08:21:33 1999 From rem-conf-request@es.net Mon Jul 26 08:21:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118mJ1-0006q1-00; Mon, 26 Jul 1999 08:04:43 -0700 Received: from mail1.alestra.net.mx [207.248.224.72] by mail1.es.net with esmtp (Exim 1.81 #2) id 118mJ0-0006pp-00; Mon, 26 Jul 1999 08:04:42 -0700 Received: from mcxiy.abc.com.hk ([209.249.147.252]) by mail1.alestra.net.mx (Post.Office MTA v3.1.2 release (PO203-101c) ID# 630-51681U3000L3000S0) with SMTP id AAA13967; Mon, 26 Jul 1999 10:06:13 -0700 From: horsy@hotbot.com To: jrqctulzxt@aol.com Reply-To: Subject: Accepting Credit Cards? qdpas Message-Id: Date: Mon, 26 Jul 1999 08:04:42 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list INCREASE SALES UP TO 50%....This Number will lead you to doing just that......1-800-636-6773 Ext. 4533 ACCEPT CREDIT CARDS OVER THE INTERNET.....NO SETUP FEES!! Good Credit/Bad Credit/No Credit.....*** NO PROBLEM*** It just Doesn't Matter - Everyone Gets Approved No Upfront Fees For application-Processing! While Others Charge You From $195 to $250 to Get Set Up WE CHARGE ZERO FOR SETUP FEES!!! Limited Offer So Take Advantage of it!! We Specialize in Servicing The Following: ** Multilevel Marketing ** Mail Order! Phone Sales ** Home Based Business ** INTERNET BASED BUSINESS ** New Business ** Small Business ** Whatever!! We Do It ALL!!! Everyone is Welcome!! ** Scroll to bottom of this e-mail for CONTACT INFORMATION!! Or better yet, no need to wait, Call 1-800-636-6773 ext. 4533 >>>>> INTERNET SERVICE <<<<< It's finally here!! A fast and reliable way to process credit cards through your web site The Internet's reach is global - it knows no time zones or physical boundaries. With our user friendly, easy to use program, you will convert your web site from an electronic brochure to a virtual storefront without the addition of a sales clerk!!! SECURE REAL-TIME ON-LINE TRANSACTIONS make it as easy as possible for your customers to purchase your products or services. We use SSL SECURITY (best on the NET today!). You will summon your customers' impulse buying when you can safely process credit cards through a secured web site linked directly to your web page. The Internet is the fastest growing industry in today's direct marketing business. DON'T BE LEFT BEHIND!!! Give your customers the convenience of ordering products right from your web page. Now tell me if this doesn't sound intriguing, lets say a customer visits your web site and decides they want to buy your product(s) or service(s). They would simply enter their credit card information and receive an approval WITHIN 5 SECONDS. That's all there is to it!!! >From that point on, the sale is complete and the money will be directly deposited into your business checking account within 24 to 48 hours. So you will have LIQUID ASSETS AVAILABLE ALMOST IMMEDIATELY!!! Your customer will be e-mailed a receipt, and you will be e-mailed an invoice slip, all instantaneously. Now, since this program is automated for 24 hours a day 7 days a week, you will be receiving orders and making money in your sleep!!! IT'S JUST THAT EASY!!! >>>>> CONTACT INFORMATION <<<<< 1-800-636-6773 Ext. 4533 We Also offer SOFTWARE AND TERMINAL PACKAGES. With our SOFTWARE PROGRAM, you can now take PHONE, and MAIL ORDERS, accept credit cards and expose your business to thousands of new customers. All of this done through your own personal computer!!! To accommodate your STOREFRONT RETAIL BUSINESS, we offer an ELECTRONIC TERMINAL, and PRINTER PACKAGE. A terminal will allow you to receive the LOWEST DISCOUNT RATE per transaction available. >>>>> CONTACT INFORMATION <<<<< 1-800-636-6773 Ext. 4533 You can apply for a merchant account with NO APPLICATION FEE, and BETTER RATES!!! We believe the ability to accept credit card payments greatly enhances your business, adds additional credibility in the marketplace, and increases your potential for immediate sales. So, if your serious about increasing your business potential, get your own Merchant Account Today!!! Call the following Number and Get Started Right Away!! 1-800-636-6773 Ext. 4533 Thank You and Here's to Bigger and Better Business!!! To be removed from future mailings email rock991@hotbot.com with remove as the subject. From rem-conf Mon Jul 26 14:03:48 1999 From rem-conf-request@es.net Mon Jul 26 14:03:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118rpR-0005YB-00; Mon, 26 Jul 1999 13:58:33 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 118rpQ-0005Xh-00; Mon, 26 Jul 1999 13:58:32 -0700 Received: from uggla (hil-qbu-ptg-vty9.as.wcom.net [206.175.103.9]) by mail.pi.se (8.8.8/8.8.8) with SMTP id WAA08430; Mon, 26 Jul 1999 22:58:15 +0200 (MET DST) Message-Id: <3.0.1.32.19990726225600.00772d1c@mail.pi.se> X-Sender: au1042@mail.pi.se (Unverified) X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 26 Jul 1999 22:56:00 +0200 To: rem-conf@es.net From: Gunnar Hellstrom Subject: draft-hellstrom-avt-rtp-text-01.txt Result of Oslo discussion. Cc: textphone@lsv.pi.se (Text Telephone Forum), mickey.nasiri@etx.ericsson.se, itu-sg16@mailbag.cps.intel.com 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 The draft rtp specification for text conversation that is discussed in the IETF AVT group is now available in the following URL.=20 www.omnitor.se/english/standards/rtp/draft-hellstrom-avt-rtp-text-01.txt It is referenced in the H.323 Annex G Text Conversation draft that is entered as a contribution to the ITU-T Q13/16 meeting next week as document APC1561. I would like to receive comments on this draft. I am aware of the following points that might need discussion. 1. Timestamp clock frequency. I had put a low figure 10 Hz in the specification. It was questioned and proposed that a figure of some thousands should be selected.=20 I am willing to accept that, and propose that 1000 Hz is used. A millisecond per tick is a handy figure.=20 This will however lead to the timestamp offset in the redundancy data headers that use only 14 bits, flip around in only 16 seconds. If correct timing information is wanted, the data flush procedure described in next section should be used. 2. Retransmission of text before a pause. Text does not flow continously, but only when a user enter text. Therefore, a recommended procedure could specify that for the redundancy scheme, it is advisable to send the ISO 10646 synch character FEFF after some inactivity timer to flush out redundant data - see section 3.4.=20 3. Recommended procedures section. In the draft that accompanies this mail, section 3 documents the recommended procedures for using the payload format. Does the group want it to be kept there or shall it be moved to the specification specifying use of this RTP Payload? ( The first user being H.323 Annex G)=20 Any other comments are welcome. Gunnar Hellstr=F6m ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom@omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06 From rem-conf Mon Jul 26 14:22:35 1999 From rem-conf-request@es.net Mon Jul 26 14:22:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118sAo-0007SF-00; Mon, 26 Jul 1999 14:20:38 -0700 Received: from (unknown) [208.152.243.19] by mail1.es.net with smtp (Exim 1.81 #2) id 118sAA-0007Jt-00; Mon, 26 Jul 1999 14:20:07 -0700 From: To: rem-conf@es.net Subject: advertisment *FREE LEATHERMAN TOOL Date: Mon, 26 Jul 1999 17:20:08 Message-Id: <256.294146.888791@unknown> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

Click here for more info http://www.safetythings.com/free.htm

wave.jpg (17981 bytes)

*Free Leatherman Wave Tool
You may reply to this offer by replying as you normally would to any email.  Then you will be able to fill in the form below and then press send "or" print it and fax it to 941-379-0921 "or" mail it to Interstate Products, Inc.  511 Interstate Court  Sarasota,  FL  34240 or go to http://www.safetythings.com/free.htm
Select the products of interest from the list below. By placing an "X" on the line before the product name.

           Ozone-Safe Computer Care                                                                        Aerosols To Clean, Anti-static, & Protect, all kinds of computer and other Hi-tech Equip.       

            Magic Jel  
Naturally Remove Graffiti, Paint, Inks, Tar, Grease, Heel Marks, Gum & More!!

         Traction-N-More
Chemical Resistant permanent Non Slip Coating.for ramps, plant floor, equipment& more!

          O.C.C.# 1267
Natural Orange degreasing & deodorizing Crystals.1Lb. Makes 40 Gals

            Safe-Seal
Chemical Resistant Water Based Sealers for concrete, Wood, & Metal. Protect against graffiti.

         Bac-Zyme
Eliminates clogged Drains and septic problems with Fast-Acting Bio-Enzymatic Action.

        “1” Step(The Rust Killer)
Eliminates Sandblasting, Grinding, and Wire Brushing.Stop rust Dead

         First Responder
Universal Spill Kits.

        Perma-Patch
Chemical Resistant Repairs Concrete, Metal & Asphalt

       Weed Killer
NEW! Safe, Fast & effective Vegetation control

 

Contact Information

*Name:                                                                   
*Title:                                                                     
*Company:                                                              
 
*Address:                                                               
*City:                                                                     
*State:                                                                  
*Zip:                                                                     



*Telephone:                                                           
 
*FAX:                                                                     
 
*E-mail:                                                                 

NOTE: ALL information MUST be entered into the fields above that have an * next to them to process your request.
* For new customers only. Not valid with any other offers or discounts. Void where prohibited by law. Subject to your company approval. Minimum $500.00 order to qualify. Substitute tool given for less than minimum order.

TO BE REMOVED FROM THIS LIST REPLY BACK WITH "REMOVE" IN THE SUBJECT LINE ONLY AND YOU WILL BE REMOVED AUTOMATICALLY AND PERMANENTLY FROM ANY FUTURE MAILING

From rem-conf Mon Jul 26 16:23:11 1999 From rem-conf-request@es.net Mon Jul 26 16:23:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 118u3o-0007eT-00; Mon, 26 Jul 1999 16:21:32 -0700 Received: from ats2-79.worldramp.net (fridaysStockPicks.com) [207.30.147.179] by mail1.es.net with smtp (Exim 1.81 #2) id 118u3k-0007dm-00; Mon, 26 Jul 1999 16:21:28 -0700 DATE: Mon, 26 Jul 1999 19:23:47 -0500 Message-ID: Subject: HOT STOCK PICK (adv.) From: ENCR@fridaysStockPicks.com To: $user@es.net X-Reply-To: ENCR@fridaysStockPicks.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Encounter.com, Inc. (OTC BB: ENCR)http://fridaysstockpicks.com/ The Stock is currently trading at only 32 cents! Upside potential is tremendous! Their current fiscal year earnings (May 31, 2000) are projected at 36 cents per share, justifying a future share price of $4.00 to $6.00 in the next twelve months. Company operates singlestogo.com interactive singles matching web site! Company is licensing it's name to and internet gaming casino and will participate in a revenue sharing of highly profitable online gambling business!!!!! ENCR is positioned to become the world's leading provider of online services to the huge global singles market, concentrating on 'voice personals', online dating, theater & event booking, Internet gaming, and the multi-billion travel industry. Read the analysis on this fascinating company at http://fridaysstockpicks.com/ From rem-conf Mon Jul 26 23:46:21 1999 From rem-conf-request@es.net Mon Jul 26 23:46:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1190wN-0005GW-00; Mon, 26 Jul 1999 23:42:19 -0700 Received: from (mail.crt.or.jp) [210.158.31.2] by mail1.es.net with smtp (Exim 1.81 #2) id 1190wL-0005GM-00; Mon, 26 Jul 1999 23:42:18 -0700 Received: from 33118.cmh.dialup.thenap.net (33118.cmh.dialup.thenap.net [209.190.33.118]) by mail.crt.or.jp (NTMail 3.03.0014/1.ajpm) with ESMTP id ra416277 for ; Tue, 27 Jul 1999 15:42:48 +0900 To: kk8gt@aol.com Bcc: 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, ftqg@bwlhjifupfzs.net From: Subject: Money Earning Power content-length: 538 Date: Tue, 27 Jul 1999 15:42:48 +0900 Message-Id: <06424829639252@crt.or.jp> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-212-465-3248 Call 24 hours a day, 7 days a week, including Sundays and holidays. From rem-conf Tue Jul 27 02:20:17 1999 From rem-conf-request@es.net Tue Jul 27 02:20:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1193N6-0007J9-00; Tue, 27 Jul 1999 02:18:04 -0700 Received: from mail6.svr.pol.co.uk [195.92.193.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 1193N4-0007Ix-00; Tue, 27 Jul 1999 02:18:02 -0700 Received: from modem-246.name69.dialup.pol.co.uk ([62.136.194.246] helo=bilbobaggins53.freeserve.co.uk) by mail6.svr.pol.co.uk with smtp (Exim 2.12 #1) id 1190EC-0000nu-00; Tue, 27 Jul 1999 06:56:40 +0100 From: sid@bilbobaggins53.freeserve.co.uk Reply-To:sid@bilbobaggins53.freeserve.co.uk To: sid@bilbobaggins53.freeserve.co.uk Subject: transmission error - please ignore Message-Id: Date: Tue, 27 Jul 1999 06:56:40 +0100 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ___________________________________________________________ transmission error - please ignore From rem-conf Wed Jul 28 12:14:01 1999 From rem-conf-request@es.net Wed Jul 28 12:14:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 119Ysx-0000V0-00; Wed, 28 Jul 1999 11:57:03 -0700 Received: from m1mail.mediaone.com [169.152.79.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 119Ysw-0000Uj-00; Wed, 28 Jul 1999 11:57:02 -0700 Received: from wsimc01.mediaone.com (wsimc01.mediaone.com [169.152.100.174]) by m1mail.mediaone.com (8.8.7/8.8.7) with SMTP id OAA07487 for ; Wed, 28 Jul 1999 14:57:02 -0400 (EDT) Received: from 169.152.100.30 by wsimc01.mediaone.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.6); Wed, 28 Jul 99 14:52:10 -0400 X-Server-Uuid: cda7734f-06b2-11d3-bc59-00805fbb2b22 Received: by exchimc01.mediaone.com with Internet Mail Service ( 5.5.2448.0) id ; Wed, 28 Jul 1999 14:55:14 -0400 Message-ID: From: "Cain, Michael E." To: "'rem-conf@es.net'" Subject: Load generator for RTP/RTCP/RTSP-based server Date: Wed, 28 Jul 1999 14:55:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 1B818ED01341165-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This may not be the appropriate forum to ask this question -- if so, I apologize in advance. I'm going to be testing an Apple streaming QuickTime server and want to be able to generate some amount of load on the box. Rather than trying to get enough PCs and/or Macs together, each running a QuickTime player, and attempting to script those players in some fashion, I would like to write a pseudo-client that asks for the stream, receives and simply discards the RTP packets, generates appropriate RTCP responses, etc. Since no actual decoding or display of the media would be done, even a low-end machine should be able to absorb several streams' worth of data. Because Apple has based their server on open RTP/RTCP/RTSP standards, writing such a pseudo-client should be straightforward. Before I do it all >from scratch, though, it seemed appropriate to ask if anyone has already done it or if some pieces at least are available (perhaps Columbia's RTP toolkit would be helpful?). Thanks in advance, Michael Cain MediaOne Labs mcain@mediaone.com From rem-conf Wed Jul 28 14:07:34 1999 From rem-conf-request@es.net Wed Jul 28 14:07:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 119anZ-000241-00; Wed, 28 Jul 1999 13:59:37 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 119anY-00023o-00; Wed, 28 Jul 1999 13:59:36 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 28 Jul 1999 15:59:10 UT Received: by notes4.nmss.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 852567BC.00732540 ; Wed, 28 Jul 1999 16:57:41 -0400 X-Lotus-FromDomain: NATURAL MICROSYSTEMS From: Bruce_Levens@nmss.com To: "Cain, Michael E." cc: rem-conf@es.net Message-ID: <852567BC.007323C0.00@notes4.nmss.com> Date: Wed, 28 Jul 1999 16:59:25 -0400 Subject: Re: Load generator for RTP/RTCP/RTSP-based server 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 you said "This may not be the appropriate forum to ask this question -- if so, I apologize in advance. I'm going to be testing an Apple streaming QuickTime server and want to be able to generate some amount of load on the box. Rather than trying to get enough PCs and/or Macs together, each running a QuickTime player, and attempting to script those players in some fashion, I would like to write a pseudo-client that asks for the stream, receives and simply discards the RTP packets, generates appropriate RTCP responses, etc. Since no actual decoding or display of the media would be done, even a low-end machine should be able to absorb several streams' worth of data. Because Apple has based their server on open RTP/RTCP/RTSP standards, writing such a pseudo-client should be straightforward. Before I do it all >from scratch, though, it seemed appropriate to ask if anyone has already done it or if some pieces at least are available (perhaps Columbia's RTP toolkit would be helpful?). Thanks in advance, Michael Cain MediaOne Labs mcain@mediaone.com " My attempt at an answer: I believe that the RTP tool kit might indeed be helpful. Our experiments indicate that: The rtptools on H.Schulzrinne's web site can run multiple copies on one pc. So, if you configure your server to pump rtp out to a set of port numbers, and configure the test pc to run rtpdump in a separate window for each of those port numbers, you will have a test. rtp does not directly request service, that is handled by other protocols so you must configure your server to spew out data on its own for this test. Hope this helps. Let us know. From rem-conf Thu Jul 29 07:07:40 1999 From rem-conf-request@es.net Thu Jul 29 07:07:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 119qke-0001WU-00; Thu, 29 Jul 1999 07:01:40 -0700 Received: from soleil.uvsq.fr [193.51.24.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 119qka-0001WH-00; Thu, 29 Jul 1999 07:01:36 -0700 Received: from lucifer.prism.uvsq.fr (lucifer.prism.uvsq.fr [193.51.25.7]) by soleil.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id QAA08986 ; Thu, 29 Jul 1999 16:01:24 +0200 (CEST) Received: from prism.uvsq.fr (berthier.prism.uvsq.fr [193.51.25.174]) by lucifer.prism.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id PAA07570 ; Thu, 29 Jul 1999 15:43:14 +0200 (MET DST) Message-ID: <37A05A14.B9323C31@prism.uvsq.fr> Date: Thu, 29 Jul 1999 15:41:40 +0200 From: Rebecca Morales Reply-To: Rebecca.Morales@prism.uvsq.fr Organization: PRiSM X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: NETWORKING 2000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id QAA08986 To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NETWORKING 2000 IFIP - TC6/ European Union Broadband Communications (BC), High Performance Networking (HPN), Performance of Communication Networks (PCN) Paris, France Cit=E9 des Sciences, La Villette May 14 =96 19, 2000 Main Sponsors IFIP TC6, European Union National Main Sponsor RNRT and SEE Supporters (pending) Alcatel, CISCO, Thomson-CSF Detexis, EDF, France Telecom Organizer University of Paris VI , University of Versailles, ENST General Chair Guy Pujolle - France Organization Committee Serge Fdida - France Jean-Alain Hernandez - France Eric Horlait - France Ren=E9 Joly - France Guy Pujolle - France Steering Committee Augusto Casaca - Portugal Andr=E9 Danthine - Belgium Olli Martikainen - Finland Harry Perros - USA Jan Slavik - Czech Republic Otto Spaniol - Germany Y. Takahashi - Japan S. Tohme - France General Program committee chair Harry Perros - USA Program committee chair for BB track Ulf Korner - Sweden Program committee chair for HPN track Serge Fdida - France Program committee chair for PCN track Ioannis Stavrakakis - USA Program committee members Augusto Albuquerque - EC Harmen van As - Austria Augusto Casaca - Portugal Paolo Castelli - Italy Imrich Chlamtac -USA Jean-Pierre Coudreuse - France Nelson L. S. Fonseca - Brazil Luigi Fratta - Italy Giorgio Gallassi - Italy Andre Girard - Canada Villy B. Iversen - Denmark Bijan Jabbari -USA Konosuke Kawashima - Japan Peter Key - USA Daniel Kofman - France Paul Kuehn - Germany Helmut Leopold - Austria John Luetchford - Canada Lorne Mason - Canada Serafim Nunes - Portugal Guido Petit - Belgium Sathya Rao - Switzerland Joao Rodrigues - Portugal Catherine Rosenberg - UK Tadao Saito - Japan Amardeo Sarnea - Germany Marion Schreinemachers - Netherl. Jan Slavik - Czech Republic Samir Tohme - France Danny Tsang - Hong Kong Finn Arve Aagesen - Norway Andres Albanese - USA Chase Bailey - USA Ermanno Berruto - Italy Andrew Campbell - USA Jon Crowcroft - UK Andre Danthine - Belgium Walid Dabbous - France Michel Diaz - France Sarolta Dibuz - Hungary Christophe Diot - USA Otto Duarte - Brazil Wolfgang Effelsberg - Germany Nicolas D. Georganas - Canada Enrico Gregori - Italy Roch Guerin - USA Christian Huitema =96 USA David Hutchinson -UK Marjory Johnson - USA Farouk Kamoun - Tunisia Koos Koen - RSA Jacques Labetoulle - France Jean-Yves Le Boudec - Switzerl. Guy Leduc - Belgium Olli Martikainen - Finland Steve Pink - Sweden Nina Taft Plotkin - USA Radu Popescu-Zeletin - Germany Luigi Rizzo - Italy Aruna Seneviratne -Australia Otto Spaniol - Germany Ralf Steinmetz - Germany Chris Blondia - Belgium Miklos Boda - Hungary Herwig Bruneel - Belgium Olga Casals - Spain Prosper Chemouil - France Giovanni Colombo - Italy Tony Ephremides - USA Andras Farago - USA Erol Gelenbe - USA Mario Gerla - USA Fabrice Guillemin - France Gerard Hebuterne - France Demetres Kouvatsos - UK Jim Kurose - USA Karl Lindberger -Sweden Jon Mark - Canada Marco Marsan - Italy Lazaros Merakos - Greece Jouni Mikkonen - Finland Debasis Mitra - USA Naotama Morita - Japan Arne Nilsson - USA Raif Onvural - USA Ramon Puigjaner - Spain James Roberts - France Yutaka Takahashi - Japan Ahmed Tantawy - USA Phouk Tran-Gia - Germany Jorma Virtamo - Finland Adam Wolisz - Germany Tutorials Committee Chair Eric Horlait -France Publicity Committee Chair Raouf Boutaba - Canada Networking 2000 Conference Networking 2000 Conference will provide an international technical forum for experts from industry and academia to exchange ideas and present results of ongoing research in networking. It is a joint conference of the following three series of conferences : Broadband Communications (BB) High Performance Networking (HPN) Performance of Communication Networks (PCN). Topics Switching Design Routing Design Switching and Routing Internet/Intranet LAN, WAN Global Network Interconnection High Performance Networking and Protocols Service Provider Interworking Control and Optimization of Communication Systems Quality of Service Multicast Active Networks Terrestrial Radio Systems Wireless and Mobile Communications Satellite and Space Communications Low Earth Orbit Satellite Communication Systems Optical Communications Access Networks Video Coding and Distribution Object Orientation Network Operations and Management Signalling Tariffing Network Reliability, Availability and Survivability Internet Services and Applications Network Design Problems in Gigabit Terabit Networks Performance Evaluation of Telecommunication Systems Traffic Models and Measurements Traffic and Congestion Control KEY DATES * September 1st,, 1999 Deadline for submitting Short Course Proposals * September 15, 1999 Deadline for submitting papers * January 15, 2000 Notification of acceptance of papers * February 15, 2000 Papers received in camera ready form * May 14-15, 2000 Tutorials * May 16-19, 2000 Networking 2000 Conference SUBMISSION OF PAPERS Paper can be submitted by mail or email. Monitor the web site for details: www.noc.uoa.gr/net2000 Papers are invited on the conference theme and related topics. Authors must state that their paper have neither been published before nor currently being submitted elsewhere. Full papers should be no longer than 15 pages, including tables, diagrams and pictures. The font size must be 12 points or larger. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the lead author's postal address, telephone number, fax number and e-mail. Accepted papers will be included in the conference proceedings and will be distributed to the attendees at the conference. The language of the conference is English and papers must be in this language. SHORT COURSES We solicit proposals for half/full day short courses outlining the subject area and a short biography of the organizer(s). Short courses can be submitted by mail or email to Prof. E. Horlait LIP6, 4 place Jussieu 75252 Paris Cedex 05 * by email to Eric.Horlait@lip6.fr INFORMATION www.noc.uoa.gr/net2000 www.prism.uvsq.fr/~net2000 Mini conferences and workshops will take place during the conference. The following proposals are being considered: (specific call for papers will be provided) MWCN - Mobile and Wireless Communication Networks (Chairman Guy Omidyar =96 USA) gomidyar@csc.com IATE - Intelligent agents for telecommunication environments (Chairpersons Dominique Gaiti - France and Olli Martikainen - Finland) Dominique.Ga=EFti@lip6.fr, Olli.Martikainen@hut.fi Quality of Service and Multimedia Applications (Chairman Eric Horlait - France) Eric.Horlait@lip6.fr Constellation of satellites (Chairwomen C. Rosenberg - Canada) C.Rosenberg@nortel.co.uk Resource allocation for mobile networks (Chairman Sami Tabbane - Tunisia) sami.tabbane@supcom.rnu.tn Internet and the Web (Chairman Keith Ross- France) ross@eurecom.fr Performance of Adaptive Intelligent Networks (Chairman E. Gelenbe - USA erol@cs.ucf.edu Programmable Networks and Active Networks (Chairman R. Boutaba =96 Canada= , Andrew Campbell - USA, Rolf Stadler =96 USA and Ian Wakeman - USA) rboutaba@jupiter.nal.utoronto.ca campbell@comet.columbia.edu Multimedia Management (Chairman Jose Neuman de Souza =96 Brazil) neuman@ufc.br From rem-conf Thu Jul 29 09:34:06 1999 From rem-conf-request@es.net Thu Jul 29 09:34:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 119t0w-0003Qf-00; Thu, 29 Jul 1999 09:26:38 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 119t0v-0003Q9-00; Thu, 29 Jul 1999 09:26:37 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25187; Thu, 29 Jul 1999 12:25:18 -0400 (EDT) Message-Id: <199907291625.MAA25187@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: An RTP Payload Format for Generic Forward Error Correction to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 29 Jul 1999 12:25:18 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider An RTP Payload Format for Generic Forward Error Correction as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-fec-07.txt From rem-conf Thu Jul 29 10:02:45 1999 From rem-conf-request@es.net Thu Jul 29 10:02:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 119tXp-0004YW-00; Thu, 29 Jul 1999 10:00:37 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 119tXm-0004Xu-00; Thu, 29 Jul 1999 10:00:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25867; Thu, 29 Jul 1999 12:59:15 -0400 (EDT) Message-Id: <199907291659.MAA25867@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: Guidelines for Writers of RTP Payload Format Specifications to BCP Reply-to: iesg@ietf.org Date: Thu, 29 Jul 1999 12:59:15 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider Guidelines for Writers of RTP Payload Format Specifications as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-format-guidelines-03.txt From rem-conf Thu Jul 29 22:33:23 1999 From rem-conf-request@es.net Thu Jul 29 22:33:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11A59C-0003Mb-00; Thu, 29 Jul 1999 22:23:58 -0700 Received: from relay2.smtp.psi.net [38.8.188.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11A599-0003M9-00; Thu, 29 Jul 1999 22:23:55 -0700 Received: from [38.209.139.44] (helo=smtp.rjnetwork.net) by relay2.smtp.psi.net with esmtp (Exim 1.90 #1) id 11A4xN-0006U8-00; Fri, 30 Jul 1999 01:11:46 -0400 Received: from ip107.oshawa2.dialup.canada.psi.net by smtp.rjnetwork.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id P5KWQDNX; Fri, 30 Jul 1999 01:13:50 -0400 Received: from login_0101.job4u.com (mail.job4u.com[204.135.201.203]) by job4u.com (8.8.5/8.7.3) with SMTP id XAA03213 for CybrMrkting99@job4u.com; Fri, 30 July 1999 01:09:30 -0700 (EDT) To: you@yourdomain.net Bcc: remcokor@euronet.nl, remcon@arctic.net, rem-conf@es.net, rem-conf-request@es.net, remcozmo@lava.net, remcsteubn@locl.net, remdaze@ix.netcom.com, remdog@mailexcite.com, remech@cport.com, remechanic@lewin.com, remedia@rempub.com, remedios@mailcity.com, remedios@mailexcite.com, remee_37@eudoramail.com, remel@mlink.net, remember_eros@mailcity.com, remember_me@eudoramail.com, remen.bbs@bbs.yuntech.edu.tw, remen@mailexcite.com, remen@ts.umu.se, remendab@sask.aecl.ca, remenecker@cadmus.com, rementz@aol.com, remer@ix.netcom.com, remer@mailexcite.com, remerich@kodak.com, remerick@erols.com, remerick@gate.net, remerson@americasemployers.com, remerson007@mailexcite.com, remertins@aol.com, remery@gnn.com, remery@ix.netcom.com, remery@mailgw.sanders.lockheed.com, remery@microserve.net, remery@mindspring.com, remery3@ccnmail.com, remess@ezin.net, remes-world@myworldmail.com, remete@pobox.sk, remey_black@mailexcite.com, remfan@mailexcite.com, remgt@aol.com, remi.castonguay@eudoramail.com, remi.fouchault@geo.mts.dec.com, remic@mailexcite.com, remichal@concentric.net, remie@mailcity.com, remiel@apex.net, remiel@kih.net, remigius.muforo@telops.gte.com, remii@msn.com, remijn@research.ptt.nl, remiller@mail.cvn.net, remiller60@aol.com, remills@mailcity.com, remimind@netnoir.net, reminf@mailcity.com, reming@gisco.net, reming@mailexcite.com, remingpoet@mailexcite.com, remington@careerbuildermail.com, remington_chief@hotmail.com, remington5@angelfire.com, remi-shrieves@mailexcite.com, remisrage@thedoghousemail.com, remital-@msn.com, remius@eden.com, remixed@mailcity.com, remixrajah@geocities.com, re-mj.carter@eudoramail.com, remje@midwest.net, remko.trentelman@mailcity.com, remko.trentlman@mailcity.com, remmah@mailcity.com, remmer@mho.net, remmer-goths-unite@mailexcite.com, remmond@mailcity.com, remmons@holonet.net, remmons@iat.holonet.net, remmons@interramp.com, remmons@mindspring.com, remmy22ke@hm.com, remnant7@mailexcite.com, remnet@geocities.com, remnight@aol.com, remno@mailcity.com, remo.steiner@mailexcite.com, remo@remo.vol.at, remo@technologist.com, remo_steiner@mailexcite.com, remo2@gurlmail.com, remodel4u2@aol.com, remonique@gurlmail.com, remopelham@mailexcite.com, remoschenker@access.ch, remoslair@mailexcite.com, remote.control@mailexcite.com, remote.s@mailexcite.com, remote@unknown.address.com From: Subject: I thought you might be interested Reply-To: CybrMrkting99@job4u.com X-PMFLAGS: 20720340.50 X-UIDL: 20720340_201230.501 Comments: Authenticated Sender is Message-Id: <13888471_91174256> content-length: 11370 Date: Fri, 30 Jul 1999 01:11:46 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Would you like to earn an extra $700 a week... $2,800 a month just by mailing our business circulars from your home? You can make this kind of money without even giving up your present job. We have created the most risk-free way to do this, and all you have to do is mail out our business circulars and get paid for your work. This exciting new home employment opportunity is so effective - yet quick and easy that your success is absolutely GUARANTEED! We Publish, sell and distribute information booklets, guides, reports, manuals and computer software all across Canada and the United States. Since we do the majority of our business by mail, we in turn send out thousands of our sales circulars each week.Our company circulars are the sales letters/product offers that are sent out in response to customer inquiries. When you mail our circulars, you'll be greatly helping us by getting our offers out to more customers. You'll be taking part in the most remarkable opportunity available. Our system of mailing circulars is very easy to operate. All you will be doing is taking copies of the standard, letter-sized (8 1/2"x11") circulars that we provide you with and fold them to fit into the envelopes you will receive. After you have folded and inserted the circulars into the envelopes, you just have to seal the envelopes and deposit them in your mail. You will not have to spend any time addressing envelopes or pay any postage costs to mail out our circulars, because all envelopes will arrive pre-addressed and with postage already in place. It should only take you a few hours a week. It's as simple as that! Circular mailing is easy and pleasant work that is very profitable! We have developed a legitimate and realistic money-making business system that is practical and uncomplicated. Simple enough that anyone can take part in it regardless of education, age, physical ability or disability. Our program is easy to understand, with step-by-step instructions that are sure to get you started quickly and with confidence. This is a highly fool-proof, tried, tested and proven method that you can run from the comfort and privacy of your own home - without any personal contact with anyone at any time. You can take part in our program any hour of the day... any day of the week. We do not require that you have any related experience to take part in our program. All that we want are serious minded people who can read and write simple English, and who are able to put in a few extra hours each week towards earning a great income. Although you don't need any experiance, it is important that you be ambitious and motivated because you will be working on your own - without supervision. It will be your responsibility to get your work done. You do not have to meet a certain quota each week, and we do not impose any restrictions on the amount of work that you choose to do. Our Circular Mailing Program allows you the complete flexibility to organize and choose your own work load and work schedule. You can work part-time or full-time, and you are always free to take a break >from your work - planning your own time off. Furthermore, you may quit the program at any time, since you will be an independent mailer and have no obligation to our company what-so-ever. Home employment is wonderful. It can provide you with a great sense of accomplishment, pride and freedom - but you must remember to treat your work seriously and with respect. What you get out of our program is exactly what you put into it. Earn as much or as little as you like - it's all up to you. You can start the same day you receive our supplies and information package, and begin receiving money within 2 weeks time, and every week from then on for as long as you desire to participate in our program. Thousands of people all over Canada and the United States are making excellent money mailing circulars from their homes. You can join our successful network, of circular mailers and get your share of this money too! It makes no difference if you live in a small town or a large city. As long as you can get to a mailbox to mail the circulars, you can participate in this great home income opportunity. Anyone with a little common sense and a desire to succeed can take part in our program and earn excellent income for themselves in a very short period of time. One of the nicest things about our circular mailing program is how quickly it works. You can start the same day you receive our supplies and information package, and begin receiving money within 2 weeks time, and then for as long as you decide to participate in our program. Imagine never having to leave your home while making more money in a few hours than a lot of people earn after a full week's work! In fact, you can be making great money in as little as 10 hours a week! And remember, you don't need any special education of experience. This program can work for anyone - regardless of background, age or location. Just mail the circulars and spend the rest of the day enjoying yourself. Imagine being able to work in the comfort of your own home, at your own pace and in your leisure with a simple system to earn $700.00 a week working only a few hours a week... it's a great place to start. You really don't have to work hard to get ahead in life - you just have to work SMART. By following our easy steps, you will connect with making $700 a week - every week. We'll even show you how you can increase an income of $700.00 a week into as much as $1,000.00 a week or more with ease. It's very simple and it's very realistic. With the basic details we've outlined, you'll easily see the incredible income potential right away. This program is so well thought out and developed that YOU CANNOT FAIL to make great money! You'll be able to set up your operation so that you can have all the free time in the world to do with as you please, without anyone looking over your shoulder. If you choose , you'll only have to work at your affairs for about an hour or two a day, and these will turn out to be extremely easy, fun hours, with no boss snooping around and no one to answer to. Believe this, after you spend the small amount of up-front time getting organized, setting up your own system, you'll soon realize that nothing could be easier, or offer you more privacy and personal freedom! Unlike others who you might see promoting the same old useless stuff - year in and year out, we have developed a unique approach which has never been released to the public by anyone else. Cybermarketing is the only source for this valuable program. So please don't confuse it with any of the other get-rich-quick schemes or ads you might see. If you're searching for an honest to goodness, legitimate, legal and spare time work at home opportunity, then your search has finally ended. This is a 100% proven Money-Making Program! PROVEN to make good money for everyone who uses it! If you're like most folks, you're going to absolutely love our Circular Mailing Program because it's the most legitimate, "on-the-level", easy to start, profitable work-from-home opportunity ever created! We say this honestly because IT REALLY WORKS! You won't find any gimmicks, surprises or silly schemes. Only valuable information that you'll need so you can quickly learn exactly WHAT TO DO and HOW TO DO IT; and our proven , professionally written circulars. Our Circular Mailing Program can bring you all the money you need. When you receive our start up package in the mail, you will get all the supplies you need to get started right away including your Personal Information Kit (your complete instructional handbook) and our business circulars. You will receive everything as promised. And don't forget you will not have to pay postage costs to mail our circulars because envelopes will arrive completely addressed and with postage already in place. Just mail out the circulars and receive pay cheques that are yours to spend any way you wish! You can take part in our program for as long as you want... earn $700 a week for the rest of your life. We can only accommodate a limited number of people in our unique program. So if you are interested, please do not delay. Send in your acceptance form as soon as you can. You have our guarantee that this program can change your life practically overnight. We know of no other home employment opportunity with the potential to make the great amounts of money that this program does. This is a complete home-based opportunity that REALLY WORKS. Our only requirement is a one time only, fully refundable payment of only $27.00 . This payment covers the cost of your supplies and the processing of your membership. This is a one-time payment, you will not have to pay us any other costs to get additional materials. And because we're so sure that we have the right home employment opportunity for you, we are backing up our promises with our exclusive guarantee... $33,600.00 Guarantee You can easily earn $33,600.00 in the next year with our program. In fact, we are so confident that you can make over $700 a week mailing out our circulars that we are going to offer you the most air-tight guarantee in existence. As soon as you receive our start up package in the mail, send out our circulars right away. If you don't start earning a minimum of $700 a week within 30 days, simply return our materials for a COMPLETE REFUND. You either make $700 a week or your money back! Join our network of circular mailers today. We truly want to help you get started as quickly and as easily as possible. This program is designed for people who are serious about earning a substantial income. We are convinced that you will be absolutely thrilled when you see just how much money you can make with our program. We've got your start-up kit all packaged up and ready to go. Just give us the word and we'll have it out the door and on its way to you. If you follow our instructions, you will be well on your way to earning $700 per week by mailing circulars from home. Just print and fill out the Exclusive Membership Form at the bottom of this page and mail it in with your remittance and your order will be rushed to you right away by first class mail. We hope that you allow us the honor of being the ones who helped you to achieve long-term financial success and personal freedom. Most sincerely, The Staff at CyberMarketing ------------------------------------------------------------------ HOME MAILERS PROGRAM ORDER-FORM ------------------------------------------------------------------ Please RUSH me my Package of the HOME MAILERS PROGRAM and the HOME BUSINESS DIRECTORY right away!!! Send $27.00 in U.S Funds. (Includes Postage & Handling) NAME:______________________________________ MAIL TO: CYBERMARKETING P.O.Box #563 ADDRESS:___________________________________ Lindsay, Ontario, Canada, K9V 4S5 CITY:_________________STATE/PROVINCE:______ ZIP/POSTAL CODE:___________________________ E-MAIL ADDRESS:____________________________ (Orders payable by cheque please allow 4-6 weeks for delivery.) 07/30/99 -------------------------------------------------------------------- From rem-conf Fri Jul 30 05:41:12 1999 From rem-conf-request@es.net Fri Jul 30 05:41:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ABvE-0000ER-00; Fri, 30 Jul 1999 05:38:00 -0700 Received: from relay2.smtp.psi.net [38.8.188.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ABvA-0000Dz-00; Fri, 30 Jul 1999 05:37:56 -0700 Received: from [38.209.139.44] (helo=smtp.rjnetwork.net) by relay2.smtp.psi.net with esmtp (Exim 1.90 #1) id 11ABuB-0003YO-00; Fri, 30 Jul 1999 08:36:57 -0400 Received: from ip170.oshawa2.dialup.canada.psi.net by smtp.rjnetwork.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id P5KWQFLY; Fri, 30 Jul 1999 08:38:56 -0400 Received: from login_0101.job4u.com (mail.job4u.com[204.135.201.203]) by job4u.com (8.8.5/8.7.3) with SMTP id XAA03977 for CybrMrkting99@job4u.com; Fri, 30 July 1999 08:34:37 -0700 (EDT) To: you@yourdomain.net Bcc: renee.r@mailcity.com, renee.cohn@astd.noli.com, renee.cockrell@mailexcite.com, renee.chavis@snet.net, rened@evansville.net, renecuellar@mailcity.com, renecose@mail.imagine.com.ar, renebarba@eudoramail.com, reneb@n2mail.com, rene1@lucent.com, rene°@globalserve.net, rene@propane.ca, rene@ntcnet.com, rene@netnoir.net, rene@inforamp.net, rene@globalserve.net, rene@creativeprofile-netcards.co.nz, rene.hamberg@icu.nl, rene.gagnon@fmc.ulaval.ca, rene.brazeau@eudoramail.com, rene.beddok@hol.fr, rene.becker@eudoramail.com, rene.barthelemy@cern.ch, rendler@access.digex.net, rendlai@geocities.com, rendengail@eudoramail.com, rendam@telkom.co.za, renda@starting-point.com, renbau@televar.com, renatosenna@mailcity.com, renato@passosnet.com.br, renato@dgx.wimsey.com, renate.teuschler@ac.com, renate.sonnenberg@t-online.de, renata.bassi@mailexcite.com, renascaince@angelfire.com, renasat@mailcity.com, renapro@intex.net, rena-m@usa.net, renaissance-woman@mailcity.com, renaisncmn@mailcity.com, renae@ionet.net, rena@foxcomm.net, ren3gade@mailexcite.com, ren@thecia.net, ren@ntl.com, ren@england.com, ren@carlsbadnm.com, remy92@remycapital.com, remy@scinfo.u-nancy.fr, remus3@aol.com, removals@eudoramail.com, remote.control@mailexcite.com, remondo@geocities.com, remodel@qni.com, remo@sunworks.com, remo@mailexcite.com, remo@lunet.it, remnant005@mailexcite.com, remmaps@mailexcite.com, remman@thedoghousemail.com, remlover@geocities.com, remley@angelfire.com, remington_chief@hotmail.com, remington@chickmail.com, remind_me@mailexcite.com, remil@mailcity.com, remicote@odyssee.net, remi_gagnon@mailcity.com, remi@gis.net, remi@gazeta.pl, remi.berland@enst-bretagne.fr, remer@mailexcite.com, remek@mailcity.com, remdrec@mailexcite.com, remdrec@mailcity.com, rem-conf@es.net, remccoll@julian.uwo.ca, rembrandt.colgan@mailexcite.com, rembol@indigo.arch.pw.edu.pl, rembol@arch.pw.edu.pl, remaxkb@trib.com, remaxdaley@aol.com, remax@tiac.net, remarket@interpath.com, remark@unicomp.net, remarck@aol.com, remarc-able@mailexcite.com, remarc@mailcity.com, remapi@mbox.vol.it, reman@smart.net, remailer@replay.com, rem@btr.com, rem.desc@mailexcite.com, relyon@accnorwalk.com, relucu@mailexcite.com, reloader@mailcity.com, rellinger@mailexcite.com, --rellil--@mailcity.com, rellceh_j14@hotmail.com From: Subject: I thought you might be interested Reply-To: CybrMrkting99@job4u.com X-PMFLAGS: 20720340.50 X-UIDL: 20720340_201230.501 Comments: Authenticated Sender is Message-Id: <87119827_44197276> content-length: 11370 Date: Fri, 30 Jul 1999 08:36:57 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Would you like to earn an extra $700 a week... $2,800 a month just by mailing our business circulars from your home? You can make this kind of money without even giving up your present job. We have created the most risk-free way to do this, and all you have to do is mail out our business circulars and get paid for your work. This exciting new home employment opportunity is so effective - yet quick and easy that your success is absolutely GUARANTEED! We Publish, sell and distribute information booklets, guides, reports, manuals and computer software all across Canada and the United States. Since we do the majority of our business by mail, we in turn send out thousands of our sales circulars each week.Our company circulars are the sales letters/product offers that are sent out in response to customer inquiries. When you mail our circulars, you'll be greatly helping us by getting our offers out to more customers. You'll be taking part in the most remarkable opportunity available. Our system of mailing circulars is very easy to operate. All you will be doing is taking copies of the standard, letter-sized (8 1/2"x11") circulars that we provide you with and fold them to fit into the envelopes you will receive. After you have folded and inserted the circulars into the envelopes, you just have to seal the envelopes and deposit them in your mail. You will not have to spend any time addressing envelopes or pay any postage costs to mail out our circulars, because all envelopes will arrive pre-addressed and with postage already in place. It should only take you a few hours a week. It's as simple as that! Circular mailing is easy and pleasant work that is very profitable! We have developed a legitimate and realistic money-making business system that is practical and uncomplicated. Simple enough that anyone can take part in it regardless of education, age, physical ability or disability. Our program is easy to understand, with step-by-step instructions that are sure to get you started quickly and with confidence. This is a highly fool-proof, tried, tested and proven method that you can run from the comfort and privacy of your own home - without any personal contact with anyone at any time. You can take part in our program any hour of the day... any day of the week. We do not require that you have any related experience to take part in our program. All that we want are serious minded people who can read and write simple English, and who are able to put in a few extra hours each week towards earning a great income. Although you don't need any experiance, it is important that you be ambitious and motivated because you will be working on your own - without supervision. It will be your responsibility to get your work done. You do not have to meet a certain quota each week, and we do not impose any restrictions on the amount of work that you choose to do. Our Circular Mailing Program allows you the complete flexibility to organize and choose your own work load and work schedule. You can work part-time or full-time, and you are always free to take a break >from your work - planning your own time off. Furthermore, you may quit the program at any time, since you will be an independent mailer and have no obligation to our company what-so-ever. Home employment is wonderful. It can provide you with a great sense of accomplishment, pride and freedom - but you must remember to treat your work seriously and with respect. What you get out of our program is exactly what you put into it. Earn as much or as little as you like - it's all up to you. You can start the same day you receive our supplies and information package, and begin receiving money within 2 weeks time, and every week from then on for as long as you desire to participate in our program. Thousands of people all over Canada and the United States are making excellent money mailing circulars from their homes. You can join our successful network, of circular mailers and get your share of this money too! It makes no difference if you live in a small town or a large city. As long as you can get to a mailbox to mail the circulars, you can participate in this great home income opportunity. Anyone with a little common sense and a desire to succeed can take part in our program and earn excellent income for themselves in a very short period of time. One of the nicest things about our circular mailing program is how quickly it works. You can start the same day you receive our supplies and information package, and begin receiving money within 2 weeks time, and then for as long as you decide to participate in our program. Imagine never having to leave your home while making more money in a few hours than a lot of people earn after a full week's work! In fact, you can be making great money in as little as 10 hours a week! And remember, you don't need any special education of experience. This program can work for anyone - regardless of background, age or location. Just mail the circulars and spend the rest of the day enjoying yourself. Imagine being able to work in the comfort of your own home, at your own pace and in your leisure with a simple system to earn $700.00 a week working only a few hours a week... it's a great place to start. You really don't have to work hard to get ahead in life - you just have to work SMART. By following our easy steps, you will connect with making $700 a week - every week. We'll even show you how you can increase an income of $700.00 a week into as much as $1,000.00 a week or more with ease. It's very simple and it's very realistic. With the basic details we've outlined, you'll easily see the incredible income potential right away. This program is so well thought out and developed that YOU CANNOT FAIL to make great money! You'll be able to set up your operation so that you can have all the free time in the world to do with as you please, without anyone looking over your shoulder. If you choose , you'll only have to work at your affairs for about an hour or two a day, and these will turn out to be extremely easy, fun hours, with no boss snooping around and no one to answer to. Believe this, after you spend the small amount of up-front time getting organized, setting up your own system, you'll soon realize that nothing could be easier, or offer you more privacy and personal freedom! Unlike others who you might see promoting the same old useless stuff - year in and year out, we have developed a unique approach which has never been released to the public by anyone else. Cybermarketing is the only source for this valuable program. So please don't confuse it with any of the other get-rich-quick schemes or ads you might see. If you're searching for an honest to goodness, legitimate, legal and spare time work at home opportunity, then your search has finally ended. This is a 100% proven Money-Making Program! PROVEN to make good money for everyone who uses it! If you're like most folks, you're going to absolutely love our Circular Mailing Program because it's the most legitimate, "on-the-level", easy to start, profitable work-from-home opportunity ever created! We say this honestly because IT REALLY WORKS! You won't find any gimmicks, surprises or silly schemes. Only valuable information that you'll need so you can quickly learn exactly WHAT TO DO and HOW TO DO IT; and our proven , professionally written circulars. Our Circular Mailing Program can bring you all the money you need. When you receive our start up package in the mail, you will get all the supplies you need to get started right away including your Personal Information Kit (your complete instructional handbook) and our business circulars. You will receive everything as promised. And don't forget you will not have to pay postage costs to mail our circulars because envelopes will arrive completely addressed and with postage already in place. Just mail out the circulars and receive pay cheques that are yours to spend any way you wish! You can take part in our program for as long as you want... earn $700 a week for the rest of your life. We can only accommodate a limited number of people in our unique program. So if you are interested, please do not delay. Send in your acceptance form as soon as you can. You have our guarantee that this program can change your life practically overnight. We know of no other home employment opportunity with the potential to make the great amounts of money that this program does. This is a complete home-based opportunity that REALLY WORKS. Our only requirement is a one time only, fully refundable payment of only $27.00 . This payment covers the cost of your supplies and the processing of your membership. This is a one-time payment, you will not have to pay us any other costs to get additional materials. And because we're so sure that we have the right home employment opportunity for you, we are backing up our promises with our exclusive guarantee... $33,600.00 Guarantee You can easily earn $33,600.00 in the next year with our program. In fact, we are so confident that you can make over $700 a week mailing out our circulars that we are going to offer you the most air-tight guarantee in existence. As soon as you receive our start up package in the mail, send out our circulars right away. If you don't start earning a minimum of $700 a week within 30 days, simply return our materials for a COMPLETE REFUND. You either make $700 a week or your money back! Join our network of circular mailers today. We truly want to help you get started as quickly and as easily as possible. This program is designed for people who are serious about earning a substantial income. We are convinced that you will be absolutely thrilled when you see just how much money you can make with our program. We've got your start-up kit all packaged up and ready to go. Just give us the word and we'll have it out the door and on its way to you. If you follow our instructions, you will be well on your way to earning $700 per week by mailing circulars from home. Just print and fill out the Exclusive Membership Form at the bottom of this page and mail it in with your remittance and your order will be rushed to you right away by first class mail. We hope that you allow us the honor of being the ones who helped you to achieve long-term financial success and personal freedom. Most sincerely, The Staff at CyberMarketing ------------------------------------------------------------------ HOME MAILERS PROGRAM ORDER-FORM ------------------------------------------------------------------ Please RUSH me my Package of the HOME MAILERS PROGRAM and the HOME BUSINESS DIRECTORY right away!!! Send $27.00 in U.S Funds. (Includes Postage & Handling) NAME:______________________________________ MAIL TO: CYBERMARKETING P.O.Box #563 ADDRESS:___________________________________ Lindsay, Ontario, Canada, K9V 4S5 CITY:_________________STATE/PROVINCE:______ ZIP/POSTAL CODE:___________________________ E-MAIL ADDRESS:____________________________ (Orders payable by cheque please allow 4-6 weeks for delivery.) 07/30/99 -------------------------------------------------------------------- From rem-conf Sat Jul 31 18:32:16 1999 From rem-conf-request@es.net Sat Jul 31 18:32:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11AkBZ-0007j7-00; Sat, 31 Jul 1999 18:13:09 -0700 Received: from mail.sginet.com [207.179.16.5] by mail1.es.net with smtp (Exim 1.81 #2) id 11AkBU-0007i7-00; Sat, 31 Jul 1999 18:13:05 -0700 Received: from gohip.com [206.40.238.61] by mail.sginet.com (SMTPD32-4.06) id AD2F1BE0090; Sat, 31 Jul 1999 19:04:47 MDT Date: 7/26/99 3:35:10 PM Pacific Daylight Time From: spy@gohip.com Reply-To:spy@gohip.com To: spy@gohip.com Subject: Don't Get Ripped Off!!! There's only ONE Internet Spy and You Software... Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Don't mistake this software for other $15 and $22 programs being advertised on the net... you get what you pay for, and there's only ONE "Internet Spy & You" program!!! Please see disclaimers at the end of this mailing. <><><><><><><><><><><><><><><><><><><><><> Welcome to another... ListBott "Opt-In" broadcast. <><><><><><><><><><><><><><><><><><><><><> Dear Subscriber, WE ARE BEING FORCED TO DISCONTINUE SELLING THIS INFORMATION. Don't miss this very limited time opportunity to get the software that will allow you to become the ultimate "Super Snoop" on anyone !!! Get The SOFTWARE They Want BANNED In All COUNTRIES!!! "THE INTERNET SPY AND YOU" SHOWS YOU HOW TO GET THE FACTS ON ANYONE!!! You now have a few days left to get the software they want banned in every country !!! Why? Because these secrets were never intended to reach your eyes... Plus, this is a VERY LIMITED TIME OFFER !!! Get the facts on anyone using the Internet! Locate Missing Persons, find Lost Relatives, obtain Addresses and Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public Record databases. Find out SECRETS about your relatives, friends, enemies, and everyone else! -- even your spouse with the new, INTERNET SPY AND YOU!!! It's absolutely astounding! Here's what you can learn: License plate number! Get anyone's name and address with just a license plate number! (Find that girl you met in traffic!) Driving record! Get anyone's driving record Social security number! Trace anyone by social security number! Address! Get anyone's address with just a name! Unlisted phone numbers! Get anyone's phone number with just a name - even unlisted numbers! Locate! Long lost friends, relatives, a past lover who broke your heart! E-mail! Send anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private investigators use (all on the Internet) secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! (Dig up old skeletons) Criminal search-background check! Find out about your daughters boyfriend! (or her husband) Find out! If you are being investigated! Neighbors! Learn all about your mysterious neighbors! Find out what they have to hide! People you work with! Be astonished by what you'll learn about people you work with! Education verification! Did he really graduate college? Find out! Internet Spy and You Software will help you discover ANYTHING about anyone, with clickable hyperlinks, no typing in Internet addresses! Just insert the floppy disk and Go! You will be shocked and amazed by the secrets that can be discovered about absolutely everyone! Find out the secrets they don't want you to know! About others, about yourself! It's INCREDIBLE what you can find out using the Internet Spy and You and the Internet! You'll be riveted to your computer screen! Get the software they're trying to ban! ACT NOW, Before it's too late! LIMITED TIME OFFER -- THIS SPECIAL SOFTWARE OFFER EXPIRES IN JUST A FEW DAYS!!! ORDER TODAY!!! Only $45.95 U.S. (Postage Paid) Only $39.95 U.S. (If paying with Cash or Money Order.) We will RUSH YOU our Internet Spy and You software so you can begin discovering all the secrets you ever wanted to know! You can know EVERYTHING about ANYONE with our Internet Spy and You Software. Works with all browsers and all versions of AOL! ORDER TODAY !!! Send Only $45.95 U.S. (Postage Paid) OR, Only $39.95 U.S. (If paying with Cash or Money Order.) Sorry, NO PERSONAL OR BUSINESS CHECKS will be accepted. (ORDERS OUTSIDE THE USA, ADD $25.00) (ALL SOFTWARE PACKAGES SHIPPED WITHIN 7 DAYS) DON'T WAIT TO GET STARTED... here's what to do: STEP 1 - Compose a new message using the order form text below STEP 2 - Type or print your order information into the order form section STEP 3 - Print your completed order, then mail to the address below >>> Order Toll-Free <<< OPTIONAL, you may choose to place your order on our secure voicemail system by calling 1-800-242-0363 Ext 2301 >>> Order By Mail <<< (Must be called-in or postmarked "on" or "before" 8/6/99) Send to: KMM P.O. Box 910652 St. George, UT 84791 USA >>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<< We have been forced to limit the distribution of this resource. Orders received or postmarked AFTER 8/6/99, will be returned or deleted. Sorry, there will be NO exceptions!!! >>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<< >>> Mail-in Order Form <<< Auth: 4586 Name: Address: City: State: Zip: Method of payment: [ ] Visa [ ] MasterCard [ ] American Express Credit Card#: Exp Date: YOUR SIGNATURE HERE:_______________________________ We cannot process your credit card payment without your signature! [ ] Credit Card Orders $45.95!!! [ ] Money Order mail in orders -- only $39.95!!! [ ] Cash mail in orders -- only $39.95!!! WE DO NOT ACCEPT PERSONAL CHECKS!!! "Products & Services For Doing Business On The Net" (SORRY, NO MAC VERSION AVAILABLE AT THIS TIME.) NOTE: THIS PROGRAM WILL NOT WORK ON WINDOWS 3.11 AND OLDER NOTE: Because this is software that can be copied, all sales are final, there will be no refunds on this offer. DISCLAIMER: The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use its resources. ************************************************************************************************** This mailing is done by an independent marketing company. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E-mail. No wasted paper! To be removed from this listserver, address book, please call us toll-free at 1-800-242-0363 Ext 2301 and we'll promptly honor your remove request.