From rem-conf Fri Dec 01 00:19:03 2000 From rem-conf-request@es.net Fri Dec 01 00:19:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141lJL-0000Ch-00; Fri, 1 Dec 2000 00:12:51 -0800 Received: from dsii.dsi.unifi.it [150.217.15.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 141lJK-0000CX-00; Fri, 1 Dec 2000 00:12:50 -0800 Received: (from icsm2001@localhost) by dsiI.dsi.unifi.it (8.9.1b+Sun/8.9.1) id JAA06416 for rem-conf@es.net; Fri, 1 Dec 2000 09:00:55 +0100 (MET) Date: Fri, 1 Dec 2000 09:00:55 +0100 (MET) From: icsm2001 (NESI) Message-Id: <200012010800.JAA06416@dsiI.dsi.unifi.it> To: rem-conf@es.net Subject: IEEE Int.Conf. Software Maintenance., Florence,Italy,ICSM2001 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague I would like to invite you at the IEEE International Conference on Software Maintenance, 2001, and associated workshops: SCAM, WESS, WSE, etc. next November 2001 in Florence, Italy. Outstanding Keynotes such as: Prof. David Lorge Parnas and Prof. Dieter Rombach. Industrial papers and experiences, reseach papers and award, tutorials, tool expositions, dissertation forum and award, workshops, panels, and other exciting activities have been planned. I hope that this CFPs could be useful for your work. Please forward the following to anybody who you think may be interested. Apologies if you have already seen this. If you would like to be removed from our list please send an email to icsm2001@dsi.unifi.it with REMOVE in the subject. ICSM2001 Paolo Nesi (General Chair) =_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= CALL---FOR---PAPER$ IEEE International Conference on Software Maintenance 2001 FLORENCE, ITALY, 6-10 November 2001 http://www.dsi.unifi.it/icsm2001 Theme: Systems and Software Evolution in the era of the Internet =_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= Sponsored by IEEE Supported bt the: EC-IST, University of Florence, O-Group ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. In the era of the Internet, businesses and end-users have invested in new technologies and small and large software organizations around the world are looking for Internet related solutions to evolve and maintain their new Internet software products. Internet technologies are strongly impacting system architectures and business processes and rules. In some cases businesses and end-users have been overwhelmed trying to keep up with software development and evolution processes and practices. In addition to novel solutions to enable the life-cycle of new web-based software systems, huge investments are necessary to migrate aginglegacy applications to web-enabled contemporary systems. ICSM 2001 will address these major changes in the software landscape and their impact on maintenance and evolution. The focus of the conference will be to explore the new challenges that the Internet, as a driver for business changes, poses for software maintenance, and the new opportunities it opens as infrastructure and enabling technology. The purpose of the conference is to promote discussion and interaction between researchers and practitioners. We are particularly interested in exchanging concepts, prototypes, research ideas, and other results which could contribute to the academic arena and also benefit business and the industrial community. ICSM 2001 will be participatory, with working collaborative sessions and presentations of industry projects. ICSM 2001 will bring together researchers, practitioners, developers and users of tools, technology transfer experts, and project managers. The Conference will be held in conjunction with: WESS -- the seventh Workshop on Empirical Studies of Software Maintenance. SCAM -- Source Code Analysis and Manipulation WSE -- Workshop on WEBsite Evolution Other workshops are welcome according to the limited available slots. Topics of interest include but are not restricted to the following aspects of maintenance and evolution: - Methods and theories -Processes and strategies - Organizational frameworks -Life cycle and process control - Design for maintenance -Tools and environments - Internet and distributed systems -Multimedia systems - User interface evolution -Commercial off-the-shelf (COTS) - Third party maintenance -Freeware and open source applications - Program comprehension -Software and system visualization - Knowledge based systems -Formal methods - Impact of new software practices -Empirical studies - Software reusability -Programming languages - Source code analysis and manipulation -Testing and regression testing - Models and methods for error prediction -Measurement of software - Maintenance and/or productivity metrics -Preventive maintenance - Personnel aspects of maintenance -Reengineering and reverse engineering - Version and configuration management -Legal aspects and standards - Management and organization -Remote, tele-work, and co-operative applications RESEARCH PAPERS Research papers should describe original and significant work in the research and practice of software maintenance. Research case studies, empirical research, and experiments are particularly welcome. We also welcome papers that present leading edge and novel ideas in maintenance. Papers should be 2000 - 5000 words in length, in English. Submit them in PDF or PostScript via email to icsm2001@unisannio.it by 15 January 2001. A prize of the Journal of Software Maintenance will be assigned at the Best submitted Paper. INDUSTRIAL APPLICATIONS We welcome proposals for presentations of Industrial Applications. These can be experience reports from real projects, industrial practices and models, or tool demonstrations. Submit proposals for Industrial Application presentations via email to icsm2001.industry@unisannio.it by 12 March 2001. Industrial Applications proposals will be reviewed by a dedicated sub-committee of the program committee and a 1 page summary of accepted proposals will be included in the conference proceedings. EXPOSITION AREA An exposition are is present in which tools realted to industrial applications can be shown. Please contact: nesi@dsi.unifi.it 1 page summary of accepted tools will be included in the conference proceedings. DISSERTATION FORUM We welcome submissions of young researchers that have delivered their dissertation (degree, master or Ph.D.) in the last three years. Please submit the PDF of the dissertation to icsm2001@unisannio.it by 15 January 2001. An Award and a full support to attend the conference will be given to the prize winner. Two other free registrations will be assigned at the second and third. 4 pages summary of accepted dissertations will be included in the conference proceedings and a special forum section will be organised at the conference. TUTORIALS Tutorials should present software maintenance and evolution topics of interest to practitioners. Tutorials may be full-day or half-day in length. Submit tutorial proposals via email to icsm2001.tutorial@unisannio.it by 12 February 2001. 1 page summary of accepted tutorial will be included in the conference proceedings. IMPORTANT DATES, DEADLINES Research Paper submission 15 January 2001, notification of acceptance 1 June 2001 Dissertation submission 15 January 2001 Industrial Application submission 12 March 2001 Tools request and submission 12 March 2001 Tutorial submission 12 February 2001 ------------------------------ General chair: Paolo Nesi, University of Florence, Italy, nesi@dsi.unifi.it Financial chair: Vaclav Rajlich, Wayne State University, USA, vtr@cs.wayne.edu Program co-chairs: Gerardo Canfora, University of Sannio, Italy, gerardo.canfora@unisannio.it Anneliese von Mayrhauser, Colorado State University, USA, avm@CS.ColoState.EDU Tutorials co-chairs: Lionel C. Briand, Carleton University, briand@sce.carleton.ca Alessandro Fantechi, University of Florence, Italy, Fantechi@dsi.unifi.it Industrial Applications co-chairs: Panagiotis K. Linos, Butler University, Department of Computer Science and Software Engineering, Indianapolis USA, linos@butler.edu, www.butler.edu/~linos Harry Sneed, Independent Consultant, Germany, Harry.Sneed@t-online.de Chris Verhoef, Free University Amsterdam, NL, x@cs.vu.nl Publicity co-chairs: Nicholas Zvegintzov (General Co-chair), Software Management Network, USA, zvegint@attglobal.net Malcolm Munro (Co-chair for Europe), University of Durham, UK, malcolm.munro@durham.ac.uk William Cheng-Chung Chu (Co-chair for East), TungHai University, Taiwan, chu@cis.thu.edu.tw Local Arrangements co-chairs: Fabrizio Fioravanti, University of Florence, Italy, fioravan@dsi.unifi.it Pierfrancesco Bellini (Industrial Applications, and Demos), University of Florence, Italy, bellini@hpcn.dsi.unifi.it Marius Bogdan Spinu, University of Florence, Italy, spinu@hpcn.dsi.unifi.it -------------------------------------------------------------------------------------------------------------- From rem-conf Fri Dec 01 03:34:44 2000 From rem-conf-request@es.net Fri Dec 01 03:34:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141oMn-0002My-00; Fri, 1 Dec 2000 03:28:37 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 141oMm-0002Mo-00; Fri, 1 Dec 2000 03:28:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22876; Fri, 1 Dec 2000 06:28:34 -0500 (EST) Message-Id: <200012011128.GAA22876@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-tcrtp-02.txt Date: Fri, 01 Dec 2000 06:28:34 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Tunneling multiplexed Compressed RTP ('TCRTP') Author(s) : B. Thompson, T. Koren, D. Wing Filename : draft-ietf-avt-tcrtp-02.txt Pages : Date : 30-Nov-00 This document describes a method to improve the end-to-end bandwidth utilization of RTP streams over an IP network using compression and multiplexing. This document describes the application of existing protocols for compression, multiplexing, and end to end tunneling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-tcrtp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-tcrtp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tcrtp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tcrtp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114057.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Dec 01 03:34:45 2000 From rem-conf-request@es.net Fri Dec 01 03:34:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141oMk-0002Mm-00; Fri, 1 Dec 2000 03:28:34 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 141oMi-0002Mc-00; Fri, 1 Dec 2000 03:28:32 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22836; Fri, 1 Dec 2000 06:28:30 -0500 (EST) Message-Id: <200012011128.GAA22836@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-crtp-enhance-01.txt Date: Fri, 01 Dec 2000 06:28:30 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Author(s) : S. Casner, V. Jacobson, T. Koren, B. Thompson, D. Wing, P. Ruddy, A. Tweedly, J. Geevarghese Filename : draft-ietf-avt-crtp-enhance-01.txt Pages : Date : 30-Nov-00 This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-crtp-enhance-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-enhance-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-enhance-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-enhance-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114042.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Dec 01 07:03:29 2000 From rem-conf-request@es.net Fri Dec 01 07:03:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141rdI-0005X3-00; Fri, 1 Dec 2000 06:57:52 -0800 Received: from sj-msg-core-1.cisco.com [171.71.163.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 141rdH-0005Vv-00; Fri, 1 Dec 2000 06:57:51 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA11345; Fri, 1 Dec 2000 06:56:52 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eB1Euv614257; Fri, 1 Dec 2000 06:56:57 -0800 (PST) Received: from [192.168.1.10] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA25742; Fri, 1 Dec 2000 06:56:25 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: Date: Fri, 1 Dec 2000 15:36:26 +0100 To: rem-conf@es.net, Stephen Casner , Colin Perkins , "Glenn Parsons" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Fwd: 3GPP-T-WG3 codecs Cc: Scott Bradner , Allison Mankin Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-1.cisco.com id GAA11345 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I sent the following message to the discussion list for Applications=20 Area, and should probably send it to you AVT people aswell. The VPIM=20 group (apps area) found that they want to have some cooperation with=20 these people, and my guess is that you want it aswell. Regards, Patrik Co-Area Director, Applications Area >Date: Thu, 30 Nov 2000 18:58:56 +0100 >Date: Thu, 30 Nov 2000 18:58:56 +0100 >To: discuss@apps.ietf.org >From: Patrik F=E4ltstr=F6m >Subject: 3GPP-T-WG3 codecs > >I need people interested in the are of codecs. Can someone help with=20 >the following request? > >Let me know if you are interested (or know someone which are interested). > > Patrik > Co-Area Director, Applications Area > > > >Date: Wednesday, 29 November, 2000 15:06 -0800 >From: "Leuca, Ileana" >To: "'sob@harvard.edu'" >Subject: 3GPP-T-WG3 codecs > > > >Scott, > >the 3GPP-T2-WG3 defines the minimum set of supported formats for >Multimedia Messaging Services. > >Please help to find an IETF person(s) to be included in the >process of standardizing the minimum set of codex for audio, >video and image types. > >In summary the following text is proposed today: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Multiple media elements shall be combined into a composite >single MM using MIME multipart format as defined in RFC 2046 >[x]. The media type of a single MM element shall be identified >by its appropriate MIME type whereas the media format shall be >indicated by its appropriate MIME subtype. > >In order to guarantee a minimum support and compatibility >between multimedia messaging capable terminals, the following >media formats shall be at least supported. > >Suggested formats or codecs for media type Audio: >- AMR / EFR; organised in octet format as specified in 3G TS >26.101 and 3G TS 26.101 >- MP3 >- MIDI >- WAV > >Suggested formats or codecs for media type Image: >- JPEG >- GIF 89a . > >Suggested formats or codecs for media type Video: >- MPEG 4 (Visual Simple Profile, Level 1) >- ITU-T H.263 >- Quicktime > >Minimum set of supported media shall support type Text formats. >Any character encoding (charset) that contains a subset of the >logical characters in Unicode [7] shall be used (e.g. US-ASCII >[8], ISO-8859-1[9], UTF-8[10], Shift_JIS, etc.). >Unrecognised subtypes of "text" shall be treated as subtype >"plain" as long as the MIME implementation knows how to handle >the charset. Any other unrecognised subtype and unrecognised >charset shall be treated as "application/octet - stream". > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D >thanks, >ileana > >-- --=20 From rem-conf Fri Dec 01 12:00:44 2000 From rem-conf-request@es.net Fri Dec 01 12:00:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141wEj-0001Fi-00; Fri, 1 Dec 2000 11:52:49 -0800 Received: from ertpg14e1.nortelnetworks.com [47.234.0.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 141wEi-0001FV-00; Fri, 1 Dec 2000 11:52:48 -0800 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 1 Dec 2000 14:43:09 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id XV2YKH3V; Fri, 1 Dec 2000 14:42:55 -0500 Received: from americasm01.nt.com (prtpd1gd.us.nortel.com [47.202.36.60]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W0VPLPFR; Fri, 1 Dec 2000 14:42:53 -0500 Message-ID: <3A27FF27.AA65A930@americasm01.nt.com> Date: Fri, 01 Dec 2000 14:42:31 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Chris Fulmer" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: G.711 (PCMA/PCMU), Silence Suppression & RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list So, I've noticed that there appear to be a few G.711-over-RTP implementations out there that have the habit of not sending a packet if it would only contain silence, but keeping the sequence numbering correct for the sent packets. In other words, packet w/ Timestamp 1 gets sent w/ sequence #1, packets w/ timestamps 2-5 aren't sent because they contain only silence then a packet w/timestamp 6 is sent w/ sequence #2. (I'm not sure off-hand what happens with the marker bit.) The only real reference to this scheme that I've found is in RFC 1890, section 4.1. There's also a new Appendix II for G.711, which suggests sending a packet with comfort noise indication during silence. (Unfortunately, I don't have a copy of this appendix currently.) It seems to me that the 'don't send silence' scheme is something of a bad idea, especially if the marker bit isn't set -- the receiving end doesn't really get any indication of what's going on: has the remote end died, or is it just sending silence? If somebody's monitoring the stream and you keep underflowing the jitter buffer, do these underflows count as much as they would if there were a real network problem? How would you know? Opinions? thx. -- Chris Fulmer Nortel Networks From rem-conf Fri Dec 01 13:10:33 2000 From rem-conf-request@es.net Fri Dec 01 13:10:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141xPM-0002dW-00; Fri, 1 Dec 2000 13:07:52 -0800 Received: from nmh.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 141xPK-0002dM-00; Fri, 1 Dec 2000 13:07:50 -0800 Received: from cabo3 (nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eB1L7hU11230; Fri, 1 Dec 2000 22:07:43 +0100 (MET) From: "Dr. Carsten Bormann" To: "Chris Fulmer" , Subject: RE: G.711 (PCMA/PCMU), Silence Suppression & RTP Date: Fri, 1 Dec 2000 22:07:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A27FF27.AA65A930@americasm01.nt.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The sequence number is contiguous, so the receiver knows there are no losses. Also, the sender is still sending RTCP, so you know it's there. Gruesse, Carsten From rem-conf Fri Dec 01 13:34:25 2000 From rem-conf-request@es.net Fri Dec 01 13:34:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141xmW-0003df-00; Fri, 1 Dec 2000 13:31:48 -0800 Received: from newman.cs.purdue.edu [128.10.2.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 141xmU-0003dV-00; Fri, 1 Dec 2000 13:31:46 -0800 Received: from tigris.cs.purdue.edu (727@tigris.cs.purdue.edu [128.10.2.71]) by newman.cs.purdue.edu (8.10.1/8.10.1/PURDUE_CS-2.0) with ESMTP id eB1LVjv29784 for ; Fri, 1 Dec 2000 16:31:45 -0500 (EST) Received: from localhost (kwonm@localhost) by tigris.cs.purdue.edu (8.10.1/8.10.1/PURDUE_CS-2.0) with ESMTP id eB1LVi103754 for ; Fri, 1 Dec 2000 16:31:44 -0500 (EST) Date: Fri, 1 Dec 2000 16:31:44 -0500 (EST) From: Minseok Kwon To: Subject: sound analysis tool... 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 have a question. I'm experimenting the sender-based packet loss recovery scheme using RAT made in UCL MM group. I would like to compare the results of various schemes like no redundancy, redundancy and interleaving. Is there a good tool to analyze the audio file to evaluate the degree of articulation? And illustrate the audio data to waveform? Thanks. In one paper of UCL group says it uses OGI(Oregon Graduate Institute) speech tools. But there's only tools for windows not for unix? Any help is appreciated. Regards, ____________________________________________________________________ James(Minseok) Kwon http://www.cs.purdue.edu/~kwonm 1398 Computer Science Phone: (765) 464-2777(H) Purdue University (765) 494-7811(O) West Lafayette, IN 47907 Email: kwonm@cs.purdue.edu From rem-conf Fri Dec 01 13:35:38 2000 From rem-conf-request@es.net Fri Dec 01 13:35:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141xpO-0003hp-00; Fri, 1 Dec 2000 13:34:46 -0800 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 141xpM-0003hX-00; Fri, 1 Dec 2000 13:34:44 -0800 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.11.1/8.11.1) with ESMTP id eB1LXh617246; Fri, 1 Dec 2000 14:33:44 -0700 (MST) Received: from P-micke (baskerville.CS.Arizona.EDU [192.12.69.35]) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) with SMTP id eB1LYf318426; Fri, 1 Dec 2000 14:34:41 -0700 (MST) Message-Id: <200012012134.eB1LYf318426@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 01 Dec 2000 22:37:06 +0100 To: "Chris Fulmer" From: Mikael Degermark Subject: Re: G.711 (PCMA/PCMU), Silence Suppression & RTP Cc: rem-conf@es.net In-Reply-To: <3A27FF27.AA65A930@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This idea breaks the definition of the RTP sequence number, so it must be a bad idea. However, (and now I don my ROHC hat), header compression may actually benefit, since the function from RTP sequence number to RTP timestamp is maintained and need not be reestablished after the silence interval. Mikael Degermark At 02:42 PM 12/1/00 -0500, Chris Fulmer wrote: >So, I've noticed that there appear to be a few G.711-over-RTP >implementations out there that have the habit of not sending a packet if >it would only contain silence, but keeping the sequence numbering >correct for the sent packets. In other words, packet w/ Timestamp 1 >gets sent w/ sequence #1, packets w/ timestamps 2-5 aren't sent because >they contain only silence then a packet w/timestamp 6 is sent w/ >sequence #2. (I'm not sure off-hand what happens with the marker bit.) > >The only real reference to this scheme that I've found is in RFC 1890, >section 4.1. > >There's also a new Appendix II for G.711, which suggests sending a >packet with comfort noise indication during silence. (Unfortunately, I >don't have a copy of this appendix currently.) > >It seems to me that the 'don't send silence' scheme is something of a >bad idea, especially if the marker bit isn't set -- the receiving end >doesn't really get any indication of what's going on: has the remote >end died, or is it just sending silence? If somebody's monitoring the >stream and you keep underflowing the jitter buffer, do these underflows >count as much as they would if there were a real network problem? How >would you know? > > >Opinions? > >thx. > >-- >Chris Fulmer >Nortel Networks > From rem-conf Fri Dec 01 13:49:44 2000 From rem-conf-request@es.net Fri Dec 01 13:49:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141y2r-0005Am-00; Fri, 1 Dec 2000 13:48:41 -0800 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 141y2q-0005Ac-00; Fri, 1 Dec 2000 13:48:40 -0800 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.11.1/8.11.1) with ESMTP id eB1Lld617429; Fri, 1 Dec 2000 14:47:39 -0700 (MST) Received: from P-micke (baskerville.CS.Arizona.EDU [192.12.69.35]) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) with SMTP id eB1Lma318790; Fri, 1 Dec 2000 14:48:36 -0700 (MST) Message-Id: <200012012148.eB1Lma318790@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 01 Dec 2000 22:51:01 +0100 To: Mikael Degermark From: Mikael Degermark Subject: Re: G.711 (PCMA/PCMU), Silence Suppression & RTP Cc: "Chris Fulmer" , rem-conf@es.net In-Reply-To: <200012012134.eB1LYf318426@baskerville.CS.Arizona.EDU> References: <3A27FF27.AA65A930@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chris and others, My comment was too hasty, I didn't read carefully enough. Forget what I said. The scheme you presented does not break the definition of the RTP sequence number. ROHC deals well with such RTP streams. Cheers, Mikael Degermark At 10:37 PM 12/1/00 +0100, Mikael Degermark wrote: >This idea breaks the definition of the RTP sequence number, >so it must be a bad idea. > >However, (and now I don my ROHC hat), header compression may >actually benefit, since the function from RTP sequence >number to RTP timestamp is maintained and need not be >reestablished after the silence interval. > >Mikael Degermark > >At 02:42 PM 12/1/00 -0500, Chris Fulmer wrote: >>So, I've noticed that there appear to be a few G.711-over-RTP >>implementations out there that have the habit of not sending a packet if >>it would only contain silence, but keeping the sequence numbering >>correct for the sent packets. In other words, packet w/ Timestamp 1 >>gets sent w/ sequence #1, packets w/ timestamps 2-5 aren't sent because >>they contain only silence then a packet w/timestamp 6 is sent w/ >>sequence #2. (I'm not sure off-hand what happens with the marker bit.) >> >>The only real reference to this scheme that I've found is in RFC 1890, >>section 4.1. >> >>There's also a new Appendix II for G.711, which suggests sending a >>packet with comfort noise indication during silence. (Unfortunately, I >>don't have a copy of this appendix currently.) >> >>It seems to me that the 'don't send silence' scheme is something of a >>bad idea, especially if the marker bit isn't set -- the receiving end >>doesn't really get any indication of what's going on: has the remote >>end died, or is it just sending silence? If somebody's monitoring the >>stream and you keep underflowing the jitter buffer, do these underflows >>count as much as they would if there were a real network problem? How >>would you know? >> >> >>Opinions? >> >>thx. >> >>-- >>Chris Fulmer >>Nortel Networks >> > From rem-conf Fri Dec 01 14:04:48 2000 From rem-conf-request@es.net Fri Dec 01 14:04:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141yHa-0005zJ-00; Fri, 1 Dec 2000 14:03:54 -0800 Received: from hafez.east.isi.edu [38.218.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 141yHZ-0005z7-00; Fri, 1 Dec 2000 14:03:53 -0800 Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id eB1M3pN18049 for ; Fri, 1 Dec 2000 17:03:51 -0500 Message-Id: <200012012203.eB1M3pN18049@hafez.east.isi.edu> To: rem-conf@es.net Subject: Updated AVT agenda Date: Fri, 01 Dec 2000 17:03:51 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, A revised AVT agenda for the San Diego AVT meeting is enclosed below. If you have comments, corrections or additions, you should contact me immediately. Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group Agenda Wednesday, 13th December 2000, 15:30-17:30 ========================================== - Introduction and status update (Casner/Perkins) 10 - draft-ietf-avt-rtp-new-08.txt - draft-ietf-avt-profile-new-09.txt - draft-ietf-avt-rtp-mime-03.txt - draft-ietf-avt-dv-audio-02.txt - draft-ietf-avt-dv-video-03.txt - draft-ietf-avt-rtp-mp3-04.txt - draft-bbuffam-avt-crtp-over-aal2-01.txt - draft-ietf-avt-rtp-cn-01.txt - RFC 2833 - RFC 2862 - RFC 2959 - Congestion control in RTP (Casner) 10 - RTP Interoperability testing (Perkins) 10 - draft-ietf-avt-rtp-interop-05.txt - draft-ietf-avt-profile-interop-03.txt - RTP Payload Format for SMPTE-292M - http://www.east.isi.edu/~ladan/smpte292.txt (Gharai) 10 - RTP Payload Format for EVRC Speech - draft-3gpp2-avt-evrc-00.txt (Li) 10 - draft-mccann-avt-rtp-evrc-00.txt (McCann) 10 - Discussion 10 - Error Tolerant RTP Payload Format for AMR - draft-xie-avt-et-rtp-amr-02.txt (Xie) 5 - draft-ietf-avt-rtp-amr-01.txt (Sjöberg) 5 - Discussion 10 - Low delay RTCP Feedback Format - draft-fukunaga-low-delay-rtcp-01.txt (Burmeister) 10 - draft-wenger-avt-rtcp-feedback-01.txt (Ott) 10 - Discussion 10 Thursday, 14th December 2000, 13:00-15:00 ========================================= - TCRTP and enhancements to CRTP (Koren) 10 - draft-ietf-avt-tcrtp-02.txt - draft-ietf-avt-crtp-enhance-01.txt - draft-koren-avt-crtp-ipcp-00.txt - An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams - draft-lnt-avt-uxp-02.txt (Pandel) 10 - An RTP Payload Format for Generic FEC with Uneven Level Protection - draft-ietf-ulp-00.txt (Li) 10 - RTP Payload Format for Payload Meta-Information (Serenyi) 10 - draft-serenyi-avt-rtp-meta-00.txt - RTP Payload Format for Program Cues - draft-brassil-avt-cues-00.txt (Brassil) 10 - Encryption, authentication and related issues - draft-blom-cmsec-3G-00.txt (Carrara) 10 - draft-blom-rtp-encrypt-00.txt (Carrara) 10 - draft-mcgrew-avt-srtp-00.txt (McGrew) 10 - Discussion 10 - RTP Payload format for MPEG-4 - Introduction (Perkins) 5 - draft-gentric-avt-rtp-mpeg4-00.txt (Gentric) 10 - draft-singer-mpeg4-ip-02.txt - RFC 3016 Once again, we have a full agenda. In order to get the most out of the meeting, we strongly encourage you to read all relevent drafts before the meeting, and for those making presentations to assume that the audience has read the draft. Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe the changes from the previous draft, highlight unresolved problems, propose future directions. Authors are also reminded of the contents of section 10 of RFC 2026. In particular, the requirement for disclosure of intellectual property relating to contributions. From rem-conf Fri Dec 01 14:49:44 2000 From rem-conf-request@es.net Fri Dec 01 14:49:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141yvg-00076g-00; Fri, 1 Dec 2000 14:45:20 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 141yvf-00076W-00; Fri, 1 Dec 2000 14:45:19 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Dec 2000 22:45:13 +0000 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Chris Fulmer cc: rem-conf@es.net Subject: Re: G.711 (PCMA/PCMU), Silence Suppression & RTP In-reply-to: Your message of "Fri, 01 Dec 2000 14:42:31 EST." <3A27FF27.AA65A930@americasm01.nt.com> Date: Fri, 01 Dec 2000 22:45:11 +0000 Message-ID: <9311.975710711@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <3A27FF27.AA65A930@americasm01.nt.com>Chris Fulmer writes: > So, I've noticed that there appear to be a few G.711-over-RTP > implementations out there that have the habit of not sending a packet if > it would only contain silence, but keeping the sequence numbering > correct for the sent packets. > > In other words, packet w/ Timestamp 1 > gets sent w/ sequence #1, packets w/ timestamps 2-5 aren't sent because > they contain only silence then a packet w/timestamp 6 is sent w/ > sequence #2. (I'm not sure off-hand what happens with the marker bit.) > The only real reference to this scheme that I've found is in RFC 1890, > section 4.1. > > There's also a new Appendix II for G.711, which suggests sending a > packet with comfort noise indication during silence. (Unfortunately, I > don't have a copy of this appendix currently.) > > It seems to me that the 'don't send silence' scheme is something of a > bad idea, especially if the marker bit isn't set -- the receiving end > doesn't really get any indication of what's going on: has the remote > end died, or is it just sending silence? It's a product differentiator, an optional feature (of merit). Comfort noise doesn't need to be sent continously so applications still get two chances to detect new talkspurts (marker and change in relationship between seq and ts). > If somebody's monitoring the stream and you keep underflowing the > jitter buffer, do these underflows count as much as they would if > there were a real network problem? How would you know? It's upto the tool to adapt it's playout to avoid under/overflow. Applications can compensate for a few percent timing skew and the user will not notice. A monitor cannot know whether an application does this or not, however with broken sequence numbering it's clearly a useful feature. - Orion. From rem-conf Fri Dec 01 15:04:55 2000 From rem-conf-request@es.net Fri Dec 01 15:04:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141zDD-0000AP-00; Fri, 1 Dec 2000 15:03:27 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 141zDB-0000AF-00; Fri, 1 Dec 2000 15:03:25 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Dec 2000 23:03:20 +0000 From: Orion Hodson To: Minseok Kwon cc: rem-conf Subject: Re: sound analysis tool... In-reply-to: Your message of "Fri, 01 Dec 2000 16:31:44 EST." Date: Fri, 01 Dec 2000 23:03:18 +0000 Message-ID: <9612.975711798@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Minseok Kwon writ es: > I have a question. I'm experimenting the sender-based packet loss recovery > scheme using RAT made in UCL MM group. I would like to compare the results > of various schemes like no redundancy, redundancy and interleaving. > > Is there a good tool to analyze the audio file to evaluate the degree of > articulation? And illustrate the audio data to waveform? Thanks. See comp.speech faq. Also- http://WWW.TSP.ECE.McGill.CA/reports/Software/index.html ITU Speech Tools (G.191), matlab, mxv. From rem-conf Fri Dec 01 15:08:15 2000 From rem-conf-request@es.net Fri Dec 01 15:08:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141zHN-0000WC-00; Fri, 1 Dec 2000 15:07:45 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 141zHM-0000W0-00; Fri, 1 Dec 2000 15:07:44 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Dec 2000 23:06:24 +0000 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Chris Fulmer cc: rem-conf@es.net Subject: Re: G.711 (PCMA/PCMU), Silence Suppression & RTP In-reply-to: Your message of "Fri, 01 Dec 2000 22:45:11 GMT." <9311.975710711@cs.ucl.ac.uk> Date: Fri, 01 Dec 2000 23:06:22 +0000 Message-ID: <9638.975711982@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <9311.975710711@cs.ucl.ac.uk>Orion Hodson writes: > <3A27FF27.AA65A930@americasm01.nt.com>Chris Fulmer writes: > > If somebody's monitoring the stream and you keep underflowing the > > jitter buffer, do these underflows count as much as they would if > > there were a real network problem? How would you know? > > It's upto the tool to adapt it's playout to avoid under/overflow. > Applications can compensate for a few percent timing skew and the user > will not notice. A monitor cannot know whether an application does > this or not, however with broken sequence numbering it's clearly a useful feature. ^^^^^^ continuous (not broken) From rem-conf Fri Dec 01 15:33:21 2000 From rem-conf-request@es.net Fri Dec 01 15:33:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 141zfD-0001ka-00; Fri, 1 Dec 2000 15:32:23 -0800 Received: from chai.east.isi.edu [38.218.19.199] by mail1.es.net with esmtp (Exim 1.81 #2) id 141zfB-0001kQ-00; Fri, 1 Dec 2000 15:32:21 -0800 Received: from chai.east.isi.edu (localhost [127.0.0.1]) by chai.east.isi.edu (8.9.3/8.9.3) with ESMTP id TAA40028 for ; Fri, 1 Dec 2000 19:36:54 GMT (envelope-from ladan@chai.east.isi.edu) Message-Id: <200012011936.TAA40028@chai.east.isi.edu> Reply-to: ladan@east.isi.edu To: rem-conf@es.net Subject: draft-ietf-avt-smpte292-video-01.txt Date: Fri, 01 Dec 2000 19:36:53 +0000 From: Ladan Gharai X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We've missed the deadline :( Please comment! - Ladan. INTERNET-DRAFT Ladan Gharai USC/ISI Gary Goncher Tektronix Colin Perkins USC/ISI David Richardson University of Washington Allison Mankin USC/ISI Nov 24, 2000 RTP Payload Format for SMPTE 292M 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 specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 292M into a payload format for the Real-Time Transport Protocol (RTP). The RTP packet counter is draft-ietf-avt-smpte292-video-01.txt [Page 1] INTERNET-DRAFT Nov 24, 2000 extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. 1. Introduction The serial digital interface, SMPTE 292M[1], defines a universal medium of interchange for uncompressed HDTV between various types of video equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s (and 1.485/1.001 Gb/s). Source formats transfered by SMPTE 292M are SMPTE 260M, 295M, 274M and 296M. Source data for these formats are 10-bit words, sampled at 4:2:2. In this memo we specify how to transfer SMPTE 292M over RTP. This memo only addresses the transfer of uncompressed HDTV. Compressed HDTV is a subset of MPEG-2 [3], which is fully described in document A/53 [4] of the Advanced Television Standards Committee. The ATSC has also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [5]. Therefore: 1. The HDTV transport system is a compatible subset of the MPEG-2 transport system. Section 2 of RFC 2250 [7] describes the RTP payload for MPEG-2's transport system, where multiple fixed length (188 bytes) MTS packets are aggregated into a single RTP packet. 2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional restrictions. Section 3 of RFC 2250 describes a packetization scheme for MPEG-2 elementary streams. The additional restrictions of HDTV do not have any implications for RTP packetization. 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[10]. 3. Payload Design Each video frame of SMPTE 292M is packetized into a number of constant size RTP packets. All active, vertical blanking and timing information is packetized. The end of a frame is marked by the M bit in the RTP header. A single packet may contain data for two consecutive scan lines. The SMPTE 292M decoder uses the sync info in the scan lines to detect the start of scan lines. draft-ietf-avt-smpte292-video-01.txt [Page 2] INTERNET-DRAFT Nov 24, 2000 A single packet may also contain information from adjacent scan lines in two consecutive frames, or by agreement between sender and receiver the last packet of a video frame may be padded to the full length of all 292M RTP packets, in which case a new will frame start in a new packet. The standard 16 bit RTP sequence counter is extended to 32 bits to accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of at least 1kByte, 32bits allows for an approximate 6 hour period before the sequence counter wraps around. A 10Mhz timestamp is used as the RTP header's timestamp. This allows the receiver to reconstruct the timing of the SMPTE 292M stream, without knowledge of the exact type of source format (e.g. SMPTE 274M or SMPTE 296M). Given SMPTE 292M's 4:2:2 color subsampling, scan line fragmentation MUST occur on sample-pair boundaries, such that Y and Cb and Cr values are not split across packets. This means the payload section of each packet will be a multiple of 40bits. In addition, to ensure unique timestamps, each packet SHOULD contain more than 8 video samples (20 bytes). 4. RTP Packetization The standard RTP header is followed by a 4 byte payload header, and the payload data. 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 |P|X| CC |M| PT | sequence# (low bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ssrc | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence# (high bits) | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1. The RTP Header The following fields of the RTP fixed header are used for SMPTE 292M encapsulation: draft-ietf-avt-smpte292-video-01.txt [Page 3] INTERNET-DRAFT Nov 24, 2000 Payload Type (PT): 7bits A dynamically allocated payload type field which designates the payload as SMPTE 292M. Timestamp: 32 bits The timestamp field shall be defined from a counter at 10 MHz. The timestamp shall be defined as the arrival time of the first 20-bit video sample to be transmitted in the current packet. At an arrival rate of 74.25 MHz for 20-bit SMPTE 292M video samples with 24/30/60Hz frame rates, the timestamp will be unique for packets with more than 8 video samples (20 bytes) and therefore, each packet SHOULD contain more than 8 samples. Timestamps shall increase monotonically until they roll over at 32 bits. One possible means of deriving the 10 MHz clocks is from a GPS (Global Positioning System) board. These boards have a disciplined oscillator that is synchronized to GPS time. The disciplined oscillator can be as accurate as 1 in 10-12, but is more typically 1 in 10-8. Thus clocks at widely separate locations can be synchronized with an accuracy of 100 ns for video timing recovery. Marker bit (M): 1bit The Marker bit denotes the end of a video frame, and is set to 1 for the last packet of the video frame and is otherwise set to 0 for all other packets. Sequence Number (low bits): 16 bits The low order bits for RTP sequence counter. The standard 16 bit RTP sequence number is augmented with another 16 bits in the payload header in order to accommodate the 1.485Gb/s data rate of SMPTE 292M. 4.2. Payload Header Sequence Number (high bits): 16bits The high order bits for the 32bit RTP sequence counter. Unused: 16bits MUST be set to zero at the sender, and ignored at the receiver. 4.3. Payload Format For 4:2:2 color subsampling Cb and Cr values are subsampled by a factor of two horizontally and are co-sited with even numbered Y samples. Therefore, Cb, Cr and Y samples MUST be arranged and transmitted in the following order: draft-ietf-avt-smpte292-video-01.txt [Page 4] INTERNET-DRAFT Nov 24, 2000 Cb, Y, Cr, Y, Cb, Y, Cr, ... where the first Cb, Y, Cr sequence refers to co-sited luminance and color-difference samples, and the next Y belongs to the next luminance sample. Therefore, as set forth in RFC2431 [11], for 10-bit words, each group of four samples must be encoded into a 40-bit word (five octets) prior to transmission. The following is a representation of a 720 sample packet with 10-bit quantization: 0 1 2 3 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 +---------+---------+---------+---------+ | Cb0 | Y0 | Cr0 | Y1 | +---------+---------+---------+---------+ | Cb1 | Y2 | Cr1 | Y3 | +---------+---------+---------+---------+ . . . +---------+---------+---------+---------+ | Cb359 | Y718 | Cr359 | Y719 | +---------+---------+---------+---------+ (Note that the word width is 40 bits) +-------+-------+-------+-------+-------+ Octets: | 0 | 1 | 2 | 3 | 4 | +-------+-------+-------+-------+-------+ The octets shown in these diagrams are transmitted in network bit and byte order, that is, left-to-right as shown. 5. RTCP Considerations RFC1889 recommends transmission of RTCP packets every 5 seconds or at a reduced minimum in seconds of 360 divided by the session bandwidth in kilobits/seconds. At 1.485Gb/s the reduced minimum interval computes to 0.2ms or 4028 packets per second. It should be noted that the sender's octet count in SR packets wraps around in 23 seconds, and that the cumulative number of packets lost wraps around in 93 seconds. This means these two fields cannot accurately represent octet count and number of packets lost since the beginning of transmission, as defined in RFC1889. Therefore for network monitoring purposes other means of keeping track of these variables should be used. draft-ietf-avt-smpte292-video-01.txt [Page 5] INTERNET-DRAFT Nov 24, 2000 6. MIME Registration This document defines a new RTP payload name and associated MIME type, SMPTE 292M. The registration forms for MIME type for SMPTE 292M video is enclosed below: MIME media type name: video MIME subtype name: SMPTE 292M Required parameters: None Optional parameters: None Encoding considerations: SMPTE 292M video can be transmitted with RTP as specified in "draft-ietf-avt-smpte292-video-01". Security considerations: None Interoperability considerations: NONE Published specification: SMPTE 292M draft-ietf-avt-smpte292-video-01 Applications which use this media type: Video communication. Additional information: None Magic number(s): None File extension(s): DV Macintosh File Type Code(s): None Person & email address to contact for further information: Ladan Gharai Intended usage: COMMON Author/Change controller: Ladan Gharai 7. Mapping to SDP Parameters Parameters are mapped to SDP [9] as follows: draft-ietf-avt-smpte292-video-01.txt [Page 6] INTERNET-DRAFT Nov 24, 2000 m=video 23456 RTP/AVP 111 a=rtpmap:111 SMPTE 292M/10000000 a=fmtp:111 length=1400 In this example, a dynamic payload type 111 is assumed for SMPTE 292M, with packet sizes of 1400bytes. 8. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification, and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat. It is perhaps to be noted that the bandwidth of this payload is high enough (1.5 Gbps without the RTP overhead) to cause potential for denial-of-service if transmitted onto most currently available Internet paths. In the absence from the standards track of a suitable congestion control mechanism for flows of this sort, use of the payload should be narrowly limited to suitably connected network endpoints and great care taken with the scope of multicast transmissions. This potential threat is common to all high bit rate applications. 9. IANA Considerations See Section 6. 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by draft-ietf-avt-smpte292-video-01.txt [Page 7] INTERNET-DRAFT Nov 24, 2000 removing the copyright notice or references to the Internet Soci- ety or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be fol- lowed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 11. Authors' Addresses Ladan Gharai ladan@isi.edu Gary Goncher ggoncher@tek.com Colin Perkins csp@isi.edu David Richardson drr@u.washington.edu Allison Mankin mankin@isi.edu 12. Bibliography [1] Society of Motion Picture and Television Engineers, Bit-Serial Digital Interface for High-Definition Television Systems, SMPTE 292M, 1998. [2] Society of Motion Picture and Television Engineers, 1280*720 Scanning, Analog and Digital Representation and Analog Interfaces, SMPTE 296M, 1998. draft-ietf-avt-smpte292-video-01.txt [Page 8] INTERNET-DRAFT Nov 24, 2000 [3] ISO/IEC International Standard 13818-2; "Generic coding of moving pictures and associated audio information: Video", 1996. [4] ATSC Digital Television Standard Document A/53, September 1995, http://www.atsc.org [5] ISO/IEC International Standard 13818-1; "Generic coding of moving pictures and associated audio information: Systems",1996. [6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport protocol for real time Applications", RFC 1889, IETF, January 1996. [7] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. [8] Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, IETF, January 1996. [9] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [10] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels". [11] D. Tynan, "RTP Payload Format for BT.656 Video Encoding", RFC 2431, October 1998. draft-ietf-avt-smpte292-video-01.txt [Page 9] From rem-conf Sun Dec 03 21:21:23 2000 From rem-conf-request@es.net Sun Dec 03 21:21:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142nqT-0000sr-00; Sun, 3 Dec 2000 21:07:21 -0800 Received: from ns.shintoshi-systems.co.jp [210.160.86.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 142nqO-0000sh-00; Sun, 3 Dec 2000 21:07:19 -0800 Received: from Y9chvSfsf ([63.36.150.15]) by ns.shintoshi-systems.co.jp (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id jp; Mon, 4 Dec 2000 11:52:23 +0900 DATE: 03 Dec 00 8:39:55 PM FROM: 96o725A7O@wire.net.au Message-ID: <80xYO1jgij5yB> TO: cattl@solar.co.it SUBJECT: About Your Rebate Check? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list About Your Rebate Check Save $100’s even $1,000’s on your life insurance, then cash your HUGE rebate check! Get all the details right now: http://www.hugerebate.com HUGE commission rebates in California and Florida. All other states receive HIGHLY DISCOUNTED rates where rebating is not allowed. Examples: 1. CA and FL Life Insurance Male Non Smoker 50 years old Health Very Good Benefit $500,000 Typical Premium $100/month Commission $1,080 YOUR HUGE REBATE $540 2. CA and FL under Indexed Investments Typical Index $50,000 YOUR HUGE REBATE $2,500 3. Other States Rebates may not be allowed in your state, but we not only have some of the lowest rates availible, we also have additional first year discounts in lieu of rebates. Get all the details right now at : http://www.hugerebate.com Or call : 312) 577-0391 ______________________________________________________ To be removed from this database reply back with R in the subject to: loram@yemenmail.com From rem-conf Mon Dec 04 00:37:20 2000 From rem-conf-request@es.net Mon Dec 04 00:37:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142r4t-0003JS-00; Mon, 4 Dec 2000 00:34:27 -0800 Received: from lumumba.luc.ac.be [193.190.9.252] (mail) by mail1.es.net with esmtp (Exim 1.81 #2) id 142r4r-0003JI-00; Mon, 4 Dec 2000 00:34:25 -0800 Received: from jori (helo=localhost) by lumumba.luc.ac.be with local-esmtp (Exim 3.12 #1 (Debian)) id 142r4p-0003QS-00 for ; Mon, 04 Dec 2000 09:34:23 +0100 Date: Mon, 4 Dec 2000 09:34:23 +0100 (CET) From: Jori Liesenborgs X-Sender: jori@lumumba.luc.ac.be To: rem-conf@es.net Subject: jrtplib v2.5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jori X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everybody ! I just wanted to let you know that there is a new version of jrtplib, a RTP library which I wrote. It is an object-oriented library, written in C++. You can find out more about it at this url: http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html Changes from version 2.4 include: - several major bugfixes - possibility to get the raw RTCP data. For a more complete list you should check the ChangeLog Bye, Jori From rem-conf Mon Dec 04 02:56:48 2000 From rem-conf-request@es.net Mon Dec 04 02:56:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142tGi-0005DL-00; Mon, 4 Dec 2000 02:54:48 -0800 Received: from (bbs.ht.net.cn) [202.103.160.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 142tGg-0005D4-00; Mon, 4 Dec 2000 02:54:46 -0800 Received: from h809 (1Cust27.tnt2.mia5.da.uu.net [63.30.197.27]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id TAA29860; Mon, 4 Dec 2000 19:11:11 +0800 Date: Mon, 4 Dec 2000 19:11:11 +0800 From: HV@derfriseur.de Message-Id: <200012041111.TAA29860@bbs.ht.net.cn> To: HV@derfriseur.de Subject: At Last, Herbal V, the All Natural Alternative is Available! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Herbal V: An Incredible All-Natural Healthy Alternative To V----a Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$46, 2 bottles=$66, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From rem-conf Mon Dec 04 05:03:42 2000 From rem-conf-request@es.net Mon Dec 04 05:03:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142vFE-0007Gi-00; Mon, 4 Dec 2000 05:01:24 -0800 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 142vF9-0007EW-00; Mon, 4 Dec 2000 05:01:20 -0800 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G5100J73NXSQD@ss3000e.cselt.it> for rem-conf@es.net; Mon, 4 Dec 2000 13:56:17 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Mon, 04 Dec 2000 13:59:41 +0100 Content-return: allowed Date: Mon, 04 Dec 2000 13:56:15 +0100 From: Franceschini Guido Subject: RE: Draft AHG meeting report To: 'Young-Kwon LIM' , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Message-id: <85077463E51D6A498C453073E167794039BF24@clu2k02a.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/mixed; boundary="----_=_NextPart_000_01C05DF2.108ADF20" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C05DF2.108ADF20 Content-Type: text/plain; charset="windows-1252" Young, Philippe, all, here attached is my personal view on the work being done. I hope I have fairly presented the AGREED results, together with additional considerations of my own. The document is intended to be read and understood (hopefully) also by those not present in NY. As a minimum, it will make you understand how my brain works ;-) That document also provides a tentative specification for the bits on the wire, since in NY we made agreements on several issues but left the exact syntax as homework for me and Philippe. In order to produce a clear document, I have also reported the open issues and designed the syntax according to my own personal (but motivated) preference on those issues. It would be great if we could close the few remeaining details, so that Philippe can safely edit the Internet Draft. Guido -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Friday, December 01, 2000 4:33 AM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: Draft AHG meeting report Dear all, Thank you everyone. The meeting was very fruitable. We made a real progress this time. Attached you will find a draft meeting report including resolutions. Comments are welcome. Sincerely, Young. ------_=_NextPart_000_01C05DF2.108ADF20 Content-Type: application/octet-stream; name="Mguido.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Mguido.zip" UEsDBBQAAAAIAARthCkMhtGjA1QAAACAAQAKAAAATWd1aWRvLmRvY+ydCWBdRbn4J2m6BBooS0uh pRygQNIlTdK9pdDQvXSjaWVfbpKT5LY396b33rSNWhREERFUdsGyr09RQP+KIrKoiPBEQPQhggL1 PQQrAopUUPn/vpk5211CmoKtmnP7682ZM2fOzDcz33wzZ2bu4z/d6/nr7jzgBZVzHKX6qX+8W64G hNxK4R7vZIhS9/JVAv949913xenb8B14t+/4lzm23vSAWuqUlym1be/7/JzlwKVmo1J7qMY1jWte nPXiLJV3lJcNU6MeUurjxxtqsvl+wse77+75nn97R0L/f/Yg5X+H/y72vW8ohMus+6cnFP8+ku8f 8P3nkP+PkorvUax/UKPUI5xfWGvcu/t+m6rx6UlKPct582SlOvi+NmVqzPUp4y/8vR/f3+b7zzzn 9nXm+7qMUqNxn7FeKYcbT0L693P+Q9yHqvzDS/dTkwtcVPnx9Px53xKuHG2rzXeuPL37vMM7f4b7 Tgrdl/st4X9qr/xwcs+vtfLwDu/+7T289HjhSTgD+gfhJYnsX5DnJopUU2l+Ont7eM/z0nM35WUw 32fsdtmqP556f4mUpzcOD8rbSQuoTXso9XzSlLvccCZR7hYqU/7kGIn7OXwf0GXOvfR45+H0yuGV 38ty0lfsu1T9kv8XLVs1b+Wy+lWLli+rX+IsX7mgftmiBn3qzF++0mlYVb9sbv3KudatIuIhcu88 Z+48Z9nylUvrl3ieFzUsn7Bo3hxn8ao5tRMa5tRNn3D8gtraijnL5y5atsBZPt9ZuvxD8teKRXNW rV45r8HhWU59Q8PyOYvqV83jz9VzFy3nKfMlVB1isSCXrpi3oKZmwkaOimWp9W57o5t26mpqaioq KhpSnekmd0b5nIZ5S1ZVNGRj2c7MjPIV6VRHKhNLVKyKZxNyNZVsimXdZCwbTyWdVIuTcde76VjC aVjirIg1rXWzGSeezKacVNJ1Vq5a4XRox4r6zmxbKj2jfEFnvDnlzE/Hkk1upqktnoxXVNQ3ZrLp WBOesk62zXWWuRtOTKXXOrHm8W2pJqfddbPxZKvTnI6189gmpyOdak27mQzP0P55dKV+Vnuso0N8 bohlnBiBE7XmcUSnKdHZLO7iuSmSgHgm0+lWO6va4hm5kk3HGzvNhSR+mjMOKUm7Ham0iVmzm43F E26zF3q7myS9SCHbFst6Ec19YnsqG1+vH5cx/tpi6wkqHV/vJm2oTfGMPJSEIZVMtVPPQ9fH3Q0m aJez9hiiIsBUh2tjjZwzcsf6eLNEKONscBOJcU5jLMMpgTWmsm2eOB0tz1RntinV7jqxZLPT4aYz qST51tKZxlNaUp8hpLSOaDUlqF1SHUtmZ+hAkGw6Raqd02PI3m0+3YlFM8vLJZE9Qkumsk4M8TSb HOrKZN32jJPpIKkt8SYjfIkHXo1jV4HcIfWRYqW9LCJn0kk368xNx1qyTksqXbAQVFfUa4mM70yS qkw2lUJIzetJUKzVNXJFfn6y4jZvkini0N7B8xvjiXi2S8eI5zkbUp2JZsfdGM9kCwXdHM8Eoccl sqQ41mwCjbd0n7AMGbyuM54m4yQ5GcmklM4V6kUyIxkxThKJyJwkuRkVY/j2y9ooIC2diUSXQ2Ym qS1kMTIWCUmN7MzYZ+SLq2JpV6hUuG5CctMTS7ylQPZk3aa2ZHxdp0uJbnYaXSmZSQp1lmdkN6Sc LjeWRsStKWoEyeSuTtEUHYlYk2vlqauCvdMR7TR+kl9YKhuWoG1a4q1z0RTpeEeWaEuRaVhiBLcQ +SKiTBdC31g1ztkQp8CTf0nXprGgbtCBdOWKV2TU6JK9HYl4E5rOz3eC0uHq0tLiShK0vujMSKLQ fhJTpIrMJYxmHVVC0v7JAtKbSSWMTvHrKGlNpSXu3NGeSiPXBKLioWs6M1mvKhjpSv7pGieqxlMf GSOytEvJdZvJugL6SzLOTbstEnwq3RpLxj9s1ERLKpFIbcjMcFrilN1El1UwugAZfRaztTbIX1OW WuJWsKFigERDJTmWdn0RNDuVGbfJqL19nJXz5junr3RbJtfUTKydNn3iZOeUtHNKm1Oyb91Q/cA8 L1Om+V4mDq2aiah5bHOiS9cEvzBVGhmTaud0rXOMdqrKryO+qvSilf/IadP9R06SR5KJaf+JyLZp rdZtoiCQmy0XEeFJzfZVn9/kdKbTci1H+yErWpl0qrmzqZtYTa+pq/FjNVliJdJqiVNLbd75Gjmv rJPqxnTcbcFjfq7kPah2UpD8KUOrZjgr2lCBHR2us8CVktUk4bnN8ayXrkh6qp35piXRBTom2j2W 6MrEM0YkyfGpxvXxVGdGKqCcGiVFM55K0EqHmrR2anXxSNbVBCVn6lBqvUgjRpZ0diS0Wnc3xsgd gjLqoLPdlZijRai4XgGVprcbQdRNnhg8o3pywfI5vW7KFN/T9KFVXiVsTjV1mlqEUsjYapRuz9cF Em2db77buKBEtbsx3dqHykesEXutumJRNhpwqC5KUCTN1WU0TvETd2STcXWxrF+NSpWymXTFyIil 40bLIQUev96tMtqlM5GNY2a5XKSqt3N/YMXpx8cSmVRu4o5ZtKCIstZXIvpaW1Qt5g8JQQuGp7kb xeJyRb/3RO1ba8CrWwUtjGqnoZO2nTg4boL6aTLGtDwx0YJaAVNQW92CcjRSqyZnoxpSOxg9quuC r6kjanSDm3Z9s0qKeFJqYbw16dcfm/EzKrjc2eRZBlq9dWrTnLMOq1obXW0D0yyvl9Aq3BZSGXeT TV1OJVq9Vds3aLlUJhNvTLhVFZl4u2nM8EBLIe16I2I2yeVP2t0ukYK02aYONmNzUjSqKlAf3Bmz FpDkk9dOZryGs40aLgWjUjd0G+KEI2WrUcpuNijIOUW8qiJqXFU2G0sR62ldZywhTZ+2sCSp1hqQ Vg1xyp1IkkyWFOvwrQcjU9Q7Vndcan6+T4lovrdMZ4fX9OM13dUhMcTwpXI2i5aTGpmNZDR6SzfR 4wvmeNAwB5k+oyK2PhVvRuprJYBYuFWXJsK06qkc06eiJZbJmt5AM2rLVBmxUmNG8ee0JLredrgp 0YBN5AuVs0IX0SCxXrnyMsJeJ9vERPOMJV876YKfY+1JHfQaFiIkMhVt6vc3oqJqpZ8nJiRyXp6U 2o39gG9RQnIXl1qlmOaaEyJzKRA8vSUdazW1rVZOK4vfUiXx0lqvNjBGKpaFDRMRS2O0klt1q41t yTDKOOp2nLYEO+OiISiWLSgq3XRn01RQyYtKrdFswEYLhdR+FZGNeDAxo8GJm/Za4iiis5HM8e01 f8g/54rVekbACLzRtP3LRKIV8lch36HgssYWjl637toQDK7Sh4xLFc64kcctG1+rLR/peWstHQ0M NWlariZUQzzT7hlKuqOuozq+Nv8miWJGdLQuw7o5oAeR5tGxRGsqTQa167xLuyaLyATti0utuiZo W8zN5ifOZC9dXieRSmV05cPsjyelUdOlRke3uwSRqVQcKY1NsXTayHv5nJVSQNM2qhnpIB8Tz66k QPHAtrjUUQqJ3JQRk0nsa+ox/apsPKiF7VhRMU+zGVNAarlvr1slLrWmKdWsq5d06JK5OWVjWpFT 0LXvnNJue3BdTqbNPsvJoIFQi63pWLMWyIp0XCTeJd0bGxOjAAv40Qb19sXSjrLodheVE09gOpgm Tbc6Ul6QVHtHVlurYlegPfTz024iJhaKE7djEk1uqGUMMtroYglT2xIZuUXMwXjQ6zZ1JiIYqUCL ClYEvyCIYqcFbE611zeJ7bQihaaYn4i1atuKiLdgFGlhIf2eZIZ0w2Jp+eKx8XSRwKXHKQF7Hcfe SXCDjBvEjW4xZqXtq1J4af0oy1QAlJfo1Q2xtO61vF+i7cxUO8tSWXeGKdy6tmfFVvC0rh5aSVkl mu5MuEaLBJU/rEXyMybTZkdlOhIpkoic2kWZhOwgW1H9Wh90A0nW+FTL+Eapflgx6VRna1sh21PM T2sPoG/Cd4k4M1WR3rw2b3StN5XCFis30Ywklkrd9ptumoMZvg5CQ8kDVjXo1q1+ddJLmgxK2Orl VQPTjBS9c3xtham03EWG7XCQvqqoX60DNmWjwV23rLN9u4IudKONbP3qXoSXexNhSVmX8WgzxGPK pO44BTpkfSwhHU0MGTeWtsM+MWMAoMs9Zd3lJ90aLmhzN9Zuxnz8uAVlSSp5SuuloHyYvqk0BV4a vD5L8Uanwq8n3kCWLlS0iV3Sp/bGp7jP+F/iJlvF1Kbmi9rwRGOrthUAhkt4gJ6M6EqkYsSPZrHJ G6oKVRFrLHn9B91N95tfbFqqp2iFVttq6+IdHs/LxNZrm7/dJLUza4PVTfVGaT24KyaButKZGWe1 E9fbdQUlwugzXa9EHNZe0nF25utYSjpT7ZIXUt19qWgZBD1L08za1M7UHVf9LBNVPVwWo5dsLIpQ fypk01foABNubL3oPisY79WCWEVaBwStkSmRng3rnXlyDpdZhKatn1iCgtXc5ekw14ywHbNofoMz J4ZSyriJCnmdYbrq6zqJoW2WMy59OXkf4o0W6FHl6kg1kxKI+Kq9O5eZfqVYrJ5tOy4Y79uQ0sVd myqk1evQSV0xnUt5K0GUrFGTypgy7TnnDM3bjnPOwIcegvA6mAkZKeqSEaOqioW24LdJt7zN3a4x BVslg9HkZpeOktusTRk7QhzUVq+K+f3EUIe1w77vspYzqevZSJTXA7LjWLpi6AEASa4Z62pKaIEF 702c8IuT6tDbr8gFXWLFYHATdgDYVBdtmIpmSMZtJ1KkahSXDL/53Uv9QN3y0vGXQc3OjHUwcpEh uqTJUiOfbGQcOzcHTeHWiiXaua+uqK2prqueWLArYjKy07xesh6r6RDoKFQ0JWKZYqNIZlyIq3Q0 Q84zpJdSOa3KIVWzcu9chfX0kYpy64PyacvDzIpy7ODKwGHWrJoq8am91lZJ19lYYauT8WyDaFGx xGYW8TAv2Zx/eWUhWy7kBWMy7EXCyUgXOT+kFWJ3JFvzL6yKt7tErr0jk39tUXPCzXFttmIPO0+s Q3JeMCtdLw/Dl+nr5F+YFrrNND4zyydMwOzKaF1R6UyZFPgkBM9PcU/1q08v7GliXeAp6GqRFNf6 t5cnVRXqoUT9TNbPyWilaK84kYfVTgl8hjVo956REg25m6YxmFXTWFsbEnrYPeScSZhiStERVymN B4fcTGH0PMcSG2JdmdUZd86qhpkhd23j4Dw36tyMhoj5ZcPLbe+qZ+L48vY9SCTy762SS4GAw5cD 2ep7C4Yc3C5lKc9L9zc7H/1oUC6co5yaIDQtFjpAS2WgGnuifnUkHQWuWZlGpLQiL4v9UCL+/EIT XPalVTgME9OI3PI95oQUeUqBAHKLrvjYVKHZZDRauIoHCs2v5PQ2XL8QTkGCvuqZa28MXw31AXK8 2KcdnKeDgmfmaIcqY4vO9Xoj3tWZ3XqfE+qFhO7YVLGpwms76pwGa/9kKkIVyLnMdHhtx3zVytXz /Hchtlk2vaOWGIVEdznN+CdVTBsXc+VbGtJqZ1G1W+1IVetyjK52RBwYBl3G0ojpm6LvjDHUXWv5 ++MjMR1oNpWqrgjX6B5ENZQTOiNFOkhcDxf5wUtfQtr5eLJAD1kPXfkvHLxugZlGUL96nLbq3HSe TKqd40NRm1+/pGG74maSuSMxq64IKbkeSMrr7u5yYioaMdNR3SER5Svt95aUGXMQocrbXNsxJXl1 403/TJuMOuCgz2z7U1JmvblOdkRghhiDblCvxIvuttq+Q6hy2GeZAR4bVCx3KG4HIuXq29t1p0+/ vuyQDmazeY3qmH53+H2GecdXXTGnYAP03iVOXp15rzNa4hslwsnmYCAhocMqEDxBW0vbjIsbjxLH xq6sGSO2Oicvh/0A4pFbbfKNfIJiZsedbNEyRg19HzNY7yySgQxJQza21h8VaXSzG6T79GE3ndLJ yXm0KLC89rUHsmq3N2iBFXgXI3GMRfoNNumF29gePNEm1+v32heqWhi5o7/mhVRQ6PSDM05lZ1Le GOJmhFNVNErdZkjYux0q2ZEMybdNZbag9i2PrbEDEn6F3B45hN/iWnmExi66tJyaggkD1c7yrAzP eCNq+oW6NKXhMRMrtIiF04Psoyp/AFmXY0d1m2++3/ch0wjLyfQ4y3qa9vcru0JqEV0pIUtUxgWj fP7giFX6udHzB5D0dX9Yqsm83xpnLAI9CCkvJrxxJ/s2w+ZAE717kYYe+JLwls+V5k+Pf2XsyMKk giMLDeF34dZjMLIQS+iCIH3I0CDD6ZHRo8rCAw8NS7RVKwZvw5LqwiMDVUHPLlZw3KDQ3XbYoOC9 wZCCvdPvQx9VE7oB15bcB3g9/5C3eDAYEPgLDSuEvHZEBhv0KEm+v4m+P3rimZkVtjvgPcY5/HDO QvdJPy50w8GzaqpMT8HGJl+bmVTqhxW8HuqdhwY0ZwZBFh0KCIVMcue6rXLZClHfHHIKx6FogAWH HbzAbAaFA/JzsspJNa5xm7JzEqmmtStdXR2aXJGm6cIWKGamCxvkYcFBpkgnueArxZmh6OQoQ2+A JEeqoWcW6vHZEQw8hAclvGtBVzqn9xf0pjc5rrzhtP4LenRmGcva3hB9arhDlfvYpgK9yGJPLuaX h0v7FH72eyeqJ8/fFBJuodGto6JjHlEvfihmCKFARKp8MekiLFZkg18gQ2U737y0Yw4Fe+zl5SKz SBB5Hfi86AQy6bl3MzJUWHxV3YZX6K5wQS4yrBS+UuWUlweVMDTmIkHkZ0QkkEJZSXhRZwksGLvh rqKjVhva4ljNlQfLvK94ps1tztMEOdq8iD4vL6TRC+v0nGKTb+4eFRVbEV+5Y1/F9cp767Kw6VO/ urhm625ALRzbPNVnXXdA/YW1X1A/ulcTQV3qgd7zHhRReJEnda/ugof1RNX52mmXUy5F7+5OZYhh cnBkjHRHU1BkhLLniSgaQCE9peP/HsPsPdFgm8JjqJMiY6iFJZs7WCHjRqbnot9JFxif0Z2FtCvT XLIFxmi8LkSlmSwXGSuy/ThvzMhNdHkdt0LCyo3anB2NWs+Hj1xvhnjukED4HXtO9Ap3xEMxTjp+ r7V4dIuE0vsUjHPa48nOjFNrXpVfbM8u0cObep5Apz/U1hJrsm+g9bwMPUNU3L2Mq7GpMfMr7EQc Pc/G65dK51IP9RSIiR5QM0sj/Wm3RUYvgu589zIv0FXdTnkXCGEHSouzyM50073dZCpX3HpahOSJ ltY4x61urQ6mg/Ad7hR702ZCM91kAGFDSketmJC1gLvpy8s6Fn+hk53oEvhvTcVkvYCekeNNDfSX OnmT1+uDSS1mQo6ea2fmrOQt1zBTEIKZtqm05EDKrAyVO2TVYrB4yayC0UXV3YgtRQlJE4GsXhDi r5WxWVCwWx9MdzEB2EFSm6t5U0vGGRXVltqgi7OZL2YnD+iQOjOumeuEFzPhRS8Uc6JL9WLNqQ5v bo+Wph208Mc9xLHQ+i1d77xZ9TOKJytXHPblR2h5cId9fdAwd4UTy5qVglLrMplUU1wXESvx6FQr EXYq44ZCHmdGo9obvcmf/vhQZ8ZMNMuLXPhmPWyVlfG/Rrse1c5lz0t+S2fSTL3JelPyE6lWvXYi lE2ZcUbUehjermUO5tvbuUt6RXqwjslObKWK1ErYtfalgiwYWuUV9baUFAsvv/RSF4mhNz09N47U G5noWjtDaqWf7f4sqWzKywvJiu3MAl0zZN3JdmT/OL0k0mhnPYGx4G12DM6ubU7qCVmyyCVnJa43 U89MMY5J+iv1NKLM2nhHlX6KXsHkFpqbZUc1W9KppD8lMTSjr1rLra6I3OzM5/dBfu5GMy/X6Ga7 aKCIhvBEl+lstIvn4rbhi0hKe2niJB1PGc00Q1R4TDScng9qH0eyZIJPwX6OHV1u8qaUyqxGSUil 0VJkzhoz7aQpRl3x5oJRhcabBU14/WSVVjt51SeySMgs+PEumdfewYsYb4mafu9ka090knruNL4c lexPp9Ph2BVz+iFGYnoxmsyDN68fZUqimMUZbcjJa864bbLtZNW8hYqeUVgVsvMiy1cqZao2Uq7q rvnTOyvobODmFslbeZkvUzqbm/0VQbQJ7gbzIk8vCYq8cqTBamqjKMc/bHSfN9bvGkszhvzMVOGM TZZujbzNMDKkJ27XUnVzh3QhNuhZipWRpZLeKiPHLAaUtbhGfeau1K3ypdweS6910/QPtlPKeSPS vZC2/6Y55y1NvmluvC6fs/I93/9qbeF40yB9hSFvoe1mC55+KfaSoiFnimzuRFc0eciCoYTqtWIF qoCdg6nlmTMTUht6emUsUmuMB5tXhNog36YgkDbJTlk41eraWbOeDdzk+kUsiIKXlJzHequIQgZD sDSsUIshCzmiu5LYybNe3S4+/TVnsbx52WSLb3hadFRVm7mjIWPEZEihZqlTe7ZC8SqAbz7mJ8dY kjq91qgsZtJJxllDQgz3UEwi6tHM/xnneDt54KfNTAMXLRHPayR1BRXD0EyJEe9mgbG3mjAUEd8I lZrj6dvo4kqdem/hib+SL3isVwaavIn59qGR50TVco7Uo83FqXYBu78jil64avuu6RTtXbtuCDOZ zrheTJebfn/C8UyvZBtDUQzc0OR6bf41+uupjXrMitXmNaUZv9Wv1B0g/Zw6WepPYRQLJ5uz9UBo RYaefq1LoNzlXCZSCrZEWet2yLwN02wGbzW96mMDdXN2SCGCi+atml9dsdLbrMBb19HlenO7c/Yx kBV5trDZQRyZ2yFLi1vdpGyXNC40idvvwGk9GrzfpBzYfTe6HNMa6Lywpk1GTwfq5HLCy8/oe1FC N3HTBluzflft68tUo5md6qlMXb66pLw5oWUa0gX0jT/zzj70stgUS7HgRT12ZnIWqBQQQL6BV12x 3Cg2UwTaRLLWxolE0SiywoHa5Rx6jaZMfLeaO7Y+Fk/EjFyDtS2VfgzXZ/wVLlUV+QtNzC0iEVmq o+2peDsBpr3aIOtDdf6JXSbrjfRaFG3OVcS9RitYUOPG9SOM9RxNTEp39vXsIaKe1btn6DkUsuCM ZMX0WqbmWDY2zknlBGFmItDtlxUzlVm/gRaLIyvz+EPLAAuVIG8pSZN0ue1NabMhQ6d9ijy4aqbX glmvulrrFiknqUHpscNAqawXYDwp6eO+8dqmjTkJbF3Zh0CvyZFYd7hpLXcEQjPs7T02IyzpwjVL T8S0doOu2HoXEr0ec2KdboErPL1pV09Kx863QI0RnjABImt7t+vfPcPkLtnfasYM066duaeT3R5K bEs868nK3Jxj7epnVVc0BGuvEijLhDy2RSRnt0awyiHICyrzOK9uyI5hktRESlRxa8qbekbetxuV 6q8iyaYCU1ZHqkiqzchGQma5inEg2zGIm00/9RTjLJGynYlFoQfYKFlbRB6na6L4t1NNbHuZjdg/ ofklMnoiRa+y3a2i8x23WmmDGyj2rIzwNOuNW+SBdCbb/fAkQbLTgG9/eIs5V66as6K6YpEje6dl JfntXY7eVc2Yj6HNIOzwJBlrxk3ssIG1OryHaKllbI2RMQI9aBc0Pmb4zshAXu07ae/dPsbE8rQd qEhaTYCAMmYpuR90gWcnTc9DomA7DOTFQms5LjJSd3y7199JTqYj2V2P9Go6XYgyqc4k7YC30Eqr 9lRaWzZIJrUh2LhC53JmRgW9gJRZEZw1e1TUGdtonN04RJSLGQJ1vEXIMW9Vsi1rcbMwzY7kNpv9 S7o8qaVtUdSWTJ7MVnmrgiNznewQreuP8y1aIeojEZ79JDOO0kGkjCFBqZChEbvRjdZB2pzWCkP2 OUhTwbtkmMMb27QGn2j3tcnUhoTbbPaOs7pEsrBa9xa05PzVeTprvX0ATF/NJpRIN3d64omnqfHY iLGmNCaAaH1SksTal2rVEZOuaLLZJD3TKd2BIH+kWVsjIwVpT6+1xzdKzClPZmF4xttgKj+LzL4X 3gikpxc3yLiFK7sP6k1zPM9iFuhNa8Ta0uMa7almb48yPztzMzqjB6+dWIvUWxm2sXvImNdLun/k Vz5doQqWiJAOafLX6iW6bMGQhbreVF5tgGsNZodivYZI9j3ws0Pbf0W0kXnTnkwFggmt+vZkZKzs 3K3rAlPWPksv/Gu220z5usrXU56FEuovaRUTUVumfYiFZW9zXNfdZNeGWFd4zNsOogYlyDMxdf5Q MjM6LVJwRDymQTHR9QefxGDQKjbmrFiyJLpKN7TpnTxfNoGKBIp9odVa0eLorWa2LVqTnhXYKLVM stlmuy4c9UkzITjZpa0M3fIGme1ZzWnXbjXY6JXFsO4zDZY2CexLmVDX+31qv8xLCtdf6N8emoJa 6GVSw5LqQi+okaksNBErYZXXFCAEY6NEut2Tp9ZOnDQ1tDeZ7J0nw28569J1V1HvKegE9r0Z0Kar iFZI25hJXtv+YLCIWts1Tf4FsXZs6r3h99As7Xq9qDrftgre4aX9NYR6FMRURpla3pDxtkxpl8mz Vp9kY0GuhXtHEXsw0yvjKWoH2VLndf6yshNYtqnNr6pGDYV8eG+w9WBdsDYjnrWT/PVgYc5UXa36 zYCjGVEzr8QyspGalDpRHTyJgld50vq4bZny+lh+xIPSHuy0JO3jjIqLF4WH57p/Ayg7aVT3bD+T vB6fme0swjWb3Jp3uradfK9gpfBdYndTkw3J5J5Gl7plh7pDY65xOyoV11un6jXa8YzX3oRsvEIN nKmaYlFmgpZMGzutsgumtzCHbk3QIU2kMlldi4wyjHVmU3qzYWM4ZVMdBbZHsb3veFZ3s5pk/0u9 NKdAhqM9RapNUjxjWVt00RNo6QK+vapsDZ62eHOzm/QqYTtnZqvDwkPcFMZOvQsCfRW7FWGlVtcu veFUWns17bKElrvavMoOIpout2d+0RRmwl073TLoBr3dGCGB1wSWQDaY8qDHqf3Rn5A/09U1+xDE m2Tqm6vrTnjxgO70u8n18UysVRLovWup1ApTXj7lZEVR+evREDF/q3J0Q2gnAvuOxQw1+KMe/mo/ O0s/5eTuRdUeN+MD4WGG0Di0UVDGAu3UHufPm1P1Pj7EbHMRfoybTqf0tj4UN63Ks6lUQkvXmGLB 3H9pRGU0wZvmVVURD41RReKo7VApA24yo4uwDA5Zsz4h9qveesd21XTPW/to7NTDES26hvkNsPfG wzSTBfJLv0pOWKmEti9s0RoTDyvrV3ivfo095jci+l1O9BVRgTKUjjdLsUt1ZgoMNIi+0rpDimqF nWLpVcDIMFtFva6Edhuj8OiHaPdYXF5iVjbE2vU2QVZN6vEOmTwTVa02ruEc1m+ejFUSNKjdTaLR O3TaEm4MgEpp2Fx/yNK8RhanKhrfrmJxMSL1B2yCdIU3M7FTJ4zdbUYZg16PjMzZoVZ/a4smveVK mkBIYpMWhe9Nv+JBaKITzIhDKFsKx7JIxtgRvIrweKdn3Zm1Rf7GUZFYBi8ddBdAdqqWV87appS6 UkRU/jMCY5y4zzPb0Dq1M5z6zmbKmy7pdTWU+RZ5R8+D6mrsij/Z2nFX3wKjvLx8llNTxJd9RVhe wFPBl965/rrbEgOftZEQQxOe9SzLvEdGJ+paL9EwvKUy5eUFggjPE/Wve/cX2TfDepJfUgj8RTbQ 8AMK/OTvpeF7mhJ48ZeN5Ec2vHtGwauFZqNHPXW3eUbYX/4GGt7jJgU+wu9VQ54CP7U92RcjmhI9 77lHO2T4wgtdD03LLi90PTrDN1qIg3nVBebdBiH5k84LTJH2JZw/jzg0Z3n7d8/QT6+r6TaI7d5D I5qkHdpIw4YT8RmZkx88K5Bf4aBCM7KL76fh5Vi3KwAiYeQWZhvA9uyqkZFdNcrtEanYhbfYsP7q wr6KbLXhe9wVNtzY8SWUvuh9BZG7zMJeL7wErZC0QrEkinoXBv/9ubZaM1J0OYssGfVerYuX2ilm ZoZZAltgfvmGYDglmEToWfXmvZuZL+jNfcuZZmDu9/rQMnopJt6ksZNmTdNPtuM+tcYKwGaYY0d3 JdpTa2T3TM9qCBkKnlXuPTLnre8GO4iqRySdSp5WVfBx4+gwxLyRfdmmVP+KT0J/t9npDpWTasZS e/1tCey7RjFQtdRqJ9XUBFf9XQX1YyYeVu3bQHUznPnH1Ju0TAxbQOuxxHXXy7yD+s+zgUJWyXvY QNEQ+2yg97CBJgdX+2ygD9QG8o2Qf7YN1P3NfdbPrmn9TOyp9TPxP8j68fVCoYZih+0jz8fkYqsC iy0yDlX+Hi2/7f4pm97DUNvFrLTasZPGTh5bWVk7dnLVmMpl42urqmbVTho7xfxtLSozqWqZt1An WCFmXsDYMa+8edF5lt7qjDf1XAaAJYAcm0+G77gY2+gcSdWo3T4jkGhXThkzZTopmFQXMQYnT9o+ a3DypF6ag1Oqpx6WY+HWEhXfxA0SXtt7Y9eks7ZuKgmdOnVKOKHTp25fQqdP7S6hddOKJrS2pnqa pFT1Hf9eR5lSE+B2+Br8BJ6A5+FFKOmv1Gw4Ga6Ba2G3gUoNgRvhJvjZIKWegnvKlfouTN5NqRlw 1O5KHQ0nwIlwEpwMp0AMGuEj8FHYBGfCx+CLcDXcCF+Fp+Dn8Cr8EV6D1+ENWDNYqbVwDnwSPgXn wqfhS3A93AK3ws/gKfgDvAp/hNfgddhIye6Ci6SEv/PXN7e+qd586U21Rb0A8nlOPa0ef1rJ52H5 7zntcr9xudu4bOH/O4yLd+xZOuisfmvk950HDCpZPajEnG/IOX9bRc835Zwr/7zcnPDXgCmDzjp1 0FmqH98Dytf0U396TQ1qX1helgE1ZPKgs44ZM2DO4uGqo03/OvtAXOS0H9/m75FKzfXy/xTIwFdt OXgInrTl4AVbFl7LKQ+ngAuvDUCG8HXKwh6UgxdhC/w9XM629exka/jkpaInz4RPfl705NGiJ98v euWB8Ml9Ra/05uTe8IkqOQgoCPwbNERVPDSw5OYBJckyNWZ0CZWn3+h+FQ/1V9YhNrqf5NTezUMk LwfL5VJ9+fBhas9zDh92GsRGl4ofrshfu8tfJdrP7kPtjbHRJcZHifxVcoBSw5T9nfdIXvUd/wFH WRmlr0Tq6WaK29VwyB5KHQqfhoF7UiZgjyFKnQZfgLvgD7BQft0dvgI/g5fhFZi+t1JJuAPuhMfh CZi5Dzoe7oKqfXPK2jvhk8iV3pz8teiVP/+TTorHrYf3FE9Cb9LjHdJsH652nz/c6pyDtN5RI6W9 uxgugUvhMngWnoO/wFuwDd6Bv0EJZaMURsBIOBBGwUFQD/NhFZwEX4SvyN+UoxikUDgdcBt8BR6E 78OBIwgDPgQnQjsk4Xq4CdJEthM+C5+DUgcdBiPhQBgFB4EDf4OSg5XaFw6AcTABmqEVrobr4IhD laqEJbAU1kEafg2/gd1Ho2ZhCFTCW28o+bxivl6U/35tP89GPj9Xj3HtIc+DnD6mHvQ/9+jcqFCD zmpaWKqa27a9uPBwWu8SdcNr1lb4XT+vra8oGXRW2cIS1b+tYdCSm4OzlZz1Wzim1LMAzH1r+0Vt hldL820Gc2Wdf0Utkvp4PGyG0UOpz7B5GHLYD9tqf66RP7fDAPLhJLgZ2jActh2IzTZKqSnkRyM0 IffDkOsyOA2+AQ/Dr+FdGHWIUm+HC+QHeBKxIXpz0sPnvBI++V3Rk/8Ln/w2fPLijp7Yo0RqtRhn /Uytpobv4dd3MSzaSkoeLx2w5zmPl54GIV1wgORLPbTBWbAZvg6PwMtQSl0YB8fBergUvg1bDg3q xtGwGtbCJ+DK0e+DJt/FTu7e0RPvmDtczRldMu+hj0tWjaQmF/L0Tzmk1AyttPl1NzwPb8DQw5Ra CW9A2eFKrYAL4XLYfAT6GxZUouchXYUegDPh0jH0teBWeGYs/St4DaaPU2oxHAsb4Hx4CwaMx/KF EZCGC6B/NXodzoMrYcYEdDTcD0/BVngHDqihHwJL4WO19PvgPLgVfgz/Dc/B8zB0MvrqdT6vbNvC Rz37Mz4PB//u4/Os/dz9Nfnwx61X3aou4WOPqC7eP3I2Z/EwtXwxdQQGh0/UEN/fIvzR6QqFIy7B 9XrOTuH6vhGXmsX7K7kr6i8aTn2kbVgcOTsscnZM5EyXvele3v8S/mzzfiJ8J1xSOnt2UqMKHJHy ftjOLO+7Ts2LxOSYnRmT/hNtXT8LroP74CUYQF0fa+t+b8pCb04+4GMXzf+dWicGSf4mrH6/2Or4 K+Fr8AN4Efqj7wfBobASzjkip0z0sIBkdsaJOaSt20Xzf/HOjEmF5OW5cB585gjTvi+w7bq054/C sWNNez7dtt/FraTIUN5fwid39uIkXvSk+D1KLRzqWbeBjOt3am4P3VViQh+hf5mRjjJ1YrDk5yBr f/W39pbYWh+zttTd8FfYv06pqbC6rru630OtELkSqa3rwiepXpzkHOGeUSQfFvWVCDkGS36ug0/B FXA73A9Pw6ugJio1DPaDpZCAa+EheA5egzGT0A3QDC6cDTfDw/CXScb+/nfrD+6Uk/f3kLqxv+RN LayCGHwSzodb4TH4FZRMUWogVMEyaIBOuATumpJTnXe4o7zzTz7QI88Saf+vY+e/510f1DFE8j+c t5Kfs6ZSz+FD05T6LLwC6elKvQmPHqnUC/AWdM1S6iIYfhRlCD53tFI3wSuzlWo9Rqk2aJnD39Bv rlJlcBNpvRlKFtDHgDK6yeUwCkbDufBZuBSugpJjlSqFETASDoRRcBA8tUSpn8ObS9EzkDlOqWvg QShpkD7/K2rLs+rnj/38Rz9X93/r/m/dccsdt6gb1DV8blBX+Z/L1IWX8d8NfM5T58k71EEZsOOq blnxd6/6vevvXlPe+9egnz5ncG4/XVyGRPrp0evRnvuiyNm4weGzA+WaHkEuUc1tw7ce2xLt1Qej y+e/vfBTwdkeWxYeHvjU5W6K5PcjUEZ+V0wN8v4CuA+ehlLy/0BYDg3TTLnojQ3w71eZe3HsWj2R CsnLTlvPb4bvwZO2zu9JfV823dT93vT3ip/0sMC8v0dE6lKj3vOOD+qIxOTAnZn/5ZK318O9Vr/v O0Op8bACToRNcDncCw/BVnh9Ru/M/p1yEhy7jtQjMdmpPZEKycs9Zyp1BMRgDVwDT8DLcDjt/ARo hSvhB/DwkcYO+Ak8Zu2B3rQHO/+keLPxTfUBHLonmqv/d2pJ3OsFa8cNt/ab2G6/h7H1lAnst0Ow 2Q6Fk+cpdTV22wPw4PzeVfniPf0dHuUrHpry5lhFe91zdqr+D8dk547/SV5OwA5fDHcsVGryIqXO gPNgK/wBEtjhd8Ot2NxbsLd/C2XLuA/mwYnLlToLfgPVK4wdng3Z4setNPb4Hg09Hjvs4UlvOtG9 CS0ylNnD6T47nIQ/9sxbwek+9uhfGoz2leqaEJ4HhOsIL1+OhGPgrhPR6fA3KD1JqY3QBRfBxXAJ XA5XwKhTsBNg/elK7d9Injcp9XWoaaa9gDVwHdwIs1uVOh7OgLWwHs6E8+ByuAG+At+CB+G/4Sfw MrwGr8OQNqWGwSiogQa4EC6Fy2ALvAzVcfqjMAuWw2q4WsaP33nzHWHrO89v5T9lPr9UT6pHf3Cv uveb936T/9TXblW3Xqeuu/W6K9WVfKvrLlbX9ez96shu3rbOpLcVnC15cvGngrNjI2eLI2dLI2dP 7x4O8yec7af7qC/6fVSv87qX31f1XHanz+r97fdxZ0jefwcuWEUphxEfop2HdScEZWH4yUp9As45 Ocjza+HYU5X68mmUQDiIMrDgdFMWtsJxZ5AXsDym1LPwHPwt9j5U0uInkUraG82wwwH0JtbF5w0V P+lmhLC7eT+iA3Lrv+SJ1N3b4CjqbqbJ1ONLbV2e0Gzqcwy+BY/CCzDQVWocrIIz4Rp4EF6E0hal xsAyWAefg9vhSXi7JSfGkfmfvTnpYWiRaZVv/cec5Bz6fYi1h6RFGCn5MbI10M8b4ILW7opYxEyO mFrVKueI2Lmi5XI9/NOO6BvXXSYmS3dmTKQs9Je8vt22tdLGRkz5DeGTOtXrY5eZ7zJnuNrlSuNO jUk/yfP9sJnqrD21ztpSP4RXYBB2Ux18CD4CN8Tfh7GfD7BH383RNxMt/xgsdvH1Nl9/A1vgt/AH GLxWqT3BgUNhbbtSSbgJboW5HUqdDM2Qgg/D2XABXAW3wB1wDzwEj8MT8Af4M7wJ+9JzPwAOgUlw PFwEF8Ml8AK8BOPS2CIwE5ZCA3wJroXr4Dl4AV6E38NuWTq3MAoOhmfgdfmbglgFY6RAbntdvb5N vcJni8zcf+xH6kf3/+h+/lPfvkvdtU1tu2vbl/lgsOFzW8j7jZtvzJnJmfN2pkczMD+oPkFwFl03 EO276HJ3lOT7fTbPX7b5/hr0p/twBCyF9dAFl8D34c0178P4zz/rxBx9878KHxWSl9vgbXgHjqSe nwJdcBVshquhKUE9h0nUexfugZ/C/8LuSfoIcAKcDTfAQ/B/MCCFXQgroRMuTvW4A9WbHtgOn+xw H3AXO4kcMv4Tnf81UvLjTvgF/AOcjkCvf6TjfYhA8e7CP/Pos//zD8n/gZLHX4A7bdssbXJx3d7L DkGf/R89dh37v0zyewT21RRre3Vau+v78DsYgC1VA6ugy9paffb/Dh67kP0v+XmvtZtfsrbzq9AP VX0YHAtZ2AAXwQPwp0yf/bdDxy5k/0le/gW2wV9hBn2kk+Cj8EW4J6fvNBvmdu4kY6a4LRG5Ejkx x64z42LXefcvdaJijM1P2QMkYn33Hf+WR3ScQpVK3s+HBbB0vVLLYB5m3nyYsLHA3jDv70nkFU3f 8U879Psf6v+gkeqgOx6f4Nzx/KyD7xg08BA49PPX9h8Nh93xnqH0Hf/yxyaY+56+uj8GPf7jV7r+ +p3H9vrs2eq/1LG37V4qjkq/jFanq5XKVS1qsqrhM1HVqmlqOt+T1U57+BT+32kPF3bKw6fzXafX 6O+Uh9eqSTsv5ZLunVTg5OGTZRXdznr4FD7/eWLfaVVtsprK4ydS2qe+R6B9R9/Rd/QdfUff0Xf0 HX1H3/FPP/ZVjtpNlai42lP1813pJc5+/d1SvgerAWqZSqm0alcxleCamL5D1OkLS8q8zcazcL0q OaOEa9dzR41aiEEcU82EmlStPKFWjVNt+v/cK6u1W639X75XltymPscTD3D+n73zaNWkXY7mM0+7 KbUfcR4wukTPZRih9rnxNbXvjUeq2YfLFbu5+bELR6rli0vVcbB24W/L1BWqVMfxCuJ4eF5M6nQc 63RMvP/z41NXID7yIryScPuN7qejVCJR0jtvt5UQtXElErXa0cRO9vHe28TvAOWtwegcpE5R/XTM TiFm++TFbKKO2UQdJ+9/I4N+RgalURmUEors9O4l/gRVpkM/oWDok3Tok3S43v8m9DITej8/OVVl hN5PDTQpGKbUKtVfh7yqYMiTdciTdZje/7W69PRXux1eZiL9DYIsk/jKtollxLeM0AZ0E+oUHeoU HZ73f60uyQMItX9UFP0Hqik2rrPVQB3qbEItzwt1qg5hICEMiIYwYJAvx7lqkA5hbsEQpukQBhHC wGgIA3eXOHiBqMWqXIeyuGAo03Uo5YQyKBrKIF1udGL29mN0pKqf/ca71/E9WA0jXtINjalO6mmW sFbwdxpa9f8dSM1R8ym3Sa6Gj3HqoNkl6g2+pbZ7MXK5S3Yq3pO8H6RKnx9y/8GyYkAtUf9YTvxL luB7MHkUJ7Q0vh1Vz5OzPCWl7xzCx9vE/uYBKij5w8MlP6FD27skQVh78tQUdet0wgjicLqWTYve 5ukQtZcKbYy/1zkjS/ZBOmNGl1C9zuCMpxzgPcUTUuhpG/XTDinZyNP259lxtVbHPF9fOdToJM90 SFFMNeLXVVXEYJTa29Zz8/A2KvdGFTx9WFj7hJ5cqVbPvl7VllTaXO8iPyR1Cf3MtYQ8QB01puSY MaXT1IfwWV8yDZ976fxK8EmpDfhv7u7OwVPUMeTjypIp+hnHcE8zvh3yyCXlkue7qaF+TQ5q8Wh1 Ak+MlYzmvkFotHZdVmIqwxPkLWs/ym8J5VvnO99lfJp06C5Xy9EU/UfrfKC2Ll/cH6H3J+mqLAmd 3HmrvvPsklsJf6BqoJwuUXP8+z+qZK3SBnXEyJKppQ39kmWf6X/TgAcGPjtoW/k+u08YvLiiZY+z 9tw85Km9/7jP7kMPH3bMfqcO79r/kgPuGPHoyJcOLD1olDP94NWHdBz62dG3HPb9w399xNuVQ8fU jl0yTvXsEM0j9WkAsR6g03i9+oKWPVe0FNJI0MQ5SPOe6pgx/k26bRmnjkL215dIHepva0VC+x2k DqDEyC8uDPTKhqpWK/B9V0k1vncvkFOmTSlVI5C97BIzw8p+Bv7LdHuc1WHvq0b69aGhH5riWaln XppM8Z+k0/REyaScNK3g/5TVDe1aEuEEzVBHUCZeKJmhS6HkVjsfV+sOxw54ubreJ5GLSeecxUNU DMapUaJPtCwG590blMZSdZDNhRpO0Z8PKXT5uxziNgFOUeY9/1fha0p7UE/C8/CCMpthv6b0xEbF I9XJcAq48BrK6nX4OmbNHmXmF0y2wOYBSl0Nh+ym1KHwaUBFq7/DHoOVOg2+AHcNNr8Us7BCqbPh K/AzeBlegel7KJWEO+BOeByegJl7UqbhLqgaotTxsBlG72V+LWHz3kr9eh+l1gzlGrXvdhiwn1In wc3QNlypbfsrtekApDFCqUZooswcdqBSy+A0+AY8DL+Gd2HUKKXqoQ3Ogs3wdXgEXoZSBD0OjoP1 cCl8G7bAEAfrBY6G1bAWPgFXwt3wS/gzDD1YqYmwEs462Oyifx+8BAMOUWosrIAEXAgXw+VwJXwN fgAvQv9DKStwKKyEc+BcOA8+A5thwWil0ocRT+y5R+HYI5R6BqZXKrUBBlWZHSr7j1Fqxlil7oeP jVfqVrgb/gr7Vys1FVbDOvgUXAG3w/3wNLxabQraMNgPlkICroWH4Dl4DcZgEE+HZnDhbLgZHoa/ wFAMkFpYBTH4JJxfa3ZQfAx+BSVU6YFQBcugATrhErgLHoGyibS4MGui2WnvArgPnobSSUodCMuh AT4EnfBZu9ve9+BJeAX2nMwzIA3Xw73wJuw7RanxsAJOhE1wOdwLD8FWeB32xBw6AmKwBq6BJ+Bl OJyKOgFa4Ur4ATwMj8JP4DF4AbowZYbPUOpzM4kTbcPvYewswj2Kujeb/IeT66mLxyj1ADwIE+Zg H8Edc5WaPE+pM+A82Ap/gMR88hduXUDZXajUbxeaHcQmwDw48VjKJvwGqpegO5YqlYVr4EE4bhn5 sJx6Dt+BC1aQfzBiJWmBdavIi9WkAYYfTz2Ac2DUCcgMroVjT1TqyydRJ+CgkymrsB62wnEorJdh +alKPQvPwd9g/9OUug2OOp04QRYuha/DhDPQfxCDb8Gj8AIMjFFnYRWcCdfAg/AilDZSJmEZrIPP we3wJLwNI5vQh3A8bIAL4Hb4CbwO+zUrVQcNsA4ugx/CKzAIZV4HH4KPwA1wH/wWXoY/wGvQv4W8 hKWwHrrgEvg+vAnbWsxq33fgyFb0MnTBVbAZroamNuoUTIpTr+Ae+Cn8L+y+BrnACXA23AAPwf/B AMyealgJnXAx3Am/gH/IiiU6qnPhZPgIfAHuhCfgTRhBgzcFjodOuAS+D7+DAUmzmmEVdMF1cC+8 CC/B7+FV6IdBehgcC1nYABfBA/An+Atsg7/CjA70O3wUvthhVkQ9A6/DwevIK5gL82HBOrPCaRnM o/GbDxNoH+vgCmV2vtfHxwVxUf8WLkO2+65BaoRT0o2fFSVGYjkus3vrctB7hax65uf9cDFpL7Eu Ki/t8vt4V6jhTiGXkjyX0jyXfnkuZXku/fNcBuS5DIy4qLwY5rvIXYPyXMq7vctIw0uFypPGTXvk 3mVcJOTd8lx2z3MZnOdSkeeyR57LnnkuQ/Jc9spz2TvPZZ88l33zXIbmuQzLc9kvz2V4nsv+eS4H 5LmMyHMZGXIxeeGVH5WXF2NG5OaFuFSWjnD6aRc5E6b1G+GUaZf9DzTIXcP9u47pc+lz6XP5F3WZ xh9lvovUblPfpW0K1/ehvp8zD+29y3BnaM2BeS6j3oeQPygXow9FGvn6MDPeEJXql/pc+lz6XPpc +lz6XP4lXIIWP9yiBe3gg9N2xEVFXEyvxOvDClE/vzky967eu5hneb1jlfesi47JvauYi/StDspz cfJcDs5zOWS7n9UTFwn50DyX0dsZjpGPN1YgDC8Z4ZRqP9sWGaJ3Hbq4sIs8/bA8l8PzXI54j3By XYbzR6nvouMzO+zn4qWFXEwqpDwXTsWby3rqInGuzHOpynMZk+cyNuRi4iOjIoXjc/Pq3rqYkPsV DXnvE3rvIqkYl+cyPs+lOs9lQp5LTZ5LbZ5LXZ7LxIiLes84G2mIbvGlMTvs57VT3z8X8yzRLYUl f97phVxMjfPG4gTxE2jjQ88wd/W57LIusz+wcPJdenJX7/z07q7e+enJXf+CLtNUeOQk388fWnY9 F6N/vFF9IernJy25+bUDLvkh57v0LuQPzkXt8jHsiYvqk8YH4KJ2MfmoXsXng7tr54bcK5cr5a+I i8J8vKhCqcrR5vcy5XcZZG/WMXZvlll4qVdmJesS4LI6EWLK3LsF5Vq1r1Kj6PjJb7rL73rLbzvL 7/vKb7zK73xKuPJ7b/KbX/K7T/LbP/L7L/IbIPI7ALIXvMzYuMDuBS17g8r+kLJHoOwTJ3uFyX5R smeQt2fMUUpmVitFt07NgXlAcGoBLAQMVEWHSh0LdJEU3RK1HFbAcbBSySxy4gcfguPhBDgJTlZm BiBmrzpNyUJbpc6ARpA0y/OP5s+jMGxPhJMhBh+FM+Ep+CO8DmuQzyfhXPgZvAqvwcZy0geXwrPw FrwDJbspNRJGQelIpQ6Eg0B+t3AkjIKNRPhiuBxkBuM+/bLvXvpx//+S0N89/P/dd+XdagUpXajn cHvrmetgiprEp/i1yfpasc0Wil2TvRCKXROCa5O4Ioua5Wmyk4C5tkrP2PauTdX3yALo8LVa/65p 2lf4miwRr1U1emXARD7Fw6zrJsxp3YQ5KZIGubNOhziZuycWvTa94LXpOo4SdqFr0+yC92LXptv7 vHhO1dKexmdi0Tzydm0ofM1sqlD4Wm5c8penF5d1NB+iso7me1TWxdJgtkAodk12KHjK1leZhSuz aWXm6+ZDtx+ZZSgzCmVWoMz0k9l3YWSmWZ1Z/iAThmfL6Eg/o07ktzHUAJB+stiqMn9jCMgcDZl/ IjNFZG7IYF1HzeJ/ma0h8zNkRobMwZA5FsNB5lHIDIwD4I2Bhgpu/Ck3xUjbLeN7xrdCjKERuJ+0 VZO2CtJ2xhkmPR7NQdrU/iTOgQRkYH8S6UCWRH4Kzocvwt9JaBmJe5DE/VD0HQmcCNNgEayFTXA2 fB7uh0dgG7wDCxDSYvgigvoS7ItADoGn4ffwN9gTAT0Dz0EJghoGp0EGXkJof4WTEVYbtEMHXArX w51wD9wP34ffwZuwG4IeBiNgFMyB5XAatMBaSMLFcBV8jkzZDAeTIeNhIsyEBbAcVsBquAW+CffA TyBNXp0Ln5XyCM0HKtUFZ8Pn4Wq4E16Cv8OgUbQPcAQcDYuhBdbBx+AzcBXcDHfCd+FheApegj/J S+mDKGdwAEyGo+AkaIKPwcVwNXwLHoQnYCv8AxY62AZwCrRCJ5wFF8AVcCN8Ex6E/4Hn4Q14F/Y5 mLhDLRwNK+BESEIaPgKfhWvgVrgHHoH/hTegDNtjD6iCqbAMToA1sBE+C9fAl+Hb8CA8Bs/DVuhH /d0DDoIqmAYzYAWcAK0Qh7NtXb/1UDNTvGG0mS2+yc4Yv+VwM1v8jzCskrJfaWaOL7azx8+Ht2BA lZlJPgIWwOIqM6v8AngaflVlZpiPhEkwDz4NV8LzsGWMmX2+BC6Gy8aamehPwVZ4G+qxvZbC5+Ai eBm2wo+pz7+C5+AN+AfsV03dgclwJDTAaZCC9XA2fA4ug83wZfgmfA9+CL+AF2Ar/An+AeUTqJNw IBwGY2EKzIB50ABtkIFPw2fgargZHoTH4VewBV6Ft2CfGvO+pRJkiHUqzIYlsAwaYS2cCefBjXAn PAQ/hRdgC/wZ/g571ZJuGA+zYCW0wEfgCrgRvgH/Dc/DNjipzvxu/cfhIrgK7oDvwMPwM3gFtkLp RPMb9pUwBmZCBs6HS+EWuA3unWh+1/5JeB62TjS/b08zp8phBBwGR8LRsBROhnVwMdwId8J34Yfw ODwHv4PXYXfs7/0mm99bnwhLYDV0wCa4Fm6De+CH8Cz8Gv4Ef4Mh2O4HwliYPsX8XvdpkIFPwaVw A9wDj8IW2DbF/K7zfnAY1MACWASnQwY+CefCZrgZvgffh5/CL+EleAPK6TfsDqNhGiyGJeBCEj4M n4Ar4Hr4KtwF8v5NVgS8BWvpd6yfblYHXASyQqAW5s8kTjPNaoGb4Bu0dT+Gl2AbnE9H41oYi8E/ Cy6EK+Ezs9Ep8AD8AirpJE2HX8Dv4UjayxNg2RzyCm6hA/VV+AY8AK9BCZ2WR+CX8F06L0/Aydj3 7XAhXAvfgUdhDp2aZfBl+CY8ScfmKRhCx+YgOBIWwf/SPr8Mx9PJOQ1m09FZBHX0syY3mN/aWwpx 6IAz6ACtgQx8GObSpzgZGiEFK4+nrEAjnSMXHoP/gwPoBB4Ih8Es+AI2zqVwPh2mC+FROk2PQSu2 wkfhk3AxXAffgFdAOpFDYDRMhqVwKnTBuXAp3ArfhkfhF/B7eAsG0xk7CCZBPRwPLfBh+ARcAdfB N+ER+BX8Gfo1YTvBYTAVzoC1cCacB5fDDfAteBD+B16Gd2BIM20+yO+SzYLj4CRIwSa4EDbDXfBN uA8ehy3wOpS56DCohlmwHE6DLjgXroYvw73wKPwG3oQS+sa1MAeOhyR8DD4vPXq4Db4MD8CP4Wl4 Bv4Eg+lPjwIHJsN8OAlaWs1vbn0Svgi/hjdgdJv5TZ612HQfh/PgcrgJ7oZXoYy++b5QCdPhOIjB JjgfvghfgXvhp/AM/HGN+Z2HIWvNb7pMg3lwMqyBM+Fc+BLcBN+Bx+A3sA0GJtClUAUzE+Y3IVJw NlwAV8EtcA88BL+CP8C7sG87er7d/IZEPayG0yADZ8FFcBXcAd+Ae+ExeAH+CKVJ2goYBzNhKZwC G+CT8CW4De6BH8Nz8Cd4FyakeCashgRsggvhCrgFboP74Ecp81sIT8PrsFsH7T+Mgokgv41wArgd 5vduPgWXw03wbXgYnoa/wUHrKGNwFJwDV8Aj8DScmqbMp429PlDJatyRffTRRx99/Fsgh6xLPxou 2Y0WAv5nd6We392sMW8dbNaZXzXYrDX/7mCz3vztwWbN+eoKs+78ggqz9vxbFWb9+TMVZu35UXuY 9efpPcz68muHmDXmR+xl1pn/Yi+zxrx9qFlnftIws9b8jmFmvXn5fmbN+an7mXXnX93PrD1vH27W n5cdYNagf+wAs+a8Cf4f3A0/hkfhedgCJaPwDw4cCnNgPvz/9s4FuqrySsD73uTmQXjcQKWALY0i QpG5hvdDrQkksKiQBJISoUgTIC8m5IYkyMMosUSlozOKUiMjVKQgrZZKAR9duiwKIo4UWR2tOsOM OoOPVaqEyuqgKJlvn//cm5Pk3rw6Oqzl2Vlf7vnPuXv/55z7n//evc9/9r8UlsE6uB0egm3wBDwN R+BVOAkfq43v8G0IARgFuTAXVsFN0AD/DM/Ac/AefAgjUvAeIR0yIB/mQQUsh9vhJ7AFtsIz8Bwc h/+Es3AOBlzCL2qYAJPhB5APt8F62A6PwAE4BCfhY+hxKb/wQIfdjYE8mAvLoQYehC3wG9gHh+Bl OAEfQOIQPCsYCsMhD/I7EeXQZ+OPXm6ej88a1hzdCEU1QtGMUBRDoxXpdpTipSvMs/K/g8/gc7g4 wC8dmAiTIR/mQxXUwHq4EzbBg/A47IHn4QD8G/wHnILT4L2SumEADIJsmA1BqIJtsB1ehiPwNrwL n8BfYWQqbQGuhmuhBMrgNrgDHoVd8AochU/hHAwcxbHAeJik0QJY6Igq3A0bYBfshtfgTUd0Ye5o fuXBaqiFBtgET8LT8Cr8ARLG8LlDX7gIgrAcNsBGeAEOwnF4G3xjad9wCVwG+TAPVkIt3A0b4FHY Bc/DAfgjvAUfwSnoN45f4TAbcuFGWA07YCc8DwfhLHwGA8Zz/mE0jIM8uN4RPbgV1sFmeAiehxcd UYQz8FfoN4HjhJFwJRRBGQShCrbBdngd3oCP4TSMwPMPwFiYAEuhHH4GDzuiA62jAhoNuP8q4+1v hT14+E+AjiLdMsXkCpg11eQL2JthcgZMzDR5AxZnmlwBz0wz+QIem25yA9RfZ/IDnLjO5Ai4GsZl 4VFkmVwATbAyj7ryzDP+Z+eb5/yH2M/6X2c/77/afub/lP3cf5797P9J+/n/uTeYZ/qL4Wl4Bo7A UfhveB8S1YOGAIyCuTAP6mAdPAzb4SC8BCfgA4jFg46HkXAl5EAuVMONsAE2wuOwB16DN+BzaILB eNGXwBTIhHmwAFbDTXAP3Ae7F5tZwI/Bv8IZ+B8YhBf9LRgPk2AuXA8rYBVsggfhZTgCH8Ep6IkX 3QfGwySYDwugDtbBTvglHISX4DR8AvF40D3guzASsmEOrIFauB82wYtwuNjkHPDiRV8LU+BHsAhu hroSk2tgKTxbZma/PAZ/gA/gT9BLPWQYDeNgPtwA9XAH7IBfwGF4BT6Ek5CAh5wEqTAG8iAfVsIa +Ck8AHvhSXgT/h00sV4MXApDYRrMgBugAG6GtbARGmAfPAWvwRtwFs7BYLzkFJgM18B8WACroRYa YBO8BP8CJ+Ej6IGH3AvGwoQKM5PjfLgFboUdsBNegBfhFJwGHx5yAgyDETALcmAVrIGN0AAH4FDQ 5EIQPONrIA0WQiGsrTQzx26BrfA7eAGOw7uVZuTBWRiK5zx8udNrHuPi4uJygdPU9A3REQPFVr41 kzOtmv+lVha/Minhb4BMlcmyQKbLCtZoLsQFMktyJJM1uqTjJCbIWFkkATtT4ldrr9S2l2G9d0U4 p1u1pFg6S0Qz5RWxpsbOpFjNu9uzuEDS+TqotHIZLuZdqqf5KVOoo9DKvKj7qds0V101FLN2geSL 5phcYulrzsmgNa5E8/PdaGWl01x61WhrKcXSSml1vJrdcIl7/r7U8+e2lwvr+v2q7ZWE14fsXSzn mpqaDs063tDUp/WfyPkmW9ps80hjv1d9QyUxVrNgxvDLzydx9KoJ1risI5mV/u/1rv2z2mgpHnkr 7tkBZltbm33HHh0YTW/qvA8vHltwfkokvUUL5w7pI4k9I+ndO+u9IcPXXvpuWz2//HDw3cOj1Zd5 xYQR2IyNtO39aVtSPVHqOzr3ulHlP7zrVKT9PN2rbvwtc67eFWnbzEm9Jp+/v8edkbaNm/rzydH2 ZczopenRjuHha3879c/vvVAV6dirva9MjWZzXcagzGg2/5J8aka0bXt9Pb8fbVva+Pev/6MMPhTp +NbXfFIYTW/B2gGLom07XJG0ONq2a3JKaqOd69B72sgAvOF6kWS4yKQLj1vIckG9ybIesHU8MR1q ioQ1Y2zNkK6vC7o+WzdA/WH9+M7rxzv0A+xJs43ETttIbGUjwNXusJPUWTtJEewExNfCVq9O2uoV xVaAXqiFPWfLaMden3bsBTiLLW0md8pmcgc2A5Ig7YlHRoTqbbvRqne3J7k+57xV725tqbs9BZQ9 YY1o7TTNm1y//wtLL82LXpq3gHLn2ukxdFON7jHVPYZu6hedb6cFMcn1Wz+39Ati0C+IKaDctXba iA2/sdGoNhqx4f+86+20Lja5vu6cZacuFjt1sQWUu9dO/b7k+sbPLFt+H7b8vgLK3W+nW7FXYOxt VXtbsVfw2d/WTlPjkuuPfWrZTI3DZmpcAeXOttNvSluJseyW0g4fON/cY5bSDh84HxyO0b+7wFST 2lHN/n6MzAbLREVj+9deZBPmW0IlUuX9wleQrRm+grRykRyYDQvBPg6t/pt1bU0lhRuJbSrcSNSU SRtumQh2YKIyIWyiMgETlQltTsXOxvZNpCWFTaQlaXeSZEx4MOExJp7qwIS/d9iEv7dePb27fCDv +MMm3vFj4h1/lw9kd7+wid39tD/t1+UDqesfNlHXX7uU/l0+kJyBYRM5AzGRMzDCgejbu3lpeK03 tm3XHag2/wDq+nXV9gRGMPHldggx3Vf9v+8IOlFpjyiqbh8SzYTbhzSb6FQf8v/Srl3VL1v1O91X 1Yddz9vTfVQ+vjNe24YGH5xmNDDiLGsgwVnW4IizrAEfZ1mdfWdZHXxnWQMMzrIGfpxlDS45yxoE cJY1COEsazDDWdagj7OsARRnWYNQzrIGl5xlDfA4y+fs8xUSDTw4yxr0cZY1EOIsa+DHWdaAlbOs QRxnWQNvzrLG52r5rHTSJKtTSJMWUsrKJH/zRx/lW7npK5MWn2aXJLJuX7n3oooTMZIY67PikYmx kZbbatV8e9t/dVWLfUibVrhKsopSUyfLyrKK6spgsFx0ldKeeGIldrNc74kZpi62R/7UI5iwxFo6 HP5PayiqqSmqatdQNySj2OxchL7elb9B3M/86yeeOo/1ILeyv6Faaj21nhT7JIdevaFvKM1CURcj CZKmvZf6IPHyA9FZ4nQuu5X8b/+OTl/HPZuUqO9Uy5Fiic0fvdeu3Yh+YXnFfG05lzUKN73/Pah5 vXExvlifNyb2jjVULDq3h61rG9UZ1ZZZ+5EiWbyuFJ2FLGjNSlrB9nHY8YrP5/F64uO84Vig86u7 Tv/lymp0FknQmst0zOVW7UlxsV6VqLWncybKxMx/elWcVZO0kjY15dv3NEOzClarbifr0/kIy627 kTX2nU6R7FHoOk5762Br6OzrfGsrrP01Mzi2LIfOnsi146x9iY9J9Hp93tio+xJN/1KJlfSE9QOk 8Zj3RGyp9e7SITMvV3TZRGaPcl5+/yPdO/0VEyvr/EekWUz0N7TnZy6TRn+9uNIt2RG3P36f7KPx jU7V5jiQlmfyUDyyoiPdjsUbXkoYvW62fk5vt432t5Cmpr72UkBm0GryJJMrNotrKY9ytrU0k/aU zdrpLGexNtexVecq1W06RiDP2p7B/zn8b/k+I30kx7paTBvNtXur0CyZJR30e19fOd+kd/2aP92Q 6DX5zm0P/eXT7FL/YxsS5Iphe99SP2u7x9xp0u33iGkXD4jpjY6JyaNyXMydxDNi8qnom7VD7ukx eVX0a0vvnkz0mPwpGR6TW6XAY3KraM4SvZOxymNyrNR7xLpjdpfHdLMbPSbnymaPqf9ErM7LamaM nJGVlzknKz1vRnZW+syU7DnT07Nm5FrFlGnZc1Jy89KzMtLnZNjrxJoDwup/0NNltZ9TxO+jlNzF pWVV5WUVJRJ+D+tbL+vdm6xg1bLC8sCSYI2U6zrd1+KqworFRdXYqCgrKTH7p/s6WgordFn3f1bZ 4qpgdbC4JiU/WLUkZVIgVWakqe1pByyXzFq+52DOqRv2e5zLMfY+6Kv2r/qqfWwHF6Qrrrjiiiuu uOKKK6644oorX2Npz//3vv771zcHLvbf14D/P/LTX6v/P9b2zXV7pRhfV+P+6vdrPED9fo0HqN+/ VUys4Bdi7hDvFuMvPy3Gz94vxg8+LCZXqsYP1PabYuIA/Vr597ptam7mzLyU3EBlID2gcVnL5x1t fF+NLOrrKPtV417WOBx/ooSGY0Z7Hew3x9SNGEJPv9lN3UU97LyymvIiCTnprrjiiiuuuOKKK664 4oorrrhyAYjl50v0OVD0Pr3em1c/WX1y9cH1nrz6/erDq3+v9/DVj9cMJxeJ8eXV39dx2Dr+ROdA 0ZG034Jvi3GUddR4ClwiOpJIRG94XwZDQYcPDQMdN/1d0PHfV8BI0KHq+kCA+ukaj1BfH/dfxoiV pl/GgY5/niBmpsRJoOOdr4Krxcyj9T0x80aliZlTa4qYuasypP35q2ZK9DmsciXyPFY6R1d7c1kV ipnPSseU61D4Il6LQceklEIZLIW/t7cv41XHu9mJtGQ56CgvHV1WAzrU50bQEVoal1kNa+Am0HHi N8MtsFbMMLVb4cewDnTo1W1wO9wB6+En8A9wJ9wF/wj/BHeLifdsgHvhPtgIP4X7oUFMHGiTmNnO HoTNsAV+Bg+JiQ89DNvg57AddsAjsFNM3EiP+VFeH4NfwS74NTwuJp6k2/fwuhf2wRPwJDwlJs6k 27+wedYuh3ClqUnHUAZpOSm0fM3NUmW1mM5Lf/F5Qra0D4lLNLHE/WbzNOd793/0qzwdv/Kc2EMk RcJ5W7orPcQbrl+lYw2xxsWFxmuO4qot5Aosl6L2VKJKb3ucY1fq11Gkg+zTHMpM0zpHTmdlEMev /bX2252tX2XwIfPqo+fSWnUcrX72M6i92NqnZY78OtFleDfO/y/1n33+fW2OvGv7M5H69XurK/X/ Rv/Z9Xus8a3L6EuzaQVL21OLKH2pX1u8fl925fyHajK1ai6iGr5Pgva45M5Lf46go/Mfuu5Cr85t WnD7wq+vePj0Y3qYttu679bfb63GKGYEF69YVlRRY/0mnJWr61hlXUy6HAhtD0yUM5P2LBdXLnD5 X1BLAQIUABQAAAAIAARthCkMhtGjA1QAAACAAQAKAAAAAAAAAAAAIAC2gQAAAABNZ3VpZG8uZG9j UEsFBgAAAAABAAEAOAAAACtUAAAAAA== ------_=_NextPart_000_01C05DF2.108ADF20-- From rem-conf Mon Dec 04 07:17:03 2000 From rem-conf-request@es.net Mon Dec 04 07:17:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142xJX-0001QI-00; Mon, 4 Dec 2000 07:13:59 -0800 Received: from lumumba.luc.ac.be [193.190.9.252] (mail) by mail1.es.net with esmtp (Exim 1.81 #2) id 142xJW-0001Py-00; Mon, 4 Dec 2000 07:13:58 -0800 Received: from jori (helo=localhost) by lumumba.luc.ac.be with local-esmtp (Exim 3.12 #1 (Debian)) id 142xIp-0005vm-00; Mon, 04 Dec 2000 16:13:15 +0100 Date: Mon, 4 Dec 2000 16:13:15 +0100 (CET) From: Jori Liesenborgs X-Sender: jori@lumumba.luc.ac.be To: rem-conf@es.net cc: Jon+rtp@ringle.org, pcnudde@globespan.net, basit@basitali.com, wimboffe@vub.ac.be, kiran_hegde@usa.net Subject: Voice over IP library: JVOIPLIB (v1.0.0) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jori X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello everybody, I just wanted to let you know that I've released the first 'official' version of JVOIPLIB. JVOIPLIB stands for "Jori's VoIP Library" and it is an object-oriented library, written in C++. It's purpose is to make it easy to set up and control VoIP sessions. The library is released under the terms of the Library General Public License (LGPL). If you're interesed, take a look at: http://lumumba.luc.ac.be/jori/jvoiplib/jvoiplib.html Bye, Jori From rem-conf Mon Dec 04 07:40:48 2000 From rem-conf-request@es.net Mon Dec 04 07:40:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142xi6-0002Ip-00; Mon, 4 Dec 2000 07:39:22 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 142xi3-0002If-00; Mon, 4 Dec 2000 07:39:20 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA12699; Mon, 4 Dec 2000 16:39:16 +0100 (MET) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma012697; Mon, 4 Dec 00 16:39:16 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA17289; Mon, 4 Dec 2000 16:39:15 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA27545; Mon, 4 Dec 2000 16:39:08 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890016413527; Mon, 4 Dec 2000 16:41:01 +0100 To: Cc: <4on2andIP-sys@advent.ee.columbia.edu>, Subject: RE: Draft AHG meeting report Message-ID: <0056890016413527000002L972*@MHS> Date: Mon, 4 Dec 2000 16:41:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 12/04/00 16:37:24" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Guido, Thanks for your document. I would like to come back on it tomorrow. For= now a general comment only. We agreed to produce an RTP spec for carriage o= f MPEG-4 content that can be used with and without MPEG-4 Systems. Theref= ore I suggest to describe all syntax in "an RFC way", not in MPEG-4 lingo. Of= course, while ensuring that transcoding to MPEG-4 Systems lingo remains= possible. In my view it is questionable whether transcoding to the "BigSL syntax"= is needed at all. It may be sufficient to keep it simple and to transcode = to the regular SL syntax, the current compliance point. Efficiency is impo= rtant at the transport, but less at the compliance point. Kind regards, Jan -----Original Message----- From: Guido.Franceschini@cselt.it [mailto:Guido.Franceschini@cselt.it] Sent: maandag, 04 december, 2000 14:16 To: 4on2andIP-sys@advent.ee.columbia.edu; young@techway.co.kr Cc: rem-conf@es.net Subject: RE: Draft AHG meeting report << File: Mguido.zip >> Young, Philippe, all, here attached is my personal view on the work being done. I hope I have= fairly presented the AGREED results, together with additional considera= tions of my own. The document is intended to be read and understood (hopefull= y) also by those not present in NY. As a minimum, it will make you understand how my brain works ;-) That document also provides a tentative specification for the bits on t= he wire, since in NY we made agreements on several issues but left the exa= ct syntax as homework for me and Philippe. In order to produce a clear document, I have also reported the open iss= ues and designed the syntax according to my own personal (but motivated) preference on those issues. It would be great if we could close the few remeaining details, so that= Philippe can safely edit the Internet Draft. Guido -----Original Message----- From: Young-Kwon LIM [mailto:young@techway.co.kr] Sent: Friday, December 01, 2000 4:33 AM To: 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: Draft AHG meeting report Dear all, Thank you everyone. The meeting was very fruitable. We made a real prog= ress this time. Attached you will find a draft meeting report including resolutions. Comments are welcome. Sincerely, Young. = From rem-conf Mon Dec 04 08:45:07 2000 From rem-conf-request@es.net Mon Dec 04 08:45:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142yhO-0003km-00; Mon, 4 Dec 2000 08:42:42 -0800 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 142yhM-0003kF-00; Mon, 4 Dec 2000 08:42:40 -0800 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G5100084YAQTN@ss3000e.cselt.it> for rem-conf@es.net; Mon, 4 Dec 2000 17:40:02 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Mon, 04 Dec 2000 17:43:26 +0100 Content-return: allowed Date: Mon, 04 Dec 2000 17:40:01 +0100 From: Franceschini Guido Subject: RE: Draft AHG meeting report To: "Guido.Franceschini@cselt.it" , "'jan.vandermeer@philips.com'" Cc: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Message-id: <85077463E51D6A498C453073E167794039BF28@clu2k02a.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jan, I believe the N AU => 1 RTP mapping is a 3 logical (only logical) steps: N AU => N SL => 1 BIGSL => 1 RTP MPEG-4 Systems only perfoms today AU => SL In my document I showed how ideally the first 2 steps could have been done in MPEG, leaving to the RFC just the trivial 1 BIGSL => 1 RTP step But I also highlighted that we AGREED instead (for procedural/timeline reasons) to have both N SL => 1 BIGSL => 1 RTP in the RFC. IMHO the approach I followed in my document helps identifying the exact information that MUST be carried in SDP, since that information is essential for the N SL => 1 BIGSL step In terms of the RFC Philippe is generating, it may or may not describe the mapping as a single (complex) step, or as 2 logically separate steps: I do not care how things are described in the final spec, but I do care that we do not make mistakes in defining the bits on the wire. As far as compliance is concerned I agree with you: given the task we decided to attribute to the mapping, there is no need to consider BIGSL. Bye Guido > ---------- > From: jan.vandermeer@philips.com[SMTP:jan.vandermeer@philips.com] > Sent: Monday, December 04, 2000 4:41 PM > To: Guido.Franceschini@cselt.it > Cc: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net > Subject: RE: Draft AHG meeting report > > Guido, > > Thanks for your document. I would like to come back on it tomorrow. For > now > a general comment only. We agreed to produce an RTP spec for carriage of > MPEG-4 content that can be used with and without MPEG-4 Systems. Therefore > I > suggest to describe all syntax in "an RFC way", not in MPEG-4 lingo. Of > course, while ensuring that transcoding to MPEG-4 Systems lingo remains > possible. > > In my view it is questionable whether transcoding to the "BigSL syntax" is > needed at all. It may be sufficient to keep it simple and to transcode to > the regular SL syntax, the current compliance point. Efficiency is > important > at the transport, but less at the compliance point. > > Kind regards, > > Jan > > -----Original Message----- > From: Guido.Franceschini@cselt.it [mailto:Guido.Franceschini@cselt.it] > Sent: maandag, 04 december, 2000 14:16 > To: 4on2andIP-sys@advent.ee.columbia.edu; young@techway.co.kr > Cc: rem-conf@es.net > Subject: RE: Draft AHG meeting report > > << File: Mguido.zip >> > Young, Philippe, all, > > here attached is my personal view on the work being done. I hope I have > fairly presented the AGREED results, together with additional > considerations > of my own. The document is intended to be read and understood (hopefully) > also by those not present in NY. > As a minimum, it will make you understand how my brain works ;-) > > That document also provides a tentative specification for the bits on the > wire, since in NY we made agreements on several issues but left the exact > syntax as homework for me and Philippe. > > In order to produce a clear document, I have also reported the open issues > and designed the syntax according to my own personal (but motivated) > preference on those issues. > > It would be great if we could close the few remeaining details, so that > Philippe can safely edit the Internet Draft. > > Guido > > -----Original Message----- > From: Young-Kwon LIM [mailto:young@techway.co.kr] > Sent: Friday, December 01, 2000 4:33 AM > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: Draft AHG meeting report > > > Dear all, > > Thank you everyone. The meeting was very fruitable. We made a real > progress > this time. > Attached you will find a draft meeting report including resolutions. > Comments are welcome. > > Sincerely, > Young. > > From rem-conf Mon Dec 04 09:46:29 2000 From rem-conf-request@es.net Mon Dec 04 09:46:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 142zen-0004zC-00; Mon, 4 Dec 2000 09:44:05 -0800 Received: from wall.graphica.co.jp (inetgw.graphica.co.jp) [210.145.91.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 142zel-0004z2-00; Mon, 4 Dec 2000 09:44:03 -0800 Received: from tnt14a-30.focal-chi.corecomm.net_[216.214.203.30] (tnt14a-30.focal-chi.corecomm.net [216.214.203.30]) by inetgw.graphica.co.jp (8.8.6/3.6Wbeta5) with SMTP id CAA21478; Tue, 5 Dec 2000 02:41:48 +0900 From: helmuth.beck@5Business.cc Received: from alpha.futurenet.co.za by tnt14a-30.focal-chi.corecomm.net with ESMTP; Mon, 04 Dec 2000 11:44:19 -0600 Message-ID: <000038f37a42$00007dc1$00007ebb@alpha.futurenet.co.za> To: Subject: The money tree 32443 Date: Mon, 04 Dec 2000 11:44:16 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do You Yen To Be A Millionaire!

Do You Have The Yen To Be a A= Millionaire?

100% return in less t= han 90 days!

The next "Bull M= arket" is foreign currency. The foreign currency market could= be ready
to make the next investor a millionaire! Are you next?

The time is now!<= /FONT>

Contact us today For a "FREE NO OBLIGATION" information packet.<= /B>

U.S and Canadian Residents = Only

Name

Required

Phone Number

Required

City

Required

State

Required

E-Mail

Optionalxxxxxxx= xxxx

(Request without phone number= will not be processed)

This is a one-time mailing, done by an independent marketing company= . We respect your online privacy and apologize if you have received this message in error. If you would like to be rem= oved from our mailing list just enter you email address in the field below and select the remove button.

Please be aware that any disruption to our r= emove link prevents those who want to be removed from our database from being removed.

<= p>

From rem-conf Mon Dec 04 11:50:40 2000 From rem-conf-request@es.net Mon Dec 04 11:50:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1431ZF-0002Jd-00; Mon, 4 Dec 2000 11:46:29 -0800 Received: from boreas.isi.edu [128.9.160.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 1431ZD-0002Io-00; Mon, 4 Dec 2000 11:46:28 -0800 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA04980; Mon, 4 Dec 2000 11:46:15 -0800 (PST) Message-Id: <200012041946.LAA04980@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3016 on RTP Payload Format for MPEG-4 Audio/Visual Cc: rfc-ed@ISI.EDU, rem-conf@es.net Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 04 Dec 2000 11:46:15 -0800 From: RFC Editor X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3016 Title: RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s): Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata Status: Standards Track Date: November 2000 Mailbox: yoshihiro.kikuchi@toshiba.co.jp, matsui@drl.mei.co.jp, t-nomura@ccm.cl.nec.co.jp, fukunaga444@oki.co.jp, kimata@nttvdt.hil.ntt.co.jp Pages: 21 Characters: 47070 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-mpeg4-es-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc3016.txt This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Multipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001204114243.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3016 --OtherAccess Content-Type: Message/External-body; name="rfc3016.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001204114243.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From rem-conf Mon Dec 04 16:03:04 2000 From rem-conf-request@es.net Mon Dec 04 16:03:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1435TL-0000gw-00; Mon, 4 Dec 2000 15:56:39 -0800 Received: from hafez.east.isi.edu [38.218.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 1435TK-0000gm-00; Mon, 4 Dec 2000 15:56:38 -0800 Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id eB4Nuah27109 for ; Mon, 4 Dec 2000 18:56:36 -0500 Message-Id: <200012042356.eB4Nuah27109@hafez.east.isi.edu> To: rem-conf@es.net Subject: RTP interoperability testing Date: Mon, 04 Dec 2000 18:56:35 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, A reminder that we still need to complete the RTP interoperability testing, before the RTP specification and audio/video profile can advance to draft standard. The details are provided in draft-ietf-avt-rtp-interop-05.txt (for the RTP specification) and draft-ietf-avt-profile-interop-03.txt (for the profile). There are a number of results missing. For the profile: - Audio codecs: 1016, G726-32, G723, 11,16,22kHz DVI, G722, QCELP, 44kHz L16, G728, GSR HR, GSR EFR, L8 - Video codecs: CelB, motion JPEG, nv, MP2T, H263, BT656, MP1S, MP2P, BMPEG If you have an implementation of any of these codecs, and have tested with another implementation, PLEASE mail me a brief note to the effect of "Vendor ??? has an implementation of ??? and has tested with vendor ???". If we do not get these tests complete, we shall have to remove these codecs >from the list of static payload types in the revised audio/video profile. For the RTP specification: - RTP with padding - SDES PRIV - RTCP BYE with multiple sources - RTCP BYE with reason for leaving - Canonical mapping of passphrase when encrypting - Encrypted RTCP (see draft for details) - RTP transported via TCP - RTCP reconsideration and timeout algorithms Again, if you have an implementation of any of the following, please contact me. If we cannot test these features, they will be removed from the revised RTP specification. Thanks in advance! Colin From rem-conf Mon Dec 04 18:21:24 2000 From rem-conf-request@es.net Mon Dec 04 18:21:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1437ep-0002mN-00; Mon, 4 Dec 2000 18:16:39 -0800 Received: from (smsrv) [210.254.59.35] (hidden-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 1437el-0002lf-00; Mon, 4 Dec 2000 18:16:35 -0800 Received: from mx.kusakabe-eng.co.jp ([172.16.1.1] (may be forged)) by smsrv (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id LAA00758; Tue, 05 Dec 2000 11:23:14 +0900 Date: Tue, 05 Dec 2000 11:23:14 +0900 From: yt@lvo.fr Message-Id: <200012050223.LAA00758@smsrv> Received: from oemcomputer ([199.179.170.174]) by mx.kusakabe-eng.co.jp (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 492569AC.000CA450; Sat, 5 Dec 1970 11:19:11 +0900 To: yt@lvo.fr Subject: Make $50K In 90 Days! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend, This really works! Have the faith, don't miss this opportunity, get involved also, and it will work for you as it does for us!!!!! Thank you for your time and interest. This email contains the ENTIRE PLAN of how YOU can make $50,000 or more in the next 90 days simply sending email! Seem impossible? Just read on and see how easy this is.... Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e- mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello - My name is Johnathon Rourke, I'm from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience in hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work. But as I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn't believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL I decided "WHY NOT!?!??" Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any for printing to send out the program, and because I also send the product (reports) by e- mail, my only expense is my time. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate...because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to"move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out, the more potential customers you will reach. So my friend, I have given you the ideas,information,materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home,store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by email! ************************************************************ ******* The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE , the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by email. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk email service companies (search for "bulk email") and have them send 25,000 - 50,000 emails for you about $49+) (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn't this about as easy as it gets? ************************************************************ ******* By the way there are over 50 MILLION email addresses with millions more joining the internet each year so don't worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this lettermany times - then one day I decided it was time to try it. ************************************************************ ******* YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can't sell them if you don't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000's of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you've ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire email to send by email to prospects. Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing (surely you can afford $20 and initial bulk mailing cost). You obviously already have access to a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved email out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email outhundreds of thousands of programs instead of 2,000 (Why stop at 2000?). But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000s end out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1st level--your first 10 send you $5...............$50 2nd level--10 members from those 10 ($5 x 100)........$500 3rd level--10 members from those 100 ($5 x 1,000)........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).......$50,000 $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ AMAZING ISN'T IT? Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan - the question is - Don't you want your name to be on the emails they will send out? * * * DON'T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets of paper write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Melissa Kugler 4397 North Niles Road New Cambria, KS 67470 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Glen Comer 941 Nena Ave. Havre de Grace, MD 21078 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: James Bybee 382 N. 800 W. Orem, UT 84057 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Joy Carver 1904 San Gabriel #103 Austin, TX 78705 ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them! -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program - If you follow the instructions exactly - results WILL FOLLOW. $$$$ ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e- mails or continue placing ads and start the whole process again! There is no limit to the income you will generate >from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start!, NOthing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above-- SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal Agency)1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax reuirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ================================================ If you are not the intended recipient of this message, please accept my apologies and delete. This message is sent in compliance of the new E-mail bill, Section 301. Paragraph (a) (2) (C) of S. 1618. This is a one time e-mail transmission. No request for removal is necessary. From rem-conf Mon Dec 04 21:54:47 2000 From rem-conf-request@es.net Mon Dec 04 21:54:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143AtP-00058V-00; Mon, 4 Dec 2000 21:43:55 -0800 Received: from (rnd.) [210.111.23.67] by mail1.es.net with smtp (Exim 1.81 #2) id 143AtM-000583-00; Mon, 4 Dec 2000 21:43:52 -0800 Received: from 210.111.23.67 by rnd. (SMI-8.6/SMI-SVR4) id NAA12042; Tue, 5 Dec 2000 13:30:44 +0900 From: friends@enterprises2001.com Received: from mailhost.enterprises2001.com (alt1.enterprises2001.com(208.5.67.10)) by enterprises2001.com (8.8.5/8.6.5) with SMTP id GAA01750 for ; Mon, 04 Dec 2000 21:03:43 -0600 (EST) Date: Mon, 04 Dec 00 21:03:43 EST To: frontunax@radiant.com Subject: YOU CAN MAKE ALOT OF MONEY AT HOME WITH THIS BUSINESS OPPORTUNITY Message-ID: Reply-To: frontunax@radiant.com X-PMFLAGS: 128 0 X-UIDL: 57484839872987388761098273678937187382 Comments: Authenticated sender is X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend, I am looking for people with good work ethic and extraordinary desire to start earning a considerable income working part-time from home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in control of your time,your finances,and your life! ----------------------------------------------------------------------- But before you make your decision as to whether or not you participate in this program, please answer one question... "DO YOU WANT TO MAKE A CHANGE IN YOUR LIFE?" If the answer is yes, please look at the following facts about this program: 1. YOU WOULD BE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU WOULD BE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. AND IT IS A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSE OTHER THAN YOUR INITIAL $20 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM MAY CHANGE YOUR LIFE FOREVER. ------------------------------------------------------------------------ You can earn $50,000 or more in next the 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... Here's an opportunity that I genuinely believe satisfies the criteria we all seek in a Good Business Opportunity. I can confirm from my research this is an ethical opportunity that does indeed provide significant returns. There are plenty of people doing this in the UK, States and Canada; genuine people who are willing to assist you. I send this to you as I received it. ------------------------------------------------------------------------- MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump (A MULTI-BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions >from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. A NOTE FROM THE ORIGINATOR: My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in the hope that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT?" Initially I sent out 100,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $55,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $55,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 100,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $55,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! P.S. Do you have any idea what 11,700 $5 bills ($58,000) look like piled up on a kitchen table? Johnathon Rourke ------------------------------------------------------------------------- With "NO RISK" and "JUST A LITTLE BIT OF EFFORT", you can make more money in the next few months than you have ever imagined. ------------------------------------------------------------------------- HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ ------------------------------------------------------------------------- INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Because of the global nature of the internet, you will be able to recruit new multi-level business partners from all over the world, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). These 4 reports show you how to actually do this online business! * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. AND MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! To assist you with marketing your business on the internet, the 4 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1000 orders for REPORT #3. Those 1000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 11,110 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR EVEN HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you how to send out 1,000,000 e-mails for free. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 6 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5 ($5 x 10).................$50 2nd level--10 members from those 10 ($5 x 100)..............$500 3rd level--10 members from those 100 ($5 x 1000)......... $5,000 4th level--10 members from those 1000 ($5 x 10,000)......$50,000 THIS TOTALS ---------------------------------------------$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Many people will get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ *** Order Each REPORT by NUMBER and NAME *** Notes: - ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHEQUES NOT ACCEPTED. - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ______________________________________________________ REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: IPS Network 355-2252 Kingsway Ave. Vancouver B.C. Canada V5N 5X6 ______________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Sarah Harris PO Box 4271 Verwood BH31 6FW UK ______________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Anthony Thomas 2 Hazelwood Drive Dorset BH31 6YQ UK ______________________________________________________ REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Yuko Imports 2187 East 8th Avenue Vancouver, British Columbia Canada V5N1V4 ----------------------------------------------------------------------- There are currently more than 175,000,000 people online worldwide! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100-150 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN. DECISIVE ACTION YIELDS POWERFUL RESULTS. From rem-conf Mon Dec 04 23:44:33 2000 From rem-conf-request@es.net Mon Dec 04 23:44:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143Cfm-0006qw-00; Mon, 4 Dec 2000 23:37:58 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 143Cfl-0006qm-00; Mon, 4 Dec 2000 23:37:57 -0800 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id XAA23714 for ; Mon, 4 Dec 2000 23:37:55 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 4 Dec 2000 23:37:54 -0800 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id XAA16084; Mon, 4 Dec 2000 23:37:54 -0800 (PST) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <200012042356.eB4Nuah27109@hafez.east.isi.edu> References: <200012042356.eB4Nuah27109@hafez.east.isi.edu> Date: Mon, 4 Dec 2000 23:35:23 -0800 To: Colin Perkins , rem-conf@es.net From: Kevin Marks Subject: Re: RTP interoperability testing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If any of you want to cross-test with QuickTime, you can get the client from http://www.apple.com/quicktime (Mac & Windows only) and the server from http://www.apple.com/quicktime/products/qtss/ OS X, Windows NT, Linux, Solaris & BSD + source These are release versions of QuickTime 4 & QTSS 2 For current development versions, go to: http://www.apple.com/quicktime/preview http://www.apple.com/quicktime/preview/qtss.html For SDKs and development info, plus newer versions of Qt5 than the public preview, go to http://developer.apple.com/seeding/index.html and become a registered Apple Developer (its free) Audio Codecs we support from the list below: 11,16,22kHz DVI, QCELP, L16, L8 (plus uLaw, aLaw etc). Video Codecs we support from the list below: motion JPEG, H263, MPEG 1 plus H261 At 6:56 PM -0500 12/4/00, Colin Perkins wrote: >Folks, > >A reminder that we still need to complete the RTP interoperability testing, >before the RTP specification and audio/video profile can advance to draft >standard. > >The details are provided in draft-ietf-avt-rtp-interop-05.txt (for the RTP >specification) and draft-ietf-avt-profile-interop-03.txt (for the profile). >There are a number of results missing. For the profile: > > - Audio codecs: 1016, G726-32, G723, 11,16,22kHz DVI, G722, QCELP, > 44kHz L16, G728, GSR HR, GSR EFR, L8 > - Video codecs: CelB, motion JPEG, nv, MP2T, H263, BT656, MP1S, MP2P, BMPEG > >If you have an implementation of any of these codecs, and have tested with >another implementation, PLEASE mail me a brief note to the effect of "Vendor >??? has an implementation of ??? and has tested with vendor ???". > >If we do not get these tests complete, we shall have to remove these codecs >from the list of static payload types in the revised audio/video profile. > >For the RTP specification: > - RTP with padding > - SDES PRIV > - RTCP BYE with multiple sources > - RTCP BYE with reason for leaving > - Canonical mapping of passphrase when encrypting > - Encrypted RTCP (see draft for details) > - RTP transported via TCP > - RTCP reconsideration and timeout algorithms > >Again, if you have an implementation of any of the following, please >contact me. If we cannot test these features, they will be removed from >the revised RTP specification. > >Thanks in advance! >Colin From rem-conf Tue Dec 05 11:35:57 2000 From rem-conf-request@es.net Tue Dec 05 11:35:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143NmY-0006fT-00; Tue, 5 Dec 2000 11:29:42 -0800 Received: from relay.eecs.berkeley.edu [169.229.34.228] by mail1.es.net with esmtp (Exim 1.81 #2) id 143NmV-0006fJ-00; Tue, 5 Dec 2000 11:29:40 -0800 Received: from bmrc.berkeley.edu (ix.CS.Berkeley.EDU [128.32.36.141]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA00478; Tue, 5 Dec 2000 11:29:38 -0800 (PST) Message-ID: <3A2D4162.2EFBE8E@bmrc.berkeley.edu> Date: Tue, 05 Dec 2000 11:26:26 -0800 From: Florissa Colina X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 12/6 Specific-Source Multicast and Wide-Area Deployment Efforts -- Supratik Bhattacharyya, Sprint Laboratories Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Specific-Source Multicast and Wide-Area Deployment Efforts Wednesday December 6, 2000 1:10 - 2:30 PST Fujitsu Seminar Room (405 Soda Hall) Supratik Bhattacharyya Sprint Laboratories Over the past year and half, Source-Specific Multicast (SSM) has been rapidly gaining grounds as an immediately deployable solution for inter-domain multicast. SSM is based on the well-known EXPRESS multicast service model in which every multicast "channel" is identified by a source address and a class-D IP multicast address. Although this restricts each channel to only one source, SSM is powerful enough to enable point-to-multipoint applications such as Internet TV that are expected to dominate the multicast application space in the near future. At the same time, SSM is simple and manageable, making it attractive from an operational standpoint. The first part of this talk will focus on the motivation behind SSM, and the benefits it offers relative to the classic IP multicast architecture. I will describe the modifications required to network protocols, end-hosts and applications in order to realize an end-to-end SSM framework. In the second part of the talk, I will discuss ongoing efforts at SprintLabs and elsewhere to facilitate the widespread deployment of SSM, as well as the standardization process in IETF. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.129/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Dec 05 21:13:38 2000 From rem-conf-request@es.net Tue Dec 05 21:13:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143WpV-0003a3-00; Tue, 5 Dec 2000 21:09:21 -0800 Received: from ip-210-48-103-121.iconz.net.nz (homer.iPayroll.co.nz) [210.48.103.121] by mail1.es.net with esmtp (Exim 1.81 #2) id 143WpS-0003Zn-00; Tue, 5 Dec 2000 21:09:19 -0800 Received: from 62.20.125.83 (01-056.033.popsite.net [216.3.182.56]) by homer.iPayroll.co.nz (8.9.3/8.8.7) with SMTP id RAA08673; Wed, 6 Dec 2000 17:51:17 +1300 From: joe@aba.com Message-Id: <200012060451.RAA08673@homer.iPayroll.co.nz> To: Subject: Search Engine Optimization Kit-2001 18405 Date: Tue, 05 Dec 2000 23:52:43 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Outlook Express X-Originating-IP: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

Get Top 10 Positions With The Search Engine Optimization Kit-2001

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

Hello Friend,

We created the Search Engine Optimization Kit-2001 to achieve high positions in search engines. This unique Kit includes:
  • Detailed information about how search engines work,

  • Step-by-step instructions to create, high-ranking,"search-= engine-friendly" pages,

  • All the tools and resources you need to create pages, submit to= engines and track your placements, and

  • Ongoing personal support by email and phone.

Click to receive Free In= formation about Search Engines and the Kit, or call direct to 937-640-2762.

We reply promptly to all inquires.

Dr. Jerry R. Perrich, Director
The Internet Marketing Institute, Inc.
Helping You Be Successful Online
937-640-2762


PS - Please forward this email to any of your business associates or friends who may benefit from it.

REMOVAL INSTRUCTIONS=
Per federal legislation, you can be removed from this mailing list at no c= ost to you by simply clicking here Remove Ple= ase. You will be promptly removed. Please note that interfering with this feder= ally approved method of removal will deny others the opportunity to be removed.

<= p>

From rem-conf Wed Dec 06 02:19:20 2000 From rem-conf-request@es.net Wed Dec 06 02:19:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143bUJ-00065l-00; Wed, 6 Dec 2000 02:07:47 -0800 Received: from prue.eim.surrey.ac.uk [131.227.76.5] (exim) by mail1.es.net with esmtp (Exim 1.81 #2) id 143bUH-00065Z-00; Wed, 6 Dec 2000 02:07:45 -0800 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 143bSr-000024-00; Wed, 06 Dec 2000 10:06:17 +0000 Date: Wed, 6 Dec 2000 10:04:15 +0000 (GMT) From: "Dr A. H. Sadka" X-Sender: ees3as@regan.ee.surrey.ac.uk To: rem-conf@es.net, conferencesa@comsoc.org, announcements@omg.org, ecoop-info@ecoop.org Subject: CFP - SCI2001 (Final callout) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Apologies if you receive multiple copies of this CFP) Dear multimedia communications and networking experts, In the light of the 5th world multi-conference SCI to be held in July 2001, an invited session on multimedia communications and networking will be organised. The objective of this session is to give the experts = in the field the opportunity to meet up and exchange ideas and thoughts on their latest research and technical activities and provide them with a plaform of publishing and presenting their most recent achievements in a world renowned conference. Therefore, you are all invited to submit an abstract of a technical paper by the 15th of December 2000 at the latest. The scope of this organised session is defined by, but not restricted to: - Media compression (video, speech, audio) - Joint source/channel coding - Packet audio/video communications (Packetisation schemes, synchronisation, lost packet recovery techniques) - Error control mechanisms (Error resilience, concealment, recovery techniques, new error handling schemes for mobile channel applications etc) - Audiovisual transmissions over 3G networks (QoS, quality/error control optimisation, Throughput and channel utilisation, multi-slotting capabilities for video service provisioning - Packet video and audio networks (Broadcast DVB and DAB technologies, Wireless multimedia, Video over Wireless ATM etc) - Multimedia and DTV applications - Internetwork communications (Multimedia Gatewaying, Multimedia Control Unit architecture and technologies, Advanced H.323 applications and services, integration of fixed and mobile IP networks etc) - Improved multimedia communication protocols (packet-switched, circuit-switched, multi-party audiovisual communications, improved QoS techniques etc) - Video indexing and retrieval - Security issues in Multimedia Communications (Image/Video authentication and watermarking, encryption, validation etc) - Novel multimedia applications and services over various networking platforms Important Dates: - Abstract submission: Dec 15, 2000 - Notification of acceptance: Feb 16, 2001 - Camera ready paper: Apr 6, 2001 Abstracts must be submitted electronically in Microsoft Word document or postscript format to a.sadka@eim.surrey.ac.uk at a date no later than the submission deadline above. Invited session Webpage: http://www.ee.surrey.ac.uk/Personal/A.Sadka/SCI2001 Conference Webpage: http://www.iiis.org/sci Best regards. _________________________________________ Dr A. H. Sadka (Lecturer) | Multimedia Communications Research Group | Centre for Communication Systems Research| Uni. of Surrey, GU2 7XH, Surrey, England | Tel: +44 (01483) 259490 | Fax: +44 (01483) 876011 | WWW: www.ee.surrey.ac.uk/Personal/A.Sadka| _________________________________________| From rem-conf Wed Dec 06 07:50:27 2000 From rem-conf-request@es.net Wed Dec 06 07:50:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143glh-0001he-00; Wed, 6 Dec 2000 07:46:05 -0800 Received: from smtp01.wxs.nl [195.121.6.61] by mail1.es.net with esmtp (Exim 1.81 #2) id 143glg-0001hC-00; Wed, 6 Dec 2000 07:46:04 -0800 Received: from zeed ([195.121.115.56]) by smtp01.wxs.nl (Netscape Messaging Server 4.15) with SMTP id G55L3100.O1D for ; Wed, 6 Dec 2000 16:45:01 +0100 From: "S. Uyar" To: Subject: Multicasting Date: Wed, 6 Dec 2000 16:46:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C05FA4.22438720" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-MS-TNEF-Correlator: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C05FA4.22438720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have a question about Multicasting in fact about the procedure of join process. The first step when you enable the multicast application, the device configures the NIC, and the built-in IGMP processes send an membership report to the router DR requesting copies of the multicast frames. Is it not possible to configure the NIC to listen first on the segment before sending an membership report? Because it's possible that the Multicast frame is already present for an other receiver. Otherwise it hast to go via DR to Querier router and so on... Actually as the Spanningtree protocol....Listening-Learning and Forwarding....... Thanks, Selcuk Uyar ( Tech. Engineer ) ------=_NextPart_000_0013_01C05FA4.22438720 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjQPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHDAAGABAALgAAAAMAKgEB A5AGAFANAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADQAAAE11bHRpY2FzdGluZwAAAAACAXEAAQAAABYAAAABwF+br1eAy4Zyy1QR1KaiABCk6IFj AAACAR0MAQAAABgAAABTTVRQOlNFTENVSy5VWUFSQFdYUy5OTAALAAEOAAAAAEAABg4A7Hihm1/A AQIBCg4BAAAAGAAAAAAAAADLuznubevTEaagABCk6IFjwoAAAAsAHw4BAAAAAgEJEAEAAAAFCQAA AQkAALgUAABMWkZ1rYK+FwMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDA0Mw8WZmUPkk8B9wKk A2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdDBAdA2MDMwNQ+gFCHzAdAUEDR9B20CgwBQ A9T7Ef8TC2IT4RRQE7IY9BTQEwcTFeQ5NBGOMjM4RRdUIAdtIENFGgU1TxqPD6AbvxzFeXIaBTe5 EY4xNhYxHx8DgkcJ0X5rGgUboSE+DlAiXwNzVOsIcBoFOSSPNyEBJd8DgpAoSGViCXB3KQKD/wHQ EX8o0BuvKgYHEAGgDeBnKuYWMSE9ODYsrxzEQv0HQHQN4Cr1JaEWbBuIBxP/HRYUkTKfHtc0NSB1 AdAdsf8WbCIYNDQjuBPRN+8llzQ0/ycmAdAhATgNKOc0NCp9LJH/PY4zvC4dJ8E4DTAnNDQxtqsC kQjmOwlvMEafZQ4w/jVHykjhSJ9JqUe0SdJIPz9MD0vNS09Jf0fPEGAyOP9RmlKxUm9TeUe0U6JS D1Xf71WdVR9TT1cUOQ5QWmRbwYdT41vAAoJzdHlsB5AqaAngdAAAcQMhbGkPAUAFEAFAA/BkY3Rs ewqxAGBzCrBfABbgX0JuBHVtAgBhYXV0bzEAYGRqdV0wBRBnaF50XmEKAV4wCgFpAZBw3jADMRYy DAEPVDMPwBAWnWNxYwnAXsBjA25wY1nDZPQDMHNuZXgXMAewzwWwAMACcxMQY3MPkAMwpWDAZGIg aXYTgEQBENNgcDHQIFAKwGEJwGJA2GggRgIhXPMxHbBd8uhmaS0PkDhhsmqzXnx5KqBkcglQbFIW oGxSd/Y0UQEXAHAB0GexX29gf79hhmqzYi9jP2RPZV5ibhB/CYACIHFRZkNqEDQgBXByiHVrawnw LSBWAHCmOjQgdyJPbgSBdwSQonB3QERhdG7gOmnE/zAwak9rX2xvbX9uj2+fcKz/XYB+gAuADhJx UQwwcYQOUN9yD3MfdC91P3ZLQgZxFtCgdGtvcCALgCBmUEZneHAIkGYgYgngbP5kacQhAHlPel97 b3x/fY6vCGBe8AuAiJBlaDBsAUCffo9/n4CkK1ABQGNiCrDsdDiBOHHmMhpwEBaToceDNBNQF3Bv b2aDj4Sf94WnknCHCXaVIAXAiHAAcMx0d5jhAQBuL4VwBbD/XTAIcAnwacQskIlPil+Lb/+Mf32P j39wr3G/gr+Vn5av+5e3mUlEmgd3VHcTeGonwL9d/18Pn69hL6H0kiM5oj+/o0+kX6VvhZivIKgA Y6xg+wnwBUBNogBnFp6jZ+avR75jAECy6GeSq6AEkHMCIKc0YV0gBaBtcBNiRQDAZQMQUzHgamwB 0FzzMv8AUKo/q0+sX61vof+wD7Ef77IvhVu6MLkQLbkyBgC9oF+4QJpCRcMTEEawdgJRIFB7VW5r E1B3FdF9wQCxcmdsMTSJEcaC7nLG1yIAxuZixtIDMLshj8YQu1CdUQGAbmJqAGBHCfBn4LRAXGh5 vBBosG90ejQOMJTReAtgqQJAb3kJ8FxmYHBdgP8AIAuQE1BooZ1Qu9AA4QIwcwJgAIBiZAwwE1EK sGO/ARAFsGigAgFm0ICCZcqA5QWwespSZGfGgguBz/DOaM4jMBABQWd20LnPcfu9oKFxNy7x0UHS NSRgGnDb0ILK0HfSw9P0aswRAHBfCzDKUV1At/AOUHYIkHf6awuAZBpw1fIE8AdAEGD/FDAKoMiQ nTFdkL0w11UCEPPK4LfRbHmZYAMAZlDJov/Y573AAMC88LvQlNHNkL3A/70xCTK9YIiQAlAHQAuQ 2/F/AlHWQbqQ2PDW4btQAmB3P9yzAlEAIAnAupDJ0HJrz86RtiIXIRLydGW4wMuBwROAQzpcXFAD YGkh3m1pcAMQB5DgME0N4ANgv7ggAYB3oAEgDeDPUFzh5tcPk8wAuTIuhXB0xmAXEH27UGS6gmZR AUDXwgSQeZ/SoCyR2IHlFQjhc3jlQnvj82h0Y8WhEwIAgAWQbP52xsDn0Q5wZtDn0gGQACD/6GLW QbSBAcHn0RbgD3AAAOe8cAzQAZAgLsT05+YOUN/ogszR6O/p/+sPbA/AvHDvBYHsv+3P7t9sGnC8 cN0g9+yP8U/yVCnrTB2w8B/0//3yNGIqYAKR9h/oEzAw88//+I/5n/qv6EAhAPvy6M/9X//+b+tM LJD7/wF/Ao8Dn+hA/yfAAH8GDwcfCCQTIaew2AD/D1CHsbpfu2S8xb3/vw/AH//BL2XFGiEXQXkC ttEREzexfyEAk9bjARLEFWkTAuMAIKBIaSwNCgzyIBgVnxoSFH0RaxY1F1dJIDiA22gx8pBxR5Bd MGlpkBxQ/mKOgbSwaKEuYLvAMeCA0K+HorzAu1AdBXTXwCCVARXOUGSaUSCVMCBqb/eHsR9jODAu MKAfMZtQmiFqIF0wZYeQd9fAh8B5vY6AIEcwLkDewR8ibR2G3RxQcN+wHbEcwiwfE6fAq9XwzlAg 5jBum1BnmlHjLVAfIk5JQySQ1SEfEyRideNwdC2HsUlH/E1QIHYtQbjwJrEqQbRw5m2IcDigaGmH kEawuND73gAfEG8fEy8wvPB4EGhQ3lIpwRyEHhHmMHDWADDwXyABIwwvIOCg4QAuGBVJPzDwEDCH 0MrgH1C44HNp/yLDKlAlZyYGKjIOACGxHlH/IWMc4R8iuPDQALSCiHDOcd8yMnfAHgIo/0ZBP4bx 1uD/25EugVGgHIDloSGgLvk4gP8fBB13LXSHoC5w3RBGsL0w/nkfUeEAtILOcTOyyuDXwK+ZAEaw zlBoIXIg8E86Mt89kTWCHAEhgSpBZypQ1fD38pArISpBUUeQvZA6UirEVyaiuCAx0YUYHEG7UHXv 3RDY4BxQJfRT1REKccfwj0cRH1K9AOYxhS5MMSPpgMEtTJkwckDyJpNpgPeeEA0RgMGFQgAYHCEQ p1Duaxj/Gg8XDHNFn0avFwwNGA1TjyC0UGsgVXmtGFEoIQDkAGgg8EWA0P+OwSrx9nAYiElfSm8X sRiG/wzzDa+7X7xvvX+uVU8BtpYZGIZ9AFgxWHAAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAAD hQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAA AEYAAAAAUoUAACdqAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAK gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABG AAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA AAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALAECACCAGAAAAAADAAAAAAAAARgAA AAAOhQAAAAAAAAMAQoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwBDgAggBgAAAAAAwAAA AAAAAEYAAAAAGIUAAAAAAAADAFiACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAbYAIIAYA AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAAy7s57m3r0xGmoAAQpOiBYwIB+g8B AAAAEAAAAMu7Oe5t69MRpqAAEKTogWMCAfsPAQAAAIIAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAA UFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dTXExvY2FsIFNldHRp bmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAADAP4P BQAAAAMADTT9NwAAAgF/AAEAAAAyAAAAPE5EQkJLR0tBTUxLTEpOQUdPTUlJQUVMSUNBQUEuc2Vs Y3VrLnV5YXJAd3hzLm5sPgAAAAMABhAY+tzfAwAHECICAAADABAQAAAAAAMAERAAAAAAHgAIEAEA AABlAAAASEksSUhBVkVBUVVFU1RJT05BQk9VVE1VTFRJQ0FTVElOR0lORkFDVEFCT1VUVEhFUFJP Q0VEVVJFT0ZKT0lOUFJPQ0VTU1RIRUZJUlNUU1RFUFdIRU5ZT1VFTkFCTEVUSEVNVQAAAAB1cg== ------=_NextPart_000_0013_01C05FA4.22438720-- From rem-conf Wed Dec 06 09:53:41 2000 From rem-conf-request@es.net Wed Dec 06 09:53:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143ihu-0003Kt-00; Wed, 6 Dec 2000 09:50:18 -0800 Received: from ihemail1.lucent.com (ihemail1.firewall.lucent.com) [192.11.222.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 143iht-0003Kj-00; Wed, 6 Dec 2000 09:50:17 -0800 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA07186 for ; Wed, 6 Dec 2000 12:50:16 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA07142; Wed, 6 Dec 2000 12:50:12 -0500 (EST) Received: from nj7460gratta by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA19426; Wed, 6 Dec 2000 12:50:06 -0500 Message-Id: <200012061750.MAA19426@hotair.hobl.lucent.com> From: "Greg Ratta" To: ietf-ppp@merit.edu, rem-conf@es.net Date: Wed, 6 Dec 2000 12:50:01 -0500 MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: Comments on AAL Type 2 Signalling Reply-to: gratta@lucent.com CC: ian.rytina@ericsson.com, mmcloughlin@asc.com, hiramatsu.yukio@lab.ntt.co.jp, arshey.odedra@itu.int, sob@harvard.edu, mankin@east.isi.edu, narten@raleigh.ibm.com, nordmark@eng.sun.com Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 0100,0100,0100This message represents a communicatio= n to the IETF AVT and PPPEXT WGs that was approved by ITU-T SG 11 at its December 6, 2000 meeting. For followup technical discussions, please correspond with Mr. Ian Rytina, Q15/11 Rapporteur ({ HYPERLINK mailto:ian.rytina@ericsson.com }ian.rytina@ericsson.com), and Mr. Mike McLoughlin (mmcloughlin@asc.com)Courier New 1. Introduction rightThis communication has been generated by I= TU- T SG11 as a result of information received >from ITU-T SG13 related to the transport of PPP and/or CRTP over AAL type 2. 2. Request for Signalling of I.366.1 Applications rightIt has been brought to the attention of SG= 11 that the IETF is planning to use the SSSAR service of ITU-T Recommendation I.366.1. It is the understanding of the participants of SG 11 that the IETF is going to use particular UUI code points to distinguish among different forms of PDUs. In addition, more than one application may use this SSSAR. rightIt has been communicated that SG13 initiat= ed the definition of an SSCF to SSSAR (as a new Annex to ITU-T Recommendation I.366.1). In addition to this new SSCF, there is a need to signal what application is making use of this new Annex. rightSG11 have noted that communication has bee= n initiated between SG13 and the IETF. SG 11 anticipate that there may be a future request to provide a signalling mechanism for such applications, once the IETF indicate which applications are required to be supported (e.g. PPP over AAL type 2 and/or CRTP over AAL type 2, similar to that outlined in draft-buffam-avt- crtp-over- aal2-01.txt). SG11 note that these are valid applications of AAL type 2 and are happy to provide the necessary signalling support. rightThe participants in SG 11 would like to point out that ITU-T Recommendations Q.2630.1 and Q.2630.2 already include a parameter entitled =93Served User Transport,=94 which may be used to carry such application information; however, it is not clear whether this meets the proposed requirements of the IETF. As such, SG11 is awaiting further information from the IETF. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com From rem-conf Wed Dec 06 10:22:54 2000 From rem-conf-request@es.net Wed Dec 06 10:22:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143jBn-0004D7-00; Wed, 6 Dec 2000 10:21:11 -0800 Received: from oberon.dnai.com [207.181.194.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 143jBl-0004Ch-00; Wed, 6 Dec 2000 10:21:09 -0800 Received: from azoth.dnai.com (azoth.dnai.com [207.181.194.94]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id KAA55365; Wed, 6 Dec 2000 10:20:05 -0800 (PST) Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by azoth.dnai.com (8.9.3/8.9.3) with ESMTP id KAA55734; Wed, 6 Dec 2000 10:20:03 -0800 (PST) Received: from hariv (quokka [216.15.52.58]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id KAA01572; Wed, 6 Dec 2000 10:19:45 -0800 (PST) Message-ID: <007901c05fb0$75af9d20$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: , , Cc: , , , , , , , Subject: Re: Comments on AAL Type 2 Signalling Date: Wed, 6 Dec 2000 10:15:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C05F6D.66AA88A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C05F6D.66AA88A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have a few doubts regarding signalling/tones data transfer on AAL-2. = ITU has suggested several tones like the following: Dial, Recall Dial, Ringing, Busy, Congestion, Special information, = Warning and Record tone (apart from PBX tones). How are these carried over by AAL-2?=20 Regards Hari V -----Original Message----- From: Greg Ratta To: ietf-ppp@merit.edu ; rem-conf@es.net = Cc: ian.rytina@ericsson.com ; = mmcloughlin@asc.com ; hiramatsu.yukio@lab.ntt.co.jp = ; arshey.odedra@itu.int = ; sob@harvard.edu ; = mankin@east.isi.edu ; narten@raleigh.ibm.com = ; nordmark@eng.sun.com Date: Wednesday, December 06, 2000 9:59 AM Subject: Comments on AAL Type 2 Signalling =20 =20 This message represents a communication to the IETF AVT and PPPEXT = WGs that was approved by ITU-T SG 11 at its December 6, 2000 meeting. = For followup technical discussions, please correspond with Mr. Ian = Rytina, Q15/11 Rapporteur ({ HYPERLINK mailto:ian.rytina@ericsson.com = }ian.rytina@ericsson.com), and Mr. Mike McLoughlin (mmcloughlin@asc.com) = =20 1. Introduction=20 This communication has been generated by ITU- T SG11 as a result of = information received from ITU-T SG13 related to the transport of PPP = and/or CRTP over AAL type 2. =20 =20 =20 2. Request for Signalling of I.366.1 Applications=20 It has been brought to the attention of SG11 that the IETF is = planning to use the SSSAR service of ITU-T Recommendation I.366.1. It is = the understanding of the participants of SG 11 that the IETF is going to = use particular UUI code points to distinguish among different forms of = PDUs. In addition, more than one application may use this SSSAR. =20 =20 =20 It has been communicated that SG13 initiated the definition of an = SSCF to SSSAR (as a new Annex to ITU-T Recommendation I.366.1). In = addition to this new SSCF, there is a need to signal what application is = making use of this new Annex. =20 =20 =20 SG11 have noted that communication has been initiated between SG13 = and the IETF. SG 11 anticipate that there may be a future request to = provide a signalling mechanism for such applications, once the IETF = indicate which applications are required to be supported (e.g. PPP over = AAL type 2 and/or CRTP over AAL type 2, similar to that outlined in = draft-buffam-avt- crtp-over- aal2-01.txt). SG11 note that these are = valid applications of AAL type 2 and are happy to provide the necessary = signalling support. =20 =20 =20 The participants in SG 11 would like to point out that ITU-T = Recommendations Q.2630.1 and Q.2630.2 already include a parameter = entitled =93Served User Transport,=94 which may be used to carry such = application information; however, it is not clear whether this meets the = proposed requirements of the IETF. As such, SG11 is awaiting further = information from the IETF.=20 =20 =20 =20 =20 Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and = protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, = gratta@lucent.com=20 ------=_NextPart_000_0076_01C05F6D.66AA88A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,
 
  I have = a few doubts=20 regarding signalling/tones data transfer on AAL-2. ITU has suggested = several=20 tones like the following:
Dial, Recall Dial, Ringing, Busy, Congestion, = Special=20 information, Warning and Record tone (apart from PBX = tones).
How are these carried over by AAL-2?
 
Regards
Hari V
 
-----Original = Message-----
From:=20 Greg Ratta <gratta@lucent.com>
To: = ietf-ppp@merit.edu <ietf-ppp@merit.edu>; rem-conf@es.net <rem-conf@es.net>
Cc: = ian.rytina@ericsson.com = <ian.rytina@ericsson.com>; = mmcloughlin@asc.com <mmcloughlin@asc.com>; hiramatsu.yukio@lab.ntt.co.= jp=20 <hiramatsu.yukio@lab.ntt.co.= jp>;=20 arshey.odedra@itu.int = <arshey.odedra@itu.int>; = sob@harvard.edu <sob@harvard.edu>; mankin@east.isi.edu <mankin@east.isi.edu>; narten@raleigh.ibm.com = <narten@raleigh.ibm.com>; = nordmark@eng.sun.com <nordmark@eng.sun.com>
D= ate:=20 Wednesday, December 06, 2000 9:59 AM
Subject: Comments = on AAL=20 Type 2 Signalling

This message represents a=20 communication to the IETF AVT and PPPEXT WGs that was approved by = ITU-T SG=20 11 at its December 6, 2000 meeting. For followup technical = discussions,=20 please correspond with Mr. Ian Rytina, Q15/11 Rapporteur ({ = HYPERLINK=20 mailto:ian.rytina@ericsson.com }ian.rytina@ericsson.com), and Mr. = Mike=20 McLoughlin (mmcloughlin@asc.com) =

1.=20 Introduction
This communication has = been=20 generated by ITU- T SG11 as a result of information received from = ITU-T SG13=20 related to the transport of PPP and/or CRTP over AAL type=20 2.



2. Request for Signalling of I.366.1 = Applications
It has been brought to = the=20 attention of SG11 that the IETF is planning to use the SSSAR service = of=20 ITU-T Recommendation I.366.1. It is the understanding of the = participants of=20 SG 11 that the IETF is going to use particular UUI code points to=20 distinguish among different forms of PDUs. In addition, more than = one=20 application may use this = SSSAR.



It has = been=20 communicated that SG13 initiated the definition of an SSCF to SSSAR = (as a=20 new Annex to ITU-T Recommendation I.366.1). In addition to this new = SSCF,=20 there is a need to signal what application is making use of this new = Annex.



SG11 have = noted that communication has been initiated between SG13 and the = IETF. SG 11=20 anticipate that there may be a future request to provide a = signalling=20 mechanism for such applications, once the IETF indicate which = applications=20 are required to be supported (e.g. PPP over AAL type 2 and/or CRTP = over AAL=20 type 2, similar to that outlined in draft-buffam-avt- crtp-over-=20 aal2-01.txt). SG11 note that these are valid applications of AAL = type 2 and=20 are happy to provide the necessary signalling=20 support.



The = participants in SG 11 would like to point out that ITU-T = Recommendations=20 Q.2630.1 and Q.2630.2 already include a parameter entitled = “Served=20 User Transport,” which may be used to carry such application=20 information; however, it is not clear whether this meets the = proposed=20 requirements of the IETF. As such, SG11 is awaiting further = information from=20 the IETF.




Greg Ratta, Vice = Chairman, ITU-T=20 SG 11, Signalling requirements and protocols
Lucent Technologies = Tel: +1=20 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com=20 ------=_NextPart_000_0076_01C05F6D.66AA88A0-- From rem-conf Wed Dec 06 13:13:31 2000 From rem-conf-request@es.net Wed Dec 06 13:13:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143llc-00069u-00; Wed, 6 Dec 2000 13:06:20 -0800 Received: from sigma.cisco.com (cisco.com) [171.69.63.142] by mail1.es.net with esmtp (Exim 1.81 #2) id 143llb-00069R-00; Wed, 6 Dec 2000 13:06:19 -0800 Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA25002; Wed, 6 Dec 2000 11:32:56 -0800 (PST) Message-Id: <4.3.1.0.20001206110620.018ce1d0@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 06 Dec 2000 11:34:35 -0800 To: "Hari Krishna Vuppaladhadiam" , , , From: Bruce A Thompson Subject: Re: Comments on AAL Type 2 Signalling Cc: , , , , , , , In-Reply-To: <007901c05fb0$75af9d20$03000004@hariv.domain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:15 AM 12/06/2000 -0800, Hari Krishna Vuppaladhadiam wrote: > >Hello, > > I have a few doubts regarding signalling/tones data transfer on AAL-2. ITU has suggested several tones like the following: >Dial, Recall Dial, Ringing, Busy, Congestion, Special information, Warning and Record tone (apart from PBX tones). >How are these carried over by AAL-2? I think you are talking about I.366.2 (AAL Type 2 Service Specific Convergence Sublayer for Trunking). The message above has nothing to do with I.366.2. It is about I.366.1 (Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2). This message is the result of a mtg we had with ITU SG13 to address issues we had in making draft-buffam-avt-crtp-over-aal2-01.txt work with I.366.1. The message is just stating what is being done in SG13 and SG11 to address the issues raised by this draft. Draft-buffam-avt-crtp-over-aal2-01.txt has generalized the original contribution draft-buffam-avt-crtp-over-aal2-00.txt which was called "IP/UDP/RTP Header Compression over AAL2" into "PPP over AAL2". Because of this change, we are presenting draft-buffam-avt-crtp-over-aal2-01.txt in PPPEXT and not in AVT. While the generalization from "IP/UDP/RTP Header Compression" to "PPP" was straight forward in the draft, it caused the draft to move from one working group to another. Sorry for any confusion caused by this. Note that no action will be taken on this draft in the ITU unless it moves forward. We are presenting draft-buffam-avt-crtp-over-aal2-01.txt in PPPEXT to determine whether it does indeed move forward. Bruce T > >Regards >Hari V > >>-----Original Message----- >>From: Greg Ratta <gratta@lucent.com> >>To: ietf-ppp@merit.edu <ietf-ppp@merit.edu>; rem-conf@es.net <rem-conf@es.net> >>Cc: ian.rytina@ericsson.com <ian.rytina@ericsson.com>; mmcloughlin@asc.com <mmcloughlin@asc.com>; hiramatsu.yukio@lab.ntt.co.jp <hiramatsu.yukio@lab.ntt.co.jp>; arshey.odedra@itu.int <arshey.odedra@itu.int>; sob@harvard.edu <sob@harvard.edu>; mankin@east.isi.edu <mankin@east.isi.edu>; narten@raleigh.ibm.com <narten@raleigh.ibm.com>; nordmark@eng.sun.com <nordmark@eng.sun.com> >>Date: Wednesday, December 06, 2000 9:59 AM >>Subject: Comments on AAL Type 2 Signalling >> >>This message represents a communication to the IETF AVT and PPPEXT WGs that was approved by ITU-T SG 11 at its December 6, 2000 meeting. For followup technical discussions, please correspond with Mr. Ian Rytina, Q15/11 Rapporteur ({ HYPERLINK mailto:ian.rytina@ericsson.com }ian.rytina@ericsson.com), and Mr. Mike McLoughlin (mmcloughlin@asc.com) >> >>1. Introduction >>This communication has been generated by ITU- T SG11 as a result of information received from ITU-T SG13 related to the transport of PPP and/or CRTP over AAL type 2. >> >> >> >>2. Request for Signalling of I.366.1 Applications >>It has been brought to the attention of SG11 that the IETF is planning to use the SSSAR service of ITU-T Recommendation I.366.1. It is the understanding of the participants of SG 11 that the IETF is going to use particular UUI code points to distinguish among different forms of PDUs. In addition, more than one application may use this SSSAR. >> >> >> >>It has been communicated that SG13 initiated the definition of an SSCF to SSSAR (as a new Annex to ITU-T Recommendation I.366.1). In addition to this new SSCF, there is a need to signal what application is making use of this new Annex. >> >> >> >>SG11 have noted that communication has been initiated between SG13 and the IETF. SG 11 anticipate that there may be a future request to provide a signalling mechanism for such applications, once the IETF indicate which applications are required to be supported (e.g. PPP over AAL type 2 and/or CRTP over AAL type 2, similar to that outlined in draft-buffam-avt- crtp-over- aal2-01.txt). SG11 note that these are valid applications of AAL type 2 and are happy to provide the necessary signalling support. >> >> >> >>The participants in SG 11 would like to point out that ITU-T Recommendations Q.2630.1 and Q.2630.2 already include a parameter entitled Served User Transport, which may be used to carry such application information; however, it is not clear whether this meets the proposed requirements of the IETF. As such, SG11 is awaiting further information from the IETF. >> >> >> >> >>Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols >>Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com Bruce Thompson Cisco Systems : IOS Products email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From rem-conf Wed Dec 06 15:31:05 2000 From rem-conf-request@es.net Wed Dec 06 15:31:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143nxd-0000e4-00; Wed, 6 Dec 2000 15:26:53 -0800 Received: from darius.concentric.net [207.155.198.79] by mail1.es.net with esmtp (Exim 1.81 #2) id 143nxc-0000du-00; Wed, 6 Dec 2000 15:26:52 -0800 Received: from newman.concentric.net (newman.concentric.net [207.155.198.71]) by darius.concentric.net (8.9.1a/(98/12/15 5.12)) id SAA20061; Wed, 6 Dec 2000 18:25:50 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from vaio.tbt.com (ts023d04.lax-ca.concentric.net [206.173.243.112]) by newman.concentric.net (8.9.1a) id SAA26406; Wed, 6 Dec 2000 18:25:40 -0500 (EST) Message-Id: <5.0.2.1.2.20001206150121.05abba00@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 06 Dec 2000 15:21:22 -0800 To: rem-conf@es.net (IETF AVT WG) From: "Michael A. Dolan" Subject: Re: draft-ietf-avt-smpte292-video-01.txt Cc: William.C.Miller@abc.com In-Reply-To: <200012011936.TAA40028@chai.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, et al: The VP of Engineering of SMPTE asked me today to communicate that you may wish to consider a different content type for this other than "video/SMPTE 292M". FYI, SMPTE is currently considering the possibility of registering its own tree with IANA for other reasons, so if it makes sense to everyone, maybe this would be "video/smpte.292" or something similar to that. Although obviously this choice would require some coordination with SMPTE. I am also told that technical comments from a couple SMPTE members are forthcoming - just FYI. Thanks and regards, Mike At 07:36 PM 12/1/00 +0000, Ladan Gharai wrote: >We've missed the deadline :( Please comment! - Ladan. > > > > > > > > > > >INTERNET-DRAFT Ladan Gharai > USC/ISI > Gary Goncher > Tektronix > Colin Perkins > USC/ISI > David Richardson > University of Washington > Allison Mankin > USC/ISI > Nov 24, 2000 > > > > RTP Payload Format for SMPTE 292M > > > > > > >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 specifies a packetization scheme for encapsulating >uncompressed HDTV as defined by SMPTE 292M into a payload format for >the Real-Time Transport Protocol (RTP). The RTP packet counter is > > > >draft-ietf-avt-smpte292-video-01.txt [Page 1] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. > > > >1. Introduction > > >The serial digital interface, SMPTE 292M[1], defines a universal medium >of interchange for uncompressed HDTV between various types of video >equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s >(and 1.485/1.001 Gb/s). Source formats transfered by SMPTE 292M are >SMPTE 260M, 295M, 274M and 296M. Source data for these formats are >10-bit words, sampled at 4:2:2. In this memo we specify how to >transfer SMPTE 292M over RTP. > >This memo only addresses the transfer of uncompressed HDTV. Compressed >HDTV is a subset of MPEG-2 [3], which is fully described in document >A/53 [4] of the Advanced Television Standards Committee. The ATSC has >also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [5]. >Therefore: > >1. The HDTV transport system is a compatible subset of the MPEG-2 >transport system. Section 2 of RFC 2250 [7] describes the RTP payload >for MPEG-2's transport system, where multiple fixed length (188 bytes) >MTS packets are aggregated into a single RTP packet. > >2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional >restrictions. Section 3 of RFC 2250 describes a packetization scheme for >MPEG-2 elementary streams. The additional restrictions of HDTV do not >have any implications for RTP packetization. > > >2. Conventions Used in this Document > >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >document are to be interpreted as described in RFC 2119[10]. > > > >3. Payload Design > >Each video frame of SMPTE 292M is packetized into a number of constant >size RTP packets. All active, vertical blanking and timing information >is packetized. The end of a frame is marked by the M bit in the RTP >header. A single packet may contain data for two consecutive scan >lines. The SMPTE 292M decoder uses the sync info in the scan lines to >detect the start of scan lines. > > > >draft-ietf-avt-smpte292-video-01.txt [Page 2] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >A single packet may also contain information from adjacent scan lines in >two consecutive frames, or by agreement between sender and receiver the >last packet of a video frame may be padded to the full length of all >292M RTP packets, in which case a new will frame start in a new packet. > >The standard 16 bit RTP sequence counter is extended to 32 bits to >accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of >at least 1kByte, 32bits allows for an approximate 6 hour period before >the sequence counter wraps around. > >A 10Mhz timestamp is used as the RTP header's timestamp. This allows the >receiver to reconstruct the timing of the SMPTE 292M stream, without >knowledge of the exact type of source format (e.g. SMPTE 274M or SMPTE >296M). > >Given SMPTE 292M's 4:2:2 color subsampling, scan line fragmentation MUST >occur on sample-pair boundaries, such that Y and Cb and Cr values are >not split across packets. This means the payload section of each packet >will be a multiple of 40bits. In addition, to ensure unique timestamps, >each packet SHOULD contain more than 8 video samples (20 bytes). > > > > > >4. RTP Packetization > >The standard RTP header is followed by a 4 byte payload header, and the >payload data. > > 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 |P|X| CC |M| PT | sequence# (low bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | time stamp | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ssrc | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | sequence# (high bits) | unused | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >4.1. The RTP Header > >The following fields of the RTP fixed header are used for SMPTE 292M >encapsulation: > > > > >draft-ietf-avt-smpte292-video-01.txt [Page 3] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >Payload Type (PT): 7bits > A dynamically allocated payload type field which designates the > payload as SMPTE 292M. > >Timestamp: 32 bits > The timestamp field shall be defined from a counter at 10 MHz. The > timestamp shall be defined as the arrival time of the first 20-bit > video sample to be transmitted in the current packet. At an arrival > rate of 74.25 MHz for 20-bit SMPTE 292M video samples with > 24/30/60Hz frame rates, the timestamp will be unique for packets > with more than 8 video samples (20 bytes) and therefore, each > packet SHOULD contain more than 8 samples. Timestamps shall > increase monotonically until they roll over at 32 bits. > > One possible means of deriving the 10 MHz clocks is from a GPS > (Global Positioning System) board. These boards have a disciplined > oscillator that is synchronized to GPS time. The disciplined > oscillator can be as accurate as 1 in 10-12, but is more typically > 1 in 10-8. Thus clocks at widely separate locations can be > synchronized with an accuracy of 100 ns for video timing recovery. > >Marker bit (M): 1bit > The Marker bit denotes the end of a video frame, and is set to 1 > for the last packet of the video frame and is otherwise set to 0 > for all other packets. > >Sequence Number (low bits): 16 bits > The low order bits for RTP sequence counter. The standard 16 bit > RTP sequence number is augmented with another 16 bits in the > payload header in order to accommodate the 1.485Gb/s data rate of > SMPTE 292M. > > >4.2. Payload Header > >Sequence Number (high bits): 16bits > The high order bits for the 32bit RTP sequence counter. > >Unused: 16bits > MUST be set to zero at the sender, and ignored at the receiver. > > >4.3. Payload Format > >For 4:2:2 color subsampling Cb and Cr values are subsampled by a factor >of two horizontally and are co-sited with even numbered Y samples. >Therefore, Cb, Cr and Y samples MUST be arranged and transmitted in the >following order: > > > >draft-ietf-avt-smpte292-video-01.txt [Page 4] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > > Cb, Y, Cr, Y, Cb, Y, Cr, ... >where the first Cb, Y, Cr sequence refers to co-sited luminance and >color-difference samples, and the next Y belongs to the next luminance >sample. > >Therefore, as set forth in RFC2431 [11], for 10-bit words, each group of >four samples must be encoded into a 40-bit word (five octets) prior to >transmission. The following is a representation of a 720 sample packet >with 10-bit quantization: > > 0 1 2 3 > 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 > +---------+---------+---------+---------+ > | Cb0 | Y0 | Cr0 | Y1 | > +---------+---------+---------+---------+ > | Cb1 | Y2 | Cr1 | Y3 | > +---------+---------+---------+---------+ > . > . > . > +---------+---------+---------+---------+ > | Cb359 | Y718 | Cr359 | Y719 | > +---------+---------+---------+---------+ > (Note that the word width is 40 bits) > +-------+-------+-------+-------+-------+ > Octets: | 0 | 1 | 2 | 3 | 4 | > +-------+-------+-------+-------+-------+ > >The octets shown in these diagrams are transmitted in network bit and >byte order, that is, left-to-right as shown. > > >5. RTCP Considerations > >RFC1889 recommends transmission of RTCP packets every 5 seconds or at a >reduced minimum in seconds of 360 divided by the session bandwidth in >kilobits/seconds. At 1.485Gb/s the reduced minimum interval computes to >0.2ms or 4028 packets per second. > >It should be noted that the sender's octet count in SR packets wraps >around in 23 seconds, and that the cumulative number of packets lost >wraps around in 93 seconds. This means these two fields cannot >accurately represent octet count and number of packets lost since the >beginning of transmission, as defined in RFC1889. Therefore for network >monitoring purposes other means of keeping track of these variables >should be used. > > > > > >draft-ietf-avt-smpte292-video-01.txt [Page 5] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >6. MIME Registration > >This document defines a new RTP payload name and associated MIME type, >SMPTE 292M. The registration forms for MIME type for SMPTE 292M video is >enclosed below: > >MIME media type name: video > >MIME subtype name: SMPTE 292M > >Required parameters: None > >Optional parameters: None > >Encoding considerations: SMPTE 292M video can be transmitted with > RTP as specified in "draft-ietf-avt-smpte292-video-01". > >Security considerations: None > >Interoperability considerations: NONE > >Published specification: SMPTE 292M > draft-ietf-avt-smpte292-video-01 > >Applications which use this media type: > Video communication. > >Additional information: None > >Magic number(s): None > >File extension(s): DV > >Macintosh File Type Code(s): None > >Person & email address to contact for further information: > Ladan Gharai > >Intended usage: COMMON > >Author/Change controller: > Ladan Gharai > > >7. Mapping to SDP Parameters > >Parameters are mapped to SDP [9] as follows: > > > > >draft-ietf-avt-smpte292-video-01.txt [Page 6] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > > m=video 23456 RTP/AVP 111 > a=rtpmap:111 SMPTE 292M/10000000 > a=fmtp:111 length=1400 > >In this example, a dynamic payload type 111 is assumed for SMPTE 292M, >with packet sizes of 1400bytes. > > > >8. Security Considerations > >RTP packets using the payload format defined in this specification are >subject to the security considerations discussed in the RTP >specification, and any appropriate RTP profile. This implies that >confidentiality of the media streams is achieved by encryption. > >This payload type does not exhibit any significant non-uniformity in the >receiver side computational complexity for packet processing to cause a >potential denial-of-service threat. > >It is perhaps to be noted that the bandwidth of this payload is high >enough (1.5 Gbps without the RTP overhead) to cause potential for >denial-of-service if transmitted onto most currently available Internet >paths. In the absence from the standards track of a suitable congestion >control mechanism for flows of this sort, use of the payload should be >narrowly limited to suitably connected network endpoints and great care >taken with the scope of multicast transmissions. This potential threat >is common to all high bit rate applications. > > > >9. IANA Considerations > >See Section 6. > > >10. Full Copyright Statement > >Copyright (C) The Internet Society (2000). All Rights Reserved. > >This document and translations of it may be copied and furnished to >others, and derivative works that comment on or otherwise explain it or >assist in its implementation may be prepared, copied, published and >distributed, in whole or in part, without restriction of any kind, >provided that the above copyright notice and this paragraph are included >on all such copies and derivative works. > >However, this document itself may not be modified in any way, such as by > > > >draft-ietf-avt-smpte292-video-01.txt [Page 7] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >removing the copyright notice or references to the Internet Soci- ety or >other Internet organizations, except as needed for the purpose of >developing Internet standards in which case the procedures for >copyrights defined in the Internet Standards process must be fol- lowed, >or as required to translate it into languages other than English. > >The limited permissions granted above are perpetual and will not be >revoked by the Internet Society or its successors or assigns. > >This document and the information contained herein is provided on an "AS >IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK >FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT >LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT >INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR >FITNESS FOR A PARTICULAR PURPOSE." > > >11. Authors' Addresses > > > Ladan Gharai > ladan@isi.edu > > Gary Goncher > ggoncher@tek.com > > Colin Perkins > csp@isi.edu > > David Richardson > drr@u.washington.edu > > Allison Mankin > mankin@isi.edu > > > > >12. Bibliography > >[1] Society of Motion Picture and Television Engineers, > Bit-Serial Digital Interface for High-Definition Television > Systems, SMPTE 292M, 1998. > >[2] Society of Motion Picture and Television Engineers, > 1280*720 Scanning, Analog and Digital Representation and Analog > Interfaces, SMPTE 296M, 1998. > > > > >draft-ietf-avt-smpte292-video-01.txt [Page 8] > > > > > >INTERNET-DRAFT Nov 24, 2000 > > >[3] ISO/IEC International Standard 13818-2; "Generic coding of > moving pictures and associated audio information: Video", 1996. > >[4] ATSC Digital Television Standard Document A/53, September 1995, > http://www.atsc.org > >[5] ISO/IEC International Standard 13818-1; "Generic coding of > moving pictures and associated audio information: Systems",1996. > >[6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport > protocol for real time Applications", RFC 1889, IETF, > January 1996. > >[7] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for > MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. > >[8] Schulzrinne, "RTP Profile for Audio and Video Conferences with > Minimal Control", RFC 1890, IETF, January 1996. > >[9] M. Handley and V. Jacobson, "SDP: Session Description Protocol", > RFC 2327, April 1998. > >[10] IETF RFC 2119, "Key words for use in RFCs to Indicate > Requirement Levels". > >[11] D. Tynan, "RTP Payload Format for BT.656 Video Encoding", > RFC 2431, October 1998. > > > > > > > > > > > > > > > > > > > > > > > > >draft-ietf-avt-smpte292-video-01.txt [Page 9] ------------------------------------------------------ Michael A. Dolan, Representing DIRECTV, (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 From rem-conf Wed Dec 06 16:32:08 2000 From rem-conf-request@es.net Wed Dec 06 16:32:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143owQ-0001yu-00; Wed, 6 Dec 2000 16:29:42 -0800 Received: from omneon.com (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 143owO-0001xN-00; Wed, 6 Dec 2000 16:29:40 -0800 Received: by webmail1.omneon.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 16:28:41 -0800 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B14177E2@webmail1.omneon.com> From: Bill Nowicki To: "'Michael A. Dolan'" , rem-conf@es.net Cc: William.C.Miller@abc.com, 'Colin Perkins' Subject: RE: draft-ietf-avt-smpte292-video-01.txt Date: Wed, 6 Dec 2000 16:28:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I will make my usual comment that I think a better approach would be to specify a single RTP payload type for sampled uncompressed video. The specific sample parameters (8 bit vs. 10, number of lines and pixels, aspect ratio or square, frame rate, etc.) could be format parameters on the fmtp sdp line. That way the same payload spec could be used for both down-sampled video (usually the first step before low bitrate encodings) all the through standard definition to the plethora of high definitions. That is not to take anything away from the authors of this draft. It is great they are publishing their spec and would love to hear any issues they discover in their work. But a standards track document should not reflect the peculiarities of any particular implementation. A spec that only works at 1.5 Gigabits per second will not be widely deployed for a while, but is interesting research. Also related note to Colin: I do not think anyone ever implemented the BT656 payload type, so that one can be deprecated. A general uncompressed payload type should be able to handle the standard definitions specified in that document too. Bill Nowicki, Omneon Video, 408-585-5126 From rem-conf Wed Dec 06 20:43:39 2000 From rem-conf-request@es.net Wed Dec 06 20:43:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143sqM-0004G5-00; Wed, 6 Dec 2000 20:39:42 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 143sqI-0004Fv-00; Wed, 6 Dec 2000 20:39:40 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA00684; Wed, 6 Dec 2000 23:12:19 -0500 Message-Id: <200012070412.XAA00684@purple.east.isi.edu> To: "Michael A. Dolan" cc: rem-conf@es.net (IETF AVT WG), William.C.Miller@abc.com Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-Reply-To: Message from "Michael A. Dolan" of "Wed, 06 Dec 2000 15:21:22 PST." <5.0.2.1.2.20001206150121.05abba00@cts.com> Date: Wed, 06 Dec 2000 23:12:19 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mike, --> "Michael A. Dolan" writes: >The VP of Engineering of SMPTE asked me today to communicate that you may >wish to consider a different content type for this other than "video/SMPTE >292M". > >FYI, SMPTE is currently considering the possibility of registering its own >tree with IANA for other reasons, so if it makes sense to everyone, maybe >this would be "video/smpte.292" or something similar to that. Although >obviously this choice would require some coordination with SMPTE. If SMPTE registers a set of MIME types, I'm happy for this draft to follow that recommendation. >I am also told that technical comments from a couple SMPTE members are >forthcoming - just FYI. Look forward to them. Colin From rem-conf Wed Dec 06 20:43:41 2000 From rem-conf-request@es.net Wed Dec 06 20:43:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143ssi-0004Go-00; Wed, 6 Dec 2000 20:42:08 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 143ssd-0004Ge-00; Wed, 6 Dec 2000 20:42:05 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA00702; Wed, 6 Dec 2000 23:26:51 -0500 Message-Id: <200012070426.XAA00702@purple.east.isi.edu> To: Bill Nowicki cc: "'Michael A. Dolan'" , rem-conf@es.net, William.C.Miller@abc.com Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-Reply-To: Message from Bill Nowicki of "Wed, 06 Dec 2000 16:28:32 PST." <03AB3CB11CBED3118A4F009027B0C2B14177E2@webmail1.omneon.com> Date: Wed, 06 Dec 2000 23:26:51 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill, I think there's scope for this approach to co-exist with a generic payload format for uncompressed video. The focus is somewhat different - closer to circuit emulation than many other payload formats - and if SMPTE 292M is a widely used format, could be very useful for device interconnect. I'd be interested in hearing opinions from others on the relative merits of this proposal, versus a generic uncompressed video format. Colin --> Bill Nowicki writes: >I will make my usual comment that I think a better approach would be to >specify a single RTP payload type for sampled uncompressed video. The >specific sample parameters (8 bit vs. 10, number of lines and pixels, aspect >ratio or square, frame rate, etc.) could be format parameters on the fmtp >sdp line. That way the same payload spec could be used for both down-sampled >video (usually the first step before low bitrate encodings) all the through >standard definition to the plethora of high definitions. > >That is not to take anything away from the authors of this draft. It is >great they are publishing their spec and would love to hear any issues they >discover in their work. But a standards track document should not reflect >the peculiarities of any particular implementation. A spec that only works >at 1.5 Gigabits per second will not be widely deployed for a while, but is >interesting research. > >Also related note to Colin: I do not think anyone ever implemented the BT656 >payload type, so that one can be deprecated. A general uncompressed payload >type should be able to handle the standard definitions specified in that >document too. > >Bill Nowicki, Omneon Video, 408-585-5126 From rem-conf Wed Dec 06 21:41:24 2000 From rem-conf-request@es.net Wed Dec 06 21:41:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143tmN-0005yp-00; Wed, 6 Dec 2000 21:39:39 -0800 Received: from (ns.timsnet.co.jp) [210.251.104.141] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 143tmL-0005yY-00; Wed, 6 Dec 2000 21:39:37 -0800 Received: from 79NGW5268 (1Cust94.tnt2.feathersound.fl.da.uu.net [63.39.114.94]) by ns.timsnet.co.jp (8.8.5/8.8.5) with SMTP id MAA10763; Thu, 7 Dec 2000 12:14:53 +0900 From: RVh42x44J@zwallet.net Message-Id: <200012070314.MAA10763@ns.timsnet.co.jp> DATE: 06 Dec 00 10:18:39 PM TO: nelida102@excite.net SUBJECT: Pager for ONLY $59.99 with Service for 1 Year X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list HOW DO THEY DO IT???? Well, its simple PAGE IT NOW buys BRAND NEW PAGERS direct from the manufacturer in large quantities passing the savings on to the consumer. Call now 1-888-212-7921 code # 322 to place order!!!!! WHAT DO I GET FOR ONLY $59.99???? You get a brand new Philips Myna pager with 1 year of airtime. This means unlimited pages in any city in the US (local service). The Myna pager has a 32 number capacity with 9 distinct rings and vibration. It has a built in alarm and comes with a 1-year warranty from the manufacturer. We ship all orders within 24 hours and have a toll free hotline (1-888-212-7921 code # 322) open for service issues 24 hours a day, 365 days a year. BEST PART OF DEAL!!!! You can renew your pager service at the end of the year for only $36 per year and if you act fast you will receive free activation at a $20.00 savings. FINAL BONUS!!!! Get basic Voice Mail added to your service for 1 year for only $20 more! FINAL FINAL BONUS!!!! Buy 3 pagers or more and pay only $49.99 each. These pagers make great Holiday Gifts along with many other helpful uses, such as locating your kids, or when you are needed in case of emergencies, the uses are endless. We can drop ship with a Happy Holiday card for you as well. This is a gift that can be utilized for a whole year, and instead of trying to come up with an idea for next years gift, you can simply renew the service. CALL NOW!!!!!! DON'T DELAY!!!!!! OFFER ENDS SOON!!!!!!!! 1-888-212-7921 code # 322 See our Brand New Pager http://pagerman65.tripod.com Shipping and Handling charges are $5.00 for as many pagers as you order. Special Offer Code: 322 without this code you cant get the free activation on the pager (this is a $20 savings) Corporate Headquarters: Page It Now Inc. 1345 Cortez St. Denver, CO 80221 303-428-5862 Fax 303-464-8218 From rem-conf Thu Dec 07 03:28:19 2000 From rem-conf-request@es.net Thu Dec 07 03:28:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 143yc7-0001W1-00; Thu, 7 Dec 2000 02:49:23 -0800 Received: from smtp2.cluster.oleane.net [195.25.12.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 143yc5-0001Vr-00; Thu, 7 Dec 2000 02:49:21 -0800 Received: from oleane (dyn-1-1-002.Vin.dialup.oleane.fr [195.25.4.2]) by smtp2.cluster.oleane.net with SMTP id eB7AnIN42312 for ; Thu, 7 Dec 2000 11:49:18 +0100 (CET) Message-ID: <001401c0603b$aa0ba240$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: VoDSL Europe Date: Thu, 7 Dec 2000 11:51:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C06044.0B7C1DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C06044.0B7C1DE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable VoDSL Europe : the deployment scenario, Paris 16-19 January. The international conference. Visit the real first VoDSL exhibition ever organized: http://www.upperside.fr/bavodsl2001.htm ------=_NextPart_000_0011_01C06044.0B7C1DE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
VoDSL Europe : the = deployment=20 scenario, Paris 16-19 January.
The international = conference.
Visit the real first VoDSL = exhibition=20 ever organized:
http://www.upperside.fr/= bavodsl2001.htm
 
------=_NextPart_000_0011_01C06044.0B7C1DE0-- From rem-conf Thu Dec 07 08:22:56 2000 From rem-conf-request@es.net Thu Dec 07 08:22:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1443g4-0005CL-00; Thu, 7 Dec 2000 08:13:48 -0800 Received: from uhura.concentric.net [206.173.118.93] by mail1.es.net with esmtp (Exim 1.81 #2) id 1443g3-0005CB-00; Thu, 7 Dec 2000 08:13:47 -0800 Received: from marconi.concentric.net (marconi.concentric.net [206.173.118.71]) by uhura.concentric.net (8.9.1a/(98/12/15 5.12)) id LAA14299; Thu, 7 Dec 2000 11:12:44 -0500 (EST) [1-800-745-2747 The Concentric Network] Received: from vaio.tbt.com (ts029d06.lax-ca.concentric.net [206.173.248.162]) by marconi.concentric.net (8.9.1a) id LAA02474; Thu, 7 Dec 2000 11:12:40 -0500 (EST) Message-Id: <5.0.2.1.2.20001207073248.05a0d310@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 07 Dec 2000 07:35:44 -0800 To: rem-conf@es.net (IETF AVT WG) From: "Michael A. Dolan" Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-Reply-To: <200012070426.XAA00702@purple.east.isi.edu> References: <03AB3CB11CBED3118A4F009027B0C2B14177E2@webmail1.omneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Remember that 292M is synchronous and runs at the clock rate no matter what. It is not tolerant of dropped data and doesn't run other than at the rates noted in the ID (which are pretty high). Use of this would have to be in a pretty special scenario I would think. Can the authors elaborate on their intended usage here and what transports it might be used on? Thanks, Mike At 11:26 PM 12/6/00 -0500, Colin Perkins wrote: >Bill, > >I think there's scope for this approach to co-exist with a generic payload >format for uncompressed video. The focus is somewhat different - closer to >circuit emulation than many other payload formats - and if SMPTE 292M is a >widely used format, could be very useful for device interconnect. > >I'd be interested in hearing opinions from others on the relative merits of >this proposal, versus a generic uncompressed video format. > >Colin > > > >--> Bill Nowicki writes: > >I will make my usual comment that I think a better approach would be to > >specify a single RTP payload type for sampled uncompressed video. The > >specific sample parameters (8 bit vs. 10, number of lines and pixels, aspect > >ratio or square, frame rate, etc.) could be format parameters on the fmtp > >sdp line. That way the same payload spec could be used for both down-sampled > >video (usually the first step before low bitrate encodings) all the through > >standard definition to the plethora of high definitions. > > > >That is not to take anything away from the authors of this draft. It is > >great they are publishing their spec and would love to hear any issues they > >discover in their work. But a standards track document should not reflect > >the peculiarities of any particular implementation. A spec that only works > >at 1.5 Gigabits per second will not be widely deployed for a while, but is > >interesting research. > > > >Also related note to Colin: I do not think anyone ever implemented the BT656 > >payload type, so that one can be deprecated. A general uncompressed payload > >type should be able to handle the standard definitions specified in that > >document too. > > > >Bill Nowicki, Omneon Video, 408-585-5126 ------------------------------------------------------ Michael A. Dolan, Representing DIRECTV, (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 From rem-conf Thu Dec 07 10:07:02 2000 From rem-conf-request@es.net Thu Dec 07 10:07:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1445Jt-0006z0-00; Thu, 7 Dec 2000 09:59:01 -0800 Received: from star.project-sho.co.jp (project-sho.co.jp) [210.163.174.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 1445Jp-0006yW-00; Thu, 7 Dec 2000 09:58:58 -0800 Received: from max1-42.peoria.corecomm.net_[209.81.190.170] (max1-42.peoria.corecomm.net [209.81.190.170]) by project-sho.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/3.6W) with SMTP id CAA00738; Fri, 08 Dec 2000 02:57:53 +0900 From: skeeter@aclnet.cz Received: from tcs.co.in by max1-42.peoria.corecomm.net with ESMTP; Thu, 07 Dec 2000 12:00:36 -0600 Message-ID: <000009815a1c$00000797$00007584@tcs.co.in> To: Subject: Does your stock portfolio look like "SWISS" cheese? 30084 Date: Thu, 07 Dec 2000 12:00:28 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Currency Trading Made Simple!
Do You Have The Yen To Be a A Millionaire?

 100% return in less than 90 days!
Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

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

Example:

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

To receive your "FREE NO OBLIGATION" information packet


click here
email us the following requested information:

1.Complete name (required)

2.Phone number (required)

3.State (required)

4.Email address
click here

 Request Without Phone Number Will Not Be Proce= ssed!











To be removed: mailto:remove@5homes.cc

=

From rem-conf Thu Dec 07 13:02:04 2000 From rem-conf-request@es.net Thu Dec 07 13:02:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14487x-0002CM-00; Thu, 7 Dec 2000 12:58:53 -0800 Received: from (tolex.co.jp) [210.145.100.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 14487w-0002CC-00; Thu, 7 Dec 2000 12:58:52 -0800 Received: from LE8qVmRiz ([63.26.114.56]) by tolex.co.jp (Lotus Domino Release 5.0.2c) with SMTP id 2000120805574115:12002 ; Fri, 8 Dec 2000 05:57:41 +0900 Date: Thu, 7 Dec 2000 12:57:18 +0900 From: 9lOfLbGuc@aha.ru Message-ID: Subject: NEW CAR? NEW TRUCK? X-MIMETrack: Itemize by SMTP Server on TOLEX_NOTES/tolex(Release 5.0.2c|16 February 2000) at 2000/12/08 05:57:43 AM, MIME-CD by Trend MailScan on TOLEX_NOTES/tolex(Release 5.0.2c|16 February 2000) at 2000/12/08 05:57:43 AM, MIME-CD complete at 2000/12/08 05:57:43 AM, Serialize by Router on TOLEX_NOTES/tolex(Release 5.0.2c|16 February 2000) at 2000/12/08 05:59:28 AM 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 The Lowest Price On Your New Car Without Negotiating For Hours! Would you like to get a straight-forward answer from a sales professional that does not have to "check with his manager"? * Prices based on dealer invoice. * No aggravation. * Save Time And Money. * All brands, new, used, take your pick. * Let Someone Else Do The Work. Click Below: http://eezeecredit.com/taco/apa3.html From rem-conf Thu Dec 07 18:51:12 2000 From rem-conf-request@es.net Thu Dec 07 18:51:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144DXX-0000Sy-00; Thu, 7 Dec 2000 18:45:39 -0800 Received: from (snmarket.ru) [194.186.227.90] by mail1.es.net with smtp (Exim 1.81 #2) id 144DXS-0000RU-00; Thu, 7 Dec 2000 18:45:35 -0800 Received: (qmail 32673 invoked by uid 506); 7 Dec 2000 19:57:38 -0000 Received: from kcx-ks18a-33.rasserver.net (HELO kcx-ks18a-33.rasserver.net??205.185.0.33?) (205.185.0.33) by mail.snmarket.ru with SMTP; 7 Dec 2000 19:57:38 -0000 Received: from dns2.aoyama-syouji.co.jp by kcx-ks18a-33.rasserver.net with ESMTP; Thu, 07 Dec 2000 14:01:48 -0600 Message-ID: <000004025e03$00005b7f$0000524a@dns2.aoyama-syouji.co.jp> To: From: belush@371.net Subject: Be the First in Your Area to Market This One! 21066 Date: Thu, 07 Dec 2000 14:01:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: belush@371.net X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Get The Inside Track On The NEXT Market Craze of the 21st Century! Discover AN ALL CASH BUSINESS that is easy to operate, simple to manage, has NO COMPETITION, and NO INVENTORY OR PRODUCT HASSLES! This is an opportunity in an established "$34 BILLION industry, where over 90% of the owners are still in business. " Small Business Administration If you had the exclusive marketing rights to the first arcade video games, where would you be today? The creators of that concept made millions almost overnight, because their product was so hot and people could not get enough of it. What if you had the opportunity to get in on the next hot business craze? An amazing money generating machine called the "Coin Shooter" has been test marketed and perfected for two years, and is now ready for National Roll Out! Marketing areas will go FAST-Get yours NOW! The Coin Shooter is a sports challenge. A game of skill. Shoot a quarter through the basketball hoop and win a prize. You could win a free meal at a restaurant, maybe win a free oil change at an auto repair shop, or maybe win a free car wash! Your business owners can entertain waiting customers while making profits! Place this game of skill in restaurants, sports bars, car washes, truck stops, mini-markets, and tons of other locations. Can you imagine yourself owning 50, 100, or 200 of these incredible machines? Each one of these units can collect as much $10 -$15 a day, or more per machine! Can you imagine owning multiple machines in just one location? Can you imagine just 5-10 locations? you could earn $100,000 per year just working part-time! Immediate cash flow 24 hours a day, 7 days a week with a huge residual income. No overhead, no inventory, no employees Prime locations are available now! ACT NOW and receive our FREE FINANCIAL SUCCESS PACKAGE and, as a BONUS, we will include FREE Shipping and Handling and EXTRA Machines! (Ask for Details) All you need to do to get started is send us an E-Mail with the following info and we will contact you by phone ASAP. Type in the following required information and mailto:goodstuff22@yours.com?subject=PleaseCall4CoinShooter NAME CITY STATE PHONE NUMBER BEST TIME TO CALL E-MAIL ADDRESS mailto:goodstuff22@yours.com?subject=PleaseCall4CoinShooter The information you submit will be kept confidential and will be not used for anything except package verification. You must be over 18 years old to qualify for this program. Copyright 2000. All rights reserved. The manufacturer does not warranty or guarantee any income projections, minimum or maximum earnings, either written or verbally, whatsoever. Any income derived by the Coin Shooter will depend on such factors as prevailing market conditions, locations, service provided, etc. These are factors the manufacturer has absolutely no control over. Your results could vary from those shown here. You could be more or less successful than the people above depending on your determination to succeed. We can help you as best as we can, but you are ultimately as successful as you want to be. (REMOVAL INSTRUCTIONS) This mailing is done by an independent marketing company. Please do not use the reply to this e-mail, an e-mail reply cannot be read! If you would like to be removed from our mailing list just click below and send us a remove request email. mailto:nada4me784@samerica.com?subject=RemoveCoinShooterPromo From rem-conf Thu Dec 07 19:18:23 2000 From rem-conf-request@es.net Thu Dec 07 19:18:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144E0v-0001cQ-00; Thu, 7 Dec 2000 19:16:01 -0800 Received: from tog-wakko2.prognet.com (lithium.dev.prognet.com) [207.188.29.249] by mail1.es.net with esmtp (Exim 1.81 #2) id 144E0u-0001cG-00; Thu, 7 Dec 2000 19:16:00 -0800 Received: from localhost (ghori@localhost) by lithium.dev.prognet.com (8.9.3/8.9.3) with ESMTP id TAA10728; Thu, 7 Dec 2000 19:15:04 -0800 X-Authentication-Warning: lithium.dev.prognet.com: ghori owned process doing -bs Date: Thu, 7 Dec 2000 19:15:04 -0800 (PST) From: Go Hori X-Sender: ghori@lithium.dev.prognet.com To: Colin Perkins cc: rem-conf@es.net Subject: Re: RTP interoperability testing In-Reply-To: <200012042356.eB4Nuah27109@hafez.east.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi! Realnetowkrs demonstrated full bidirectional interop. with Apple Quicktime is as follows: 44kHz L16, L8, QCELP, H263 Also, we do have RTP over TCP using HTTP fully interoperating with Quicktime player. Thanks, Go At 09:50 AM 12/5/00 -0800, Milko Boic wrote: > >I know we have interop. of QTS -> RP with the following codecs: >44kHz L16, >L8, >QCELP > >H263 was working but seems broken now... I'll confirm later today. > >Milko > > >At 06:30 PM 12/4/00 -0800, Go Hori wrote: >> >>I don't remember which codec we had tested against QTS. But L16 and L8 >>seem like what we had. If so, I can replay. >> >>We have HTTP cloaking to QTP, which means we are sending RTP over TCP. >>When I receive an answer for the codecs, I can reply on this one as well. >> On Mon, 4 Dec 2000, Colin Perkins wrote: > Folks, > > A reminder that we still need to complete the RTP interoperability testing, > before the RTP specification and audio/video profile can advance to draft > standard. > > The details are provided in draft-ietf-avt-rtp-interop-05.txt (for the RTP > specification) and draft-ietf-avt-profile-interop-03.txt (for the profile). > There are a number of results missing. For the profile: > > - Audio codecs: 1016, G726-32, G723, 11,16,22kHz DVI, G722, QCELP, > 44kHz L16, G728, GSR HR, GSR EFR, L8 > - Video codecs: CelB, motion JPEG, nv, MP2T, H263, BT656, MP1S, MP2P, BMPEG > > If you have an implementation of any of these codecs, and have tested with > another implementation, PLEASE mail me a brief note to the effect of "Vendor > ??? has an implementation of ??? and has tested with vendor ???". > > If we do not get these tests complete, we shall have to remove these codecs > from the list of static payload types in the revised audio/video profile. > > For the RTP specification: > - RTP with padding > - SDES PRIV > - RTCP BYE with multiple sources > - RTCP BYE with reason for leaving > - Canonical mapping of passphrase when encrypting > - Encrypted RTCP (see draft for details) > - RTP transported via TCP > - RTCP reconsideration and timeout algorithms > > Again, if you have an implementation of any of the following, please > contact me. If we cannot test these features, they will be removed from > the revised RTP specification. > > Thanks in advance! > Colin > From rem-conf Thu Dec 07 19:46:44 2000 From rem-conf-request@es.net Thu Dec 07 19:46:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144ESP-0002V9-00; Thu, 7 Dec 2000 19:44:25 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 144ESI-0002Uz-00; Thu, 7 Dec 2000 19:44:20 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA07248; Thu, 7 Dec 2000 22:43:39 -0500 Message-Id: <200012080343.WAA07248@purple.east.isi.edu> To: Go Hori cc: rem-conf@es.net Subject: Re: RTP interoperability testing In-Reply-To: Message from Go Hori of "Thu, 07 Dec 2000 19:15:04 PST." Date: Thu, 07 Dec 2000 22:43:39 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Excellent news! Many thanks..... Colin --> Go Hori writes: >hi! > >Realnetowkrs demonstrated full bidirectional interop. with Apple Quicktime >is as follows: > >44kHz L16, >L8, >QCELP, >H263 > >Also, we do have RTP over TCP using HTTP fully interoperating with >Quicktime player. > >Thanks, >Go > > >At 09:50 AM 12/5/00 -0800, Milko Boic wrote: >> >>I know we have interop. of QTS -> RP with the following codecs: >>44kHz L16, >>L8, >>QCELP >> >>H263 was working but seems broken now... I'll confirm later today. >> >>Milko >> >> >>At 06:30 PM 12/4/00 -0800, Go Hori wrote: >>> >>>I don't remember which codec we had tested against QTS. But L16 and L8 >>>seem like what we had. If so, I can replay. >>> >>>We have HTTP cloaking to QTP, which means we are sending RTP over TCP. >>>When I receive an answer for the codecs, I can reply on this one as >well. >>> > > >On Mon, 4 Dec 2000, Colin Perkins wrote: > >> Folks, >> >> A reminder that we still need to complete the RTP interoperability testing, >> before the RTP specification and audio/video profile can advance to draft >> standard. >> >> The details are provided in draft-ietf-avt-rtp-interop-05.txt (for the RTP >> specification) and draft-ietf-avt-profile-interop-03.txt (for the profile). >> There are a number of results missing. For the profile: >> >> - Audio codecs: 1016, G726-32, G723, 11,16,22kHz DVI, G722, QCELP, >> 44kHz L16, G728, GSR HR, GSR EFR, L8 >> - Video codecs: CelB, motion JPEG, nv, MP2T, H263, BT656, MP1S, MP2P, BMPEG >> >> If you have an implementation of any of these codecs, and have tested with >> another implementation, PLEASE mail me a brief note to the effect of "Vendor >> ??? has an implementation of ??? and has tested with vendor ???". >> >> If we do not get these tests complete, we shall have to remove these codecs >> from the list of static payload types in the revised audio/video profile. >> >> For the RTP specification: >> - RTP with padding >> - SDES PRIV >> - RTCP BYE with multiple sources >> - RTCP BYE with reason for leaving >> - Canonical mapping of passphrase when encrypting >> - Encrypted RTCP (see draft for details) >> - RTP transported via TCP >> - RTCP reconsideration and timeout algorithms >> >> Again, if you have an implementation of any of the following, please >> contact me. If we cannot test these features, they will be removed from >> the revised RTP specification. >> >> Thanks in advance! >> Colin >> > From rem-conf Thu Dec 07 22:17:35 2000 From rem-conf-request@es.net Thu Dec 07 22:17:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144Gn1-0004ZA-00; Thu, 7 Dec 2000 22:13:51 -0800 Received: from dns.packetdesign.net (mailman.packetdesign.com) [216.15.46.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 144Gn0-0004WH-00; Thu, 7 Dec 2000 22:13:50 -0800 Received: from localhost.cisco.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eB86C8Q18570; Thu, 7 Dec 2000 22:12:08 -0800 (PST) (envelope-from casner@acm.org) Date: Thu, 7 Dec 2000 22:14:06 -0800 (Pacific Standard Time) From: Stephen Casner To: Go Hori cc: Colin Perkins , Subject: Re: RTP interoperability testing In-Reply-To: Message-ID: Sender: casner@packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 7 Dec 2000, Go Hori wrote: > Realnetowkrs demonstrated full bidirectional interop. with Apple Quicktime > is as follows: > > 44kHz L16, > L8, > QCELP, > H263 Thanks for that contribution! But... > Also, we do have RTP over TCP using HTTP fully interoperating with > Quicktime player. Unfortunately for the purposes of this interop survey, I believe what you describe uses an encapsulation defined by the application rather than the minimal encapsulation specified in the RTP profile (prefixing each packet with a two-octet length field) for cases where the application does not define the framing. The open question is whether there is value in making that specification, or if it should simply be removed. -- Steve From rem-conf Fri Dec 08 09:57:17 2000 From rem-conf-request@es.net Fri Dec 08 09:57:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144RSz-0003pC-00; Fri, 8 Dec 2000 09:37:53 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 144RSx-0003od-00; Fri, 8 Dec 2000 09:37:51 -0800 Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Fri, 8 Dec 2000 09:40:57 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Fri Dec 08 09:40:56 2000 -0800 Received: from C585902B (c585902-b.frmt1.sfba.home.com [24.20.2.99]) by exchange.entera.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTZLX89P; Fri, 8 Dec 2000 09:34:59 -0800 Message-ID: <002701c0613d$d03f90e0$63021418@frmt1.sfba.home.com> From: "Alagu Periyannan" To: "Stephen Casner" , "Go Hori" Cc: "Colin Perkins" , , References: Subject: Re: RTP interoperability testing Date: Fri, 8 Dec 2000 09:39:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From: "Stephen Casner" > > Also, we do have RTP over TCP using HTTP fully interoperating with > > Quicktime player. > > Unfortunately for the purposes of this interop survey, I believe what > you describe uses an encapsulation defined by the application rather > than the minimal encapsulation specified in the RTP profile (prefixing > each packet with a two-octet length field) for cases where the > application does not define the framing. The open question is whether > there is value in making that specification, or if it should simply be > removed. There could be cases where RTP over TCP can be used without RTSP or some other control protocol. So there is value in keeping this around. I would like to point out that a fair amount of RTP interoperability was addressed in the RTSP interoperability event that Entera hosted this past summer. Please refer to the results in Ron Frederick's message to the confctrl list just after the event. On a separate note, I would really like to see at least an informational RFC (or even better a real standards track RFC) on the RTP over TCP using HTTP. I'll be more than happy to contribute to this effort if Apple or Real are interested. We have Entera's TeraCAST server also working with the RTP over TCP using HTTP scheme with the Apple QT player. -Alagu alagu@entera.com From rem-conf Fri Dec 08 12:44:44 2000 From rem-conf-request@es.net Fri Dec 08 12:44:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144UEu-0005kG-00; Fri, 8 Dec 2000 12:35:32 -0800 Received: from chai.east.isi.edu [38.218.19.199] by mail1.es.net with esmtp (Exim 1.81 #2) id 144UEs-0005jv-00; Fri, 8 Dec 2000 12:35:30 -0800 Received: from chai.east.isi.edu (localhost [127.0.0.1]) by chai.east.isi.edu (8.9.3/8.9.3) with ESMTP id QAA13537; Fri, 8 Dec 2000 16:37:55 GMT (envelope-from ladan@chai.east.isi.edu) Message-Id: <200012081637.QAA13537@chai.east.isi.edu> To: Bill Nowicki , miked@tbt.com, rem-conf@es.net, William.C.Miller@abc.com Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-reply-to: Your message of "Wed, 06 Dec 2000 16:28:32 PST." <03AB3CB11CBED3118A4F009027B0C2B14177E2@webmail1.omneon.com> Date: Fri, 08 Dec 2000 16:37:55 +0000 From: Ladan Gharai X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill, we did initially look into having a general RTP payload type for uncompressed video, however you simply dont run into the same issues when trying to packetize a low bitrate stream, say 1.1Mbits (64x80x15fps) and a high bitrate stream at 1,485Gbits - in addition, SMPTE 292 is a transport stream, and all the necessary info. is actually carried in the stream itself, i.e. the decoder syncs up using the SMPTE292 syncs words. ladan > I will make my usual comment that I think a better approach would be to > specify a single RTP payload type for sampled uncompressed video. The > specific sample parameters (8 bit vs. 10, number of lines and pixels, aspect > ratio or square, frame rate, etc.) could be format parameters on the fmtp > sdp line. That way the same payload spec could be used for both down-sampled > video (usually the first step before low bitrate encodings) all thethrough > standard definition to the plethora of high definitions. > > That is not to take anything away from the authors of this draft. It is > great they are publishing their spec and would love to hear any issues they > discover in their work. But a standards track document should not reflect > the peculiarities of any particular implementation. A spec that only works > at 1.5 Gigabits per second will not be widely deployed for a while, but is > interesting research. > > Also related note to Colin: I do not think anyone ever implemented the BT656 > payload type, so that one can be deprecated. A general uncompressed payload > type should be able to handle the standard definitions specified in that > document too. > > Bill Nowicki, Omneon Video, 408-585-5126 > From rem-conf Fri Dec 08 12:52:13 2000 From rem-conf-request@es.net Fri Dec 08 12:52:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144UTd-0006NR-00; Fri, 8 Dec 2000 12:50:45 -0800 Received: from chai.east.isi.edu [38.218.19.199] by mail1.es.net with esmtp (Exim 1.81 #2) id 144UTc-0006NE-00; Fri, 8 Dec 2000 12:50:44 -0800 Received: from chai.east.isi.edu (localhost [127.0.0.1]) by chai.east.isi.edu (8.9.3/8.9.3) with ESMTP id QAA13571; Fri, 8 Dec 2000 16:53:26 GMT (envelope-from ladan@chai.east.isi.edu) Message-Id: <200012081653.QAA13571@chai.east.isi.edu> To: "Michael A. Dolan" , rem-conf@es.net Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-reply-to: Your message of "Thu, 07 Dec 2000 07:35:44 PST." <5.0.2.1.2.20001207073248.05a0d310@cts.com> Date: Fri, 08 Dec 2000 16:53:25 +0000 From: Ladan Gharai X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mike, in the case of loss of data does the decoder not sync up at the next sync word? transport is essentialy over IP, on a high capacity but not necessaraly dedicated network. L. > Remember that 292M is synchronous and runs at the clock rate no matter > what. It is not tolerant of dropped data and doesn't run other than at the > rates noted in the ID (which are pretty high). Use of this would have to > be in a pretty special scenario I would think. Can the authors elaborate > on their intended usage here and what transports it might be used on? > > Thanks, > Mike > > At 11:26 PM 12/6/00 -0500, Colin Perkins wrote: > >Bill, > > > >I think there's scope for this approach to co-exist with a generic payload > >format for uncompressed video. The focus is somewhat different - closer to > >circuit emulation than many other payload formats - and if SMPTE 292M is a > >widely used format, could be very useful for device interconnect. > > > >I'd be interested in hearing opinions from others on the relative merits of > >this proposal, versus a generic uncompressed video format. > > > >Colin > > > > > > > >--> Bill Nowicki writes: > > >I will make my usual comment that I think a better approach would be to > > >specify a single RTP payload type for sampled uncompressed video. The > > >specific sample parameters (8 bit vs. 10, number of lines and pixels, aspect > > >ratio or square, frame rate, etc.) could be format parameters on the fmtp > > >sdp line. That way the same payload spec could be used for both down-sampled > > >video (usually the first step before low bitrate encodings) all the through > > >standard definition to the plethora of high definitions. > > > > > >That is not to take anything away from the authors of this draft. It is > > >great they are publishing their spec and would love to hear any issues they > > >discover in their work. But a standards track document should not reflect > > >the peculiarities of any particular implementation. A spec that only works > > >at 1.5 Gigabits per second will not be widely deployed for a while, but is > > >interesting research. > > > > > >Also related note to Colin: I do not think anyone ever implemented the BT656 > > >payload type, so that one can be deprecated. A general uncompressed payload > > >type should be able to handle the standard definitions specified in that > > >document too. > > > > > >Bill Nowicki, Omneon Video, 408-585-5126 > > ------------------------------------------------------ > Michael A. Dolan, Representing DIRECTV, (619)445-9070 > PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 > > From rem-conf Sat Dec 09 00:22:11 2000 From rem-conf-request@es.net Sat Dec 09 00:22:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144f8O-0003si-00; Sat, 9 Dec 2000 00:13:32 -0800 Received: from serg.oves.khv.ru (mail.oil.khv.ru) [212.19.27.137] by mail1.es.net with esmtp (Exim 1.81 #2) id 144f8L-0003sS-00; Sat, 9 Dec 2000 00:13:30 -0800 Received: from [216.84.245.142] by mail.oil.khv.ru (Netscape Mail Server v2.02) with SMTP id AAJ309; Sat, 9 Dec 2000 18:12:09 +1000 Received: from libra.jftaiwan.com.tw by e5-kanc-dp-1-15.espire.net with ESMTP; Sat, 09 Dec 2000 02:15:47 -0600 Message-ID: <00007c581e48$0000067b$0000522b@libra.jftaiwan.com.tw> To: From: arge.wdv@371.net Subject: Ingenius Marketing Product Means Money In Your Pocket 21035 Date: Sat, 09 Dec 2000 02:15:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: arge.wdv@371.net X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Get The Inside Track On The NEXT Market Craze of the 21st Century! Discover AN ALL CASH BUSINESS that is easy to operate, simple to manage, has NO COMPETITION, and NO INVENTORY OR PRODUCT HASSLES! This is an opportunity in an established "$34 BILLION industry, where over 90% of the owners are still in business. " Small Business Administration If you had the exclusive marketing rights to the first arcade video games, where would you be today? The creators of that concept made millions almost overnight, because their product was so hot and people could not get enough of it. What if you had the opportunity to get in on the next hot business craze? An amazing money generating machine called the "Coin Shooter" has been test marketed and perfected for two years, and is now ready for National Roll Out! Marketing areas will go FAST-Get yours NOW! The Coin Shooter is a sports challenge. A game of skill. Shoot a quarter through the basketball hoop and win a prize. You could win a free meal at a restaurant, maybe win a free oil change at an auto repair shop, or maybe win a free car wash! Your business owners can entertain waiting customers while making profits! Place this game of skill in restaurants, sports bars, car washes, truck stops, mini-markets, and tons of other locations. Can you imagine yourself owning 50, 100, or 200 of these incredible machines? Each one of these units can collect as much $10 -$15 a day, or more per machine! Can you imagine owning multiple machines in just one location? Can you imagine just 5-10 locations? you could earn $100,000 per year just working part-time! Immediate cash flow 24 hours a day, 7 days a week with a huge residual income. No overhead, no inventory, no employees Prime locations are available now! ACT NOW and receive our FREE FINANCIAL SUCCESS PACKAGE and, as a BONUS, we will include FREE Shipping and Handling and EXTRA Machines! (Ask for Details) All you need to do to get started is send us an E-Mail with the following info and we will contact you by phone ASAP. Type in the following required information and mailto:iwantmore355@usa.com?subject=PleaseCall4CoinShooter NAME CITY STATE PHONE NUMBER BEST TIME TO CALL E-MAIL ADDRESS mailto:iwantmore355@usa.com?subject=PleaseCall4CoinShooter The information you submit will be kept confidential and will be not used for anything except package verification. You must be over 18 years old to qualify for this program. Copyright 2000. All rights reserved. The manufacturer does not warranty or guarantee any income projections, minimum or maximum earnings, either written or verbally, whatsoever. Any income derived by the Coin Shooter will depend on such factors as prevailing market conditions, locations, service provided, etc. These are factors the manufacturer has absolutely no control over. Your results could vary from those shown here. You could be more or less successful than the people above depending on your determination to succeed. We can help you as best as we can, but you are ultimately as successful as you want to be. (REMOVAL INSTRUCTIONS) This mailing is done by an independent marketing company. Please do not use the reply to this e-mail, an e-mail reply cannot be read! If you would like to be removed from our mailing list just click below and send us a remove request email. mailto:nohitter785@repairman.com?subject=RemoveCoinShooterPromo From rem-conf Sat Dec 09 10:21:21 2000 From rem-conf-request@es.net Sat Dec 09 10:21:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144oRO-0000ZX-00; Sat, 9 Dec 2000 10:09:46 -0800 Received: from neko.cts.com [209.68.192.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 144oRN-0000ZN-00; Sat, 9 Dec 2000 10:09:45 -0800 Received: from vaio.tbt.com (mikedo.cts.com [204.212.152.85]) by neko.cts.com (8.9.3/8.9.3) with ESMTP id KAA07610 for ; Sat, 9 Dec 2000 10:09:43 -0800 (PST) Message-Id: <5.0.2.1.2.20001209092109.05496c00@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 09 Dec 2000 09:22:41 -0800 To: rem-conf@es.net (IETF AVT WG) From: "Michael A. Dolan" Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-Reply-To: <200012081653.QAA13571@chai.east.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It would be helpful in trying to reply if you could respond to my requests regarding the purpose of this ID. Thank you, Mike At 04:53 PM 12/8/00 +0000, Ladan Gharai wrote: >Mike, in the case of loss of data does the decoder not sync up at the >next sync word? >transport is essentialy over IP, on a high capacity but not necessaraly >dedicated network. > >L. > > > Remember that 292M is synchronous and runs at the clock rate no matter > > what. It is not tolerant of dropped data and doesn't run other than > at the > > rates noted in the ID (which are pretty high). Use of this would have to > > be in a pretty special scenario I would think. Can the authors elaborate > > on their intended usage here and what transports it might be used on? > > > > Thanks, > > Mike > > > > At 11:26 PM 12/6/00 -0500, Colin Perkins wrote: > > >Bill, > > > > > >I think there's scope for this approach to co-exist with a generic > payload > > >format for uncompressed video. The focus is somewhat different - > closer to > > >circuit emulation than many other payload formats - and if SMPTE 292M > is a > > >widely used format, could be very useful for device interconnect. > > > > > >I'd be interested in hearing opinions from others on the relative > merits of > > >this proposal, versus a generic uncompressed video format. > > > > > >Colin > > > > > > > > > > > >--> Bill Nowicki writes: > > > >I will make my usual comment that I think a better approach would be to > > > >specify a single RTP payload type for sampled uncompressed video. The > > > >specific sample parameters (8 bit vs. 10, number of lines and > pixels, aspect > > > >ratio or square, frame rate, etc.) could be format parameters on > the fmtp > > > >sdp line. That way the same payload spec could be used for both > down-sampled > > > >video (usually the first step before low bitrate encodings) all the > through > > > >standard definition to the plethora of high definitions. > > > > > > > >That is not to take anything away from the authors of this draft. It is > > > >great they are publishing their spec and would love to hear any > issues they > > > >discover in their work. But a standards track document should not > reflect > > > >the peculiarities of any particular implementation. A spec that > only works > > > >at 1.5 Gigabits per second will not be widely deployed for a while, > but is > > > >interesting research. > > > > > > > >Also related note to Colin: I do not think anyone ever implemented > the BT656 > > > >payload type, so that one can be deprecated. A general uncompressed > payload > > > >type should be able to handle the standard definitions specified in > that > > > >document too. > > > > > > > >Bill Nowicki, Omneon Video, 408-585-5126 > > > > ------------------------------------------------------ > > Michael A. Dolan, Representing DIRECTV, (619)445-9070 > > PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 > > > > ------------------------------------------------------ Michael A. Dolan, Representing DIRECTV, (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 From rem-conf Sat Dec 09 15:52:52 2000 From rem-conf-request@es.net Sat Dec 09 15:52:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 144tip-0003OI-00; Sat, 9 Dec 2000 15:48:07 -0800 Received: from (mail.inra.de) [62.157.97.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 144tin-0003O8-00; Sat, 9 Dec 2000 15:48:05 -0800 To: From: seeme@phreaker.net Subject: FREE 3 DAY 2 NIGHT VACATION ! 6796 Date: Sat, 09 Dec 2000 18:46:59 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200012100051437.SM00115@SMTP> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

Great News!!

You have been qualified to receive one of our exclusive complimentary free vacations. That’s right, it’s a FREE vacation package. You will receive complimentary accommodations in your choice of one our 7 fabulous vacation destinations. All you have to do is sign up.

Orlando FL, Ft. Lauderdale FL, Daytona Beach FL, Las Vegas NV, New Orleans LA, Branson MO, Williamsburg VA

There is no obligation to buy anything. We just ask you to come visit one of our exclusive resorts and have a great time. We realize the value of word of mouth advertising generated by happy guests telling their friends and family about our exclusive resorts.

So what are you waiting for, click the link below and find out how you can be on you way.

CLICK HERE NOW!

To be removed from future mailings please reply with "remove" in the subject line to freetravelservices@myrealbox.com or by using the following link:

REMOVE ME

-----------------------------------------------= --------------------------------------------

This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialemail/S771index.htm Here is a more detailed version of the legal notice above: This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.htm Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line.

-----------------------------------------------= --------------------------------------------

content=3D"text/h= tml; charset=3Diso-8859-1">

Welcome Aboard

<= p> From rem-conf Mon Dec 11 17:16:26 2000 From rem-conf-request@es.net Mon Dec 11 17:16:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 145dYT-00019U-00; Mon, 11 Dec 2000 16:44:29 -0800 Received: from relay3.rcp.net.pe [200.1.178.249] by mail1.es.net with esmtp (Exim 1.81 #2) id 145dYQ-00019K-00; Mon, 11 Dec 2000 16:44:27 -0800 Received: from kuntur.rcp.net.pe ([161.132.5.4]:34963 "HELO kuntur.rcp.net.pe" ident: "NO-IDENT-SERVICE[2]") by relay3.rcp.net.pe with SMTP id <24322-18845>; Mon, 11 Dec 2000 19:44:09 -0500 Received: from tecnofarma.com.pe([209.45.97.66]) (17501 bytes) by kuntur.rcp.net.pe via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Mon, 11 Dec 2000 19:32:41 -0500 (GMT) (Smail-3.2.0.105 1999-Mar-3 #33 built 1999-Mar-8) Received: from SERVER/SpoolDir by tecnofarma.com.pe (Mercury 1.48); 11 Dec 00 19:35:13 -0500 Received: from SpoolDir by SERVER (Mercury 1.48); 11 Dec 00 19:25:05 -0500 Received: from gauifnbece.cc.net.ei ([67.45.310.4]) by rsi5s2.daida34xcentotera.chua.caimetsy. (63.22.59.232) by tecnofarma.com.pe (Mercury 1.48); 11 Dec 00 19:24:56 -0500 To: From: return67@uole.com Subject: Lenders COMPETE for mortgage LOANS! 20279 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: return65@uole.com Message-ID: <713D6DE106E@tecnofarma.com.pe> Date: Mon, 11 Dec 2000 19:44:09 -0500 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Lender

The Lender's Network Mortgage Specia= lists

For U.S.A. Homeowners Only
Save Now!

We Shop The Best Loan For You!

The Lenders Network i= s a 100% free service which lets you shop for a mortgage conveniently and securely from the = comfort of your home. Using our vast network of lenders across the U.S., we will searc= h our database of loan programs for the best loans that fit your needs.  Even if yo= u're currently working with another lender or have been turned down before, we can st= ill help. 

Our= loan programs can get you the cash you need for:

  • Debt Consolidation
  • 2nd Mortgage
  • Refinance
  • Credit Repair
  • Home Improvement
  • New Car
  • Dream Vacation
  • College Tuition
  • To start a new business ..and much, much more!

F= unding borrowers with less than perfect credit is our specialty!

Incredibly low monthly payments

We can get you the loa= n you need. 
Regardless of whether you have good or bad= credit, we can help you.

Ready to get starte= d? 
Simply fill out the form below, and we'll = begin shopping for your loan.  It's that easy! 

Free Mortgage Quote

 

Contact Information (* required info)
Name: *
Address: *
City: *
State(US Only): *
Zip/Postal Code: *
Home Phone:  *
Work Phone: *
Email Address:
Best Time to Call:
Do You Own Your Home? Mobile Homes DO NOT Qualify=
Property Value: * 
Property Type:
Purchase Price: *
Year Acquired: *
1st Mortgage Balance Owe= d: * 
1st Mortgage Interest Ra= te: *
Is 1st Adjustable or Fix= ed?: *
2nd Mortgage Balance Owe= d: *
Amount You Wish To Borro= w: *
Employer:
Monthly Gross Household = Income *
Cre= dit Rating: *
Loan Interested In: *


Removal Instructions:
Click on the below link to be exclude from further communication.
Click Here<= /a>

From rem-conf Mon Dec 11 17:36:06 2000 From rem-conf-request@es.net Mon Dec 11 17:36:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 145e09-0001Yz-00; Mon, 11 Dec 2000 17:13:05 -0800 Received: from chai.east.isi.edu [38.218.19.199] by mail1.es.net with esmtp (Exim 1.81 #2) id 145e08-0001Yp-00; Mon, 11 Dec 2000 17:13:04 -0800 Received: from chai.east.isi.edu (localhost [127.0.0.1]) by chai.east.isi.edu (8.9.3/8.9.3) with ESMTP id VAA19627; Mon, 11 Dec 2000 21:16:19 GMT (envelope-from ladan@chai.east.isi.edu) Message-Id: <200012112116.VAA19627@chai.east.isi.edu> To: "Michael A. Dolan" , rem-conf@es.net Subject: Re: draft-ietf-avt-smpte292-video-01.txt In-reply-to: Your message of "Sat, 09 Dec 2000 09:22:41 PST." <5.0.2.1.2.20001209092109.05496c00@cts.com> Date: Mon, 11 Dec 2000 21:16:18 +0000 From: Ladan Gharai X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mike - the draft is about how one would transfer SMPTE 292 over an IP network, with RTP/UDP/IP. This is essentially a research project, and Tektronix is currently in the process of building a hardware box which will transfer SMPTE 292 over a high capacity (OC48) general purpose network. They have previously built the UNAS (Universal Network Access System) which is capable of transfering SMPTE 292M over ATM. We hope to have the first demonstration of SMPTE 292 over RTP to be >from University of Washington to ISI-East (or vice versa) over Abiline/SuperNet. Please let us know if we can provide you with more info. We look forward to your input. L. > It would be helpful in trying to reply if you could respond to my requests > regarding the purpose of this ID. > > Thank you, > > Mike > From rem-conf Tue Dec 12 13:52:08 2000 From rem-conf-request@es.net Tue Dec 12 13:52:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 145wyg-0000yW-00; Tue, 12 Dec 2000 13:28:50 -0800 Received: from ietf.207.137.73.67.tx.verio.net (purple.east.isi.edu) [207.137.73.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 145wyf-0000yM-00; Tue, 12 Dec 2000 13:28:49 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id QAA00803; Tue, 12 Dec 2000 16:25:36 -0500 Message-Id: <200012122125.QAA00803@purple.east.isi.edu> To: casner@acm.org Subject: Final AVT agenda for San Diego cc: agenda@ietf.org, rem-conf@es.net Date: Tue, 12 Dec 2000 13:25:36 -0800 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Audio/Video Transport Working Group Agenda Wednesday, 13th December 2000, 15:30-17:30 ========================================== - Introduction and status update (Casner/Perkins) 10 - draft-ietf-avt-rtp-new-08.txt - draft-ietf-avt-profile-new-09.txt - draft-ietf-avt-rtp-mime-03.txt - draft-ietf-avt-dv-audio-02.txt - draft-ietf-avt-dv-video-03.txt - draft-ietf-avt-rtp-mp3-04.txt - draft-bbuffam-avt-crtp-over-aal2-01.txt - draft-ietf-avt-rtp-cn-01.txt - RFC 2833 - RFC 2862 - RFC 2959 - Congestion control in RTP (Casner) 10 - RTP Interoperability testing (Perkins) 10 - draft-ietf-avt-rtp-interop-05.txt - draft-ietf-avt-profile-interop-03.txt - RTP Payload Format for SMPTE-292M - http://www.east.isi.edu/~ladan/smpte292.txt (Gharai) 10 - RTP Payload Format for EVRC Speech - draft-3gpp2-avt-evrc-00.txt (Li) 10 - draft-mccann-avt-rtp-evrc-00.txt (McCann) 10 - Discussion 10 - Error Tolerant RTP Payload Format for AMR - draft-xie-avt-et-rtp-amr-02.txt (Xie) 5 - draft-ietf-avt-rtp-amr-01.txt (Sjöberg) 5 - Discussion 10 - Low delay RTCP Feedback Format - draft-wenger-avt-rtcp-feedback-01.txt (Ott) 10 - draft-fukunaga-low-delay-rtcp-01.txt (Burmeister) 10 - draft-ietf-avt-rtp-selret-00.txt - Discussion 10 Thursday, 14th December 2000, 13:00-15:00 ========================================= - TCRTP and enhancements to CRTP (Koren) 10 - draft-ietf-avt-tcrtp-02.txt - draft-ietf-avt-crtp-enhance-01.txt - draft-koren-avt-crtp-ipcp-00.txt - An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams - draft-lnt-avt-uxp-02.txt (Wagner) 10 - An RTP Payload Format for Generic FEC with ULP - draft-ietf-avt-ulp-00.txt (Li) 10 - Transport of meta-information with RTP streams - draft-serenyi-avt-rtp-meta-00.txt (Serenyi) 10 - draft-brassil-avt-cues-00.txt (Brassil) 10 - Encryption, authentication and related issues - draft-blom-cmsec-3G-00.txt (Carrara) 10 - draft-blom-rtp-encrypt-00.txt (Carrara) 10 - draft-mcgrew-avt-srtp-00.txt (McGrew) 10 - Discussion 10 - RTP Payload format for MPEG-4 - Introduction (Perkins) 5 - draft-gentric-avt-rtp-mpeg4-00.txt (Gentric) 10 - draft-singer-mpeg4-ip-02.txt - RFC 3016 Once again, we have a full agenda. In order to get the most out of the meeting, we strongly encourage you to read all relevent drafts before the meeting, and for those making presentations to assume that the audience has read the draft. Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe the changes from the previous draft, highlight unresolved problems, propose future directions. Authors are also reminded of the contents of section 10 of RFC 2026. In particular, the requirement for disclosure of intellectual property relating to contributions. From rem-conf Tue Dec 12 21:01:25 2000 From rem-conf-request@es.net Tue Dec 12 21:01:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1463tm-0003OL-00; Tue, 12 Dec 2000 20:52:14 -0800 Received: from traal.act.cmis.csiro.au [138.44.72.94] by mail1.es.net with smtp (Exim 1.81 #2) id 1463tk-0003O5-00; Tue, 12 Dec 2000 20:52:12 -0800 Received: by traal.act.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id PAA14099; Wed, 13 Dec 2000 15:50:03 +1100 Received: from avalon.act.cmis.CSIRO.AU(152.83.80.104), claiming to be "cmis.csiro.au" via SMTP by traal.act.cmis.CSIRO.AU, id smtpdAAAa003SH; Wed Dec 13 15:50:00 2000 Sender: Chris.Gunn@cmis.CSIRO.AU Message-ID: <3A36FFF8.1930984E@cmis.csiro.au> Date: Wed, 13 Dec 2000 15:50:00 +1100 From: Chris Gunn Organization: CSIRO X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: kirsten@f2f-inc.com CC: im1-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: RE player3d missing rendering of animations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have experianced a similar problem, and think I have found the cause. However, I don't know how to fix it. My problem is that my scene loads correctly into a player, then subsequent edits (you might call them animations) to a Coordinate often (but not always) do not get shown. I have tracked the reason down to the variable m_dwStartTime, in class Root. Root inherits from MediaObject. MediaObject has a variable m_pRoot which is also a Root. This m_pRoot is not pointing back to pScene, but is pointing to another Root object (I'm not sure what it is for). Because pScene and its m_pRoot are both of class Root, they both have a m_dwStartTime. In my system, these hold different values! It seems that pScene->m_dwStartTime gets set when the scene is loaded, but pScene->m_pRoot->m_dwStartTime is the one that gets used when determining whether a new rendering is required. Additionally, pScene->m_pRoot->m_dwStartTime never gets initialized. Diagrammatically: Root * pScene - MediaObject - Root * m_pRoot - m_dwStartTime (never gets initialized and holds garbage) - m_dwStartTime (gets initialized when scene is loaded) So why does it work sometimes? This depends on the garbage that is sitting in m_dwStartTime. The render test simply compares it to another time value, so if it is less, it works and if more, it doesn't. Can someone enlighten me on what this m_pRoot value is for, should the dwStartTime be propogated recursively from each Root to its m_pRoot etc, whenever it gets set? By the way, I have tested this out by patching in a sensable number to m_dwStartTime, in the debugger, and my render worked every time. Thanks, -- | Chris Gunn chris.gunn@cmis.csiro.au | | CSIRO Mathematical and Information Sciences | | C.S.I.R.O. Canberra, Australia | | Fax +61 02 62167111 Phone +61 02 62167081 | > Dear Kirsten, > > I have a similar problem with IndexedFaceSet. > It seems that this rendering problem has been existing for quite a while. > In my case, it decodes well but sometimes the texture is not shown. > In case of multiple streams, it even crashes during the rendering stage. > However, since Matthew cannot maintain the Player3D anymore, I'm afraid we are > in the situation of take it or leave it, until somebody else volunteers to > maintain the code. > So, I am as lost as you are. > > Best regards, > Mahnjin > > Kirsten Schulz wrote: > > > Dear all, > > > > Has any body found the problem with this issue or a suggestion? > > > > thanks, > > Kirsten > > > > Kirsten Schulz wrote: > > > > > Dear all, > > > I put the player 3.4.0 with face animation in the site ftp.es.com under > > > IM1, player3.4.0.face.src.tar.gz. It has a test directory where there is > > > a Face3.trif file, script and scene. I encountered a problem that > > > sometimes the animation does not run, it seems to be time or thread > > > related. It decodes the animation stream (opossum.bifa), it goes to > > > rendering; but the face does not move, other times the face moves. > > > > > > thanks, > > > Kirsten > > ------------- End Forwarded Message ------------- From rem-conf Tue Dec 12 21:17:56 2000 From rem-conf-request@es.net Tue Dec 12 21:17:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1464Ej-0004Zi-00; Tue, 12 Dec 2000 21:13:53 -0800 Received: from mail.wayport.net [216.12.231.53] by mail1.es.net with esmtp (Exim 1.81 #2) id 1464Ei-0004ZY-00; Tue, 12 Dec 2000 21:13:52 -0800 Received: from scope (ip94.holi.snd.wayport.net [216.12.254.94] (may be forged)) by mail.wayport.net (8.10.1/8.10.1) with SMTP id eBD5CQC12348; Tue, 12 Dec 2000 23:12:27 -0600 (CST) From: "Adam Li" To: "Ietf-Avt" , "Steve Casner" , "Colin Perkins" Cc: "Pete McCann" , , , , , , , , , Subject: merged draft for the payload format for EVRC Date: Tue, 12 Dec 2000 21:09:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C0647F.DC7A4A40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0647F.DC7A4A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The enclosed is the merged draft for the RTP payload format for EVRC. It is combined from the two drafts that are submitted for AVT in this San Diego meeting. It is a collaborate draft from 3GPP2 with contributions from Lucent, Nokia, Qualcomm, Samsung, and UCLA (alphabetic ordered). We are looking forward to discuss with you on Wednesday. Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) ------=_NextPart_000_0000_01C0647F.DC7A4A40 Content-Type: text/plain; name="draft-3gpp2-avt-evrc-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-3gpp2-avt-evrc-01.txt" Internet Draft A. H. Li draft-3gpp2-avt-evrc-01.txt UCLA December 12, 2000 Editor=20 Expires: June 2001 An RTP Payload Format for EVRC Speech 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=20 http://www.ietf.org/shadow.html. ABSTRACT This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech. The packet format supports variable interleaving to reduce the effect of packet loss on Speech quality. In additional, the non-interleaving format is also supported. 1 Introduction This document describes how compressed EVRC speech as produced by the EVRC CODEC [1] may be formatted for use as an RTP payload type. A method is provided to interleave the output of the compressor to reduce quality degradation due to lost packets. Furthermore, the sender may choose various interleave settings based on the importance of low end-to-end delay versus greater tolerance for lost packets. 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]. 2 Background The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-127 [1] defines a speech compression algorithm for use in cdma2000 applications. IS-127, or EVRC is the emerging speech codec standard for cdma2000. The EVRC CODEC [1] compresses each 20 milliseconds of 8000 Hz, 16- bit sampled input speech into one of three different size output frames: Rate 1 (171 bits), Rate 1/2 (80 bits), or Rate 1/8 (16 bits). The CODEC chooses the output frame rate based on analysis of the input speech and the current operating mode (either normal or one of several reduced rates). For typical speech patterns, this results in an average output of 4.2 K bits/sec for normal mode and lower for reduced rate modes. 3 RTP/EVRC Packet Format The RTP timestamp is in 1/8000 of a second units. The RTP payload data for the EVRC CODEC has one of the following 2 formats conditional on whether the receiver uses interleaving and/or bundling or sends one codec frame per packet: For the case where interleaving is in use and/or multiple codec data frames are present in a single RTP packet the RTP packet format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header [2] | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ |RR | LLL | NNN | | +-+-+-+-+-+-+-+-+ one or more codec data frames + | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the case when interleaving is not used and a single codec data frame is present in a single RTP packet the RTP packet format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header [2] | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | | + one codec data frames +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP header has the expected values as described in [2]. The extension bit is not set and this payload type MUST never have the marker bit set. The codec data frames are aligned on octet boundaries. When interleaving is in use and/or multiple codec data frames are present in a single RTP packet, the timestamp is, as always, that of the oldest data represented in the RTP packet. The other fields have the following meaning: Reserved (RR): 2 bit MUST be set to zero by sender, SHOULD be ignored by receiver. Interleave (LLL): 3 bits MUST have a value between 0 and 5 inclusive. The remaining two values (6 and 7) MUST not be used by senders. If this field is non-zero, interleaving is enabled. All receivers MUST support interleaving. Senders MAY support interleaving. Senders that do not support interleaving MUST set field LLL and NNN to zero. Interleave Index (NNN): 3 bits MUST have a value less than or equal to the value of LLL. Values of NNN greater than the value of LLL are invalid. Interleaving/Bundling indication can be determined at the receiver by detecting the presence of a 1 in the first bit of the RTP packet payload. 3.1 Receiving Invalid Values On receipt of an RTP packet with an invalid value of the LLL or NNN field, the RTP packet MUST be treated as lost by the receiver for the purpose of generating erasure frames as described in section 4. 3.2 CODEC data frame format The output of the EVRC CODEC must be converted into CODEC data frames for inclusion in the RTP payload as follows: a. Octet 0 of the CODEC data frame indicates whether interleaving is present, if rate reduction is desired, and the rate of the codec frame. The format of the octet is indicated below: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|R| frame type| +-+-+-+-+-+-+-+-+ Interleaving Disabled (I): 1 bit This bit indicates whether the interleaving byte is present. This bit MUST be set to 1 if the interleaving byte is missing (i.e., interleaving/bundling is not used), otherwise it MUST=20 be set to 0. Note: if the first bit of the first RTP payload=20 octet is zero this byte is the interleaving byte, otherwise it is octet zero of the EVRC payload. Reduce Rate (R): 1 bit Setting the 'R' bit indicates that this packet is requesting a reduced codec rate for the reverse direction. When the 'R' bit=20 is not set the packet is requesting that the codec resume=20 normal operation. In the case of packet loss the codec should=20 continue to operate in the mode indicated by the last packet=20 received. Frame Type: 6 bits The frame type values are described in the table below and the size of the associated packet is indicated in the table below: Value RATE TOTAL CODEC data frame size (in octets) --------------------------------------------------------- 0 Blank 1 =20 1 1/8 3 =20 3 1/2 11 =20 4 1 23 =20 14 Erasure 1 (SHOULD NOT be transmitted by sender) Receipt of a CODEC data frame with a reserved value in octet 0 MUST be considered invalid data as described in 3.1. All=20 values not listed in the above table MUST be considered=20 reserved. b. The bits as numbered in the standard [1] from highest to lowest are packed into octets. The highest numbered bit (170 for Rate 1, 79 for Rate 1/2 and 15 for Rate 1/8) is placed in the most significant bit (Internet bit 0) of octet 1 of the CODEC data frame, the second highest bit is placed in the second most significant bit of the first octet, the third highest in the third most significant bit of the first octet, and so on. This continues until all of the bits have been placed in the CODEC data frame. The remaining unused bits of the last octet of the CODEC data frame MUST be set to zero (note that this is only applicable to rate 1 frames as the others fit completely into a whole number of octets). =20 Here is a detail of how a Rate 1 frame is converted into a CODEC data frame: =20 Octet 0 of the data frame has value 4 (see table above) indicating the total data frame length (including octet 0) is 23 octets. Bits 169 through 0 from the standard Rate 1 frame are placed as indicated with bits marked with "Z" being set to zero. The Rate 1/8 and 1/2 standard frames are converted similarly but do not require zero padding because they align on octet boundaries. Rate 1 CODEC data frame (bytes 0 - 3) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| |I|R| 3(Rate 1) |7|6|6|6|6|6|6|6|6|6|6|5|5|5|5|5|5|5|5|5|5|4|4|4| | | | |0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rate 1 CODEC data frame (bytes 20 - 22) 1 1 1 1 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1|1| | | | | | | | | | | | | | | | |8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|Z|Z|Z|Z|Z| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 Bundling CODEC data frames As indicated in section 3, more than one CODEC data frame MAY be included in a single RTP packet by a sender. Receivers MUST handle bundles of up to 10 CODEC data frames in a single RTP packet. Furthermore, senders have the following additional restrictions: o MUST not bundle more CODEC data frames in a single RTP packet than will fit in the MTU of the RTP transport protocol. For the purpose of computing the maximum bundling value, all CODEC data frames should be assumed to have the Rate 1 size. o MUST never bundle more than 10 CODEC data frames in a single RTP packet. o Once beginning transmission with a given SSRC and given bundling value, MUST NOT increase the bundling value. If the bundling value needs to be increased, a new SSRC number MUST be used. o MAY decrease the bundling value only between interleave groups = (see section 3.4). If the bundling value is decreased, it MUST NOT be increased (even to the original value), although it may be decreased again at a later time. 3.3.1 Determining the number of bundled CODEC data frames Since no count is transmitted as part of the RTP payload and the CODEC data frames have differing lengths, the only way to determine how many CODEC data frames are present in the RTP packet is to examine octet 0 of each CODEC data frame in sequence until the end of the RTP packet is reached. 3.4 Interleaving CODEC data frames Interleaving is meaningful only when more than one CODEC data frame is bundled into a single RTP packet. All receivers MUST support interleaving. Senders MAY support interleaving. Given a time-ordered sequence of output frames from the EVRC CODEC=20 numbered 0..n, a bundling value B, and an interleave value L where=20 n =3D B * (L+1) - 1, the output frames are placed into RTP packets as = follows (the values of the fields LLL and NNN are indicated for=20 each RTP packet): First RTP Packet in Interleave group: LLL=3DL, NNN=3D0 Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of B frames Second RTP Packet in Interleave group: LLL=3DL, NNN=3D1 Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a total of B frames This continues to the last RTP packet in the interleave group: L+1 RTP Packet in Interleave group: LLL=3DL, NNN=3DL Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a total of B frames Senders MUST transmit in timestamp-increasing order. Furthermore, within each interleave group, the RTP packets making up the interleave group MUST be transmitted in value-increasing order of the NNN field. While this does not guarantee reduced end-to-end delay on the receiving end, when packets are delivered in order by the underlying transport, delay will be reduced to the minimum possible. Additionally, senders have the following restrictions: o Once beginning transmission with a given SSRC and given interleave value, MUST NOT increase the interleave value. If the interleave value needs to be increased, a new SSRC number MUST be used. o MAY decrease the interleave value only between interleave groups. If the interleave value is decreased, it MUST NOT be increased (even to the original value), although it may be decreased again at a later time. 3.5 Finding Interleave Group Boundaries Given an RTP packet with sequence number S, interleave value (field LLL) L, and interleave index value (field NNN) N, the interleave group consists of RTP packets with sequence numbers from S-N to S-N+L inclusive. In other words, the Interleave group always consists of L+1 RTP packets with sequential sequence numbers. The bundling value for all RTP packets in an interleave group MUST be the same. The receiver determines the expected bundling value for all RTP packets in an interleave group by the number of CODEC data frames bundled in the first RTP packet of the interleave group received. Note that this may not be the first RTP packet of the interleave group sent if packets are delivered out of order by the underlying transport. On receipt of an RTP packet in an interleave group with other than the expected bundling value, the receiver MAY discard CODEC data frames off the end of the RTP packet or add erasure CODEC data frames to the end of the packet in order to manufacture a substitute packet with the expected bundling value. The receiver MAY instead choose to discard the whole interleave group and play silence. 3.6 Switching from Interleaved/Bundled Mode to Single EVRC CODEC data Frame Per Packet Mode o If both bundling and interleaving have been reduced to a single CODEC data frame per packet then the sender should switch to the non-inter- leaved/non-bundled RTP payload type description. o Once switching transmission from interleaved/bundled packet mode = to single CODEC data frame per packet mode, the sender MUST NOT return to interleave/bundling mode without a new SSRC number being used. 3.7 Reconstructing Interleaved Speech Given an RTP sequence number ordered set of RTP packets in an interleave group numbered 0..L, where L is the interleave value and B is the bundling value, and CODEC data frames within each RTP packet that are numbered in order from first to last with the numbers 1..B, the original, time-ordered sequence of output frames from the CODEC may be reconstructed as follows: First L+1 frames: Frame 0 from packet 0 of interleave group Frame 0 from packet 1 of interleave group And so on up to... Frame 0 from packet L of interleave group Second L+1 frames: Frame 1 from packet 0 of interleave group Frame 1 from packet 1 of interleave group And so on up to... Frame 1 from packet L of interleave group And so on up to... Bth L+1 frames: Frame B from packet 0 of interleave group Frame B from packet 1 of interleave group And so on up to... Frame B from packet L of interleave group 3.7.1 Additional Receiver Responsibility Assume that the receiver has begun playing frames from an interleave group. The time has come to play frame x from packet n of the interleave group. Further assume that packet n of the interleave group has not been received. As described in section 4, an erasure frame will be sent to the EVRC CODEC. Now, assume that packet n of the interleave group arrives before frame x+1 of that packet is needed. Receivers SHOULD use frame x+1 of the newly received packet n rather than substituting an erasure frame. In other words, just because packet n wasn't available the first time it was needed to reconstruct the interleaved speech, the receiver SHOULD NOT assume it's not available when it's subsequently needed for interleaved speech reconstruction. 4 Handling lost RTP packets The EVRC CODEC supports the notion of erasure frames. These are frames that for whatever reason are not available. When reconstructing interleaved speech or playing back non-interleaved speech, erasure frames MUST be fed to the EVRC CODEC for all of the missing packets. Receivers MUST use the timestamp clock to determine how many CODEC data frames are missing. Each CODEC data frame advances the timestamp clock EXACTLY 160 counts. Since the bundling value may vary (it can only decrease), the timestamp clock is the only reliable way to calculate exactly how many CODEC data frames are missing when a packet is dropped. Specifically when reconstructing interleaved speech, a missing RTP packet in the interleave group should be treated as containing B erasure CODEC data frames where B is the bundling value for that interleave group. 5 Discussion The EVRC CODEC interpolates the missing speech content when given an erasure frame. However, the best quality is perceived by the listener when erasure frames are not consecutive. This makes interleaving desirable as it increases speech quality when dropped packets are more likely. On the other hand, interleaving can greatly increase the end-to-end delay. Where an interactive session is desired, the non-interleaved/ non-bundled RTP payload type is recommended. When end-to-end delay is not a concern, a bundling value of at least 4 and an interleave (field LLL) value of 4 or 5 is recommended subject to MTU limitations. The restrictions on senders set forth in sections 3.3 and 3.4 guarantee that after receipt of the first payload packet from the sender, the receiver can allocate a well-known amount of buffer space that will be sufficient for all future reception from the same SSRC value. Less buffer space may be required at some point in the future if the sender decreases the bundling value or interleave, but never more buffer space. This prevents the possibility of the receiver needing to allocate more buffer space (with the possible result that none is available) should the bundling value or interleave value be increased by the sender. Also, were the interleave or bundling value to increase, the receiver could be forced to pause playback while it receives the additional packets necessary for playback at an increased bundling value or increased interleave. 6. The EVRC MIME Type Registration=20 The MIME-name for the EVRC codec is allocated from the IETF tree since EVRC is expected to be a widely used codec for voice-over-IP applications. Media Type Name: audio=20 Media Subtype Name: EVRC=20 Required Parameters: none=20 Optional parameters for RTP mode:=20 ptime: Defined as usual for RTP audio.=20 maxframes: Maximum number of EVRC speech frames in one RTP packet. The receiver may set this parameter in order to limit buffering requirements or delay. Optional parameters for storage mode: none=20 Encoding considerations for RTP mode: see section 4 and section 5 of this document. Encoding considerations for storage mode: The EVRC speech frames are packed into consecutive compound EVRC payloads, see section 4 and section 5. The compound EVRC payloads must be stored in sequential order. This implies that the first octet after payload n must be the first octet of payload (n+1). Furthermore, missing frames and non-received frames during non-speech period must be encapsulated into a compound EVRC payload as blank frames or erasures. Each receiving entity that accepts this MIME type must be able to decode all EVRC coding modes. Security considerations: see section 8 "Security Considerations". =20 Public specification: this document.=20 =20 Additional information for storage mode:=20 Magic number: none=20 File extensions: evc, EVC=20 Macintosh file type code: none=20 Object identifier or OID: none=20 =20 Intended usage: COMMON. It is expected that many VoIP applications=20 (as well as mobile applications) will use this type.=20 =20 =20 7. Mapping to SDP Parameters=20 =20 Please note that this chapter applies to the RTP mode only.=20 =20 Parameters are mapped to SDP [5] as usual.=20 Example usage in SDP:=20 m =3D audio 49120 RTP/EVRC 97=20 a =3D rtpmap:97 EVRC=20 a =3D fmtp:97 maxframes =3D 2=20 =20 =20 8 Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [2], and any appropriate profile (for example [4]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances, a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in=20 future versions of IGMP [6] and in multicast routing protocols to=20 allow a receiver to select which sources are allowed to reach it. 9 Acknowledgements The editor thanks the following authors for contributions to this=20 document: J. D. Villasenor, D.S. Park, J.H. Park, K. Miller,=20 S. C. Greer, D. Leon, N. Leung, M. Lioy, T. Hiller, P. J. McCann,=20 M. D. Turner, and A. Rajkumar. 10 References [1] TIA/EIA/IS-127, "Enhanced Variable Rate Codec, Speech Service = =20 Option 3 for Wideband Spread Spectrum Digital Systems", January=20 1997. [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. [5] M. Handley and V. Jacobson, "SDP: Session Description Protocol", = RFC 2327, April 1998. [6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. =20 =20 11 Authors' Address Adam H. Li Image Communication Lab Electrical Engineering Department University of California Los Angeles, CA 90095 USA Phone: +1 310 825 5178 EMail: adamli@icsl.ucla.edu =20 John D. Villasenor Image Communication Lab Electrical Engineering Department University of California Los Angeles, CA 90095 USA Phone: +1 310 825 0228 EMail: villa@icsl.ucla.edu =20 Dong-Seek Park Samsung Electronics Suwon, Kyungki 442-742 Korea Phone: +82 31 200 3674 Email: dspark@samsung.com =20 Jeong-Hoon Park Samsung Electronics Suwon, Kyungki 442-742 Korea Phone: +82 31 200 3747 Email: dspark@samsung.com =20 Keith Miller Nokia 6000 Connection Drive=20 Irving, Texas 75039=20 USA Phone: +1 972 894 4296 Email: keith.miller@nokia.com S. Craig Greer Nokia 6000 Connection Drive=20 Irving, Texas 75039=20 USA Phone: +1 972 894 4867 Email: craig.greer@nokia.com =20 David Leon Nokia 6000 Connection Drive=20 Irving, Texas 75039=20 USA Phone: +1 972 374 1860 Email: david.leon@nokia.com Marcello Lioy QUALCOMM, Incorporated 5775 Morehouse Drive=20 San Diego, CA 92121=20 USA Phone: +1 858 651 8220 Email: mlioy@qualcomm.com Nikolai Leung QUALCOMM, Incorporated 7710 Takoma Ave.=20 Takoma Park, MD 20912=20 USA Phone: +1 703 346 8351 Email: nleung@qualcomm.com Tom Hiller=20 Lucent Technologies=20 Room 2F-218=20 263 Shuman Drive=20 Naperville, IL 60137=20 USA Phone: +1 630 979 7673=20 Email: tom.hiller@lucent.com=20 =20 Peter J. McCann=20 Lucent Technologies=20 Room 2Z-305=20 263 Shuman Drive=20 Naperville, IL 60137=20 USA Phone: +1 630 713 9359=20 Email: mccap@lucent.com=20 =20 Michael D. Turner=20 Lucent Technologies=20 Room 2A-203=20 67 Whippany Rd=20 Whippany, NJ 07981=20 USA Phone: +1 973 386 3579=20 Email: mdturner@lucent.com=20 =20 Ajay Rajkumar=20 Lucent Technologies=20 Room 1A-235=20 67 Whippany Rd=20 Whippany, NJ 07981=20 USA Phone: +1 973 386 5249=20 Email: ajayrajkumar@lucent.com=20 =20 ------=_NextPart_000_0000_01C0647F.DC7A4A40-- From rem-conf Wed Dec 13 02:39:41 2000 From rem-conf-request@es.net Wed Dec 13 02:39:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1469GF-0003W5-00; Wed, 13 Dec 2000 02:35:47 -0800 Received: from (oga.namahage.ne.jp) [210.169.134.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 1469GD-0003Vv-00; Wed, 13 Dec 2000 02:35:45 -0800 Received: from tnt14a-103.focal-chi.corecomm.net_[216.214.203.103] (tnt14a-103.focal-chi.corecomm.net [216.214.203.103]) by oga.namahage.ne.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with SMTP id TAA22605; Wed, 13 Dec 2000 19:34:37 +0900 (JST) From: bet@crpcu.lu Received: from futurnet.es.futurnet.es by tnt14a-103.focal-chi.corecomm.net with ESMTP; Wed, 13 Dec 2000 04:36:46 -0600 Message-ID: <0000053225b5$00006646$000076ae@futurnet.es.futurnet.es> To: Subject: Invest in your future..now 30382 Date: Wed, 13 Dec 2000 04:36:39 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do You Have The Yen To Be a A Millionaire?

100% return in less than 90 days!

Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

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

Example:

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

For a "FREE NO OBLIGATION" information packet, just Click Below to visit o= ur website:

click here




















To be removed:jackson7558@5homes.cc

From rem-conf Wed Dec 13 07:59:00 2000 From rem-conf-request@es.net Wed Dec 13 07:58:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146EEa-0007cw-00; Wed, 13 Dec 2000 07:54:24 -0800 Received: from (mail.incubate-online.com) [212.67.196.27] by mail1.es.net with esmtp (Exim 1.81 #2) id 146EEX-0007cf-00; Wed, 13 Dec 2000 07:54:22 -0800 Received: from FD9Ys4Lj3 [63.23.241.12] by mail.incubate-online.com (SMTPD32-6.00) id A99650134; Wed, 13 Dec 2000 15:45:26 +0000 DATE: 13 Dec 00 9:53:48 AM FROM: 9iQzG3Ev8@public.sta.net.cn Message-ID: <5O01YbrWPIzzc2> SUBJECT: Are you serious about making a change in quality of your life? Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are not in the business of wasting time, yours or ours- We are looking for a few serious individuals who want to create a seven figure income in the next 24-36 months and learn how to make that money go to work for them. No boss and no traffic. Powerful 3 year retirement program! NOT BLUE OR WHITE COLLAR, CORPORATE, MLM or a FRANCHISE Potential: Six Figures every 90 days Don't bother to call unless you are really serious and have a good work ethic. For more information CALL 1 800-784-4913 (24 hr 2 min. message) Please accept our deepest apologizes, if you received this email unsolicited, and you can be removed automatically below. ********************************************************************************** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:moremoney@adalia.cc?subject=Remove PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. ********************************************************************************** From rem-conf Wed Dec 13 17:45:15 2000 From rem-conf-request@es.net Wed Dec 13 17:45:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146NK8-0007kK-00; Wed, 13 Dec 2000 17:36:44 -0800 Received: from traal.act.cmis.csiro.au [138.44.72.94] by mail1.es.net with smtp (Exim 1.81 #2) id 146NK5-0007kA-00; Wed, 13 Dec 2000 17:36:42 -0800 Received: by traal.act.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id MAA01958; Thu, 14 Dec 2000 12:34:43 +1100 Received: from avalon.act.cmis.CSIRO.AU(152.83.80.104), claiming to be "cmis.csiro.au" via SMTP by traal.act.cmis.CSIRO.AU, id smtpdAAAa000UZ; Thu Dec 14 12:34:34 2000 Sender: Chris.Gunn@cmis.CSIRO.AU Message-ID: <3A3823AA.2A6B3850@cmis.csiro.au> Date: Thu, 14 Dec 2000 12:34:34 +1100 From: Chris Gunn Organization: CSIRO X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Kirsten Schulz CC: im1-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: RE player3d missing rendering of animations References: <3A36FFF8.1930984E@cmis.csiro.au> <3A3788AC.2E551FC3@f2f-inc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Kirsten, I've found a fix for this problem. Not sure how logical it is but it just involves a one line change: In File Executiv.cpp, I have added the line with the comment "// CJG" at the end. void Executive :: ReplaceScene () { m_pRoot = m_pInline -> GetScene (); if (!m_bSceneInited && m_pRoot != NULL) { m_pPresenter -> Start (); m_pRoot->ResetTime(); // CJG m_bSceneInited = TRUE; } } The call m_pRoot->ResetTime() sets the m_pRoot's m_dwStartTime. Just prior to this function getting called, a pScene object gets its m_dwStartTime set, but this object is not the same as the m_pRoot above. It is not good having the start time stored in 2 different places, but I wasn't confident enough with the code to figure out how to reduce it to one place, so I just set the 2 to be consistent. Good luck! - Chris Kirsten Schulz wrote: > > Chris, > > Thanks for the feedback. I will see what I can do about it with your info. > > Kirsten > > Chris Gunn wrote: > > > Hi, > > > > I have experianced a similar problem, and think I have found the cause. > > However, I don't know how to fix it. > > > > My problem is that my scene loads correctly into a player, then > > subsequent edits (you might call them animations) to a Coordinate often > > (but not always) do not get shown. > > I have tracked the reason down to the variable m_dwStartTime, in class > > Root. > > Root inherits from MediaObject. > > MediaObject has a variable m_pRoot which is also a Root. > > This m_pRoot is not pointing back to pScene, but is pointing to another > > Root object (I'm not sure what it is for). > > Because pScene and its m_pRoot are both of class Root, they both have a > > m_dwStartTime. In my system, these hold different values! It seems that > > pScene->m_dwStartTime gets set when the scene is loaded, but > > pScene->m_pRoot->m_dwStartTime is the one that gets used when > > determining whether a new rendering is required. Additionally, > > pScene->m_pRoot->m_dwStartTime never gets initialized. > > > > Diagrammatically: > > > > Root * pScene > > - MediaObject > > - Root * m_pRoot > > - m_dwStartTime (never gets initialized and holds garbage) > > - m_dwStartTime (gets initialized when scene is loaded) > > > > So why does it work sometimes? > > This depends on the garbage that is sitting in m_dwStartTime. The render > > test simply compares it to another time value, so if it is less, it > > works and if more, it doesn't. > > > > Can someone enlighten me on what this m_pRoot value is for, should the > > dwStartTime be propogated recursively from each Root to its m_pRoot etc, > > whenever it gets set? > > > > By the way, I have tested this out by patching in a sensable number to > > m_dwStartTime, in the debugger, and my render worked every time. > > > > Thanks, > > > > -- > > | Chris Gunn chris.gunn@cmis.csiro.au | > > | CSIRO Mathematical and Information Sciences | > > | C.S.I.R.O. Canberra, Australia | > > | Fax +61 02 62167111 Phone +61 02 62167081 | > > > > > Dear Kirsten, > > > > > > I have a similar problem with IndexedFaceSet. > > > It seems that this rendering problem has been existing for quite a while. > > > In my case, it decodes well but sometimes the texture is not shown. > > > In case of multiple streams, it even crashes during the rendering stage. > > > However, since Matthew cannot maintain the Player3D anymore, I'm afraid we are > > > in the situation of take it or leave it, until somebody else volunteers to > > > maintain the code. > > > So, I am as lost as you are. > > > > > > Best regards, > > > Mahnjin > > > > > > Kirsten Schulz wrote: > > > > > > > Dear all, > > > > > > > > Has any body found the problem with this issue or a suggestion? > > > > > > > > thanks, > > > > Kirsten > > > > > > > > Kirsten Schulz wrote: > > > > > > > > > Dear all, > > > > > I put the player 3.4.0 with face animation in the site ftp.es.com under > > > > > IM1, player3.4.0.face.src.tar.gz. It has a test directory where there is > > > > > a Face3.trif file, script and scene. I encountered a problem that > > > > > sometimes the animation does not run, it seems to be time or thread > > > > > related. It decodes the animation stream (opossum.bifa), it goes to > > > > > rendering; but the face does not move, other times the face moves. > > > > > > > > > > thanks, > > > > > Kirsten > > > > > > ------------- End Forwarded Message ------------- -- | Chris Gunn chris.gunn@cmis.csiro.au | | CSIRO Mathematical and Information Sciences | | C.S.I.R.O. Canberra, Australia | | Fax +61 02 62167111 Phone +61 02 62167081 | From rem-conf Wed Dec 13 17:50:19 2000 From rem-conf-request@es.net Wed Dec 13 17:50:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146NSk-00006n-00; Wed, 13 Dec 2000 17:45:38 -0800 Received: from (WWW.SEII.FR) [195.154.151.2] by mail1.es.net with smtp (Exim 1.81 #2) id 146NSg-00003O-00; Wed, 13 Dec 2000 17:45:34 -0800 Received: from bungee5(2Cust98.tnt5.lax3.da.uu.net[63.23.67.98]) by WWW.SEII.FR (IBM OS/400 SMTP V04R04M00) with TCP; Thu, 14 Dec 2000 02:41:37 +0100 To: diegdt@ldb.han.de From: diegdt@ldb.han.de Comments: Authenticated sender is Reply-to: diegdt@ldb.han.de Subject: New - 15-Million Fresh E-Mail Addresses Message-Id: <200012121471JAA43406@post.196.222.100> Date: Wed, 13 Dec 2000 17:45:34 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ JUST RELEASED 15-Million Fresh E-Mail Addresses _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ Our research has found that many people have tried one or more of the following... Free Classifieds? (Don't work anymore) Web Site? (Takes thousands of visitors) Banners? (Expensive and losing their punch) E-Zine? (Hope they have a *huge* subscriber list) Search Engines? (Forget it, unless you're in the top 20) S O W H A T W I L L W O R K ? Although often misunderstood, there is one method that has proven to succeed time-after-time. E - M A I L M A R K E T I N G ! ! IT'S A FACT... It if you're not using your computer to generate income, GOOD income, you're leaving money on the table. Here's what the experts have to say about E-Mail Marketing: "E-mail is an incredible lead generation tool" -Crains Magazine "A gold mine for those who can take advantage of bulk e-mail programs" - The New York Times "Blows away traditional Mailing" - Advertising Age Here's an example of your potential earnings if you have a product or service that brings you a profit of around $30. Remember, on the Internet, you can make money 7 days a week, 24 hours a day... even while you sleep, orders come from all over the world! Orders Per Day Weekly Monthly Yearly 1 $ 210 $ 840 $ 10,080 2 420 1,680 20,160 3 630 2,520 30,240 5 1,050 4,200 50,400 10 2,100 8,400 100,000 15 3,150 12,600 151,200 THE QUESTION IS... how do you generate those orders? The least expensive and fastest way is through E-Mail Marketing. M I L L I O N S V O L U M E 13 ***New Just Released - and now, 15 Million addresses*** We have just increased our list size from 10-million to 15-million without a corresponding increase in price! M I L L I O N S V O L U M E 13 Over the past 6 years, we have gained a reputation for having the cleanest, most responsive e-mail address lists in the industry. No one has gone to the work it takes to produce an e-mail address list of this quality. Here's how we prepare our e-mail lists: 1. We clean and eliminate all duplicates. 2. Next, we use a filter list of 400+ words/phrases to clean even more. No address with inappropriate or profane wording survives! 3. Then we use our private database of thousands of known Internet "extremists", those opposed to any kind of commercial e-mail, and kicked off every one we could find. 4. All domains were verified to insure they're valid. 5. And finally, we sorted the list into easy-to-manage packets of 20,000 addresses in simple text (.txt) format that will work with any computer operating system. WHAT DID WE END UP WITH? M I L L I O N S V O L U M E 13 15 Million Addresses Strong! With this super clean e-mail address lists you'll send less...and get better results... * Y O U G E T W H A T Y O U P A Y F O R * Our FRESH 15 Million, Volume 13 Address List CD, will result in: * Higher Response Rates * Higher Sales Conversion Ratios * More Receptive prospects; Less Flames & Non-Buyers. * Less Contact With Anti-Commerce Radicals & Extremists. Remember that potential income chart at the beginning of this message? Can you imagine the kind of money you could make if you mailed one million pieces and sold only one tenth (.01%) of one percent? You do the math, you'll be amazed! This is not a rental list that is restricted to a one-time mailing. You are purchasing an e-mail address list for your personal mailings and may use it over-and-over. DON'T HESITATE on this offer or you will miss out on the least expensive, most effective way to market... PERIOD! _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ F R E E B O N U S E S Order within 96 hours and we'll include the following FREE Bonuses... we call this our "BUSINESS STARTER" bonus. 1. To help you get started we include basic proven Professional Mailing Software (PC Only). This software has sold for as high as $399.00 in the past. Not a demo, but a full working version. SORRY, SINCE THE SOFTWARE IS FREE WE CANNOT OFFER ANY TECHNICAL SUPPORT, however set-up instructions and help files are included. 2. Every survey has always indicated that the most profitable product to sell on the Internet is INFORMATION! Our "BUSINESS STARTER" bonus gives you 650 reports/manuals/books that are yours to use and sell. With these "Special Reports" you may instantly start your "Information Product" business... plus a sample SALES LETTER is included to help you GET STARTED FAST! 3. "THE BULK E-MAIL SURVIVAL GUIDE" A manual/guide that addresses the Bulk E-Mail business. Especially useful for beginners. "THE BULK E-MAIL SURVIVAL GUIDE" will answer many of your questions and concerns about Bulk E-Mail. An exclusive for our customers... INCLUDED FREE. 4. "LISTMATE" - This is the software the Pro's use to manage their mailing lists. We've included two versions, both are fully functional demo's, the only limit is the file size. 5. "SCIENTIFIC ADVERTISING"! This is the book that is responsible for untold millions of dollars in sales and profits. Many of today's Internet "gurus" have used this powerful book as the foundation for marketing courses that they have written and sold for as much as $495. Marketeer's that have studied this book have been so deeply inspired, that it has changed their entire way of doing business, and they've gone on to make fortunes -- it's yours FREE with your order! This "BUSINESS STARTER" bonus is yours absolutely FREE if you order within the next 96 hours --- After that... Poof!... it's gone! ***SPECIAL BONUS*** Order Now and receive an additional 1,093,808 e-mail addresses as a prompt ordering bonus... that's a total of: 16,093,808 addresses. Order Now! _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ D O N ' T H E S I T A T E E-Marketing is the most effective and fastest way to market anywhere... PERIOD! O R D E R N O W . . . SAME DAY SERVICE (M-F) if your order is received before 2pm Pacific. 24hour fax service, just fax to: 1-530-504-5247 or if busy 1-612-632-5008 To order, via credit card simply cut/paste and print out the EZ ORDER FORM below and fax to our office today. ***** MILLIONS CD - Volume 13 ***** ***** NOW ONLY $247! ***** This "Special Price" is in effect for the next 96 hours, after that we go back to our regular price of $299.00 ... Don't delay... you can be in business tomorrow! We accept Visa, Mastercard, Amex and Checks by Fax. Fax your order to: 1-530-504-5247 or if busy 1-612-632-5008 ----------------------Cut & Paste---------------------- ---------------------EZ Order Form--------------------- _____Yes! I want everything! I am ordering within 96 hours. Include my FREE "Business On A CD" bonus along with the 15 Million Vol.13 E-Mail address CD (plus 1,093,808 bonus addresses) for the special price of only $247.00 + one of the shipping options I have indicated below. _____Oop's I missed the 96 hour "special". I am ordering Vol.13 at the regular price of $299.00 + shipping. ***PLEASE SELECT YOUR SHIPPING OPTION*** ____I would like to receive my package FedEx OVERNIGHT. I am including $15 for shipping. (Hawaii & Alaska $20 - Canada $25, all other International add an *additional* $25 [$40 total] for shipping) ____I would like to receive my package FedEx 2nd Day delivery. I'm including $10 for shipping. (***Sorry FedEx 2nd Day is NOT AVAILABLE for shipments to Alaska, Hawaii, Canada or any International destination - Continental U.S. shipping only***). ***Please Print Carefully*** NOTE: Orders cannot be shipped without complete information including your signature. No exceptions! NAME____________________________________________________ COMPANY NAME____________________________________________ ADDRESS_________________________________________________ (FedEx can only ship to street addresses - no P.O. boxes) CITY________________________________________ STATE/PROVINCE______________________________ COUNTRY_____________________________________ ZIP/POSTAL CODE_____________________________ PHONE NUMBER________________________________ (required for shipping & tracking) EMAIL ADDRESS___________________________________________ (Print Very Carefully With Block Letters - our ability to read your e-mail address is critical. We will be sending you instructions... if we cannot read your writing, we're both stuck!!! TYPE OF CREDIT CARD: ______VISA _____MASTERCARD _____AMEX CREDIT CARD# __________________________________________ EXPIRATION DATE________________________________________ NAME ON CARD___________________________________________ TOTAL AMOUNT (Including Shipping): $___________________ DATE:x__________________ (Required) SIGNATURE:x_________________________________ I understand that I am purchasing the Millions Vol.13 E-Mail Address List on a CD. The addresses are not rented, and while I may use the list for my own personal mailing, it is copyrighted and I may not share or offer it for resale. Free bonuses are included, but cannot be considered part of the financial transaction. I understand that it is my responsibility to comply with any laws applicable to my local area. As with all software, once opened the CD may not be returned, however, if found defective it will be replaced with like product at no charge. You may fax your order to us at: 1-530-504-5247 or if busy 1-612-632-5008 CHECK BY FAX SERVICES! Please Note: Sorry, we can only accept checks drawn on U.S. banks. If you would like to fax a check, tape your check below and fax it to our office along with the EZ Order Form to: 1-530-504-5247 or if busy 1-612-632-5008 ****************************************************** ***24 HOUR FAX SERVICES*** PLEASE TAPE YOUR CHECK HERE AND FAX IT TO US AT 1-530-504-5247 or if busy 1-612-632-5008 ******************************************************* If You fax a check, there is no need for you to mail the original. We will prepare a one-time draft, with the exact information on your original check. All checks will be held for bank clearance (14 business days). Make payable to: "CD-Marketing" ***************************************************************** All REMOVE requests are AUTOMATICALLY honored upon receipt. mailto:nomoremail@hongkong.com?subject=remove PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list. ***************************************************************** From rem-conf Wed Dec 13 20:09:12 2000 From rem-conf-request@es.net Wed Dec 13 20:09:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146PeN-0002wg-00; Wed, 13 Dec 2000 20:05:47 -0800 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 146PeL-0002wV-00; Wed, 13 Dec 2000 20:05:46 -0800 Received: from accordion ([150.203.56.21]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id PAA14177; Thu, 14 Dec 2000 15:05:31 +1100 (EST) Message-Id: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 14 Dec 2000 15:05:20 +1100 To: Dave Singer , confctrl@ISI.EDU, rem-conf@es.net, Guido.Franceschini@CSELT.IT, 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com From: Markus Buchhorn Subject: Internet Streaming Media Alliance and MPEG4 on IP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All Could somebody please explain to me what Apple/Sun/Cisco/... are doing in the ISMA, which is different to what has been discussed on these lists for some time? Or have these discussions been part of the ISMA's work? http://www.isma.tv/ > The first specification from the > ISMA will define an implementation agreement for streaming MPEG-4 video > and audio over IP networks. > > In preparation for the launch of the Alliance, members have been working to > develop an initial specification for MPEG-4 over IP, which will be circulated for > review and input at the initial meeting of the ISMA in February 2001. This first > meeting will be open to any company interested in becoming an ISMA member. Thanks! Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62799805 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 **From 1 Jan 2001: Ph +61 2 61258810, Fax: TBD..., Mobile: unchanged ** From rem-conf Wed Dec 13 20:20:30 2000 From rem-conf-request@es.net Wed Dec 13 20:20:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146Prr-0003on-00; Wed, 13 Dec 2000 20:19:43 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 146Prq-0003od-00; Wed, 13 Dec 2000 20:19:42 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA06127 for ; Wed, 13 Dec 2000 20:19:39 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Wed, 13 Dec 2000 20:19:39 -0800 Received: from [207.137.72.236] (vpn-gh-1035.apple.com [17.254.140.10]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id UAA03706; Wed, 13 Dec 2000 20:19:38 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> Date: Wed, 13 Dec 2000 20:19:06 -0800 To: Markus Buchhorn From: Dave Singer Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP Cc: confctrl@ISI.EDU, rem-conf@es.net, Guido.Franceschini@CSELT.IT, 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote: >Hi All > >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in >the ISMA, which is different to what has been discussed on these lists for >some time? Or have these discussions been part of the ISMA's work? > >http://www.isma.tv/ I'm not an official ISMA spokesperson, but here goes. For a start, I expect any specs that are to be published will be submitted to the IETF, ISO et al. as appropriate. The ISMA members might get together to help write etc., but I don't think this is a standards body per se. The ISMA will expect members to implement the agreed-to specs, and will hold interop events to make sure that the specs and implementations are good. They will also promote the use of these specs from the IETF and ISO, with the goal of making internet-based multimedia as open and multivendor as, say, http and html are today (perhaps a bad analogy, given the rocky road HTML has had, but you probably see what I mean). > >> The first specification from the >> ISMA will define an implementation agreement for streaming >MPEG-4 video >> and audio over IP networks. >> >> In preparation for the launch of the Alliance, members have been >working to >> develop an initial specification for MPEG-4 over IP, which will >be circulated for >> review and input at the initial meeting of the ISMA in February >2001. This first >> meeting will be open to any company interested in becoming an >ISMA member. > >Thanks! > >Cheers, > Markus > >Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 >email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62799805 >Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 > **From 1 Jan 2001: Ph +61 2 61258810, Fax: TBD..., Mobile: unchanged ** -- David Singer Apple Computer/QuickTime From rem-conf Wed Dec 13 22:00:33 2000 From rem-conf-request@es.net Wed Dec 13 22:00:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146RHx-0005eO-00; Wed, 13 Dec 2000 21:50:45 -0800 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 146RHw-0005eE-00; Wed, 13 Dec 2000 21:50:44 -0800 Received: from [207.137.70.59] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 630129; Thu, 14 Dec 2000 00:53:00 -0500 Message-ID: <3A385FFE.8122F67E@21rst-century.com> Date: Thu, 14 Dec 2000 00:52:01 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dave Singer CC: Markus Buchhorn , confctrl@ISI.EDU, rem-conf@es.net, Guido.Franceschini@CSELT.IT, 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave Singer wrote: > > At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote: > >Hi All > > > >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in > >the ISMA, which is different to what has been discussed on these lists for > >some time? Or have these discussions been part of the ISMA's work? > > > >http://www.isma.tv/ > > I'm not an official ISMA spokesperson, but here goes. For a start, I > expect any specs that are to be published will be submitted to the > IETF, ISO et al. as appropriate. The ISMA members might get together > to help write etc., but I don't think this is a standards body per > se. The ISMA will expect members to implement the agreed-to specs, > and will hold interop events to make sure that the specs and > implementations are good. They will also promote the use of these > specs from the IETF and ISO, with the goal of making internet-based > multimedia as open and multivendor as, say, http and html are today > (perhaps a bad analogy, given the rocky road HTML has had, but you > probably see what I mean). > Is this different from or in competition with the Audio Visual Transport (AVT) working group in the IETF ? Why is another standards body needed ? Why didn't they present today in the AVT meeting (there is still another chance tomorrow) ? Regards Marshall Eubanks (from the 49th IETF) Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From rem-conf Wed Dec 13 22:43:45 2000 From rem-conf-request@es.net Wed Dec 13 22:43:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146S5W-0006wB-00; Wed, 13 Dec 2000 22:41:58 -0800 Received: from ns.live.com [208.184.148.162] by mail1.es.net with esmtp (Exim 1.81 #2) id 146S5V-0006w1-00; Wed, 13 Dec 2000 22:41:57 -0800 Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170]) by ns.live.com (8.9.3/8.9.3) with ESMTP id WAA94423; Wed, 13 Dec 2000 22:41:46 -0800 (PST) (envelope-from finlayson@live.com) Message-Id: <4.3.1.1.20001213222157.00b5e560@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 13 Dec 2000 22:41:31 -0800 To: Markus Buchhorn From: Ross Finlayson Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP Cc: confctrl@ISI.EDU, rem-conf@es.net In-Reply-To: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 08:05 PM 12/13/00, Markus Buchhorn wrote: >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in >the ISMA, which is different to what has been discussed on these lists for >some time? I rarely pay much attention to "industry consortia" like this. They are typically set up for largely political purposes, and often don't last very long. (Hint: You can usually find the *true* reason for such a consortium by looking at its list of members, and noting which prominent company/companies in the field are *not* on the list.) If this organization's goal is, indeed, to promote interoperability using open standards, then it may well end up being Mostly Harmless. In any event, the primary organization that I'll be looking towards to meet this goal will continue to be the IETF... Ross (who decided to forego the overcrowded IETF meeting this time) From rem-conf Thu Dec 14 02:15:39 2000 From rem-conf-request@es.net Thu Dec 14 02:15:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146VLG-0002Le-00; Thu, 14 Dec 2000 02:10:26 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 146VLD-0002LU-00; Thu, 14 Dec 2000 02:10:23 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA19593; Thu, 14 Dec 2000 11:10:09 +0100 (MET) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma019591; Thu, 14 Dec 00 11:10:10 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA00855; Thu, 14 Dec 2000 11:10:08 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlmsn2.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA16082; Thu, 14 Dec 2000 11:10:07 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890016914111; Thu, 14 Dec 2000 11:11:59 +0100 To: , Cc: , , , , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Internet Streaming Media Alliance and MPEG4 on IP Message-ID: <0056890016914111000002L912*@MHS> Date: Thu, 14 Dec 2000 11:11:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 12/14/00 11:08:17" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Marshall Eubanks wrote: >Is this different from or in competition with the Audio Visual Transpo= rt (AVT) >working group in the IETF ? Why is another standards body needed ? Wh= y didn't >they present today in the AVT meeting (there is still another chance >tomorrow) ? This is about a standard at application level: "Fully interoperable A/V= streaming services over IP". To achieve interoperability, agreement is needed on the use of a set of protocols, amongst others from the AVT gr= oup in IETF. I would hope that ISMA does not need to invent new protocols, = but can build on top of existing ones. Though not all may be in full existe= nce yet, for example some RTP Payload format for MPEG-4. But in competition= with AVT ? Never. Kind regards, Jan van der Meer ************************ Jan van der Meer Philips - Digital Networks Building OAN-4 P.O. Box 80002 5600 JB Eindhoven The Netherlands Phone +31 402 735 774 Fax +31 402 735 545 Email jan.vandermeer@philips.com ************************ = From rem-conf Thu Dec 14 05:43:23 2000 From rem-conf-request@es.net Thu Dec 14 05:43:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146Yay-0005VX-00; Thu, 14 Dec 2000 05:38:52 -0800 Received: from p5.usslc14.stsn.com (basto.stsn.com) [12.23.74.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 146Yaw-0005VH-00; Thu, 14 Dec 2000 05:38:50 -0800 Received: from young ([10.120.45.64]) by basto.stsn.com (8.9.3/8.8.7) with SMTP id GAA12742; Thu, 14 Dec 2000 06:36:46 -0700 Message-ID: <006f01c065d2$c7511050$402d780a@techway.co.kr> From: "Young-Kwon LIM" To: , , Cc: , , , , <4on2andIP-sys@advent.ee.columbia.edu> References: <0056890016914111000002L912*@MHS> Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP Date: Thu, 14 Dec 2000 22:35:23 +0900 Organization: mp4cast MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBKYW4gYW5kIGFsbCwNCg0KPiANCj4gVGhpcyBpcyBhYm91dCBhIHN0YW5kYXJkIGF0IGFw cGxpY2F0aW9uIGxldmVsOiAiRnVsbHkgaW50ZXJvcGVyYWJsZSBBL1YNCj4gc3RyZWFtaW5nIHNl cnZpY2VzIG92ZXIgSVAiLiBUbyBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHksIGFncmVlbWVudCBp cw0KPiBuZWVkZWQgb24gdGhlIHVzZSBvZiBhIHNldCBvZiBwcm90b2NvbHMsIGFtb25nc3Qgb3Ro ZXJzIGZyb20gdGhlIEFWVCBncm91cA0KPiBpbiBJRVRGLiBJIHdvdWxkIGhvcGUgdGhhdCBJU01B IGRvZXMgbm90IG5lZWQgdG8gaW52ZW50IG5ldyBwcm90b2NvbHMsIGJ1dA0KPiBjYW4gYnVpbGQg b24gdG9wIG9mIGV4aXN0aW5nIG9uZXMuIFRob3VnaCBub3QgYWxsIG1heSBiZSBpbiBmdWxsIGV4 aXN0ZW5jZQ0KPiB5ZXQsIGZvciBleGFtcGxlIHNvbWUgUlRQIFBheWxvYWQgZm9ybWF0IGZvciBN UEVHLTQuIEJ1dCBpbiBjb21wZXRpdGlvbiB3aXRoDQo+IEFWVCA/IE5ldmVyLg0KPiANCg0KSSBh Z3JlZS4gSSBiZWxpZXZlIHdlLCBNUEVHIGFuZCBJRVRGIEFWVFIsIGNhbiBjb29wZXJhdGUgd2l0 aCBJU01BIGluIHZhcmlvdXMgd2F5IHRvIG1ha2UgdGhlIGJldHRlciBzdGFuZGFyZCwgd2lkZWx5 IGFjY2VwdGVkISBBcmUgdGhlcmUgYW55b25lIGludm9sdmVkIGluIElTTUEgdGVjaG5pY2FsbHk/ DQoNClNpbmNlcmVseSwNCllvdW5nLg0K From rem-conf Thu Dec 14 08:06:48 2000 From rem-conf-request@es.net Thu Dec 14 08:06:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146arC-0000Bz-00; Thu, 14 Dec 2000 08:03:46 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 146ar6-0000Bp-00; Thu, 14 Dec 2000 08:03:45 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id IAA19531 for ; Thu, 14 Dec 2000 08:03:39 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Thu, 14 Dec 2000 08:03:38 -0800 Received: from [207.137.73.29] (vpn-gh-587.apple.com [17.254.138.74]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id IAA06353; Thu, 14 Dec 2000 08:03:37 -0800 (PST) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <3A385FFE.8122F67E@21rst-century.com> References: <3.0.32.20001214150518.01314e70@acsys.anu.edu.au> <3A385FFE.8122F67E@21rst-century.com> Date: Thu, 14 Dec 2000 08:00:53 -0800 To: tme@21rst-century.com From: Dave Singer Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP Cc: Markus Buchhorn , confctrl@ISI.EDU, rem-conf@es.net, Guido.Franceschini@CSELT.IT, 4on2andIP-sys@advent.ee.columbia.edu, jan.vandermeer@philips.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Like I said, any standards that need to be published I expect to be published through and with and in the regular cooperation of the members in the ietf. I'm at the IETF and would be happy to talk about it; I was hoping to say a few words today, when mpeg-4 comes up. At 12:52 AM -0500 12/14/00, Marshall Eubanks wrote: >Dave Singer wrote: >> >> At 3:05 PM +1100 12/14/00, Markus Buchhorn wrote: >> >Hi All >> > >> >Could somebody please explain to me what Apple/Sun/Cisco/... are doing in >> >the ISMA, which is different to what has been discussed on these lists for >> >some time? Or have these discussions been part of the ISMA's work? >> > >> >http://www.isma.tv/ >> >> I'm not an official ISMA spokesperson, but here goes. For a start, I >> expect any specs that are to be published will be submitted to the >> IETF, ISO et al. as appropriate. The ISMA members might get together >> to help write etc., but I don't think this is a standards body per >> se. The ISMA will expect members to implement the agreed-to specs, >> and will hold interop events to make sure that the specs and >> implementations are good. They will also promote the use of these >> specs from the IETF and ISO, with the goal of making internet-based >> multimedia as open and multivendor as, say, http and html are today >> (perhaps a bad analogy, given the rocky road HTML has had, but you >> probably see what I mean). >> > >Is this different from or in competition with the Audio Visual Transport (AVT) >working group in the IETF ? Why is another standards body needed ? Why didn't >they present today in the AVT meeting (there is still another chance >tomorrow) ? > > > Regards > Marshall Eubanks (from the 49th IETF) > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 201 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com -- David Singer Apple Computer/QuickTime From rem-conf Thu Dec 14 09:28:51 2000 From rem-conf-request@es.net Thu Dec 14 09:28:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146c7K-0001yj-00; Thu, 14 Dec 2000 09:24:30 -0800 Received: from mercury.sun.com [192.9.25.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 146c7I-0001yZ-00; Thu, 14 Dec 2000 09:24:28 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09550; Thu, 14 Dec 2000 09:24:27 -0800 (PST) From: Michael.Speer@Eng.Sun.COM Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA29377; Thu, 14 Dec 2000 09:24:26 -0800 (PST) Received: from esun1as-be (esun1as-be.Central.Sun.COM [129.147.34.142]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA28354; Thu, 14 Dec 2000 09:24:25 -0800 (PST) Message-ID: <492865574.976815059719.JavaMail.speer@nasnfs.Eng.Sun.COM> Date: Thu, 14 Dec 2000 10:30:59 -0700 (MST) To: Ross Finlayson Subject: Re: Internet Streaming Media Alliance and MPEG4 on IP Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ross: This alliance was primarily created to bring focus to the MPEG4 on IP standardization efforts. We are not trying to circumvent any IETF or ISO process, we are just trying aid these efforts by adopting standards produced by the IETF and ISO. More over, the alliance is open to host interoperability events to check compliance with the IETF and ISO standards. Does this clarify the position of the alliance? Michael >At 08:05 PM 12/13/00, Markus Buchhorn wrote: >>Could somebody please explain to me what Apple/Sun/Cisco/... are doing in >>the ISMA, which is different to what has been discussed on these lists for >>some time? > >I rarely pay much attention to "industry consortia" like this. They are >typically set up for largely political purposes, and often don't last very >long. (Hint: You can usually find the *true* reason for such a consortium >by looking at its list of members, and noting which prominent >company/companies in the field are *not* on the list.) > >If this organization's goal is, indeed, to promote interoperability using >open standards, then it may well end up being Mostly Harmless. In any >event, the primary organization that I'll be looking towards to meet this >goal will continue to be the IETF... > > Ross (who decided to forego the overcrowded IETF meeting this time) > > From rem-conf Thu Dec 14 15:42:08 2000 From rem-conf-request@es.net Thu Dec 14 15:42:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146huj-0006GM-00; Thu, 14 Dec 2000 15:35:53 -0800 Received: from ietf.207.137.72.195.tx.verio.net (purple.east.isi.edu) [207.137.72.195] by mail1.es.net with esmtp (Exim 1.81 #2) id 146huh-0006GC-00; Thu, 14 Dec 2000 15:35:51 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id SAA00790 for ; Thu, 14 Dec 2000 18:35:51 -0500 Message-Id: <200012142335.SAA00790@purple.east.isi.edu> To: rem-conf@es.net Subject: Presentation slides Date: Thu, 14 Dec 2000 15:35:51 -0800 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If you presented in AVT, please send me a copy of your slides. I'll collect them for inclusion on a webpage and in the minutes. Thanks! Colin From rem-conf Thu Dec 14 16:27:25 2000 From rem-conf-request@es.net Thu Dec 14 16:27:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146ihL-0007Ke-00; Thu, 14 Dec 2000 16:26:07 -0800 Received: from server4.fiasj.net (mail1.fiasj.net) [208.232.76.249] by mail1.es.net with esmtp (Exim 1.81 #2) id 146ihJ-0007KU-00; Thu, 14 Dec 2000 16:26:05 -0800 Received: from niranjanlaptop [63.194.92.130] by mail1.fiasj.net (SMTPD32-6.05) id A680205A0260; Thu, 14 Dec 2000 16:32:00 -0800 From: "Niranjan Avadhanam" To: Cc: "Niranjan Avadhanam" Subject: Archives Date: Thu, 14 Dec 2000 16:26:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200012142335.SAA00790@purple.east.isi.edu> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, Is there an archive for the messages on this forum/discussion group? I subscribed recently to this group and would love to access the older discussions. Thanks. Niranjan Niranjan Avadhanam Senior DSP Development Manager HelloSoft Inc 408-373-5365 www.hellosoft.com From rem-conf Thu Dec 14 17:12:08 2000 From rem-conf-request@es.net Thu Dec 14 17:12:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146jO7-0000WZ-00; Thu, 14 Dec 2000 17:10:19 -0800 Received: from illustrious.concentric.net (illustrious.cnchost.com) [207.155.252.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 146jO5-0000WP-00; Thu, 14 Dec 2000 17:10:17 -0800 Received: from auvo.com (4032268D.ptr.dia.nextlink.net [64.50.38.141]) by illustrious.cnchost.com id UAA21058; Thu, 14 Dec 2000 20:10:17 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A396F71.D13784DE@auvo.com> Date: Thu, 14 Dec 2000 19:10:09 -0600 From: Jeff Meunier Organization: Auvo Technologies Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: WAN simulators for emulating loaded/lossy networks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are looking at ways to simulate different network characteristics, specifically lossy and limited bandwidth situations. Two packages were suggested and appear to be useful: Shunra's "The Cloud" SW WAN simulator, and the dummynet utility in FreeBSD. Does anyone have any experience with these for testing/evaluating protocols and streaming media performance? Can anyone recommend other solutions? Thanks, Jeff -- Jeff Meunier Auvo Technologies Inc. jmeunier@auvo.com From rem-conf Thu Dec 14 22:09:54 2000 From rem-conf-request@es.net Thu Dec 14 22:09:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146nuV-00035m-00; Thu, 14 Dec 2000 22:00:03 -0800 Received: from ietf.207.137.72.195.tx.verio.net (purple.east.isi.edu) [207.137.72.195] by mail1.es.net with esmtp (Exim 1.81 #2) id 146nuU-00035b-00; Thu, 14 Dec 2000 22:00:02 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA01472; Fri, 15 Dec 2000 00:59:56 -0500 Message-Id: <200012150559.AAA01472@purple.east.isi.edu> To: Niranjan Avadhanam cc: rem-conf Subject: Re: Archives In-Reply-To: Message from Niranjan Avadhanam of "Thu, 14 Dec 2000 16:26:25 PST." Date: Thu, 14 Dec 2000 21:59:56 -0800 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Niranjan Avadhanam writes: >Is there an archive for the messages on this forum/discussion group? >I subscribed recently to this group and would love to access the older >discussions. The archive at ftp://ftp.es.net/pub/mail-archive/rem-conf/ has messages since January 1993. Does anyone have a record of the earlier traffic? Colin From rem-conf Fri Dec 15 01:01:05 2000 From rem-conf-request@es.net Fri Dec 15 01:01:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 146qeS-0004zE-00; Fri, 15 Dec 2000 00:55:40 -0800 Received: from max5.rrze.uni-erlangen.de [131.188.3.50] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 146qeQ-0004z4-00; Fri, 15 Dec 2000 00:55:38 -0800 Received: from lisa.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP; Fri, 15 Dec 2000 09:55:34 +0100 Received: from localhost by lisa (8.9.3+Sun/cl-RRZE) id JAA01758; Fri, 15 Dec 2000 09:55:34 +0100 (MET) Date: Fri, 15 Dec 2000 09:55:34 +0100 (MET) From: Falko Dressler To: Jeff Meunier cc: rem-conf@es.net, Jochen Kaiser Subject: Re: WAN simulators for emulating loaded/lossy networks In-Reply-To: <3A396F71.D13784DE@auvo.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 Jeff, one of our students works on an extension of the driver, in order to produce a variable jitter. Also the same probability functions are to be used, in order to produce a variable package loss rate. If you only require to simulate a limited bandwidth and a lossy network (a normal distribution presupposed), you can use the 'standard' dummynet driver. You wrote, that you need the tool to evaluate streaming media protocols: Most of the multimedia protocols use RTP as the transport protocol. For this, a large jitter is a very large problem. Best regards, Falko. On Thu, 14 Dec 2000, Jeff Meunier wrote: > Date: Thu, 14 Dec 2000 19:10:09 -0600 > From: Jeff Meunier > To: rem-conf@es.net > Subject: WAN simulators for emulating loaded/lossy networks > > We are looking at ways to simulate different network characteristics, > specifically lossy and limited bandwidth situations. Two packages were > suggested and appear to be useful: Shunra's "The Cloud" SW WAN > simulator, and the dummynet utility in FreeBSD. Does anyone have any > experience with these for testing/evaluating protocols and streaming > media performance? Can anyone recommend other solutions? > > Thanks, > Jeff > > -- > Jeff Meunier > Auvo Technologies Inc. > jmeunier@auvo.com > -- Falko Dressler Universitaet Erlangen-Nuernberg, RRZE EMail: Falko.Dressler@rrze.uni-erlangen.de Tel: +49 9131 85-27802 / Fax: +49 9131 302941 WWW: http://bsd.rrze.uni-erlangen.de/~fd/ From rem-conf Fri Dec 15 11:42:40 2000 From rem-conf-request@es.net Fri Dec 15 11:42:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1470el-0003SK-00; Fri, 15 Dec 2000 11:36:39 -0800 Received: from dns.packetdesign.net (mailman.packetdesign.com) [216.15.46.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 1470ek-0003RW-00; Fri, 15 Dec 2000 11:36:38 -0800 Received: from localhost (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id eBFJZaQ91137; Fri, 15 Dec 2000 11:35:36 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 15 Dec 2000 11:39:16 -0800 (Pacific Standard Time) From: Stephen Casner To: Subject: AVT meeting summary Message-ID: Sender: casner@packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm forwarding to the AVT working group the "one paragraph" summary that the chairs are responsible for sending to the Area Directors by the end of the IETF meeting. Full minutes will follow. -- Steve Audio/Video Transport Working Group summary The most important task for AVT is to progress the RTP spec to Draft Standard. This requires two interoperable and independent implementations of each feature and function. This is complete for most features, but not all. Revised versions of the RTP spec and A/V profile will be issued by January 15 with the incomplete features and codecs removed. Also, the WG rough consensus at this meeting that the congestion control text in the spec and profile should stay as it is. Three new payload formats were presented in addition to updates on five already in development. Considerable discussion ensued on an alternative proposal for AMR payload format, but in a post-session discussion the authors agreed to work towards a compromise solution. There are two proposals for meta-payload formats for unequal error protection; the authors are to write performance comparisons to allow selection of one. In place of two payload formats for MPEG-4 systems payload formats going for Experimental status, we now have a single proposal under development by the MPEG committee which will be completed and submitted for standards track. For one new payload format, for EVRC speech, the two proposals have already been merged, but it was brought to our attention that ITU may have already defined a conflicting payload format without our knowledge. This is to be investigated further. Significant progress was made toward a profile for low-delay RTCP backchannel information. There are two drafts to be merged to complete that profile, then one or more payload formats that will make use of it, e.g., for retransmission on unicast streams. An updated was presented on extensions to CRTP. Per a discussion with the Area Director, the existing CRTP will be advanced to Draft Standard, and the enhanced CRTP will be a follow-on Proposed Standard. In addition, the draft on tunneled, multiplexed CRTP, which is the WG's solution for multiplexing RTP streams, was updated and will be submitted for BCP. The major new topic for this meeting was security for RTCP. A requirements document and two proposals were presented. The two proposals have a lot in common, and the authors have agreed that they can select among the differences to produce a single proposal. The "hum" consensus of the room was that the security task and the new payload format proposals should be accepted as working group tasks. From rem-conf Sat Dec 16 08:30:44 2000 From rem-conf-request@es.net Sat Dec 16 08:30:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147JxH-0005aP-00; Sat, 16 Dec 2000 08:13:03 -0800 Received: from server.nurcad.ufsc.br [150.162.229.1] by mail1.es.net with smtp (Exim 1.81 #2) id 147JxF-0005aF-00; Sat, 16 Dec 2000 08:13:01 -0800 Received: from frank (unverified [200.176.78.101]) by server.nurcad.ufsc.br (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 16 Dec 2000 13:14:06 -0300 From: "SBRC 2001" To: Subject: SBRC 2001: Call for Papers Date: Sat, 16 Dec 2000 14:11:55 -0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Please distribute; we apologize if you receive multiple copies.] SBRC 2001 19th BRAZILIAN SYMPOSIUM ON COMPUTER NETWORKS Florianópolis, Santa Catarina, Brazil; May 22-25, 2001 The Brazilian Symposium on Computer Networks (SBRC) is an annual event promoted by the Brazilian Computing Society (SBC) and by the National Laboratory of Computer Networks (LARC). The SBRC has become the most important forum for professionals interested in computer networks and distributed systems in Brazil over the years. In its 19th edition, the SBRC will consist of technical sessions, tutorials, workshops, lectures, mini-courses and panels. An exhibition of products, equipment and services is also being organized. CALL FOR PAPERS FOR THE TECHNICAL SESSIONS Authors are invited to submit papers describing research projects, experimental results and recent developments related, but not limited, to the following topics: - high-speed networks; - wireless communication; - the Internet: protocols, services and applications; - quality of service (QoS); - management of computer and telecommunication networks; - security; - middleware; - distributed multimedia systems; - distributed systems: algorithms, real-time and fault-tolerance; - multicomputers and distributed processing; - performance evaluation; - specification, verification, implementation and testing of distributed systems and protocols; - mobile agents and active networks; - multi-agent systems; - mobile computing. The submission of papers will be processed electronically. Papers must be written in English or Portuguese, and must be in Postscript Postscript (please use generic postscript) or PDF (generated by Adobe Acrobat) format. Please do not send papers in the .doc format used by MS Word. The paper should have no more than 16 pages, including abstract, figures, diagrams, bibliography, etc (please avoid figures in bitmap format). The page size should be A4 (29,7 by 21,0 cm), with top margin of 3,0 cm, and bottom and side margins of 2,5 cm; the text should be in 12-point Times font, disposed in a single column with no more than 45 lines. Additional information related to the submission of papers can be found at http://www.gta.ufrj.br/sbrc2001. This call for papers can be found in HTML, PDF, and doc formats, in both English and Portuguese, at http://www.sbrc2001.ufsc.br. IMPORTANT DATES Preliminary version due Jan 26, 2001 Notification of acceptance Mar 03, 2001 Final version due Apr 06, 2001 GENERAL CHAIR OF THE SYMPOSIUM Jean-Marie Farines DAS/UFSC and NURCAD/UFSC E-Mail: farines@lcmi.ufsc.br CHAIR OF THE PROGRAM COMMITTEE Otto Carlos Muniz Bandeira Duarte GTA/UFRJ E-Mail: otto@gta.ufrj.br PROGRAM COMMITTEE Aloysio de Castro Pinto Pedroza - UFRJ Antônio Alfredo Ferreira Loureiro - UFMG Carlos Becker Westphall - UFSC Carlos de Castro Goulart - UFV Djamel Sadok - UFPE Edmundo A. de Souza e Silva - UFRJ Edmundo Roberto Mauro Madeira - Unicamp Eduardo Whitaker Bergamini - INPE Eleri Cardozo - Unicamp Elias Procopio Duarte Jr - UFPR Guido Lemos de Sousa Filho - UFRN Jean-Marie Farines - UFSC Joberto Sergio Barbosa Martins - UNIFACS Joni da Silva Fraga - UFSC José Augusto Suruagy Monteiro - UNIFACS José Ferreira de Rezende - UFRJ José Gonçalves Pereira Filho - UFES Jose Marcos Silva Nogueira - UFMG José Neuman de Souza - UFC Julius Leite - UFF Luís Felipe Magalhães de Moraes - UFRJ Luiz Eduardo Buzato - Unicamp Luiz Fernando Gomes Soares - PUC/RIO Luiz Fernando Rust da Costa Carmo - UFRJ Marcus Endler - USP Maria Izabel Cavalcante Cabral - UFPb Maria Janilce Almeida - UFRGS Mauricio Magalhães - Unicamp Michael Stanton - UFF Nelson Fonseca - Unicamp Noemi Rodriguez - PUC/Rio Orlando Loques - UFF Otto Carlos Muniz Bandeira Duarte - UFRJ Raimundo José de Araújo Macêdo - UFBA Ricardo de Oliveira Anido - Unicamp Rogério Drummond - Unicamp Rosa Maria M. Leão - UFRJ Wanderley Lopes de Souza - UFSCar Wilson Vicente Ruggiero - USP ORGANIZED BY UFSC - Federal University of Santa Catarina NURCAD - High Speed Networks and High Performance Computing Group DAS - Department of Automation and Systems INE - Department of Computing and Statistics PROMOTED BY SBC - Brazilian Computer Society LARC - National Laboratory of Computer Networks ADDITIONAL INFORMATION ABOUT THE SYMPOSIUM E-Mail: sbrc2001@nurcad.ufsc.br WWW: http://www.sbrc2001.ufsc.br From rem-conf Sat Dec 16 10:31:27 2000 From rem-conf-request@es.net Sat Dec 16 10:31:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147M1Q-0007CX-00; Sat, 16 Dec 2000 10:25:28 -0800 Received: from prue.eim.surrey.ac.uk [131.227.76.5] (exim) by mail1.es.net with esmtp (Exim 1.81 #2) id 147M1P-0007CN-00; Sat, 16 Dec 2000 10:25:27 -0800 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 147M1M-00046s-00; Sat, 16 Dec 2000 18:25:24 +0000 Date: Sat, 16 Dec 2000 18:25:20 +0000 (GMT) From: "Dr A. H. Sadka" X-Sender: ees3as@regan.ee.surrey.ac.uk To: rem-conf@es.net, conferencesa@comsoc.org, announcements@omg.org Subject: Deadline Extension - CFP - SCI2001 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Due to many requests, we have extended the deadline for abstract submission to this invited session until Friday the 22nd of December. Please find below the original call for abstracts as it was initially announced. -------------------------------------------------------------------- Dear multimedia communications and networking experts, In the light of the 5th world multi-conference SCI to be held in July 2001, an invited session on multimedia communications and networking will be organised. The objective of this session is to give the experts = in the field the opportunity to meet up and exchange ideas and thoughts on their latest research and technical activities and provide them with a plaform of publishing and presenting their most recent achievements in a world renowned conference. Therefore, you are all invited to submit an abstract of a technical paper by the 15th of December 2000 at the latest. The scope of this organised session is defined by, but not restricted to: - Media compression (video, speech, audio) - Joint source/channel coding - Packet audio/video communications (Packetisation schemes, synchronisation, lost packet recovery techniques) - Error control mechanisms (Error resilience, concealment, recovery techniques, new error handling schemes for mobile channel applications etc) - Audiovisual transmissions over 3G networks (QoS, quality/error control optimisation, Throughput and channel utilisation, multi-slotting capabilities for video service provisioning - Packet video and audio networks (Broadcast DVB and DAB technologies, Wireless multimedia, Video over Wireless ATM etc) - Multimedia and DTV applications - Internetwork communications (Multimedia Gatewaying, Multimedia Control Unit architecture and technologies, Advanced H.323 applications and services, integration of fixed and mobile IP networks etc) - Improved multimedia communication protocols (packet-switched, circuit-switched, multi-party audiovisual communications, improved QoS techniques etc) - Video indexing and retrieval - Security issues in Multimedia Communications (Image/Video authentication and watermarking, encryption, validation etc) - Novel multimedia applications and services over various networking platforms Important Dates: - Abstract submission: Dec 15, 2000 - Notification of acceptance: Feb 16, 2001 - Camera ready paper: Apr 6, 2001 Abstracts must be submitted electronically in Microsoft Word document or postscript format to a.sadka@eim.surrey.ac.uk at a date no later than the submission deadline above. Invited session Webpage: http://www.ee.surrey.ac.uk/Personal/A.Sadka/SCI2001 Conference Webpage: http://www.iiis.org/sci Best regards. _________________________________________ Dr Abdul H. Sadka (Lecturer) | Multimedia Communications Research Group | Centre for Communication Systems Research| Uni. of Surrey, GU2 7XH, Surrey, England | Tel: +44 (01483) 259490 | Fax: +44 (01483) 876011 | WWW: www.ee.surrey.ac.uk/Personal/A.Sadka| _________________________________________| From rem-conf Sun Dec 17 02:41:48 2000 From rem-conf-request@es.net Sun Dec 17 02:41:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147b7L-0000fG-00; Sun, 17 Dec 2000 02:32:35 -0800 Received: from imo-r05.mx.aol.com [152.163.225.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 147b7K-0000d2-00; Sun, 17 Dec 2000 02:32:34 -0800 Received: from ydh86@netscape.net by imo-r05.mx.aol.com (mail_out_v28.34.) id 3.101.4e9602 (16237) for ; Sun, 17 Dec 2000 05:31:26 -0500 (EST) Received: from netscape.com (aimmail11.aim.aol.com [205.188.144.203]) by air-in03.mx.aol.com (v77.31) with ESMTP; Sun, 17 Dec 2000 05:31:26 -0500 Date: Sun, 17 Dec 2000 05:31:26 -0500 From: ydh86@netscape.net To: rem-conf@es.net Mime-Version: 1.0 Message-ID: <7838BA01.6BF78257.000163B3@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Does anyone know the RTP payload format for QT player? Could you please point me a document (better to explain the payload format as clear as the RTP header format in RFC1889?) Thank you. PS: I got email transmision problem, sorry if it is duplicated. From rem-conf Sun Dec 17 11:01:51 2000 From rem-conf-request@es.net Sun Dec 17 11:01:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147iwS-0005Uy-00; Sun, 17 Dec 2000 10:53:52 -0800 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 147iwO-0005Uo-00; Sun, 17 Dec 2000 10:53:50 -0800 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id NAA02681; Sun, 17 Dec 2000 13:53:02 -0500 Message-Id: <200012171853.NAA02681@purple.east.isi.edu> To: "Adam Li" cc: "Stephen Casner" , "John D. Villasenor" , "D.-S. Park" , "Jeong-Hoon Park" , "Yung Lyul Lee" , rem-conf@es.net Subject: Re: AVT meeting summary In-Reply-To: Message from "Adam Li" of "Fri, 15 Dec 2000 17:04:03 PST." Date: Sun, 17 Dec 2000 13:53:02 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Adam, all, (I cc'd rem-conf@es.net, for comment from those not in San Diego) --> "Adam Li" writes: >Thanks for the meeting summary. I have two questions. > >First, has the avt group decided that the unequal error protection proposals >should preceed as two seperate working item or one has to be choose among >them? For now they should proceed as two separate work items. Once we have a performance comparison we can decide which, if any, will go forward to proposed standard. >Second, has the EVRC payload been adopted as a working item for avt, or it >is still pending for the discussion with ITU? It was accepted as a work item of AVT, on the understanding that the two proposals we had before the meeting would be merged. We have to resolve the potential conflict with the ITU before the payload format can advance to proposed standard. Colin From rem-conf Sun Dec 17 22:39:24 2000 From rem-conf-request@es.net Sun Dec 17 22:39:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147trd-00044P-00; Sun, 17 Dec 2000 22:33:37 -0800 Received: from icsl.icsl.ucla.edu [128.97.90.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 147trb-00044F-00; Sun, 17 Dec 2000 22:33:35 -0800 Received: from scope (nat32@ts14-54.dialup.bol.ucla.edu [164.67.24.63]) by icsl.icsl.ucla.edu (8.8.8+Sun/8.8.8(ICSL0003)) with SMTP id WAA10381; Sun, 17 Dec 2000 22:33:12 -0800 (PST) From: "Adam Li" To: "Colin Perkins" Cc: "Stephen Casner" , "John D. Villasenor" , "D.-S. Park" , "Jeong-Hoon Park" , "Yung Lyul Lee" , Subject: RE: AVT meeting summary Date: Sun, 17 Dec 2000 22:29:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200012171853.NAA02681@purple.east.isi.edu> Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Colin, Thank you very much for your reply. About the EVRC draft, the two drafts before the meeting has already been merged to the one that was presented at the meeting. We are contacting the ITU document editors to find out about the details of what's defined there. I will keep you and everyone who is interested in this updated. About the unequal error protections, it seems that the two proposals ("An RTP Payload Format for Generic FEC with Uneven Level Protection" and "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams") are covering quite different scopes, even just figuring out the simulation condition all agreed on may be unfeasible and may take a long time. It might be unnecessary to compare the performance between them and choose one based on the comparison alone. Regards, Adam > -----Original Message----- > From: Colin Perkins [mailto:csp@isi.edu] > Sent: Sunday, December 17, 2000 10:53 AM > To: Adam Li > Cc: Stephen Casner; John D. Villasenor; D.-S. Park; Jeong-Hoon Park; > Yung Lyul Lee; rem-conf@es.net > Subject: Re: AVT meeting summary > > > Adam, all, > > (I cc'd rem-conf@es.net, for comment from those not in San Diego) > > --> "Adam Li" writes: > >Thanks for the meeting summary. I have two questions. > > > >First, has the avt group decided that the unequal error > protection proposals > >should preceed as two seperate working item or one has to be choose among > >them? > > For now they should proceed as two separate work items. Once we have a > performance comparison we can decide which, if any, will go forward to > proposed standard. > > >Second, has the EVRC payload been adopted as a working item for > avt, or it > >is still pending for the discussion with ITU? > > It was accepted as a work item of AVT, on the understanding that the two > proposals we had before the meeting would be merged. > > We have to resolve the potential conflict with the ITU before the payload > format can advance to proposed standard. > > Colin > > From rem-conf Mon Dec 18 01:13:55 2000 From rem-conf-request@es.net Mon Dec 18 01:13:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 147wKY-0006al-00; Mon, 18 Dec 2000 01:11:38 -0800 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 147wKX-0006aa-00; Mon, 18 Dec 2000 01:11:37 -0800 Received: from kabums.cs.tu-berlin.de (root@presto.cs.tu-berlin.de [130.149.25.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA00633; Mon, 18 Dec 2000 10:04:01 +0100 (MET) Message-Id: <5.0.2.1.2.20001217104133.02abb970@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 18 Dec 2000 10:01:54 +0100 To: Stephen Casner From: Stephan Wenger Subject: Re: AVT meeting summary Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Steve, Adam, Group, Regarding the EVRC speech codec packetization in H.225. > For one new payload > format, for EVRC speech, the two proposals have already been merged, > but it was brought to our attention that ITU may have already defined > a conflicting payload format without our knowledge. This is to be > investigated further. In the last H.225 versions, Annex F describes some packetization formats for various audio codecs. All of these packetization schemes are straightforward: put a single or a multitude of audio frames into a single RTP packet and send it. All this is very much comparable to the packetization spec for audio in the AV Profile. As it was mentioned in the meeting, such a straightforward packetization scheme was added for EVRC into V.4 of H.225, which was decided (given final approval) in November 2000. The full version 4 of H.225 is available from http://standard.pictel.com/ftp/avc-site/ Now, what does this mean? Let me give you some very subjective interpretation: People in the ITU-T want to use EVRC, but are not so much interested in a high performance implementation, or they simeply did not know that something better than the straightforward approach is possible. In order to put code points in the cap exchange and control protocol (H.245), they were in dire need for referenceable text on how EVRC is to be packetized. In the absence of an IETF packetization scheme they took the easiest route and put the simplest possible packetization into H.225. It is beyond my expertise to judge whether their simple packetization is sufficient -- but the amount of work spent in the IETF/AVT suggests that it is not. Which means, terminals using the simple packetization will probably have poorer performance than necessary. How to proceed? In my opinion it would be a bad decision to stop the standardization of a EVRC scheme that works better than the quick hack in H.225. But the authors of the IETF EVRC packetization should probably have a close look to H.225 Annex F, and give us their opinion about the relative performance. It will be up to the ITU T to fix their own problem of rushing through an supposedly oversimplified packetization scheme, most likely by adding more H.245 codepoint that support the new scheme. Bugs like that happened before in H.245. Of course, such a route is not optimal from a interoperability point-of-view. But if the new packetization is really better than the simple one, then market forces will quickly decide. One final remark regarding the coordination of SG16 and IETF/AVT. In the meeting I had a feeling of upcoming tension because of this issue. AVTers, please rest assured that this change likely just slipped into H.225 because many people were not aware or not interested in EVRC speech and/or the ongoing process of a payload specification standardization for it. Would people have known/listen, then there would have been comments and the thing would very likely have been postponed. There are several recent examples where rushed-in proposals for RTP payloads were rejected (or at least not immediately accepted) by SG16, and people were sent over to IETF/AVT instead. My two cents. Stephan From rem-conf Mon Dec 18 05:19:48 2000 From rem-conf-request@es.net Mon Dec 18 05:19:47 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14803u-0004w5-00; Mon, 18 Dec 2000 05:10:42 -0800 Received: from ip43.tucson3.az.pub-ip.psi.net ([38.29.63.43] helo=rPbedboy.com) by mail2.es.net with smtp (Exim 1.92 #1) id 14803p-0004vO-00; Mon, 18 Dec 2000 05:10:38 -0800 Date: Mon, 18 Dec 2000 05:57:46 -0700 Subject: FWD:The Scooter TOPS this Year's CHRISTMAS LIST! -vjmt Message-Id: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT To: I-MARKETING-92@excite.com From: I-MARKETING-31@excite.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scooters the Kids are lining-up for at the lowest prices! VIEW: http://nav.to/jdbug1 Also featuring Lightening Wheels...wheels that light-up in the dark! VIEW: http://nav.to/jdbug1 Order By Phone: 1-480-874-8560 Color choices for JDBUG are: Red, Orange, Green, Black, Silver $ 59.95 Note all JDBUGs have a base color of silver. The colors on the scooters are the wheels, handgrips, straps and stickers. The silver color scooter however is mainly silver with clear wheels. Color choices for Jonson are: Silver, Gold & Silver, Red and Silver, Black & Silver,Purple and silver $ 49.95 Lightning wheels come in red, yellow, green, blue. They are a safety feature, and they also never need batterys. They are powered from friction plates. The price on the lightning wheels are $19.95 per set. Unsubscribe: Reply with ""UNSUBSCRIBE"". in subjet line. From rem-conf Mon Dec 18 06:59:29 2000 From rem-conf-request@es.net Mon Dec 18 06:59:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1481gr-0003NP-00; Mon, 18 Dec 2000 06:55:01 -0800 Received: from nwcst340.netaddress.usa.net [204.68.23.85] by mail1.es.net with smtp (Exim 1.81 #2) id 1481gp-0003ND-00; Mon, 18 Dec 2000 06:54:59 -0800 Received: (qmail 3446 invoked by uid 60001); 18 Dec 2000 14:54:54 -0000 Message-ID: <20001218145454.3445.qmail@nwcst340.netaddress.usa.net> Received: from 204.68.23.85 by nwcst340 for [208.237.135.21] via web-mailer(34FM.0700.4B.01) on Mon Dec 18 14:54:54 GMT 2000 Date: 18 Dec 00 09:54:54 EST From: veera bhadrarao To: rem-conf@es.net Subject: Hi... X-Mailer: USANET web-mailer (34FM.0700.4B.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, I am interested in joining this group.Pl add my emeil id in this group. Thank you. Veerab ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From rem-conf Mon Dec 18 12:24:45 2000 From rem-conf-request@es.net Mon Dec 18 12:24:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1486eO-0000ZS-00; Mon, 18 Dec 2000 12:12:48 -0800 Received: from chiron.east.isi.edu [38.218.19.204] by mail1.es.net with esmtp (Exim 1.81 #2) id 1486eM-0000ZI-00; Mon, 18 Dec 2000 12:12:46 -0800 Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id eBIKCjd10124 for ; Mon, 18 Dec 2000 15:12:45 -0500 Message-Id: <200012182012.eBIKCjd10124@chiron.east.isi.edu> To: rem-conf@es.net Subject: Presentation slides from San Diego AVT meeting Date: Mon, 18 Dec 2000 15:12:45 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks to those who have sent me their presentation slides from the San Diego meeting. These are now available from http://www.east.isi.edu/DIV7/IETF/AVT/ If you presented and have not yet submitted your slides, please do so! Thanks, Colin From rem-conf Mon Dec 18 13:26:37 2000 From rem-conf-request@es.net Mon Dec 18 13:26:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1487lA-00029k-00; Mon, 18 Dec 2000 13:23:52 -0800 Received: from chiron.east.isi.edu [38.218.19.204] by mail1.es.net with esmtp (Exim 1.81 #2) id 1487l8-00029a-00; Mon, 18 Dec 2000 13:23:50 -0800 Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id eBILNgR10491; Mon, 18 Dec 2000 16:23:42 -0500 Message-Id: <200012182123.eBILNgR10491@chiron.east.isi.edu> To: Adam Li cc: Stephen Casner , "John D. Villasenor" , "D.-S. Park" , Jeong-Hoon Park , Yung Lyul Lee , rem-conf Subject: Re: AVT meeting summary In-Reply-To: Your message of "Sun, 17 Dec 2000 22:29:06 PST." Date: Mon, 18 Dec 2000 16:23:42 -0500 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Adam, --> Adam Li writes: >About the EVRC draft, the two drafts before the meeting has already been >merged to the one that was presented at the meeting. We are contacting the >ITU document editors to find out about the details of what's defined there. >I will keep you and everyone who is interested in this updated. Thanks. >About the unequal error protections, it seems that the two proposals ("An >RTP Payload Format for Generic FEC with Uneven Level Protection" and "An RTP >Payload Format for Erasure-Resilient Transmission of Progressive Multimedia >Streams") are covering quite different scopes, even just figuring out the >simulation condition all agreed on may be unfeasible and may take a long >time. It might be unnecessary to compare the performance between them and >choose one based on the comparison alone. Actually, the scope seemed to be somewhat similar, although the solutions are very different. Colin From rem-conf Mon Dec 18 15:44:51 2000 From rem-conf-request@es.net Mon Dec 18 15:44:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1489uf-0004OH-00; Mon, 18 Dec 2000 15:41:49 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 1489ue-0004O7-00; Mon, 18 Dec 2000 15:41:48 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA11358 for ; Mon, 18 Dec 2000 15:41:46 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Mon, 18 Dec 2000 15:41:46 -0800 Received: from [17.202.37.131] (il0203a-dhcp03.apple.com [17.202.37.131]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id PAA06589; Mon, 18 Dec 2000 15:41:45 -0800 (PST) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <7838BA01.6BF78257.000163B3@netscape.net> References: <7838BA01.6BF78257.000163B3@netscape.net> Date: Mon, 18 Dec 2000 15:37:01 -0800 To: ydh86@netscape.net, rem-conf@es.net From: Kevin Marks Subject: Re: Unidentified subject! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 5:31 AM -0500 12/17/00, ydh86@netscape.net wrote: >Does anyone know the RTP payload format for QT player? Could you >please point me a document (better to explain the payload format as >clear as the RTP header format in RFC1889?) QT supports multiple payload formats. The QuickTime generic payload that we use for encapsulating media data that does not have its own specific payload is documented in RFC-like fashion at: http://devworld.apple.com/quicktime/icefloe/dispatch026.html From rem-conf Mon Dec 18 16:58:12 2000 From rem-conf-request@es.net Mon Dec 18 16:58:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148B4i-0005wy-00; Mon, 18 Dec 2000 16:56:16 -0800 Received: from mcns187.docsis69.singa.pore.net (oemcomputer) [202.156.69.187] by mail1.es.net with smtp (Exim 1.81 #2) id 148B4f-0005wa-00; Mon, 18 Dec 2000 16:56:13 -0800 From: news@emailmarketing To: Subject:All businessman must read MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_dbfE64iKlmmu8R4u9Tq" X-Mailer: wjhgkYhfbzT10l6I3h5iBX X-Priority: 3 X-MSMail-Priority: Normal Message-Id: Date: Mon, 18 Dec 2000 16:56:13 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_dbfE64iKlmmu8R4u9Tq Content-Type: multipart/alternative; boundary="----=_NextPart_dbfE64iKlmmu8R4u9TqAA" ------=_NextPart_dbfE64iKlmmu8R4u9TqAA Content-Type: text/plain; Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0i dGV4dC9odG1sOyBjaGFyc2V0PWJpZzUiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNaWNyb3NvZnQgV29yZCA5NyI+DQo8VElUTEU+KCCmubZspfOsT7hnuvW1uKWrs/W+ULDipL2l cbVvpVgsIKxPpb+37SBPUFQtSU4gtmyl8yw8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxC PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+KCCmubZspfOsT7hnuvW1uKWrs/Wk vaVxtW+lWKFBIKxPpb+37SBPUFQtSU4gtmyl86FBPC9QPg0KPFA+ICCtWaazsUi/+aZhp32hQb3Q rey9zCAhIKZdprm1TLa3pUi5cbZspl7C0KFBIMHCwcIgISApPC9QPg0KPC9GT05UPjxGT05UIFNJ WkU9ND4NCjwvRk9OVD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPqpGq26oyLhn wNm1b65pqLOzdKFBIKZVsNOuYaazp1+m0rx7tmmteKpGq26oyKWrs/UgPzwvUD4NCjwvRk9OVD48 Rk9OVCBTSVpFPTI+DQo8L0ZPTlQ+PEZPTlQgRkFDRT0itdixZMKyt6IoUCkiIFNJWkU9ND48UD6m 26r3v8Stt7zJpUir4aFBqkarbqjIsOquYcnKrau+46xGqnakzqr3v8TF6ah0oUGn67jqwPS50qTp r3GnubW9oUGr3KZopX6w6qfruOqqzKR3r8mvya9GpEq407DPsOyn67jqoUGmXrP4qrq856RPq9yw qqFDrFClW6lZrE+qRqtuqMimYbDPpKShQaxGqnakzrhnwNmzzMOtqXequrDqrmGhQaVbpFe7yKbm xemodKe5tb2hQbNRsOq72qS9u3ussKjjprOzzLJ6t1Gn67jqwPS50qFBuPOw6qS9pXHJyqVIrFCl W6lZrLCwz7DswWCzoaFBpUi63rJ6qkarbqjIqOSlTKZhsM+kp7d+sMihQbNRu3ussLZppWmn8KFB sGilaaZ1oUHDraSkqESz06q6pmGwz6FDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj48UCBBTElH Tj0iSlVTVElGWSI+PC9QPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+ PFA+pKSkcKuspL2lcaFBpmKn67jqpX6w6q7JoUGraKSjpnC487DqpL2lca5lqfahQaZdrLCkWqjG rW6/y6RPv8ussKFBue+lfrDquGew08D0udKko7z0sXihQaRIpE+kzrjqt72ko6isoUGkzqSjqr6m cKbzpEqk4qFBpUim3Kd4w/itq62roUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9GT05U PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pbukvaVxpESsUKVbqVm1+aVVsNO3 frresnqkzsVVsN2kvaVxoUGxTar5qPOnVaSkpHCrrKS9pXGhQazGptykQKRIpL2lcaFBp+u46qxQ pVupWajGqXmhQbTup0OlTK3Mqrqn67jqrbfASaTOusm2cajzp1WlTK3MuNGoTaazw/amYqxQpVup WbZ9s12kvaVxqMapeaFDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj4NCjwvRk9OVD48Rk9OVCBG QUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPq1ZprO/s73soUGlaaXTvdCmqKywpbukvaVxt3yt +6FDpqissLd8rfur4aFBsPKlu6pBsMisT7d8tKOo0aRArdO/7KS9q8emYad9tbm71aRVp0CssLZR pL2lcaZirFClW6lZqrq2bLFIof6u/KV+pMCm5qH+wXC1uKZhp32lzrN+oUGow6VOu9WkVaastW+k zrNCsnqp0qazqNOpuatIpfOkzrbHr3WhQaazw/a71aRVpKerSKXzpM62x691oUG3fMLgsUim3LvV pFWr/Kl3qrqmYad9qc62x691uLm9WKFDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj4NCjwvRk9O VD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPrvVpFWlabFOpmGnfadArLCu/KV+ pMCm5qZhp32hQaZMqOqmYrvVpFWquqZXpPmkV6FBqM+71aRVpKekvaVxpb+moaaorLCkQLahsOq7 2qX4t36hQajJprOn87Cqq0jFQaFDoUA8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9GT05U PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+rVm71aRVsnukd6azq8ik4aZirFCl W6lZtE6lsra3pd+nWaXTvdCmqKywpbukvaVxt3yt+6FBpUilu6S9pXGnQKywtlGkvaVxpmKsUKVb qVmkp7hnsnqkSKFBu9WkVaVpp/Ok6KtLs0KyerNvuMykp7d+sMihQajPq8ik4bnvtlGkvaVxp/Om s6tIpN+hQ6W8prO3frDIpmKsUKVbqVmqurDTrmGhQaXnvdC6yafWpdO90KaorLC3fK37oUGlSKtL wEiuyaVppquuaa78pX63frDIoUGkzqxkuN+ms8P2uOquxqFJPC9QPg0KPC9GT05UPjxGT05UIFNJ WkU9Mj4NCjwvRk9OVD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPqjkpUyqQbDI pV2sQaFBpauz9bHAwlihQbr1pFe1brxzp2mhQbr1rbazXa1woUG3fK1woUGzZqqrwXuuycB4pnOh QanbuHWu/KV+xVWt+6FBpU6ryKastNqhQbbXtNogLi4uLrWloUM8L1A+DQo8L0ZPTlQ+PEZPTlQg U0laRT0yPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pbukvaVx pUi71aRVpmKsUKVbqVmkp7hnsnqkSKitpfe0wLvVpFW63rJ6t36wyKFBusmlaa/gqPOnVbZRpL2l cbjRqE2mYqxQpVupWaSnt36wyLDdw0ShQajPu9WkVaits0Kw6qS6oUGsxqbcqKyko6VYpOGhQaXn pWm3brGxut6yeqxQpVupWaSnt36wyKFBqM+71aRVpKe63rJ6p/Oms67EsnahQbd8rfu2T6TOqOSl TKpBsMi2T6Vppc6maLDqs2a59KVJtNqhQaRRpMCk6KtLoUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0la RT0yPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pdO90KaorLC3 fK37qsyhQaWytre4Z8Dnpliqa6XNt06hQ6W8prOkvaVxple62arMoUGlaaX9pc6t06RIple4caXT vdChQzwvUD4NCjwvRk9OVD48Rk9OVCBTSVpFPTI+DQo8L0ZPTlQ+PEZPTlQgRkFDRT0itdixZMKy t6IoUCkiIFNJWkU9ND48UD6ms7+zveyqzKFBvdCl36dZtsevdabcoUCitaK0odCisqKyorWisqKz oreisqFAoaeq97Dspfi3fqGooUCvwaj6qu2u5qFBvdC1+an6oael073Qrvylfrd8rfuhqKFAtsev daS6vdC8Z6RXpL2lcaZXutmhQaZhp32hQblxtmyhQbbHr3W4ub1YpM7BcLW4uXG43KFds3Owz7Ds uLm9WKFeoUGlaaXOpKSh/q1epOW28bxnoUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9G T05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pdGp87G1qPy3fK37pEi8xqaz ra2hQb3Qp1mz+KZXoUM8L1A+PC9CPjwvRk9OVD48L0JPRFk+DQo8L0hUTUw+IA== ------=_NextPart_dbfE64iKlmmu8R4u9TqAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0i dGV4dC9odG1sOyBjaGFyc2V0PWJpZzUiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNaWNyb3NvZnQgV29yZCA5NyI+DQo8VElUTEU+KCCmubZspfOsT7hnuvW1uKWrs/W+ULDipL2l cbVvpVgsIKxPpb+37SBPUFQtSU4gtmyl8yw8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxC PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+KCCmubZspfOsT7hnuvW1uKWrs/Wk vaVxtW+lWKFBIKxPpb+37SBPUFQtSU4gtmyl86FBPC9QPg0KPFA+ICCtWaazsUi/+aZhp32hQb3Q rey9zCAhIKZdprm1TLa3pUi5cbZspl7C0KFBIMHCwcIgISApPC9QPg0KPC9GT05UPjxGT05UIFNJ WkU9ND4NCjwvRk9OVD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPqpGq26oyLhn wNm1b65pqLOzdKFBIKZVsNOuYaazp1+m0rx7tmmteKpGq26oyKWrs/UgPzwvUD4NCjwvRk9OVD48 Rk9OVCBTSVpFPTI+DQo8L0ZPTlQ+PEZPTlQgRkFDRT0itdixZMKyt6IoUCkiIFNJWkU9ND48UD6m 26r3v8Stt7zJpUir4aFBqkarbqjIsOquYcnKrau+46xGqnakzqr3v8TF6ah0oUGn67jqwPS50qTp r3GnubW9oUGr3KZopX6w6qfruOqqzKR3r8mvya9GpEq407DPsOyn67jqoUGmXrP4qrq856RPq9yw qqFDrFClW6lZrE+qRqtuqMimYbDPpKShQaxGqnakzrhnwNmzzMOtqXequrDqrmGhQaVbpFe7yKbm xemodKe5tb2hQbNRsOq72qS9u3ussKjjprOzzLJ6t1Gn67jqwPS50qFBuPOw6qS9pXHJyqVIrFCl W6lZrLCwz7DswWCzoaFBpUi63rJ6qkarbqjIqOSlTKZhsM+kp7d+sMihQbNRu3ussLZppWmn8KFB sGilaaZ1oUHDraSkqESz06q6pmGwz6FDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj48UCBBTElH Tj0iSlVTVElGWSI+PC9QPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+ PFA+pKSkcKuspL2lcaFBpmKn67jqpX6w6q7JoUGraKSjpnC487DqpL2lca5lqfahQaZdrLCkWqjG rW6/y6RPv8ussKFBue+lfrDquGew08D0udKko7z0sXihQaRIpE+kzrjqt72ko6isoUGkzqSjqr6m cKbzpEqk4qFBpUim3Kd4w/itq62roUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9GT05U PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pbukvaVxpESsUKVbqVm1+aVVsNO3 frresnqkzsVVsN2kvaVxoUGxTar5qPOnVaSkpHCrrKS9pXGhQazGptykQKRIpL2lcaFBp+u46qxQ pVupWajGqXmhQbTup0OlTK3Mqrqn67jqrbfASaTOusm2cajzp1WlTK3MuNGoTaazw/amYqxQpVup WbZ9s12kvaVxqMapeaFDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj4NCjwvRk9OVD48Rk9OVCBG QUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPq1ZprO/s73soUGlaaXTvdCmqKywpbukvaVxt3yt +6FDpqissLd8rfur4aFBsPKlu6pBsMisT7d8tKOo0aRArdO/7KS9q8emYad9tbm71aRVp0CssLZR pL2lcaZirFClW6lZqrq2bLFIof6u/KV+pMCm5qH+wXC1uKZhp32lzrN+oUGow6VOu9WkVaastW+k zrNCsnqp0qazqNOpuatIpfOkzrbHr3WhQaazw/a71aRVpKerSKXzpM62x691oUG3fMLgsUim3LvV pFWr/Kl3qrqmYad9qc62x691uLm9WKFDPC9QPg0KPC9GT05UPjxGT05UIFNJWkU9Mj4NCjwvRk9O VD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPrvVpFWlabFOpmGnfadArLCu/KV+ pMCm5qZhp32hQaZMqOqmYrvVpFWquqZXpPmkV6FBqM+71aRVpKekvaVxpb+moaaorLCkQLahsOq7 2qX4t36hQajJprOn87Cqq0jFQaFDoUA8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9GT05U PjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+rVm71aRVsnukd6azq8ik4aZirFCl W6lZtE6lsra3pd+nWaXTvdCmqKywpbukvaVxt3yt+6FBpUilu6S9pXGnQKywtlGkvaVxpmKsUKVb qVmkp7hnsnqkSKFBu9WkVaVpp/Ok6KtLs0KyerNvuMykp7d+sMihQajPq8ik4bnvtlGkvaVxp/Om s6tIpN+hQ6W8prO3frDIpmKsUKVbqVmqurDTrmGhQaXnvdC6yafWpdO90KaorLC3fK37oUGlSKtL wEiuyaVppquuaa78pX63frDIoUGkzqxkuN+ms8P2uOquxqFJPC9QPg0KPC9GT05UPjxGT05UIFNJ WkU9Mj4NCjwvRk9OVD48Rk9OVCBGQUNFPSK12LFkwrK3oihQKSIgU0laRT00PjxQPqjkpUyqQbDI pV2sQaFBpauz9bHAwlihQbr1pFe1brxzp2mhQbr1rbazXa1woUG3fK1woUGzZqqrwXuuycB4pnOh QanbuHWu/KV+xVWt+6FBpU6ryKastNqhQbbXtNogLi4uLrWloUM8L1A+DQo8L0ZPTlQ+PEZPTlQg U0laRT0yPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pbukvaVx pUi71aRVpmKsUKVbqVmkp7hnsnqkSKitpfe0wLvVpFW63rJ6t36wyKFBusmlaa/gqPOnVbZRpL2l cbjRqE2mYqxQpVupWaSnt36wyLDdw0ShQajPu9WkVaits0Kw6qS6oUGsxqbcqKyko6VYpOGhQaXn pWm3brGxut6yeqxQpVupWaSnt36wyKFBqM+71aRVpKe63rJ6p/Oms67EsnahQbd8rfu2T6TOqOSl TKpBsMi2T6Vppc6maLDqs2a59KVJtNqhQaRRpMCk6KtLoUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0la RT0yPg0KPC9GT05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pdO90KaorLC3 fK37qsyhQaWytre4Z8Dnpliqa6XNt06hQ6W8prOkvaVxple62arMoUGlaaX9pc6t06RIple4caXT vdChQzwvUD4NCjwvRk9OVD48Rk9OVCBTSVpFPTI+DQo8L0ZPTlQ+PEZPTlQgRkFDRT0itdixZMKy t6IoUCkiIFNJWkU9ND48UD6ms7+zveyqzKFBvdCl36dZtsevdabcoUCitaK0odCisqKyorWisqKz oreisqFAoaeq97Dspfi3fqGooUCvwaj6qu2u5qFBvdC1+an6oael073Qrvylfrd8rfuhqKFAtsev daS6vdC8Z6RXpL2lcaZXutmhQaZhp32hQblxtmyhQbbHr3W4ub1YpM7BcLW4uXG43KFds3Owz7Ds uLm9WKFeoUGlaaXOpKSh/q1epOW28bxnoUM8L1A+DQo8L0ZPTlQ+PEZPTlQgU0laRT0yPg0KPC9G T05UPjxGT05UIEZBQ0U9IrXYsWTCsreiKFApIiBTSVpFPTQ+PFA+pdGp87G1qPy3fK37pEi8xqaz ra2hQb3Qp1mz+KZXoUM8L1A+PC9CPjwvRk9OVD48L0JPRFk+DQo8L0hUTUw+IA== ------=_NextPart_dbfE64iKlmmu8R4u9TqAA-- ------=_NextPart_dbfE64iKlmmu8R4u9Tq-- From rem-conf Tue Dec 19 13:40:15 2000 From rem-conf-request@es.net Tue Dec 19 13:40:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148UGH-00079r-00; Tue, 19 Dec 2000 13:25:29 -0800 Received: from thalia.eecs.wsu.edu [199.237.73.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 148UGG-00079M-00; Tue, 19 Dec 2000 13:25:28 -0800 Received: from carmel.eecs.wsu.edu (IDENT:root@carmel.eecs.wsu.edu [199.237.72.81]) by thalia.eecs.wsu.edu with ESMTP (8.9.3/) id NAA04122 for ; Tue, 19 Dec 2000 13:25:05 -0800 (PST) From: "DAWN Research Lab - Dr. Sivalingam" Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id NAA23353 for rem-conf@es.net; Tue, 19 Dec 2000 13:25:05 -0800 Message-Id: <200012192125.NAA23353@carmel.eecs.wsu.edu> Subject: CFP: ACM MobiCom 2001 To: rem-conf@es.net Date: Tue, 19 Dec 2000 13:25:05 -0800 (PST) X-Mailer: ELM [version 2.5 PL3] 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 Enclosed below please find a Preliminary Announcement and Call for Papers for the 7th Annual International Conference on Mobile Computing and Networking (MobiCom) to be held in Rome, Italy from July 16-21, 2001. As you might already know, MobiCom has an established reputation as the pre-eminent conference in this area owing to the exceptionally high quality of papers, excellent tutorials and workshops, and stimulating panels conducted by mobile computing illuminati of various stripes. For complete information about the upcoming conference, please visit: http://www.research.ibm.com/mobicom2001/ A printer friendly version of this CFP is available at: http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.pdf (PDF) http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.ps (PS) We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** Preliminary Announcement and Call for Papers *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline: January 12, 2001 *********************************************************************** PAPERS: Technical papers (maximum 15 pages) describing original, previously unpublished, completed research, not currently under review by another conference or journal, are solicited on the following topics: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. Note: Student Registrations will be provided at a discounted rate. CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Proposals for tutorials are solicited. Tutorial topics that encompass the systems aspects of mobile computing and/or practical experiences in building/deploying such systems are of particular interest. Informal proposals for research demos are solicited. Proposals should include: the focus area in mobility, the technologies involved, specific equipment used, demo layout, space required, etc. Please refer to the conference website for submission and other details. (The paper submission website is READY for submissions now.) IMPORTANT DATES: * Technical Paper Submissions due: January 12, 2001 - Please refer to the website for submission instructions * Notification of acceptance: May 1, 2001 * Camera-ready version due: May 15, 2001 * Challenges Session Papers, Panel Proposals, Tutorial Proposals Submissions due: January 12, 2001 - Please refer to the website for submission instructions FOR MORE INFORMATION: Send email to mobicom2001@winlab.rutgers.edu with any questions or comments about the conference or for more information. ORGANIZING COMMITTEE: * General Chair: * Tutorials Co-Chairs: Christopher Rose Ravi Jain Rutgers University, WINLAB Telcordia Technologies * General Vice Chair: Chiara Petrioli Politecnico di Milano Sergio Palazzo Universita` di Catania * Panels Chair: * Program Co-Chairs: Ramesh Rao Univ. of California, San Diego Mahmoud Naghshineh IBM T.J. Watson Research Center * Local Arrangement Chair: Michele Zorzi Marco Listanti Universita` di Ferrara Universita` di Roma "La Sapienza" * Finance Chair: Chiara Petrioli Politecnico di Milano David B. Johnson Rice University * Registration Chair: * Exhibits/Sponsorships Chair: Irene Katzela Marco Ajmone Marsan Lucent Technologies Politecnico di Torino * Publicity Co-Chairs: * Research Demos Chair: Stefano Basagni Nigel Davies Univ. of Texas at Dallas Lancaster University Krishna Sivalingam * Steering Committee Chair: Washington State University Imrich Chlamtac Univ. of Texas at Dallas *********************************************************************** From rem-conf Wed Dec 20 01:12:16 2000 From rem-conf-request@es.net Wed Dec 20 01:12:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148eu4-0006qK-00; Wed, 20 Dec 2000 00:47:16 -0800 Received: from proxy-zh.systor.com [194.209.165.138] by mail1.es.net with esmtp (Exim 1.81 #2) id 148eu1-0006pm-00; Wed, 20 Dec 2000 00:47:14 -0800 Received: (from uucp@localhost) by proxy-zh.systor.com (8.9.1a/8.9.1) id JAA05921; Wed, 20 Dec 2000 09:44:26 +0100 (MET) From: caribic.dreams@5services.cc Received: from max1-23.kansascity.corecomm.net(209.81.129.151) by proxy-zh via smap (V2.1) id xmac05906; Wed, 20 Dec 00 09:43:57 +0100 Received: from xbyse.nada.kth.se by max1-23.kansascity.corecomm.net with ESMTP; Wed, 20 Dec 2000 02:43:13 -0600 Message-ID: <0000682d2be1$00005e16$000042a0@xbyse.nada.kth.se> To: Subject: The currency market may be your answer. 17056 Date: Wed, 20 Dec 2000 02:43:02 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do You Have The Yen To Be a A Millionaire?

100% return in less than 90 days!

Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

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

Example:

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

For a "FREE NO OBLIGATION" information packet, just Click Below to visit o= ur website:

click here




















To be removed:jackson7558@5paintings.cc

Do You Have The Yen To Be a A Millionaire?


100% return in= less than 90 days!

From rem-conf Wed Dec 20 02:11:36 2000 From rem-conf-request@es.net Wed Dec 20 02:11:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148fzo-0000Ma-00; Wed, 20 Dec 2000 01:57:16 -0800 Received: from host-209-214-159-124.msy.bellsouth.net (wowmail.com) [209.214.159.124] by mail1.es.net with smtp (Exim 1.81 #2) id 148fzm-0000MQ-00; Wed, 20 Dec 2000 01:57:14 -0800 From: Subject: A Special Gift For The Person Who Has Everything Date: Wed, 20 Dec 2000 04:00:05 Message-Id: <56.552200.435140@wowmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Looking for that special gift for the person who has everything? How About a Free Satellite TV System? If Interested, You'll Receive The Following: * Free Delivery * Free Installation * Free In Home Service * Free Premium Programing For 3 Months Enjoy The Features Of Your New System: * Over 150 Channels Of Digital Quality Television * Interactive Television Capability * Innovative 20" Satellite Dish * On Screen graphics, Stereo Receiver And Infared Remote For Further Details Call Our Knowledgeable Support Team At: 1-800-248-5571 and Mention Code 130 Available 24/7 To Answer All Your Questions. BONUS: To The First 1,000 Subscribers * A FREE 3 Day 2 Night Vacation For 2 * CHOOSE FROM 20 DESTINATIONS: Las Vegas, Laughlin, Reno, Lake Tahoe, NV - Atlantic City, NJ - Honolulu, HIDaytona Beach, Orlando, FL - Myrtle Beach, SC - Anaheim, Palm Springs, CA -New Orleans, LA - Gatlinburg, TN - San Antonio, TX - White Mountain, NH -Pocono Mountains, PA - Branson, MO - Putero Vallarta, Cancun, Mazatlan, MX Sent in compliance with U.S. Senate Bill 1618, Title 3, Section 301. Further transmissions to you by the sender may be stopped by sending a reply to this email address with the word REMOVE in the subject line. Remove@mancity.net From rem-conf Wed Dec 20 04:30:23 2000 From rem-conf-request@es.net Wed Dec 20 04:30:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148i9Q-0002MW-00; Wed, 20 Dec 2000 04:15:20 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 148i9O-0002MM-00; Wed, 20 Dec 2000 04:15:18 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20360; Wed, 20 Dec 2000 07:15:13 -0500 (EST) Message-Id: <200012201215.HAA20360@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-smpte292-video-01.txt Date: Wed, 20 Dec 2000 07:15:12 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for SMPTE 292M Author(s) : L. Gharai, G. Goncher, C. Perkins, D. Richardson, A. Mankin Filename : draft-ietf-avt-smpte292-video-01.txt Pages : 9 Date : 19-Dec-00 This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 292M into a payload format for the Real-Time Transport Protocol (RTP). The RTP packet counter is extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte292-video-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-smpte292-video-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-smpte292-video-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001219130436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-smpte292-video-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-smpte292-video-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001219130436.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Dec 20 10:50:49 2000 From rem-conf-request@es.net Wed Dec 20 10:50:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 148o4f-0007cE-00; Wed, 20 Dec 2000 10:34:49 -0800 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 148o4e-0007c3-00; Wed, 20 Dec 2000 10:34:48 -0800 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id TAA26527; Wed, 20 Dec 2000 19:34:45 +0100 (MET) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma026525; Wed, 20 Dec 00 19:34:45 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA15462; Wed, 20 Dec 2000 19:34:45 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA25086; Wed, 20 Dec 2000 19:34:44 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900014714558; Wed, 20 Dec 2000 19:44:27 +0100 To: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: MPEG-4 player Message-ID: <0056900014714558000002L082*@MHS> Date: Wed, 20 Dec 2000 19:44:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 12/20/00 19:34:03" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Following several "private" requests for this URL: Our first MPEG-4 player (win32 platforms) is available (as well as some demo content) at: http://www.mpeg-4player.com Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions philippe.gentric@philips.com = From rem-conf Thu Dec 21 02:41:30 2000 From rem-conf-request@es.net Thu Dec 21 02:41:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1492Wz-0003ka-00; Thu, 21 Dec 2000 02:01:01 -0800 Received: from pelican.tk.uni-linz.ac.at [140.78.188.41] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1492Ww-0003kP-00; Thu, 21 Dec 2000 02:00:58 -0800 Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA05690 for ; Thu, 21 Dec 2000 11:00:50 +0100 (MET) From: Michael Welzl Sender: "Michael Welzl" To: Subject: 2nd CFP Special session "ABR to the Internet", SCI 2001, ext. abstracts due 31.12.00 Date: Thu, 21 Dec 2000 11:07:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pelican.tk.uni-linz.ac.at id LAA05690 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please note that the deadline for submission of extended abstracts (31. 12.) is getting close. Our apologies if you receive this message more than once. Please distribute this call to any of your colleagues who might be interested. -------------------------------------------------------------------- 2nd C A L L F O R P A P E R S Special Session: ABR to the Internet =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order= to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questio= ns: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5= to 2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF = or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, research= ers and consultants, theoreticians and practitioners in the fields of Systemi= cs, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 31. 12. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further informat= ion on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: michael@tk.uni-linz.ac.at SESSION CO-CHAIR: Prof. Dr. Max M=FChlh=E4user TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-dat= e information. From rem-conf Thu Dec 21 08:09:42 2000 From rem-conf-request@es.net Thu Dec 21 08:09:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 149804-00010d-00; Thu, 21 Dec 2000 07:51:24 -0800 Received: from david.siemens.de [192.35.17.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 149803-00010T-00; Thu, 21 Dec 2000 07:51:23 -0800 X-Envelope-Sender-Is: Marcel.Wagner@mchp.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.0/8.11.0) with ESMTP id eBLFpLu23318; Thu, 21 Dec 2000 16:51:21 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.0/8.11.0) with ESMTP id eBLFpKh22398; Thu, 21 Dec 2000 16:51:20 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2448.0) id ; Thu, 21 Dec 2000 16:51:27 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3FB2B3EC@mchp905a.mch.sbs.de> From: Wagner Marcel To: "Adam Li (E-Mail)" Cc: Pandel Juergen , "IETF-AVT (E-Mail)" Subject: RE: AVT meeting summary Date: Thu, 21 Dec 2000 16:51:24 +0100 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 Hi Adam, > About the unequal error protections, it seems that the two > proposals ("An > RTP Payload Format for Generic FEC with Uneven Level > Protection" and "An RTP > Payload Format for Erasure-Resilient Transmission of > Progressive Multimedia > Streams") are covering quite different scopes, even just > figuring out the > simulation condition all agreed on may be unfeasible and may > take a long > time. It might be unnecessary to compare the performance > between them and > choose one based on the comparison alone. > the simulation conditions have been discussed since October and were changed according to your comments. What are your recent objections concerning the feasibility? We should clarify this as soon as possible to be able to complete the simulations until February. Best regards Marcel From rem-conf Thu Dec 21 12:03:17 2000 From rem-conf-request@es.net Thu Dec 21 12:03:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 149BXi-0005C7-00; Thu, 21 Dec 2000 11:38:22 -0800 Received: from (www.b2bsky.com) [202.99.11.214] by mail1.es.net with esmtp (Exim 1.81 #2) id 149BXh-0005Bw-00; Thu, 21 Dec 2000 11:38:21 -0800 Received: from mail.salesforlife.net [63.59.212.40] by www.b2bsky.com (SMTPD32-5.08) id AE5243B902F8; Fri, 22 Dec 2000 02:37:06 +0000 Subject: Are you shopping for a new car for Christmas? From: lance9@salesforlife.net Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-Id: To: hostmaster@uconect.net CC: relztnag@uconect.net, rem-conf@uconect.net, rem-kuro@uconect.net X-Mailer: mozilla 4.7 (en) (win95; U) Date: Thu, 21 Dec 2000 14:42:19 -0500 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Get The Lowest Price On Your New Car Without Negotiating For Hours
Get The Lowest Price On Your New Car
Without Negotiating For Hours!

 

Would you like to get a straight-forward answer from
a sales professional that does not have to "check with his manager"?

 
  • Prices based on dealer invoice.
  • No aggravation.
  • Instant Quotes online.
  • All brands, new, used, take your pick.

     
Click Here

 

To be removed from future mailings click here
From rem-conf Thu Dec 21 13:45:26 2000 From rem-conf-request@es.net Thu Dec 21 13:45:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 149DQ0-0007h5-00; Thu, 21 Dec 2000 13:38:32 -0800 Received: from (ns.heinfo.gov.cn) [210.76.194.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 149DPz-0007gv-00; Thu, 21 Dec 2000 13:38:31 -0800 Received: from [209.81.129.155] by ns.heinfo.gov.cn (Netscape Mail Server v2.02) with SMTP id AAF25003; Fri, 22 Dec 2000 05:34:09 +0800 Received: from mail.chel.com.ru by max1-27.kansascity.corecomm.net with ESMTP; Thu, 21 Dec 2000 15:35:57 -0600 Message-ID: <0000284f69bb$0000629a$00006002@mail.chel.com.ru> To: From: brit.hitchman@5services.cc Subject: The money tree 24578 Date: Thu, 21 Dec 2000 15:35:45 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: adamsd34@hongkong.com X-Mailer: USANET web-mailer (34WB1.4.03) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do You Have The Yen To Be a A Millionaire?

100% return in less than 90 days!

Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

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

Example:

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

For a "FREE NO OBLIGATION" information packet, just Click Below to visit o= ur website:

click here




















To be removed:jackson7558@5services.cc

From rem-conf Fri Dec 22 06:57:08 2000 From rem-conf-request@es.net Fri Dec 22 06:57:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 149TQ2-0005jI-00; Fri, 22 Dec 2000 06:43:38 -0800 Received: from e1.ny.us.ibm.com [32.97.182.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 149TQ1-0005j6-00; Fri, 22 Dec 2000 06:43:37 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA48028; Fri, 22 Dec 2000 09:42:21 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA56472; Fri, 22 Dec 2000 09:40:44 -0500 Importance: Normal Subject: Call for Papers: ACM SIGCOMM 2001 To: ifip-6-1-distr@run.montefiore.ulg.ac.be, ifip-tc6@informatik.rwth-aachen.de, sigmetrics@haven.epm.ornl.gov, dbworld@cs.wisc.edu, f-troup@CODEX.CIS.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com, conf@colmar.uha.fr, Cost264@lip6.fr, domain3@BXL.DG13.cec.eu.int, nichains@BXL.DG13.cec.eu.int, gi-fb3@fokus.gmd.de, kuvs-elg@fokus.gmd.de, multicomm@cc.bellcore.com, kgold@firstconf.com, announcements.chi@acm.com, netnomics@eco.utexas.edu, IEEETCPC-request@LISTSERV.UTORONTO.CA, gigabitkits@arl.wustl.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Dilip D Kandlur" Date: Fri, 22 Dec 2000 09:46:48 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6 |December 14, 2000) at 12/22/2000 09:43:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS ACM SIGCOMM 2001 CONFERENCE August 27 - August 31, 2001 Mandeville Auditorium, UC San Diego, CA, USA. http://www.acm.org/sigcomm/sigcomm2001 Important Dates: Paper submission: January 26, 2001 Tutorial proposals: February 12, 2001 Notification of acceptance: April 23, 2001 Camera ready papers: May 21, 2001 The SIGCOMM 2001 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Areas of interest include, but are not limited to: - Distributed application networking infrastructure. - Distributed common application services, middleware protocols, and signaling. - Routing, switching, and addressing. - Resource sharing, quality of service, multimedia networks, and OS support. - Multimedia networking. - Networking aspects of the WWW. - Heterogeneous internetworking, large-scale networks. - Network management. - Active network architectures and protocols. - Important experimental results from operational networks and lessons learned from prototype implementations. - Wireless networking and support for nomadic computing. - Analysis and design of computer network architectures and algorithms. SIGCOMM 2001 is a single-track, highly selective conference at which successful submissions typically report results firmly substantiated by experiment, implementation, simulation, or mathematical analysis. In addition to the technical program (paper presentations), SIGCOMM 2001 will offer tutorials by noted instructors on the two days preceding the actual conference, and feature an outrageous opinion session where fresh and unconventional perspectives will be offered. Submission Instructions: ------------------------ Papers must be less than 20 double-spaced pages long (formatted for printing in the Proceedings, papers may not be longer than 12 pages), have an abstract of 100-150 words, and be original material that has not been previously published nor is currently under review by another conference or journal. Authors must submit papers electronically, using the instructions at http://www.acm.org/sigs/sigcomm/sigcomm2001/submission/index.htm. Authors not able to comply with these instructions should contact the Program Co-Chairs at sigcomm2001@seas.upenn.edu . Papers submitted after the deadline will not be considered without an ahead-of-time extension from the Program Co-Chairs. All submitted papers will be judged based on their quality and relevance through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Consult the on-line submission instructions for information on preparing a manuscript for double-blind review. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at the conference. The Proceedings of the conference will be published as a special issue of ACM SIGCOMM Computer Communication Review. The Program Committee may also select a few papers for possible publication in the IEEE/ACM Transactions on Networking. Electronic copies of the accepted papers will be published on the SIGCOMM 2001 web site prior to the conference unless authors specifically request that this not be done. Tutorials: ---------- SIGCOMM 2001 will begin with two days of full-day and half-day tutorials covering single topics in detail, at both the introductory or advanced level. Individuals interested in submitting tutorial proposals are encouraged to contact the Tutorial Chair before the deadline to discuss the proposed content. Student Paper Award ------------------- Papers submitted by students may be considered for a student-paper award, which includes full conference registration and a travel grant of approximately $500. To be eligible, the student must be the sole author of the paper, or the first author and primary contributor. A cover letter or email to the Program Chairs must identify the paper as a candidate for this competition. SIGCOMM Award: -------------- The keynote speaker at SIGCOMM 2001 will be the 2001 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained from Scott Shenker (shenker@aciri.org). From rem-conf Mon Dec 25 20:36:44 2000 From rem-conf-request@es.net Mon Dec 25 20:36:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14AlIM-0006W0-00; Mon, 25 Dec 2000 20:01:02 -0800 Received: from (cc-edu.cc-edu.com) [202.103.190.137] by mail1.es.net with esmtp (Exim 1.81 #2) id 14AlIA-0006Pq-00; Mon, 25 Dec 2000 20:00:51 -0800 Received: from cccm-www.cc-edu.com (szptt103-190.szptt.net.cn [202.103.190.161]) by cc-edu.cc-edu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XKKA901Z; Tue, 26 Dec 2000 12:00:40 +0800 Received: from 63.38.73.39 ([63.38.73.39]) by cccm-www.cc-edu.com with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 26 Dec 2000 11:58:43 +0800 Message-ID: <000076ca3b8e$00005d76$00003b1d@63.38.73.39> To: From: alonzo@sprintmail.com Subject: Cash In Today 15133 Date: Mon, 25 Dec 2000 19:56:53 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE Mortgage Quote


 HOMEOWNERS

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

 WE SPECIALIZE IN FAST AND EASY APPROVALS

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

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

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

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

 * WE FUND THE LOANS THAT OTHER LENDERS TURN DOWN!

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



Our 60 second application

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



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



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

 

 

 

 

 

From rem-conf Tue Dec 26 12:32:31 2000 From rem-conf-request@es.net Tue Dec 26 12:32:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14B0El-00017p-00; Tue, 26 Dec 2000 11:58:19 -0800 Received: from mailhost.softeam.fr [194.2.241.2] (emailing) by mail1.es.net with esmtp (Exim 1.81 #2) id 14B0Eg-00017f-00; Tue, 26 Dec 2000 11:58:15 -0800 Received: (from emailing@localhost) by mailhost.softeam.fr (8.9.3/8.9.3/idpgr-1.2.6) id VAA10211 for rem-conf@es.net; Tue, 26 Dec 2000 21:11:52 +0100 (MET) Date: Tue, 26 Dec 2000 21:11:52 +0100 (MET) Message-Id: <200012262011.VAA10211@mailhost.softeam.fr> To: rem-conf@es.net From: SOFTEAM Subject: The Objecteering Letter MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C06C13.5C5337F0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C06C13.5C5337F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.softeam.fr id VAA10211 The Objecteering Letter : _____ Build a highly professional UML CASE Tool adapted to dedicated domains, environments or skills in a couple of weeks, and deploy it freely worldwi= de. This is an exclusive advantage of the "UML Open Edition" initiative. The "UML Open Edition" toolset is based on an extension of the UML profil= e mechanism, as defined for the new OMG UML1.4 standard, and provides a mea= ns of packaging and deploying a set of profiles in the form of "modules" tha= t will customize the Objecteering/UML Modeler CASE Tool. UML Open Edition regulated by a charter (accessible from the site), desig= ned to protect the developments in which members may have invested. UML Open Edition is a community in which any organization can participate(Individuals, Companies, Research centers, Universities, Students, etc). Members can register for UML open edition on the umlopenedition.com web site and can also diffuse their modu= les via this site. UML Users can download available extensions from the umlopenedition.com web site and take advantage of a UML too= l specialized for a specifically chosen domain. Lets take the example of an organization which has good XML skills, and a good knowledge of implementing a UML diagram in XML. This organization ha= s simply to become a member of UML Open Edition, and acquire an Objecteering/UML Open Edition license at a special rate (see the web site= ). It can then define UML Profiles, including UML extensions, and also dedicated behaviors, such as model transformations, consistency checks, c= ode generation or a dedicated GUI. These profiles are then packaged in the fo= rm of an Objecteering "module" that can be published on the site. In this wa= y, anybody can obtain the Objecteering CASE tool free of charge(Personal Edition, downloadable at www.objecteering.com) customized in the form of = a tool dedicated to UML modeling and XML generation. It is up to the organization itself to decide to deploy this module as a free, open or payable module. UML Open Edition will in the future help provide modules dedicated to rea= l time, to component modeling, to EJB generation, to software process modeling, etc. UML Open Edition uses the Objecteering/UML Profile Builder tool , which h= as unique and highly impressive customization capacities. This tool has been used to automate design pattern generation, document generation, code (Ja= va, C++, EJB, XML, IDL, VB, SQL, etc.) generation, model checking, automated diagram creation, process driven development, etc. We wish that umlopenedition.com becomes = a dialog forum, and that everyone be able to easily distribute his knowledg= e as a dedicated toolset. -- In accordance with french law N=B078-17 of the 6th January 1978, you can,= at any time, ask to be withdrawn from this letter, by clicking on the "Reply= to sender" button and marking "Unsubscribe" as the subject of the message ------=_NextPart_000_0012_01C06C13.5C5337F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Objecteering Letter :

The Objecteering Letter = :

Build a highly professional UML CASE Tool adapted to dedicated domains, = environments or skills in a couple of weeks, and deploy it freely worldwide. =

This is an = exclusive advantage of the "UML Open Edition" = initiative.

The "UML Open Edition" toolset is based on an extension of the UML profile = mechanism, as defined for the new OMG UML1.4 standard, and provides a means of = packaging and deploying a set of profiles in the form of "modules" = that will customize the Objecteering/UML Modeler CASE Tool.

UML Open Edition = regulated by a charter (accessible from the site), designed to protect the = developments in which members may have invested. UML Open Edition is a community in = which any organization can participate(Individuals, Companies, Research = centers, Universities, Students, etc).

Members can = register for UML open edition on the umlopenedition.com web site and can also diffuse their modules = via this site.

UML Users can = download available extensions from the umlopenedition.com web site and take advantage of a UML tool specialized for a specifically chosen domain.

Lets take the = example of an organization which has good XML skills, and a good knowledge of implementing a UML diagram in XML. This organization has simply to = become a member of UML Open Edition, and acquire an Objecteering/UML Open = Edition license at a special rate (see the web site). It can then define UML Profiles, including UML extensions, and also dedicated behaviors, such = as model transformations, consistency checks, code generation or a = dedicated GUI. These profiles are then packaged in the form of an Objecteering "module" that can be published on the site. In this way, = anybody can obtain the Objecteering CASE tool free of charge(Personal Edition, downloadable at www.objecteering.com<= /font>) customized in the = form of a tool dedicated to UML modeling and XML generation. It is up to = the organization itself to decide to deploy this module as a free, open or payable module.

UML Open Edition = will in the future help provide modules dedicated to real time, to component modeling, to EJB generation, to software process modeling, etc. =

UML Open Edition = uses the Objecteering/UML Profile Builder tool , which has unique and highly impressive customization capacities. This tool has been used to = automate design pattern generation, document generation, code (Java, C++, EJB, = XML, IDL, VB, SQL, etc.) generation, model checking, automated diagram = creation, process driven development, etc.

We wish that = umlopenedition.com becomes a dialog forum, and that everyone be = able to easily distribute his knowledge as a dedicated = toolset.

--

In accordance with = french law N=B078-17 of the 6th January 1978, you can, at any time, ask to be withdrawn from this letter, by clicking on the "Reply to = sender" button and marking "Unsubscribe" as the subject of the = message

 

------=_NextPart_000_0012_01C06C13.5C5337F0-- From rem-conf Wed Dec 27 23:57:08 2000 From rem-conf-request@es.net Wed Dec 27 23:57:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14BXh6-00004S-00; Wed, 27 Dec 2000 23:41:48 -0800 Received: from (f1engine.clair.net) [207.219.65.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 14BXgw-000035-00; Wed, 27 Dec 2000 23:41:38 -0800 Received: from 216.79.80.96 ([216.79.80.96]) by f1engine.clair.net (8.8.5/SCO5) with SMTP id CAA03268; Thu, 28 Dec 2000 02:36:42 -0500 (EST) From: xvz3@aol.com Message-Id: <200012280736.CAA03268@f1engine.clair.net> To: qwd6@aol.com Subject: Best DVD Player...$299 Date: Thu, 28 Dec 00 02:19:45 Pacific Standard Time Reply-To: xvz3@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html;


The DIGIVIEW 3200 DVD PLAYER!!!

 PLAYS ALL DVDS Mp3's and VCDS.......

 For more info or to place an
order call:
 1 800-474-9698

 "Get Free Shipping with Special Offer Code300 "

Did you know that with 6 different types of DVD disks on the market, not
all players can play all DVDs??
That's right...The low end DVD models in most stores can't play all DVD movies!! But instead of spending $600 or more on a dvd player that can play all 6 typesof disks, now you have a choice....

 The DIGIVIEW 3200 DVD,CD MP3 Player.
 REGION FREE...PlayDVDS from all over the world.
 The DIGIVIEW 3200 DVD,CD MP 3 Player. Comparable to the $600 model you have
been looking at in Circuit City, Best Buy and the rest.
 Now available at half the cost. ONLY $299.00 With Warranty
 For more info or to place an order call:
 1 800-474-9698

 "Get Free Shipping with Special Offer Code300 "
 SPECIAL OFFER ! ONLY $299.00 With Warranty!
We Ship Anywhere in the World!
 For more info or to place an order call:
 1 800-474-9698

 "Get Free Shipping with Special Offer Code300 "
 ONLY $299.00 withWarranty!
 JUST LOOK AT THESE FEATURES!
 -MACROVISION DISABLED (allows copying)!!
-Dolby& reg; Digital (AC3)
- MP3 Playback, ScreenSaver
-Region Free playback capabilities
-Supports DVD/CD/MP3/VCD/SVCD/CDR Playback
-Also comes with two built in games (Tetris and Othello)
and much more!!
 For more info or to place an order call:
 1 800-474-9698
 "Get Free Shipping with Special Offer Code300 "


From rem-conf Fri Dec 29 15:47:03 2000 From rem-conf-request@es.net Fri Dec 29 15:47:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14C90Y-00057p-00; Fri, 29 Dec 2000 15:32:22 -0800 Received: from myriad.its.unimelb.edu.au [128.250.6.196] by mail1.es.net with esmtp (Exim 1.81 #2) id 14C90W-00057f-00; Fri, 29 Dec 2000 15:32:21 -0800 Received: from BORONIA.mlg.pau.philips.com (its-dialin2asy57.its.unimelb.edu.au [128.250.138.185]) by myriad.its.unimelb.edu.au (8.9.3/8.9.3) with SMTP id KAA14248 for ; Sat, 30 Dec 2000 10:32:15 +1100 (AEDT) Message-Id: <4.1.20001230095320.009a0960@clyde.its.unimelb.edu.au> X-Sender: dxpc@clyde.its.unimelb.edu.au X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 30 Dec 2000 10:03:50 +1100 To: rem-conf@es.net From: dxpc Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I have problems to get the Media Data in Scheme1 format from the RTP payload of QT RTP packets. Originally, I thought all three Media Data Scheme use the Media Data format "S bit + Sample Length + Sample Timestamp + Sample Data". But, after revisiting Dispatch 26 again, I suspect that the Scheme1 and Scheme3 may directly put the Sample Data in the Media Data field without "S bit + Sample Length + Sample Timestamp". The spec does not indicate this clearly. Could someone confirm me whether my understanding is right or wrong please? Thank you for your help. Happy new year. yh