From rem-conf Tue Feb 01 00:37:11 2000 From rem-conf-request@es.net Tue Feb 01 00:37:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12FYio-000485-00; Tue, 1 Feb 2000 00:31:38 -0800 Received: from laas.laas.fr [140.93.0.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12FYih-00047t-00; Tue, 1 Feb 2000 00:31:36 -0800 Received: from klebs.laas.fr (root@klebs [140.93.192.5]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id JAA07438; Tue, 1 Feb 2000 09:25:56 +0100 (MET) Received: from laas.fr (sfax [195.83.132.83]) by klebs.laas.fr (8.9.3/8.9.3) with ESMTP id JAA27282; Tue, 1 Feb 2000 09:25:11 +0100 (MET) Message-ID: <389699E4.BF6AE8A2@laas.fr> Date: Tue, 01 Feb 2000 09:31:32 +0100 From: Khalil Drira X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, kia@usl.edu, multicomm@cc.bellcore.com, osimcast@bbn.com, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, ARP LYON CC: Claude Ghaoui Subject: , Collaboration in Multimedia NA and Groupware (Deadline is approaching) Content-Type: multipart/mixed; boundary="------------22D521F17A4F9D6E92C79143" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------22D521F17A4F9D6E92C79143 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (Our apologies if you receive this message multiple times) --------------22D521F17A4F9D6E92C79143 Content-Type: text/plain; charset=us-ascii; name="cfpcoop.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cfpcoop.txt" CALL FOR PAPERS Special Session on Collaboration in Multimedia Networked Applications and GroupWare Session Co-ordinators: Michel Diaz, Khalil Drira, Thierry Villemur ({diaz,drira,villemur}@laas.fr) at the EUROMICRO WORKSHOP on Multimedia and Telecommunication Maastricht, Netherlands, Sept. 4-7, 2000 Workshop Programme Chair: Claude Ghaoui (c.ghaoui@livjm.ac.uk) http://www.laas.fr/~khalil/cmnag.html Important Dates Deadline for Paper Submission and Compositions: February 28th, 2000 Notification of acceptance: May 2nd, 2000 Camera-ready paper due: June 15th, 2000 Deadline for proposals(of Other Submissions): October 15th, 1999 Proposal acceptance: October 30th, 1999 Overview The Euromicro workshop is a forum for interdisciplinary research and practice in computer systems, interfaces, architectures and applications. As part of the year 2000 conference in the Netherlands there will be a special session looking at . This session is organised as part of the Workshop on Multimedia and Telecommunication. Background The purpose of this session is to bring together researchers, and practitioners working on cooperation, coordination and communication in Multimedia Networked Applications and GroupWare. The session serves as a forum enabling experience exchange between academia and industry as well as between researchers working in the different multimedia and groupware research branches. Topics of interest include but are not limited to: + Formal and semi-formal methods for groupware and multimedia applications modeling and analysis + architecture of groupware and multimedia applications + object oriented design and implementation of cooperation and coordination protocols + coordination models and applications for CSCW using multimedia applications + group membership protocols + applications in Java and CORBA Queries Any questions regarding submissions for this session should be made (ideally via email) to one of the session coordinators , but full papers should be sent to the Programme Chair directly (Claude Ghaoui). The Call for Papers for the whole workshop can be viewed in pdf format here. Submission of Papers There is no restriction on the number or type of submissions. For technical papers, both regular papers and short contributions are invited. Authors should send their full paper to the Programme Chair directly as: 1) a PostScript version by Email, and 2) four copies by Post. The papers should not exceed 4000 words and should include an abstract of up to 150 words. The title page should be separate and clearly show the name, full mailing address, e-mail and fax number of the author to contact, as well as the topic areas of the submitted paper. Papers will be blind-refereed by three reviewers who are expert in the domain area. Accepted papers will appear in the proceedings which will be published by the IEEE Computer Society and be available at the conference. Papers exceeding 8 pages will be charged NLG 100 per page in excess. The following signed statement should be included on the cover page: "Neither this paper nor any version close to it has been or is being offered elsewhere for publication. All necessary clearances have been obtained for the publication of this paper. If accepted, the paper will be made available in Camera-ready forms by June 15th, 2000, and it will be personally presented at the EUROMICRO 2000 Conference by the author or one of the co-authors. The presenting author(s) will pre-register for EUROMICRO 2000 before the due date of the Camera-ready paper." Journal Publication for Best Papers In addition, selected best papers will be considered for journal publication. Authors of these papers will be advised on submitting extended versions of their originals for this purpose. Journals offered are: + Special issue, Journal of Network and Computer Applications (JNCA), Guest Editor is Claude Ghaoui, 'Support for Open and Distance Learning on the WWW', Academic Press pub. + Special issue, J. `Digital Creativity', Swets pub. + European J. Engineering Educ. (EJEE), SEFI pub. + J.Interactive Learning Environments, Intellect pub. + International J. of Knowledge and Information Systems (KAIS), Springer-Verlag pub. + Real Time Graphics & ACM SIGBIO Newsletters Other Submissions Special Sessions, Panels, Half-day or 1-day tutorials and Short Courses (90-180 minutes) on related topics are welcomed. Companies and students working on Projects of different levels (undergrad., postgrad. or industrially-oriented) are invited to participate in a Project Showcase. Submission and reviewing will follow the same procedure of the regular papers. Email the proposal to the programme chair, including: your submission title and aims, targeted audience, your plan of how to make it a success, short CV and full contact address of the proposer (with email) and any other supporting information. For special sessions or panels, please include a detailed Call for Papers/Participation. Keynote Speaker Prof. H. Maurer, Institute for Information Processing and Computer Supported Media, Technical University Graz, Austria. His main research areas are: multimedia systems; E. publishing, Web based learning; telematic; computer networks; CAL; computer supported media & social implications. He is the author of fourteen books, over 450 scientific contributions and dozens of multimedia products. He is the project manager of a number of multimillion-dollar projects. (see http://www.iicm.edu/maurer) Programme Chair Dr Claude Ghaoui School of Computing and Mathematical Sciences, Liverpool John Moores University, Byrom Street, Liverpool L3 3AF United Kingdom Tel: +44 151 .231 2276 Fax: +44 151 207 4594 C.GHAOUI@LIVJM.AC.UK Session Coordinators Michel Diaz , Khalil Drira , Thierry Villemur Communication Tools and Software Group LAAS-CNRS 7, Av. Colonel Roche 31077 Toulouse Cedex 4 FRANCE e-mail: diaz@laas.fr , drira@laas.fr , villemur@laas.fr Tel: +33 5 61 33 62 56 / +33 5 61 33 63 22 / +33 5 61 33 69 55 Fax: +33 5 61 33 64 11 General Information The workshop is an integral part of the EUROMICRO 2000 conference. UPDATED INFORMATION See the EUROMICRO WWW : http://www.euromicro.org --------------22D521F17A4F9D6E92C79143-- From rem-conf Tue Feb 01 11:08:14 2000 From rem-conf-request@es.net Tue Feb 01 11:08:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12FiSn-0005Db-00; Tue, 1 Feb 2000 10:55:45 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 12FiSl-0005DR-00; Tue, 1 Feb 2000 10:55:43 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA29437; Tue, 1 Feb 2000 10:42:36 -0800 (PST) Message-Id: <3.0.3.32.20000201104241.00a762c0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 01 Feb 2000 10:42:41 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 2/2/2000 Estimation of Web Video Multiplicity -- Samson Cheung, EECS Department, U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Estimation of Web Video Multiplicity Wednesday February 2, 2000 1:10 - 2:30 PST Fujitsu Seminar Room (405 Soda Hall) Sen-ching Samson Cheung EECS Department, U.C. Berkeley With ever more popularity of video web-publishing, many popular contents are being mirrored, modified and republished, resulting in excessive content duplication. While such redundancy provides fault tolerance for continuous availability of information, it could potentially make multimedia web search results repetitious and cluttered. As such, developing techniques for detecting similarity and duplication is important to multimedia search engines. Content providers might also be interested in identifying duplicates of their content for business related reasons. In this talk, we will present an efficient algorithm, called video signature, to detect similar video sequences for large databases. The idea is to first form a "signature" for each video sequence by selecting a small number of its frames that are most similar to a number of randomly chosen seed images. Then the similarity between any two video sequences can be reliably estimated by comparing their respective signatures. Using this method, we achieve 85% recall and precision ratios on a test database of 377 video sequences. We have applied our proposed algorithm to a collection of 1800 hours of video corresponding to around 45000 clips from the web. Our results indicate that, on average, every video in our collection has around five similar copies. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm You'll see a link to cs298-5/real networks/live programs. You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Wed Feb 02 02:53:56 2000 From rem-conf-request@es.net Wed Feb 02 02:53:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Fx95-0005kL-00; Wed, 2 Feb 2000 02:36:23 -0800 Received: from hd2.vsnl.net.in (hd2.dot.net.in) [202.54.30.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Fx93-0005kB-00; Wed, 2 Feb 2000 02:36:21 -0800 Received: from hyd.chiplogic.com ([203.197.21.159]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id QAA22836 for ; Wed, 2 Feb 2000 16:05:29 +0530 (IST) Received: from chiplogic.com ([192.168.2.66]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id PAA25900 for ; Wed, 2 Feb 2000 15:33:45 +0530 Message-ID: <38980466.2150E178@chiplogic.com> Date: Wed, 02 Feb 2000 15:48:15 +0530 From: "T.V.Rami Reddy" Organization: Chiplogic X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: timstamps in rtp and rtcp? Content-Type: multipart/alternative; boundary="------------BB467BA2C8833963F0358A6E" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------BB467BA2C8833963F0358A6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, can anyone give the detailed difference between the rtp timestamp in the rtp packet and timestamp in the rtcp SR packet. suppose if an rtcp SR packet is send rtcpSR------------ntp timestamp 2nd feb 2000 10:00:05 time stamp 1174(some value) then let 4 rtp packets be send in the interval before an another rtcp SR packet is send rtp 1234 rtp 1394 (234+160 say) rtp 1454 (1394+160 ) rtp 1514 (1454+160 ) rtcp SR ------------ntp timestamp 2nd feb 2000 10:00:10 timestamp will be 1234 or 1514 or ? thanks, --------------BB467BA2C8833963F0358A6E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi,
can anyone give the detailed difference between the rtp timestamp in the rtp packet and timestamp in the rtcp SR packet.
suppose if an rtcp SR packet is send
rtcpSR------------ntp timestamp 2nd feb 2000  10:00:05   time stamp 1174(some value)
then let 4 rtp packets be send in the interval before an another rtcp SR packet is send
rtp                1234
rtp                1394 (234+160 say)
rtp                1454 (1394+160 )
rtp                1514  (1454+160 )
rtcp SR   ------------ntp timestamp 2nd feb 2000 10:00:10   timestamp will be  1234 or 1514 or ?
 

thanks, --------------BB467BA2C8833963F0358A6E-- From rem-conf Wed Feb 02 05:38:07 2000 From rem-conf-request@es.net Wed Feb 02 05:38:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12FzkT-0007cm-00; Wed, 2 Feb 2000 05:23:09 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12FzkP-0007cc-00; Wed, 2 Feb 2000 05:23:06 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Feb 2000 13:23:00 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id NAA32578; Wed, 2 Feb 2000 13:23:12 GMT Message-Id: <200002021323.NAA32578@cperkins-d.cs.ucl.ac.uk> To: "T.V.Rami Reddy" cc: rem-conf@es.net Subject: Re: timstamps in rtp and rtcp? In-Reply-To: Message from "T.V.Rami Reddy" of "Wed, 02 Feb 2000 15:48:15 +0530." <38980466.2150E178@chiplogic.com> Date: Wed, 02 Feb 2000 13:23:12 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "T.V.Rami Reddy" writes: >can anyone give the detailed difference between the rtp timestamp in the >rtp packet and timestamp in the rtcp SR packet. >suppose if an rtcp SR packet is send >rtcpSR------------ntp timestamp 2nd feb 2000 10:00:05 time stamp >1174(some value) >then let 4 rtp packets be send in the interval before an another rtcp SR >packet is send >rtp 1234 >rtp 1394 (234+160 say) >rtp 1454 (1394+160 ) >rtp 1514 (1454+160 ) >rtcp SR ------------ntp timestamp 2nd feb 2000 10:00:10 timestamp >will be 1234 or 1514 or ? The RTP timestamp in an SR packet represents the time at which that SR packet is generated (section 6.4.1 of draft-ietf-avt-rtp-new-05.txt). Both NTP and RTP clocks are free-running, and are sampled at the instant the packet is generated. For example: NTP time RTP time 2 Feb 2000 13:15:00.000 1000 RTP 2 Feb 2000 13:15:00.020 1160 RTP 2 Feb 2000 13:15:00.030 1240 RTCP SR 2 Feb 2000 13:15:00.040 1320 RTP 2 Feb 2000 13:15:00.060 1480 RTP 2 Feb 2000 13:15:00.080 1640 RTP 2 Feb 2000 13:15:00.100 1800 RTP 2 Feb 2000 13:15:00.120 1960 RTP 2 Feb 2000 13:15:00.140 2120 RTP ... ... ... The SR packets provide a mapping between the RTP clock and the NTP clock, so that RTP data packets don't need to include the NTP timestamp. Colin From rem-conf Wed Feb 02 10:29:35 2000 From rem-conf-request@es.net Wed Feb 02 10:29:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12G4AX-0002LC-00; Wed, 2 Feb 2000 10:06:21 -0800 Received: from oberon.dnai.com [207.181.194.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 12G4AV-0002JN-00; Wed, 2 Feb 2000 10:06:19 -0800 Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id KAA40336 for ; Wed, 2 Feb 2000 10:05:14 -0800 (PST) Received: from hariv (cheetah1 [216.15.52.38]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id KAA16569 for ; Wed, 2 Feb 2000 10:05:04 -0800 (PST) Message-ID: <008e01bf6da8$a56116c0$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Audio Playout buffer Date: Wed, 2 Feb 2000 10:09: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 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 Hi, This is w.r.to Audio playout issue: I am going through various implementation issues. How much delay does the packet jitter Buffer contribute to the overall end to end delay. Assume that a fixed buffer is used containing of N-packets. Regards Hari From rem-conf Wed Feb 02 11:14:29 2000 From rem-conf-request@es.net Wed Feb 02 11:14:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12G532-0003Li-00; Wed, 2 Feb 2000 11:02:40 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 12G52y-0003LM-00; Wed, 2 Feb 2000 11:02:36 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA23541; Wed, 2 Feb 2000 11:01:27 -0800 (PST) Date: Wed, 2 Feb 2000 11:04:16 -0800 (Pacific Standard Time) From: Stephen Casner To: "T.V.Rami Reddy" cc: rem-conf@es.net Subject: Re: timstamps in rtp and rtcp? In-Reply-To: <38980466.2150E178@chiplogic.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 2 Feb 2000, T.V.Rami Reddy wrote: > can anyone give the detailed difference between the rtp timestamp in the > rtp packet and timestamp in the rtcp SR packet. > suppose if an rtcp SR packet is send > rtcpSR------------ntp timestamp 2nd feb 2000 10:00:05 time stamp > 1174(some value) > then let 4 rtp packets be send in the interval before an another rtcp SR > packet is send > rtp 1234 > rtp 1394 (234+160 say) > rtp 1454 (1394+160 ) > rtp 1514 (1454+160 ) > rtcp SR ------------ntp timestamp 2nd feb 2000 10:00:10 timestamp > will be 1234 or 1514 or ? Essentially the same question was asked on this list two weeks ago. The RTP spec says: NTP timestamp: 64 bits Indicates the wallclock time (see Section 4) when this report was sent ... RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. ... --> Note that in most cases this timestamp --> will not be equal to the RTP timestamp in any adjacent data --> packet. Rather, it MUST be calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant. Please let me know whether the text above is unclear or hard to find in the document so we can improve it for the next revision. The method I recommend to calculate the RTP timestamp for the RTCP SR packet is as follows. Periodically, at the time a sample buffer completes, establish a correspondence between the RTP timestamp that will correspond to the first sample in that buffer and the time that sample was taken according to the clock used for the NTP timestamps. That time is usually the current time minus the duration of the buffer and some allowance for interrupt or operating system latency. The correspondence is an offset in RTP timestamp units: offset = (int32)(current_NTP_time * RTP_timestamp_clock_rate) - RTP_timestamp where current_NTP_time is in seconds and fraction. The calculation can be done in floating point (double precision) or with multiple-precision integer arithmetic. In both cases, there will be a truncation to get the 32-bit integer offset and RTP timestamp. You don't need to do this calculation on every sample buffer, just often enough to accommodate the drift between the sampling clock and the clock used for the NTP timestamps if these come from different oscillators (for example, a crystal on the audio board and a crystal on the motherboard from which the operating system clock is derived). If both clocks are derived from the same oscillator, you only need to establish the correspondence once because there will be no drift, but then the NTP times are probably not synchronized with Network Time Protocol to absolute time. Ideally, the capture interrupt routine would return a timestamp for the capture time from which you could form the NTP timestamp. After you have calculated the offset, then when it is time to send an RTCP SR packet, you get the current NTP time and calculate the RTP timestamp for the SR packet as: RTP_timestamp = (int32)(current_NTP_time * RTP_timestamp_clock_rate) - offset I think this is pretty easy. Generating these timestamps accurately is critical for the receivers to be able to use them for inter-media synchronization. Unfortunately, if the server does a bad job of it, then it is the receiver that looks bad because the presentation is out of sync. (Of course, the receiver can also mess up the synchronization even when it is given good timestamps.) -- Steve From rem-conf Thu Feb 03 10:35:53 2000 From rem-conf-request@es.net Thu Feb 03 10:35:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12GQsj-0006Nd-00; Thu, 3 Feb 2000 10:21:29 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 12GQsi-0006NS-00; Thu, 3 Feb 2000 10:21:28 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA10434; Thu, 3 Feb 2000 10:00:27 -0800 (PST) Message-Id: <3.0.3.32.20000203100000.00aaf730@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 03 Feb 2000 10:00:00 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 2/9 User Experiences with the Communications Revolution -- Charles H. House, Intel Dialogic Division Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gumby.CS.Berkeley.EDU id KAA10434 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar User Experiences with the Communications Revolution Wednesday February 9, 2000,=20 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall)=20 Charles H. House Intel Dialogic Division=20 After driving fifty miles down a long road in eastern China, and seeing s= ix vehicles in an hour, heading to a "town" of 4 million people with only three "Western" hotels, our driver=92s beeper beeped. He pulled it out of= his pocket, scanned the screen, and said, in perfect English, "ahh, Cisco, up= a =BD point". Not as compelling as the wireless phone call from the top of = Mt. Everest to his wife in New Zealand as the stricken climber died, but compelling enough for the van of travelers that the world of communicatio= ns has indeed changed.=20 What will be the impact of our new technologies - ever more complex and cheaper chips, wireless and glass-based wideband networks, and ubiquitous databases with XML cross-product "joins"? Everything from e-commerce to "virtual meetings" to new forms of company, community, and governance wil= l happen. The CITS group (Center for Information Technology and Society) at UCSB has been established to study these impacts from a wide perspective. Our speaker, who had a key role in founding the Center, will describe som= e of the inquiry that will be done there, and some of the major observation= s of where this work might be expected to lead. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Network= s G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm=20 You'll see a link to cs298-5/real networks/live programs. =20 You can also directly put in this url into the Real Player:=20 rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving t= he announcement you may be able to receive the session by manually configuri= ng the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center=20 From rem-conf Thu Feb 03 11:05:40 2000 From rem-conf-request@es.net Thu Feb 03 11:05:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12GRQv-0007g5-00; Thu, 3 Feb 2000 10:56:49 -0800 Received: from (guido) [158.252.1.113] by mail1.es.net with smtp (Exim 1.81 #2) id 12GRQo-0007fU-00; Thu, 3 Feb 2000 10:56:46 -0800 From: "Opera Portables, Inc." To: Message-Id: <419.436559.58204167gjkmail@earthlink.net> Subject: Best New Trade Show Display By Opera Portables, Inc. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2000 10:56:46 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Opera Portables, Inc. is presenting "by invitation" visits to our web site. Newly updated and packed full of exciting display projects and news, Opera is leading the industry with eye-popping visuals and an exhibit structure that is completely new. Opera is a young progressive company and winner of multiple industry awards, including Exhibitor Magazine's Best New Product, Ernst & Young's Crescendo Award, 40 Under Forty and Emerging Thirty. Go to http://3493280838/ and check us out. If you use displays you really owe it to yourself to see our stuff! gjkmail@earthlink.net From rem-conf Thu Feb 03 15:01:32 2000 From rem-conf-request@es.net Thu Feb 03 15:01:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12GV7K-0002up-00; Thu, 3 Feb 2000 14:52:50 -0800 Received: from www.diamondpress.com.au (diamondpress.com.au) [203.111.101.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 12GV7G-0002tg-00; Thu, 3 Feb 2000 14:52:48 -0800 Received: from 2u9SFLIn8 [38.30.162.241] by diamondpress.com.au [10.1.1.52] with SMTP (MDaemon.v2.8.5.0.R) for ; Fri, 04 Feb 2000 07:41:55 +1100 DATE: 03 Feb 00 3:39:18 PM FROM: 1T9todqbh@dsys.korea.ac.kr Message-ID: <3w188qrbNbWt8Lu311gwxl> Received: From 201def568746ghyj24 by 202dewa2548gthu954621grde;Thu, 3 Feb 2000 15:39:18 -400 (EDT) Subject: Important Notice-Anti-aging X-MDaemon-Deliver-To: rem-conf@es.net X-Return-Path: 1T9todqbh@dsys.korea.ac.kr Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Medial News -- Anti-aging Breakthrough-- Grow 10 to 20 Years Younger!!! As announced on NBC News, Dateline NBC, 20/20, Oprah Winfrey and many other news programs and talk shows, you can stop the aging process and actually reverse it. These scientific and medical breakthroughs, which can help millions of Americans better defend against the most devastating diseases of aging such as heart disease, cancer and stroke, are now available to the public. This news is important to every person over 40 and affects every family. Educate yourself. Get the facts now. Documentation beats conversation. Go to our comprehensive scientific Anti-Aging Web site extension- Medial News -- Anti-aging Breakthrough-- Grow 10 to 20 Years Younger!!! As announced on NBC News, Dateline NBC, 20/20, Oprah Winfrey and many other news programs and talk shows, you can stop the aging process and actually reverse it. These scientific and medical breakthroughs, which can help millions of Americans better defend against the most devastating diseases of aging such as heart disease, cancer and stroke, are now available to the public. This news is important to every person over 40 and affects every family. Educate yourself. Get the facts now. Documentation beats conversation. Go to our comprehensive scientific Anti-Aging Web site extension- http://1062687076/ to view the latest medical information on these incredible breakthroughs. Medical experts report that aging is now classified as a disease -- a disease that can be prevented. Scientists have also determined what causes aging and have identified the cure. Getting old isn't inevitable. The biological clock can now be turned back -- 10 to 20 years. A more vital, vibrant and healthy life is possible for everyone. With the new scientific breakthrough products available to the public, you can also monitor your biological age and watch yourself turn the clock back 10, 15 even 20 years. We have scientific evidence that proves you can turn back the clock several years in the first 30 days, while feeling and seeing the following benefits: Reversing the effects of aging; lessening stress levels; strengthening the immune system; lowering blood pressure and cholesterol; improving sexual performance; losing fat; building muscle; removing wrinkles; eliminating cellulite; improving sleep quality; fighting osteoporosis; calming menopause; improving your outlook on life and much more. Go to our scientific Web site extension - http://1062687076/ for complete information. Best of all -- these products are affordably priced and there is nothing to lose with the products -- but years. You can prove that the products work with a simple at-home laboratory test and the products are backed by a 90-day, 100-percent, money-back guarantee from one of the largest FDA-approved pharmaceutical laboratories in the United States. Don't miss this opportunity to educate yourself. Go to our scientific Web site extension- http://1062687076/ and gather all the scientific facts. Best regards, Robert Adams Anti-Aging Counselor ****** We apologize if you are not interested in medical news. The Internet is the fastest method of distributing this type of timely medical information. If you wish to have your e-mail address deleted from our scientific update database, DO NOT USE THE REPLY BUTTON THIS ADDRESS DOES NOT GO TO OUR REMOVE DATA BASE. Simply click here - http://1062687076/ and select the unsubscribe button at the top right side of the page. From rem-conf Sat Feb 05 00:10:03 2000 From rem-conf-request@es.net Sat Feb 05 00:10:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12H08s-0002Hr-00; Sat, 5 Feb 2000 00:00:30 -0800 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 12H08q-0002Hh-00; Sat, 5 Feb 2000 00:00:28 -0800 Received: from tis2.tis.toshiba.co.jp by inet-tsb.toshiba.co.jp (8.8.8/3.3W9-04/12/95) id RAA26095; Sat, 5 Feb 2000 17:00:11 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id RAA05721; Sat, 5 Feb 2000 17:00:10 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id RAA26415; Sat, 5 Feb 2000 17:00:08 +0900 (JST) Received: from ef63.eel.rdc.toshiba.co.jp (srg-75 [133.196.81.75]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id RAA40331; Sat, 5 Feb 2000 17:00:08 +0900 (JST) Message-ID: <01d201bf6faf$3cb1abe0$4b51c485@ef63.eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" Subject: New Internet Draft for MPEG-4 Audio/Visual RTP payload format Date: Sat, 5 Feb 2000 17:01:40 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01CF_01BF6FFA.AC3C3FC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01CF_01BF6FFA.AC3C3FC0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear all, I have submitted a new version of the MPEG-4 Audio/Visual RTP Internet Draft as follows. -------- Title : RTP payload format for MPEG-4 Audio/Visual streams Author(s) : Yoshihiro Kikuchi, Toshiyuki Nomura, Shigeru Fukunaga, Yoshinori Matsui, Hideaki Kimata Filename : draft-ietf-avt-rtp-mpeg4-es-00.txt Pages : 14 Date : 01-Feb-2000 This document describes RTP payload formats for the carriage of MPEG-4 Audio and Visual streams, and an RTCP format for MPEG-4 upstream messages functionalities. In this specification, MPEG-4 Audio/Visual bitstreams are directly mapped into RTP packets without using MPEG-4 Systems. The RTP header fields usage and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are specified. It also specifies an RTCP packet usage to carry the MPEG-4 upstream messages. -------- Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 ------=_NextPart_000_01CF_01BF6FFA.AC3C3FC0 Content-Type: text/plain; name="draft-ieft-avt-rtp-mpeg4-es-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ieft-avt-rtp-mpeg4-es-00.txt" Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-00.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT February 1, = 2000 RTP payload format for MPEG-4 Audio/Visual streams Status of this Memo This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that other = groups may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months and may be = updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to = cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes RTP payload formats for the carriage of = MPEG-4 Audio and Visual streams[2][3], and an RTCP format for MPEG-4 = upstream messages functionalities[4]. In this specification, MPEG-4 = Audio/Visual bitstreams are directly mapped into RTP packets without using MPEG-4 Systems[6]. The RTP header fields usage and the fragmentation rule = for MPEG-4 Visual and Audio bitstreams are specified. It also specifies = an RTCP packet usage to carry the MPEG-4 upstream messages. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 1. Introduction 1.1 Why MPEG-4 Audio/Visual RTP format needed? The RTP payload formats described in this Internet-Draft specify the normative way on how MPEG-4 Audio/Visual streams are fragmented and mapped directly onto RTP packets. No extra header field is used for = such functionality as error protection or grouping of streams. H.323 terminals could be the case. MPEG-4 Audio/Visual streams are = not managed by Object Descriptors[6] but H.245, and directly mapped into = RTP packets without Sync Layer[6]. The semantics of RTP headers in this = case need to be clearly defined including the association with the MPEG-4 Audio/Visual data elements. In addition, it would be beneficial to define the fragmentation rule of RTP packets for MPEG-4 Video streams = to enhance error resiliency by utilizing the error resilience tools = provided inside the MPEG-4 Video stream. However, they have not been studied until now. 1.2 Consideration on the MPEG-4 Visual RTP payload format MPEG-4 Visual is a visual coding standard with many new = functionalities: high coding efficiency, high error resiliency, multiple arbitrary = shaped object based coding, etc. [2]. It covers a wide range of bitrate from several Kbps to many Mbps. It also covers a wide variety of networks = from guarantied with almost error-free to mobile with high error rate by = its error resilience functionalities. A normative way of fragmentation of an MPEG-4 visual bitstream into = RTP packets is defined in this Internet draft. Since MPEG-4 Visual is = used for a wide variety of networks, it is not desired to apply too much restriction on the fragmentation like a single video packet shall = always be mapped on a single RTP packet. On the other hand, a careless media unaware fragmentation may cause degradation of the error resiliency = and the bandwidth efficiency. The fragmentation rule described in this Internet draft is flexible but to define the minimum rules to prevent = the meaningless fragmentation of e.g. splitting a header into packets. For video coding media such as H.261 or MPEG-1/2, the additional = media specific RTP header works effectively for recovering e.g. a picture header corrupt by packet losses. However, there are error resilience functionalities inside MPEG-4 Visual to recover corrupt headers. = These functionalities can commonly be used on RTP/IP network as well as = other networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, no extra RTP = header fields are defined in the MPEG-4 Visual RTP payload format. 1.3 Consideration on the MPEG-4 Audio RTP payload format MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. It also supports a mechanism representing synthesized sounds. Low-overhead MPEG-4 Audio Transport Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Multiplex (LATM) manages the sequence of the compressed or the represented audio data by MPEG-4 Audio tools with relatively small overhead. In audio-only applications, the LATM-based MPEG-4 Audio bitstreams, therefore, are desirable to be directly mapped into the = RTP packets without using MPEG-4 Systems. Furthermore, if the payload of a packet is a single audio frame, a = packet loss does not impair the decodability of adjacent packets. Therefore, = a payload specific header for MPEG-4 Audio is not required as same as = one for the other audio coders. 1.4 MPEG-4 Audio/Visual upstream messaging on RTCP packets In some cases, MPEG-4 Audio/Visual has upstream messaging functionalities. These messages are extremely Audio/Visual specific, since coders directly use these messages for controlling coding parameters. From the point of view of controlling parameters, these messages should be transmitted without delay. Therefore these = messages are directly mapped onto some kind of low delay RTCP packets. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. 3. RTP Packetization of MPEG-4 Visual bitstream This section specifies the RTP packetization rule for MPEG-4 Visual content. An MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or removal of any Visual syntax elements. The Combined Configuration/Elementary streams mode is used so that the configuration information is carried in the = same RTP port as the elementary stream. (see 6.2.1 "Start codes" of = ISO/IEC 14496-2 [2][9][4]) When the short video header mode is used, RTP payload format for = H.263 specified in the relevant RFCs or other standards MAY be used. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | = RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | = Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | | RTP | MPEG-4 Visual stream (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream 3.1 RTP header fields usage for MPEG-4 Visual Payload Type (PT): Distinct payload type should be assigned to = specify MPEG-4 Visual RTP payload format. If the dynamic payload type = assignment is used, it is specified by some out-of-band means (e.g. H.245, SDP, etc.) that the MPEG-4 Visual payload format is used for the = corresponding RTP packet. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Increment by one for each RTP data packet sent. It starts with a random initial value for security reasons. Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder by adding a constant = random offset for security reasons. For a video object plane, it is defined = by vop_time_increment (in units of 1/vop_time_increment_resolution = seconds) plus the cumulative number of whole seconds specified by = module_time_base and time_code of Group_of_VideoObjectPlane() if present. In the case = of interlaced video, a VOP consists of lines from two fields and the timestamp indicates the composition time of the first field. If the = RTP Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D packet contains only configuration information and/or Group_of_VideoObjectPlane(), the composition time of the subsequent = VOP in the coding order is used. If the RTP packet contains only visual_object_sequence_end_code, the composition time of the = immediately preceding VOP in the coding order is used. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default (90KHz). SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 3.2 Fragmentation of MPEG-4 Visual bitstream A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or removal of any Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. (1) The configuration information and Group_of_VideoObjectPlane() = SHALL be placed at the beginning of the RTP payload (just after the RTP = header) or just after the header of the syntactically upper layer function. (2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Two or more VOPs SHALL be fragmented into different RTP packets = so that one RTP packet consists of the data bytes associated with an = unique presentation time (that indicated to the timestamp field in the RTP packet header). (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted such that the resulting RTP packet is not larger than the path-MTU. Hear, header means: - Configuration information (Visual Object Sequence Header, Visual = Object Header and Visual Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the = definition of the configuration information and the entry point functions. The video packet starts with the VOP header or the video packet = header, followed by motion_shape_texture(), and ends with = next_resync_marker() or next_start_code). 3.3 Examples of packetized MPEG-4 Visual bitstream Considering that MPEG-4 Visual is used on a wide variety of networks = from several Kbps to many Mbps, from guarantied networks with almost = error- free to mobile networks with high error rate, it is not desired to = apply too much restriction on the fragmentation like a single video packet shall always be mapped on a single RTP packet. On the other hand, a careless media unaware fragmentation will cause degradation of the = error resiliency and the bandwidth efficiency. The fragmentation criteria described in 3.2 are flexible but to define the minimum rules to = prevent the meaningless fragmentation of e.g. splitting a header into = packets. For video coding media such as H.261 or MPEG-1/2, the additional = media specific RTP header works effectively for recovering e.g. a picture header corrupt by packet losses. However, there is an error = resilience functionality inside MPEG-4 Visual to recover corrupt headers. This functionality can commonly be used on RTP/IP network as well as other networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, there is no = strong reason to define MPEG-4 Visual specific extra RTP header fields. Figure 2 shows examples of RTP packets generated based on the = criteria described in 3.2 (a) is an example of the first RTP packet or the random access point = of an MPEG-4 visual bitstream. This RTP packet contains the = configuration information. According to the criterion (1), the Visual Object = Sequence Header(VS header) is placed at the beginning of the RTP payload, and = the Visual Object Header and the Visual Object Layer Header(VO header, = VOL header) follow it. Since the fragmentation rule defined in 3.2 = guaranties that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning = of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is an example the RTP packet that contains Group_of_VideoObjectPlane(GOV). Following the criterion (1), the GOV = is placed at the beginning of the RTP payload. It is a waste of RTP/IP header overhead to generate a RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be = placed in the same RTP packet as shown in (b). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D (c) is an example that one video packet is packetized into one RTP packet. When the packet-loss rate of the underlying network is high, = this kind of packetization is recommended. It is strongly recommended to = set resync_marker_disable to 0 in the VOL header to enable adjustment of = the video packet size. Even when the RTP packet containing the VOP header = is discarded by a packet loss, the other RTP packets can be decoded by = using the HEC(Header Extension Code) information in the video packet = header. No extra RTP header field is necessary. (d) is an example that more than one video packets are packetized = into one RTP packet. This kind of packetization is effective to save the overhead of RTP/IP headers if the bit-rate of the underlying network = is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The adequate number of video packets in a RTP packet and the RTP packet length depend the packet-loss rate and the bit-rate of the underlying network. Figure 3 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, like (a), will = not only increase the overhead of RTP/IP headers but also decrease the = error resiliency. Therefore, it is prohibited by the criterion (3). When concatenating more than one video packets into a RTP packet, VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization like (b) is not allowed by the = criterion (2). This is because of the error resiliency. Comparing this example = with Figure 2(c), two video packets are mapped onto two RTP packets in = both cases. However, there is a difference between the packet-loss = resiliency. When the second RTP packet is lost, both video packets 1 and 2 are = lost in the case of Figure 3(b) whereas only video packet 2 is lost in the case of Figure 2(c). A RTP packet containing more than one VOPs, like (c), is not allowed. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+-----+------------------+ (b) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (c) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (d) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ = +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video = Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) = | +------+------+----------+ = +------+---------+------+------------+ +------+------+------------------+------+------------------+ (c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane| |header|header| (1) |header| (2) | +------+------+------------------+------+------------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 4. RTP Packetization of MPEG-4 Audio bitstream When tools defined in MPEG-4 Systems are not used MPEG-4 Audio stream = is formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) format[5], and then mapped onto RTP packets as described the = subsequent section. 4.1 RTP Packet Format The LATM consists of the sequence of audioMuxElements that include = one or more audio frames. A complete audioMuxElement or the part of audioMuxElements SHALL be mapped directly onto the RTP payload = without removal of any audioMuxElement syntax elements as shown in Figure 4. = The first byte of each audioMuxElement SHALL be located at the first = payload location of an RTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number = |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp = |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | |RTP : audioMuxElement (byte aligned) = :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - An RTP packet for MPEG-4 Audio It is required for the audioMuxElement to indicate the following muxConfigPresent information by an out-of-band means. muxConfigPresent: If this information is set to 1, the = audioMuxElement SHALL include an indication bit "useSameStreamMux" and MAY include = the configuration information for audio compression "StreamMuxConfig". = The useSameStreamMux bit indicates whether the StreamMuxConfig element in = the previous frame is applied in the current frame. 4.2 RTP Header Fields Usage Payload Type (PT): Distinct payload type should be assigned to = specify MPEG-4 Audio RTP payload format. If the dynamic payload type = assignment is used, it is specified by some out-of-band means (e.g. H.245, SDP, Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D etc.) that the MPEG-4 Audio payload format is used for the = corresponding RTP packet. Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = This bit is set to one to mark the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. Timestamps are = recommended to start at a random value for security reasons. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default (90 kHz). Sequence Number: Increment by one for each RTP packet sent. It starts with a random value for security reasons. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is desirable to put one audioMuxElement per RTP packet. The size = of an audioMuxElement is tried to be adjusted such that the resulting RTP packet is not larger than the path-MTU. If this is not possible, the audioMuxElement MAY be fragmented across several packets based on the following rules. (1) "payloadMux" which consists of payload elements MAY be fragmented into several RTP packets so that one RTP packet consists of one or = more payload elements. A payload element SHOULD NOT be fragmented. (2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig SHALL be included into the RTP packet containing the first payload element. 5. RTCP Packetization of MPEG-4 upstream messages This section specifies the usage of particular RTCP packets to carry = the upstream messages generated using the MPEG-4 Audio/Visual upstream messaging functionalities, e.g. NEWPRED[4]. RTCP packets specified in this section SHALL ONLY be used when it is indicated by the profile = and level indication of MPEG-4 the codecs have such functionalities. = (e.g. Advanced Real Time Simple Visual Profile[4]) The MPEG-4 upstream messages are transmitted on particular RTCP = packets, like H.261 RTCP control packets [10]. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D In the case that the RTP session uses a multicast address, the MPEG-4 upstream message packets are not transmitted to the normal RTCP destination transport address. Instead, these upstream message = packets are sent directly via unicast from the decoder to the coder. The destination port number of these upstream message packets is always = same to the port number of the normal RTCP address. As a consequence, these upstream message packets may only be used = when no RTP mixers or translators intervene in the path from the coder to the decoder. If such intermediate systems do intervene, the address of = the coder would no longer be present as the network-level source address = in packets received by the decoder, and in fact, it might not be = possible for the decoder to send packets directly to the coder. Some reliable multicast protocols use similar NACK control packets transmitted over the normal multicast distribution channel, however = they typically use random delays to prevent a NACK implosion problem. The = goal of such protocols is to provide reliable multicast packet delivery at = the expense of delay, which is appropriate for applications such as a = shared whiteboard. On the other hand, real-time Audio/Visual transmission is more = sensitive to delay and does not require full reliability. For Audio/Visual applications it is more effective to send the MPEG-4 upstream message packets as soon as possible, i.e. as soon as a loss is detected, = without adding any random delays. 5.1. MPEG-4 Visual upstream message packets definition 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P| UMT | PT=3DRTCP_MP4UM | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | MPEG-4 Upstream Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets = as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP packet contains some = additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. In the case several upstream messages are mapped onto one RTCP packet, padding should only be required on the last individual message. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D upstream message type (UMT): 5 bits Identifies the type of the MPEG-4 upstream messages. 0: forbidden 1: MPEG-4 Visual NEWPRED 2-63: reserved In this internet-draft, only NEWPRED is assigned as the candidate = of the UMT for the moment. Some other MPEG-4 Audio/Visual = applications using the upstream messages may be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant RTCP_MP4UM (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of = this packet. MPEG-4 Upstream Message Payload: variable The syntax and semantics of the MPEG-4 upstream messages are = defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, and several messages with same UMT could be continuously mapped onto one = RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. 6. Security Considerations RTP packets using the payload format defined in this specification = are subject to the security considerations discussed in the RTP = specification [8]. This implies that confidentiality of the media streams is = achieved by encryption. Because the data compression used with this payload = format is applied end-to-end, encryption may be performed on the compressed = data so there is no conflict between the two operations. 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. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 2 ISO/IEC 14496-2:1999, "Information technology - Coding of = audio-visual objects - Part2: Visual", December 1999. 3 ISO/IEC 14496-3:1999, "Information technology - Coding of = audio-visual objects - Part3: Audio", December 1999. 4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999. 5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999. 6 ISO/IEC 14496-1:1999, "Information technology - Coding of = audio-visual objects - Part1: Systems", December 1999. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A = Transport Protocol for Real Time Applications", RFC 1889, Internet = Engineering Task Force, January 1996. 9 ISO/IEC 14496-2/DCOR1, October 1999. 10 T. Turletti, C. Hitema, "RTP Payload Format for H.261 Video = Streams", RFC 2032, Octover 1996. 8. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan Email: kiku@eel.rdc.toshiba.co.jp Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan Email: matsui@drl.mei.co.jp Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN Email: t-nomura@ccm.cl.nec.co.jp Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan Email: kimata@nttvdt.hil.ntt.co.jp =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into =0C ------=_NextPart_000_01CF_01BF6FFA.AC3C3FC0-- From rem-conf Sat Feb 05 13:55:34 2000 From rem-conf-request@es.net Sat Feb 05 13:55:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12HD4I-0000Bh-00; Sat, 5 Feb 2000 13:48:38 -0800 Received: from www.bun.ne.jp [210.225.192.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12HD4F-0000B8-00; Sat, 5 Feb 2000 13:48:35 -0800 Received: from dODaYXmT3 (98AA970A.ipt.aol.com [152.170.151.10]) by www.bun.ne.jp (8.8.5/8.8.5) with SMTP id GAA25346; Sun, 6 Feb 2000 06:46:45 +0900 (JST) From: ross66@sitek.net Message-Id: <200002052146.GAA25346@www.bun.ne.jp> DATE: 05 Feb 00 4:47:22 PM TO: jilly22@aol.com SUBJECT: UNIVERSITY DIPLOMAS FAST LIKE NOW! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-602-230-4252 Call 24 hours a day, 7 days a week, including Sundays and holidays. From rem-conf Sun Feb 06 15:32:56 2000 From rem-conf-request@es.net Sun Feb 06 15:32:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Hahu-0002O7-00; Sun, 6 Feb 2000 15:03:06 -0800 Received: from dyn149-ras3.froglike.co.uk (winbet systems) [212.49.226.149] by mail1.es.net with smtp (Exim 1.81 #2) id 12Haho-0002Nx-00; Sun, 6 Feb 2000 15:03:02 -0800 From: WIN-BET To: Message-Id: <419.436562.96295949winalot@winwin.co.uk> Subject: FREE,FOOTBALL FORECASTING TRIAL, HAVE FUN AND WIN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 6 Feb 2000 15:03:02 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Well you've come this far, you obviously want to win, go one more step and check out our website....... www.free2000.com/winbet apologies to those who tried to access the win-bet.co.uk site this has now been moved From rem-conf Tue Feb 08 03:44:19 2000 From rem-conf-request@es.net Tue Feb 08 03:44:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12I8rT-0003rM-00; Tue, 8 Feb 2000 03:31:15 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12I8rR-0003r1-00; Tue, 8 Feb 2000 03:31:13 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13434; Tue, 8 Feb 2000 06:31:02 -0500 (EST) Message-Id: <200002081131.GAA13434@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-text-04.txt Date: Tue, 08 Feb 2000 06:31:01 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-04.txt Pages : 9 Date : 07-Feb-00 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-text-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-text-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125401.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Feb 08 03:44:19 2000 From rem-conf-request@es.net Tue Feb 08 03:44:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12I8rb-0003rR-00; Tue, 8 Feb 2000 03:31:23 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12I8rR-0003r3-00; Tue, 8 Feb 2000 03:31:13 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13483; Tue, 8 Feb 2000 06:31:07 -0500 (EST) Message-Id: <200002081131.GAA13483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mpeg4-es-00.txt Date: Tue, 08 Feb 2000 06:31:07 -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 MPEG-4 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Matsui Filename : draft-ietf-avt-rtp-mpeg4-es-00.txt Pages : 13 Date : 07-Feb-00 This document describes RTP payload formats for the carriage of MPEG-4 Audio and Visual streams[2][3], and an RTCP format for MPEG-4 upstream messages functionalities[4]. In this specification, MPEG-4 Audio/Visual bitstreams are directly mapped into RTP packets without using MPEG-4 Systems[6]. The RTP header fields usage and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are specified. It also specifies an RTCP packet usage to carry the MPEG-4 upstream messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mpeg4-es-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125416.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Feb 08 11:00:37 2000 From rem-conf-request@es.net Tue Feb 08 11:00:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IFdK-0001lG-00; Tue, 8 Feb 2000 10:45:06 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 12IFdI-0001l6-00; Tue, 8 Feb 2000 10:45:04 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with SMTP id KAA00738; Tue, 8 Feb 2000 10:27:08 -0800 (PST) Message-Id: <3.0.3.32.20000208102716.00aa2820@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 08 Feb 2000 10:27:16 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 2/9 User Experiences with the Communications Revolution -- Charles H. House, Intel Dialogic Division Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gumby.CS.Berkeley.EDU id KAA00738 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar User Experiences with the Communications Revolution Wednesday February 9, 2000,=20 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall)=20 Charles H. House Intel Dialogic Division=20 After driving fifty miles down a long road in eastern China, and seeing s= ix vehicles in an hour, heading to a "town" of 4 million people with only three "Western" hotels, our driver=92s beeper beeped. He pulled it out of= his pocket, scanned the screen, and said, in perfect English, "ahh, Cisco, up= a =BD point". Not as compelling as the wireless phone call from the top of = Mt. Everest to his wife in New Zealand as the stricken climber died, but compelling enough for the van of travelers that the world of communicatio= ns has indeed changed.=20 What will be the impact of our new technologies - ever more complex and cheaper chips, wireless and glass-based wideband networks, and ubiquitous databases with XML cross-product "joins"? Everything from e-commerce to "virtual meetings" to new forms of company, community, and governance wil= l happen. The CITS group (Center for Information Technology and Society) at UCSB has been established to study these impacts from a wide perspective. Our speaker, who had a key role in founding the Center, will describe som= e of the inquiry that will be done there, and some of the major observation= s of where this work might be expected to lead. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Network= s G2 broadcast. You can connect to the live RealNetworks broadcast at: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm=20 You'll see a link to cs298-5/real networks/live programs. =20 You can also directly put in this url into the Real Player:=20 rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving t= he announcement you may be able to receive the session by manually configuri= ng the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center=20 From rem-conf Tue Feb 08 12:15:02 2000 From rem-conf-request@es.net Tue Feb 08 12:15:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IGmC-00036U-00; Tue, 8 Feb 2000 11:58:20 -0800 Received: from oberon.dnai.com [207.181.194.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 12IGmA-00035u-00; Tue, 8 Feb 2000 11:58:19 -0800 Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id LAA58918 for ; Tue, 8 Feb 2000 11:57:17 -0800 (PST) Received: from hariv (cheetah1 [216.15.52.38]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id LAA06180 for ; Tue, 8 Feb 2000 11:57:02 -0800 (PST) Message-ID: <00df01bf726f$48d7c5e0$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Audio Playout buffer Date: Tue, 8 Feb 2000 12:01:27 -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 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 Subject: Audio playout issues Hi, Can anyone guide me on Audio Playout algorithms. How much delay does the packet jitter Buffer contribute to the overall end to end delay? Assume that a fixed buffer is used containing of N-packets. Are the Adaptive playout schemes really implemented for VoIP? If so what kind of Speech codecs does it apply? Regards Hari From rem-conf Wed Feb 09 08:49:03 2000 From rem-conf-request@es.net Wed Feb 09 08:49:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IZxt-0004fZ-00; Wed, 9 Feb 2000 08:27:41 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12IZxt-0004fP-00; Wed, 9 Feb 2000 08:27:41 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA27203; Wed, 9 Feb 2000 11:23:13 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38A1946E.523D22D3@cs.columbia.edu> Date: Wed, 09 Feb 2000 11:23:10 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > The packetcable security spec specifies a 2 or 4 > byte MAC (using MMH) to be appended to the RTP Is this simply hash(RTP packet | shared secret)? Could the bad guy record a conversation, including the hash, and then mix in the old data with the "real" one? > packet itself. I have argued that RFC 2198 might > actually be a cleaner way to append the MAC > itself, but so long as the parties agree to the > payload format, a relatively weak MAC should make > barge in sufficiently difficult that even if an > attacker managed to get through every once in a > while, they probably wouldn't do anything > especially exciting. Since this is an RTP issue, I wonder if this shouldn't be written up for avt. Another possibility is an RTP header extension. That, at least, would be backward compatible with non-MMH implementations. > > > > > > So, what's stopping a haxor like me from strobbing a gateway with random > > > audio... ?? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Feb 09 09:24:57 2000 From rem-conf-request@es.net Wed Feb 09 09:24:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IabH-0005Q2-00; Wed, 9 Feb 2000 09:08:23 -0800 Received: from sj-mailhub-3.cisco.com [171.68.224.215] by mail1.es.net with esmtp (Exim 1.81 #2) id 12IabG-0005KB-00; Wed, 9 Feb 2000 09:08:22 -0800 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA25358; Wed, 9 Feb 2000 09:27:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26012; Wed, 9 Feb 2000 09:06:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14497.40587.553748.584990@thomasm-u1.cisco.com> Date: Wed, 9 Feb 2000 09:06:19 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations In-Reply-To: <38A1946E.523D22D3@cs.columbia.edu> References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> <38A1946E.523D22D3@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne writes: > Michael Thomas wrote: > > > > The packetcable security spec specifies a 2 or 4 > > byte MAC (using MMH) to be appended to the RTP > > Is this simply hash(RTP packet | shared secret)? Yes. In packetcable, the payload is encrypted with RC4, but the MAC is applied to the entire RTP packet. > Could the bad guy record a conversation, including the hash, and then > mix in the old data with the "real" one? Not if you use the RTP timestamp. Built in replay protection :-) > > packet itself. I have argued that RFC 2198 might > > actually be a cleaner way to append the MAC > > itself, but so long as the parties agree to the > > payload format, a relatively weak MAC should make > > barge in sufficiently difficult that even if an > > attacker managed to get through every once in a > > while, they probably wouldn't do anything > > especially exciting. > > Since this is an RTP issue, I wonder if this shouldn't be written up for > avt. Another possibility is an RTP header extension. That, at least, > would be backward compatible with non-MMH implementations. Whatever way has the least number of bytes is probably the right answer. Packetcable's only incurs the cost of the MAC itself since there is an agreement between the sender and receiver that there be the MAC tacked on to the end. Since it's a trailer, it ought not effect a naive implementation (though it would certainly violate the "conservative in what you send" principle). I do sort of like the idea of the MAC being a payload not entirely unlike a codec payload, though I'm not wedded to the notion. It does have the advantage that we can offer up the MAC "codec" up in SDP m= as being something that the endpoint is willing to receive. With RFC 2198, the sender would then oblige by sending several different "codecs", namely the real codec and the MAC at the same time. Mike From rem-conf Wed Feb 09 09:43:36 2000 From rem-conf-request@es.net Wed Feb 09 09:43:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Ib3X-0006HD-00; Wed, 9 Feb 2000 09:37:35 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Ib3W-0006H2-00; Wed, 9 Feb 2000 09:37:34 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA03407; Wed, 9 Feb 2000 12:27:24 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38A1A378.469B6FE1@cs.columbia.edu> Date: Wed, 09 Feb 2000 12:27:20 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> <38A1946E.523D22D3@cs.columbia.edu> <14497.40587.553748.584990@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > > Since this is an RTP issue, I wonder if this shouldn't be written up for > > avt. Another possibility is an RTP header extension. That, at least, > > would be backward compatible with non-MMH implementations. > > Whatever way has the least number of bytes is > probably the right answer. Packetcable's only > incurs the cost of the MAC itself since there is > an agreement between the sender and receiver that > there be the MAC tacked on to the end. Since it's > a trailer, it ought not effect a naive > implementation (though it would certainly violate > the "conservative in what you send" principle). Since RTP doesn't have a length field, a "naive" implementation would treat the MAC bytes as G.711 samples. Not good. > > I do sort of like the idea of the MAC being a > payload not entirely unlike a codec payload, > though I'm not wedded to the notion. It does have > the advantage that we can offer up the MAC "codec" > up in SDP m= as being something that the endpoint > is willing to receive. With RFC 2198, the sender > would then oblige by sending several different > "codecs", namely the real codec and the MAC at the > same time. My major concern with this is that there's a fair amount of overhead just to get 2 or 4 bytes across. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Feb 09 10:06:23 2000 From rem-conf-request@es.net Wed Feb 09 10:06:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IbTm-0007DQ-00; Wed, 9 Feb 2000 10:04:42 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12IbTl-0007DG-00; Wed, 9 Feb 2000 10:04:41 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Feb 2000 18:03:31 +0000 To: Henning Schulzrinne cc: Michael Thomas , 'SIP List' , rem-conf@es.net Subject: Re: Question about media desinations In-reply-to: Your message of "Wed, 09 Feb 2000 12:27:20 EST." <38A1A378.469B6FE1@cs.columbia.edu> Date: Wed, 09 Feb 2000 18:03:27 +0000 Message-ID: <4160.950119407@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >Michael Thomas wrote: >> I do sort of like the idea of the MAC being a >> payload not entirely unlike a codec payload, >> though I'm not wedded to the notion. It does have >> the advantage that we can offer up the MAC "codec" >> up in SDP m= as being something that the endpoint >> is willing to receive. With RFC 2198, the sender >> would then oblige by sending several different >> "codecs", namely the real codec and the MAC at the >> same time. > >My major concern with this is that there's a fair amount of overhead >just to get 2 or 4 bytes across. It's one more byte than using the RTP header extension..... Still, it may be better to define a new RTP profile which includes the MAC as part of the fixed RTP header. That's probably the solution with the least overhead, and the protocol definition can be straightforward RFC1890 + 4 bytes of MAC header. Colin From rem-conf Wed Feb 09 11:10:08 2000 From rem-conf-request@es.net Wed Feb 09 11:10:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12IcNH-0000ar-00; Wed, 9 Feb 2000 11:02:03 -0800 Received: from kickme.cisco.com [198.92.30.42] by mail1.es.net with esmtp (Exim 1.81 #2) id 12IcNF-0000ae-00; Wed, 9 Feb 2000 11:02:01 -0800 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA11764; Wed, 9 Feb 2000 10:50:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26055; Wed, 9 Feb 2000 11:00:03 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14497.47409.853886.712574@thomasm-u1.cisco.com> Date: Wed, 9 Feb 2000 11:00:01 -0800 (PST) To: Colin Perkins Cc: Henning Schulzrinne , Michael Thomas , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations In-Reply-To: <4160.950119407@cs.ucl.ac.uk> References: <38A1A378.469B6FE1@cs.columbia.edu> <4160.950119407@cs.ucl.ac.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins writes: > --> Henning Schulzrinne writes: > >Michael Thomas wrote: > >> I do sort of like the idea of the MAC being a > >> payload not entirely unlike a codec payload, > >> though I'm not wedded to the notion. It does have > >> the advantage that we can offer up the MAC "codec" > >> up in SDP m= as being something that the endpoint > >> is willing to receive. With RFC 2198, the sender > >> would then oblige by sending several different > >> "codecs", namely the real codec and the MAC at the > >> same time. > > > >My major concern with this is that there's a fair amount of overhead > >just to get 2 or 4 bytes across. > > It's one more byte than using the RTP header extension..... > > Still, it may be better to define a new RTP profile which includes the > MAC as part of the fixed RTP header. That's probably the solution with > the least overhead, and the protocol definition can be straightforward > RFC1890 + 4 bytes of MAC header. Would that not lead to a combinatorial explosion of name space with rtpmap in SDP? Ie, G711-MMH2, etc? I'm all for having zero overhead, but not at the expense of making a mess of SDP. That is sort of why I was attracted to RFC 2198. If somebody else has a better way of doing the same thing without requiring, for example, structured names in SDP that would be great too. Mike From rem-conf Wed Feb 09 11:29:17 2000 From rem-conf-request@es.net Wed Feb 09 11:29:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Iclp-0001Z0-00; Wed, 9 Feb 2000 11:27:25 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Iclo-0001Yp-00; Wed, 9 Feb 2000 11:27:24 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA15405; Wed, 9 Feb 2000 14:15:34 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38A1BCD2.C4CC7160@cs.columbia.edu> Date: Wed, 09 Feb 2000 14:15:30 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Colin Perkins , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <38A1A378.469B6FE1@cs.columbia.edu> <4160.950119407@cs.ucl.ac.uk> <14497.47409.853886.712574@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > Would that not lead to a combinatorial explosion > of name space with rtpmap in SDP? Ie, G711-MMH2, No, not really, this designation would replace the RTP/AVP in SDP with something like RTP/AVP-MMH. The codec names would stay the same, since they are unaffected by this change. . > etc? I'm all for having zero overhead, but not at > the expense of making a mess of SDP. That is sort > of why I was attracted to RFC 2198. If somebody > else has a better way of doing the same thing > without requiring, for example, structured names > in SDP that would be great too. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Feb 10 03:50:20 2000 From rem-conf-request@es.net Thu Feb 10 03:50:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Iryw-0002Wn-00; Thu, 10 Feb 2000 03:41:58 -0800 Received: from mailhub.cie-signaux.fr (oass09.cstelecom.cie-signaux.fr) [194.2.40.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Irys-0002Wd-00; Thu, 10 Feb 2000 03:41:54 -0800 Received: from hermes2.fty.cstelecom.com (hermes2.cstelecom.cie-signaux.fr [172.17.68.52]) by oass09.cstelecom.cie-signaux.fr with ESMTP id MAA27066 for ; Thu, 10 Feb 2000 12:39:28 +0100 (MET) From: Internet-Drafts@ietf.org Received: from gl17.fty.cstelecom.com ([172.17.68.34]) by hermes2.fty.cstelecom.com (Netscape Messaging Server 3.62) with ESMTP id 410; Thu, 10 Feb 2000 12:43:53 +0100 Received: from cc25.fty (cc25 [172.17.68.42]) by gl17.fty.cstelecom.com (8.8.8+Sun/jtpda-5.3) with SMTP id MAA17228 ; Thu, 10 Feb 2000 12:40:07 +0100 (MET) Received: by cc25.fty (SMI-8.6/SMI-SVR4) id MAA23462; Thu, 10 Feb 2000 12:40:07 +0100 Date: Thu, 10 Feb 2000 12:40:07 +0100 Message-Id: <200002101140.MAA23462@cc25.fty> Apparently-To: 06:31:01@ietf.org Apparently-To: 08@ietf.org Apparently-To: Date:@ietf.org Apparently-To: rem-conf@es.net Apparently-To: 200002081131.GAA13434@ietf.org Apparently-To: 06:31:02@ietf.org Apparently-To: all-ietf@loki.ietf.org Apparently-To: -0500@ietf.org Apparently-To: 06:45:01@ietf.org Apparently-To: 2000@ietf.org Apparently-To: Feb@ietf.org Apparently-To: 8@ietf.org Apparently-To: Tue@ietf.org Apparently-To: ietf-123-outbound.02@ietf.org; Apparently-To: for@ietf.org Apparently-To: a.burgain@CSTELECOM.COM Apparently-To: ;;@ietf.org Apparently-To: IETF-Announce:@ietf.org Bcc: To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-04.txt Pages : 9 Date : 07-Feb-00 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-text-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-text-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125401.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Feb 10 03:51:14 2000 From rem-conf-request@es.net Thu Feb 10 03:51:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Is36-0002Zn-00; Thu, 10 Feb 2000 03:46:16 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Is34-0002Zd-00; Thu, 10 Feb 2000 03:46:14 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18778; Thu, 10 Feb 2000 06:46:09 -0500 (EST) Message-Id: <200002101146.GAA18778@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-pointer-01.txt,.ps Date: Thu, 10 Feb 2000 06:46:08 -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 Real-Time Pointers Author(s) : M. Civanlar, G. Cash Filename : draft-ietf-avt-pointer-01.txt,.ps Pages : 5 Date : 09-Feb-00 This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalitiesp needed to implement a general mouse event transmission mechanism. This version of the draft includes MIME type registration information and a wording change in Section 2.2 for clarification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-pointer-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-pointer-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-pointer-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: <20000209152809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-pointer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-pointer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000209152809.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Feb 10 03:51:31 2000 From rem-conf-request@es.net Thu Feb 10 03:51:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Is3n-0002a7-00; Thu, 10 Feb 2000 03:46:59 -0800 Received: from mailhub.cie-signaux.fr (oass09.cstelecom.cie-signaux.fr) [194.2.40.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Is3k-0002Zx-00; Thu, 10 Feb 2000 03:46:58 -0800 Received: from hermes2.fty.cstelecom.com (hermes2.cstelecom.cie-signaux.fr [172.17.68.52]) by oass09.cstelecom.cie-signaux.fr with ESMTP id MAA27653 for ; Thu, 10 Feb 2000 12:44:37 +0100 (MET) From: Internet-Drafts@ietf.org Received: from gl17.fty.cstelecom.com ([172.17.68.34]) by hermes2.fty.cstelecom.com (Netscape Messaging Server 3.62) with ESMTP id 402; Thu, 10 Feb 2000 12:48:57 +0100 Received: from cc25.fty (cc25 [172.17.68.42]) by gl17.fty.cstelecom.com (8.8.8+Sun/jtpda-5.3) with SMTP id MAA17668 ; Thu, 10 Feb 2000 12:45:27 +0100 (MET) Received: by cc25.fty (SMI-8.6/SMI-SVR4) id MAA26531; Thu, 10 Feb 2000 12:45:27 +0100 Date: Thu, 10 Feb 2000 12:45:27 +0100 Message-Id: <200002101145.MAA26531@cc25.fty> Apparently-To: 08@ietf.org Apparently-To: Date:@ietf.org Apparently-To: rem-conf@es.net Apparently-To: 200002081131.GAA13483@ietf.org Apparently-To: 06:31:07@ietf.org Apparently-To: all-ietf@loki.ietf.org Apparently-To: -0500@ietf.org Apparently-To: 06:55:01@ietf.org Apparently-To: 2000@ietf.org Apparently-To: Feb@ietf.org Apparently-To: 8@ietf.org Apparently-To: Tue@ietf.org Apparently-To: ietf-123-outbound.02@ietf.org; Apparently-To: for@ietf.org Apparently-To: a.burgain@CSTELECOM.COM Apparently-To: ;;@ietf.org Apparently-To: IETF-Announce:@ietf.org Bcc: To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for MPEG-4 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Matsui Filename : draft-ietf-avt-rtp-mpeg4-es-00.txt Pages : 13 Date : 07-Feb-00 This document describes RTP payload formats for the carriage of MPEG-4 Audio and Visual streams[2][3], and an RTCP format for MPEG-4 upstream messages functionalities[4]. In this specification, MPEG-4 Audio/Visual bitstreams are directly mapped into RTP packets without using MPEG-4 Systems[6]. The RTP header fields usage and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are specified. It also specifies an RTCP packet usage to carry the MPEG-4 upstream messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mpeg4-es-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125416.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Feb 10 14:38:05 2000 From rem-conf-request@es.net Thu Feb 10 14:38:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12J21S-0003tL-00; Thu, 10 Feb 2000 14:25:14 -0800 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12J21Q-0003t6-00; Thu, 10 Feb 2000 14:25:12 -0800 Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id RAA03101 for ; Thu, 10 Feb 2000 17:25:44 -0500 (EST) Posted-Date: Thu, 10 Feb 2000 17:27:13 -0500 Message-Id: <10002102227.AA15166@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Thu, 10 Feb 00 17:27:14 EST To: rem-conf@es.net Subject: Multicast Seminar 2/18: Vernor Vinge - The Digital Gaia Reply-To: mankin@east.isi.edu Date: Thu, 10 Feb 2000 17:27:13 -0500 From: Allison Mankin X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vernor Vinge, "The Digital Gaia" NGI Distinguished Lecture - 18 February 2000, 1 PM EST In this talk, I assume that Moore's Law continues to be valid for another quarter century, and consider the consequences of that progress for VR/wearable computing, fine-grained distributed systems, collaborations, and central-site technology: How far can we take ubiquitous computing? What will our lives and work be like as we soar along this trajectory of hardware and software improvement? The DARPA NGI Program is proud to announce the start of a new series of live and telecast seminars on Next Generation Internet technologies. The first NGI Distinguished Lecturer will be the Hugo Award-winning science fiction author, Vernor Vinge. Numerous Internauts have said their imaginations were expanded by Vinge's works, including True Names (1981), often considered to be the introduction of the fictional concept of cyberspace (three years before William Gibson's Neuromancer), The Peace War (1984), and A Fire upon the Deep (1992). A Deepness in the Sky (1999) is the prequel to A Fire upon the Deep; both of these novels feature a richly imagined intergalactic email infrastructure. A collection entitled True Names And the Opening of the Cyberspace Frontier, reprinting the novella and including essays by Richard Stallman and Danny Hillis, among others, will appear in April 2000. Vinge is also an associate professor of computer science at San Diego State University, where his interests are in networks and distributed systems. Location: National Center for Supercomputing Applications ACCESS Facility: Ballston Metro Center Office Tower, Suite 800 901 North Stuart Street Arlington, Virginia 22203 Attendance: Space is limited. Please RSVP to ngi-seminar-rsvp@isi.edu. Directions for getting to the Access Facility can be found at: http://www.ncsa.uiuc.edu/VEG/homepages/tcoffin/ACCESS/directions.html Multicast/Webcast: The NGI Distinguished Lecture Series will be multicast live and also webcast using RealMedia. The live multicast will allow for questions and comments from the remote audience. To tune into the Internet multicasts, look for the announcement in your MBONE session directory program ('sdr'). If the announcement is not present there, it still may be possible to receive the session by manually configuring the client programs ('vic', and 'rat' or 'vat') with session addresses. The session addresses, webcast details, and information on non-live access to the seminar will be posted on: http://www.ngi-supernet.org/conferences.html During the seminar, any technical difficulties about the multicast can be addressed to dartnoc@isi.edu. NGI Distinguished Lecture Series Future Speakers: 23 March 2000 Kim Claffy, CAIDA (date tentative) Date TBA Vint Cerf, Interplanetary Internet From rem-conf Fri Feb 11 02:24:47 2000 From rem-conf-request@es.net Fri Feb 11 02:24:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12JDC5-0002sk-00; Fri, 11 Feb 2000 02:20:57 -0800 Received: from 07-121.028.popsite.net (bookstore) [216.126.181.121] by mail1.es.net with smtp (Exim 1.81 #2) id 12JDC1-0002sJ-00; Fri, 11 Feb 2000 02:20:54 -0800 From: jhbsojhskjm@nkfgbiahko.avimedia.de Subject: FREE Satellite T.V. System.. -mmjuxgs Date: Sat, 11 Dec 1999 02:21:46 -0800 Content-Type: text/plain; charset="iso-8859-1" Message-ID: To: routing@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE SATELLITE T.V. SYSTEM Watch over 500 channels of Digital Broadcast quality television on your own FREE satellite television system.These new Digital satellite systems use the new 18 inch satellite dish antenna. For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation! This is a top of the line system with features like on screen graphics, dual LNB, stereo receiver and infrared remote. All you have to do is call us to arrange delivery and order the channels you want to receive. The monthly cost of satellite television is usually much less than cable T.V and satellite television offers over 500 channels of all digital broadcast video quality and CD audio. You even get local channels now. Don't miss this offer…it's only available while supplies last. For your Free Satellite System call 626-568-0903 24 hours a day. From rem-conf Fri Feb 11 03:34:21 2000 From rem-conf-request@es.net Fri Feb 11 03:34:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12JEIp-00043O-00; Fri, 11 Feb 2000 03:31:59 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12JEIn-00043E-00; Fri, 11 Feb 2000 03:31:57 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03807; Fri, 11 Feb 2000 06:31:53 -0500 (EST) Message-Id: <200002111131.GAA03807@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-pointer-02.txt,.ps Date: Fri, 11 Feb 2000 06:31:53 -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 Real-Time Pointers Author(s) : G. Cash, M. Civanlar Filename : draft-ietf-avt-pointer-02.txt,.ps Pages : 5 Date : 10-Feb-00 This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-pointer-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-pointer-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-pointer-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: <20000210142715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-pointer-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-pointer-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000210142715.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Feb 11 13:43:27 2000 From rem-conf-request@es.net Fri Feb 11 13:43:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12JNlX-0002Sn-00; Fri, 11 Feb 2000 13:38:15 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 12JNlW-0002SP-00; Fri, 11 Feb 2000 13:38:14 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA03618; Fri, 11 Feb 2000 13:37:23 -0800 (PST) Date: Fri, 11 Feb 2000 13:40:17 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net, ITU-SG16@mailbag.cps.intel.com cc: Henning Schulzrinne Subject: URGENT question on draft-ietf-avt-tones-07 Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the IETF AVT working group and ITU SG16: --> Interested parties need to respond by end of day PST Monday 2/14 <-- The following has come up during IESG discussion of the draft-ietf-avt-tones-06.txt document: > In section 3.11 there are two events (CRd and MRd) where the signals > are different for the initiator and the responder. > This implies that the entity doing the translation between audio and events > need to be aware of the higher layer roles of the communicating peers. > Is this a reasonable assumption? This appears to be a valid concern that we did not realize in the working group review of this document. One would want the gateway that is doing the translation from an event to a tone to not be required to know the higher layer roles. It would be possible to give two different codepoints to each of these events. I don't know if there has already been enough implementation of this protocol that this would cause a problem, and the purpose of this message is to find out. Given that the modem and fax tones were added fairly late in the development of the draft, I suspect is would not be a problem to add two codepoints in that section (32-47) without changing the other sections. The author (Henning Schulzrinne) agreed: > This is at least ambiguous, particularly for a "pass-through" gateway > that's pretty clueless as to call state. There are effectively four tone > sequences > > 1375/2002 followed by 1150 > 1529/2225 followed by 1150 > 1357/2002 followed by 1900 > 1529/2225 followed by 1900 > > My suggestion would be to split the Crd and Mrd into Crdi and Crdr for > the initiating and responding side. Same for the other pair. The draft has been revised to make this split, so the codepoints 41-49 are now different. The revised draft has been submitted but is available in the meantime as: http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.txt http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.ps I believe that, subject to this change, the draft has been approved by the IESG. If there are no objections from the working group by the end of the day PST on Monday (2/14), then I will give our OK for the -07 draft be sent to the RFC editor. This is a very short response time, but our goal is to get the RFC number assigned before the end of the SG16 meeting on 2/18. To those at the SG16 meeting, please call this issue to the attention of interested parties that might not have seen this message. -- Steve Casner From rem-conf Mon Feb 14 13:25:03 2000 From rem-conf-request@es.net Mon Feb 14 13:25:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12KSg8-00075G-00; Mon, 14 Feb 2000 13:05:08 -0800 Received: from 209.124.92.6.92.124.209.in-addr.arpa (drivequest.com) [209.124.92.6] by mail1.es.net with smtp (Exim 1.81 #2) id 12KSg7-00073a-00; Mon, 14 Feb 2000 13:05:07 -0800 From: Subject: Drivers get security and free software at DriveQuest.com ADV Date: Mon, 14 Feb 2000 16:08:02 Message-Id: <360.440423.10568@drivequest.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

The 1st 10,000 new members receive a suite of software absolutely free. It
is worth hundreds of dollars and we are giving it away to introduce DriveQuest.com and Towbuster Autoclub. The software includes: virus scan and removal, a file shredder, resume, and text extraction for corrupt files. We will give it to you free just for trying Towbuster Autoclub. While other autoclubs like AAA charge you $56.00 per year for limited service, Towbuster costs only $34.95 for unlimited roadside service and towing! That's less than 10 cents a day!!!

You win both ways. You drive more securely with unlimited roadside assistance and towing and your hard drive will be more secure with our software. Cool huh?

Want to know more? Click here!

To be removed from our mailing list Click here

From rem-conf Mon Feb 14 20:01:05 2000 From rem-conf-request@es.net Mon Feb 14 20:01:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12KZ5W-00045f-00; Mon, 14 Feb 2000 19:55:46 -0800 Received: from hoemail1.lucent.com (hoemlsrv.firewall.lucent.com) [192.11.226.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 12KZ5U-00045V-00; Mon, 14 Feb 2000 19:55:45 -0800 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22880 for ; Mon, 14 Feb 2000 11:43:09 -0500 (EST) Received: from electric.amc.bell-labs.com (h135-17-7-254.lucent.com [135.17.7.254]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA22298 for ; Mon, 14 Feb 2000 11:42:33 -0500 (EST) Received: by electric.amc.bell-labs.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Feb 2000 11:34:19 -0500 Message-ID: From: "Chopra, Rajeev" To: "'rem-conf@es.net'" Cc: "Chopra, Rajeev" Subject: Request for information on Gateways supporting "ietf-avt-tones-06 .txt" Date: Mon, 14 Feb 2000 11:34:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am looking for some information on current Gateways supporting the "RTP payload tokens for DTMF Signaling" as specified in "ietf-avt-tones-06.txt". I need the following information a. Which all GWs out there currently support this spec, for use with G.729A encoding. b. GWs with plans to support this mechanism in near term (6-12 months) c. The spec proposes two ways of conveying DTMF signals and events i) Named signals ii) Tone representation Any information on whether GWs currently supporting the spec use I) or ii) or both ways. d. Does the GW strip the DTMF signals for the RTP stream, if it uses the proposed RTP token mechanism(s)? I know it is optional, as per the specs. I am working on incorporation of G.729A in a Media server, with the proposed RTP token mechanism for conveying the DTMF signaling and events. Any responses to above questions will be highly appreciated. Thanks Rajeev 732-949-9059 From rem-conf Tue Feb 15 03:40:57 2000 From rem-conf-request@es.net Tue Feb 15 03:40:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12KgEh-0000c6-00; Tue, 15 Feb 2000 03:33:43 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12KgEf-0000bw-00; Tue, 15 Feb 2000 03:33:41 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22135; Tue, 15 Feb 2000 06:33:40 -0500 (EST) Message-Id: <200002151133.GAA22135@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tones-07.txt,.ps Date: Tue, 15 Feb 2000 06:33:39 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-07.txt,.ps Pages : 29 Date : 14-Feb-00 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-tones-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-tones-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000214115122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000214115122.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Feb 15 19:26:08 2000 From rem-conf-request@es.net Tue Feb 15 19:26:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12KuqX-0002NN-00; Tue, 15 Feb 2000 19:09:45 -0800 Received: from mail1.wh.hb.cn (public.wh.hb.cn) [202.103.0.118] by mail1.es.net with esmtp (Exim 1.81 #2) id 12KuqV-0002MR-00; Tue, 15 Feb 2000 19:09:44 -0800 Received: from dhx60 ([202.103.31.80]) by public.wh.hb.cn (Sun Internet Mail Server sims.3.5.1999.07.30.00.05.p8) with SMTP id <0FQ000L9Q5X61P@public.wh.hb.cn> for rem-conf@es.net; Wed, 16 Feb 2000 11:05:31 +0800 (CST) Date: Wed, 16 Feb 2000 11:08:28 +0800 From: wmshen Subject: question on video transcoder or gateway To: rem-conf@es.net Message-id: <002b01bf782b$19953940$501f67ca@dhx60.telware> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 4.72.3110.5 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_hLiUvVG1KajeUGQ/7I4TRw)" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Priority: 3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_hLiUvVG1KajeUGQ/7I4TRw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hello, all experts, =20 I am a Ph.D student working on video communication. I am wondering about = how the video transcoder/gateway works between H.261 and H.263, and = between IP network and PSTN or ISDN, in paticular i wonder whether there = is a method by which bitstreams can be translated directly between H.261 = and H.263 format. =20 Who knows the technique details on above topics or where may i get some = useful reference infomation? =20 Any help will be approciated. =20 =20 Weiming Shen =20 --Boundary_(ID_hLiUvVG1KajeUGQ/7I4TRw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hello, = all=20 experts,
 
I am a = Ph.D student=20 working on video communication. I am wondering about how the video=20 transcoder/gateway works between H.261 and H.263, and between IP network = and=20 PSTN or ISDN, in paticular i wonder whether there is a method by which=20 bitstreams can be translated directly between H.261 and H.263=20 format.
 
Who = knows the=20 technique details on above topics or where may i get some useful = reference=20 infomation?
 
Any help = will be=20 approciated.
 
 
Weiming=20 Shen
 
--Boundary_(ID_hLiUvVG1KajeUGQ/7I4TRw)-- From rem-conf Wed Feb 16 02:15:42 2000 From rem-conf-request@es.net Wed Feb 16 02:15:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12L1OF-00062i-00; Wed, 16 Feb 2000 02:08:59 -0800 Received: from prue.eim.surrey.ac.uk [131.227.76.5] (exim) by mail1.es.net with esmtp (Exim 1.81 #2) id 12L1OD-00062Y-00; Wed, 16 Feb 2000 02:08:58 -0800 Received: from zebedee.ee.surrey.ac.uk ([131.227.87.19] ident=ees3as) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12L1Ne-0002fS-00; Wed, 16 Feb 2000 10:08:22 +0000 Date: Wed, 16 Feb 2000 10:08:21 +0000 (GMT) From: Abdul Sadka To: wmshen cc: rem-conf@es.net Subject: Re: question on video transcoder or gateway In-Reply-To: <002b01bf782b$19953940$501f67ca@dhx60.telware> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Video transcoding between two DCT-based compression algorithms consists of syntactical mapping of output video parameters from one bitstream to another. For the case of ITU-T H.261 and H.263, the layering structure and the syntax are very similar except for few differences in half-pixel accuracy and motion compensation that make the parameter-mapping a bit more complicated. For instance, H.261 uses one MV predictor to compensate for motion in the current MB as opposed to 3 MV predictors in H.263 whereby one median predictor in both x and y dimensions is considered for motion compensation. This will induce certain complications in the associated video transcoding algorithm. However, the main focus in heterogeneous video transcoding today is on how to map the output bitstreams of 2 video coders which have completely different layering structures and syntactical properties. For example, it is not very straightforward to transcode from MPEG-4 to H.263 since MPEG-4 employs the arbitrary shape VOP structure as opposed to the full picture MB-Grid in H.263. To achieve this mapping, you will need to map the VOP defined in MPEG-4 onto its precise location in the picture area of H.263 and extrapolate the pixels that are off the contour of the VOP but inside the tightest box that encloses the arbirary shape object. Perhaps, to have an introductory step into the area, you could refer to the following publication: S. Dogan, A. H. Sadka, A.M. Kondoz "Efficient MPEG-4/H.263 Video Transcoder for Interoperability of Heterogeneous Multimedia Networks" IEE Electronic Letters, Vol. 35, No. 11, pp 863-864, 27th May 1999. Regards. _________________________________________ Dr Abdul H. Sadka (Lecturer) | Multimedia Communications Research Group | Centre for Communication Systems Research| Uni. of Surrey, GU2 5XH, Surrey, England | Tel: +44 (01483) 259490 | Fax: +44 (01483) 259504 | WWW: www.ee.surrey.ac.uk/Personal/A.Sadka| _________________________________________| On Wed, 16 Feb 2000, wmshen wrote: > Hello, all experts, > > I am a Ph.D student working on video communication. I am wondering about how the video transcoder/gateway works between H.261 and H.263, and between IP network and PSTN or ISDN, in paticular i wonder whether there is a method by which bitstreams can be translated directly between H.261 and H.263 format. > > Who knows the technique details on above topics or where may i get some useful reference infomation? > > Any help will be approciated. > > > Weiming Shen > > From rem-conf Wed Feb 16 08:12:32 2000 From rem-conf-request@es.net Wed Feb 16 08:12:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12L6x1-0001f1-00; Wed, 16 Feb 2000 08:05:15 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12L6x0-0001dl-00; Wed, 16 Feb 2000 08:05:14 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Feb 2000 16:05:08 +0000 To: rem-conf@es.net Subject: RTP interoperability testing Date: Wed, 16 Feb 2000 16:05:06 +0000 Message-ID: <3141.950717106@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group, As noted in the AVT meeting at the Washington DC IETF, it is necessary to collect interoperability reports for RTP implementations before we can progress the RTP specification and audio/video profile to draft standard. Two internet-drafts describe the type of interoperability statement required: draft-ietf-avt-rtp-interop-02.txt draft-ietf-avt-profile-interop-00.txt and a third draft (draft-ietf-avt-rtptest-02.txt) describes possible testing strategies. This message is a plea for vendors with RTP implementations to make available results of their interoperability tests, in order that we can advance the specifications. Results of the tests to date are available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/RTPinterop/ Please send additions to this table to me (if you have a problem with making this information publically available, please contact me privately and we can arrange alternatives). Note that we cannot advance the revised RTP specification or audio/video profile to become RFCs unless this information is received. Your help in compiling the interoperability statements is vital. Thanks, Colin From rem-conf Wed Feb 16 08:12:33 2000 From rem-conf-request@es.net Wed Feb 16 08:12:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12L6xi-0001fc-00; Wed, 16 Feb 2000 08:05:58 -0800 Received: from lumumba.luc.ac.be [193.190.9.252] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 12L6xh-0001fK-00; Wed, 16 Feb 2000 08:05:57 -0800 Received: (qmail 32345 invoked from network); 16 Feb 2000 16:05:08 -0000 Received: from lumumba.luc.ac.be (jori@193.190.9.252) by lumumba.luc.ac.be with SMTP; 16 Feb 2000 16:05:08 -0000 Date: Wed, 16 Feb 2000 17:05:08 +0100 (CET) From: Jori To: rem-conf@es.net Subject: JRTPLIB v2.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello everybody, I just wanted to say a couple of things - for those of you who have already downloaded jrtplib (version 2.1 or 2.2). It contained a bug in rtpsourcedata.cpp. You can download the corrected file at http://lumumba.luc.ac.be/jori/rtp/rtp.html - About JRTPLIB: It's an object-oriented RTP library, written in C++. It has been known to work on Linux, Solaris and Windows platforms. However, it should also work on other unix-like platforms... The download site is the same as above... Bye, Jori From rem-conf Wed Feb 16 14:58:54 2000 From rem-conf-request@es.net Wed Feb 16 14:58:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LDGd-0006L7-00; Wed, 16 Feb 2000 14:49:55 -0800 Received: from (mail.cps.com.tw) [203.75.205.62] by mail1.es.net with esmtp (Exim 1.81 #2) id 12LDGb-0006KY-00; Wed, 16 Feb 2000 14:49:53 -0800 Received: from 7qX3nKg9U ([171.220.147.64]) by mail.cps.com.tw (Netscape Messaging Server 3.62) with SMTP id 565; Thu, 17 Feb 2000 06:45:23 +0800 DATE: 16 Feb 00 5:57:15 PM FROM: JILL@mecom.net TO: Sally@aol.com SUBJECT: **NEED A DEGREE FAST LIKE TODAY** Message-ID: <20000216222002234.ABF142.565@7qX3nKg9U> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 713-866-6501 Call 24 hours a day, 7 days a week, including Sundays and holidays. From rem-conf Thu Feb 17 03:39:07 2000 From rem-conf-request@es.net Thu Feb 17 03:39:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LP5X-0005Th-00; Thu, 17 Feb 2000 03:27:15 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12LP5T-0005TX-00; Thu, 17 Feb 2000 03:27:12 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08994; Thu, 17 Feb 2000 06:27:09 -0500 (EST) Message-Id: <200002171127.GAA08994@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-08.txt Date: Thu, 17 Feb 2000 06:27:09 -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 : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-08.txt Pages : 37 Date : 16-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-08.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: <20000216123048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000216123048.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Feb 17 08:58:03 2000 From rem-conf-request@es.net Thu Feb 17 08:58:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LU7p-0001HB-00; Thu, 17 Feb 2000 08:49:57 -0800 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 12LU7n-0001GT-00; Thu, 17 Feb 2000 08:49:56 -0800 X-Internal-ID: 38A968D800022713 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Thu, 17 Feb 2000 17:48:05 +0100 X-Internal-ID: 38A959B500026E59 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Thu, 17 Feb 2000 17:43:45 +0100 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Thu, 17 Feb 2000 17:43:44 +0100 (Paris, Madrid) X-Internal-ID: 385F71DE000186E7 Received: from minos.snmrennes.thomcast.thomson-csf.com (178.3.1.10) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Thu, 17 Feb 2000 17:52:18 +0100 Received: from artic ([178.3.1.211]) by minos.snmrennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.62) with SMTP id 465 for ; Thu, 17 Feb 2000 17:42:41 +0100 From: "Ludovic Havet" To: Subject: info on MPEG2 packet audio/video player ? Date: Thu, 17 Feb 2000 17:47:43 +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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I work on RTP with MPEG2 and search a way to visualize an MPEG2 packet audio/video (or elementary) program. In this view I search a PC based board or an STB. Also it would be great to have an API to feed the board and to decide where and how to get the result. If you have any information / offer... Thanks in advance for your kind help, Ludovic Havet From rem-conf Thu Feb 17 12:58:27 2000 From rem-conf-request@es.net Thu Feb 17 12:58:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LXtu-0004Jy-00; Thu, 17 Feb 2000 12:51:50 -0800 Received: from mail5.microsoft.com [131.107.3.121] by mail1.es.net with smtp (Exim 1.81 #2) id 12LXtt-0004IR-00; Thu, 17 Feb 2000 12:51:49 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Feb 2000 12:00:59 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Thu, 17 Feb 2000 12:00:59 -0800 Message-ID: <5B3F16B2DB67D1119A0D00805F312AA2179C187E@RED-MSG-58> From: Gary Sullivan To: 'Baldine Paul' , cabo@tzi.org, lscline@jf.intel.com, thomas.r.gardos@intel.com, Gary Sullivan , stewe@cs.tu-berlin.de Cc: rem-conf@es.net Subject: RE: H.263 RFC 2429 Date: Thu, 17 Feb 2000 12:00:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7981.B493782E" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7981.B493782E Content-Type: text/plain; charset="ISO-8859-1" To Baldine Paul re RFC 2429, Just came across this old question -- I don't know why I didn't see it earlier. Section 5.1.1 was meant to say that UFEP could be 1 in the redundant header copy even if it was 0 in the payload stream. Whether you actually do that or not was intentionally left up to the implementer. For example, nothing is ever changing in the entire stream for hours on end, it is probably safe to not send full headers. Best Wishes, Gary Sullivan -----Original Message----- From: Baldine Paul [mailto:baldine@research.att.com] Sent: Friday, October 22, 1999 1:42 PM To: cabo@tzi.org; lscline@jf.intel.com; thomas.r.gardos@intel.com; Gary Sullivan; stewe@cs.tu-berlin.de Cc: rem-conf@es.net Subject: H.263 RFC 2429 I have a comment regarding the packetization scheme described in Section 5.1.2 of the RFC. It specifies that a redundant copy of the picture header may be attached to the RTP header for packets that begin with GBSC or SSC. What is not obvious is whether that redundant picture header is full length (with UFEP=001) or not. Although, it could be left to the implementer to decide whether to include a complete picture header or not, I suggest, to be consistent with the recommendation of Section 5.1.1, that all redundant picture headers(for packets beginning with a Picture Start Code, a GBSC, a SSC or even a Follow-on packet), be complete, with UFEP=001. Baldine-Brunel Paul AT&T Labs-Research Room 3-225, 100 Schultz Drive Red Bank, NJ 07701 phone: 732-345-3312 baldine@research.att.com http://www.research.att.com/info/baldine ------_=_NextPart_001_01BF7981.B493782E Content-Type: text/html; charset="ISO-8859-1"
To Baldine Paul re RFC 2429,
 
Just came across this old question -- I don't know why I didn't see it earlier.
 
Section 5.1.1 was meant to say that UFEP could be 1 in the redundant header copy
even if it was 0 in the payload stream.  Whether you actually do that or not was
intentionally left up to the implementer.  For example, nothing is ever changing in
the entire stream for hours on end, it is probably safe to not send full headers.
 
Best Wishes,
 
Gary Sullivan
 
 
-----Original Message-----
From: Baldine Paul [mailto:baldine@research.att.com]
Sent: Friday, October 22, 1999 1:42 PM
To: cabo@tzi.org; lscline@jf.intel.com; thomas.r.gardos@intel.com; Gary Sullivan; stewe@cs.tu-berlin.de
Cc: rem-conf@es.net
Subject: H.263 RFC 2429

I have a comment regarding the packetization scheme described in
Section 5.1.2 of the RFC. It specifies that a redundant copy of the picture
header may be attached to the RTP header for packets that begin with GBSC or SSC.
What is not obvious is whether that redundant picture header is full length (with UFEP=001) or
not.
Although, it could be left to the implementer to decide whether to include a complete picture
header or not, I suggest, to be consistent with the recommendation of Section 5.1.1, that
all redundant picture headers(for packets beginning with a Picture Start Code,
a GBSC, a SSC or even a Follow-on packet), be complete, with UFEP=001.
 
Baldine-Brunel Paul
AT&T Labs-Research
Room 3-225, 100 Schultz Drive
Red Bank, NJ 07701
phone: 732-345-3312
baldine@research.att.com
http://www.research.att.com/info/baldine
 
------_=_NextPart_001_01BF7981.B493782E-- From rem-conf Thu Feb 17 20:26:27 2000 From rem-conf-request@es.net Thu Feb 17 20:26:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LeuQ-00019r-00; Thu, 17 Feb 2000 20:20:50 -0800 Received: from westga.edu [160.10.4.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12LeuP-00019h-00; Thu, 17 Feb 2000 20:20:49 -0800 Received: from sun (localhost [127.0.0.1]) by westga.edu (8.9.2/8.9.2/TSS-usg.m4_1.17-x[29Jan1999]) with SMTP id XAA24055 for ; Thu, 17 Feb 2000 23:20:31 -0500 (EST) MIME-Version: 1.0 Reply-To: mclay@westga.edu Date: Thu, 17 Feb 2000 23:20:31 -0500 From: "Matthew Clay" Message-Id: <950847631.mailspinnerdV3.2.5.3@localhost> To: rem-conf@es.net Subject: EnVision X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone have experience using EnVision Desktop Video Conferencing? Matthew Clay, Director Education Technology Services College of Education State University of West Georgia From rem-conf Fri Feb 18 03:44:32 2000 From rem-conf-request@es.net Fri Feb 18 03:44:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Llfz-00072C-00; Fri, 18 Feb 2000 03:34:23 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Llfy-000722-00; Fri, 18 Feb 2000 03:34:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19849; Fri, 18 Feb 2000 06:34:15 -0500 (EST) Message-Id: <200002181134.GAA19849@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-text-05.txt Date: Fri, 18 Feb 2000 06:34:15 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-05.txt Pages : 9 Date : 17-Feb-00 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-text-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-text-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000217093612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-text-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000217093612.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Feb 18 09:52:09 2000 From rem-conf-request@es.net Fri Feb 18 09:52:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Lr5c-0004ao-00; Fri, 18 Feb 2000 09:21:12 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Lr5b-0004ae-00; Fri, 18 Feb 2000 09:21:11 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27526; Fri, 18 Feb 2000 12:21:04 -0500 (EST) Message-Id: <200002181721.MAA27526@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload for Text Conversation to Proposed Standard Date: Fri, 18 Feb 2000 12:21:03 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'RTP Payload for Text Conversation' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document defines a way to carry low-rate text in RTP packets, in accordance with ITU-T Recommendation T.140. The payload format provides for non-duplicated, in-order delivery, with loss detection and optional limited loss recovery via redundancy. Working Group Summary The initial draft was revised as a result of input from the working group and there is good working group consensus for publishing the document. Protocol Quality Vern Paxson reviewed the the spec for the IESG. Note to RFC Editor: The IESG requests that the Revision History section at the end of the document be removed prior to publication as an RFC. From rem-conf Fri Feb 18 11:15:20 2000 From rem-conf-request@es.net Fri Feb 18 11:15:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LsnK-0006da-00; Fri, 18 Feb 2000 11:10:26 -0800 Received: from viewgraphics.viewgraphics.com (viewgraphics.com) [205.178.119.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 12LsnJ-0006dQ-00; Fri, 18 Feb 2000 11:10:25 -0800 Received: from viewgraphics.com (pc-wei.viewgraphics.com [205.178.119.53]) by viewgraphics.com (8.8.8+Sun/Viewgraphics-SM.cf) with ESMTP id LAA20050; Fri, 18 Feb 2000 11:15:49 -0800 (PST) Message-ID: <38AD9A53.1C64A416@viewgraphics.com> Date: Fri, 18 Feb 2000 11:15:31 -0800 From: Wei Li X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ludovic Havet CC: rem-conf@es.net Subject: Re: info on MPEG2 packet audio/video player ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Ludovic, Viewgraphics Inc. makes PCI boards which can perform MPEG2 ASI input/output >from a standard PC with NT4.0 or Windows 2000. There exists an SDK as well with which you gain full access of the card. The system mainly works with transport stream and seems to fit your application. For more information, please take a look at: http://www.viewgraphics.com. Under Products, look for "MediaPump XL with MediaSplice". --Wei ------------------------------------------------ Wei Li Viewgraphics Inc. 1340 Space Park Way Mountain View, CA 94043 Tel: 650-903-4900(main) 650-903-1481 (direct) Fax:650-969-6388 E-mail: wei@viewgraphics.com Web: www.viewgraphics.com ------------------------------------------------ Ludovic Havet wrote: > Hello, > > I work on RTP with MPEG2 and search a way to visualize an MPEG2 packet > audio/video (or elementary) program. In this view I search a PC based board > or an STB. Also it would be great to have an API to feed the board and to > decide where and how to get the result. > > If you have any information / offer... > > Thanks in advance for your kind help, > > Ludovic Havet From rem-conf Fri Feb 18 14:41:10 2000 From rem-conf-request@es.net Fri Feb 18 14:41:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12LvvA-0002oY-00; Fri, 18 Feb 2000 14:30:44 -0800 Received: from (cqu.edu.cn) [202.202.0.33] by mail1.es.net with smtp (Exim 1.81 #2) id 12Lvuu-0002nT-00; Fri, 18 Feb 2000 14:30:31 -0800 Received: from 202.202.0.33 by cqu.edu.cn (SMI-8.6/SMI-SVR4) id EAA08748; Sat, 19 Feb 2000 04:27:20 +0800 From: cabletvinfo@flashmail.com Message-Id: <200002182027.EAA08748@cqu.edu.cn> Received: from cabletvinfo@flashmail.com by cabletvinfo@flashmail.com (8.8.5/8.6.5) with SMTP id GAA01764 for ; Fri, 18 Feb 2000 10:01:59 -0600 (EST) Date: Fri, 18 Feb 00 10:01:59 EST To: cabletvinfo@flashmail.com Subject: CABLE TV X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- LEGAL CABLE TV DE-SCRAMBLER Want to watch Sporting Events?--Movies?--Pay-Per-View?? You can assemble from electronic store parts for about $12.00. We Send You: E-Z To follow Assembly Instructions. E-Z To read Original Drawings. Electronic parts lists. PLUS SOMETHING NEW YOU MUST HAVE! Something you can't do without. THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY Warning: You should not build a TV Descrambler without reading this report first. Frequently Asked Questions--CABLE TV DESCRAMBLER Q: Will the descrambler work on Fiber, TCI, Jarrod A: The answer is YES. Q: Do I need a converter box? A: This plan works with or without a converter box. Specific instructions are included in the plans for each! Q: Can the cable company detect that I have the descrambler? A: No, the signal descrambles right at the box and does not move back through the line! Q: Do I have to alter my existing cable system, television or VCR? A: The answer is no! Q: Does this work with my remote control? A: The answer is yes. The descrambler is manually controlled--but very easy to use! Q: Can you email me the plans? A: No the program comes with an easy to follow picture guide. Q: Does this work everywhere across the country? A: Yes, every where in the USA plus England, Brazil, Canada and other countries! Q: Is this deal guaranteed? A: Yes, if you are unhappy for any reason we will refund your money. Q: When I order, when will I get my stuff? A: We mail out all orders within 48 hours of receiving them. ORDER INFORMATION ACT WITHIN THE NEXT 14 DAYS AND RECEIVE TWO FREE BONUS!! THE CABLE MANUAL! This manual contains hard to find information your cable company does not want you to know. Also receive The RADAR JAMMER PLANS! Never get another speeding ticket. Build you own radar jammer, this unit will jam police radar so they can't get a reading on your vechicle. Radar jammers are legal in 48 states. It is simple to build. The FREE BONUSES ALONE ARE WORTH ACTING NOW! THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE ONLY FREE CABLE TV TO GAIN! ACT NOW! SIMPLY SEND $14.00 CHECK OR, MONEY ORDER, OR CREDIT CARD INFORMATION TO: HELPFUL HINTS PO BOX 31202 DES MOINES, IA 50310 FOR CREDIT CARD ORDERS FILL OUT THIS FORM AND MAIL IN, ATTENTION HELPFUL HINTS, here is my credit card information for the amount of $14.00 for the cable descrambler kit. ACCOUNT NUMBER____________________________________ EXP. DATE____________________ NAME_____________________________________________ BILLING ADDRESS__________________________________________ CITY/STATE/ZIP_____________________________________ HOME PHONE__________________________________ THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of new millenium! If you would like to be removed release@dcemail.com From rem-conf Sat Feb 19 12:05:16 2000 From rem-conf-request@es.net Sat Feb 19 12:05:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12MFuO-0001Wd-00; Sat, 19 Feb 2000 11:51:16 -0800 Received: from (ashley5.net) [199.1.88.149] by mail1.es.net with smtp (Exim 1.81 #2) id 12MFuN-0001W7-00; Sat, 19 Feb 2000 11:51:15 -0800 From: yrtptc44@officina.net To: rem-conf@es.net Subject: Your Platinum Free Vacation and Airline Tickets!! Date: Sat, 19 Feb 2000 14:59:51 -0500 X-Sender: yrtptc44@officina.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Platinum Travel Club Would Like To Offer You A Complimentary Vacation Of A Lifetime And Two Free Airline Tickets. Please click on http://www.platinumtravelclub.com or if you can not click on the link please simply visit our website at www.platinumtravelclub.com for Details Of How To Receive This Now. Please understand that this is a one time offer and Platinum Club will not resend this offer to you again. If you do not respond and you have received this message in error we apologize for the inconvenience and we would like to confirm that you will not receive this offer or any other offer from us again. Thank You. Code P.F.C.C.52598 From rem-conf Sun Feb 20 21:39:01 2000 From rem-conf-request@es.net Sun Feb 20 21:39:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12MlIv-0004Aw-00; Sun, 20 Feb 2000 21:22:41 -0800 Received: from (unicid.br) [200.212.140.174] by mail1.es.net with esmtp (Exim 1.81 #2) id 12MlIt-0004Aj-00; Sun, 20 Feb 2000 21:22:39 -0800 Received: from B5RX8R9xH by unicid.br (8.8.8+Sun/SMI-SVR4) id CAA14250; Mon, 21 Feb 2000 02:16:01 -0300 (EST) From: hIY0wQF37@mail.esshelp.com DATE: 20 Feb 00 11:11:57 PM Message-ID: <2y7on83OXmBqI78l> SUBJECT: Re: It's Not Too Late!!! sasfd Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IT IS NOT TOO LATE!!!! You can still get the "updated" Seven Steps to the "New" You -- How To Create A New Identity program!!! We have no control over how long we will be able to sell this on the Internet !!! You may never again get the opportunity to "get connected" with what we have to show you !!! Get this new and powerful information before everyone is using it !!! ==> INCREDIBLE "FREE BONUS", SEE BELOW <== "Seven Steps to the New You" -- How To Create A New Identity It's true, in as little as just seven days you can have a new name, credit file, social security number, picture ID, and be able to apply for any major credit card !!! Give yourself the benefits of a fresh NEW start in life with just seven steps in seven days. Does this sound too good to be real? Continue reading. FACT FROM FICTION => The picture ID you can get is NOT a fake ID, it is a valid state ID like any other photo ID. => The credit cards you can get are NOT fake or require any deposits, they are valid just like any other. => There is no laws against having two identities. => This information is for REAL and should be taken seriously. Think you've seen this offer before? Think again, new U.S. laws AND the Freedom Of The Press, now allows us to reveal these secret loopholes previously available to only a select few in the U.S. ACT NOW and get this INCREDIBLE BONUS absolutely FREE... The Second Chance Credit Manual - How to get all the credit you want and deserve! If you have bad credit and you want to fix it, then this is for you! => 100% Legal => 100% Effective => 100% Guaranteed The very latest guide to creating a new credit file with a brand new number. Full details guide you every step of the way, and explain exactly what you are doing and why. DON'T WAIT YEARS for negative items to come off your credit report. All you need to know is spelled out in clear, detailed directions. WHAT ARE PEOPLE SAYING ABOUT THIS OFFER? (Copied word-for-word from the customer's letter.) "You people are crazy exposing this kinda info to the public, but thanks guys, your program really saved me!" -- A. Randazzo, NY "A new ID, yeah right, but I was desperate so I took a chance and ordered your steps program. I gotta say that I got more than my money's worth from this deal." -- T.C. Perez, TX "It's the best $50 bucks I ever spent. I would have paid five times that for what your new you packet allowed me to do!!!" -- K. Waterbury, CA Have you heard enough? Are you now ready to accept the great life and opportunities that a new identity can provide? We want everyone who truly needs this to be able to have it. If you're serious about changing your life, you MUST ACT NOW!!! As we've stated above, we will most likely be forced to stop distributing this information very soon. ==> INCREDIBLE "FREE BONUS", SEE BELOW <== Don't loose your opportunity for a second chance, get your confidential identity package and Second Chance Credit Manual NOW, before it's too late!!! We've sold this package for $50 before, but only to our personal contacts. From this week, up until we are forced to stop offering this info, we will be selling our Seven Steps To The New You Program for only $29.95 (USD) Payment Options: [ ] Cash [ ] Money Order [ ] Amex Travelers Cheque [ ] Check -- mailed or faxed -- Fax check to: 1-212-504-0866 We guarantee that your order will be priority processed so that you can have this package within 24 hours!!! (**For emailed orderfulfillment.) Send your order to: N. I., LLC 705 Martens Court, PMB 8-345 Laredo, TX 78041-6010 = = => ORDER FORM STARTS HERE <= = = Product Code: TE Description: "Seven Steps to the New You" + FREE BONUS Second Chance Credit Manual - How to get all the credit you want and deserve! Total amount: $29.95 Today's Date:_______________ Name:___________________________________ Address:__________________________________ City, State, Zip:________________________________________ Your Email Address:____________________________________ (** Required if you want an email formatted copy sent to you.) ==================================================== New Program - How To Get A Visa/MasterCard with NO CREDIT CHECK. Plus - How To Get An Instant $4000 Credit Line With "NO" Credit Check. You won't believe how EASY this is and it's Yours FREE if your order is postmarked "before" 02/29/00. ==================================================== DISCLAIMER: The seller of this information WILL NOT be held legally responsible for what the purchaser might choose to use this information. From rem-conf Sun Feb 20 22:06:24 2000 From rem-conf-request@es.net Sun Feb 20 22:06:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Mlq3-00059n-00; Sun, 20 Feb 2000 21:56:55 -0800 Received: from ppp7-mulhouse.libertysurf.fr (Nina) [213.36.41.7] by mail1.es.net with smtp (Exim 1.81 #2) id 12Mlq0-00059T-00; Sun, 20 Feb 2000 21:56:54 -0800 From: EZ To: Message-Id: <419.436577.29695486freemp3@altavista.com> Subject: EZ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 20 Feb 2000 21:56:54 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi The Women of MP3, dedicated to promoting the advancement and achievements of women in the music industry. From folk to alternative, hip-hop to metal, and everything in between, you will find exceptional women artists, women-fronted and all-girl bands spotlighted weekly. So show your support, and visit often! English http://artists.mp3s.com/artists/45/ez.html Français http://francemp3.com/music/artistes.asp?N=48 Enjoy EZ From rem-conf Mon Feb 21 05:21:46 2000 From rem-conf-request@es.net Mon Feb 21 05:21:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12MsgN-0002UD-00; Mon, 21 Feb 2000 05:15:23 -0800 Received: from 60-225.pop.fl.mi.verio.com (server3) [209.69.60.225] by mail1.es.net with smtp (Exim 1.81 #2) id 12MsgI-0002QT-00; Mon, 21 Feb 2000 05:15:18 -0800 To: You@yourdomain2.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Date: Mon, 21 Feb 2000 08:15:16 -0500 Subject: Low Price Dental Message-Id: X-Mailer: Eudora 3.06 From: saveondental@AllThePlanet.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SIGN UP TODAY AND SAVE!! Low Price Dental and Optical plan Hello, We work with a group of your local doctors and dentists and are offering a Dental - Optical Plan that runs approximately $3 a week for an individual and $4 a week for the entire family with no limit to the number of children. Would you like our office to furnish you with the details? Call Toll-Free 1-800-422-3057 "Refer to the K600 offer." *If your state is listed below then we currently do not service your area. ************************************************* We are linked to plenty of web sites that offer free subscriptions to our mailing list. You may JOIN or LEAVE this list at any time by following the simple instructions that can be found at the end of this email. You are on our mailing list because you have subscribed at one of our associate web sites, sent us email or we have a previous online relationship. If you would like to be unsubscribe, then please click on reply and make sure you put unsubscribe in the subject field to be sure to be removed.. then click send. Marketing Service Co. Customer Service Department *Not available for Alaska Washington D.C. Hawaii Maine Montana New Hampshire Rhode Island South Dakota Vermont Washington Wyoming california From rem-conf Mon Feb 21 05:32:17 2000 From rem-conf-request@es.net Mon Feb 21 05:32:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12MstD-0003G5-00; Mon, 21 Feb 2000 05:28:39 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12MstB-0003Ft-00; Mon, 21 Feb 2000 05:28:37 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06050; Mon, 21 Feb 2000 08:28:31 -0500 (EST) Message-Id: <200002211328.IAA06050@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals to Proposed Standard Date: Mon, 21 Feb 2000 08:28:31 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document defines how to carry both particular telephony control tones and general multi-frequency tones in RTP packets. Tones are explicitly encoded so that (1) they can be reproduced without loss of quality even by low-rate codecs, and (2) their meaning can be unambiguously determined. Working Group Summary There's been solid working group consensus for the payload format for some time. Discussion focussed on which events in particular to add, and how to represent the set of supported events in SDP and in a MIME registration. Protocol Quality The document was reviewed for the IESG by Vern Paxson. From rem-conf Tue Feb 22 06:28:39 2000 From rem-conf-request@es.net Tue Feb 22 06:28:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NG1s-0003XD-00; Tue, 22 Feb 2000 06:11:08 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12NG1r-0003Wx-00; Tue, 22 Feb 2000 06:11:07 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Feb 2000 14:10:52 +0000 To: rem-conf@es.net Subject: AVT agenda for Adelaide Date: Tue, 22 Feb 2000 14:10:51 +0000 Message-ID: <6089.951228651@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The AVT working group has requested two slots at the IETF meeting in Adelaide, and have been allocated 15:30-17:30 on Wednesday 29th March and 13:00-15:00 on Thursday 30th March on the draft agenda. Anyone wanting to time to discuss their work at the meeting should contact me and Steve, and we'll arrange the agenda. Colin From rem-conf Wed Feb 23 00:58:15 2000 From rem-conf-request@es.net Wed Feb 23 00:58:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NXW4-0001al-00; Wed, 23 Feb 2000 00:51:28 -0800 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 12NXW2-0001aa-00; Wed, 23 Feb 2000 00:51:26 -0800 Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA04768 for ; Wed, 23 Feb 2000 00:51:26 -0800 (PST) Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id AAA04310; Wed, 23 Feb 2000 00:51:25 -0800 (PST) Message-Id: <200002230851.AAA04310@rum.isi.edu> To: rem-conf@es.net Date: Tue, 04 Jan 2000 16:37:03 -0800 From: Joe Touch Reply-To: sigcomm2000-info@acm.org Organization: Sigcomm 2000 MIME-Version: 1.0 Subject: reminder - Sigcomm 2000 tutorial deadline approaching X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The tutorial deadline for Sigcomm 2000 is Feb. 28, 2000. Please see the website below for further information on how to submit a proposal. --------------------------------------------------------------- Call for Papers ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org >> Tutorial proposals: February 28, 2000 The SIGCOMM 2000 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. Proposals for tutorials, information on student paper award eligibility and procedures, and nominations for the SIGCOMM Award are also sought at this time. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu, or sigcomm2000-info@acm.org) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) From rem-conf Wed Feb 23 07:17:25 2000 From rem-conf-request@es.net Wed Feb 23 07:17:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NdLE-0006IZ-00; Wed, 23 Feb 2000 07:04:40 -0800 Received: from horse.mail.ru [194.67.23.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 12NdLD-0006IJ-00; Wed, 23 Feb 2000 07:04:39 -0800 Received: from f1.int ([10.0.0.48] helo=f1.mail.ru) by horse.mail.ru with esmtp (Exim 3.02 #116) id 12NdLi-000IOg-00 for rem-conf@es.net; Wed, 23 Feb 2000 18:05:10 +0300 Received: from mail by f1.mail.ru with local (Exim 3.02 #107) id 12NYJM-000Oeg-00 for rem-conf@es.net; Wed, 23 Feb 2000 12:42:24 +0300 Received: from [144.206.171.7] by win.mail.ru with HTTP; Wed, 23 Feb 2000 09:42:24 +0000 (GMT) From: "LMM IIT" To: rem-conf@es.net Subject: invitation Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [144.206.171.7] Reply-To: "LMM IIT" Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Date: Wed, 23 Feb 2000 12:42:24 +0300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Invitation to Participate in a Research Project to Develop the Key Encoding Module under the MPEG-4 Video Coding Standard The new content-oriented video coding standard MPEG-4 adopted in 1999 specifies formats for coding and combining video objects present in video sequences. MPEG-4 is expected to open the way for advanced 21-century digital video coding. This standard, however, does not specify the mechanism or the procedure for locating (segmenting) such objects in a video sequence based on their motion and/or color. This is a subject of active research in many laboratories worldwide. The problem of spatiotemporal segmentation of video sequences is a priority subject in the Semantic Segmentation research project started at the end of 1997 and conducted by the Laboratory of Mathematical Methods, Institute of Information Technologies, Russian Research Center, Kurchatov Institute, Moscow. This project was supported by SAIT (Samsung Advances Institute of Technology), Korea. This Laboratory has been doing work in the field of computer vision for two decades. Its researchers have fulfilled a number of projects in theoretical and applied computer vision, medical and industrial diagnostics, automatic form entry and processing, and target detection and recognition. Working on the Semantic Segmentation project, our computer vision group has been able to find conclusive solutions to several important problems inherent in trying to decompose a video sequence into individual objects. We believe that we have correctly formulated the problems that need be tackled to come closer to extracting video objects from natural video sequences (like sports or drama). The purpose of this invitation is to get additional financial support that will make it possible to expand the team of researchers working on the project and to obtain the results in a shorter period. With the additional financial support of about $100,000 over a period of 1.5 to 2 years, we would be able to address and solve most of essential problems in spatiotemporal object segmentation and develop workable technologies for general purpose video sequences. On your request, we would be ready to provide additional information including Demos on the work done at the previous stages of the Semantic Segmentation project and a detailed technical proposal for the future research. A.P. Aleksandrov, Director of the Institute of Information Technologies. lmmiit@mail.ru From rem-conf Wed Feb 23 07:52:21 2000 From rem-conf-request@es.net Wed Feb 23 07:52:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Ne1o-0007RO-00; Wed, 23 Feb 2000 07:48:40 -0800 Received: from goliath.siemens.de [194.138.37.131] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Ne1N-0007Qu-00; Wed, 23 Feb 2000 07:48:28 -0800 X-Envelope-Sender-Is: Martin.Euchner@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id QAA29264 for ; Wed, 23 Feb 2000 16:48:07 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id QAA09645; Wed, 23 Feb 2000 16:48:07 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2448.0) id <1Z9BG0KN>; Wed, 23 Feb 2000 16:48:08 +0100 Message-ID: From: Euchner Martin To: rem-conf@es.net, Euchner Martin Subject: proposal for RTP header authentication method / anti-spamming Date: Wed, 23 Feb 2000 16:48:01 +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 Dear experts, the following contribution attached below proposes an RTP header authentication method to protect against denial-of-service attacks using RTP packet flooding on discovered UDP/RTP ports. First, some background information may be helpful for the reader's understanding in general in addition to the contribution: - I am the editor in ITU-T Study Group 16 of draft recommendation H.235 version 2, that deals with "Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals". - Basically, H.235 describes the framework for security in H.323 based multimedia systems. It offers a variety of security services such as authentication, access control, integrity, confidentiality, non-repudiation with digital signatures and integrated key-management with security capability negotiation for the secured call signaling and secure media transport over RTP. H.235v2 features also interoperable security profiles for various purposes and scenarios. - H.235 basically offers two methods for protection of the RTP media streams: - network layer security using IPSEC, - or application-level security where the RTP media payload data is encrypted. This is the preferred method that is currently of major interest. Several encryption algorithms could be applied, among them are DES, Triple-DES and RC2. Note, that ITU-T SG16 currently does not see necessities to integrity protect the RTP media stream, this is an issue left for further study, once there would be a requirement. - As the most recent successful and severe denial-of-service attacks on major ISPs and Internet services shows, sophisticated attacking tools are already available in the hacker community. Such attacking tools could simply be misused (with none or slight modifications perhaps) also against the RTP protocol and thus thwarting any system that uses the RTP protocol including H.323 Voice-over-IP systems. - While approved recommendation H.235v1 does not provide explicit countermeasures against denial-of-service attacks, it is recognized that H.235v2 should provide a simple, light-weight security means that is sufficiently effective without the necessity to integrity-protect complete media packet for performance reasons. The proposed light-weight security improvement for RTP interworks both works with H.235 encrypted media streams but also simply with unencrypted RTP payload data. H.235v2 cares for the necessary key-management with automatic, integrated session key-distribution, key update/synchronization and security capability negotiation using H.245 open logical channel signaling means. H.235 allows also manual key-management with statically configured keys. RTP does not define any key-management and defines key-management tasks as by "non-RTP means". Thus, our proposal nicely fits already in the current RTP approach and concept. - At the most recent ITU-T Study Group 16 meeting in Geneva, CH, 7-18 February 2000; the attached contribution D.335 was accepted for H.235v2. However, it was pointed out by some delegates, that the IETF AVT working group currently discusses a revised version of the RTP protocol. As the fundamental problem is more related to RTP than H.323, we feel, that it would be wise to solve the problem on an RTP level and provide the solution to other RTP applications as well. Thus, we see good opportunities to discuss our ideas with you and that we hopefully could come to an agreement of a common procedure. - Our workplan in ITU-T SG16 is as follows: H.235v2 has recently been determined. The final version of the draft is scheduled for approval/decision in November 2000. Our next Rapporteurs meeting will be held in May. We see good chances to come to a resolution of these common matters until then. - The idea that is described in the proposal, cryptographically protects the changing portion of the RTP header (i.e. timestamp and sequence number) with a message digest. The result is put into the modified RTP padding fields in the end of the RTP packet. This should be backwards compatible with existing implementations. The message digest could be computed using encryption techniques (DES-MAC) or using a secure hash algorithm (SHA-1). These algorithms are not part of D.335 and have been recently added to the draft of H.235v2. The receiver could verify the authenticity of the packet and drop it if the digest is not correct. This operation consumes only low effort and saves any significant processing effort or resources of the application on top of RTP that would occur otherwise. - Another option could be to deploy the RTP header extension method. It is not clear, whether this had significant benefits and how that exactly would work. - At present the enhanced RTP protocol format is still very flexible; the length of the AUTH and padlen fields are not fully fixed since H.235 can negotiate these parameters using H.245. When the protocol extension became part of RTP, some further considerations should be given on defining appropriate packet formats of course. - The contribution is the ASCII-converted delayed contribution D.335 with some minor modifications. I've decided to have the H.245 and H.235 stuff still included for better understanding of the entire procedures even the RTP issues in the current draft would likely not be affected by this. Those of you who are interested in the original Word97 version of the document, may obtain it on request of course. I am looking forward to hearing your comments, opinions and questions on this. With kind regards, Martin Euchner. Here is the proposal: TITLE: RTP anti-spamming method in H.235v2 ____________________________________________ This contribution describes a security enhancement to H.235v2 to counter denial-of service attacks on UDP/RTP ports when sending spam media packets against the recipient. The described improvement will increase the security and reliability of H.323 Voice-over-IP-systems. 1. Introduction Current H.323 and H.235 based multimedia systems do not provide explicit means against denial-of-service attacks when flooding discovered RTP/UDP media ports with spam packets. This is of concern in mission-critical VoIP systems that require high availability and have to resist basic attacks. Some simple, lightweight security means are necessary to counter the flooding attack on a discovered UDP port. As a result of a successful attack, the end system (terminal, gateway, MCU,...) may no longer provide its service or function appropriately due to caused overload situation while considerably wasting resources (processing, memory,..). Such an attack using IP-masquerading techniques is basically possible on any H.323 system, regardless of whether H.235 media (voice/video) encryption is implemented or not. While firewalls usually cannot counter this kind of attack once the UDP ports have been connected through, the countermeasure could be implemented in the end-system. For an attacker listening to the media port negotiation (H.245 or H.225.0), the denial-of service attack is quite easy to perform. The attacker either sends arbitrary media packets with meaningful RTP header information or even replays intercepted RTP media packets on the discovered port. The attacker may even probe the destination ports without listening to a signaling connection. Present H.235 does not provide adequate security means to protect against such threats. While media integrity in general would provide means to detect such denial-of-service attacks too, the required countermeasures are usually quite CPU-cycle intensive as the entire media packet would have to be cryptographically integrity protected. Actually, media integrity would not only counter any content manipulation of the data in transit but also provide the media anti-spamming as a side effect. However, as the need for true media integrity is not obvious at the moment, section H.235/B.3 lists integrity and replay protection of the RTP stream as for further study. We provide an appropriate, yet simple lightweight countermeasure, which is suitable for H.323 systems both with and without implemented media encryption. Thus, the security can be enhanced step-by-step. The basic idea is to utilize the end-to-end secret that can be negotiated by means of H.235 anyway and apply it cryptographically to a short, non-constant portion of the RTP packet and compute some digest upon; actually this is a cryptographic message authentication code. Rapid checking of the digest allows the receiver to filter out unauthorized packets from unknown sources before spending any further considerable resources processing the malicious packet. This shall thwart the denial-of-service attacks of RTP packet flooding. We therefore call this security mechanism the "media anti spamming method". The cryptographic digest may be computed using a symmetric crypto algorithm such as DES or SHA1. 2. Proposal We propose to use the new media anti-spamming method as an option in H.235v2 (summarized in a new subsection 11.2 of H.235v2) and adopt the following modifications to H.245 as well. It is proposed to use the DES algorithm for the digest computation; SHA1 may be used as an alternative when the system does not offer media encryption. 2.1. H.245 modifications: {this subsection is provided just for your information, it is subject to H.245 and H.235} The capability of a terminal to support anti-spamming is signaled in H.245 as follows. The anti-spaming capability is thus subject to negotiation as well: EncryptionAuthenticationAndIntegrity offers AuthenticationCapability, which is extended as follows for media anti-spamming: Enhancements to H.245 ANNEX A: AuthenticationCapability ::=SEQUENCE { nonStandard NonStandardParameter OPTIONAL, ... antiSpamAlgorithm OBJECT IDENTIFIER OPTIONAL } Enhancements to H.245 Annex B.2.2.8 (Encryption, Authentication and Integrity Capabilities) EncryptionCapabilities, if present, indicate the encryption capabilities of a terminal for each media type where the capabilities are present. The scope of encryption indicates whether the encryption is applied to the entire bit stream, a portion of the bit stream in a standard way, or a portion of the stream in a non standard way. The algorithm selects the encryption algorithm. AuthenticationCapabilities if present, indicate that the authentication components of H.235 [16] are supported by the terminal. antiSpamAlgorithm indicates the method and algorithm how to provide countermeasures against flooding and denial-of-service attacks. 2.2. H.235 additions H.235v2 provides a new subsection "11.2 Media anti-spamming" with the following content: The receiver of an RTP media stream may wish to counter denial-of-service and flooding attacks on discovered RTP/UDP ports. Receivers, when having implemented the anti-spam capability, can quickly determine whether an obtained RTP packet stems from an unauthorized source and discard it. The anti-spamming capability when set indicates use of the anti-spamming mechanism either - for plaintext media data without media encryption (see case 1 below) or - in combination with encrypted media data when EncryptionCapability features an encryption algorithm (see case 2 below). Both options provide a lightweight RTP packet authentication on selected fields through a computed message authentication code (MAC). The MAC may be computed using an encryption algorithm (e.g. DES in MAC mode, see ISO/IEC 9797) or using a cryptographic one-way function (e.g. SHA1). The MAC algorithm is indicated in the object identifier of antiSpamAlgorithm. The algorithm OID implicitly indicates also the size of the MAC; e.g. 1 block = 64 bits for DES MAC. In order to save bandwidth, the MAC could be truncated albeit sacrificing some security; e.g., to a 32-bit MAC; this requires a different object identifier then. The anti-spam method is independent of any additional payload encryption (see cases 1 and 2 below). Anti-spamming uses the following RTP packet format (see Figure 1) where the RTP padding sequence is interpreted as follows (see H.225.0 Annex A.5). - The P bit in the RTP header shall be set to 1. - Padding bytes shall be appended at the end of the payload with the following meaning: <------------------------------- RTP packet -----------------------------------------------> <-- RTP Header --> <-RTP payload-> <-- RTP padding --> +----------+------+-----------+------+---------------+---------------+------ --------+--------+ |... P ... | SEQ# | timestamp | .... | media payload | padding bytes | AUTH | padlen | +----------+------+-----------+------+---------------+---------------+------ --------+--------+ \____ e.g. 64 bits ___/ \__ possibly encrypted __/ \e.g.64 bits / \1 byte/ ^ | MAC_k(...SEQ#,timestamp) ----------------------------------------+ Figure 1: General RTP packet format for media anti-spamming Note: If anti-spamming is not used, then the AUTH and padlen fields are not used either and the usual RTP packet format applies. 1. Case anti-spamming-only: This case applies when the media data are not encrypted; see Figure 2. The last octet of the RTP padding contains a count of how many padding octets should be ignored at the end of the RTP packet. The other padding bytes carry the MAC; see Figure 3. The MAC shall be computed over the first crypto block of the RTP header including the varying timestamp and sequence number using the negotiated MAC algorithm of antiSpamAlgorithm and applying the symmetric secret. A static or manually configured shared secret or a dynamically negotiated shared secret may be used according to the procedures of H.235. For larger block sizes (more than 64 bits), some sufficient additional bits of the RTP header or even the first media payload shall be taken. As key for the MAC computation, it is recommended to use the key that is obtained from the H.235 media session key distribution; although the session key applied is not used for payload encryption. Secure fast connect with key establishment (see H.323 Annex J) or manual keying may be used for key management. The sender computes the MAC as described above and includes the result in the MAC field in the RTP padding AUTH field. Sender and receiver know the size of the AUTH field and the length of the MAC by the antiSpamAlgorithm. The MAC verification at the receiver side should be done as early as possible, if possible already within the RTP stack or at latest before decryption or decompressing the payload. The receiver first recomputes the MAC in the same way as the sender did and compares the computed MAC with the delivered MAC in the RTP padding. If the MACs mismatch, the RTP header has been modified in transit or was sent by an unauthorized entity that does not possess the key. Thus, the mis-authenticated RTP packet shall be discarded, the event may be logged; this likely indicates an attempted denial-of-service attack. Otherwise, the authenticated RTP packet can be processed further, the RTP padding is removed and the payload is fed through the codec. Note: The lightweight MAC computation/verification with DES encryption involves only a single encryption operation; alternatively, SHA1 MAC is computed on a short part of the packets of fixed length, thus the crypto operations consume absolutely minimal processing resources. <------------------------------- RTP packet --------------------------------> <-- RTP Header --> <-RTP payload-> <-- RTP padding --> +----------+------+-----------+------+---------------+---------------+------ --+ |... P ... | SEQ# | timestamp | .... | media payload | MAC | padlen | +----------+------+-----------+------+---------------+---------------+------ --+ \___ e.g. 64 bits ___/ \e.g.64 bits / \1 byte/ ^ | MAC_k(...SEQ#,timestamp) -------------------------+ Figure 2: RTP packet format for media anti-spamming without encryption <----- RTP padding -----------> +------------------+------------+ | MAC | padlen | +------------------+------------+ \_ e.g. 64 bits _/ \_ 1 byte _/ Figure 3: RTP padding for anti-spamming-only 2. Case anti-spam method and payload encryption: This case applies when the media data are encrypted and the anti-spamming method is invoked; see Figure 4. When the payload does not fall on even block boundaries, some additional padding bytes have to be appended to the payload in front of the MAC. The media payload encryption is according to chapter 11/H.235. <------------------------------- RTP packet -----------------------------------------------> <-- RTP Header --> <-RTP payload-> <-- RTP padding --> +----------+------+-----------+------+---------------+---------------+------ --------+--------+ |... P ... | SEQ# | timestamp | .... | media payload | padding bytes | AUTH | padlen | +----------+------+-----------+------+---------------+---------------+------ --------+--------+ \____ e.g. 64 bits ___/ \_ encrypted in CBC mode __/ \e.g.64 bits / \1 byte/ ^ | MAC_k(...SEQ#,timestamp) ----------------------------------------+ Figure 4: RTP padding for anti-spamming with payload encryption EncryptionCapability defines the payload encryption algorithm while antiSpamAlgorithm defines the anti-spamming method. For security reasons, the media encryption and the MAC shall use different session keys. The MAC key k is computed by feeding the encryption key K through the SHA1 one-way hash function; k = SHA1(K); sufficient bits shall be taken from the hashed result in network byte order. When antiSpamAlgorithm indicates an encryption algorithm, then the collected bits shall be made a correct encryption key; e.g. setting DES parity bits. After the receiver successfully verified the authenticity of the RTP packet, the payload is decrypted and then the RTP padding be discarded. The general procedure is according to case 1 above. 3. References - Draft H.235v2: Security and Encryption for H-series (H.323 and other H.245-based) Multimedia Terminals - Draft H.323 Annex J: Security for H.323 Annex F - H.245v7: Control Protocol for Multimedia Communication - ISO/IEC 9797: Data cryptographic techniques - Data integrity mechanism using a cryptographic check function employing an n-bit algorithm with truncation. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- From rem-conf Wed Feb 23 11:41:59 2000 From rem-conf-request@es.net Wed Feb 23 11:41:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NhZb-0003S7-00; Wed, 23 Feb 2000 11:35:47 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 12NhZa-0003Rx-00; Wed, 23 Feb 2000 11:35:46 -0800 Received: from BMRC.Berkeley.EDU (opus.CS.Berkeley.EDU [128.32.131.116]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id LAA04691 for ; Wed, 23 Feb 2000 11:35:46 -0800 (PST) Message-ID: <38B43691.188D0986@BMRC.Berkeley.EDU> Date: Wed, 23 Feb 2000 11:35:45 -0800 From: "Lawrence A. Rowe" Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf Subject: "The Future of Interactive Television is Internet Webcasting" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi - I gave a talk on monday at the U of Illinois, Urbana-Champaign that folks on this list might be interested in seeing. I've included the title and abstract below with a link to the archive that you can replay (Windows Media Player). Comments appreciated. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry --- "The Future of Interactive Television is Internet Webcasting" (archived at http://www.cs.uiuc.edu/dls/rowe/rowe.html) Lawrence A. Rowe Computer Science Division - EECS University of California at Berkeley Traditional broadcast television programs are composed of one video stream with no interaction, fixed image size, and constrained picture quality. The development of media distribution networks such as Broadcast.com and Real Broadcast Networks and single-source multicast protocols suggests that Internet Webcasting will be yet another distribution channel for television programming with the same constraints imposed by current television distribution technologies (e.g., wireless, satellite, and cable). Internet Webcasting, on the other hand, can support multiple video streams, interaction between participants, and variable quality streams. In spite of these technical capabilities, most webcasts today are produced using traditional television technologies and are constrained to the limitations imposed by that technology. This talk describes research on developing computer-based webcasting technology that exploits capabilities of this new medium including broadcast management, video-effects processing, and live production control. The principle application is distance/asynchronous learning, but the technology applies to many more applications including distributed collaboration and entertainment. From rem-conf Thu Feb 24 00:35:16 2000 From rem-conf-request@es.net Thu Feb 24 00:35:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NtYz-000579-00; Thu, 24 Feb 2000 00:23:57 -0800 Received: from (ami4000.hei.co.kr) [202.30.128.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 12NtYx-000554-00; Thu, 24 Feb 2000 00:23:55 -0800 Received: from aaa ([166.125.29.59]) by ami4000.hei.co.kr (8.9.3/8.9.3) with SMTP id RAA24034; Thu, 24 Feb 2000 17:19:15 +0900 (KST) Message-ID: <025901bf7e9f$dbb2ef20$3b1d7da6@hei.co.kr> From: "Nam Kyu Kim" To: "Jonathan Rosenberg" Cc: References: <388480A9.50636D98@dynamicsoft.com> <200001181626.IAA29242@windsor.research.att.com> <38849B62.CA372ADB@dynamicsoft.com> <200001181724.JAA29905@windsor.research.att.com> <3884B6E6.76E311F2@dynamicsoft.com> <200001181914.LAA00776@windsor.research.att.com> <3884C503.FAEB6A54@dynamicsoft.com> Subject: Re: rtp time stamp in RTCP packet.... Date: Thu, 24 Feb 2000 17:18:50 +0900 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SGVsbG8gZXZlcnlvbmUuLg0KDQpJIGhhdmUganVzdCBzdWJzY3JpYmVkIHJlbS1jb25mIGUtbWFp bCByZWZsZWN0b3IuDQpBbmQgSSBoYXZlIHJlY2VpdmVkIGFuIG9sZCBpbnRlcmVzdGluZyBlLW1h aWxzIG9uIHRpbWVzdGFtcCBpbiBSVFAgYW5kIFJUQ1ANCmZyb20gbXkgZmVsbG93cy4NCg0KSXQg bWF5IGJlIGFuIG91dC1vZi1kYXRlIGNvbW1lbnRzLCBidXQgaW4gbXkgb3Bpbmlvbg0KdGhlcmUg aXMgYSBkaWZmZXJlbnQgcG9pbnQgYmV0d2VlbiB0aW1lc3RhbXAgaW4gUlRQIGFuZCB0aW1lc3Rh bXAgaW4gUlRDUC4NClJUUCB0aW1lc3RhbXAgZm9sbG93IHNhbXBsaW5nIGluc3RhbnQgaW4gYWNj b3JkYW5jZSB3aXRoIGNsb2NrIGZyZXF1ZW5jeSANCmJ1dCBSVENQIHRpbWVzdGFtcCBmb2xsb3cg c2FtcGxpbmcgaW5zdGFudCBpbiBhY2NvcmRhbmNlIHdpdGggTlRQIG5vdCBjbG9jayBmcmVxdWVu Y3kuDQpBbmQgUlRDUCB0aW1lc3RhbXAgdW5pdHMgbXVzdCBiZSB0cmFuc2xhdGVkIGZyb20gTlRQ IHVuaXRzIGludG8gUlRQIHRpbWVzdGFtcCB1bml0cywNCmJlY2F1c2UgaXQgdXNlcyB1bml0cyBv ZiBSVFAgdGltZXN0YW1wLiBBbmQgYWNjb3JkaW5nIHRvIHRoZSBSRkMxODg5LCB0aGF0IGNhbiBi ZSBpbXBsZW1lbnRlZCANCmJ5IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIE5UUCB0aW1lc3RhbXAgYW5k IFJUUCB0aW1lc3RhbXAgbWFpbnRhaW5lZCBieSBwZXJpb2RpY2FsbHkgY2hlY2tpbmcgDQp0aGUg d2FsbGNsb2NrIHRpbWUgYXQgYSBzYW1wbGlnIGluc3RhbnQuDQoNCldoYXQgSSB3YW50IHRvIHNh eSBpcyB0aGF0IFJUQ1AgdGltZXN0YW1wIHJlZmxlY3RzIHRoZSBpbnN0YW50IHRpbWUgaW4gc2Vu ZGluZyBTUiANCm5vdCBhZGphY2VudCBSVFAgZGF0YSB0aW1lc3RhbXAuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOYW0gS3l1IEtpbSANClIg JiBEIFRlYW0gOQ0KTW9iaWxlIFRlbGVjb21tdW5pY2F0aW9uIFRlcm1pbmFsIERpdmlzaW9uDQpI WVVOREFJIEVMRUNUUk9OSUNTIElORFVTVFJJRVMgQ28uLCBMdGQuDQoNClRFTCA6ICg4Mi0yKTU4 MC01NTExICAgICAgIEZBWCA6ICg4Mi0yKTU4MC01NDg3DQpIb21lIDogKDgyLTIpMjI4Mi0zMDc3 ICAgQy5QLiA6IDAxNy0yMTEtMzA3Nw0KRS1tYWlsIDogYmF0bWFuQGdvb2QudG8NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBSaWdo dCBhZ2FpbiwgQmlsbC4gSSB3YXMgdGhpbmtpbmcgYXVkaW8sIHdoZXJlIGVhY2ggc2FtcGxlID0g MSB0aWNrLiBNeQ0KPiAobm93IG1pbm9yKSBwb2ludCBpcyB0aGF0IHlvdSBzdGlsbCBuZWVkIHRv IHBpY2sgYW4gaW50ZWdlciBmb3IgdGhpcw0KPiB0aW1lc3RhbXAsIHNvIGl0IG1heSBub3QgYmUg dGhlIGFjdHVhbCBzZW5kIHRpbWUsIGJ1dCByYXRoZXIgdGhlIGNsb3Nlc3QNCj4gdGhpbmcuDQo+ IA0KPiAtSm9uYXRoYW4gUi4NCj4gDQo+IEJpbGwgRmVubmVyIHdyb3RlOg0KPiA+IA0KPiA+ID5I b3dldmVyLCB5b3UnbGwgc3RpbGwgbmVlZCB0byB1c2UgdGhlIHNhbXBsZSB0aW1lIG9mIHRoZQ0K PiA+ID5sYXN0IHNhbXBsZSBvYnRhaW5lZCBiZWZvcmUgc2VuZGluZyB0aGUgcGFja2V0LCBpbiBv cmRlciB0byBnZXQgYW4NCj4gPiA+aW50ZWdyYWwgbnVtYmVyIGZvciB0aGUgUlRQIHRpbWVzdGFt cC4NCj4gPiANCj4gPiBUaGF0J3MgYSBsaXR0bGUgcmVzdHJpY3RpdmUuICBUYWtlIGEgdmlkZW8g Y29kZWMgd2l0aCB0aW1lc3RhbXBzIGluIHVuaXRzDQo+ID4gb2YgOTBrSHouICBJZiB5b3UncmUg ZG9pbmcgNjBmcHMgdmlkZW8sIHRoZXJlIGFyZSAxNDk5IGludGVncmFsIHRpbWVzdGFtcA0KPiA+ IHZhbHVlcyBpbiBiZXR3ZWVuIGVhY2ggZnJhbWUgdGhhdCBjb3VsZCBhbHNvIGJlIHVzZWQgYXMg dGhlIFJUUCB0aW1lc3RhbXAuDQo+ID4gDQo+ID4gICBCaWxsDQo+IA0KPiAtLSANCj4gSm9uYXRo YW4gRC4gUm9zZW5iZXJnICAgICAgICAgICAgICAgICAgICAgICAyMDAgRXhlY3V0aXZlIERyaXZl DQo+IENoaWVmIFNjaWVudGlzdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3VpdGUgMTIw IA0KPiBkeW5hbWljc29mdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlc3QgT3Jh bmdlLCBOSiAwNzA1Mg0KPiBqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbSAgICAgICAgICAgICAgICAg ICAgIEZBWDogICAoNzMyKSA3NDEtNDc3OA0KPiBodHRwOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+ amRyb3NlbiAgICAgICAgIFBIT05FOiAoNzMyKSA3NDEtNzI0NA0KPiBodHRwOi8vd3d3LmR5bmFt aWNzb2Z0LmNvbQ0KPiANCj4gDQo= From rem-conf Thu Feb 24 01:33:49 2000 From rem-conf-request@es.net Thu Feb 24 01:33:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12NuZn-0006Mr-00; Thu, 24 Feb 2000 01:28:51 -0800 Received: from pi4.informatik.uni-mannheim.de [134.155.48.96] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12NuZl-0006Mh-00; Thu, 24 Feb 2000 01:28:50 -0800 Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96]) by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id KAA20015; Thu, 24 Feb 2000 10:28:46 +0100 (MET) Sender: mauve@pi4.informatik.uni-mannheim.de Message-ID: <38B4F9CE.17C28427@pi4.informatik.uni-mannheim.de> Date: Thu, 24 Feb 2000 10:28:46 +0100 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net, rmt@lbl.gov Subject: RTP/I Internet Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, please excuse if this mail is slightly off topic. We have submitted an Internet Draft specifying a Real Time Application Level Protocol for Distributed Interactive Media (RTP/I). Here is the abstract of the RTP/I Internet Draft: This document specifies RTP/I, an application level real-time protocol for distributed interactive media. Typical examples of distributed interactive media are shared whiteboards, networked computer games and distributed virtual environments. RTP/I defines a standardized framing for the transmission of data and provides mechanisms that are universally needed for this media class. Thereby RTP/I enables the development of reusable functionality and generic services that can be employed for multiple distributed interactive media. Examples for this kind of functionality are the ability to record sessions, to support late coming participants, and to provide security services. RTP/I is a protocol that follows the ideas of application level framing and integrated layer processing. It has been designed to be independent of the underlying network and transport layers. To a large extend RTP/I has been inspired by the real-time transport protocol (RTP), which is used for continuous non-interactive media. This document is intended to stimulate the discussion on how to transport distributed interactive media over the Internet. There exists an RTP/I mailing list. Instructions on how to subscribe to this list can be found at the RTP/I homepage (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/RTPI/index.html). Feedback on this document should be addressed to the RTP/I mailing list or directly to the authors. The RTP/I Internet Draft can be downloaded from the IETF directory or >from our RTP/I homepage (see above for the URL). We would welcome any kind of feedback! cheers, Martin -- --------------------------------------------------------------------------- Martin Mauve University of Mannheim Praktische Informatik IV Phone: +49-621-181-2616 L 15,16 Fax : +49-621-181-2601 68131 Mannheim mauve@pi4.informatik.uni-mannheim.de Germany --------------------------------------------------------------------------- From rem-conf Thu Feb 24 08:08:26 2000 From rem-conf-request@es.net Thu Feb 24 08:08:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12O0X5-0003YK-00; Thu, 24 Feb 2000 07:50:27 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12O0X3-0003YA-00; Thu, 24 Feb 2000 07:50:25 -0800 Received: from p109.nas2.is4.u-net.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 24 Feb 2000 15:49:54 +0000 Message-ID: <010801bf7eda$e9399aa0$edc666c3@tenaga> From: Farez To: rem-conf , agents , mobile-systems Subject: reminder - AMOC tutorial deadline approaching Date: Thu, 24 Feb 2000 15:21:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 1 March, 2000 is the tutorial proposal deadline for AMOC so there is 1 week to submit your proposals. Please see the CFT below for detais. ------------------------------------------------------------------------ Call for Tutorial Proposals FIRST ASIAN INTERNATIONAL MOBILE COMPUTING CONFERENCE (AMOC 2000) 1-3 November, 2000. Penang, Malaysia Tutorials: 31 October, 2000 http://www.fsktm.um.edu.my/amoc http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/amoc low bandwidth: append /lowband to URL above *** Proposal submission deadline: 1 March, 2000 *** The AMOC Programme Committee invites proposals for tutorials to be held on the 31st of October, 2000 in Penang, Malaysia. We invite proposals for three-hour tutorials on topics relating to the theory and/or practice of mobile and wireless computing and communications. The aim is to offer conference delegates both tutorials on up-to-date technologies, and case study tutorials on the application of the technologies to real-world problems. A list of suggested topics related to mobile/wireless computing/communications is given below as a guide; other topics will naturally be considered: o Quality of Service(QoS) o handover & location management o systems infrastructure o satellite technology o Internet access o power management o data services o lower layer protocols o rural wireless communications o data management o billing o security o e-commerce o agent technology o multimedia o hardware o Personal Communication Systems o terminal design & ergonomics Submission Procedures --------------------- All tutorial proposals should contain the following: - A brief description of the tutorial, suitable for inclusion in the conference registration brochure. - A detailed outline of the tutorial, including why the proposed topic is an important one and the content of the tutorial. - The necessary background and the potential target audience for the tutorial. - A description of why the tutorial topic is of interest to a substantial part of the AMOC audience. - A brief resumé of the presenter(s), which should include name, postal address, phone and fax numbers, email address if available, background in the tutorial area, references to any published work in the area and evidence of teaching experience, if any. This information may be included in the conference registration brochure. - Any audio-visual and room requirements. Tutorial proposals should be sent by email, in plain text format, to amoc-submission@fsktm.um.edu.my by 1 March, 2000. For more information, please visit http://www.fsktm.um.edu.my/amoc/ or email amoc-submission@fsktm.um.edu.my Important Dates --------------- Proposal submission deadline: 1 March, 2000 Notification of acceptance: 1 April, 2000 Tutorial abstract deadline: 1 May, 2000 Camera ready tutorial notes: 1 August, 2000 Additional Notes ---------------- Tutorial instructors will have their conference registration fees to AMOC waived. However, a maximum of two presenters' fees can be waived if there are two or more instructors. The AMOC organising committee reserves the right to cancel any tutorial if deadlines are missed or if the number of attendees is too low to support the costs related to organising and running the tutorial. From rem-conf Sun Feb 27 01:39:27 2000 From rem-conf-request@es.net Sun Feb 27 01:39:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12OztM-0002Qd-00; Sun, 27 Feb 2000 01:21:32 -0800 Received: from ncc.moc.kw [196.1.69.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 12OztK-0002QN-00; Sun, 27 Feb 2000 01:21:30 -0800 Received: from cashfloweb.freeservers.com (ppp-23-144.kems.net [168.187.23.144]) by ncc.moc.kw (8.9.2/8.9.3) with SMTP id MAA04948 for ; Sun, 27 Feb 2000 12:19:36 +0300 (GMT) Message-Id: <200002270919.MAA04948@ncc.moc.kw> Date: 27 Feb 00 12:14:00 +-0300 From: "CA$HFLOWEB" To: Subject: Do You Want to Be a Millionaire? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear , Have you ever sat in front of your PC and thought that there must be some way to use this powerful piece of technology to make extra money, but didn't have slightest idea how to go about doing it? Welcome to the world of Mail Order! Now before you get the idea that this will involve a lot of stamp-licking and trips to the post office, let me say that this business is not like the traditional mail-ordering business. Instead of a lot of paperwork, your PC will be accomplishing the bulk of the work much faster and easier than if it was done manually. The total investment for this opportunity is $5.00 (no kidding!) and the cost of five postage stamps. The rest of the work will be done by your PC, and will only involve a small amount of time behind the keyboard. But once again, I'd like to ask that you follow the instructions carefully. The success or failure of this plan depends on the honesty and integrity of its participants. If the plan is followed to the letter, it cannot fail. go to the following link http://www.cashfloweb.freeservers.com. Once you are there, download the program from the main page and start making money. Best Regards, CA$HFLOWEB From rem-conf Sun Feb 27 06:10:24 2000 From rem-conf-request@es.net Sun Feb 27 06:10:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12P4Hu-0004vG-00; Sun, 27 Feb 2000 06:03:10 -0800 Received: from hercules.ntsource.com (ntsource.com) [208.223.151.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12P4Hs-0004v0-00; Sun, 27 Feb 2000 06:03:08 -0800 Received: from uchicago.edu by ntsource.com (8.8.5/NETSO-5.9) id OAA03307; Sun, 27 Feb 2000 14:02:54 GMT Message-ID: <38B92F0C.48494A97@uchicago.edu> Date: Sun, 27 Feb 2000 08:05:00 -0600 From: Ken Hopper Reply-To: khopper@uchicago.edu Organization: The University of Chicago X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "CA$HFLOWEB" CC: rem-conf@es.net Subject: REMOVE References: <200002270919.MAA04948@ncc.moc.kw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "CA$HFLOWEB" wrote: > > Dear , > > Have you ever sat in front of your PC and thought that there must be some way to use this powerful piece of technology to make extra money, but didn't have slightest idea how to go about doing it? > > Welcome to the world of Mail Order! Now before you get the idea that this will involve a lot of stamp-licking and trips to the post office, let me say that this business is not like the traditional mail-ordering business. Instead of a lot of paperwork, your PC will be accomplishing the bulk of the work much faster and easier than if it was done manually. The total investment for this opportunity is $5.00 (no kidding!) and the cost of five postage stamps. The rest of the work will be done by your PC, and will only involve a small amount of time behind the keyboard. But once again, I'd like to ask that you follow the instructions carefully. The success or failure of this plan depends on the honesty and integrity of its participants. If the plan is followed to the letter, it cannot fail. > > go to the following link http://www.cashfloweb.freeservers.com. Once you are there, download the program from the main page and start making money. > > Best Regards, > CA$HFLOWEB > From rem-conf Sun Feb 27 10:10:41 2000 From rem-conf-request@es.net Sun Feb 27 10:10:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12P81L-0007KB-00; Sun, 27 Feb 2000 10:02:19 -0800 Received: from (ds138.datareturn.com) [216.46.234.112] by mail1.es.net with smtp (Exim 1.81 #2) id 12P81I-0007Jk-00; Sun, 27 Feb 2000 10:02:16 -0800 Received: from falkortech.com [207.97.14.170] by ds138.datareturn.com (SMTPD32-4.07) id A0BB3BE00D0; Thu, 24 Feb 2000 15:21:29 PDT From: Falkor Technologies Inc. To: Subscribers@es.net Subject: All stock-related operations on your own machine! How could that be ? Date: Sun, 27 Feb 2000 12:00:41 PDT Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------ The Offer ------------ We are glad to offer you our new products. They are BB Stock Tool and its improved edition BB Stock Pro. We offer user friendly interface, a superior system of prompting which provides ease of use and many other features and potentialities which are necessary for your successful online trading. While creating our software we conducted a public opinion poll of over 10,000 online brokers and traders. We have incorporated their advise and wishes in our new product. Now that our program has been completed, we are proud to provide you with the most fully functional and useful stock monitoring program available. With BB Stock Tools, you can do stock screening, portfolio management, technical charting on your own computer, so why pay monthly fee, login to online service to do it. Look at it's features! It makes low demands on computer resources as seen by it's systems requirements. You can find all this information at our web site where you can download our software! Try BB Stock Tool & BB Stock Pro and tell your friends about it! Trade online with BB Stock! Visit our site at http://www.falkortech.com! To unsubscribe this mailing list please write to info@falkortech.com with subject 'unsubscribe'. Features ---------- - Charting Chart window with price, volume and analysis information all in one window, a scrollbar to let you view 400 trading day easily. You can click on anyday in the chart to get the price and volume information. You can draw trendline and trend channels on the chart. - Watch List You can customize this list to monitor your own stocks easily, The buttons 'Load Next Stock' and 'Load Previous Stock' load the stock from this list. If you don't customize watch list, it defaults to all of the stocks in your historic database. - Auto Split Detection and Management Detects stock splits and you can confirm the splits. It adjusts portfolio accordingly, say from 200 shares of XYZ stocks from $48 to 400 shares at $24. - Auto Run Like auto slider show, it displays all of the stocks in your watch list one-by-one. You can also adjust the time interval between each display. - Technical Analysis and FlexTune (tm) It has all of the popular methods of technical analysis. BB Stock Pro has FlexTune, it allows you to adjust the parameters for each analysis and for each stock. For instance, Ford will most likely have different parameters from Cisco. You can customize the parameters and save to file. - Stock Screening You can find most active stocks and big price movers, you can also adjust the thresholds for the most active and big price movers. - Portfolio Management Trade Log window displays all of your transactions, Portfolio window displays all of your positions which are still open, that is, you still hold this stock, or the short sale is not covered. Transaction window is for you to open or close a position, In addition to buy and sell, you can sell short and buy cover. - Alert You can setup an high, low alerts for each stock, whenever a stock price reaches the alerts, a visual symbol is displayed when you load the stock, you can also view the Alert window to see all of the stocks and their alerts level. - Preview Analysis You can preset a price and preview the technical analysis result, it is very useful to find the price level to put order in advance. From rem-conf Mon Feb 28 07:15:53 2000 From rem-conf-request@es.net Mon Feb 28 07:15:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PReY-0002aL-00; Mon, 28 Feb 2000 07:00:06 -0800 Received: from lila.east.isi.edu [38.245.76.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PReU-0002a6-00; Mon, 28 Feb 2000 07:00:03 -0800 Received: from mailgate1.darpa.mil (mailgate1.darpa.mil [192.5.18.61]) by lila.east.isi.edu (8.8.5/8.6.12) with ESMTP id JAA25865 for ; Mon, 28 Feb 2000 09:45:25 -0500 (EST) Received: from mailhub1.darpa.mil (mailhub1.darpa.mil [158.63.2.41]) by mailgate1.darpa.mil (8.9.1/8.9.1) with ESMTP id JAA03062 for ; Mon, 28 Feb 2000 09:53:19 -0500 (EST) Received: from msx-smtp2.darpa.mil (msx-smtp2.darpa.mil [158.63.2.67]) by mailhub1.darpa.mil (8.9.1/8.9.1) with ESMTP id JAA17839 for ; Mon, 28 Feb 2000 09:52:38 -0500 (EST) Received: by msx-smtp2.darpa.mil with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Feb 2000 09:52:47 -0500 Message-ID: <71FB3F91A596D211960208002BB91BA39B364D@msx-4.darpa.mil> From: mmaeda To: "'ngi-list@ngi-supernet.org'" Subject: ngi seminar telcast: Vint Cerf - Interplanetary Internet Date: Mon, 28 Feb 2000 09:52:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Please pass along to your project team and to others who may be interested. Mari ------ Vint Cerf, "Interplanetary Internet" NGI Distinguished Lecture - 1 March 2000, 1 PM EST In order to expand the potential of Internet protocol beyond our realm and into space, I recently began working with NASA's Jet Propulsion Laboratory on a new project. The project entails developing an interplanetary communications system based on a special set of protocols that would carry transmissions between planets. The DARPA and NSF NGI Programs are proud to announce the second event in the NGI Distinguished Lecturer series of live and telecast seminars on Next Generation Internet technologies. Vint Cerf is senior vice president of Internet Architecture and Technology for MCI Worldcom. Cerf is the co-designer of the TCP/IP protocol, the communications protocol that gave birth to the Internet and which is commonly used today. In December 1997, President Clinton presented the U.S. National Medal of Technology to Cerf and his partner, Robert E. Kahn, for founding and developing the Internet. During his tenure from 1976-1982 with the U.S. Department of Defense's Advanced Research Projects Agency (DARPA), Cerf played a key role leading the development of Internet and Internet-related data packet and security technologies. Cerf served as founding president of the Internet Society from 1992-1995 and as the chairman of the Board from 1998-1999. He is a fellow of the IEEE, ACM, American Association for the Advancement of Science, the American Academy of Arts and Sciences and the National Academy of Engineering. He is on the Board of Directors of the Internet Corporation for Assigned Names and Numbers. Location: National Center for Supercomputing Applications ACCESS Facility: Ballston Metro Center Office Tower, Suite 800 901 North Stuart Street Arlington, Virginia 22203 Attendance: Space is limited. Please RSVP to ngi-seminar-rsvp@isi.edu. Directions for getting to the Access Facility can be found at the seminar's listing on http://www.ngi-supernet.org/conferences.html Multicast/Webcast: The NGI Distinguished Lecture Series will be multicast live and also webcast using RealMedia. The live multicast will allow for questions and comments from the remote audience. To tune into the Internet multicasts, look for the announcement in your MBONE session directory program ('sdr'). If the announcement is not present there, it still may be possible to receive the session by manually configuring the client programs ('vic', and 'rat' or 'vat') with session addresses. The session addresses, webcast details, and information on non-live access to the seminar will be posted on: http://www.ngi-supernet.org/conferences.html During the seminar, any technical difficulties about the multicast can be addressed to dartnoc@isi.edu. NGI Distinguished Lecture Series Future Speakers: 23 March 2000 Kim Claffy, CAIDA ======================== If you would like your name removed from this mailing list, pls send a note to ngi-list-owner@ngi-supernet.org From rem-conf Mon Feb 28 14:50:39 2000 From rem-conf-request@es.net Mon Feb 28 14:50:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PYr8-0000E3-00; Mon, 28 Feb 2000 14:41:34 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PYr7-0000Ds-00; Mon, 28 Feb 2000 14:41:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22609; Mon, 28 Feb 2000 17:41:28 -0500 (EST) Message-Id: <200002282241.RAA22609@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP Payload Format for Real-Time Pointers to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 28 Feb 2000 17:41:28 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload Format for Real-Time Pointers as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 13, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-pointer-02.txt From rem-conf Mon Feb 28 17:04:07 2000 From rem-conf-request@es.net Mon Feb 28 17:04:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PazO-0002Du-00; Mon, 28 Feb 2000 16:58:14 -0800 Received: from kickme.cisco.com [198.92.30.42] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PazN-0002Br-00; Mon, 28 Feb 2000 16:58:13 -0800 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id QAA11993; Mon, 28 Feb 2000 16:46:22 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA00125; Mon, 28 Feb 2000 16:57:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14523.6487.46685.713776@thomasm-u1.cisco.com> Date: Mon, 28 Feb 2000 16:56:55 -0800 (PST) To: Euchner Martin Cc: rem-conf@es.net Subject: proposal for RTP header authentication method / anti-spamming In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Euchner, You might want to take a look at the Packetcable security spec (http://www.packetcable.com) which also defines RTP payload encryption and authentication. The basic synopsis of the packetcable media stream security scheme is as follows: 1) Derive keying from upper layer signaling 2) Use RC-4 for the media encryption of the payload only. Since RC-4 is a stream cipher, potential packet drops need to be taken into account which the spec goes into quite a bit of detail about. 3) Use a 2 or 4 byte MAC which is appended to the end of the RTP packet itself. The packetcable spec does not use the pad bit, though in discussions on the SIP mailing list, this was also brought up as an option. Others think that the packetcable approach but using a different RTP profile (say, RTP/AVP-AUTH) ala RFC 1890 might be the right answer. I tend toward that solution because it consumes the fewest bytes, but the pad method is also a potential. One other difference is that the packetcable spec runs the MAC algorithm over the entire RTP packet, instead of just selected fields. In addition to being more secure, I suspect that you will find that running the MAC algorithm over the entire RTP datagram is cheaper CPUwise since it is more regular (we're only talking about a few bytes difference, right?). I have done some preliminary testing and the overall results look very promising (this was compiled on my Linux box at home with a P150 in it): code size: ~1kb ram size: ~530 bytes/full duplex (ie send and receive) speed: 2MB/sec for the MAC+Encryption In other words, it is *very* well suited to implementation on both large and small gateways, and very DSP friendly. Mike Euchner Martin writes: > Dear experts, > > the following contribution attached below proposes an RTP header > authentication method to protect against denial-of-service attacks using RTP > packet flooding on discovered UDP/RTP ports. > > First, some background information may be helpful for the reader's > understanding in general in addition to the contribution: > - I am the editor in ITU-T Study Group 16 of draft recommendation > H.235 version 2, that deals with "Security and encryption for H-Series > (H.323 and other H.245-based) multimedia terminals". > > - Basically, H.235 describes the framework for security in H.323 based > multimedia systems. It offers a variety of security services such as > authentication, access control, integrity, confidentiality, non-repudiation > with digital signatures and integrated key-management with security > capability negotiation for the secured call signaling and secure media > transport over RTP. H.235v2 features also interoperable security profiles > for various purposes and scenarios. > > - H.235 basically offers two methods for protection of the RTP media > streams: > - network layer security using IPSEC, > - or application-level security where the RTP media payload data is > encrypted. This is the preferred method that is currently of major interest. > Several encryption algorithms could be applied, among them are DES, > Triple-DES and RC2. > Note, that ITU-T SG16 currently does not see necessities to > integrity protect the RTP media stream, this is an issue left for further > study, once there would be a requirement. > > - As the most recent successful and severe denial-of-service attacks > on major ISPs and Internet services shows, sophisticated attacking tools are > already available in the hacker community. Such attacking tools could simply > be misused (with none or slight modifications perhaps) also against the RTP > protocol and thus thwarting any system that uses the RTP protocol including > H.323 Voice-over-IP systems. > > - While approved recommendation H.235v1 does not provide explicit > countermeasures against denial-of-service attacks, it is recognized that > H.235v2 should provide a simple, light-weight security means that is > sufficiently effective without the necessity to integrity-protect complete > media packet for performance reasons. The proposed light-weight security > improvement for RTP interworks both works with H.235 encrypted media streams > but also simply with unencrypted RTP payload data. H.235v2 cares for the > necessary key-management with automatic, integrated session > key-distribution, key update/synchronization and security capability > negotiation using H.245 open logical channel signaling means. H.235 allows > also manual key-management with statically configured keys. RTP does not > define any key-management and defines key-management tasks as by "non-RTP > means". Thus, our proposal nicely fits already in the current RTP approach > and concept. > > - At the most recent ITU-T Study Group 16 meeting in Geneva, CH, 7-18 > February 2000; the attached contribution D.335 was accepted for H.235v2. > However, it was pointed out by some delegates, that the IETF AVT working > group currently discusses a revised version of the RTP protocol. As the > fundamental problem is more related to RTP than H.323, we feel, that it > would be wise to solve the problem on an RTP level and provide the solution > to other RTP applications as well. Thus, we see good opportunities to > discuss our ideas with you and that we hopefully could come to an agreement > of a common procedure. > > - Our workplan in ITU-T SG16 is as follows: H.235v2 has recently been > determined. The final version of the draft is scheduled for > approval/decision in November 2000. Our next Rapporteurs meeting will be > held in May. We see good chances to come to a resolution of these common > matters until then. > > - The idea that is described in the proposal, cryptographically > protects the changing portion of the RTP header (i.e. timestamp and sequence > number) with a message digest. The result is put into the modified RTP > padding fields in the end of the RTP packet. This should be backwards > compatible with existing implementations. The message digest could be > computed using encryption techniques (DES-MAC) or using a secure hash > algorithm (SHA-1). These algorithms are not part of D.335 and have been > recently added to the draft of H.235v2. The receiver could verify the > authenticity of the packet and drop it if the digest is not correct. This > operation consumes only low effort and saves any significant processing > effort or resources of the application on top of RTP that would occur > otherwise. > > - Another option could be to deploy the RTP header extension method. > It is not clear, whether this had significant benefits and how that exactly > would work. > > - At present the enhanced RTP protocol format is still very flexible; > the length of the AUTH and padlen fields are not fully fixed since H.235 can > negotiate these parameters using H.245. When the protocol extension became > part of RTP, some further considerations should be given on defining > appropriate packet formats of course. > > - The contribution is the ASCII-converted delayed contribution D.335 > with some minor modifications. I've decided to have the H.245 and H.235 > stuff still included for better understanding of the entire procedures even > the RTP issues in the current draft would likely not be affected by this. > Those of you who are interested in the original Word97 version of the > document, may obtain it on request of course. > > > I am looking forward to hearing your comments, opinions and questions on > this. > > With kind regards, > > Martin Euchner. > > Here is the proposal: > > TITLE: RTP anti-spamming method in H.235v2 > ____________________________________________ > > This contribution describes a security enhancement to H.235v2 to counter > denial-of service attacks on UDP/RTP ports when sending spam media packets > against the recipient. The described improvement will increase the security > and reliability of H.323 Voice-over-IP-systems. > > 1. Introduction > > Current H.323 and H.235 based multimedia systems do not > provide explicit means against denial-of-service attacks when flooding > discovered RTP/UDP media ports with spam packets. This is of concern in > mission-critical VoIP systems that require high availability and have to > resist basic attacks. > > Some simple, lightweight security means are necessary to > counter the flooding attack on a discovered UDP port. As a result of a > successful attack, the end system (terminal, gateway, MCU,...) may no longer > provide its service or function appropriately due to caused overload > situation while considerably wasting resources (processing, memory,..). Such > an attack using IP-masquerading techniques is basically possible on any > H.323 system, regardless of whether H.235 media (voice/video) encryption is > implemented or not. While firewalls usually cannot counter this kind of > attack once the UDP ports have been connected through, the countermeasure > could be implemented in the end-system. For an attacker listening to the > media port negotiation (H.245 or H.225.0), the denial-of service attack is > quite easy to perform. The attacker either sends arbitrary media packets > with meaningful RTP header information or even replays intercepted RTP media > packets on the discovered port. The attacker may even probe the destination > ports without listening to a signaling connection. > > Present H.235 does not provide adequate security means to > protect against such threats. While media integrity in general would provide > means to detect such denial-of-service attacks too, the required > countermeasures are usually quite CPU-cycle intensive as the entire media > packet would have to be cryptographically integrity protected. Actually, > media integrity would not only counter any content manipulation of the data > in transit but also provide the media anti-spamming as a side effect. > However, as the need for true media integrity is not obvious at the moment, > section H.235/B.3 lists integrity and replay protection of the RTP stream as > for further study. > We provide an appropriate, yet simple lightweight > countermeasure, which is suitable for H.323 systems both with and without > implemented media encryption. Thus, the security can be enhanced > step-by-step. > > The basic idea is to utilize the end-to-end secret that can > be negotiated by means of H.235 anyway and apply it cryptographically to a > short, non-constant portion of the RTP packet and compute some digest upon; > actually this is a cryptographic message authentication code. Rapid checking > of the digest allows the receiver to filter out unauthorized packets from > unknown sources before spending any further considerable resources > processing the malicious packet. This shall thwart the denial-of-service > attacks of RTP packet flooding. We therefore call this security mechanism > the "media anti spamming method". The cryptographic digest may be computed > using a symmetric crypto algorithm such as DES or SHA1. > > > 2. Proposal > > We propose to use the new media anti-spamming method as an > option in H.235v2 (summarized in a new subsection 11.2 of H.235v2) and adopt > the following modifications to H.245 as well. > It is proposed to use the DES algorithm for the digest > computation; SHA1 may be used as an alternative when the system does not > offer media encryption. > > 2.1. H.245 modifications: > {this subsection is provided just for your information, it is subject to > H.245 and H.235} > > The capability of a terminal to support anti-spamming is > signaled in H.245 as follows. The anti-spaming capability is thus subject to > negotiation as well: > EncryptionAuthenticationAndIntegrity offers > AuthenticationCapability, which is extended as follows for media > anti-spamming: > > Enhancements to H.245 ANNEX A: > > AuthenticationCapability ::=SEQUENCE > { > nonStandard NonStandardParameter OPTIONAL, > ... > antiSpamAlgorithm OBJECT IDENTIFIER OPTIONAL > } > > Enhancements to H.245 Annex B.2.2.8 (Encryption, > Authentication and Integrity Capabilities) > EncryptionCapabilities, if present, indicate the encryption > capabilities of a terminal for each media type where the capabilities are > present. The scope of encryption indicates whether the encryption is applied > to the entire bit stream, a portion of the bit stream in a standard way, or > a portion of the stream in a non standard way. The algorithm selects the > encryption algorithm. > AuthenticationCapabilities if present, indicate that the > authentication components of H.235 [16] are supported by the terminal. > antiSpamAlgorithm indicates the method and algorithm how to provide > countermeasures against flooding and denial-of-service attacks. > > 2.2. H.235 additions > > H.235v2 provides a new subsection "11.2 Media anti-spamming" > with the following content: > > The receiver of an RTP media stream may wish to counter > denial-of-service and flooding attacks on discovered RTP/UDP ports. > Receivers, when having implemented the anti-spam capability, can quickly > determine whether an obtained RTP packet stems from an unauthorized source > and discard it. > > The anti-spamming capability when set indicates use of the > anti-spamming mechanism either > - for plaintext media data without media encryption (see > case 1 below) or > - in combination with encrypted media data when > EncryptionCapability features an encryption algorithm (see case 2 below). > > Both options provide a lightweight RTP packet authentication > on selected fields through a computed message authentication code (MAC). The > MAC may be computed using an encryption algorithm (e.g. DES in MAC mode, see > ISO/IEC 9797) or using a cryptographic one-way function (e.g. SHA1). The MAC > algorithm is indicated in the object identifier of antiSpamAlgorithm. The > algorithm OID implicitly indicates also the size of the MAC; e.g. 1 block = > 64 bits for DES MAC. In order to save bandwidth, the MAC could be truncated > albeit sacrificing some security; e.g., to a 32-bit MAC; this requires a > different object identifier then. The anti-spam method is independent of any > additional payload encryption (see cases 1 and 2 below). > > Anti-spamming uses the following RTP packet format (see > Figure 1) where the RTP padding sequence is interpreted as follows (see > H.225.0 Annex A.5). > - The P bit in the RTP header shall be set to 1. > - Padding bytes shall be appended at the end of the payload > with the following meaning: > > <------------------------------- RTP packet > -----------------------------------------------> > <-- RTP Header --> <-RTP payload-> <-- RTP > padding --> > > +----------+------+-----------+------+---------------+---------------+------ > --------+--------+ > |... P ... | SEQ# | timestamp | .... | media payload | padding bytes | > AUTH | padlen | > +----------+------+-----------+------+---------------+---------------+------ > --------+--------+ > > \____ e.g. 64 bits ___/ \__ possibly encrypted __/ > \e.g.64 bits / \1 byte/ > > > ^ > > | > MAC_k(...SEQ#,timestamp) > ----------------------------------------+ > > Figure 1: General RTP packet format for media anti-spamming > > Note: If anti-spamming is not used, then the AUTH and padlen > fields are not used either and the usual RTP packet format applies. > > 1. Case anti-spamming-only: > This case applies when the media data are not encrypted; see > Figure 2. The last octet of the RTP padding contains a count of how many > padding octets should be ignored at the end of the RTP packet. The other > padding bytes carry the MAC; see Figure 3. The MAC shall be computed over > the first crypto block of the RTP header including the varying timestamp and > sequence number using the negotiated MAC algorithm of antiSpamAlgorithm and > applying the symmetric secret. A static or manually configured shared secret > or a dynamically negotiated shared secret may be used according to the > procedures of H.235. For larger block sizes (more than 64 bits), some > sufficient additional bits of the RTP header or even the first media payload > shall be taken. > > As key for the MAC computation, it is recommended to use the > key that is obtained from the H.235 media session key distribution; although > the session key applied is not used for payload encryption. Secure fast > connect with key establishment (see H.323 Annex J) or manual keying may be > used for key management. The sender computes the MAC as described above and > includes the result in the MAC field in the RTP padding AUTH field. Sender > and receiver know the size of the AUTH field and the length of the MAC by > the antiSpamAlgorithm. > > The MAC verification at the receiver side should be done as > early as possible, if possible already within the RTP stack or at latest > before decryption or decompressing the payload. The receiver first > recomputes the MAC in the same way as the sender did and compares the > computed MAC with the delivered MAC in the RTP padding. If the MACs > mismatch, the RTP header has been modified in transit or was sent by an > unauthorized entity that does not possess the key. Thus, the > mis-authenticated RTP packet shall be discarded, the event may be logged; > this likely indicates an attempted denial-of-service attack. Otherwise, the > authenticated RTP packet can be processed further, the RTP padding is > removed and the payload is fed through the codec. > > Note: The lightweight MAC computation/verification with DES > encryption involves only a single encryption operation; alternatively, SHA1 > MAC is computed on a short part of the packets of fixed length, thus the > crypto operations consume absolutely minimal processing resources. > > <------------------------------- RTP packet > --------------------------------> > <-- RTP Header --> <-RTP payload-> <-- RTP padding > --> > > +----------+------+-----------+------+---------------+---------------+------ > --+ > |... P ... | SEQ# | timestamp | .... | media payload | MAC | > padlen | > +----------+------+-----------+------+---------------+---------------+------ > --+ > > \___ e.g. 64 bits ___/ \e.g.64 bits / \1 > byte/ > > ^ > | > MAC_k(...SEQ#,timestamp) -------------------------+ > > Figure 2: RTP packet format for media anti-spamming without > encryption > > > <----- RTP padding -----------> > > +------------------+------------+ > | MAC | padlen | > +------------------+------------+ > \_ e.g. 64 bits _/ \_ 1 byte _/ > > Figure 3: RTP padding for anti-spamming-only > > 2. Case anti-spam method and payload encryption: > This case applies when the media data are encrypted and the > anti-spamming method is invoked; see Figure 4. When the payload does not > fall on even block boundaries, some additional padding bytes have to be > appended to the payload in front of the MAC. The media payload encryption is > according to chapter 11/H.235. > > > > <------------------------------- RTP packet > -----------------------------------------------> > <-- RTP Header --> <-RTP payload-> <-- RTP > padding --> > > +----------+------+-----------+------+---------------+---------------+------ > --------+--------+ > |... P ... | SEQ# | timestamp | .... | media payload | padding bytes | > AUTH | padlen | > +----------+------+-----------+------+---------------+---------------+------ > --------+--------+ > > \____ e.g. 64 bits ___/ \_ encrypted in CBC mode __/ > \e.g.64 bits / \1 byte/ > > > ^ > > | > MAC_k(...SEQ#,timestamp) > ----------------------------------------+ > > Figure 4: RTP padding for anti-spamming with payload > encryption > > EncryptionCapability defines the payload encryption > algorithm while antiSpamAlgorithm defines the anti-spamming method. For > security reasons, the media encryption and the MAC shall use different > session keys. The MAC key k is computed by feeding the encryption key K > through the SHA1 one-way hash function; > k = SHA1(K); sufficient bits shall be taken from the hashed > result in network byte order. When antiSpamAlgorithm indicates an encryption > algorithm, then the collected bits shall be made a correct encryption key; > e.g. setting DES parity bits. > > After the receiver successfully verified the authenticity of > the RTP packet, the payload is decrypted and then the RTP padding be > discarded. The general procedure is according to case 1 above. > > > > > 3. References > > - Draft H.235v2: Security and Encryption for H-series (H.323 and other > H.245-based) Multimedia Terminals > - Draft H.323 Annex J: Security for H.323 Annex F > - H.245v7: Control Protocol for Multimedia Communication > - ISO/IEC 9797: Data cryptographic techniques - Data integrity mechanism > using a cryptographic check function employing an n-bit algorithm with > truncation. > > > ----------------------------------------------------------------------- > | Dipl.-Inf. Phone: +49 89 636-46201 > | Martin Euchner Fax : +49 89 636-48000 > | Siemens AG > | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de > | mailto:martin.euchner@ties.itu.int > | Otto-Hahn-Ring 6 Intranet: > http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ > index.html > | D-81730 Muenchen Internet: http://www.siemens.de > | __________________ > | Germany > ----------------------------------------------------------------------- > > > From rem-conf Mon Feb 28 18:12:41 2000 From rem-conf-request@es.net Mon Feb 28 18:12:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Pc51-0003PB-00; Mon, 28 Feb 2000 18:08:07 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Pc4z-0003P1-00; Mon, 28 Feb 2000 18:08:05 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA10502; Mon, 28 Feb 2000 21:08:01 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38BB29FF.D0FB3EA1@cs.columbia.edu> Date: Mon, 28 Feb 2000 21:07:59 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming References: <14523.6487.46685.713776@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > Euchner, > > You might want to take a look at the Packetcable > security spec (http://www.packetcable.com) which > also defines RTP payload encryption and > authentication. The basic synopsis of the > packetcable media stream security scheme is as > follows: > > 1) Derive keying from upper layer signaling > > 2) Use RC-4 for the media encryption of the > payload only. Since RC-4 is a stream cipher, > potential packet drops need to be taken into > account which the spec goes into quite a bit of > detail about. > > 3) Use a 2 or 4 byte MAC which is appended to the > end of the RTP packet itself. The packetcable > spec does not use the pad bit, though in > discussions on the SIP mailing list, this was > also brought up as an option. Others think that > the packetcable approach but using a different > RTP profile (say, RTP/AVP-AUTH) ala RFC 1890 > might be the right answer. I tend toward that > solution because it consumes the fewest bytes, > but the pad method is also a potential. > > One other difference is that the packetcable > spec runs the MAC algorithm over the entire > RTP packet, instead of just selected fields. > In addition to being more secure, I suspect > that you will find that running the MAC > algorithm over the entire RTP datagram is > cheaper CPUwise since it is more regular > (we're only talking about a few bytes > difference, right?). In a sense, 12 bytes of RTP header is more "regular" than the whole payload. I agree that picking and choosing bits and pieces of the RTP header is probably a waste of time. However, one consideration is that this is needed not just for audio, but also for video, in which case running MAC over the whole packet is probably a good idea (2 Mb/s may not do the trick there, particularly since you don't want to dedicate your whole CPU to this). Thus, as I would hope that PacketCable looks ahead to more than just audio, it appears that a header-only approach may be preferable. > > I have done some preliminary testing and the > overall results look very promising (this was > compiled on my Linux box at home with a P150 in > it): > > code size: ~1kb > ram size: ~530 bytes/full duplex (ie send and receive) > speed: 2MB/sec for the MAC+Encryption > > In other words, it is *very* well suited to > implementation on both large and small gateways, > and very DSP friendly. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Feb 29 00:33:42 2000 From rem-conf-request@es.net Tue Feb 29 00:33:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Pi0X-0007QE-00; Tue, 29 Feb 2000 00:27:53 -0800 Received: from wgserv.vnet.com.br (carrier-pigeon.vnet.com.br) [200.255.24.2] by mail1.es.net with smtp (Exim 1.81 #2) id 12Pi0T-0007PY-00; Tue, 29 Feb 2000 00:27:50 -0800 Received: from 152.172.129.10 [152.172.129.10] by carrier-pigeon.vnet.com.br (SMTPD32-4.06) id A49015B00C2; Mon, 28 Feb 2000 22:20:00 +0000 Message-ID: <0000351b70ea$0000154a$00005060@> To: From: kio322@email.com Subject: Hey Joe Date: Mon, 28 Feb 2000 16:04:01 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: kio322@email.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Have you ever dreamed of: - Owning Your Own Time? - Controlling your Financial Future? - Feeling Good about what you do and Helping Others? Are you: - Tired of working for someone else and getting paid what "they" feel you're worth? - Tired of the "get-rich-quick" $5 fantasy programs? - Tired of the MLM "dream scene"? - Looking for a legitimate home-based enterprise that can generate you $10k-20k+ monthly? THEN CHECK THIS OUT - Make $1,000 to $15,000 profit on every sale and our system does the selling for you! - No personal selling or "convince me" tactics involved. - Complete information system in place that does the explaining for you. - Free enterprise in its purest form, not MLM or franchise. - Full training and support in an environment of utmost integrity. - Exceptional products, not "vitamins, lotions, and potions". - Lead generation system that brings qualified prospects to you. - A multiple 6-figure income is realistically attainable in 1st year. - 2 to 3-year retirement program... PERIOD! - This program is all about money... how to make it, how to keep it, and how to make it work for you. CALL: 1-800-340-8929 (Free recorded message) You have nothing to lose and everything to gain, so call NOW! This is a one time mailing. You will not be removed by calling the 800 number! Have you ever dreamed of: - Owning Your Own Time? - Controlling your Financial Future? - Feeling Good about what you do and Helping Others? Are you: From rem-conf Tue Feb 29 02:46:44 2000 From rem-conf-request@es.net Tue Feb 29 02:46:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Pk69-0001dl-00; Tue, 29 Feb 2000 02:41:50 -0800 Received: from lila.east.isi.edu [38.245.76.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Pk68-0001db-00; Tue, 29 Feb 2000 02:41:49 -0800 Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by lila.east.isi.edu (8.8.5/8.6.12) with ESMTP id FAA27708 for ; Tue, 29 Feb 2000 05:28:42 -0500 (EST) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id <1GPVDS5H>; Tue, 29 Feb 2000 18:36:36 +0800 Message-ID: <30A14FB41CC5D311854D00508B5EEF0201ED5515@exs23.ex.nus.edu.sg> From: Ge Yu To: "'ngi-list@ngi-supernet.org'" Date: Tue, 29 Feb 2000 18:36:35 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscibe From rem-conf Tue Feb 29 03:10:40 2000 From rem-conf-request@es.net Tue Feb 29 03:10:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PkWT-0002XJ-00; Tue, 29 Feb 2000 03:09:01 -0800 Received: from dns.tundo.com (tundosbs.tundo.com) [192.116.161.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PkWS-0002X7-00; Tue, 29 Feb 2000 03:09:00 -0800 Received: by tundo.com with Internet Mail Service (5.5.1960.3) id ; Tue, 29 Feb 2000 13:08:37 +0200 Message-ID: <515C8AD5F244D311AFB700508B442B22056144@TUNDOMAIL> From: Lior Gedalyahu To: "'rem-conf@es.net'" Subject: Date: Tue, 29 Feb 2000 13:04:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscibe __________________________________________ Lior Gdalyahu Software Engineer Tundo Communications & Telephony Ltd. Giborei Israel Str.,P.O.Box 8420,Natania 42504 Tel (+) 972 9 885 2245 ext. 252 Fax (+) 972 9 885 2249 www.tundo.com E-mail: liorg@tundo.com __________________________________________ From rem-conf Tue Feb 29 09:49:44 2000 From rem-conf-request@es.net Tue Feb 29 09:49:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PqjD-0006fs-00; Tue, 29 Feb 2000 09:46:35 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PqjC-0006fi-00; Tue, 29 Feb 2000 09:46:34 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA03760; Tue, 29 Feb 2000 12:46:10 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38BC05E1.4158C779@cs.columbia.edu> Date: Tue, 29 Feb 2000 12:46:09 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming References: <14523.6487.46685.713776@thomasm-u1.cisco.com> <38BB29FF.D0FB3EA1@cs.columbia.edu> <14524.1010.983454.104942@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > Henning Schulzrinne writes: > > However, one consideration is that this is needed not just for audio, > > but also for video, in which case running MAC over the whole packet is > > probably a good idea (2 Mb/s may not do the trick there, particularly > > since you don't want to dedicate your whole CPU to this). > > So, I'm confused: you're saying that the MAC > *should* be run over the RTP header + payload? > If so, I agree, and that is in fact what the > packetcable spec mandates. No, it should only use the first 12 bytes RTP header (i.e., without worrying about CSRC lists, although this is debatable), since video packets are generally quite long and the overall video rate can well approach your 2Mb/s capacity, sucking up all CPU just with doing integrity checks. > > It wasn't clear given my cursory reading of their > spec whether the MAC was run over the payload or > not. Assuming that it is not, the obvious > complaint is that it is susceptible to man in > the middle attacks which tamper with the > payload. While I guess this comes down to how > rigorous you want to be, it seems there should > be a huge amount of motivation to *not* do the > more secure thing. I'm not convinced at all for > audio that there is any such motivation, and > I'm pretty doubtful about video as well. The primary motivation is data handling. In your scheme, a PC would do nothing but generate the outgoing MAC and verify the incoming MAC, with no cycles left for anything else useful. A nice denial-of-service attack right there. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Feb 29 09:49:46 2000 From rem-conf-request@es.net Tue Feb 29 09:49:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Pqc4-0006aa-00; Tue, 29 Feb 2000 09:39:12 -0800 Received: from sj-mailhub-3.cisco.com [171.68.224.215] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Pqc4-0006aM-00; Tue, 29 Feb 2000 09:39:12 -0800 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA19075; Tue, 29 Feb 2000 10:01:29 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA00422; Tue, 29 Feb 2000 09:37:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14524.1010.983454.104942@thomasm-u1.cisco.com> Date: Tue, 29 Feb 2000 09:37:54 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming In-Reply-To: <38BB29FF.D0FB3EA1@cs.columbia.edu> References: <14523.6487.46685.713776@thomasm-u1.cisco.com> <38BB29FF.D0FB3EA1@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne writes: > However, one consideration is that this is needed not just for audio, > but also for video, in which case running MAC over the whole packet is > probably a good idea (2 Mb/s may not do the trick there, particularly > since you don't want to dedicate your whole CPU to this). So, I'm confused: you're saying that the MAC *should* be run over the RTP header + payload? If so, I agree, and that is in fact what the packetcable spec mandates. It wasn't clear given my cursory reading of their spec whether the MAC was run over the payload or not. Assuming that it is not, the obvious complaint is that it is susceptible to man in the middle attacks which tamper with the payload. While I guess this comes down to how rigorous you want to be, it seems there should be a huge amount of motivation to *not* do the more secure thing. I'm not convinced at all for audio that there is any such motivation, and I'm pretty doubtful about video as well. Mike From rem-conf Tue Feb 29 10:56:04 2000 From rem-conf-request@es.net Tue Feb 29 10:56:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Prkk-0000oA-00; Tue, 29 Feb 2000 10:52:14 -0800 Received: from goliath.siemens.de [194.138.37.131] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Prkj-0000o0-00; Tue, 29 Feb 2000 10:52:13 -0800 X-Envelope-Sender-Is: Martin.Euchner@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id TAA06921; Tue, 29 Feb 2000 19:52:06 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id TAA24853; Tue, 29 Feb 2000 19:52:06 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Feb 2000 19:52:08 +0100 Message-ID: From: Euchner Martin To: "'Michael Thomas'" , Henning Schulzrinne Cc: Euchner Martin , rem-conf@es.net Subject: RE: proposal for RTP header authentication method / anti-spamming Date: Tue, 29 Feb 2000 19:52:07 +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 my impression obtained by looking shortly at the CableLabs Spec (thanks for providing the pointer) is that CableLabs might address other (i.e. higher) security requirements than Henning and I have in mind. This however seems to indicate, that RTP is being used by different applications, in different scenarios with different security requirements. BTW, I do not know the reason why CableLabs considered media integrity that important; is this described somewhere? Thus, it seems evident, that RTP cannot and probably does not have to satisfy them all with the same security mechanism. My guess is, that the protocol should support the approaches in some basic manner while maintaining enough degree of flexibility and find some common mechanism (is this the padding method? or could we agree to something like that?) that suits all purposes. As I mentioned in my initial email, H.235 until now has not identified any security need for provisioning media integrity. We left this issue for further study and I believe this will stay so for some more time. People have already concerns about media encryption performance and this will become even worse when media integrity should be done as well. Please remember that ITU-T SG 16 uses RTP not only in terminals, where performance is not that issue but also in large scale voice gateways with thousands of parallel media streams. Then each CPU cycle counts and unless there is a real need for integrity, the encryption provided should probably already be sufficient. Manipulation on the encrypted media content would probably yield annoying sounds at the receiver when trying to decode the manipulated data, but this "denial-of-service" attack could be countered already when using the proposed integrity check just over the header parts. So I consider media integrity as a low(er) priority security requirement. I also doubt whether media integrity is really appropriate just for countering denial-of-service attacks with sent spam packets: this sounds a bit of over-engineering to me. On the other hand, throwing away manipulated RTP packets does not result in a "denial-of-service attack"; although from a user's perspective this might look so. This is so, as RTP does not provide a guaranteed delivery of data (because of unreliable UDP) and packets may get dropped anyway somewhere in network elements. For your information, I'm preparing already an internet-draft that goes beyond my initial ideas. I expect it to be ready early next week and you will get it as soon as it is ready. The paper will take into account media integrity as an option as well and will describe also means how efficient media integrity could be achieved without the need for extra CPU-intensive integrity computation. Martin ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Michael Thomas [SMTP:mat@cisco.com] Sent: Tuesday, February 29, 2000 6:38 PM To: Henning Schulzrinne Cc: Michael Thomas; Euchner Martin; rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming Henning Schulzrinne writes: > However, one consideration is that this is needed not just for audio, > but also for video, in which case running MAC over the whole packet is > probably a good idea (2 Mb/s may not do the trick there, particularly > since you don't want to dedicate your whole CPU to this). So, I'm confused: you're saying that the MAC *should* be run over the RTP header + payload? If so, I agree, and that is in fact what the packetcable spec mandates. It wasn't clear given my cursory reading of their spec whether the MAC was run over the payload or not. Assuming that it is not, the obvious complaint is that it is susceptible to man in the middle attacks which tamper with the payload. While I guess this comes down to how rigorous you want to be, it seems there should be a huge amount of motivation to *not* do the more secure thing. I'm not convinced at all for audio that there is any such motivation, and I'm pretty doubtful about video as well. Mike From rem-conf Tue Feb 29 16:00:53 2000 From rem-conf-request@es.net Tue Feb 29 16:00:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PwRU-0004Ub-00; Tue, 29 Feb 2000 15:52:40 -0800 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PwRT-0004TA-00; Tue, 29 Feb 2000 15:52:39 -0800 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA07365; Tue, 29 Feb 2000 15:52:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA00463; Tue, 29 Feb 2000 15:51:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14524.23432.133855.641433@thomasm-u1.cisco.com> Date: Tue, 29 Feb 2000 15:51:36 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming In-Reply-To: <38BC05E1.4158C779@cs.columbia.edu> References: <14523.6487.46685.713776@thomasm-u1.cisco.com> <38BB29FF.D0FB3EA1@cs.columbia.edu> <14524.1010.983454.104942@thomasm-u1.cisco.com> <38BC05E1.4158C779@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne writes: > Michael Thomas wrote: > > > > Henning Schulzrinne writes: > > > However, one consideration is that this is needed not just for audio, > > > but also for video, in which case running MAC over the whole packet is > > > probably a good idea (2 Mb/s may not do the trick there, particularly > > > since you don't want to dedicate your whole CPU to this). > > > > So, I'm confused: you're saying that the MAC > > *should* be run over the RTP header + payload? > > If so, I agree, and that is in fact what the > > packetcable spec mandates. > > No, it should only use the first 12 bytes RTP header (i.e., without > worrying about CSRC lists, although this is debatable), since video > packets are generally quite long and the overall video rate can well > approach your 2Mb/s capacity, sucking up all CPU just with doing > integrity checks. Uh, I don't think we should get all hung up about actual speeds. My P150 can do 2-3 M*bytes*, not bits, and if done on a DSP with single cycle multiplies, it would be closer to 10MB. But this ignores the larger question though: do you actually consider man in the middle attacks to be of no concern? With the way you're proposing we do this, I can intercept your 700 Club video packets, and adulter the payload to play out the Hustler Channel (or more frightening still, the reverse). Your RTP receiver would be none the wiser. As far as DoS attacks, I can just as easily send you lots of MTU sized packets with ESP headers with a valid SPI and spoofed IP headers to and cause you do lots and lots of useless SHA-1 computations; it sort of goes with the territory. Making RTP marginally better for DoS attacks doesn't seem like it's worth much in the grander scheme of things, especially when you're opening yourself up to well known (and serious, IMO) attacks. Mike From rem-conf Tue Feb 29 16:05:40 2000 From rem-conf-request@es.net Tue Feb 29 16:05:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12PwaK-0004eC-00; Tue, 29 Feb 2000 16:01:48 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12PwaJ-0004e2-00; Tue, 29 Feb 2000 16:01:47 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA13526; Tue, 29 Feb 2000 19:01:38 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <38BC5DE1.DF6D7A4A@cs.columbia.edu> Date: Tue, 29 Feb 2000 19:01:37 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming References: <14523.6487.46685.713776@thomasm-u1.cisco.com> <38BB29FF.D0FB3EA1@cs.columbia.edu> <14524.1010.983454.104942@thomasm-u1.cisco.com> <38BC05E1.4158C779@cs.columbia.edu> <14524.23432.133855.641433@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > Henning Schulzrinne writes: > > Michael Thomas wrote: > > > > > > Henning Schulzrinne writes: > > > > However, one consideration is that this is needed not just for audio, > > > > but also for video, in which case running MAC over the whole packet is > > > > probably a good idea (2 Mb/s may not do the trick there, particularly > > > > since you don't want to dedicate your whole CPU to this). > > > > > > So, I'm confused: you're saying that the MAC > > > *should* be run over the RTP header + payload? > > > If so, I agree, and that is in fact what the > > > packetcable spec mandates. > > > > No, it should only use the first 12 bytes RTP header (i.e., without > > worrying about CSRC lists, although this is debatable), since video > > packets are generally quite long and the overall video rate can well > > approach your 2Mb/s capacity, sucking up all CPU just with doing > > integrity checks. > > Uh, I don't think we should get all hung up > about actual speeds. My P150 can do 2-3 M*bytes*, > not bits, and if done on a DSP with single > cycle multiplies, it would be closer to 10MB. > > But this ignores the larger question though: do > you actually consider man in the middle attacks > to be of no concern? With the way you're > proposing we do this, I can intercept your 700 > Club video packets, and adulter the payload to > play out the Hustler Channel (or more > frightening still, the reverse). Your RTP > receiver would be none the wiser. > > As far as DoS attacks, I can just as easily > send you lots of MTU sized packets with ESP > headers with a valid SPI and spoofed IP headers > to and cause you do lots and lots of useless > SHA-1 computations; it sort of goes with the > territory. Making RTP marginally better for > DoS attacks doesn't seem like it's worth much > in the grander scheme of things, especially > when you're opening yourself up to well known > (and serious, IMO) attacks. Practically speaking, I can launch a DOS attack from just about anywhere. It requires a fair amount of network access to intercept your packets (since I need to be able to snoop them and then inject them again). That said, I agree we'd all be better off if we can agree on one method within ITU/PacketCable/etc., rather than have half a dozen. Preferably a method that then has an SDP negotiation mechanism associated with it; would be even nicer to have one which is backward-compatible with existing systems, as that would speed its deployment significantly. Padding offers this, under the probably mistaken assumption that a certain common RTP client made by a famous maker actually doesn't choke on these (or header extensions). > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Tue Feb 29 20:57:41 2000 From rem-conf-request@es.net Tue Feb 29 20:57:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12Q19c-0000HT-00; Tue, 29 Feb 2000 20:54:32 -0800 Received: from reddot.dynamicsoft.com [216.89.83.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 12Q19b-0000H3-00; Tue, 29 Feb 2000 20:54:32 -0800 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA11247; Tue, 29 Feb 2000 23:54:14 -0500 (EST) Message-ID: <38BC50DA.4CBE175E@dynamicsoft.com> Date: Tue, 29 Feb 2000 18:06:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Henning Schulzrinne , Euchner Martin , rem-conf@es.net Subject: Re: proposal for RTP header authentication method / anti-spamming References: <14523.6487.46685.713776@thomasm-u1.cisco.com> <38BB29FF.D0FB3EA1@cs.columbia.edu> <14524.1010.983454.104942@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > > Henning Schulzrinne writes: > > However, one consideration is that this is needed not just for audio, > > but also for video, in which case running MAC over the whole packet is > > probably a good idea (2 Mb/s may not do the trick there, particularly > > since you don't want to dedicate your whole CPU to this). > > So, I'm confused: you're saying that the MAC > *should* be run over the RTP header + payload? > If so, I agree, and that is in fact what the > packetcable spec mandates. I think the problem is that Henning left out a "not" in the sentence above, so it should rather read: However, one consideration is that this is needed not just for audio, but also for video, in which case running MAC over the whole packet is probably *NOT* a good idea (2 Mb/s may not do the trick there, particularly since you don't want to dedicate your whole CPU to this). > It wasn't clear given my cursory reading of their > spec whether the MAC was run over the payload or > not. Assuming that it is not, the obvious > complaint is that it is susceptible to man in > the middle attacks which tamper with the > payload. Actually, you don't need man in the middle to tamper. You can simply snoop packets, make a copy, remove the payload, insert your own payload, and then send those. The receiver will get one or the other first; if the faked ones are received first you will be able to insert your forged audio stream. While I guess this comes down to how > rigorous you want to be, it seems there should > be a huge amount of motivation to *not* do the > more secure thing. I'm not convinced at all for > audio that there is any such motivation, and > I'm pretty doubtful about video as well. Just to make sure we're not missing a not here also - you're arguing for the less secure mechanism? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com