From rem-conf Tue Dec 01 01:42:47 1998 From rem-conf-request@es.net Tue Dec 01 01:42:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkmEg-0004gy-00; Tue, 1 Dec 1998 01:36:46 -0800 Received: from haig.cs.ucl.ac.uk [128.16.6.8] by mail1.es.net with smtp (Exim 1.81 #2) id 0zkmEe-0004go-00; Tue, 1 Dec 1998 01:36:45 -0800 Received: from tiramisu.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 1 Dec 1998 09:36:28 +0000 Message-ID: <006401be1d0d$a7563e20$9b051080@tiramisu.cs.ucl.ac.uk> From: Socrates Varakliotis To: Malcolm Caldwell , rem-conf Cc: "s.varakliotis" Subject: Re: Linux vat Date: Tue, 1 Dec 1998 09:33:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Malcolm Caldwell To: rem-conf@es.net Date: Tuesday, December 01, 1998 12:26 AM Subject: Linux vat >I am looking for a version of vat for linux that will run cards supported by >video for linux, or better video for linux 2. You probably mean vic here. >I have been on the list for a long time. I have a lot of problems finding >various versions of vic for different platforms. I guess the problem is that >vic stopped being supported. Heaps of people have made their own versions >with various cards supported etc. Have you seen the original vic web page at UCB/LBNL? http://www-nrg.ee.lbl.gov/vic/ Isidor's page might be of interest, as well: http://www.cs.ucl.ac.uk/staff/i.kouvelas/vic/ >What is needed is a real "vic" web page, with a list of all the different >versions. See also: http://www.cs.brown.edu/~lsh/ooVIC/ http://kbs.cs.tu-berlin.de/payload/ and the MASH version: http://www-mash.cs.berkeley.edu/mash/software/usage/vic.html I hope this helps. Kind regards, Socrates Varakliotis ______________________________________________________________________ Department of Computer Science Tel: +44 (0)171 419 3697 University College London Fax: +44 (0)171 387 1397 Gower Street, London, WC1E 6BT www.cs.ucl.ac.uk/staff/S.Varakliotis ______________________________________________________________________ From rem-conf Tue Dec 01 08:39:16 1998 From rem-conf-request@es.net Tue Dec 01 08:39:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zksp9-00001K-00; Tue, 1 Dec 1998 08:38:51 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zksp6-000018-00; Tue, 1 Dec 1998 08:38:49 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id SAA11228; Tue, 1 Dec 1998 18:36:00 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566CD.005B72A6 ; Tue, 1 Dec 1998 18:38:51 +0200 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: Henning Schulzrinne cc: rem-conf@es.net Message-ID: <422566CD.0051882F.00@il4.vocaltec.co.il> Date: Tue, 1 Dec 1998 17:16:41 +0200 Subject: Re: A totally different (simpler?) approach to tones and errata Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ok, I give up. I'm glad I submitted the first version. Just so we're all on the same page, here would be the tone frequency format, after the few changes that we've mentioned: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | modulation |M|D| volume | duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R R R| frequency |R|R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R R R| frequency |R|R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R R R| frequency |R|R R R| frequency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: modulation is an integer F between 0 and 255 - gives the modulation frequency in Hz, unless either M or D is 1. M is the "mutliply by 2" bit. If 1 then the modulation frequency is doubled. D is the "divide by 3 bit. If 1 then modulation frequency is divided by three. (so modulation frequency is F * (M+1) / (3D+1)) (This is a very ad hoc scheme, but it allows all of the freqencies in the ITU draft) Volume and duration are as in the Named signal event ("dtmf") format. R is reserved and must be 0 right now. (We might use it to signal some phase reversals or individual modulations, etc if it's ever needed. BTW, the ear can hear (say) a 440 Hz tone played with N phase reversals per second. The discontinuities in the derivative N times per second show up as harmonics that can be heard or detected. My friend swears that this is the difference between fax tones and modem tones, but I have not seen the standard. Is it V.8?? But for now no one seems to need it.) Frequency is a positive integer between 0 and 4096. This basically allows one to play Hungarian dial tone, or indeed the Brahms Hungarian Dances which were perhaps its inspiration. I think that the specification should note that telephone systems (outside Hungary) are only REQUIRED to be able to synthesize two tones simultaneously. BTW, if we include a separate modulation for each frequency, we will be able to synthesize some speech.... (maybe hungarian will need two modulation for each frequency). Scott Henning Schulzrinne on 11/30/98 06:52:59 PM To: Scott Petrack cc: rem-conf@es.net Subject: Re: A totally different (simpler?) approach to tones and errata Scott Petrack wrote: > > >I just don't see the advantage of a table instead of the simple > >enumeration of frequencies. > > The simple enumeration of frequencies is what is done in the DTMF draft: > after all, draft-ietf-avt-dtmf.txt just gives a table where index 1 means > "697 Hz + 1209 Hz". I just thought that the advantages there also apply > here. This is, I believe, somewhat different, since the set of DTMF signals won't be changed unless you modify a large fraction of the world's 640 million telephones. Adding new central-office tones doesn't require nearly that amount of change - one reason why DTMF is universal and CO tones are not. I think of DTMF "tones" as much more like the signal events like "Busy", except that they have a duration. > My understanding is that the combination of frequencies that is used > in the world's telephone networks is pretty fixed and stable. It isn't The problem is the "pretty". A few changes here and there are enough to make the table approach unwieldy at best. There may also be tones that the table misses (such as CNG and other fax/modem/control tones). A representation that can handle tones in the voiceband range seems much safer and adds only marginal space overhead. From a receiver perspective, it also seems easier, since I don't have to store the table. Plus, I can use it to play advertising jingles :-) This is not a major issue, but anything that doesn't require yet another IANA registry or 'vintages' on specifications is a win in my book... From rem-conf Tue Dec 01 08:39:19 1998 From rem-conf-request@es.net Tue Dec 01 08:39:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zksl3-0007mm-00; Tue, 1 Dec 1998 08:34:37 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zksl1-0007mb-00; Tue, 1 Dec 1998 08:34:35 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA22661; Tue, 1 Dec 1998 08:34:34 -0800 (PST) Message-Id: <3.0.3.32.19981201083433.00a99d90@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 01 Dec 1998 08:34:33 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 12/2 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Towards a Human-Centered Interaction Architecture Wednesday December 2, 1998 12:30-2:00 pm 405 Soda Hall Terry Winograd Computer Science Department, Stanford University We are developing an integrated multi-device workspace, based on a high level architecture for organizing multi-person multi-modal interactions with computer systems. The architecture provides several mechanisms for coping with fundamental properties of human interaction: object-based perception, context-dependent interpretation, and action-perception coupling. The talk will describe the underlying principles and the ways that they are being applied in our planned interactive workspace. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Dec 01 12:35:54 1998 From rem-conf-request@es.net Tue Dec 01 12:35:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkwO5-0003Sg-00; Tue, 1 Dec 1998 12:27:09 -0800 Received: from gnu.in-berlin.de (mail.vr.IN-Berlin.DE) [192.109.42.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkwO3-0003SU-00; Tue, 1 Dec 1998 12:27:07 -0800 Received: from hirsch.in-berlin.de (root@hirsch.in-berlin.de [192.109.42.6]) by mail.vr.IN-Berlin.DE (8.9.1a/8.9.1) with ESMTP id VAA11923; Tue, 1 Dec 1998 21:25:59 +0100 (CET) (envelope-from goldbach.in-berlin.de!kraxel@hirsch.in-berlin.de) Received: by hirsch.in-berlin.de (Smail3.2) id ; Tue, 1 Dec 1998 21:25:58 +0100 (CET) Received: from bogomips.masq.in-berlin.de (kraxel@bogomips.masq.in-berlin.de [192.168.69.77]) by goldbach.in-berlin.de (8.8.8/8.8.8) with ESMTP id VAA32363; Tue, 1 Dec 1998 21:17:34 +0100 From: Gerd Knorr Received: (from kraxel@localhost) by bogomips.masq.in-berlin.de (8.8.7/8.8.8) id VAA01338; Tue, 1 Dec 1998 21:17:33 +0100 Date: Tue, 1 Dec 1998 21:17:33 +0100 Message-Id: <199812012017.VAA01338@bogomips.masq.in-berlin.de> To: malcolm@it.ntu.edu.au Cc: rem-conf@es.net Subject: Re: Linux vat Newsgroups: lists.avt.rem-conf References: <19981201092554.A8164@abu.ntu.edu.au> X-Newsreader: NN version 6.5.1 (NOV) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In lists.avt.rem-conf you write: >I am looking for a version of vat for linux that will run cards supported by >video for linux, or better video for linux 2. diff and RedHat binary (i386) for a vic version with video4linux support available at: http://www.in-berlin.de/User/kraxel/v4l Tested with the bttv driver. Gerd -- Beware "We should", extend a hand to "How do I"... -- Alan Cox on /. From rem-conf Tue Dec 01 14:43:23 1998 From rem-conf-request@es.net Tue Dec 01 14:43:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zkyOV-0005tu-00; Tue, 1 Dec 1998 14:35:43 -0800 Received: from mtiwmhc04.worldnet.att.net [204.127.131.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zkyOT-0005tA-00; Tue, 1 Dec 1998 14:35:41 -0800 Received: from amil.saturn.bbn.com ([12.72.67.217]) by mtiwmhc04.worldnet.att.net (InterMail v03.02.07 118 124) with SMTP id <19981201001833.EMKC12648@amil.saturn.bbn.com>; Tue, 1 Dec 1998 00:18:33 +0000 From: akp4233@worldnet.att.net To: "Hot list of candidates"@es.net Date: Mon, 30 Nov 1998 16:12:04 -0800 X-Distribution: Bulk MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: Hot List of Candidates Priority: normal Message-Id: <19981201001833.EMKC12648@amil.saturn.bbn.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 0100,0100,0100Times New RomanHi, I have a few strong candidates available for consulting work. There profile is provided for your reference. Please contact me to pursue any one of these candidates. I would appreciate it very much if you please forward this profile to othe= r hiring managers in your organization. Gridcomp provides contract engineers to fulfill your short term or long term employment requirements. (1) Strong VC++ & NT candidate - available immediately. Has these skills: Experience: 4+ years of experience. has wor= ked for Oracle corp. Languages: Java, Microsoft Visual C++, C, Perl, SQL= , HTML, CORBA IDL outAPI=92s: Windows Tele= phony API (TAPI), OLE, ActiveX, Speech API (SAPI), CGI, Java Cryptography Extension (JCE 1.2) OS: Windows NT, 95, 3.1, MSDOS 6.x, UNIX (Solaris,= AIX, SunOS) Education: MS, Computer science, UCLA BS, summa Cum Laude, Computer science & Engineering, UCLA (2) Murali: Strong Java, SNMP, ATM, GUI candidate SUMMARY : Over 3+ years of experience with computer applications involving design, development, testing and Implementation. Expertise in building Network Management System(NMS) using SNMP protocols. Expertise in using JAVA, JDBC, RMI, Java Socket Programming, HTML, CGI, Java Script, C,C++, VC++, Install Shield-V5 ,Unix Shell Script, Java Workshop, Microsoft Frontpage-8,paint Shop Pro-3. TECHNICAL SKILLS: Protocols Worked :HTTP and SNMP. Area of Specialization :Network Management. outLanguages & Packages = :C,C++,VC++(V-5), JAVA (JDK1.1) , HTML, CGI, JDBC, JAVA Socket Programming,, Java Script, , RMI(Remote Method Invokation), Unix Shell Programming, InstallShield-V5, Java Workshop-V1, Symantec Caf=E9, Microsoft FrontPage- 8, PaintShop Pro-3 , Oracle -7, HP-OpenView Operating Systems :DOS, UNIX ( SUN OS ), Windows95, Windows NT. GUI :X-Windows/Motif, Forms-4. Tools Used :Net X-ray, SNMP-C, Sniffer. (3) Rajiv: Powerbuilder, Oracel, SQL, Foxpro candidate: SUMMARY : outOver 4 years of experience in the IT = Industry in various environments. outDevelopment which includes coding and design= ing user interface using DBMS and RDBMS concepts. outDeveloped packages using Software Environmen= t like FOXPRO and 4GL TOOLS like POWER BUILDER 4.0/5.0/6.0 with ORACLE 7.x which is a client/server technology. outGood knowledge on Inventory systems and Sto= ck Management Systems. outHands on experience in Banking systems. rightTECHNICAL SKILLS: ArialOPERATING SYSTEMS: MS-DOS, Windows 95/98,Windows NT 4.0. Windows 3.11 for workgroups. FRONT END TOOL : POWER BUILDER 4.0/5.0/6.0<= /italic> RDBMS: Oracle 7.x,Sybase SQL Anywhere 5.0, Watcom SQL 4.0 DBMS : FOXPRO LANGUAGES: C, C++,FORTRAN HARDWARE : INTEL PENTIUMS, IBM COMPATIBLES. FAMILIAR WITH: DEVELOPER 2000, DELPHI 1.0 Times New Roman(4) TV Murugan: Power Buil= der, Sybase, SQL, GUI candidate SUMMARY: Three years IT experience in software design, development, testing,= implementation and support using Power Builder (6.0/5.0/4.0 with PFC Application Development), Sybase System 10, Microsoft SQL Server 6.5 and GUIs. Working experience in applications such as Financial Accounting & Inventory control systems, Structural Engineering Design systems, Banking systems and Payroll systems. TECHNICAL SKILLS: Operating Systems : UNIX, Windows NT, Window= s 95, and DOS. RDBMS : Microsoft SQL Server 6.5, Syb= ase System 10 GUI : Power Builder 6.0/5.0/4.0 with= PFC (5) P. Ganesh: C, C++, VC++, MFC, COM/DCOM OOP, Crystal reports candidate ArialSUMMARY: Overall 5 =BD years of experience in multimedia projects, applicati= on development in Client Server environment and Internet. outProficient in C, C++, VC++ (MFC, ODBC & DAO)= , COM/DCOM, MS-Access & OOPS concepts outExperience in Analysis, Design, Development = & Testing out4 years experience in VC++ out2 years experience in BTrieve Crystal Report= s outBusiness Processes known =96 Retail Trading = & Point of Sale(POS) Times New RomanTECHNICAL SKILLS: ArialLanguages := C, C++ Frond End Tools : Visual C++, Visual Basic Operating Systems : MS-DOS, Win 3.1, Windows for Wo= rkgroups, Win95, Win98/NT Third Party Tools : Objective Grid, Dragon Voice Internet Tools : COM/DCOMTimes = New Roman Contact Anil Patel at { HYPERLINK mailto:anil@gridcomp.com }0000,0000,FF00anil@gridcomp.com0100,0100,0100 or (650)494-8407 to pursue these candidates. From rem-conf Tue Dec 01 20:54:42 1998 From rem-conf-request@es.net Tue Dec 01 20:54:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zl4Cp-0001i1-00; Tue, 1 Dec 1998 20:48:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zl4Cn-0001hr-00; Tue, 1 Dec 1998 20:48:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Dec 1 23:47:52 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id XAA22549; Tue, 1 Dec 1998 23:47:51 -0500 (EST) Message-ID: <3664C5E0.694F4ACE@dnrc.bell-labs.com> Date: Tue, 01 Dec 1998 23:45:20 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Neal Schneider CC: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981201010722.13622.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > The problem with this, arises when/if individual calls do not arrive at > consistant intervals to the multiplexing engine (i.e. over a packet > switched network, rather than a TDM.) Then the offset becomes very > difficult to calculate appropriately, if at all. The original > information must be retained. This is a very different kind of muxing. Now, you are talking about muxing in the middle of an IP network and demuxing in the middle of an IP network. As opposed to the gateway to gateway case, there will be no correlation between any of the components of any of the headers of any of the packets which are muxed together, since presumably they come from different sources. In this case, you will need to reconstruct the entire packet at the demux point, both timestamp and sequence number; that is, unless you are arguing for throwing away the timestamp for RTP in general. So, I don't see how offsets nor anything else help you here. Perhaps you have a different model in mind? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Dec 02 08:17:59 1998 From rem-conf-request@es.net Wed Dec 02 08:17:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlEtC-0004aG-00; Wed, 2 Dec 1998 08:12:30 -0800 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlEtB-0004Yh-00; Wed, 2 Dec 1998 08:12:29 -0800 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id LAA08817 for ; Wed, 2 Dec 1998 11:11:28 -0500 (EST) Received: from woodr by Software.Mitel.COM (4.1/SMI-4.0) id AA25833 for rem-conf@es.net; Wed, 2 Dec 98 11:11:27 EST Sender: woodr@Mitel.COM Message-Id: <366566AF.7093@mitel.com> Date: Wed, 02 Dec 1998 11:11:27 -0500 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/715) Mime-Version: 1.0 To: avt Subject: Intro & Q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I've just subscribed to this group and am having some problems getting the archives, so please bear with me if I am repeating previous discussions. I have the following Qs: 1. The draft rtpproto-00 has expired. Does this mean RTP will not be elevated to a protocol. I hope so, but a pity. 2. The draft rtp-multiplex-01 as a method of reducing bandwidth utilisation between VOIP gateways: a) Although the IP overhead figures given in table 1 make it look like an incredible waste, if one looks at the % of bandwidth utilization for a single channel, using 100base-T as a reference, it's pretty small. Need we be so obsessed by bandwidth utilisattion? b) Rather than this complicated scheme of multiplexing RTP headed packets, why not just trunk a number of channels through in one stream. Thus, an RTP trunking packet may be one sample from each of 32 channels. This keeps latency to a minimum which is highly desired by telcos. 3. I have also the following observations: a)With G.711, the number of 20mS for a frame packetisation period is arbitary and not ideal from the point of view of latency. My figures show there is very little difference in bandwidth utilization per channel, as a percentage, between 32 sample and 160 sample packets. In discussing this around here, I find this number of 20mS is a historical artifact. This is a typical frame period for compression and, secondly, software cannot process enough packets per second to allow smaller frames. b)Telcos really do place a premium on low-latency. [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com From rem-conf Wed Dec 02 08:41:51 1998 From rem-conf-request@es.net Wed Dec 02 08:41:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlFGq-0005d9-00; Wed, 2 Dec 1998 08:36:56 -0800 Received: from melimelo.enst-bretagne.fr [192.108.115.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlF7z-0005ID-00; Wed, 2 Dec 1998 08:27:49 -0800 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA36223; Wed, 2 Dec 1998 17:25:12 +0100 Received: from pacman (pacman.rennes.enst-bretagne.fr [193.52.74.218]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id RAA22067; Wed, 2 Dec 1998 17:24:36 +0100 (MET) From: Omar Elloumi Received: by pacman (SMI-8.6/rsalz-13-nov-89); Wed, 2 Dec 1998 17:24:37 +0100 Date: Wed, 2 Dec 1998 17:24:37 +0100 Message-Id: <199812021624.RAA04156@pacman> To: atm97authors@inesc.pt, atm96@inesc.pt, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov, atm@sun.com, cost237-transport@comp.lancs.at, Omar.Elloumi@enst-bretagne.fr Subject: extended deadline for ISCC'99 Cc: tantawi@us.ibm.com, Hossam.Afifi@enst-bretagne.fr X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My apologies if you receive multiple copies of this email. Due to several requests, the submission deadline for ISCC'99 has been extended to December 15, 1998. For further information, please visit the following web site: http://www.rennes.enst-bretagne.fr/~afifi/iscc99.html From rem-conf Wed Dec 02 09:33:41 1998 From rem-conf-request@es.net Wed Dec 02 09:33:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlG7B-0000IN-00; Wed, 2 Dec 1998 09:31:01 -0800 Received: from f249.hotmail.com (hotmail.com) [207.82.251.140] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlG7A-0000Gs-00; Wed, 2 Dec 1998 09:31:00 -0800 Received: (qmail 13844 invoked by uid 0); 2 Dec 1998 17:29:59 -0000 Message-ID: <19981202172959.13843.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Wed, 02 Dec 1998 09:29:58 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, jdrosen@dnrc.bell-labs.com Cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Wed, 02 Dec 1998 09:29:58 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are correct, in that offsets have no correlation with each other in this general arrival case. Is there any reason why sequence numbers could not retain all of the necessary information for reconstructing the RTP packet, if the original sampling rate was constant? Where the reconstructed timestamp would be equal to (sequence number * sampling interval). Rgds, Neal A. Schneider >different sources. In this case, you will need to reconstruct the entire >packet at the demux point, both timestamp and sequence number; that is, >unless you are arguing for throwing away the timestamp for RTP in >general. So, I don't see how offsets nor anything else help you here. >Perhaps you have a different model in mind? > >-Jonathan R. > > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Wed Dec 02 11:51:42 1998 From rem-conf-request@es.net Wed Dec 02 11:51:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlIDu-000448-00; Wed, 2 Dec 1998 11:46:06 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlIDt-00043y-00; Wed, 2 Dec 1998 11:46:05 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id VAA26376; Wed, 2 Dec 1998 21:44:42 +0200 (EET) Received: from bosteels (bsdhcp181182.americas.nokia.com) by miller.americas.nokia.com with SMTP (1.39.111.2/16.2) id AA284707919; Wed, 2 Dec 1998 14:45:19 -0500 Received: by localhost with Microsoft MAPI; Wed, 2 Dec 1998 14:46:22 -0500 Message-Id: <01BE1E02.873C5AC0.Jarno.Rajahalme@research.nokia.com> From: Jarno Rajahalme Reply-To: "Jarno.Rajahalme@research.nokia.com" To: "'nschneid@hotmail.com'" , "'jdrosen@dnrc.bell-labs.com'" Cc: "'rem-conf@es.net'" Subject: RE: RTP Multiplexing and Sequence Numbers Date: Wed, 2 Dec 1998 14:46:20 -0500 Organization: Nokia Research Center / Boston X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list That's right. As long as the time duration of each packet is constant, the timestamp can be derived from the sequence number as you stated. The problem is that when something like silence detection and comfort noise is used the original assumption does not hold any more. Typically the duration of the comfort noise packet is longer than that of a regular voice packet (or even unspecified). Sometimes packets with just silence are simply not transmitted. In these cases it is difficult to know the proper placement of the next actual voice packet in the playout buffer, if the timestamp is omitted. In cases where the network jitter is bounded, the arrival times of the few first packets of the talkspurt could provide enough information for the proper playback of the talkspurt, though. As the bandwidth saving from the silence detection is quite remarkable, it would be reasonable to expect every solution to work also when silence is suppressed in a form or another. Jarno Rajahalme -- Jarno Rajahalme Nokia Research Center / Boston 3 Burlington Woods Drive, Suite 260 Burlington, MA 01803, USA On Wednesday, December 02, 1998 12:30 PM, EXT Neal Schneider [SMTP:nschneid@hotmail.com] wrote: > You are correct, in that offsets have no correlation with each other in > this general arrival case. Is there any reason why sequence numbers > could not retain all of the necessary information for reconstructing the > RTP packet, if the original sampling rate was constant? Where the > reconstructed timestamp would be equal to (sequence number * sampling > interval). > > Rgds, > Neal A. Schneider > > >different sources. In this case, you will need to reconstruct the > entire > >packet at the demux point, both timestamp and sequence number; that is, > >unless you are arguing for throwing away the timestamp for RTP in > >general. So, I don't see how offsets nor anything else help you here. > >Perhaps you have a different model in mind? > > > >-Jonathan R. > > > > > >-- > >Jonathan D. Rosenberg Lucent Technologies > >Member of Technical Staff 101 Crawfords Corner Rd. > >High Speed Networks Research Holmdel, NJ 07733 > >FAX: (732) 834-5379 Rm. 4C-526 > >EMAIL: jdrosen@bell-labs.com > >URL: http://www.cs.columbia.edu/~jdrosen > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From rem-conf Wed Dec 02 12:05:21 1998 From rem-conf-request@es.net Wed Dec 02 12:05:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlITL-0004nI-00; Wed, 2 Dec 1998 12:02:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlITK-0004n7-00; Wed, 2 Dec 1998 12:02:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Dec 2 15:01:50 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA15554; Wed, 2 Dec 1998 15:01:49 -0500 (EST) Message-ID: <36659C13.8ECBB66D@dnrc.bell-labs.com> Date: Wed, 02 Dec 1998 14:59:15 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Jarno.Rajahalme@research.nokia.com" CC: "'nschneid@hotmail.com'" , "'rem-conf@es.net'" Subject: Re: RTP Multiplexing and Sequence Numbers References: <01BE1E02.873C5AC0.Jarno.Rajahalme@research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jarno Rajahalme wrote: > > That's right. As long as the time duration of each packet is constant, the > timestamp can be derived from the sequence number as you stated. The > problem is that when something like silence detection and comfort noise is > used the original assumption does not hold any more. Typically the duration > of the comfort noise packet is longer than that of a regular voice packet > (or even unspecified). Sometimes packets with just silence are simply not > transmitted. > > In these cases it is difficult to know the proper placement of the next > actual voice packet in the playout buffer, if the timestamp is omitted. In > cases where the network jitter is bounded, the arrival times of the few > first packets of the talkspurt could provide enough information for the > proper playback of the talkspurt, though. There is a more important problem related to backwards compatibility. In the case we are discussing here, that of mux and demux points outside of gateways or end systems, the RTP end users, gateways for example, won't know that the muxing is even going on. Now, say you design a mux protocol which generates incorrect timestamps in the RTP packet, under the assumption that you don't need them. The gateways will receive the RTP packets with the incorrect timestamp, but won't know they are incorrect since there is no indication that these have been muxed and demuxed prior to reception. As there are certainly gateways and end systems in production know which make use of the timestamp, you will break compatibility with them. I believe that *if* you want to do this non end-to-end muxing, you MUST reproduce exactly at the demux point the packets which enter at the mux point, regardless of whether you like sequence numbers, timestamps, or the like. I emphasize *if* as I'm not yet sure its such a hot idea. Its really not clear what kind of mux gains you'll get, as there is not much correlation in the headers of the muxed packets. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Dec 02 12:08:15 1998 From rem-conf-request@es.net Wed Dec 02 12:08:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlIXp-00055e-00; Wed, 2 Dec 1998 12:06:41 -0800 Received: from smtp1.erols.com [207.172.3.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlIXo-00055S-00; Wed, 2 Dec 1998 12:06:40 -0800 Received: from 207-172-138-110.s47.as6.dam.erols.com (207-172-138-110.s47.as6.dam.erols.com [207.172.138.110]) by smtp1.erols.com (8.8.8/8.8.5) with SMTP id PAA03395; Wed, 2 Dec 1998 15:06:33 -0500 (EST) Received: by 207-172-138-110.s47.as6.dam.erols.com with Microsoft Mail id <01BE1E05.AC2FDC00@207-172-138-110.s47.as6.dam.erols.com>; Wed, 2 Dec 1998 15:08:52 -0500 Message-ID: <01BE1E05.AC2FDC00@207-172-138-110.s47.as6.dam.erols.com> From: Imran Chaudhri To: "'Neal Schneider'" , "jdrosen@dnrc.bell-labs.com" Cc: "rem-conf@es.net" Subject: RE: RTP Multiplexing and Sequence Numbers Date: Wed, 2 Dec 1998 15:05:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Assuming both source and destination have access to the same synchronous = network clock you can do away with timestamps. However whenever you = cross an administrative or country boundary, this is not the case. Imran Imran N. Chaudhri imran@chaudhri.net T:301-963-3852 F:301-963-3851 M:301-537-8444 -----Original Message----- From: Neal Schneider [SMTP:nschneid@hotmail.com] Sent: Wednesday, December 02, 1998 12:30 PM To: nschneid@hotmail.com; jdrosen@dnrc.bell-labs.com Cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers You are correct, in that offsets have no correlation with each other in=20 this general arrival case. Is there any reason why sequence numbers=20 could not retain all of the necessary information for reconstructing the = RTP packet, if the original sampling rate was constant? Where the=20 reconstructed timestamp would be equal to (sequence number * sampling=20 interval). Rgds,=20 Neal A. Schneider >different sources. In this case, you will need to reconstruct the=20 entire >packet at the demux point, both timestamp and sequence number; that is, >unless you are arguing for throwing away the timestamp for RTP in >general. So, I don't see how offsets nor anything else help you here. >Perhaps you have a different model in mind? > >-Jonathan R. > > >--=20 >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Wed Dec 02 12:59:26 1998 From rem-conf-request@es.net Wed Dec 02 12:59:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlJIZ-0000ni-00; Wed, 2 Dec 1998 12:54:59 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlJIW-0000m5-00; Wed, 2 Dec 1998 12:54:56 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id WAA05732; Wed, 2 Dec 1998 22:54:14 +0200 (EET) Received: from bosteels (bsdhcp181182.americas.nokia.com) by miller.americas.nokia.com with SMTP (1.39.111.2/16.2) id AA293342095; Wed, 2 Dec 1998 15:54:55 -0500 Received: by localhost with Microsoft MAPI; Wed, 2 Dec 1998 15:55:59 -0500 Message-Id: <01BE1E0C.40F63270.Jarno.Rajahalme@research.nokia.com> From: Jarno Rajahalme Reply-To: "Jarno.Rajahalme@research.nokia.com" To: "'jdrosen@dnrc.bell-labs.com'" Cc: "'nschneid@hotmail.com'" , "'rem-conf@es.net'" Subject: RE: RTP Multiplexing and Sequence Numbers Date: Wed, 2 Dec 1998 15:55:57 -0500 Organization: Nokia Research Center / Boston X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list What is written below is valid, assuming that the endpoints indeed are using non-muxed RTP, and are e.g. using timestamps to synchronize multiple streams, etc. However, if the multiplex payload format is used to multiplex NON-RTP streams, there is no harm done (since there were no timestamps to begin with), and the header overhead can be reduced to two bytes per voice frame. Applicable example could be a network of IP telephony gateways interconnected with a network of "mux and demux nodes". Also, for simple IP telephony (single voice stream etc.) conversion from non-muxed RTP to/from muxed RTP could work as well. Also, deployed base of endpoints that would fail because of "artificial' timestamps could be small compared to the IP telephony deployment in the future. Finally, the terminals could use capability negotiation with their gateways/proxies to determine the use of multiplex payload format also for single stream voice or for multiplexed voice/video. With regards, Jarno Rajahalme On Wednesday, December 02, 1998 2:59 PM, EXT Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] wrote: > There is a more important problem related to backwards compatibility. In > the case we are discussing here, that of mux and demux points outside of > gateways or end systems, the RTP end users, gateways for example, won't > know that the muxing is even going on. Now, say you design a mux > protocol which generates incorrect timestamps in the RTP packet, under > the assumption that you don't need them. The gateways will receive the > RTP packets with the incorrect timestamp, but won't know they are > incorrect since there is no indication that these have been muxed and > demuxed prior to reception. As there are certainly gateways and end > systems in production know which make use of the timestamp, you will > break compatibility with them. > > I believe that *if* you want to do this non end-to-end muxing, you MUST > reproduce exactly at the demux point the packets which enter at the mux > point, regardless of whether you like sequence numbers, timestamps, or > the like. I emphasize *if* as I'm not yet sure its such a hot idea. Its > really not clear what kind of mux gains you'll get, as there is not much > correlation in the headers of the muxed packets. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > -- Jarno Rajahalme Nokia Research Center / Boston 3 Burlington Woods Drive, Suite 260 Burlington, MA 01803, USA From rem-conf Wed Dec 02 15:02:24 1998 From rem-conf-request@es.net Wed Dec 02 15:02:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlLBz-0000uj-00; Wed, 2 Dec 1998 14:56:19 -0800 Received: from f182.hotmail.com (hotmail.com) [207.82.251.71] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlLBx-0000rB-00; Wed, 2 Dec 1998 14:56:17 -0800 Received: (qmail 5737 invoked by uid 0); 2 Dec 1998 22:55:15 -0000 Message-ID: <19981202225515.5736.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Wed, 02 Dec 1998 14:55:15 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: Jarno.Rajahalme@research.nokia.com, jdrosen@dnrc.bell-labs.com Cc: nschneid@hotmail.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Wed, 02 Dec 1998 14:55:15 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Why would the muxed protocol violate legacy gateways? As long as the sequence number was accurately accounted for (even through periods of silence), one should be able to recreate timestamps accurately. This should be transparent to the end-to-end RTP session. Possibly the timestamp will be shifted by a certain constant, but the relationship between subsequent timestamps should remain the same. Am I correct in assuming that it is the difference in timestamps that really counts? Regards, Neal A. Schneider >There is a more important problem related to backwards compatibility. In >the case we are discussing here, that of mux and demux points outside of >gateways or end systems, the RTP end users, gateways for example, won't >know that the muxing is even going on. Now, say you design a mux >protocol which generates incorrect timestamps in the RTP packet, under >the assumption that you don't need them. The gateways will receive the >RTP packets with the incorrect timestamp, but won't know they are >incorrect since there is no indication that these have been muxed and >demuxed prior to reception. As there are certainly gateways and end >systems in production know which make use of the timestamp, you will >break compatibility with them. > >I believe that *if* you want to do this non end-to-end muxing, you MUST >reproduce exactly at the demux point the packets which enter at the mux >point, regardless of whether you like sequence numbers, timestamps, or >the like. I emphasize *if* as I'm not yet sure its such a hot idea. Its >really not clear what kind of mux gains you'll get, as there is not much >correlation in the headers of the muxed packets. > >-Jonathan R. > > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Dec 03 01:25:32 1998 From rem-conf-request@es.net Thu Dec 03 01:25:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlUvi-0002oy-00; Thu, 3 Dec 1998 01:20:10 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlUvf-0002oU-00; Thu, 3 Dec 1998 01:20:08 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Dec 1998 09:19:52 +0000 X-Mailer: exmh version 2.0.2 To: "'nschneid@hotmail.com'" cc: "Jarno.Rajahalme@research.nokia.com" , "jdrosen@dnrc.bell-labs.com" , "rem-conf@es.net" Subject: Re: RTP Multiplexing and Sequence Numbers In-reply-to: Your message of "Wed, 02 Dec 1998 15:55:57 EST." <01BE1E0C.40F63270.Jarno.Rajahalme@research.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 1998 09:19:49 +0100 Message-ID: <568.912676789@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The reason you want both sequence numbers and timestamps is the same reason you want them in RTP in the first place. Three reasons being: (a) without both tools cannot distinguish between packet loss and silence intervals. Therefore they cannot determine when to invoke loss concealment mechanisms, retransmission requests, FEC recovery, etc... (b) in the case where a talkspurt marker packet is lost you may lose legitimate opportunities to recalculate playout points. With both timestamps and seqno's you can tell when this happens because of change of relationship between the two. (c) you eliminate the opportunity for variable frame rate codecs. I am not aware of any that have been standardised, but have seen papers describing research in this direction (although not recent work :-) You do not have to send both in every packet, you just need a mechanism for reconstructing both. GeRM does this with a compact representation, using single bits to indicate (dis)continuities in seqno and timestamp and then updated fields follow the header. It is reasonable that the majority of streamed applications (voice, video, stock tickers, text messages, etc) need both irrespective of whether they are RTP-based or not. regards - Orion -- Orion Hodson [Research Student] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street London, WC1E 6BT, UK. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <01BE1E0C.40F63270.Jarno.Rajahalme@research.nokia.com>Jarno Rajahalme writes: > What is written below is valid, assuming that the endpoints indeed are > using non-muxed RTP, and are e.g. using timestamps to synchronize multiple > streams, etc. > > However, if the multiplex payload format is used to multiplex NON-RTP > streams, there is no harm done (since there were no timestamps to begin > with), and the header overhead can be reduced to two bytes per voice frame. > Applicable example could be a network of IP telephony gateways > interconnected with a network of "mux and demux nodes". > > Also, for simple IP telephony (single voice stream etc.) conversion from > non-muxed RTP to/from muxed RTP could work as well. Also, deployed base of > endpoints that would fail because of "artificial' timestamps could be small > compared to the IP telephony deployment in the future. > > Finally, the terminals could use capability negotiation with their > gateways/proxies to determine the use of multiplex payload format also for > single stream voice or for multiplexed voice/video. > > With regards, > > Jarno Rajahalme > > On Wednesday, December 02, 1998 2:59 PM, EXT Jonathan Rosenberg > [SMTP:jdrosen@dnrc.bell-labs.com] wrote: > > There is a more important problem related to backwards compatibility. In > > the case we are discussing here, that of mux and demux points outside of > > gateways or end systems, the RTP end users, gateways for example, won't > > know that the muxing is even going on. Now, say you design a mux > > protocol which generates incorrect timestamps in the RTP packet, under > > the assumption that you don't need them. The gateways will receive the > > RTP packets with the incorrect timestamp, but won't know they are > > incorrect since there is no indication that these have been muxed and > > demuxed prior to reception. As there are certainly gateways and end > > systems in production know which make use of the timestamp, you will > > break compatibility with them. > > > > I believe that *if* you want to do this non end-to-end muxing, you MUST > > reproduce exactly at the demux point the packets which enter at the mux > > point, regardless of whether you like sequence numbers, timestamps, or > > the like. I emphasize *if* as I'm not yet sure its such a hot idea. Its > > really not clear what kind of mux gains you'll get, as there is not much > > correlation in the headers of the muxed packets. > > > > -Jonathan R. > > > > > > -- > > Jonathan D. Rosenberg Lucent Technologies > > Member of Technical Staff 101 Crawfords Corner Rd. > > High Speed Networks Research Holmdel, NJ 07733 > > FAX: (732) 834-5379 Rm. 4C-526 > > EMAIL: jdrosen@bell-labs.com > > URL: http://www.cs.columbia.edu/~jdrosen > > > > > -- > Jarno Rajahalme > Nokia Research Center / Boston > 3 Burlington Woods Drive, Suite 260 > Burlington, MA 01803, USA > > From rem-conf Thu Dec 03 06:08:59 1998 From rem-conf-request@es.net Thu Dec 03 06:08:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlZMS-0002FE-00; Thu, 3 Dec 1998 06:04:04 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlZMQ-0002Er-00; Thu, 3 Dec 1998 06:04:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Dec 3 09:03:48 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA10538; Thu, 3 Dec 1998 09:03:47 -0500 (EST) Message-ID: <366699A6.2929DEAA@dnrc.bell-labs.com> Date: Thu, 03 Dec 1998 09:01:10 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Neal Schneider CC: Jarno.Rajahalme@research.nokia.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981202225515.5736.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > Why would the muxed protocol violate legacy gateways? As long as the > sequence number was accurately accounted for (even through periods of > silence), one should be able to recreate timestamps accurately. This > should be transparent to the end-to-end RTP session. Possibly the > timestamp will be shifted by a certain constant, but the relationship > between subsequent timestamps should remain the same. Am I correct in > assuming that it is the difference in timestamps that really counts? I assume that "sequence number was accurately accounted for during silence" would mean artificially jumping it to match the timestamp gap during silence periods. As Orion has pointed out, this will break systems which differentiate between loss repair and silence comfort noise insertion (and there is a difference), eliminate the possibility of variable rate codecs, and make talkspurt detection harder. Its more than that. RTCP loss statistics would be way off, reporting astronomical losses. This would then break any sender adaptive schemes which use loss as a guide for FEC insertion, codec selection, etc. I know of both research and commercial products that use adaptive techniques at the sender based on RTCP loss statistics. Also, doing this kind of SN manipulation will require stateful mux and demux to keep track of the SN. SHould it screw up in any way, potentially all voice calls through it become garbled. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Dec 03 07:04:17 1998 From rem-conf-request@es.net Thu Dec 03 07:04:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlaGY-0001ow-00; Thu, 3 Dec 1998 07:02:02 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlaGW-0001ol-00; Thu, 3 Dec 1998 07:02:00 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id RAA19288; Thu, 3 Dec 1998 17:01:16 +0200 (EET) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA065737313; Thu, 3 Dec 1998 10:01:53 -0500 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Dec03.095300.1991.399158; Thu, 03 Dec 1998 09:59:09 -0500 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: robert_wood@Mitel.COM (Robert Wood) Cc: rem-conf@es.net ('rem-conf') Message-Id: <1998Dec03.095300.1991.399158@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Thu, 03 Dec 1998 09:59:09 -0500 Subject: RE: Intro & Q X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to answer your Q 2.a You can consider a scenario where a new operator like to setup a IP = telephony network. In this case, the operator has to lease the trunk from a = = Telco. If this is the case, an operator would like to have a scheme by which= = every bit (he/she pays for) is used in an efficient way. I don't have to = repeat the 9 cents and 10 cents difference between operator and what it = means for customers. The important think to consider is that we develop a compromised scheme tha= t = meets the service requirement of Telephony and at the same time improves the= = bw efficiency. Your comment on 2.b is not clear to me. How do we identify the channels on = = RTP trunking packet ? >This is a typical frame period for compression and, secondly, software = cannot > process enough packets per second to allow smaller frames. Are you aware of the 10 ms and lower frames. regards, Barani Subbiah ---------- From: Robert Wood To: avt Subject: Intro & Q Date: Wednesday, December 02, 1998 11:11AM Hi, I've just subscribed to this group and am having some problems getting the archives, so please bear with me if I am repeating previous discussions. I have the following Qs: 1. The draft rtpproto-00 has expired. Does this mean RTP will not be elevated to a protocol. I hope so, but a pity. 2. The draft rtp-multiplex-01 as a method of reducing bandwidth utilisation between VOIP gateways: a) Although the IP overhead figures given in table 1 make it look like an incredible waste, if one looks at the % of bandwidth utilization for a single channel, using 100base-T as a reference, it's pretty small. Need we be so obsessed by bandwidth utilisattion? b) Rather than this complicated scheme of multiplexing RTP headed packets, why not just trunk a number of channels through in one stream. Thus, an RTP trunking packet may be one sample from each of 32 channels. This keeps latency to a minimum which is highly desired by telcos. 3. I have also the following observations: a)With G.711, the number of 20mS for a frame packetisation period is arbitary and not ideal from the point of view of latency. My figures show there is very little difference in bandwidth utilization per channel, as a percentage, between 32 sample and 160 sample packets. In discussing this around here, I find this number of 20mS is a historical artifact. This is a typical frame period for compression and, secondly, software cannot process enough packets per second to allow smaller frames. b)Telcos really do place a premium on low-latency. [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com From rem-conf Thu Dec 03 10:12:54 1998 From rem-conf-request@es.net Thu Dec 03 10:12:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zld94-0007ED-00; Thu, 3 Dec 1998 10:06:30 -0800 Received: from wya-lfd91.hotmail.com (hotmail.com) [207.82.252.155] by mail1.es.net with smtp (Exim 1.81 #2) id 0zld92-00074v-00; Thu, 3 Dec 1998 10:06:28 -0800 Received: (qmail 25857 invoked by uid 0); 3 Dec 1998 18:04:47 -0000 Message-ID: <19981203180447.25856.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Thu, 03 Dec 1998 10:04:45 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, jdrosen@dnrc.bell-labs.com Cc: Jarno.Rajahalme@research.nokia.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 03 Dec 1998 10:04:45 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree that manipulating sequence numbers (the basis for packet order, packet loss, and timing is there is no timestamp) is a jeopardous solution. In the case of multiplexing many voices, however, the benefits of completely dropping a channel in periods of silence are not substantial. Granted, if all voices were silent there would be an argument for holding back packets, but one could just take that as a infrequent loss. Could one continuously send packets with a 'comfort noise' payload format and incremental sequence numbers during periods of silence? And merely achieve less efficiency when there are fewer voices being multiplexed? Regards, Neal A. Schneider >I assume that "sequence number was accurately accounted for during >silence" would mean artificially jumping it to match the timestamp gap >during silence periods. As Orion has pointed out, this will break >systems which differentiate between loss repair and silence comfort >noise insertion (and there is a difference), eliminate the possibility >of variable rate codecs, and make talkspurt detection harder. Its more >than that. RTCP loss statistics would be way off, reporting astronomical >losses. This would then break any sender adaptive schemes which use loss >as a guide for FEC insertion, codec selection, etc. I know of both >research and commercial products that use adaptive techniques at the >sender based on RTCP loss statistics. > >Also, doing this kind of SN manipulation will require stateful mux and >demux to keep track of the SN. SHould it screw up in any way, >potentially all voice calls through it become garbled. > >-Jonathan R. > > > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Dec 03 11:19:27 1998 From rem-conf-request@es.net Thu Dec 03 11:19:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zleDr-00068s-00; Thu, 3 Dec 1998 11:15:31 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zleDl-0005za-00; Thu, 3 Dec 1998 11:15:26 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Dec 3 14:13:45 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA21367; Thu, 3 Dec 1998 14:13:44 -0500 (EST) Message-ID: <3666E24A.7B65246@dnrc.bell-labs.com> Date: Thu, 03 Dec 1998 14:11:06 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Neal Schneider CC: Jarno.Rajahalme@research.nokia.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981203180447.25856.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > I agree that manipulating sequence numbers (the basis for packet order, > packet loss, and timing is there is no timestamp) is a jeopardous > solution. > > In the case of multiplexing many voices, however, the benefits of > completely dropping a channel in periods of silence are not substantial. > Granted, if all voices were silent there would be an argument for > holding back packets, but one could just take that as a infrequent loss. > Could one continuously send packets with a 'comfort noise' payload > format and incremental sequence numbers during periods of silence? And > merely achieve less efficiency when there are fewer voices being > multiplexed? In the case of mid-network multiplexing, you could try this, but I still see problems. Firstly, the RTCP statistics will still be totally fouled up (even worse, in fact), since the loss rates will most likely be negative (receiver gets more than sender sends) since the mux point is inserting these comfort noise packets. Highest SN sent statistic will also be fouled up. Thus, adaptive schemes will still fail. Secondly, I thought the whole point of this argument was that sending the timestamp was too much overhead. Well, its 32 bits per user. Given a person is in silence roughly 50% of the time, you want to send a comfort noise filler, which is likely more than 64 bits, instead of sending nothing. I believe you will actually end up sending more bits than if you just leave the timestamp in place, and let it work as it was originally designed to. You could have the mux point hijack the RTCP also, and then modify it on the fly based on new statistics. But, you'll lose the end to end statistics provided by RTCP, in addition to now requiring some really serious processing. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Dec 03 11:30:05 1998 From rem-conf-request@es.net Thu Dec 03 11:30:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zleQ3-0000C5-00; Thu, 3 Dec 1998 11:28:07 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zleQ0-0000BH-00; Thu, 3 Dec 1998 11:28:05 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Dec 3 14:26:16 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA22011; Thu, 3 Dec 1998 14:26:10 -0500 (EST) Message-ID: <3666E534.88ABDD22@dnrc.bell-labs.com> Date: Thu, 03 Dec 1998 14:23:32 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Subbiah Baranitharan NRC/Bos CC: Robert Wood , "'rem-conf'" Subject: Re: Intro & Q References: <1998Dec03.095300.1991.399158@rhino.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subbiah Baranitharan NRC/Bos wrote: > > Your comment on 2.b is not clear to me. How do we identify the channels on RTP trunking packet ? I think I understand the comment - are you (Robert) arguing for the equivalent of ATM's circuit emulation in IP? In other words, there are N 64 kbps channels. Take one byte from each every 125us, and make a packet of N bytes, and then send. There are certain cases where this does make sense, but it has the following limitations: 1. channel identification is based on positioning within the packet (ie, 3 bytes in is channel 3). Silence detection pretty much throws this for a loop. See our muxissues draft, where we discuss the use of bitmasks to indicate which packets are in silence. This approach also has implications on signaling, synchronization, and reliability. 2. With compression, the codecs generate an entire frame of data all at once, every T ms (usually T=20 or 30). By sending a byte from each in a packet, you will actually increase the latency by a factor of two (T frame delay, plus T more ms to finish sending the packet, one byte per packet) 3. You won't be able to support variable rate codecs, or use of different codecs in a multiplex. 4. The packet overhead is higher, since you have only one byte per packet from each user, as opposed to a frames worth per user. 5. Your packet rate jumps up. For 64kbps PCM, you'll have 1 packet every 125us, which is 8000 packets per second. With the kind of muxes we've been discussing, you'll have a packet every 30ms (say), which is 33 packets per second. Big difference, especially since routers are sensitive to packet rates. So, IP CES has some problems. Using a more frame/packet oriented multiplex eliminates these problems. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Dec 03 11:47:47 1998 From rem-conf-request@es.net Thu Dec 03 11:47:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlegg-0002RS-00; Thu, 3 Dec 1998 11:45:18 -0800 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlegf-0002L4-00; Thu, 3 Dec 1998 11:45:17 -0800 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id OAA03899; Thu, 3 Dec 1998 14:44:15 -0500 (EST) Received: from woodr by Software.Mitel.COM (4.1/SMI-4.0) id AA05893 for rem-conf@es.net; Thu, 3 Dec 98 14:44:14 EST Sender: woodr@Mitel.COM Message-Id: <3666EA0E.685F@mitel.com> Date: Thu, 03 Dec 1998 14:44:14 -0500 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/715) Mime-Version: 1.0 To: Jonathan Rosenberg Cc: Subbiah Baranitharan NRC/Bos , "'rem-conf'" Subject: Re: Intro & Q References: <1998Dec03.095300.1991.399158@rhino.ntc.nokia.com> <3666E534.88ABDD22@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: > > Subbiah Baranitharan NRC/Bos wrote: > > > > Your comment on 2.b is not clear to me. How do we identify the channels on RTP trunking packet ? > > I think I understand the comment - are you (Robert) arguing for the > equivalent of ATM's circuit emulation in IP? In other words, there are N > 64 kbps channels. Take one byte from each every 125us, and make a packet > of N bytes, and then send. There are certain cases where this does make > sense, but it has the following limitations: > Yes, where N may be between 32 and 256. I personally like small packets for low latency. 32 to 64 samples. > 1. channel identification is based on positioning within the packet (ie, > 3 bytes in is channel 3). I don't see this as a problem. If the trunking is static, we are always sending the same link(s) down one packet's stream. If the trunking is dynamic, the voice channel is allocated a position in the packet at call setup time. > Silence detection pretty much throws this for > a loop. There is no silence suppression or voice compression implemented. This is intended for simple, raw trunking. > See our muxissues draft, where we discuss the use of bitmasks to > indicate which packets are in silence. This approach also has > implications on signaling, synchronization, and reliability. > > 2. With compression, the codecs generate an entire frame of data all at > once, every T ms (usually T=20 or 30). By sending a byte from each in a > packet, you will actually increase the latency by a factor of two (T > frame delay, plus T more ms to finish sending the packet, one byte per > packet) The RTP packet concatenations you are considering are appropriate for this situation. > 4. The packet overhead is higher, since you have only one byte per > packet from each user, as opposed to a frames worth per user. One could put in several bytes per channel and still keep latency low. Thanks for the feedback. [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com From rem-conf Thu Dec 03 11:48:16 1998 From rem-conf-request@es.net Thu Dec 03 11:48:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlejH-0002nT-00; Thu, 3 Dec 1998 11:47:59 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlejF-0002mz-00; Thu, 3 Dec 1998 11:47:58 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Dec 1998 19:46:45 +0000 X-Mailer: exmh version 2.0.2 To: Neal Schneider cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers In-reply-to: Your message of "Thu, 03 Dec 1998 10:04:45 PST." <19981203180447.25856.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 1998 19:46:43 +0100 Message-ID: <1548.912714403@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <19981203180447.25856.qmail@hotmail.com>Neal Schneider writes: > I agree that manipulating sequence numbers (the basis for packet order, > packet loss, and timing is there is no timestamp) is a jeopardous > solution. > > In the case of multiplexing many voices, however, the benefits of > completely dropping a channel in periods of silence are not substantial. > Granted, if all voices were silent there would be an argument for > holding back packets, but one could just take that as a infrequent loss. > Could one continuously send packets with a 'comfort noise' payload > format and incremental sequence numbers during periods of silence? And > merely achieve less efficiency when there are fewer voices being > multiplexed? Yes, but consider: (a) you probably lose the b/w saving you gain from not sending timestamps or not sending sequence numbers. B/w lost between application and multiplexor. Or do you want the multiplexor to send comfort noise packets? You still have the problem that the app must send comfort noise for the multiplexor to generate packets and multiplex may have to be comfort noise codec smart. (b) you force every application to implement comfort noise generation and transmission (incompatibilities? bugs? backward compatibility?). (c) comfort noise probably wants to be sent at less frequent intervals (probably variable intervals depending on how background noise evolves). (d) not all codecs have a comfort noise scheme devised (ok there are generic schemes but you may find boundary effects at transition between codec and comfort noise). (e) apps may have problems mixing multiple comfort noise sources especially at transitions between multiple speakers. And that's before you worry about RTCP issues... - Orion. From rem-conf Thu Dec 03 11:53:36 1998 From rem-conf-request@es.net Thu Dec 03 11:53:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zleoC-0003Zc-00; Thu, 3 Dec 1998 11:53:04 -0800 Received: from wya-lfd94.hotmail.com (hotmail.com) [207.82.252.158] by mail1.es.net with smtp (Exim 1.81 #2) id 0zleoB-0003SH-00; Thu, 3 Dec 1998 11:53:03 -0800 Received: (qmail 11380 invoked by uid 0); 3 Dec 1998 19:52:02 -0000 Message-ID: <19981203195202.11379.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Thu, 03 Dec 1998 11:52:00 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, jdrosen@dnrc.bell-labs.com Cc: Jarno.Rajahalme@research.nokia.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 03 Dec 1998 11:52:00 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I wasn't intending to insert noise packets at the mux point. I figured that the source would generate these packets. Again, I believe that manipulation at the mux-demux engines should be minimal. Yes, this defeats some of the intentions of efficient silence suppression, but can't a payload format be specified (small field), in which the actual noise payload be recreated on the demux or end-point based on a a noise level negotiated out of band? Also, One might assume that bandwidth utilization would not be much of an issue from the source to the mux point, considering that multiplexing is inserted at points of aggregation. I want a 32-bit mux header which contains all the necessary information for retaining a RTP session. Non-dynamic information outside this header format would like to be negotiated out-of-band. Regards, Neal A. Schneider >In the case of mid-network multiplexing, you could try this, but I still >see problems. Firstly, the RTCP statistics will still be totally fouled >up (even worse, in fact), since the loss rates will most likely be >negative (receiver gets more than sender sends) since the mux point is >inserting these comfort noise packets. Highest SN sent statistic will >also be fouled up. Thus, adaptive schemes will still fail. Secondly, I >thought the whole point of this argument was that sending the timestamp >was too much overhead. Well, its 32 bits per user. Given a person is in >silence roughly 50% of the time, you want to send a comfort noise >filler, which is likely more than 64 bits, instead of sending nothing. I >believe you will actually end up sending more bits than if you just >leave the timestamp in place, and let it work as it was originally >designed to. > >You could have the mux point hijack the RTCP also, and then modify it on >the fly based on new statistics. But, you'll lose the end to end >statistics provided by RTCP, in addition to now requiring some really >serious processing. > >-Jonathan R. > > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Dec 03 12:40:07 1998 From rem-conf-request@es.net Thu Dec 03 12:40:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlfTO-0000Qm-00; Thu, 3 Dec 1998 12:35:38 -0800 Received: from exchange1.telescan.com [204.251.138.227] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlfTM-0000Nb-00; Thu, 3 Dec 1998 12:35:36 -0800 Received: by exchange1.telescan.com with Internet Mail Service (5.5.2232.9) id ; Thu, 3 Dec 1998 14:34:38 -0600 Message-ID: <81831E1053A2D111A03800805FEFA27D04C7AD@exchange1.telescan.com> From: Peter Cole To: rem-conf@es.net Subject: Date: Thu, 3 Dec 1998 14:34:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Thu Dec 03 13:23:38 1998 From rem-conf-request@es.net Thu Dec 03 13:23:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlgAs-0004Is-00; Thu, 3 Dec 1998 13:20:34 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zlgAq-0004Gb-00; Thu, 3 Dec 1998 13:20:32 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01762 for ; Thu, 3 Dec 1998 16:19:17 -0500 (EST) Message-Id: <199812032119.QAA01762@ietf.org> To: rem-conf@es.net Subject: 43rd IETF-ORLANDO, FL: Multicast Schedule Date: Thu, 03 Dec 1998 16:19:17 -0500 From: Marcia Beaulieu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Orlando IETF Multicast Guide (as of 12/03/98) Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the agenda at http://www.ietf.org/meetings/agenda_orlando.txt It is possible that this schedule will be modified. MULTICAST GUIDE Note that times are in Eastern Time. UTC (aka GMT) also provided. MONDAY 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1430-1630 1800-2000 2030-2230 2430-0300 =========+===========+===========+===========+===========+ CHAN 1 | idr | mobileip | pim | mboned | =========+===========+===========+===========+===========+ CHAN 2 | ruts | diffserv | diffserv | | =========+===========+===========+===========+===========+ TUESDAY 0900-1000 1015-1115 1300-1400 1415-1515 (UTC) 1400-1500 1515-1615 1800-1900 1915-2015 =========+===========+===========+===========+===========+ CHAN 1 | nfsv4 | nfsv4 | tcpsat | tcpsat | =========+===========+===========+===========+===========+ CHAN 2 | mmusic | mmusic | ngtrans | ngtrans | =========+===========+===========+===========+===========+ TUESDAY (CON'T) 1545-1645 1700-1800 (UTC) 2045-2145 2200-2300 =========+===========+===========+ CHAN 1 | mboned | mboned | =========+===========+===========+ CHAN 2 | policy | policy | =========+===========+===========+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1400-1630 1800-2000 2030-2230 2430-0300 =========+===========+===========+===========+===========+ CHAN 1 | pilc | idmr | issll | plenary | =========+===========+===========+===========+===========+ CHAN 2 | msdp | rap | tcpimpl | plenary | =========+===========+===========+===========+===========+ THURSDAY 0900-1130 1300-1500 1530-1730 (UTC) 1400-1630 1800-2000 2030-2230 =========+===========+===========+===========+ CHAN 1 | malloc | avt | iptel | =========+===========+===========+===========+ CHAN 2 | ion | rsvp | ipngwg | =========+===========+===========+===========+ FRIDAY 0900-1130 (UTC) 1400-1630 =========+===========+ CHAN 1 | avt | =========+===========+ CHAN 2 | ipngwg | =========+===========+ Each day's program may also be replayed by tape delay from: 2330 (UTC): 0430 Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf Fri Dec 04 06:44:40 1998 From rem-conf-request@es.net Fri Dec 04 06:44:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zlwFA-0005pR-00; Fri, 4 Dec 1998 06:30:04 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zlwF8-0005pH-00; Fri, 4 Dec 1998 06:30:02 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Fri Dec 4 09:28:45 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id JAA19415; Fri, 4 Dec 1998 09:28:44 -0500 (EST) Message-ID: <3667F0FB.17ADC969@dnrc.bell-labs.com> Date: Fri, 04 Dec 1998 09:26:03 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Neal Schneider CC: Jarno.Rajahalme@research.nokia.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers References: <19981203195202.11379.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Neal Schneider wrote: > > I wasn't intending to insert noise packets at the mux point. I figured > that the source would generate these packets. Again, I believe that > manipulation at the mux-demux engines should be minimal. Yes, this > defeats some of the intentions of efficient silence suppression, but > can't a payload format be specified (small field), in which the actual > noise payload be recreated on the demux or end-point based on a a noise > level negotiated out of band? Well, this would then require the end systems to know about the mux. > > Also, One might assume that bandwidth utilization would not be much of > an issue from the source to the mux point, considering that multiplexing > is inserted at points of aggregation. I'm not so sure how often this assumption is true. It seems to me that access bandwidth is quite frequently what is at a premium. In this case, the utilization of the access links to the gateways may be important. In any case, it still seems easier and less expensive to just send the timestamp as currently defined. > > I want a 32-bit mux header which contains all the necessary information > for retaining a RTP session. Non-dynamic information outside this > header format would like to be negotiated out-of-band. For mid-network mux, I don't see how this is possible. In my mind, the model is that of gateways from many different providers/domains, feeding packets into the mux. There is no special signaling between the gateways and mux, or mux and demux points. The gateways an muxes will need to be configured with each others addresses. The gateways will also need to know which mux to send packets to for a given destination IP address. One could design protocols to automate this, but then we'd be talking about RTP routing protocols. If this model is not what you have in mind, please say so. Anyway, in this model, there is no correlation between the field values in the headers across packets being muxed. How, then, can you expect to compress to 32 bits per mux packet, and still retain all of the information? Perhaps you are suggesting to modify everything - rewrite timestamps, SN's, etc. to force them to be correlated? Sort of a man-in-the-middle attack kind of thing. Even in such a scenario, its not clear how much you will be able to change, and what the impacts will be on existing gateways. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Dec 04 10:53:19 1998 From rem-conf-request@es.net Fri Dec 04 10:53:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zm0Dz-0000Xi-00; Fri, 4 Dec 1998 10:45:07 -0800 Received: from wya-lfd37.hotmail.com (hotmail.com) [207.82.252.101] by mail1.es.net with smtp (Exim 1.81 #2) id 0zm0Dy-0000Wo-00; Fri, 4 Dec 1998 10:45:06 -0800 Received: (qmail 11189 invoked by uid 0); 4 Dec 1998 18:44:05 -0000 Message-ID: <19981204184405.11188.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Fri, 04 Dec 1998 10:44:04 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Fri, 04 Dec 1998 10:44:04 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> J Rosenberg: >> in which the actual >> noise payload be recreated on the demux or end-point based on a a noise >> level negotiated out of band? > >Well, this would then require the end systems to know about the mux. > I am not sure if I follow. Isn't there a standard comfort noise level payload format for the RTP? As long as the demux engine can recreate a compatible RTP packet (retaining required information), then the multiplexing should be transparent to the end user. >> >> Also, One might assume that bandwidth utilization would not be much of >> an issue from the source to the mux point, considering that multiplexing >> is inserted at points of aggregation. > >I'm not so sure how often this assumption is true. It seems to me that >access bandwidth is quite frequently what is at a premium. In this case, >the utilization of the access links to the gateways may be important. In >any case, it still seems easier and less expensive to just send the >timestamp as currently defined. > Service Access Points are most certainly bandwidth bottlenecks. That is why you must multiplex at these points (trunk interfaces, etc.) About the timestamps, please help me understand what the issues are with this philosophy: Forget about dropping packets during silence for a minute, let's assume that can be dealt with in other ways. If the sampling rate and generation of source RTP packets is at a _constant_ timing interval (same bitrate unless negotiated out of band), can not all the information necessary for performing all RTCP, jitter, and FEC calculations be performed correctly using solely the sequence numbers. I know I'm beating this issue into the ground, I just want to make certain that timestamps are necessary. >For mid-network mux, I don't see how this is possible. In my mind, the >model is that of gateways from many different providers/domains, feeding >packets into the mux. There is no special signaling between the gateways >and mux, or mux and demux points. The gateways an muxes will need to I believe that MGCP begins to define inter-gateway signaling in this manner. be >configured with each others addresses. The gateways will also need to >know which mux to send packets to for a given destination IP address. >One could design protocols to automate this, but then we'd be talking >about RTP routing protocols. If this model is not what you have in mind, >please say so. > An RTP routing protocol sounds like a good idea. >Anyway, in this model, there is no correlation between the field values >in the headers across packets being muxed. How, then, can you expect to This is true. In this model, there is no need for the RTP header, merely RTP muxed headers. The timestamps/sequence numbers have no correlation whatsoever, so why retain an overall header for the group. >compress to 32 bits per mux packet, and still retain all of the >information? Perhaps you are suggesting to modify everything - rewrite >timestamps, SN's, etc. to force them to be correlated? Sort of a >man-in-the-middle attack kind of thing. Even in such a scenario, its not >clear how much you will be able to change, and what the impacts will be >on existing gateways. I don't want to force any correlation. I just want optimize a header format for a specific application of the RTP. Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri Dec 04 10:56:37 1998 From rem-conf-request@es.net Fri Dec 04 10:56:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zm0N1-0000ek-00; Fri, 4 Dec 1998 10:54:27 -0800 Received: from alpha.xerox.com [13.1.64.93] (firewall-user) by mail1.es.net with smtp (Exim 1.81 #2) id 0zm0My-0000eZ-00; Fri, 4 Dec 1998 10:54:26 -0800 Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <54919(2)>; Fri, 4 Dec 1998 10:54:15 PST Received: (from fenner@localhost) by mango.parc.xerox.com (8.8.8/8.8.8) id KAA06302; Fri, 4 Dec 1998 10:54:11 -0800 (PST) (envelope-from fenner) Date: Fri, 4 Dec 1998 10:54:11 PST From: Bill Fenner Message-Id: <199812041854.KAA06302@mango.parc.xerox.com> To: fenner@parc.xerox.com Subject: Announcing mtrace 5.2 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There aren't any spectacular new features; lots of bug fixes and some fairly minor changes. The most interesting fixes/features are: - No more "Unknown protocol 8"! - No more defaulting to 224.2.0.1; the default group is now 0.0.0.0 . Older versions of IOS can't handle this default so you may have to specify a group if you see a "No route" from an older IOS router in the middle of the path. The README is attached. Bill $Id: README.mtrace,v 5.2 1998/12/04 05:04:15 fenner Exp $ Multicast Traceroute Release 5.2 December 3, 1998 available from ftp.parc.xerox.com, file pub/net-research/ipmulti/mtrace-5.2.tar.gz binaries pub/net-research/ipmulti/mtrace-5.2-sparc-sunos41x.tar.gz pub/net-research/ipmulti/mtrace-5.2-sparc-solaris2.tar.gz pub/net-research/ipmulti/mtrace-5.2-alpha-osf1.tar.gz pub/net-research/ipmulti/mtrace-5.2-sgi-irix.tar.gz pub/net-research/ipmulti/mtrace-5.2-i386-freebsd.tar.gz The 5.2 release fixes the following bugs: o 100% loss was reported as "?/nn = --"; switch it back to 100% o TTL calculation didn't handle IOS's claim that packets with TTL 0 would be forwarded. o Part of the byte-swapping heuristic was removed; it caused more problems than it solved. o Hop names are now printed correctly in passive mode o The interface list is properly retrieved from the kernel; selecting an interface now works correctly on multi-homed 4.3-Tahoe-and-later hosts. It properly skips down interfaces, thanks to John Kay, and stops when it finds the right interface, thanks to Mark Foster. o mtrace no longer depends on trying to figure out how the compiler is going to pack an 8-bit and 24-bit integer into a 32-bit value and instead explicitly extracts the values from a 32-bit value (tr_rttlqid). o passive mtrace joins the group on the interface specified with -i and now always prints * * * for the query source since it's unknown (thanks to Dave Thaler) The 5.2 release has the following new features: o New option -L to only print stats when loss is greater than n% o New option -f to start a hop-by-hop trace at hop n o Workaround for IOS bug CSCdi68628 which causes incorrect routers to reply to 3rd-party mtrace requests o Options RAW_INPUT_IS_RAW and RAW_OUTPUT_IS_RAW for compilation on Linux and OpenBSD o New routing protocol codes o Passive mode now ignores most duplicate responses (instead of treating them as individual responses and printing out multiple stats runs at once) o Workaround for some routers returning integer seconds instead of in units of 1/65535th as the spec says o The default group of 224.2.0.1 has been removed; the default is now a "weak" mtrace (i.e. group 0.0.0.0). This can cause problems with older versions of IOS; if you see "No route" where it doesn't seem to make sense, try the trace again specifying a group. From rem-conf Fri Dec 04 11:25:13 1998 From rem-conf-request@es.net Fri Dec 04 11:25:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zm0nu-0001z0-00; Fri, 4 Dec 1998 11:22:14 -0800 Received: from dfw-ix1.ix.netcom.com [206.214.98.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zm0nr-0001vC-00; Fri, 4 Dec 1998 11:22:11 -0800 Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id NAA16697; Fri, 4 Dec 1998 13:21:07 -0600 (CST) From: amilk@ix.netcom.com Received: from hac-nj6-07.ix.netcom.com(206.214.115.135) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma016611; Fri Dec 4 13:20:39 1998 Message-ID: <36685DB2.6A8E@ix.netcom.com> Date: Fri, 04 Dec 1998 14:09:54 -0800 X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net CC: amilk@ix.netcom.com Subject: remove Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Fri Dec 04 23:33:14 1998 From rem-conf-request@es.net Fri Dec 04 23:33:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmCA9-0000Ku-00; Fri, 4 Dec 1998 23:29:57 -0800 Received: from crilling.telmex.net.mx [200.33.150.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zmCA7-0000In-00; Fri, 4 Dec 1998 23:29:55 -0800 Received: from sergio ("port 2084"@[200.38.203.92]) by sims01.telmex.net.mx (Sun Internet Mail Server sims.3.5.1998.09.21.23.34) with SMTP id <0F3G00FIPSPCSM@sims01.telmex.net.mx> for rem-conf@es.net; Fri, 4 Dec 1998 17:46:26 -0600 (CST) Date: Fri, 04 Dec 1998 17:42:54 -0600 From: "Dr. Sergio Martinez Arrieta" Subject: X-Sender: marrieta@nl1.telmex.net.mx To: rem-conf@es.net Message-id: <1.5.4.32.19981204234254.006ee75c@nl1.telmex.net.mx> MIME-version: 1.0 X-Mailer: Windows Eudora Light Version 1.5.4 (32) Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Sat Dec 05 06:57:30 1998 From rem-conf-request@es.net Sat Dec 05 06:57:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmJ2b-0003SW-00; Sat, 5 Dec 1998 06:50:37 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zmJ2a-0003R9-00; Sat, 5 Dec 1998 06:50:36 -0800 Received: from rtp-dial-1-27.cisco.com (rtp-dial-1-27.cisco.com [171.70.158.27]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA27666; Sat, 5 Dec 1998 06:49:27 -0800 (PST) Date: Sat, 5 Dec 1998 06:49:01 -0800 (Pacific Standard Time) From: Stephen Casner To: Neal Schneider cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers In-Reply-To: <19981204184405.11188.qmail@hotmail.com> Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 4 Dec 1998, Neal Schneider wrote: > > Forget about dropping packets during silence for a minute, let's assume > that can be dealt with in other ways. If the sampling rate and > generation of source RTP packets is at a _constant_ timing interval > (same bitrate unless negotiated out of band), can not all the > information necessary for performing all RTCP, jitter, and FEC > calculations be performed correctly using solely the sequence numbers. I > know I'm beating this issue into the ground, I just want to make certain > that timestamps are necessary. Stop! I can't take it anymore! Yes, you are right, if the duration of each packet is the same and a packet is sent in every interval, then the sequence number and timestamp are linearly related (given modulo arithmetic). If you don't maintain state between the two ends to allow reconstruction of the timestamp to the same value as went in, then it won't be possible to use the RTCP synchronization mechanisms to sync two streams, say audio and video, together. But you probably don't want to send RTCP at all anyway because that's just going to waste more bandwidth. It's not a big surprise that if you discard many of the assumptions underlying the design of RTP that it no longer seems like a good fit. What you really want is a circuit-switched TDM hierarchy, and guess what, it's already available! > An RTP routing protocol sounds like a good idea. No, it is a TERRIBLE idea! Why should we redesign and reconstruct at the application level all of what has been built at the IP layer over many years? It seems to me that you are missing the whole idea of packet switching. It allows traffic to be bursty without wasting channel bandwidth. Voice is one example of bursty traffic, often estimated as 40% of the (full duplex) channel bandwidth utilization. The use of silence suppression is how we get back the efficiency to offset the header overhead. And packet switching provides the straightforward multiplexing of all kinds of traffic at significantly different rates without having to construct separate mechanisms for each kind of traffic. In the not-to-distant future when the voice traffic is just a blip next to the data traffic, none of this standing on one's head (e.g. multiplexing and routing at the application level) is going to matter. One can only hope that we haven't cemented in place too much crap during the transition. -- Steve From rem-conf Sun Dec 06 03:03:14 1998 From rem-conf-request@es.net Sun Dec 06 03:03:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmbmf-0003D2-00; Sun, 6 Dec 1998 02:51:25 -0800 Received: from alpha1.eun.eg (alpha1-eng.cairo.eun.eg) [193.227.10.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zmbma-0003Cs-00; Sun, 6 Dec 1998 02:51:21 -0800 Received: from localhost by alpha1-eng.cairo.eun.eg; (5.65v3.2/1.1.8.2/06May97-1246PM) id AA04562; Sun, 6 Dec 1998 12:30:46 +0200 Date: Sun, 6 Dec 1998 12:30:46 +0200 (EET) From: Khaled Elsayed Reply-To: Khaled Elsayed To: tccc@ieee.org, a.jajszczyk@ieee.org, Laurent Toutain Cc: atm97authors@inesc.pt, atm96@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, xtp-relay@cs.concordia.ca, end2end-interest@isi.edu, enternet@bbn.com, hipparch@sophia.inria.fr, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, atm@sun.com Subject: Call for Papers and Reviewers: IEEE Comm. Magazine In-Reply-To: <199812021624.RAA04156@pacman> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry if you get multiple copies. Please distribute to your colleagues. Thanks, Khaled -- Dr. Khaled Fuad Elsayed Department of Electronics and Communications Engineering Faculty of Engineering, Cairo University Giza, Egypt 12613 E-mail: khaled@ieee.org Fax: +202-572-3486 Phone: +202-567-8850 ----------------------------- Cut Here ---------------------------------- Call for Papers and Reviewers IEEE Communications Magazine Internet Technology Series Series Editors: Laurent Toutain (ENST Bretagne) and Khaled Elsayed (Cairo University) The IEEE Communications Magazine invites contributions from authors with academic and industrial affiliation for the Internet Technology Series. The Focus of the Internet Technology Series is to bring the latest advances in state of the art techniques in the Internet to the large readers group of the Communications Magazine. Preference will be given to papers addressing technical issues that are encountered in implementing current or future Internet products or solutions. We are currently looking for articles in the following areas: - Managing the flows and QoS support in the Internet - Web Caching - Terabit Routing - Internet Telephony and VOIP Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Also check: http://207.127.135.8/ci1 (author guidelines) and http://207.127.135.8/ci1/public/1998/may/cimess.html Since this is an Internet related series, we would like to handle all the submissions and the reviewing process via the Internet. Send your submission in postscript or PDF (acrobat) format to the series editors. Khaled Elsayed: Khaled@ieee.org Laurent Toutain: Laurent.Toutain@enst-bretagne.fr In the mean time we would to ask for the help in evaluating the submitted articles. If you are willing to provide high-quality timely reviews, kindly send your name, affiliation, e-mail, fax, mailing address and research interests to both the series editors. Reviewers will be acknowledged by listing their names in the December issue (starting 1999) and the IEEE Communications Magazine Home Page. Please note that we intend to handle the whole review process electronically so you need to be able to handle postscript and pdf e-mail attachments. From rem-conf Sun Dec 06 03:58:51 1998 From rem-conf-request@es.net Sun Dec 06 03:58:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmcnq-00048M-00; Sun, 6 Dec 1998 03:56:42 -0800 Received: from sun4000.casema.net (smtp1.casema.net) [195.96.96.97] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zmcnn-00048C-00; Sun, 6 Dec 1998 03:56:40 -0800 Received: from casema.net (3dyn97.breda.casema.net [195.96.110.97]) by smtp1.casema.net (8.9.1/CASEMA) with ESMTP id MAA21609 for ; Sun, 6 Dec 1998 12:55:58 +0100 (MET) Posted-Date: Sun, 6 Dec 1998 12:55:58 +0100 (MET) Message-ID: <366A7111.A1E4F1DC@casema.net> Date: Sun, 06 Dec 1998 12:57:05 +0100 From: witte X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: nl,en,zh-TW,zh-CN,ja MIME-Version: 1.0 To: rem-conf@es.net Subject: REMOVE Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Sun Dec 06 18:17:51 1998 From rem-conf-request@es.net Sun Dec 06 18:17:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmq4W-0001l7-00; Sun, 6 Dec 1998 18:06:48 -0800 Received: from (server1.car-pi.es) [195.76.38.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zmq4U-0001kx-00; Sun, 6 Dec 1998 18:06:46 -0800 Received: from d48-xa101h1-toro-pdi.attcanada.net by server1.car-pi.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id YJM05LQW; Mon, 7 Dec 1998 02:29:32 +0100 To: uyh5@aol.com Bcc: reluctantl@hotmail.com, reluctg@pcfastnet.com, relumined@semiflexed.com, relwell@ix.netcom.com, relwood@dechert.com, rely@ix.netcom.com, relysis@deltanet.com, rem-conf@es.net, rem.raives@cc.jyu.fi, rem1@ix.netcom.com From: Subject: hello content-length: 699 Message-Id: Date: Sun, 6 Dec 1998 18:06:46 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 From rem-conf Mon Dec 07 01:04:44 1998 From rem-conf-request@es.net Mon Dec 07 01:04:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zmwVV-0005Ag-00; Mon, 7 Dec 1998 00:59:05 -0800 Received: from igcb.igc.apc.org (igcb.igc.org) [192.82.108.46] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zmwVU-0005AW-00; Mon, 7 Dec 1998 00:59:04 -0800 Received: from igce.igc.org (igce.igc.org [192.82.108.49]) by igcb.igc.org (8.8.8/8.8.8) with ESMTP id AAA26294; Mon, 7 Dec 1998 00:58:32 -0800 (PST) Received: from econet.org (PPPa33-ResaleSantaCruz1-5R1017.saturn.bbn.com [4.16.34.236]) by igce.igc.org (8.9.1/8.9.1) with ESMTP id AAA20139; Mon, 7 Dec 1998 00:58:07 -0800 (PST) Message-ID: <366B9946.48F42FB0@econet.org> Date: Mon, 07 Dec 1998 01:00:54 -0800 From: Ron Swenson Reply-To: ecosystems@econet.org Organization: EcoSystems X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: remove References: <36685DB2.6A8E@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove Sorry to bug everyon. I tried to cancel the standard way twice and it didn't work for me. It's been interesting reviewing what you all are doing. Keep up the good work! Ron Swenson From rem-conf Mon Dec 07 07:09:24 1998 From rem-conf-request@es.net Mon Dec 07 07:09:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zn2AK-0000FN-00; Mon, 7 Dec 1998 07:01:36 -0800 Received: from blanc.cisco.com [161.44.2.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zn2AI-0000F5-00; Mon, 7 Dec 1998 07:01:34 -0800 Received: from cisco.com (localhost [127.0.0.1]) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA01330 for ; Mon, 7 Dec 1998 09:59:33 -0500 (EST) Sender: nsraju@cisco.com Message-ID: <366BED55.64BCC6DD@cisco.com> Date: Mon, 07 Dec 1998 09:59:33 -0500 From: Raju Nadimpalli Organization: Cisco Systems Inc X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SUBSCRIBE From rem-conf Mon Dec 07 09:39:12 1998 From rem-conf-request@es.net Mon Dec 07 09:39:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zn4Wy-0002XL-00; Mon, 7 Dec 1998 09:33:08 -0800 Received: from mumble.cs.rpi.edu (cs.rpi.edu) [128.213.8.16] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zn4Ww-0002XA-00; Mon, 7 Dec 1998 09:33:07 -0800 Received: from ephraim.cs.rpi.edu (glinert@ephraim.cs.rpi.edu [128.213.8.39]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id MAA26407; Mon, 7 Dec 1998 12:32:32 -0500 (EST) From: "Ephraim P. Glinert" Received: (from glinert@localhost) by ephraim.cs.rpi.edu (8.9.1/8.9.1) id MAA04412; Mon, 7 Dec 1998 12:32:29 -0500 (EST) Date: Mon, 7 Dec 1998 12:32:29 -0500 (EST) Message-Id: <199812071732.MAA04412@ephraim.cs.rpi.edu> To: end2end-interest@isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: New NSF Research Focus X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks: I would like to draw your attention to a new research focus on the topic of UNIVERSAL ACCESS jointly sponsored by the HCI and KCS programs within the Information and Intelligent Systems (IIS) Division of CISE. The word "access" implies the ability to find, manipulate and use information in an efficient and comprehensive manner. A primary objective of the HCI/KCS research focus on universal access is to empower people with disabilities so that they are able to participate as first class citizens in the emerging information society. But more than that, the research focus will benefit the nation as a whole, by advancing computer technology so that all people can possess the skills needed to fully harness the power of computing to enrich and make their lives more productive within a tightly knit "national family" whose members communicate naturally and painlessly through the sharing of (multimodal) information. For more information, please point your web browser at http://www.cise.nsf.gov/iis/index.html then click on "IIS Programs" and from there go to either the HCI or KCS page, where you will find a link to Universal Access. Please feel free to contact me with any questions! =============================================================== Ephraim P. Glinert, Program Director Knowledge and Cognitive Systems / HCI / Universal Access Division of Information and Intelligent Systems National Science Foundation 4201 Wilson Blvd., Suite 1115 Arlington, VA 22230 Phone: (703) 306 1926 Fax: (703) 306 0599 E-mail: eglinert@nsf.gov =============================================================== From rem-conf Mon Dec 07 10:49:32 1998 From rem-conf-request@es.net Mon Dec 07 10:49:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zn5e7-0003yC-00; Mon, 7 Dec 1998 10:44:35 -0800 Received: from wya-lfd84.hotmail.com (hotmail.com) [207.82.252.148] by mail1.es.net with smtp (Exim 1.81 #2) id 0zn5e6-0003xh-00; Mon, 7 Dec 1998 10:44:34 -0800 Received: (qmail 3678 invoked by uid 0); 7 Dec 1998 18:43:33 -0000 Message-ID: <19981207184333.3677.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 07 Dec 1998 10:43:32 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, casner@cisco.com Cc: rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 07 Dec 1998 10:43:32 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >It's not a big surprise that if you discard many of the assumptions >underlying the design of RTP that it no longer seems like a good fit. >What you really want is a circuit-switched TDM hierarchy, and guess >what, it's already available! > For convergence purposes, I am just saying is that RTP could be better tailored to handle voice. >> An RTP routing protocol sounds like a good idea. > >No, it is a TERRIBLE idea! Why should we redesign and reconstruct at >the application level all of what has been built at the IP layer over >many years? > Point well taken. If voice is to be treated the same as all other data on the network, there is no reason to supersede layer 3 routing. My point being, once a call is set up there is consistent bursts of packets for a relatively long connection period. Setting up virtual paths for these sessions does not seem totally out the question. >In the not-to-distant future when the voice traffic is just a blip >next to the data traffic, none of this standing on one's head >(e.g. multiplexing and routing at the application level) is going to >matter. One can only hope that we haven't cemented in place too much >crap during the transition. > -- Steve 64kbps is comparatively even by today's standards. Bandwidth will continue to be less and less of an issue, but consider the case of a network service provider who is now handling all of the voice traffic for the area. You don't think that higher efficiency matters? You think Cellular Phone services today aren't standing on their heads to find a more efficient means? Forget bandwidth. There has to be necessary means to reduce latency for voice to sound decent. Granted, some of that will come from routing priorities, increased bandwidth, etc, but there has to be additional methods taken at the application/gateways in terms of sampling sizes, buffering, header manipulation, etc, to make a significant reduction. A latency across the country of 30 ms doesn't mean much when there is 150 ms added from the application, buffering, etc, for voice in order to force some efficiency in the current RTP structure. Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Mon Dec 07 12:22:48 1998 From rem-conf-request@es.net Mon Dec 07 12:22:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zn77O-0005nb-00; Mon, 7 Dec 1998 12:18:54 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zn77N-0005mx-00; Mon, 7 Dec 1998 12:18:53 -0800 Received: from localhost (casner@localhost) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA11042; Mon, 7 Dec 1998 12:17:50 -0800 (PST) Date: Mon, 7 Dec 1998 12:17:50 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Revised AVT agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To accommodate the shift of AVT's second session to Friday morning, we've rearranged the agenda a bit because there were conflicts with the MEGACO BOF. The revised agenda follows. -- Steve & Colin Audio/Video Transport WG A G E N D A Thursday, December 10 at 1300-1500 ================================== - Introduction 5 - Documents published since last meeting RFC2429 - H.263+ payload format RFC2431 - BT.656 payload format RFC2435 - JPEG video payload format RFC2448 - AT&T's Error Resilient Video Transmission Technique - Transport of DTMF tones (Petrack) 20 draft-ietf-avt-tones-00.txt draft-ietf-avt-dtmf-01.txt - RTP multiplexing proposals draft-ietf-avt-muxissues-00.txt (Rosenberg) 15 draft-ietf-avt-mux-rtp-00.txt (Subbiah) 10 draft-tanigawa-rtp-multiplex-01.txt (Hoshi) 5 draft-ietf-avt-germ-00.txt (Handley) 5 Discussion 20 - Transport of MPEG4 streams (Civanlar) 20 - Generic payload format draft-guillemot-genrtp-00.txt (Guillemot) 20 Friday, December 11 at 0900-1130 ================================ - Update to RTP draft-ietf-avt-rtp-new-02.txt, .ps (Casner) 10 draft-ietf-avt-rtpsample-01.txt (Rosenberg) 5 draft-parnes-rtp-sdes-00.txt (Casner) 5 - Update to RTP audio/video profile draft-ietf-avt-profile-new-04.txt, .ps (Casner) 20 - Documents to act upon draft-ietf-avt-crtp-05.txt draft-ietf-avt-rtp-mib-02.txt (Baugher) 10 draft-ietf-avt-rtp-format-guidelines-01.txt (Handley) 5 - Payload formats for loss tolerant media draft-ietf-avt-fec-04.txt (Rosenberg) 5 draft-ietf-avt-reedsolomon-00.txt (Rosenberg) 5 draft-ietf-avt-interleaving-00.txt (Perkins) 5 - RTP Payload Format for PureVoice(tm) Audio draft-mckay-qcelp-01.txt - Charter update (Perkins) 15 From rem-conf Mon Dec 07 16:32:54 1998 From rem-conf-request@es.net Mon Dec 07 16:32:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znAyc-0001GO-00; Mon, 7 Dec 1998 16:26:06 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0znAya-0001GE-00; Mon, 7 Dec 1998 16:26:04 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Dec 1998 00:25:40 +0000 To: Neal Schneider cc: casner@cisco.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers In-reply-to: Your message of "Mon, 07 Dec 1998 10:43:32 PST." <19981207184333.3677.qmail@hotmail.com> Date: Tue, 08 Dec 1998 00:25:37 +0100 Message-ID: <9851.913076737@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Neal Schneider writes: >64kbps is comparatively even by today's standards. Bandwidth will >continue to be less and less of an issue, but consider the case of a >network service provider who is now handling all of the voice traffic >for the area. You don't think that higher efficiency matters? You >think Cellular Phone services today aren't standing on their heads to >find a more efficient means? > >Forget bandwidth. There has to be necessary means to reduce latency for >voice to sound decent. Granted, some of that will come from routing >priorities, increased bandwidth, etc, but there has to be additional >methods taken at the application/gateways in terms of sampling sizes, >buffering, header manipulation, etc, to make a significant reduction. >A latency across the country of 30 ms doesn't mean much when there is >150 ms added from the application, buffering, etc, for voice in order to >force some efficiency in the current RTP structure. But the 150ms latency at the application comes from the requirement to smooth jitter introduced by the network, not because of the overhead of RTP. If you have a quality IP network, the application will adapt its playout buffers to be small, and one can achieve very low latencies. There are issues with low-efficiency when sending many RTP streams, but I don't believe that these contribute to latency (in fact multiplexing to increase efficiency is likely to _increase_ both latency and jitter). -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: +44 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Mon Dec 07 17:06:50 1998 From rem-conf-request@es.net Mon Dec 07 17:06:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znBZD-0001zP-00; Mon, 7 Dec 1998 17:03:55 -0800 Received: from wya-lfd89.hotmail.com (hotmail.com) [207.82.252.153] by mail1.es.net with smtp (Exim 1.81 #2) id 0znBZC-0001z4-00; Mon, 7 Dec 1998 17:03:54 -0800 Received: (qmail 25799 invoked by uid 0); 8 Dec 1998 01:02:27 -0000 Message-ID: <19981208010227.25798.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 07 Dec 1998 17:02:27 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, C.Perkins@cs.ucl.ac.uk Cc: casner@cisco.com, rem-conf@es.net Subject: Re: RTP Multiplexing and Sequence Numbers MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 07 Dec 1998 17:02:27 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >-- >Colin Perkins > >But the 150ms latency at the application comes from the requirement to >smooth jitter introduced by the network, not because of the overhead of >RTP. If you have a quality IP network, the application will adapt its >playout buffers to be small, and one can achieve very low latencies. > >There are issues with low-efficiency when sending many RTP streams, but I >don't believe that these contribute to latency (in fact multiplexing to >increase efficiency is likely to _increase_ both latency and jitter). > Adaptive Jitter buffers are important in reducing latency. Jitter will become less of an issue when the internet is better adapted for real-time traffic (i.e. "better than best effort" service), and is less of an issue today with intranets, controlled networks. The latencies which one cannot avoid with gateways are algorithmic and packetization delays. Granted if one really wants compression, the algorithmic delay is unavoidable, but in the case of uncompressed G.711, the packetization delay can be substantially reduced. If one were to send 4ms samples of PCM, instead of the typical 30ms sample size, the latency would automatically drop substantially. Unfortunately, header overhead becomes a large problem with small sample sizes therefore this approach is not taken. But given a standard, powerful multiplexing scheme, small sample sizes may become a reality, decreasing the end-to-end delay. Regards, Neal A. Schneider >But the 150ms latency at the application comes from the requirement to >smooth jitter introduced by the network, not because of the overhead of >RTP. If you have a quality IP network, the application will adapt its >playout buffers to be small, and one can achieve very low latencies. > >There are issues with low-efficiency when sending many RTP streams, but I >don't believe that these contribute to latency (in fact multiplexing to >increase efficiency is likely to _increase_ both latency and jitter). > >-- >Colin Perkins Email: c.perkins@cs.ucl.ac.uk >Department of Computer Science Phone: +44 171 419 3666 >University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Tue Dec 08 02:49:56 1998 From rem-conf-request@es.net Tue Dec 08 02:49:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znKY7-0007CN-00; Tue, 8 Dec 1998 02:39:23 -0800 Received: from f74.hotmail.com (hotmail.com) [207.82.250.180] by mail1.es.net with smtp (Exim 1.81 #2) id 0znKY5-0007Bv-00; Tue, 8 Dec 1998 02:39:21 -0800 Received: (qmail 6676 invoked by uid 0); 8 Dec 1998 10:38:20 -0000 Message-ID: <19981208103820.6675.qmail@hotmail.com> Received: from 158.140.148.64 by www.hotmail.com with HTTP; Tue, 08 Dec 1998 02:38:19 PST X-Originating-IP: [158.140.148.64] From: "Nitin Nanda" To: rem-conf@es.net Subject: remove MIME-Version: 1.0 Content-Type: text/plain Date: Tue, 08 Dec 1998 02:38:19 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Tue Dec 08 12:57:02 1998 From rem-conf-request@es.net Tue Dec 08 12:57:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znU23-0005Ho-00; Tue, 8 Dec 1998 12:46:55 -0800 Received: from usr51-dialup24.mix1.willowsprings.cw.net (Post Office Mail) [166.55.47.152] by mail1.es.net with smtp (Exim 1.81 #2) id 0znU21-0005Hd-00; Tue, 8 Dec 1998 12:46:54 -0800 From: Increase Your Traffic In 72 Hours! To: Message-Id: <419.436138.15095729hitechmail@usa.net> Subject: FREE Bulk E-Mail Software Today! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 8 Dec 1998 12:46:54 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list //// Supercharge your computer with Desktop Server 98 //// * * * Removal instructions below: * * * Get $249 Worth of FREE Bulk Email Software Today! Pardon me for the intrusion. Did you know that Desktop Server 98 is the exact same bulk email software all the big advertising companies use? Including Myself! It's the simplest bulk email software in the world. We can also do your bulk emailing for you: 500 - 100,000 Targeted addresses weekly If you visit our website today you will receive our email collector called Atomic Harvester" and "List Manager" software FREE. For more information please respond below with the words "More Info" in the subject line. mailto:postofficemail@bigfoot.com Sincerely, Loretta Hartgrove 1(888)240-4503 Hitech Marketing Techniques 1007 Parkview Ave Youngstown, Ohio 44511 mailto:postofficemail@bigfoot.com ================================================================= Our team promotes professional and responsible use of direct email marketing in compliance of the new email bill: SECTION (a) (2) (C) of S. 1618 http://www.senate.gov/~murkowski/commercialemail/EMailAmendText.html ================================================================== If you wish to remove from all future mailings please respond with the words "Remove" in the subject line. mailto:hitechmail@usa.net From rem-conf Tue Dec 08 18:48:15 1998 From rem-conf-request@es.net Tue Dec 08 18:48:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znZZR-000199-00; Tue, 8 Dec 1998 18:41:45 -0800 Received: from sgi3974ef1.iddeo.es (smtp1.retemail.es) [62.81.31.132] by mail1.es.net with esmtp (Exim 1.81 #2) id 0znZZQ-00018z-00; Tue, 8 Dec 1998 18:41:44 -0800 Received: from smtp.iddeo.es ([62.81.90.51]) by smtp1.retemail.es (InterMail v4.00.03.01 201-229-104-101) with SMTP id <19981209024453.BZGB20035.smtp1@smtp.iddeo.es>; Wed, 9 Dec 1998 03:44:53 +0100 From: Viagra To: Lista de destinatarios oculta Date: Wed, 09 Dec 1998 02:57:20 +0100 Subject: OFERTA LIMITADA X-Mailer: MultiMailer MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <19981209024453.BZGB20035.smtp1@smtp.iddeo.es> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ahora Viagra a un precio especial, solo 1900 Pesetas / Dosis. Este precio incluye gastos de envio y receta. Haga su pedido ahora en la siguiente direccion: http://www.e-art.net/viagra E-Mail : viagra@e-art.net From rem-conf Tue Dec 08 21:28:13 1998 From rem-conf-request@es.net Tue Dec 08 21:28:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0znc7g-0002vV-00; Tue, 8 Dec 1998 21:25:16 -0800 Received: from anchor.cs.colorado.edu [128.138.242.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0znc7e-0002v3-00; Tue, 8 Dec 1998 21:25:14 -0800 Received: (from evi@localhost) by anchor.cs.colorado.edu (8.9.1a/8.9.1) id WAA25136; Tue, 8 Dec 1998 22:24:12 -0700 (MST) Date: Tue, 8 Dec 1998 22:24:12 -0700 (MST) From: Evi Nemeth Message-Id: <199812090524.WAA25136@anchor.cs.colorado.edu> To: rem-conf@es.net Subject: USENIX LISA Conference Broadcast Cc: evi@anchor.cs.colorado.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list the usenix lisa (system administration) conference in boston this week, 9:00am wednesday dec 9 thru 5:00pm friday dec 11, will broadcast selected sessions. the aproximate program follows: 9:00am wed, dec 9 keynote, eric allman, sendmail inc. 11:00 security session, 3 papers 2:00pm scaling a network, brent chapman, covad comm. 4:00pm storage performance, 3 papers 9:00am thurs, dec 10 an adult web site, dan klein, cybertainment 2:00pm mailer wars (sendmail, qmail, exim) 4:00pm sysadmin certification debate 9:00am friday, dec 11 LISA/NT conference overview 11:00am new thoughts and evolution, 3 papers 2:00pm palm pilot magic, barb dijker, labyrinth 4:00pm LISA quiz show closing session, rob kolstad -evi From rem-conf Thu Dec 10 05:11:59 1998 From rem-conf-request@es.net Thu Dec 10 05:11:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zo5bc-00017B-00; Thu, 10 Dec 1998 04:54:08 -0800 Received: from mail.point.gehe.de (mail.gehe.de) [195.125.116.67] by mail1.es.net with smtp (Exim 1.81 #2) id 0zo5bY-00016I-00; Thu, 10 Dec 1998 04:54:04 -0800 Received: from c2I9EA17w by mail.gehe.de with SMTP (SMI-8.6/GEN-1.2.12) via EUnet for worldnet.att.net. id NAA21268; Thu, 10 Dec 1998 13:57:19 +0100 DATE: 10 Dec 98 3:43:09 AM FROM: kgl204123@netscape.net Message-ID: SUBJECT: Maximize Your Website's Traffic. Increase Your Search Engine Rank! Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Maximize Your Website's Traffic. Increase Your Search Engine Rank! If your Web site isn't getting the traffic it should, it's likely that it's not ranked well on the major Internet search engines. According to recent Internet E-commerce studies, over 90% of consumers find the Web sites they visit by using "The Big Eight" search engines, which are Yahoo!, Excite, AltaVista, Infoseek, Lycos, Web Crawler, HotBot, and Northern Light. If your website isn't located in the Top-30 listings of these engines, chances are your site will never be seen. The single most important thing you can do to increase your Web site's traffic is to increase your search engine ranking. ------------- "PUT YOUR NAME IN LIGHTS -- List your business with search engines to make sure potential customers can find it." -- BIZ Excite, PC Computing magazine, November 1998 ------------- THE BASICS: HOW SEARCH ENGINES RANK YOUR SITE When you submit your website to a search engine to be indexed in its database, it sends a "robot" to scan your page. Using complex algorithms to rank your page for keyword relevance, the "robot" determines whether you'll be ranked number 1 or 1,000,000 when potential visitors conduct a search looking for sites like yours. Because the search engines are constantly changing their algorithms to provide users with the best possible search results, there's only one true solution to high search engine placement--us. In short, submission alone isn't enough. *Good search engine ranking* is critical to your site's success. ------------- HERE'S WHAT WE DO -- A UNIQUE, SUCCESSFUL APPROACH In order to counter the ever-changing search engine algorithms, we create an entire series of "entry pages" that are optimized for the search engines--one for every keyword (or keyword phrase) that you provide. Each entry page is optimized for a different set of algorithm variables. In other words, instead of having only *one* page struggling to rank well on all engines, we create separate, search engine-specific entry pages for each keyword. As a result, your pages rank well because they contain information relevant to search queries that are related to your industry. ------------- HOW ENTRY PAGES AFFECT YOUR WEB SITE'S CURRENT STRUCTURE Put simply, they don't. When creating entry pages we *do not* make any changes to the existing structure, content, or functionality of your current site. The entry pages act as a welcome screen for your Web site when people enter from your highly ranked link on the search engine. The pages will say a few introductory words about your site, which are keyword and/or keyword phrase rich, and then provide a link that asks the visitor to "Click Here To Enter," which moves them directly to your current homepage. ------------ HERE'S WHAT WE DON'T *EVER* DO TO HELP YOUR SEARCH ENGINE RANK We *will not* build pages for irrelevant--yet "popular"--keywords. Also, we will *never* "spamdex" pages. "Spamdexing" is "stuffing" a Web page full of words for the search engine's robots. You may have seen spamdexing, which is placing many words in the same text color as a background onto a Web page. Spamdexing will actually get your pages "kicked" from search engine indexes. What we *will* do is simply present very relevant keywords for your site to the search engines in the way that they "like" to see it. ------------- "It's simple: If they can't find you on the search engines, they can't buy from you." -- J. LeRoss, Internet Sales Consultant ------------ HOW WELL DOES THE SERVICE WORK? We'll send you a detailed report of your current search engine ranking on "The Big Eight" engines before we begin. Then, once your new entry pages have been indexed, we'll send you a second report showing how they've ranked. Here's a sampling of some results we've acheived for previous clients. (These examples are for competitive keywords--not just obscure words on which no one is conducting searches.) <> 6 top-10 rankings on Infoseek for different relevant keywords <> 18 top-10 rankings across the major search engines <> 3 top-10 rankings on Alta Vista for one keyword <> 16 total *number one* rankings <> 40 top-30 rankings, spread across the different engines. <> 1 to 2 hits per week increased to 500 per day <> 45,000 hits per month grew to 108,000. ------------ HOW MUCH DOES YOUR SERVICE COST? Our services are $385. This includes: <> Construction of optimized entry pages for up to 20 keywords -- This gives you good "coverage" in your industry <> Submission of the keyword-dense entry pages to the major search engines <> A complete report of your search engine rankings before we submit <> A complete report of your search engine rankings after submission--so you can see the ranking results When you contact us, ask about other services we provide that may be able to help your Internet initiatives succeed. ------------ HOW DO I GET STARTED? <> Call us--we'll answer any questions you may have and provide a no-cost initial consultation. <> Submit your keywords and/or keyword phrases (up to 20) to us <> Remit payment ------------ COMMENTS FROM CLIENTS "Frankly, I'm impressed with the foregoing. So many solicitations from email sources turn out to be a phone line that hooks up to a voice mail system that is designed to give the impression of size, and people who never return phone calls/messages. . . So its a pleasant surprise to find that someone at the other end is really operating as a business!!!" --Alan B. "Incredible! Our site is now receiving more hits in a day than we used to get in an entire month. [My boss] is still eating his words." -- Bob W. "I knew the search engines were a fantastic marketing tool, but my company simply didn't have the time to devote to search engine placement. It has proven to be the best money we've ever spent on marketing." -- Shelley H. "I worked for weeks to get good search engine placement, but I could never crack the top 80 . . . my site was deserted. Within a month [after using your service], I'd had more hits than I'd had in the last year. I wouldn't believe it if it hadn't happened to me." -- Chris L. ------------ OUR JOB: INCREASE YOUR WEB SITE'S RANKING. We can't *guarantee* that better ranking will increase the number of visitors that "surf" to your Web site. Some highly-ranked websites still don't get much traffic--much depends on your particular industry and choice of keywords. *However*, high rankings, in most cases, *do mean* increased Web site traffic. And, we have *never* failed to increase a client's ranking. Ever. ------------ CONTACT A REPRESENTATIVE: Search Engine Success Group, (410) 783-8269 ----------------------- If you've received this message in error--and are not interested in our services--please click reply. From rem-conf Thu Dec 10 11:36:47 1998 From rem-conf-request@es.net Thu Dec 10 11:36:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoBmD-00053p-00; Thu, 10 Dec 1998 11:29:29 -0800 Received: from fwgate-2.rss.rockwell.com (fwgate-2.nb.rss.rockwell.com) [157.152.197.3] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zoBmB-00053f-00; Thu, 10 Dec 1998 11:29:27 -0800 Received: by fwgate-2.nb.rss.rockwell.com; id LAA19811; Thu, 10 Dec 1998 11:29:19 -0800 (PST) From: Received: from npbsmtp1.nb.rss.rockwell.com(157.152.161.153) by fwgate-2.nb.rss.rockwell.com via smap (4.1) id xma019760; Thu, 10 Dec 98 11:28:50 -0800 Received: by npbsmtp1.nb.rockwell.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882566D6.006AF9BC ; Thu, 10 Dec 1998 11:28:27 -0800 X-Lotus-FromDomain: RSS To: rem-conf@es.net Message-ID: <882566D6.006AF971.00@npbsmtp1.nb.rockwell.com> Date: Thu, 10 Dec 1998 20:28:04 +0100 Subject: NetMeeting/ConferenceID H.225 [To rem-conf@es.net] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sirs, Does anyone know how NetMeeting computes is (H.225) ConferenceIdentifier of ASN.1 type conferenceID in the Setup message ? I have been writng my own H.323 application which is supposed to connect to NetMeeting. Best Regards Norbert Rossello From rem-conf Fri Dec 11 04:21:32 1998 From rem-conf-request@es.net Fri Dec 11 04:21:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoRSq-0004Gw-00; Fri, 11 Dec 1998 04:14:32 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zoRSo-0004Gm-00; Fri, 11 Dec 1998 04:14:30 -0800 Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 3749; Fri, 11 Dec 98 07:14:25 1 E Received: by HAIFA (XAGENTA 4.0) id 6772; Fri, 11 Dec 1998 14:14:12 +0200 Received: from hrlsmtp.haifa.ibm.com by mail.haifa.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA41810; Fri, 11 Dec 1998 14:17:51 +0200 Received: by hrlsmtp.haifa.ibm.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 422566D7.00431E86 ; Fri, 11 Dec 1998 14:13:07 +0200 X-Lotus-Fromdomain: IBMHAIFA From: "Gal Ashour" To: casner@cisco.com, rem-conf@es.net Message-Id: <422566D7.00431C79.00@hrlsmtp.haifa.ibm.com> Date: Fri, 11 Dec 1998 14:10:28 +0200 Subject: RTP Proposal - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Following the avt discussion earlier today, we were requested to list scenarios for using RTP-multiplexing. My main interest is audio IP-Telephony, but I think that the RTP multiplexing applies in general to implementations that require real-time (or at least quick enough) response on one hand, and have a relatively short payload on the other hand (and thus the headers, IP/UDP and possibly the RTP, become a significant overhead). Scott's signalling proposal (if adopted) could become a candidate for using this mechanism too since it falls into the category above. I will use the G.723.1 codec for comparison of the different proposals. For G.723 I assume in the calculation 24 bytes per payload (generated every 30 msec). The results may change a little based on the payload size for other codecs, but I do not think that it will result in a dramatic change of the picture. Before I go on with the numbers, I would suggest that a higher weight should be given to scenarios that use a relatively short payload, rather than those who use large ones (which may be the case with Video and Data), since the main advantage in RTP multiplexing is for applications that have short payload and thus the header overhead is their main concern. I will assume X simultaneous calls, all using the same codec and payload length (just for simplicity of the calculation) - I think that this assumption is reasonable, and should not distort the general picture we get >from the comparison. PFS stands hereby for Payload Frame Size, and eventually will be given the value 24 (per the above codec assumption). Hitachi proposal: -------------------------- Advantages: Very simple to implement, do not loose any information originally in the RTP header (since it is multiplex as is). Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28 + (12+PFS)*X (28 stands for IP+UDP headers). Asymptotic Bandwidth reduction (large X): 1- (12+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (36)/(64)= 43 % GeRM Proposal: _______________ Advantage: All the information in the original RTP header can be reconstructed, High compression ratio. Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+12+ (1+ 1+PFS)*X ( The first '1' stands for the GeRM 1-byte Header, the second '1' stands for payload type for the first block, and for the LSB of the SSRC which may be needed due to silence characteristics for the other blocks (we could even use 0.5 byte on average as a worse case) ). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Bell Proposal: ____________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+12+ (2+PFS)*X (The '2' stands for the minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Since the CC field is not in the mini-header it may imply that no CSRC information is transferred - which may be a disadvantage in some centralized conferencing scenarios where we may have several contributor sources to the same payload (and wish to identify them in the application). Also timestamp information may be of importance, but do not fit into the mini header. Nokia Proposal ______________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+ (2+PFS)*X (The '2' stands for the minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Again, since the CC field is not in the mini-header it may imply that no CSRC information is transferred, which may be a disadvantage in some centralized conferencing scenarios where we may have several contributions to the same payload. Also timestamp information may be of importance, but do not fit into the mini header. This proposal limits the length field is to only 5 bits (which may be a limitation for payload scenarios that are slightly longer than 31 bytes, and could still benefit from multiplexing). ========================= My Perspective: _______________ I think that all the four proposals are basically good ones, but we need to go forward. It seem that three of the proposals fit into the 'high bandwidth reduction' category, while the Hitachi fits into a 'medium bandwidth reduction category'. Two of the 'high bandwidth reduction' proposals are lossy in respect to the RTP header information, and thus may limit their use in comparison to the GeRM and Hitachi's proposal that are 'lossless' in that respect. I would suggest to proceed with two of the proposals: GeRM and Hitachi, since they both don't loose RTP header information, and represent the two ends of simplicity vs. high compression. Once the GeRM proposal is completed (like ID negotiation issue), we may decide which of the two is preferred. As for the RTCP issue. I think that the information is still valid in respect to the 'global' packet, and can be associated with the timestamp of the first block in each multiplexed packet. Best Regards, -- Gal. ------------------------------------------------------- Gal Ashour Audio/Video Group IBM Research - Haifa Research Lab. ISRAEL ashour@haifa.vnet.ibm.com ------------------------------------------------------- From rem-conf Fri Dec 11 04:48:26 1998 From rem-conf-request@es.net Fri Dec 11 04:48:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoRy8-0004xn-00; Fri, 11 Dec 1998 04:46:52 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zoRy7-0004xc-00; Fri, 11 Dec 1998 04:46:51 -0800 Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 4045; Fri, 11 Dec 98 07:46:46 1 E Received: by HAIFA (XAGENTA 4.0) id 6788; Fri, 11 Dec 1998 14:46:34 +0200 Received: from hrlsmtp.haifa.ibm.com by mail.haifa.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA41750; Fri, 11 Dec 1998 14:50:16 +0200 Received: by hrlsmtp.haifa.ibm.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 422566D7.004616E3 ; Fri, 11 Dec 1998 14:45:33 +0200 X-Lotus-Fromdomain: IBMHAIFA From: "Gal Ashour" To: rem-conf@es.net Message-Id: <422566D7.004614CF.00@hrlsmtp.haifa.ibm.com> Date: Fri, 11 Dec 1998 14:42:55 +0200 Subject: RTP Proposal - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Following the avt discussion earlier today, we were requested to list scenarios for using RTP-multiplexing. My main interest is audio IP-Telephony, but I think that the RTP multiplexing applies in general to implementations that require real-time (or at least quick enough) response on one hand, and have a relatively short payload on the other hand (and thus the headers, IP/UDP and possibly the RTP, become a significant overhead). Scott's signalling proposal (if adopted) could become a candidate for using this mechanism too since it falls into the category above. I will use the G.723.1 codec for comparison of the different proposals. For G.723 I assume in the calculation 24 bytes per payload (generated every 30 msec). The results may change a little based on the payload size for other codecs, but I do not think that it will result in a dramatic change of the picture. Before I go on with the numbers, I would suggest that a higher weight should be given to scenarios that use a relatively short payload, rather than those who use large ones (which may be the case with Video and Data), since the main advantage in RTP multiplexing is for applications that have short payload and thus the header overhead is their main concern. I will assume X simultaneous calls, all using the same codec and payload length (just for simplicity of the calculation) - I think that this assumption is reasonable, and should not distort the general picture we get >from the comparison. PFS stands hereby for Payload Frame Size, and eventually will be given the value 24 (per the above codec assumption). Hitachi proposal: -------------------------- Advantages: Very simple to implement, do not loose any information originally in the RTP header (since it is multiplex as is). Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28 + (12+PFS)*X (28 stands for IP+UDP headers). Asymptotic Bandwidth reduction (large X): 1- (12+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (36)/(64)= 43 % GeRM Proposal: _______________ Advantage: All the information in the original RTP header can be reconstructed, High compression ratio. Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+12+ (1+ 1+PFS)*X ( The first '1' stands for the GeRM 1-byte Header, the second '1' stands for payload type for the first block, and for the LSB of the SSRC which may be needed due to silence characteristics for the other blocks (we could even use 0.5 byte on average as a worse case) ). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Bell Proposal: ____________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+12+ (2+PFS)*X (The '2' stands for the minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Since the CC field is not in the mini-header it may imply that no CSRC information is transferred - which may be a disadvantage in some centralized conferencing scenarios where we may have several contributor sources to the same payload (and wish to identify them in the application). Also timestamp information may be of importance, but do not fit into the mini header. Nokia Proposal ______________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing = (40+PFS)*X With RTP Multiplexing = 28+ (2+PFS)*X (The '2' stands for the minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=24: Asymptotic Bandwidth reduction: 1- (26)/(64)= 59 % Again, since the CC field is not in the mini-header it may imply that no CSRC information is transferred, which may be a disadvantage in some centralized conferencing scenarios where we may have several contributions to the same payload. Also timestamp information may be of importance, but do not fit into the mini header. This proposal limits the length field is to only 5 bits (which may be a limitation for payload scenarios that are slightly longer than 31 bytes, and could still benefit from multiplexing). ========================= My Perspective: _______________ I think that all the four proposals are basically good ones, but we need to go forward. It seem that three of the proposals fit into the 'high bandwidth reduction' category, while the Hitachi fits into a 'medium bandwidth reduction category'. Two of the 'high bandwidth reduction' proposals are lossy in respect to the RTP header information, and thus may limit their use in comparison to the GeRM and Hitachi's proposal that are 'lossless' in that respect. I would suggest to proceed with two of the proposals: GeRM and Hitachi, since they both don't loose RTP header information, and represent the two ends of simplicity vs. high compression. Once the GeRM proposal is completed (like ID negotiation issue), we may decide which of the two is preferred. As for the RTCP issue. I think that the information is still valid in respect to the 'global' packet, and can be associated with the timestamp of the first block in each multiplexed packet. Best Regards, -- Gal. ------------------------------------------------------- Gal Ashour Audio/Video Group IBM Research - Haifa Research Lab. ISRAEL ashour@haifa.vnet.ibm.com ------------------------------------------------------- From rem-conf Fri Dec 11 05:30:05 1998 From rem-conf-request@es.net Fri Dec 11 05:30:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoSRh-0005st-00; Fri, 11 Dec 1998 05:17:25 -0800 Received: from services.paradyne.com [135.90.253.90] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zoSRh-0005rC-00; Fri, 11 Dec 1998 05:17:25 -0800 Received: from pinto ([131.247.166.16]) by services.paradyne.com (Netscape Messaging Server 3.6) with SMTP id AAA1BA8 for ; Fri, 11 Dec 1998 08:16:20 -0500 Received: by localhost with Microsoft MAPI; Fri, 11 Dec 1998 08:17:55 -0500 Message-ID: <01BE24DE.C11A0480.pinto@eng.paradyne.com> From: "Jesus A. Pinto" To: "'rem-conf@es.net'" Subject: remove Date: Fri, 11 Dec 1998 08:16:49 -0500 Organization: Paradyne Corporation X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Fri Dec 11 09:05:38 1998 From rem-conf-request@es.net Fri Dec 11 09:05:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoVvm-0000Bb-00; Fri, 11 Dec 1998 09:00:42 -0800 Received: from sunblast.eng.usf.edu [131.247.14.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zoVvl-0000BR-00; Fri, 11 Dec 1998 09:00:41 -0800 Received: from localhost (padhye@localhost [127.0.0.1]) by sunblast.eng.usf.edu (8.8.8/8.8.7) with ESMTP id MAA24889 for ; Fri, 11 Dec 1998 12:00:52 -0500 (EST) Date: Fri, 11 Dec 1998 12:00:51 -0500 (EST) From: Chinmay Padhye X-Sender: padhye@sunblast To: rem-conf@es.net Subject: Congestion Control. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello: I am a graduate student at the University Of South Florida, Tampa, FL. I am interested in the area of transporting voice over IP. I have looked at a few papers on congestion control. However these papers mainly deal with congestion control in streaming applications and do not look at congestion control in interactive applications. Can anyone point to me to a few papers on congestion control in interactive voice applications. Thanks in advance... Chinmay V. P. Graduate Student. Department of Computer Science and Engineering. University Of South Florida. From rem-conf Fri Dec 11 09:05:48 1998 From rem-conf-request@es.net Fri Dec 11 09:05:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoW0D-0000Ct-00; Fri, 11 Dec 1998 09:05:17 -0800 Received: from outside.organic.com [204.152.144.47] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zoW0C-0000Ce-00; Fri, 11 Dec 1998 09:05:16 -0800 Received: (from majord@localhost) by outside.organic.com (8.8.4/8.8.4) id VAA08295 for javangelist-outgoing; Tue, 8 Dec 1998 21:56:44 -0800 (PST) X-Authentication-Warning: outside.organic.com: majord set sender to miko@outside.organic.com using -f Date: Tue, 8 Dec 1998 21:56:41 -0800 (PST) From: Miko Matsumura X-Sender: miko@outside.organic.com To: javangelist@miko.com Subject: [miko] Farewell Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: miko@outside.organic.com Reply-To: Miko Matsumura X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello my community, Hello my friends both nearby and overseas; Coworkers both old and new. I also greet my colleagues and leaders in this fast, vibrant industry. Through working and playing with all of you I have felt the admiration, inspiration and motivation needed to kee p me going. For three and a half years I've had the privilege to serve as the Java Evangelist for Sun Microsystems. This role has taught me what it means to run fast and "run everywhere". The early Java team showed me what kind of incredible creative energy, talent, intelligence, persistence, humor, and insight it takes to bring a great new technology into the world. I'm grateful for that time. This is why I include a measure of sadness as well as excitement and hope among the feelings as I close this chapter of my c areer. I am leaving Sun but of course I am not leaving Java. I am launching a Silicon Valley Java startup tentatively called BizTone-a subsidiary of Madura.net (http://www.madura.net). They are innovators in their use of the latest Java technologies including Ji ni and JFC/Swing. And of course they have the killer app. Using Java to deliver the power of Fortune 500 Enterprise Resource Management to "the rest of us" (small and mid-sized businesses) over network or even phone lines. I feel confident leaving the official duties of Java Evangelism especially at a time when America OnLine has announced its commitment to Java client browsers and hardware. Coupled with the announcement of the release of the Java 2 class libraries and the preliminary injunction against Microsoft, I can retire knowing that tens of millions of compatible clients are assured. Having evangelized some 100,000 people I can rest with the knowledge that I contributed in some way to the Java revolution. I am not cl aiming that the Java story is complete, merely that these trends represent the end of an important stage in Java's evolution. Finally, the announcement of community source models for JDK suggest a natural evolution of Java towards a open but compatible conclusion. The richest, most meaningful events in one's life are those which are reflected in our relationships with others. I've had the good fortune to share some of myself with each of you and in turn appreciate what you have offered me. Without the mirror of my communities, I would be much the poorer in the knowledge I have of myself. The context of a community is further deepened by a sense of history and continuity. I hope that you will stay in contact with me through this and other life transitions. (Further information is provided below.) Sincerely, Miko Matsumura Former Java Evangelist President, US operations VP of strategy Madura.net How often do you want to hear from Miko? Once every six months: If you received a primary copy of this message, it means that you have been subscribed to the Javangelist. This mailing list will be updated approximately once in six months. If you do not wish to receive these updates, please send a message to majordomo@miko.com with the body text unsubscribe javangelist. (I have only added people to the list whose email addresses I have in my personal inbox. If you don't know me, I don't know how your email came to be in my box!) Once every few weeks: If you are more actively interested to hear what is going on with Miko, feel free to subscribe to Miko's friends' list. Just send a message to majordomo@miko.com with the body text subscribe friends. At will: If you ever want to check in on me, feel free to email me at miko@miko.com or check my web page at www.miko.com From rem-conf Fri Dec 11 11:13:50 1998 From rem-conf-request@es.net Fri Dec 11 11:13:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoXxx-0002dt-00; Fri, 11 Dec 1998 11:11:05 -0800 Received: from wya-lfd83.hotmail.com (hotmail.com) [207.82.252.147] by mail1.es.net with smtp (Exim 1.81 #2) id 0zoXxw-0002da-00; Fri, 11 Dec 1998 11:11:04 -0800 Received: (qmail 14500 invoked by uid 0); 11 Dec 1998 19:09:34 -0000 Message-ID: <19981211190934.14499.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Fri, 11 Dec 1998 11:09:33 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: rem-conf@es.net, ASHOUR@HAIFA.VNET.IBM.COM Subject: Re: RTP Proposal - comparison MIME-Version: 1.0 Content-Type: text/plain Date: Fri, 11 Dec 1998 11:09:33 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >-- Gal. >I would suggest to proceed with two of the proposals: GeRM and Hitachi, >since they both don't loose RTP header information, and represent the two >ends of simplicity vs. high compression. >Once the GeRM proposal is completed (like ID negotiation issue), we may >decide which of the two is preferred. Both simplicity and efficiency are important factors in determining a useful multiplexing scheme. A standard solution should take them both into consideration and effectively compromise the GeRM and Hitachi proposals. A GeRM header is greatly efficient, but its complexity may become a limiting factor in high-capacity gateways. The Hitachi proposal has the least complexity involved, but does not achieve the efficiency numbers that make multiplexing a true benifit. There are a few easy modifications to this (Hitachi) simple muxing scheme that would assist in efficiency (e.g. replacing the SSRC with user ID's, out of band payload identification, etc.) Regards, Neal A. Schneider > > >------------------------------------------------------- >Gal Ashour >Audio/Video Group >IBM Research - Haifa Research Lab. >ISRAEL > >ashour@haifa.vnet.ibm.com >------------------------------------------------------- > > > > > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri Dec 11 15:37:07 1998 From rem-conf-request@es.net Fri Dec 11 15:37:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zoc4m-00056c-00; Fri, 11 Dec 1998 15:34:24 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zoc4k-00056S-00; Fri, 11 Dec 1998 15:34:23 -0800 Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 4359; Fri, 11 Dec 98 18:34:18 1 E Received: by HAIFA (XAGENTA 4.0) id 6946; Sat, 12 Dec 1998 01:34:05 +0200 Received: from hrlsmtp.haifa.ibm.com by mail.haifa.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA90202; Sat, 12 Dec 1998 01:37:44 +0200 Received: by hrlsmtp.haifa.ibm.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 422566D7.00815AD2 ; Sat, 12 Dec 1998 01:32:53 +0200 X-Lotus-Fromdomain: IBMHAIFA From: "Gal Ashour" To: "Neal Schneider" , rem-conf@es.net Message-Id: <422566D7.00815A55.00@hrlsmtp.haifa.ibm.com> Date: Sat, 12 Dec 1998 01:30:19 +0200 Subject: Re: RTP (multiplexing) Proposals - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Neal, I couldn't agree with you more. Both simplicity and efficiency are important, which is the exact reason that I suggested to concentrate on the two proposals that represent each of those two categories (with a possibility of a later merger). They both also share a common important characteristic, which is not losing information from the original RTP header. The Hitachi proposal may well be enhanced in the future, but it has merit even as is. The difference between 59% bandwidth reduction and 43% (as is the case for G.723 under the assumption in my previous posting) is not negligible, but yet it isn't a huge difference neither. It may not be such a bad trade-off for its simplicity - but I guess that this can be decided later on, after GeRM defines the needed means for its ID and payload determination. Until a robust and reliable out-of-band mechanism is provided for payload and ID determination, the Hitachi proposal provides a simple solution that can be already implemented (based on some well defined preliminary H.323 negotiation). You may be well right, that once GeRM provides those mechanism, a third alternative may be to adopt the Hitachi proposal, after incorporating into it the ID and Payload negotiation schemes developed for GeRM. Regards, -- Gal. "Neal Schneider" on 11/12/98 21:09:33 To: rem-conf@es.net, ASHOUR@HAIFA.VNET.IBM.COM cc: (bcc: Gal Ashour/IBMHAIFA) Subject: Re: RTP Proposal - comparison >-- Gal. >I would suggest to proceed with two of the proposals: GeRM and Hitachi, >since they both don't loose RTP header information, and represent the two >ends of simplicity vs. high compression. >Once the GeRM proposal is completed (like ID negotiation issue), we may >decide which of the two is preferred. Both simplicity and efficiency are important factors in determining a useful multiplexing scheme. A standard solution should take them both into consideration and effectively compromise the GeRM and Hitachi proposals. A GeRM header is greatly efficient, but its complexity may become a limiting factor in high-capacity gateways. The Hitachi proposal has the least complexity involved, but does not achieve the efficiency numbers that make multiplexing a true benifit. There are a few easy modifications to this (Hitachi) simple muxing scheme that would assist in efficiency (e.g. replacing the SSRC with user ID's, out of band payload identification, etc.) Regards, Neal A. Schneider > > >------------------------------------------------------- >Gal Ashour >Audio/Video Group >IBM Research - Haifa Research Lab. >ISRAEL > >ashour@haifa.vnet.ibm.com >------------------------------------------------------- > > > > > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Sat Dec 12 22:14:39 1998 From rem-conf-request@es.net Sat Dec 12 22:14:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zp4b1-0006wT-00; Sat, 12 Dec 1998 22:01:35 -0800 Received: from dfssl.exchange.microsoft.com [131.107.88.59] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zp4b0-0006uz-00; Sat, 12 Dec 1998 22:01:34 -0800 Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Sat, 12 Dec 1998 21:57:46 -0800 Message-ID: <69D8143E230DD111B1D40000F8485840073B4E16@ED> From: "Anders Klemets (Exchange)" To: "'rem-conf@es.net'" , "'4onip-sys@fzi.de'" <4onip-sys@fzi.de> Subject: Comments on Generic RTP Payload Format proposal Date: Sat, 12 Dec 1998 21:57:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a couple of minor comments on the Generic RTP Payload Format proposal, draft-guillemot-genpayload-00.txt, that was presented at the IETF AVT working group meeting. The payload format supports grouping and fragmentation, of higher level "application units". It is also possible to carry arbitrary extension data. It is through this extension mechanism that the payload format can be made to support FEC with parity codes, FEC with Reed-Solomon codes, redundancy, etc. The correct interpretation of the extension data is given by the XT (Extension Type) header field. I think the main concern that I heard from several people at the IETF meeting, was that this introduces an extra multiplexing point. To figure out how to interpret an RTP packet, one must first look at the RTP Payload Type field, and then look at the XT field in the generic payload format. However, after having looked at the Internet-Draft again, I now think this might not be such a big issue after all. The reason is that the Internet-Draft does not specify any static assignments for the XT field. Rather, it says that the values to be used for the XT field should be communicated out-of-band, using SDP or similar mechanisms. I would think that in most cases, the extension data field would not be used, or it would only be used in one single way. For instance, I think it is unlikely that some packets in an RTP session would have extension data for parity FEC, while other packets in the same session would use Reed-Solomon FEC. So, when SDP indicates that there are 0-1 valid values for the XT field, the RTP receiver can effectively ignore the field. Thus, the problem with the additional multiplexing point becomes a non-issue in the typical case. Given this, one could argue that the XT field should be removed, although that would give up some flexibility that could be useful in the future. In any case, it seems clear that 8 bits is an excessively large size for this field. I would also like to second Jonathan Rosenberg's comment, that it is better to specify the format of the extension data field by referring to the relevant documents, rather than including the text explicitly in this Internet-Draft. Of course, there might be cases where no relevant document exists. In those cases, it might still be better to publish the format of the extension data field in a different document, which would be separate >from the document that specifies the Generic Payload Format. I also have some comments regarding the alignment of the various fields in the payload format. The primary concern of any payload format that implements "grouping" or "multiplexing", is to reduce the number of packets. The second concern would be to reduce the number of bytes in the payload format header. This is quite important when very small application units are grouped together. To achieve this second goal, I think most people would accept giving up word alignment of header fields, as long as the header fields are still aligned to byte boundaries. In this payload format, however, individual header fields are not byte aligned. Padding is inserted at the end of the last header field to ensure that the payload begins at a byte boundary. I know that byte alignment is not an issue in the MPEG world (Just look at the MPEG-4 SL-Packet header definition and you will be either horrified or delighted, depending on where you come from) but in the IETF header fields are typically aligned. I have two different proposals for how the header syntax can be modified. Both proposals ensure that header fields are byte aligned, but they work a little bit differently. The proposals all show that byte alignment can be achieved at a maximum cost of one byte, sometimes even less. Proposal 1: * Reduce the XT field from 8 bits to 6 bits. As discussed earlier, it is hard to conceive of a situation where someone would want more than 64 different kinds of Extension Data in the same RTP session. * If E=0, insert a new field with 5 bits, directly following the F field. The 5 bits are reserved and should always be set to 0. * The size of the LENGTH field is increased from 13 to 16 bits. This causes all header fields to be aligned with byte boundaries. No padding field is necessary. This comes at a cost, however. If you look at example #3 in draft-guillemot-genpayload-00.txt, you might see that the second header, which consists only of flags and a LENGTH field, will increase from two bytes to three bytes. And this is a fairly common case, because it happens whenever the packet consists of extension data and an application unit that is not being fragmented. Proposal 2: * Reduce the XT field from 8 bits to 6 bits. See comment above. * If E=1, increase the size of the LENGTH field from 13 to 16 bits. * If E=0, the size of the LENGTH field remains at 13 bits. * If G=0 and E=0, the size of TSOFFSET is reduced from 16 to 13 bits. * If G=1 or E=1, the size of TSOFFSET remains at 16 bits. * If the FOFFSET field would directly follow the flag fields (because neither LENGTH nor TSOFFSET is present), insert 5 reserved bits in front of FOFFSET, instead of adding 5 bits of padding at the end of FOFFSET. This causes all header fields to be aligned with byte boundaries. And this comes at no extra cost in terms of the header size. As a matter of fact, this scheme saves one entire byte when the payload header only contains the TSOFFSET field. (See example #1, in draft-guillemot-genpayload-00.txt.) Of course, you may already have noticed that there is another kind of cost associated with this proposal: complexity. Anders From rem-conf Sun Dec 13 06:24:43 1998 From rem-conf-request@es.net Sun Dec 13 06:24:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpCLL-00023J-00; Sun, 13 Dec 1998 06:17:56 -0800 Received: from 3ctc91-psw.skyweb.net (mail.skyweb.com) [205.216.239.91] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpCLK-000234-00; Sun, 13 Dec 1998 06:17:55 -0800 Message-ID: <6284.31257@mail.skyweb.com> From: lisaf@skyweb.com Bcc: Reply-To: lisaf@skyweb.com Subject: Online Underwriting Breakthrough (4515) Date: Sun, 12 Dec 1998 09:18:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Become a substandard expert with Risk Tutor. Our online "wisdom tools" will make screening, researching and submitting your substandard cases online to any carrier or brokerage agency remarkably easy. Go to http://www.risktutor.com and see the first online underwriting knowledge system for life insurance agents that provides an instant upgrade for managing substandard cases. Be brilliant, complete and successful in placing substandard cases without a medical school education. Get Risk Tutor! **************************************************************************************** 59114 From rem-conf Sun Dec 13 07:03:52 1998 From rem-conf-request@es.net Sun Dec 13 07:03:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpCzl-00035o-00; Sun, 13 Dec 1998 06:59:41 -0800 Received: from imo17.mx.aol.com [198.81.17.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpCzi-000351-00; Sun, 13 Dec 1998 06:59:38 -0800 Received: from Hardlik069@aol.com by imo17.mx.aol.com (IMOv18.1) id EOIYa03172; Sun, 13 Dec 1998 09:00:22 -0500 (EST) From: Hardlik069@aol.com Message-ID: <8172dc00.3673c876@aol.com> Date: Sun, 13 Dec 1998 09:00:22 EST Mime-Version: 1.0 Subject: Publishing Company For Sale Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 16-bit for Windows sub 41 Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list See information about Free Credit Application Below! My Multi-Million Dollar Publishing Company ONLY $149 Free Pre-Approved Merchant Account Application with Order!! To Start Your Business Out Right!! If you ever wanted "the easy way out" to make a lot of money with a business of your own.... Here is the EASIEST WAY TO START! I'm writing this letter to let you in on something that'll blow you away. What I'm about to present is something I've never done before...something that I'll never do again.... So PAY ATTENTION! For the past few years...I've have been running ads in newspapers & magazines, by direct mail, and throughout the internet. These ads were always small and very cheap... On these ads, we have been selling little manuals. These manuals have sold for anywhere between $10 to $99 each. We always ran different ads for each manual we were selling. I like selling information because NOBODY can put a price on it...ESPECIALLY when it is your own...The Sky is the Limit! Plus it is very cheap to reproduce How-To manuals. It costs between 40 cents and $3 to print the entire print manuals and around 35 cents to copy the manuals on disk. AND you can sell them for up to $99 each. That is one hell of a markup! These manuals tell you how to get a car with no money down and no credit...another one tells you how to avoid taxes by depositing income offshore...now you may not be interested in saving money by going offshore...but believe me....there are MILLIONS OF PEOPLE WHO DO...and they are willing to pay me to teach them!!! Well this is where the unbelievable offer comes in...I hope you are sitting down for this one...because this is a once in a lifetime chance for you. I do not know of an easier way to become financially independent...In fact THERE IS NO EASIER WAY!!! The next few paragraphs will reveal everything to you. I am willing to sell you my entire informational product line with FULL REPRINT RIGHTS and complete step-by-step instructions on how to start your mail order information business with very little money. Remember, these are PROVEN WINNERS. If you are stumped on something to sell or if you are having trouble writing a good ad, I have also included an entire book on disk to help you produce KILLER ads! This entire package which I call a Publishing Company in a Box will come on 1 CD containing over 2000 'Hot-Selling' Books, Reports And Manuals ready to print and sell, Sell, SELL! It also will come with a signed letter giving YOU FULL REPRINT RIGHTS allowing you to sell them for as much as you want and however you want. You Can even sell the entire kit to someone else to resale on their own! You also receive copies of KILLER ads which can fill your mailbox with cash! I am not even going to ask you for any of the money either... What you make is yours to keep . In fact...you get to make a ton of money on these manuals for as long as you wish...and you will never have to pay me another red cent in royalties! I am even going to print out and prepare our #1 selling report which contains the secrets of obtaining credit without a credit check and producing an offshore income without taxes so that you will be able to take it down to your local copy shop and be ready to sell it the same day you have received it. Watch out though - one individual is making $70,000 a month on this report alone! (Why - Because you can include a FREE offshore credit application for those with bad or no credit with this report and explode your mailbox with orders) Note: THIS APPLICATION IS INCLUDED! All I ask for is...$149 and I will include FREE Priority Mail Shipping! Yes, I said $149. There are no zeros missing. Plus if you order before Dec. 18th I will include 4 extra special bonuses... Bonus #1 - "Search Engine Magic" on disk. This report will shoot your web site up to the top of the search engine listings. Other web advertisers are selling this manual for $99 by itself - But I will give it to you for FREE with this package. Bonus #2 - The report "How to Make at least $1,600 a week online...Starting Now!" which is taking the internet by storm will be included absolutely FREE! Bonus #3 - I will include special details about a secret source for direct mail leads that can produce cash orders along with out KILLER ads. And another source will be given which allows you to advertise nationwide through newspapers to 70,000,000 readers for as low as 7 cents per word. Bonus #4 - I also will include a pre-approved application for a merchant account for your business benefit. Taking credit cards will increase your business up to 100%. The normal $195 application fee will be waved with this pre-approved application. But there is one drawback... I am sending this ad to 10,000 other people...and I will only allow 50 kits to be sold. It wouldn't make much sense if I sold this kit to 1,000 or 2,000 people...The market would be saturated with these same manuals... and I don't want to do that. To make sure that the people in this offer get the same results I have...ONLY 50 people can have it for $149.00! Chances are, I will get all 50 within a week's time. So if this is something you are interested in...RUSH me a check or money order for $149.00 TODAY to insure your future business. But, even if you decide to pass this up...Don't sweat it. It's not like I am going to be mad or anything like that. I know I will get my 50 order limit really fast. And anyone who gets their check into me late... I will simply send it back. For only $149.00, I am going to let you have the easiest money you will ever make. The manuals are written, the ads are presented, the advertising plan is laid out, and all you have to do is print them out for pennies and place the ads. Do it today! Rush me your payment of $149.00 right now...and get your very own MILLION DOLLAR publishing company going! You can start with one or two manuals...even the day you receive the package...and then expand to include ALL of them! For $149.00, you have everything you need to make a killing with your very own business. If you want to make real money - then this offer is for you! "I took the report "Search Engine Magic" and sold over 50 copies on disk within 2 weeks! They sold for $99 and I was able to copy them for under 50 cents each. Wait till I start marketing the other products included in this line!!!" Joe Fisher - Internet Marketer To rush order this "MILLION DOLLAR Publishing Company in a Box" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------------- Please send to: Your Name__________________________________________ Your Address________________________________________ Your City____________________________________________ State / Zip___________________________________________ Phone #: ____________________________________________ (For problems with your order only. No salesmen will call.) Email Address_______________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard and American Express. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $149.00 Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ [ ] YES! Please rush my Publishing Company in a Box. I understand I have FULL REPRINT Rights and can sell any of the items for whatever price I desire, even the entire kit. [ ] DOUBLE YES! I am ordering by Dec. 18th! Please include the extra special bonuses! * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing my credit card number. (Note your card will be charged for $149.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $149.00! Note - If ordering outside continental US, please add $5 to S&H P.S. Don't forget you will receive 2,000 Manuals, Books, and Reports (Some of which are up to 200 pages each)...all for $149...You have full reprint and resale rights to make as much money as you want without ever paying any royalties whatsoever! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * You have been carefully selected to receive the following as a person obviously interested in this subject based upon your previous internet postings, or visits to one of our affiliate web sites. If you have received this message in error, reply with the word unsubscribe in the subject. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From rem-conf Sun Dec 13 15:28:29 1998 From rem-conf-request@es.net Sun Dec 13 15:28:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpKq4-0006mB-00; Sun, 13 Dec 1998 15:22:12 -0800 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpKq2-0006m1-00; Sun, 13 Dec 1998 15:22:10 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Sun Dec 13 18:15:06 EST 1998 To: rem-conf@es.net Received: from alliance.research.att.com ([135.207.26.26]) by research; Sun Dec 13 18:20:17 EST 1998 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA21836 for ; Sun, 13 Dec 1998 18:20:15 -0500 (EST) From: Pawan Goyal Received: (from goyal@localhost) by windsor.research.att.com (8.8.7/8.8.5) id SAA17450 for rem-conf@es.net; Sun, 13 Dec 1998 18:20:14 -0500 (EST) Date: Sun, 13 Dec 1998 18:20:14 -0500 (EST) Message-Id: <199812132320.SAA17450@windsor.research.att.com> Content-Type: text Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please find enclosed herewith the CFP for NOSSDAV 99. My apologies in advance if you receive multiple copies of the same. Pawan Goyal ====================================================================== The 9th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 99) http://www.research.att.com/conf/nossdav99/ 23-25 June, 1999 Hosted By: AT&T Labs Networking and Distributed Systems Research Laboratory CALL FOR PAPERS Objectives The 9th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 99) is the international workshop concerned with state of the art technology in networking and operating system support for multimedia systems. For eight years, NOSSDAV has proven to be an outstanding forum for researchers involved in building innovative multimedia systems, networks and applications in both industry and academia. A key aspect of the workshop is that it provides extensive discussion periods during which attendees can informally discuss their current work and future research directions. Traditionally, NOSSDAV has emphasized high quality experimental research based on prototype or real systems. NOSSDAV99 will continue this tradition. Submissions Submissions are sought in any area related to Network and Operating Systems Support for Digital Audio and Video. Two types of submissions are solicited: position statements or work in progress reports and full papers. These will be reviewed in entirely different ways and have different deadlines. Full papers will be subject to a normal review process and are restricted to fifteen pages. Accepted papers will be presented at the Workshop and will appear in the published proceedings. Position statements and work in progress reports of no more than three pages, will be reviewed by the program committee only. Papers will be chosen on the basis of their potential to provoke discussion. Roughly half of the workshop presentations will be allocated to this category. Submissions, should be sent by electronic mail to nossdav99@research.att.com. Please include 1. The paper in PostScript or Microsoft Word (Word 6.0 or Word 97) form 2. The title of the paper, the list of authors with complete contact information in the form of email address and phone number, and, in the case of full papers, an abstract summarizing the paper in PLAIN TEXT. The paper abstracts will be circulated among the NOSSDAV program committee members to solicit reviewers. Please note that the proceedings of the workshop will be published as a book and the best papers will be forwarded to selected journals for publication. Important Dates Submission Deadline for Full Papers: 1 March 1999 Acceptance Notification for Full Papers: 30 April 1999 Final Full Papers Due: 30 May 1999 Submission Deadline for Position Statements: 30 March 1999 Acceptance Notification for Position Statements: 30 April 1999 Workshop: 23-25 June 1999 Program Chair: Chuck Kalmanek AT&T Labs Shannon Laboratory Room A113 180 Park Avenue Florham Park NJ 07032 crk@research.att.com Other Correspondence: nossdav99@research.att.com Program Committee Ian Leslie, Cambridge University, UK Charles Kalmanek, AT&T Labs Research Jim Kurose, University of Masachusetts Tom Little, Boston University Derek McAuley, Microsoft Research, UK Henning Schulzrinne, Columbia University Hide Tokuda, Keio University Domenico Ferrari, Universita Cattolica, Italy Kevin Jeffay, University of North Carolina Mike Jones, Microsoft Doug Shepherd, Lancaster University, UK Richard Black, University of Glasgow, UK Jason Nieh, Columbia University Partho Mishra, AT&T Labs Research S. Keshav, Cornell University H. Zhang, Carnegie Mellon University Raj Yavatkar, Intel Duane Northcutt, Sun Microsystems LOCATION AT&T Learning Center, Basking Ridge NJ From rem-conf Mon Dec 14 03:36:38 1998 From rem-conf-request@es.net Mon Dec 14 03:36:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpW5N-0003XK-00; Mon, 14 Dec 1998 03:22:45 -0800 Received: from (artemis.rus.uni-stuttgart.de) [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpW5L-0003XA-00; Mon, 14 Dec 1998 03:22:43 -0800 Received: from kssun9.rus.uni-stuttgart.de (kssun9.rus.uni-stuttgart.de [129.69.13.19]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id MAA12682; Mon, 14 Dec 1998 12:22:38 +0100 (MET) env-from (wesner@rus.uni-stuttgart.de) Received: from ksat22 (ksat22.rus.uni-stuttgart.de [129.69.13.26]) by kssun9.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id MAA28965; Mon, 14 Dec 1998 12:19:36 +0100 (MET) From: "Stefan Wesner" To: "Anders Klemets (Exchange)" , , <4onip-sys@fzi.de> Cc: "Paul Christ" , "Christine Guillemot" Subject: RE: Comments on Generic RTP Payload Format proposal Date: Mon, 14 Dec 1998 12:20:43 +0100 Message-ID: <002b01be2753$c9d1c7d0$1a0d4581@ksat22.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <69D8143E230DD111B1D40000F8485840073B4E16@ED> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > .... > > However, after having looked at the Internet-Draft again, I now think this > might not be such a big issue after all. The reason is that the > Internet-Draft does not specify any static assignments for the XT field. > Rather, it says that the values to be used for the XT field should be > communicated out-of-band, using SDP or similar mechanisms. > right. > I would think that in most cases, the extension data field would not be > used, or it would only be used in one single way. For instance, > I think it > is unlikely that some packets in an RTP session would have extension data > for parity FEC, while other packets in the same session would use > Reed-Solomon FEC. > > So, when SDP indicates that there are 0-1 valid values for the XT > field, the > RTP receiver can effectively ignore the field. Thus, the problem with the > additional multiplexing point becomes a non-issue in the typical case. > I agree that the number of eXTension types are limited to a small number. Typical "use cases" for the XT field can be 1. Providing the FEC information 2. In-band signaling of sth. (e.g. change of time-resolution, change the XOR mask, ... ) For us the typical case is that some PDUs are protected with FEC ("High Prioroty data") and some are not. Or some are more protected than others, so we want to use Unequal Error Protection (UEP) depending on the media importance. We assume for that it there is some mechanism above the "payload creation layer" that provides AccessUnits together with a priority similar to the Elementary Stream Interface in MPEG4. > Given this, one could argue that the XT field should be removed, although > that would give up some flexibility that could be useful in the > future. In > any case, it seems clear that 8 bits is an excessively large size for this > field. > the sizes of the fields are open for discussion... > I would also like to second Jonathan Rosenberg's comment, that it > is better > to specify the format of the extension data field by referring to the > relevant documents, rather than including the text explicitly in this > Internet-Draft. Of course, there might be cases where no > relevant document > exists. In those cases, it might still be better to publish the format of > the extension data field in a different document, which would be separate > from the document that specifies the Generic Payload Format. > We just wanted to give some examples of the use of the XT type to make it more clear. It is just more convenient to read the data inside the document rather than specifying a reference with section number. There are also some slight changes to the format from Rosenberg and there will be possibly some more. As mentioned above I think the mask in the FEC payload changes maybe not so often or never and can be transmitted separately with another XT number. > I also have some comments regarding the alignment of the various fields in > the payload format. The primary concern of any payload format that > implements "grouping" or "multiplexing", is to reduce the number > of packets. > The second concern would be to reduce the number of bytes in the payload > format header. This is quite important when very small application units > are grouped together. To achieve this second goal, I think most people > would accept giving up word alignment of header fields, as long as the > header fields are still aligned to byte boundaries. > Agreed. > In this payload format, however, individual header fields are not byte > aligned. Padding is inserted at the end of the last header field > to ensure > that the payload begins at a byte boundary. I know that byte alignment is > not an issue in the MPEG world (Just look at the MPEG-4 SL-Packet header > definition and you will be either horrified or delighted, > depending on where > you come from) but in the IETF header fields are typically aligned. > I insisted on byte alignment of the payload because I have to implement it... > I have two different proposals for how the header syntax can be modified. > Both proposals ensure that header fields are byte aligned, but they work a > little bit differently. The proposals all show that byte alignment can be > achieved at a maximum cost of one byte, sometimes even less. > We haven't looked in that detail on the fields (problems with the deadline...) so we appreciate any comments on that. > Proposal 1: > > * Reduce the XT field from 8 bits to 6 bits. As discussed earlier, it is > hard to conceive of a situation where someone would want more than 64 > different kinds of Extension Data in the same RTP session. > > * If E=0, insert a new field with 5 bits, directly following the F field. > The 5 bits are reserved and should always be set to 0. > > * The size of the LENGTH field is increased from 13 to 16 bits. > > This causes all header fields to be aligned with byte boundaries. No > padding field is necessary. This comes at a cost, however. If > you look at > example #3 in draft-guillemot-genpayload-00.txt, you might see that the > second header, which consists only of flags and a LENGTH field, will > increase from two bytes to three bytes. And this is a fairly common case, > because it happens whenever the packet consists of extension data and an > application unit that is not being fragmented. > We optimised for that case (it is assumed to be the most common one) but we still feel not satisfied with the header fields sizes. So thank you for you comment. > Proposal 2: > > * Reduce the XT field from 8 bits to 6 bits. See comment above. > > * If E=1, increase the size of the LENGTH field from 13 to 16 bits. > > * If E=0, the size of the LENGTH field remains at 13 bits. > > * If G=0 and E=0, the size of TSOFFSET is reduced from 16 to 13 bits. > > * If G=1 or E=1, the size of TSOFFSET remains at 16 bits. > > * If the FOFFSET field would directly follow the flag fields (because > neither LENGTH nor TSOFFSET is present), insert 5 reserved bits > in front of > FOFFSET, instead of adding 5 bits of padding at the end of FOFFSET. > > This causes all header fields to be aligned with byte boundaries. > And this > comes at no extra cost in terms of the header size. As a matter of fact, > this scheme saves one entire byte when the payload header only > contains the > TSOFFSET field. (See example #1, in > draft-guillemot-genpayload-00.txt.) Of > course, you may already have noticed that there is another kind of cost > associated with this proposal: complexity. > For me it seems a bit too complex. Again thank you for your comments. > Anders > > Stefan. -- Computer centre University of Stuttgart Stefan Wesner http://www-ks.rus.uni-stuttgart.de/PKB Allmandring 3a mailto:wesner@rus.uni-stuttgart.de 70550 Stuttgart Tel.: +49 711 685 4275 Fax.: +49 711 678 8363 From rem-conf Mon Dec 14 09:54:47 1998 From rem-conf-request@es.net Mon Dec 14 09:54:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpc6g-0006Rq-00; Mon, 14 Dec 1998 09:48:30 -0800 Received: from labredes14.dif.um.es [155.54.12.168] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpc6d-0006R1-00; Mon, 14 Dec 1998 09:48:28 -0800 Received: from labredes14.dif.um.es (pedrom@localhost [127.0.0.1]) by labredes14.dif.um.es (8.8.7/8.8.7) with ESMTP id SAA04623 for ; Mon, 14 Dec 1998 18:46:36 +0100 Message-Id: <199812141746.SAA04623@labredes14.dif.um.es> X-Mailer: exmh version 2.0.2 From: Pedro Miguel Ruiz Martinez To: rem-conf@es.net Subject: Vic on video4linux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Dec 1998 18:46:36 +0100 Sender: pedrom@labredes14.dif.um.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, Does anybody know where can I find vic on video4linux? Thanks, -------------------------------------------------------------------- Pedro Miguel Ruiz Martinez Laboratorio de Redes Facultad de Informatica Universidad de Murcia Tlf +34 968364644 Spain -------------------------------------------------------------------- From rem-conf Mon Dec 14 11:00:17 1998 From rem-conf-request@es.net Mon Dec 14 11:00:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpdA8-0007e3-00; Mon, 14 Dec 1998 10:56:08 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpdA7-0007dt-00; Mon, 14 Dec 1998 10:56:07 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Dec 14 13:55:48 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id NAA26522; Mon, 14 Dec 1998 13:55:47 -0500 (EST) Message-ID: <36755EA2.DB615A63@dnrc.bell-labs.com> Date: Mon, 14 Dec 1998 13:53:22 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Gal Ashour CC: Neal Schneider , rem-conf@es.net Subject: Re: RTP (multiplexing) Proposals - comparison References: <422566D7.00815A55.00@hrlsmtp.haifa.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gal Ashour wrote: > > Both simplicity and efficiency are important, which is the exact reason > that I suggested to concentrate on the two proposals that represent each of > those two categories (with a possibility of a later merger). > They both also share a common important characteristic, which is not losing > information from the original RTP header. Implicit in this statement is the assumption that we are not designing a gateway to gateway protocol. Not that I'm saying we shouldn't design a more general purpose one (as we want one for MPEG4, for example); what I am saying is that for G2G, you can get better efficiencies and less complexity than a more general purpose one. You should also note that its not so clear how much efficiency germ will provide. The SSRC and timestamps both won't compress well when used with silence suppression, I suspect. As a result, it was decided that we need to run some simulations to understand real performance under varying conditions. Germ in particular has performance very much dependent on dynamic effects, less so for the others. But, depending on your assumptions (such as changing of lengths or encodings), the various proposals will have quite a variance in performance. I welcome thoughts on the models/assumptions for the simulations. > > The Hitachi proposal may well be enhanced in the future, but it has merit > even as is. The difference between 59% bandwidth reduction and 43% (as is > the case for G.723 under the assumption in my previous posting) is not > negligible, but yet it isn't a huge difference neither. I'm not sure the Hitachi proposal is within scope. Its not really an RTP mux protocol so much as a UDP mux protocol, and its missing some stuff for that anyway (port numbers, length fields). This was discussed during the meeting on Friday. Dean Willis presented a mux protocol that filled in the gaps, in fact. It was also mentioned that there may already be UDP mux protocols.... -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Dec 14 11:56:30 1998 From rem-conf-request@es.net Mon Dec 14 11:56:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpe3g-0000vV-00; Mon, 14 Dec 1998 11:53:32 -0800 Received: from wya-lfd93.hotmail.com (hotmail.com) [207.82.252.157] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpe3f-0000vC-00; Mon, 14 Dec 1998 11:53:31 -0800 Received: (qmail 10340 invoked by uid 0); 14 Dec 1998 19:52:26 -0000 Message-ID: <19981214195226.10337.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 14 Dec 1998 11:52:22 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: ASHOUR@HAIFA.VNET.IBM.COM, jdrosen@dnrc.bell-labs.com Cc: nschneid@hotmail.com, rem-conf@es.net Subject: Re: RTP (multiplexing) Proposals - comparison MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 14 Dec 1998 11:52:22 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Implicit in this statement is the assumption that we are not designing a >gateway to gateway protocol. Not that I'm saying we shouldn't design a >more general purpose one (as we want one for MPEG4, for example); what I >am saying is that for G2G, you can get better efficiencies and less >complexity than a more general purpose one. You should also note that >its not so clear how much efficiency germ will provide. The SSRC and >timestamps both won't compress well when used with silence suppression, >I suspect. Perhaps two multiplexing formats should become standard for RTP. One specific to the G2G configuration; the other more general purpose. Clearly there are efficiency advantages to the gateway proposals which should not be ignored (utilizing overall timestamps, sequence numbers, etc.) A more general purpose proposal would have to be more flexible in order to handle less correlated channels, which will cause less efficiency. Separating the two (G2G and general) might be a good idea at this time, since G2G currently commands the largest need for multiplexing. >in the gaps, in fact. It was also mentioned that there may already be >UDP mux protocols.... > This would be a good solution for the general case, retaining all of the necessary RTP information. Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Mon Dec 14 14:22:22 1998 From rem-conf-request@es.net Mon Dec 14 14:22:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpgJs-0002RK-00; Mon, 14 Dec 1998 14:18:24 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpgJq-0002R8-00; Mon, 14 Dec 1998 14:18:23 -0800 Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 5617; Mon, 14 Dec 98 17:18:16 2 E Received: by HAIFA (XAGENTA 4.0) id 9447; Tue, 15 Dec 1998 00:16:53 +0200 Received: from hrlsmtp.haifa.ibm.com by mail.haifa.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA117524; Tue, 15 Dec 1998 00:20:27 +0200 Received: by hrlsmtp.haifa.ibm.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 422566DA.007A45C1 ; Tue, 15 Dec 1998 00:15:32 +0200 X-Lotus-Fromdomain: IBMHAIFA From: "Gal Ashour" To: Jonathan Rosenberg Cc: Neal Schneider , rem-conf@es.net Message-Id: <422566DA.007A4441.00@hrlsmtp.haifa.ibm.com> Date: Tue, 15 Dec 1998 00:12:57 +0200 Subject: Re: RTP (multiplexing) Proposals - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: > >Implicit in this statement is the assumption that we are not designing >a gateway to gateway protocol. Not that I'm saying we shouldn't design a >more general purpose one (as we want one for MPEG4, for example); what >I am saying is that for G2G, you can get better efficiencies and less >complexity than a more general purpose one. You should also note that >its not so clear how much efficiency germ will provide. The SSRC and >timestamps both won't compress well when used with silence suppression, >I suspect. Even if you focus on a G2G scenario, I think that when supporting conferencing you may well consider the need of CSRC fields in order to identify several sources streamed out from an MCU in a single payload. Identifying those sources in the endpoint clients seems an important feature to me (or at least one that I wouldn't automatically consider 'redundant'). If I didn't miss something, both the Nokia and Bell proposals lack the CC field in their mini-header, and thus there is no easy way to incorporate the CCRC information in each potential block. This is just one example that comes to my mind, while there may well be others (even when limiting ourselves to a G2G scenario). My main focal point is G2G too, but my perspective is a little different. What I would like to see is a one cross-solution RTP-mux format. When used for G2G though, the multiplexer in the sending Gateway may impose additional restrictions on its input streams, while producing the output multiplexed stream - as it sees fit. Thus, if changes in timestamps are 'minor enough' for the specific solution to ignore them - it can do so even when using GeRM's scheme. What I'm basically saying is that it should be the application's (or solution's) decision, rather than an apriori lack of support in the format itself. If we finally decide to adopt the GeRM decision, we may achieve two goals: 1. Providing one generic and compatible format for transferring RTP payloads with a low bandwidth overhead (while the content could be MPEG4, G2G IP-Telephony, or anything else that you would consider using above RTP in the first place). 2. Each solution (G2G or other), may decide under which conditions some of the RTP header information is not "very important", and may thus be ignored even when using the GeRM difference scheme. This way we achieve efficiency at least as good as with the Nokia and Bell proposals (and possibly even a slightly better one). Using the above approach you get the desired efficiency, and yet do not compromise on flexibility. Besides, I didn't ignore silence suppression effects when doing the bandwidth reduction calculation for GeRM, which is basically why I put an average of two bytes as GeRM overhead rather than just one (GeRM minimal overhead is a single byte, while the Nokia and Bell proposal require two bytes as the minimum overhead). According to the GeRM scheme the SSRC is divided to two portions (the LSB byte, and the rest 3 MSB). It is likely to assume changes only in the LSB of the SSRC, and thus even when counting for 50% silence, we should expect at worse case an average of half a byte due to the difference coding when using silence suppression. To be on the safe side, I rounded the half byte in one calculation to one byte, and adding it to the GeRM header byte I got an overhead of two bytes (which is similar to the best case mini-header overhead when using either the Nokia or Bell proposals). Besides, from your excellent (and I do mean it) work regarding the mux issues, I recall that you mentioned that even during silence periods, coders may choose to force some information in order to produce a natural background noise on the other end. In this scenario silence suppression counts even less in respect to the GeRM proposal (since packets are produced even during silence). > > I'm not sure the Hitachi proposal is within scope. Its not really an RTP > mux protocol so much as a UDP mux protocol, and its missing some stuff > for that anyway (port numbers, length fields). > I am new to the avt WG, but thought that its charter is providing means for transporting audio and video streams. I'm not sure if I care if the proposal that is eventually adopted by the group falls into the UDP-mux category or the RTP-mux category. The target, as I understand it, is not to provide 'RTP-mux' format per se, but rather a format that will reduce bandwidth overhead when transmitting 'many' RTP packets. I wish that the chosen format will limit flexibility as little as possible (if at all), and thus be useful even for implementations that we don't think of today - but may need tomorrow. If indeed there are other UDP-mux protocols, then we do need to evaluate them. Still, I'm saying that my own opinion is that out of the 4 original proposals we should now focus on GeRM and the Hitachi proposals (in addition to new proposals that we didn't evaluate yet). The Nokia and Bell proposals incorporate built-in decisions regarding what is necessary and what is not in the original RTP header. If we leave this decision dynamic for the specific solution to decide we get at least as good results using GeRM (if not even slightly better ones). As a last comment, from the calculation that I did for the G.723.1 case (posted earlier to this mailing list), it seems that the typical difference between the efficient schemes of GeRM/Bell/Nokia and the somewhat less efficient scheme of Hitachi is not that dramatic, and may not be such a bad trade-off for its simplicity. Yet, a merged GeRM/Hitachi scheme may eventually result in a powerful format in terms of simplicity, efficiency and (yes) flexibility. By merging I mainly refer to a method for reducing the SSRC field to one byte, which will make the enhanced Hitachi format a little more similar to the other proposal that have an ID field in the order of one byte. Best Regards, -- Gal A. ------------------------------------ Gal Ashour Audio/Video Technologies Group IBM Research - Haifa Research Lab. ISRAEL ashour@haifa.vnet.ibm.com ------------------------------------ From rem-conf Mon Dec 14 14:58:49 1998 From rem-conf-request@es.net Mon Dec 14 14:58:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpguB-0003KN-00; Mon, 14 Dec 1998 14:55:55 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpguA-0003KD-00; Mon, 14 Dec 1998 14:55:54 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id AAA21485; Tue, 15 Dec 1998 00:54:19 +0200 (EET) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA273596098; Mon, 14 Dec 1998 17:54:58 -0500 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Dec14.174500.1991.411133; Mon, 14 Dec 1998 17:52:24 -0500 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: ASHOUR@HAIFA.VNET.IBM.COM (Gal Ashour), casner@cisco.com (casner), rem-conf@es.net (rem-conf) Message-Id: <1998Dec14.174500.1991.411133@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Mon, 14 Dec 1998 17:52:24 -0500 Subject: RE: RTP Proposal - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I appreciate your effort in presenting arguments with numbers. At the same = = time I have to say that efficiency you have indicated is not correct. = Efficiency varies under different conditions with each proposal. You can = look closely the GerM draft and see how it changes when Gateways co-operate = = and when they don't cooperate. >From my point of view, we need a solution that suits G2G when the G = interconnect clouds of PSTN or GSM users (non RTP sources). At this moment, = = IP is being deployed in the infrastructure and what we need is a solution = that meets the requirements of such scenario. In this case, many fields in = the RTP headers can be considered as common for all sources multiplexed = within a packet. For example, RTP SN is useful for insequence delivery of = packets between gateways. Multiplexing in UDP is possible if we have larger = = header (most prob. subset of RTP header). We chose RTP since we do not want = = to reinvent the wheel. An optimized solution that satisfies the large market= = should be considered. I have to second Steve Casner comment on an earlier mail that what we are = trying to do is an interim solution. When we have full blown IP model and = voice traffic becomes tiny compared to data traffic, RTP multiplexing will = not make any sense. However, until we reach that point we need to encourage = = vendors and operators to deploy IP based infrastructure in the network. Also, I have to say that when we have RTP sources, it is better to use = compression from the source rather than at some aggregation point. In = general, bottleneck is in the access side of the network. regards, Barani Subbiah Nokia Research ---------- From: Gal Ashour To: casner; rem-conf Subject: RTP Proposal - comparison Date: Friday, December 11, 1998 2:10PM Following the avt discussion earlier today, we were requested to list scenarios for using RTP-multiplexing. My main interest is audio IP-Telephony, but I think that the RTP multiplexing applies in general to implementations that require real-time (or at least quick enough) response on one hand, and have a relatively short payload on the other hand (and thus the headers, IP/UDP and possibly the RTP, become a significant overhead). Scott's signalling proposal (if adopted) could become a candidate for using= this mechanism too since it falls into the category above. I will use the G.723.1 codec for comparison of the different proposals. For G.723 I assume in the calculation 24 bytes per payload (generated every= 30 msec). The results may change a little based on the payload size for other codecs,= but I do not think that it will result in a dramatic change of the picture.= Before I go on with the numbers, I would suggest that a higher weight should be given to scenarios that use a relatively short payload, rather than those who use large ones (which may be the case with Video and Data), since the main advantage in RTP multiplexing is for applications that have short payload and thus the header overhead is their main concern. I will assume X simultaneous calls, all using the same codec and payload length (just for simplicity of the calculation) - I think that this assumption is reasonable, and should not distort the general picture we get= >from the comparison. PFS stands hereby for Payload Frame Size, and eventually will be given the value 24 (per the above codec assumption). Hitachi proposal: -------------------------- Advantages: Very simple to implement, do not loose any information originally in the RTP header (since it is multiplex as is). Bandwidth Requirements: Without RTP Multiplexing =3D (40+PFS)*X With RTP Multiplexing =3D 28 + (12+PFS)*X (28 stands for IP+UDP headers). Asymptotic Bandwidth reduction (large X): 1- (12+PFS)/(40+PFS) Assuming PFS=3D24: Asymptotic Bandwidth reduction: 1- (36)/(64)=3D 43 % GeRM Proposal: _______________ Advantage: All the information in the original RTP header can be reconstructed, High compression ratio. Bandwidth Requirements: Without RTP Multiplexing =3D (40+PFS)*X With RTP Multiplexing =3D 28+12+ (1+ 1+PFS)*X ( The first '1' stands for the GeRM 1-byte Header, the second '1' stands for payload type for the first block, and for the LSB of the SSRC which may be= needed due to silence characteristics for= the other blocks (we could even use 0.5 byte on average as a worse case) ). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=3D24: Asymptotic Bandwidth reduction: 1- (26)/(64)=3D 59 % Bell Proposal: ____________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing =3D (40+PFS)*X With RTP Multiplexing =3D 28+12+ (2+PFS)*X (The '2' stands f= or the minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=3D24: Asymptotic Bandwidth reduction: 1- (26)/(64)=3D 59 % Since the CC field is not in the mini-header it may imply that no CSRC information is transferred - which may be a disadvantage in some centralized conferencing scenarios where we may have several contributor sources to the same payload (and wish to identify them in the application).= Also timestamp information may be of importance, but do not fit into the mini header. Nokia Proposal ______________ Advantage: High compression ratio Bandwidth Requirements: Without RTP Multiplexing =3D (40+PFS)*X With RTP Multiplexing =3D 28+ (2+PFS)*X (The '2' stands for th= e minimal mini-header per block, i.e no need for 16-bit length). Asymptotic Bandwidth reduction (large X): 1- (2+PFS)/(40+PFS) Assuming PFS=3D24: Asymptotic Bandwidth reduction: 1- (26)/(64)=3D 59 % Again, since the CC field is not in the mini-header it may imply that no CSRC information is transferred, which may be a disadvantage in some centralized conferencing scenarios where we may have several contributions to the same payload. Also timestamp information may be of importance, but do not fit into the mini header. This proposal limits the length field is to only 5 bits (which= may be a limitation for payload scenarios that are slightly longer than 31 bytes, and could still benefit from multiplexing). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D My Perspective: _______________ I think that all the four proposals are basically good ones, but we need to= go forward. It seem that three of the proposals fit into the 'high bandwidth reduction'= category, while the Hitachi fits into a 'medium bandwidth reduction category'. Two of the 'high bandwidth reduction' proposals are lossy in respect to the= RTP header information, and thus may limit their use in comparison to the GeRM and Hitachi's proposal that are 'lossless' in that respect. I would suggest to proceed with two of the proposals: GeRM and Hitachi, since they both don't loose RTP header information, and represent the two ends of simplicity vs. high compression. Once the GeRM proposal is completed (like ID negotiation issue), we may decide which of the two is preferred. As for the RTCP issue. I think that the information is still valid in respect to the 'global' packet, and can be associated with the timestamp of the first block in each multiplexed packet. Best Regards, -- Gal. ------------------------------------------------------- Gal Ashour Audio/Video Group IBM Research - Haifa Research Lab. ISRAEL ashour@haifa.vnet.ibm.com ------------------------------------------------------- From rem-conf Mon Dec 14 15:46:33 1998 From rem-conf-request@es.net Mon Dec 14 15:46:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zphcl-0004Gg-00; Mon, 14 Dec 1998 15:41:59 -0800 Received: from wya-lfd85.hotmail.com (hotmail.com) [207.82.252.149] by mail1.es.net with smtp (Exim 1.81 #2) id 0zphck-0004Fw-00; Mon, 14 Dec 1998 15:41:58 -0800 Received: (qmail 12942 invoked by uid 0); 14 Dec 1998 23:40:28 -0000 Message-ID: <19981214234028.12941.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Mon, 14 Dec 1998 15:40:28 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: rem-conf@es.net, subbiah@NASBPD01BS.ntc.nokia.com Subject: RE: RTP Proposal - comparison MIME-Version: 1.0 Content-Type: text/plain Date: Mon, 14 Dec 1998 15:40:28 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Also, I have to say that when we have RTP sources, it is better to use = >compression from the source rather than at some aggregation point. In = >general, bottleneck is in the access side of the network. > >regards, > >Barani Subbiah >Nokia Research What if the aggregation point is the access side of the network (i.e. IP phones hanging off of a Lan). It wouldn't make sense to put compression inside 250 IP phones if you only needed it for a few outside lines. --Neal ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Mon Dec 14 16:07:04 1998 From rem-conf-request@es.net Mon Dec 14 16:07:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zphy8-0005A8-00; Mon, 14 Dec 1998 16:04:04 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zphy6-00059y-00; Mon, 14 Dec 1998 16:04:02 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Dec 14 19:02:04 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id TAA28071; Mon, 14 Dec 1998 19:02:00 -0500 (EST) Message-ID: <3675A664.321907D6@dnrc.bell-labs.com> Date: Mon, 14 Dec 1998 18:59:32 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Gal Ashour CC: Neal Schneider , rem-conf@es.net Subject: Re: RTP (multiplexing) Proposals - comparison References: <422566DA.007A4441.00@hrlsmtp.haifa.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gal Ashour wrote: > > Jonathan Rosenberg wrote: > > > >Implicit in this statement is the assumption that we are not designing > >a gateway to gateway protocol. Not that I'm saying we shouldn't design a > >more general purpose one (as we want one for MPEG4, for example); what > >I am saying is that for G2G, you can get better efficiencies and less > >complexity than a more general purpose one. You should also note that > >its not so clear how much efficiency germ will provide. The SSRC and > >timestamps both won't compress well when used with silence suppression, > >I suspect. > > Even if you focus on a G2G scenario, I think that when supporting > conferencing you may well consider the need of CSRC fields in order to > identify several sources streamed out from an MCU in a single payload. > Identifying those sources in the endpoint clients seems an important > feature to me (or at least one that I wouldn't automatically consider > 'redundant'). If I didn't miss something, both the Nokia and Bell proposals > lack the CC field in their mini-header, and thus there is no easy way to > incorporate the CCRC information in each potential block. > This is just one example that comes to my mind, while there may well be > others (even when limiting ourselves to a G2G scenario). I'm not sure I see how this works. Where is the MCU, and where is the gateway? Are you saying an RTP mixer sends RTP to a gateway, which then sends it on an RTP trunk to another gateway? I'm not clear on how the mixer and gateway are interacting here. > Besides, I didn't ignore silence suppression effects when doing the > bandwidth reduction calculation for GeRM, which is basically why I put an > average of two bytes as GeRM overhead rather than just one (GeRM minimal > overhead is a single byte, while the Nokia and Bell proposal require two > bytes as the minimum overhead). > According to the GeRM scheme the SSRC is divided to two portions (the LSB > byte, and the rest 3 MSB). It is likely to assume changes only in the LSB > of the SSRC, and thus even when counting for 50% silence, we should expect > at worse case an average of half a byte due to the difference coding when > using silence suppression. Yes, but its not just the SSRC. The SN is also affected. It will quickly diverge (even if all users start with the same SN) and I think will be completely uncompressable. Thats another 16 bits for every muxed user. We could possibly do something about this by imroving the compression. I wonder if we actually tried real compression if this would help. In other words, treat the RTP headers as a piece of data, and run Lempel Ziv on it. I wonder if it would be better or worse than germ under various scenarios. Or, one could use a generic UDP mux and then apply IP payload compression.... -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Dec 14 20:03:24 1998 From rem-conf-request@es.net Mon Dec 14 20:03:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zplcO-0007Ps-00; Mon, 14 Dec 1998 19:57:52 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zplcM-0007Pi-00; Mon, 14 Dec 1998 19:57:50 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.1/8.9.1) with ESMTP id MAA25056 for ; Tue, 15 Dec 1998 12:57:47 +0900 (JST) Message-Id: <199812150357.MAA25056@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: Vic on video4linux? In-reply-to: Your message of "Mon, 14 Dec 1998 18:46:36 +0100." <199812141746.SAA04623@labredes14.dif.um.es> Content-ID: <25013.913693957.0@aohakobe.ipc.chiba-u.ac.jp> Date: Tue, 15 Dec 1998 12:57:46 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Does anybody know where can I find vic on video4linux? Patrick Vielle said in the message to MBONE mailing list (Sep.22, 1998) Patrick> Also there is a VIC compiled for video4linux which I have'nt tried. Patrick> Patrick> http://user.cs.tu-berlin.de/~kraxel/linux/ try and tell us if it's usable or not (-: -- yozo. From rem-conf Tue Dec 15 06:48:33 1998 From rem-conf-request@es.net Tue Dec 15 06:48:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpvZo-0003dU-00; Tue, 15 Dec 1998 06:35:52 -0800 Received: from cassiopeia.hkstar.com [202.82.3.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpvZm-0003dK-00; Tue, 15 Dec 1998 06:35:50 -0800 Received: from mailsystem.com ([202.82.41.19]) by cassiopeia.hkstar.com (8.9.1/8.9.1) with ESMTP id WAA12116; Tue, 15 Dec 1998 22:35:15 +0800 (HKT) Received: from ukuu.ucplh.lheq.com [11.12.13.14] by emailgun.com (FTGate 2, 1, 1, 0); Tue, 15 Dec 98 21:27:36 +0800 Message-Id: <199812152115.TGF5451@ukuu.ucplh.lheq.com> Date: Tue, 15 Dec 1998 09:15:52 PM Subject: 20 Asian Girl Pictures a day !! X-UIDL: 870483344.852 From: ytoknk@hjbk.kyqwk.wkpk.com Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IF YOU ARE UNDER 21 DELETE NOW! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As a Preferred User, you're invited to attend the http://195.224.181.171/andorra/gilbert/default.html 20 Asian Girl Pictures a day !! All models are at least 18 years of age! From rem-conf Tue Dec 15 09:29:25 1998 From rem-conf-request@es.net Tue Dec 15 09:29:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpyBj-0005Gz-00; Tue, 15 Dec 1998 09:23:11 -0800 Received: from vnet.ibm.com [204.146.168.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0zpyBf-0005Gp-00; Tue, 15 Dec 1998 09:23:08 -0800 Received: from HAIFA by VNET.IBM.COM (IBM VM SMTP V2R4) with BSMTP id 8156; Tue, 15 Dec 98 12:23:02 2 E Received: by HAIFA (XAGENTA 4.0) id 0304; Tue, 15 Dec 1998 19:22:47 +0200 Received: from hrlsmtp.haifa.ibm.com by mail.haifa.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA123064; Tue, 15 Dec 1998 19:26:11 +0200 Received: by hrlsmtp.haifa.ibm.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 422566DB.005F5037 ; Tue, 15 Dec 1998 19:21:04 +0200 X-Lotus-Fromdomain: IBMHAIFA From: "Gal Ashour" To: Jonathan Rosenberg , subbiah@NASBPD01BS.ntc.nokia.com Cc: Neal Schneider , rem-conf@es.net Message-Id: <422566DB.005F4F7C.00@hrlsmtp.haifa.ibm.com> Date: Tue, 15 Dec 1998 19:18:35 +0200 Subject: Re: RTP (multiplexing) Proposals - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: > > I'm not sure I see how this works. Where is the MCU, and where is the > gateway? Are you saying an RTP mixer sends RTP to a gateway, which then > sends it on an RTP trunk to another gateway? I'm not clear on how the > mixer and gateway are interacting here. > The example referred to a scenario where one of the Gateways (say Gateway A) is also acting as an MCU for the conference (with a possibility of also several IP and PSTN clients attached to it). In this scenario Gateway A could have several inputs (from its IP clients and from its PSTN clients), it would mix them together and provide the mixed stream to the various clients (one of them could be Gateway B). There is an advantage in using RTP-mux for packets sent between Gateway A and Gateway B. Having valid CSRC fields would allow Gateway B to identify the sources who contributed to a specific payload and pass this information to its own clients. Since both Nokia and Bell's proposal do not carry the CC field in their proposed mini header, there would be no vehicle for carrying this information - a result of a non-flexible format. Actually, the example is not that important, but rather the principle as restated in my second comment below. > Yes, but its not just the SSRC. The SN is also affected. It will quickly > diverge (even if all users start with the same SN) and I think will be > completely uncompressable. Thats another 16 bits for every muxed user. > We could possibly do something about this by imroving the compression. I > wonder if we actually tried real compression if this would help. In > other words, treat the RTP headers as a piece of data, and run Lempel > Ziv on it. I wonder if it would be better or worse than germ under > various scenarios. Or, one could use a generic UDP mux and then apply IP > payload compression.... > Sure, but then you can reflect to comments regarding timestamps in my previous posting. If SN, timestamps (or any other field for this matter) is not important in a specific context, the SPECIFIC implementation could "mask" the appropriate bit in the GeRM header, and just not send this "not needed" information - this is much better than Lempel-Ziv. In this case the output format from this 'customized GeRM Implementation' will be a 100% compatible with the GeRM format, and still extremely efficient (or at least as efficient as the implementation cares to be). My main point was and is, let us leave the decision of what is "necessary" and what we can "live without" to the specific implementation (which no doubt knows best). The specific implementation can decide (when using GeRM) if a specific portion of a header is worth coding into its output multiplexed stream or not. This will serve us better in the future when using the adopted format in other implementation, each with its own flavor of which segment of the RTP header is important and which is not. I think that it is a wrong approach to make the application's life "easy" by limiting the format... Barani Subbiah Wrote: > > At this moment, IP is being deployed in the infrastructure and what we need is a solution that > meets the requirements of such scenario. In this case, many fields in the RTP headers can be > considered as common for all sources multiplexed within a packet. For example, RTP SN is useful > for insequence delivery of packets between gateways. > See my comment above. If a field is common or its change is not of 'real significance', no penalty in GeRM either - the implementation can easily enough ignore the change and still produce a perfectly legal output as much as the (GeRM) format is concerned. > I have to second Steve Casner comment on an earlier mail that what we are trying to do is an > interim solution. When we have full blown IP model and voice traffic becomes tiny compared to > data traffic, RTP multiplexing will not make any sense. However, until we reach that point we > need to encourage vendors and operators to deploy IP based infrastructure in the network. > Also, I have to say that when we have RTP sources, it is better to use compression from the > source rather than at some aggregation point. In general, bottleneck is in the access side of > the network. > If we wouldn't have GeRM on the table, you may have got my vote. I do not believe in interim solutions if we can get at about the same time a solution that will serve us better and longer. Both GeRM and Hitachi can be available as soon as we want to (or at least as quickly as the other proposals). The difference between the Hitachi and the other three proposals in terms of efficiency, could become quite small once enhanced a little. Even as is, the Hitachi proposal provides a significant reduction in bandwidth requirements. It may be (but then maybe not) that it is worth to go into some complexities in order to squeeze the percentage even more - this is by all means an open question that in my opinion needs to be addressed by the group. If we decide we need to squeeze every byte, using the GeRM format will probably serve us at least as well as the Nokia and Bell's proposals (taking into account the implementation's ability to mask unimportant differences). If on the other hand we decide that we can live with a simpler (and less efficient) format, we can get it from the Hitachi's proposal (or possibly other UDP-mux formats - if available). Best Regards, -- Gal. (ashour@haifa.vnet.ibm.com) ------------------------------------ Gal Ashour Audio/Video Technologies Group IBM Research - Haifa Research Lab. ISRAEL ashour@haifa.vnet.ibm.com ------------------------------------ From rem-conf Tue Dec 15 10:43:00 1998 From rem-conf-request@es.net Tue Dec 15 10:43:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpzMD-0006PU-00; Tue, 15 Dec 1998 10:38:05 -0800 Received: from sumo.vocaltec.co.il [199.203.72.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpzMB-0006PK-00; Tue, 15 Dec 1998 10:38:04 -0800 Received: from il4.vocaltec.co.il (notesgw.vocaltec.co.il [199.203.72.136]) by sumo.vocaltec.co.il (8.8.5/8.6.12) with SMTP id UAA09258; Tue, 15 Dec 1998 20:31:25 +0200 (IST) Received: by il4.vocaltec.co.il(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 422566DB.00660F5A ; Tue, 15 Dec 1998 20:34:46 +0200 X-Lotus-FromDomain: VOCALTEC From: "Elad Sion" To: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) cc: rem-conf@es.net Message-ID: <422566DB.006535D7.00@il4.vocaltec.co.il> Date: Tue, 15 Dec 1998 20:32:34 +0200 Subject: RE: RTP Proposal - comparison Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -------- On 14/12/98 10:52 PM GMT subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) wrote: >Also, I have to say that when we have RTP sources, it is better to use compression >from the source rather than at some aggregation point. In general, bottleneck is in >the access side of the network. > >regards, > >Barani Subbiah >Nokia Research Just by removing the IP and UDP headers, you already save major overhead as far as bandwidth is concerned. The more important thing to save is, I think, the number of IP packets in order to reduce the amount of forwarding decisions done in the router. Does anybody know of a good IP simulation device/software that can be used to test various mux scenarios? -- Elad. From rem-conf Tue Dec 15 10:56:28 1998 From rem-conf-request@es.net Tue Dec 15 10:56:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zpzc9-0006vA-00; Tue, 15 Dec 1998 10:54:33 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zpzc8-0006uu-00; Tue, 15 Dec 1998 10:54:32 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id UAA23193; Tue, 15 Dec 1998 20:49:16 +0200 (EET) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA052807783; Tue, 15 Dec 1998 13:49:43 -0500 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Dec15.134614.1991.412352; Tue, 15 Dec 1998 13:47:06 -0500 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: nschneid@hotmail.com (Neal Schneider), rem-conf@es.net (rem-conf) Message-Id: <1998Dec15.134614.1991.412352@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Tue, 15 Dec 1998 13:47:06 -0500 Subject: RE: RTP Proposal - comparison X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I assume you are not referring to IP phones on LAN to PSTN. In case of IP phones connected on LANs via some IP trunk then we are = looking at different functionalities. Basically, you strip of the RTP packet= = coming to your ingress aggregation point and then try to multiplex. At the = egress point you need reconstruct the full RTP header. There are few things to note. With this scheme 1. Time stamps will more likely different since generated at source. 2. SN will be different. and we need to regenerate the SN at the egress = point. 3. In terms of H.323 signaling, we need 3 signaling procedure to setup a = connection 1)Source - Ingress point - 2) Ingress - egress 3) egress to = destination My argument is that you get more efficiency using compression at the source= = than at some where in the middle. regards, Barani Subbiah Nokia Research ---------- From: Neal Schneider To: Subbiah Baranitharan (NRC/Bos); rem-conf Subject: RE: RTP Proposal - comparison Date: Monday, December 14, 1998 3:40PM >Also, I have to say that when we have RTP sources, it is better to use =3D >compression from the source rather than at some aggregation point. In =3D >general, bottleneck is in the access side of the network. > >regards, > >Barani Subbiah >Nokia Research What if the aggregation point is the access side of the network (i.e. IP phones hanging off of a Lan). It wouldn't make sense to put compression inside 250 IP phones if you only needed it for a few outside lines. --Neal ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Tue Dec 15 12:48:31 1998 From rem-conf-request@es.net Tue Dec 15 12:48:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1IR-0000lg-00; Tue, 15 Dec 1998 12:42:19 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zq1IQ-0000lW-00; Tue, 15 Dec 1998 12:42:18 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Dec 1998 20:42:06 +0000 To: rem-conf@es.net Subject: Slides from Orlando AVT meeting Date: Tue, 15 Dec 1998 20:42:06 +0100 Message-ID: <2074.913754526@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Most of the slides presented at the AVT meeting in Orlando are now available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/. The remainder will become available as soon as I receive copies. Colin From rem-conf Tue Dec 15 13:11:31 1998 From rem-conf-request@es.net Tue Dec 15 13:11:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1iF-0001aC-00; Tue, 15 Dec 1998 13:08:59 -0800 Received: from miro.mew.com [158.118.10.10] by mail1.es.net with smtp (Exim 1.81 #2) id 0zq1iE-0001a2-00; Tue, 15 Dec 1998 13:08:58 -0800 Received: from dali.ca.mew.com by miro.mew.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 15 Dec 1998 21:08:58 UT Received: (from claude@localhost) by ca.mew.com (8.9.1a/8.9.1a-SuperSafe) id NAA04550 for rem-conf@es.net; Tue, 15 Dec 1998 13:08:57 -0800 (PST) From: Claude Huss Message-Id: <199812152108.NAA04550@ca.mew.com> Subject: remove claude@mew.com To: rem-conf@es.net Date: Tue, 15 Dec 1998 13:08:57 -0800 (PST) X-Disclaimer: Opinions expressed here are strictly my own X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Tue Dec 15 13:14:19 1998 From rem-conf-request@es.net Tue Dec 15 13:14:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1mw-0001qE-00; Tue, 15 Dec 1998 13:13:50 -0800 Received: from dns2.anl.gov [146.139.254.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq1mv-0001q1-00; Tue, 15 Dec 1998 13:13:49 -0800 Received: from ipdlink.ipd.anl.gov (ipdlink.ipd.anl.gov [146.137.140.101]) by dns2.anl.gov (8.8.7/8.6.11) with SMTP id PAA28102 for ; Tue, 15 Dec 1998 15:13:48 -0600 (CST) From: jcullen@ipdlink.ipd.anl.gov Received: from ccMail by ipdlink.ipd.anl.gov (ccMail Link to SMTP R8.11.00.3) id AA913756530; Tue, 15 Dec 98 15:15:33 -0600 Message-Id: <9812159137.AA913756530@ipdlink.ipd.anl.gov> X-Mailer: ccMail Link to SMTP R8.11.00.3 Date: Tue, 15 Dec 98 15:11:10 -0600 To: Subject: Request for M-Bone session MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have been requested to do an M-Bone multicast tomorrw for an all-day seminar on the Next Generation Internet Forum. We will be broadcasting from 8:45 am until 4:00 pm Central Standard Time with a long lunch break. From rem-conf Tue Dec 15 13:15:57 1998 From rem-conf-request@es.net Tue Dec 15 13:15:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1oa-00024d-00; Tue, 15 Dec 1998 13:15:32 -0800 Received: from dns2.anl.gov [146.139.254.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq1oZ-00023i-00; Tue, 15 Dec 1998 13:15:31 -0800 Received: from ipdlink.ipd.anl.gov (ipdlink.ipd.anl.gov [146.137.140.101]) by dns2.anl.gov (8.8.7/8.6.11) with SMTP id PAA28181 for ; Tue, 15 Dec 1998 15:15:30 -0600 (CST) From: jcullen@ipdlink.ipd.anl.gov Received: from ccMail by ipdlink.ipd.anl.gov (ccMail Link to SMTP R8.11.00.3) id AA913756631; Tue, 15 Dec 98 15:17:14 -0600 Message-Id: <9812159137.AA913756631@ipdlink.ipd.anl.gov> X-Mailer: ccMail Link to SMTP R8.11.00.3 Date: Tue, 15 Dec 98 15:12:52 -0600 To: Subject: Request for M-Bone session MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have been requested to do an M-Bone multicast tomorrw for an all-day seminar on the Next Generation Internet Forum. We will be broadcasting from 8:45 am until 4:00 pm Central Standard Time with a long lunch break. Jim Cullen jcullen@anl.gov Argonne National Laboratory Argonne, IL 60439 630-252-5600 From rem-conf Tue Dec 15 13:16:44 1998 From rem-conf-request@es.net Tue Dec 15 13:16:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1pM-0002HG-00; Tue, 15 Dec 1998 13:16:20 -0800 Received: from mail2.fw-bc.sony.com [198.83.177.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq1pL-00020F-00; Tue, 15 Dec 1998 13:16:19 -0800 Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail2.fw-bc.sony.com (8.8.8/8.8.8) with ESMTP id NAA03156 for ; Tue, 15 Dec 1998 13:15:15 -0800 (PST) Received: by mail2.sjc.in.sel.sony.com id NAA23312; Tue, 15 Dec 1998 13:15:14 -0800 (PST) Received: from deniz.sisrl.sel.sony.com by mediac2 (SMI-8.6/SMI-SVR4) id MAA06636; Tue, 15 Dec 1998 12:57:44 -0800 Message-ID: <001401be286f$e20657e0$600a862b@deniz.sisrl.sel.sony.com> From: "Sadik Bayrakeri" To: Subject: remove sadik@usrl.sony.com Date: Tue, 15 Dec 1998 13:14:20 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01BE282C.D36D99C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BE282C.D36D99C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0011_01BE282C.D36D99C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
------=_NextPart_000_0011_01BE282C.D36D99C0-- From rem-conf Tue Dec 15 13:23:58 1998 From rem-conf-request@es.net Tue Dec 15 13:23:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq1vY-0003mk-00; Tue, 15 Dec 1998 13:22:44 -0800 Received: from smtprich.nortel.com (smtprich) [192.135.215.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq1vX-0003lg-00; Tue, 15 Dec 1998 13:22:43 -0800 Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprich; Tue, 15 Dec 1998 15:21:42 -0600 Received: from zrtpd00x.us.nortel.com by zrtpd00m.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id Y4L00C14; Tue, 15 Dec 1998 16:21:33 -0500 Received: from nrtphf51.us.nortel.com by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id Y4MB78GC; Tue, 15 Dec 1998 16:20:51 -0500 Sender: "Chris Fulmer" Message-ID: <3676D2B4.249A19B5@americasm01.nt.com> Date: Tue, 15 Dec 1998 16:20:53 -0500 From: "Chris Fulmer" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: Slides from Orlando AVT meeting References: <2074.913754526@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list May I suggest that in the future, it would be helpful for slides to be put into a less-proprietary format than powerpoint? Not only are not all subscribers to this list on PCs, but it's possible for various Microsoft document formats to have viruses. (Such as MS Word macro viruses... I have no idea about Powerpoint.) This is one of the reasons Adobe invented PDF. I'd offer to translate these to pdf or postscript or just plain JPGs, but I can't do it without Powerpoint! Colin Perkins wrote: > Most of the slides presented at the AVT meeting in Orlando are now > available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/. > The remainder will become available as soon as I receive copies. > > Colin -- Chris Fulmer Nortel, Ltd RTP, NC These opinions do not necessarily reflect those of my employer. From rem-conf Tue Dec 15 14:06:51 1998 From rem-conf-request@es.net Tue Dec 15 14:06:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq2SE-0005Di-00; Tue, 15 Dec 1998 13:56:30 -0800 Received: from ns11.nokia.com [131.228.6.230] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq2SD-0005DY-00; Tue, 15 Dec 1998 13:56:29 -0800 Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns11.nokia.com (8.8.8/8.6.9) with ESMTP id XAA11289 for ; Tue, 15 Dec 1998 23:56:27 +0200 (EET) Received: from nrchub01he.research.nokia.com (nrchub01he [131.228.10.247]) by pepper.research.nokia.com (8.9.1a/8.9.1) with ESMTP id XAA21890 for ; Tue, 15 Dec 1998 23:56:25 +0200 (EET) Received: from Microsoft Mail (PU Serial #1751) by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9h for Windows NT(tm)) id AA-1998Dec15.235300.1751.318660; Tue, 15 Dec 1998 23:57:57 +0200 From: roberta.eklund@research.nokia.com (Eklund Roberta NRC/Tre) To: rem-conf@es.net (rem-conf) Message-ID: <1998Dec15.235300.1751.318660@nrchub01he.research.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Organization: Nokia Date: Tue, 15 Dec 1998 23:57:57 +0200 Subject: remove roberta.eklund@research.nokia.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Tue Dec 15 14:15:09 1998 From rem-conf-request@es.net Tue Dec 15 14:15:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq2iV-0005pG-00; Tue, 15 Dec 1998 14:13:19 -0800 Received: from wya-lfd93.hotmail.com (hotmail.com) [207.82.252.157] by mail1.es.net with smtp (Exim 1.81 #2) id 0zq2iU-0005nl-00; Tue, 15 Dec 1998 14:13:18 -0800 Received: (qmail 437 invoked by uid 0); 15 Dec 1998 22:12:17 -0000 Message-ID: <19981215221217.436.qmail@hotmail.com> Received: from 208.211.99.70 by www.hotmail.com with HTTP; Tue, 15 Dec 1998 14:12:13 PST X-Originating-IP: [208.211.99.70] From: "Neal Schneider" To: nschneid@hotmail.com, rem-conf@es.net, subbiah@NASBPD01BS.ntc.nokia.com Subject: RE: RTP Proposal - comparison MIME-Version: 1.0 Content-Type: text/plain Date: Tue, 15 Dec 1998 14:12:13 PST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am thinking of essentially ethernet phones, where the bandwidth efficiency is not an issue due to small utilization on an ethernet. That is why compression at the Trunk Interface, e.g. DS1, would make more sense, rather than at every phone on a 100baseT. In terms of multiplexing, the sequence numbers would not be correlated at all between calls, and would therefore have to be retained. The timestamps may not differ much from the source to gateway, since the transfer latency over an ethernet is very small. So the timestamp from the original source may not need be maintained for each user (except for offsets.) A full RTP header would have to be reconstructed, so all required RTP information must be maintained in-band or signaled out-of-band. Maintaining RTP Signaling is a big issue with this scenario, however. Regards, Neal A. Schneider > In case of IP phones connected on LANs via some IP trunk then we are = >looking at different functionalities. Basically, you strip of the RTP packet= > = >coming to your ingress aggregation point and then try to multiplex. At the = >egress point you need reconstruct the full RTP header. > >There are few things to note. With this scheme > >1. Time stamps will more likely different since generated at source. >2. SN will be different. and we need to regenerate the SN at the egress = >point. >3. In terms of H.323 signaling, we need 3 signaling procedure to setup a = >connection 1)Source - Ingress point - 2) Ingress - egress 3) egress to = >destination > >My argument is that you get more efficiency using compression at the source= > = >than at some where in the middle. > >regards, > >Barani Subbiah >Nokia Research > ---------- ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Tue Dec 15 14:21:47 1998 From rem-conf-request@es.net Tue Dec 15 14:21:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq2qH-0006Tk-00; Tue, 15 Dec 1998 14:21:21 -0800 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq2qG-0006TV-00; Tue, 15 Dec 1998 14:21:20 -0800 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.9.1a/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id WAA21019; Tue, 15 Dec 1998 22:21:18 GMT Received: from mbaugher-desk.jf.intel.com (mbaugher-desk.jf.intel.com [192.198.161.123]) by ideal.jf.intel.com (8.9.0/8.9.0) with SMTP id OAA10053; Tue, 15 Dec 1998 14:21:15 -0800 (PST) From: mbaugher@intel.com Message-Id: <199812152221.OAA10053@ideal.jf.intel.com> Sender: "Mark Baugher" To: "'Chris Fulmer'" , "Colin Perkins" Cc: Subject: RE: Slides from Orlando AVT meeting Date: Tue, 15 Dec 1998 14:21:10 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3676D2B4.249A19B5@americasm01.nt.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Powerpoint is preferred by the IETF (http://www.ietf.org/instructions/slides.html). PDF is not mentioned in the instructions. I'll post postscript if asked to do so. Mark > -----Original Message----- > From: Chris Fulmer [mailto:Chris.Fulmer.chrisf@nt.com] > Sent: Tuesday, December 15, 1998 1:21 PM > To: Colin Perkins > Cc: rem-conf@es.net > Subject: Re: Slides from Orlando AVT meeting > > > May I suggest that in the future, it would be helpful for > slides to be put > into a less-proprietary format than powerpoint? Not only are not all > subscribers to this list on PCs, but it's possible for > various Microsoft > document formats to have viruses. (Such as MS Word macro > viruses... I > have no idea about Powerpoint.) This is one of the reasons > Adobe invented > PDF. > > I'd offer to translate these to pdf or postscript or just > plain JPGs, but I > can't do it without Powerpoint! > > > Colin Perkins wrote: > > > Most of the slides presented at the AVT meeting in Orlando are now > > available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/. > > The remainder will become available as soon as I receive copies. > > > > Colin > > -- > Chris Fulmer Nortel, Ltd RTP, NC > These opinions do not necessarily reflect those of my employer. > > > > From rem-conf Tue Dec 15 17:13:16 1998 From rem-conf-request@es.net Tue Dec 15 17:13:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zq5SL-0000o6-00; Tue, 15 Dec 1998 17:08:49 -0800 Received: from logatome-2.francenet.fr (logatome.micronet.fr) [193.149.96.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zq5S7-0000nw-00; Tue, 15 Dec 1998 17:08:36 -0800 Received: from LES_GARCONS (sfrs5.francenet.net [193.149.109.246]) by logatome.micronet.fr (8.8.8/8.8.8) with SMTP id QAA28350; Tue, 15 Dec 1998 16:29:04 +0100 (CET) Message-ID: <003601be2840$ca6cab90$f66d95c1@LES_GARCONS.sfrs.fr> From: "=?iso-8859-1?Q?St=E9phanie_BERTHIER?=" To: Subject: =?iso-8859-1?Q?Nouveaut=E9s_SFRS?= Date: Tue, 15 Dec 1998 16:26:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01BE2849.2C2F8CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0033_01BE2849.2C2F8CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by logatome.micronet.fr id QAA28350 NOUVEAUTES DERNIER TRIMESTRE 98 Plusieurs documents (c=E9d=E9roms - logiciels - cassettes vid=E9o) ont re= joint le catalogue du Service du Film de Recherche Scientifique, consultable sur notre site web http://www.sfrs.fr : 23 c=E9d=E9roms et logiciels traitant d'ornithologie, d'astronomie, d'arch=E9ologie, d'histoire, de politique, de p=E9dagogie, de physique, d= e chimie, de biologie, d'=E9cologie, d'=E9lectronique et de techniques industrielles 4 films : trois sur les algues (biologie v=E9g=E9tale) et un sur les crev= ettes primitives (biologie animale) Ces documents sont destin=E9s principalement aux =E9tudiants et =E0 leurs professeurs, certains d'entre eux sont toutefois accessibles =E0 un plus = large public, concern=E9 par la culture scientifique. Une pr=E9sentation d=E9ta= ill=E9e vous est propos=E9e en annexe. Par ailleurs, nous avons le plaisir de vous annoncer que le SFRS a re=E7u plusieurs distinctions : Le film =93Dans l'ombre du tiroir, =E9co-=E9pid=E9miologie de la maladie = de Chagas=94 s'est vu d=E9cerner 3 prix : - le prix =E9pidaure - cat=E9gorie promotion et communication - de la rec= herche en m=E9decine et =E9cologie - le premier prix - cat=E9gorie maladies infectieuses et tropicales - du Festival du Film de M=E9decine (FILMED) =E0 Amiens - le prix du minist=E8re de la sant=E9 du festival Ekotopfilm en Slovaqui= e Le c=E9d=E9rom =93Mati=E8re molle, physique des objets de tous les jours = par Pierre-Gilles de Gennes=94 s'est vu d=E9cerner le Faust d'or du Forum des= Arts de l'Univers Scientifique et Technologique =E0 Toulouse. Il a =E9galement= =E9t=E9 nomin=E9 au Prix Roberval 98. Ci-joint, vous trouverez en pi=E8ce jointe une annexe des CD-Roms PC, logiciels et films VHS. St=E9phanie BERTHIER Service du Film de Recherche Scientifique 96, Bld Raspail - 75272 Paris cedex 06 T=E9l. : 01.42.22.46.44 Fax : 01.42.22.93.50 berthier@sfrs.fr http://www.sfrs.fr ------=_NextPart_000_0033_01BE2849.2C2F8CF0 Content-Type: application/msword; name="Annexe.doc" Content-Disposition: attachment; filename="Annexe.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANQAAAAAAAAAA EAAANwAAAAEAAAD+////AAAAADQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEASQAMBAAAABK/AAAAAAAAEAAAAAAABAAAshUAAA4AYmpiarKzsrMAAAAAAAAAAAAAAAAAAAAA AAAMBBYAHjYAANDZAQDQ2QEAshEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJAAAAAAAAAAkAAAAJAA AAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAABQAAAAAAAAAAAAAAKQAAAAAAAAApAAA AAAAAACkAAAAAAAAAKQAAAAAAAAApAAAABQAAAC4AAAAJAAAAKQAAAAAAAAA1AMAAPIAAADoAAAA AAAAAOgAAAAAAAAA6AAAAAAAAADoAAAAAAAAAOgAAAAAAAAA6AAAAAAAAADoAAAAAAAAAOgAAAAA AAAAmQMAAAIAAACbAwAAAAAAAJsDAAAAAAAAmwMAAAAAAACbAwAAAAAAAJsDAAAAAAAAmwMAACQA AADGBAAA9AEAALoGAABeAAAAvwMAABUAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAAAAAADoAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADoAAAAAAAAAOgAAAAAAAAA6AAAAAAAAADoAAAAAAAAAL8DAAAAAAAA uAEAAAAAAACQAAAAAAAAAJAAAAAAAAAA6AAAAAAAAAAAAAAAAAAAAOgAAAAAAAAA6AAAAAAAAAC4 AQAAAAAAALgBAAAAAAAAuAEAAAAAAADoAAAA0AAAAJAAAAAAAAAA6AAAAAAAAACQAAAAAAAAAOgA AAAAAAAAmQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAApAAAAAAAAACkAAAAAAAAAJAAAAAAAAAAkAAA AAAAAACQAAAAAAAAAJAAAAAAAAAA6AAAAAAAAACZAwAAAAAAALgBAACOAAAAuAEAAAAAAABGAgAA VgAAAE0DAABAAAAAkAAAAAAAAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmQMAAAAAAADoAAAAAAAAANwAAAAMAAAAoO6YEAgo vgGkAAAAAAAAAKQAAAAAAAAAuAEAAAAAAACNAwAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQW5u ZXhlDUNFREVST01TIFBDDQ1Pcm5pdGhvbG9naWUgDZNMZXMgT2lzZWF1eCBkZSBub3MgamFyZGlu c5MNUHLpc2VudGF0aW9uIGQndW5lIGNlbnRhaW5lIGQnZXNw6GNlcyBkJ29pc2VhdXggcGFybWkg bGVzIHBsdXMgculwYW5kdWVzIGVuIEV1cm9wZS4NQXN0cm9ub21pZQ2TTGUgQ2llbJQNVW4gb3V0 aWwgZCdvYnNlcnZhdGlvbiBhc3Ryb25vbWlxdWUuDUFyY2jpb2xvZ2llDZNE6WxvcyINQSBsYSBk 6WNvdXZlcnRlIGRlIETpbG9zLCBjaXTpIHByb3Nw6HJlIGV0IHNhbmN0dWFpcmUgcHJlc3RpZ2ll dXggZGUgbGEgR3LoY2UgYW50aXF1ZS4Nk0EgbGEgY29ucXXqdGUgZGUgbCdhcmNo6W9sb2dpZSBt b2Rlcm5llA1JbnN0aXR1dGlvbiBkZSBwbHVzIDE1MCBhbnMsIGwnRWNvbGUgZnJhbudhaXNlIGQn QXRo6G5lcyBkaWZmdXNlIHNvbiBwYXRyaW1vaW5lIGV4Y2VwdGlvbm5lbC4NaGlzdG9pcmUgLSBw aGlsb3NvcGhpZQ2TRGVzY2FydGVzkw1QculzZW50YXRpb24gZGUgbCecdXZyZSBldCBkZSBsYSB2 aWUgZHUgcGhpbG9zb3BoZS4NSGlzdG9pcmUgcG9saXRpcXVlDZNMZSBD6WTpcm9tIGR1IHBvdXZv aXKTDVVuIGPpZOlyb20gY29uc2FjcukgYXUgcG91dm9pciBleOljdXRpZi4Nk0VseXPpZSAyLCBs YSBwculzaWRlbmNlIGRlIGxhIHLpcHVibGlxdWUglA1FbmN5Y2xvcOlkaWUgbXVsdGlt6WRpYSBk dSBzeXN06G1lIHBvbGl0aXF1ZSBmcmFu52Fpcywg4CB0cmF2ZXJzIG5vdGFtbWVudCBsZSBwb3J0 cmFpdCBkZXB1aXMgMTg0OCBkZSAyMiBwculzaWRlbnRzLg1wZWRhZ29naWUNk1FDTSA2lA1VbiBv dXRpbCBwdWlzc2FudCBwb3VyIGxlcyBlbnNlaWduYW50cy4gTGEgImJhbnF1ZSIgZGUgcXVlc3Rp b25zIGVzdCB1bmUgYmFzZSBkZSBkb25u6WVzIGF1IGZvcm1hdCBJU0FNIChNaWNyb3NvZnQpLiBV biBzZXVsIGZpY2hpZXIgZGUgY2UgdHlwZSBwZXV0IGNvbnRlbmlyIGp1c3F1J+AgZW52aXJvbiAy NTAgMDAwIHF1ZXN0aW9ucywgY2hhY3VuZSBkJ2VudHJlIGVsbGVzIGVzdCBhY2Nlc3NpYmxlIGlu c3RhbnRhbultZW50LiBRQ002IGVzdCBsaXZy6SBhdmVjIHVuIHN0b2NrIGluaXRpYWwgZCdlbnZp cm9uIDQgMDAwIHF1ZXN0aW9ucy4NQ2hpbWllDZNQRVJJT0RJQyBDaGltaWUgkw1DZSBj6WTpcm9t IHJhc3NlbWJsZSBsZXMgZG9ubullcyBlc3NlbnRpZWxsZXMgc3VyIGxlcyAxMTEg6WzpbWVudHMg Y2hpbWlxdWVzIGFjdHVlbGxlbWVudCBjb25udXMgcXVpIGNvbnN0aXR1ZW50IG5vdHJlIHVuaXZl cnMuDVBoeXNpcXVlDZNMYSBQaHlzaXF1ZSBwYXIgbCdleHDpcmllbmNlIJMNRGVzIHNpbXVsYXRp b25zIGludGVyYWN0aXZlcyBlbiBt6WNhbmlxdWUsIHRoZXJtb2R5bmFtaXF1ZSwg6WxlY3RyaWNp dOksIG1hZ27pdGlzbWUsIG9wdGlxdWUsIHBoeXNpcXVlIHF1YW50aXF1ZSBwb3VyIG1pZXV4IGNv bXByZW5kcmUgbGVzIHBo6W5vbehuZXMgcGh5c2lxdWVzIChzZWNvbmQgY3ljbGUgZXQgc3Vw6XJp ZXVyKS4Nk1BoeXNpcXVlIHRlcm1pbmFsZSBTkw1QculzZW50YXRpb24gZGUgbGEgdG90YWxpdOkg ZHUgcHJvZ3JhbW1lIGRlIGwnYW5u6WUgc2NvbGFpcmUgKHZlcnNpb24gZW5zZWlnbmVtZW50KS4N DUxPR0lDSUVMUyAoc3VyIGRpc3F1ZXR0ZXMgUEMpDQ1waHlzaXF1ZQ2TVm9sdGFraXSUDVNpbXVs YXRpb24gZGUgbW9udGFnZSBkZSBjaXJjdWl0cyDpbGVjdHJpcXVlcy4NIJNXYXZlbGFikw1TaW11 bGF0aW9uIGRlcyBwaOlub23obmVzIG9uZHVsYXRvaXJlcw0gk0dyYXZpbGFikw1TaW11bGF0aW9u IGRlcyBlZmZldHMgZGUgbGEgZ3Jhdml0YXRpb24Nk0NvbG9ya2l0kw1JbGx1c3RyYXRpb24gZGUg bGEgdGjpb3JpZSBkZXMgbelsYW5nZXMgY29sb3Lpcw1iaW9sb2dpZQ2TRHJvc29sYWKTDVNpbXVs YXRpb24gZCdleHDpcmltZW50YXRpb25zIGfpbul0aXF1ZXMgcGFyIGNyb2lzZW1lbnQgZGUgZHJv c29waGlsZXMNk0Zyb2dtZXeUDUV4cOlyaW1lbnRhdGlvbnMgc3VyIGxhIG3pdGFtb3JwaG9zZSBk ZSBsYSBncmVub3VpbGxlDZNCYWN0b2xhYpMNU2ltdWxhdGlvbiBkZSB0cmF2YXV4IGRlIGJhY3Tp cmlvbG9naWUNk1JlZmxleGFyY5QNUHJvcHJp6XTpcyBmb25kYW1lbnRhbGVzIGR1IHN5c3TobWUg bmVydmV1eA1FY29sb2dpZQ2TRWNvam9ilA1HZXN0aW9uIHNpbXVs6WUgZCd1biDpY29zeXN06G1l IHNpbXBsZQ10ZWNobmlxdWVzIGluZHVzdHJpZWxsZXMNk1Bpdm90IGV4cGVydJQgDUxvZ2ljaWVs IGRlIG3pY2FuaXF1ZSwgc2ltdWxhdGlvbiBkZSBtb250YWdlIGRlIHJvdWxlbWVudHMNZWxlY3Ry by10ZWNobmlxdWUNkzIgUC1w9Gxlc5QNUmVwculzZW50YXRpb24gZGVzIGNoYW1wcyBtYWdu6XRp cXVlcyBkYW5zIGxlcyBtYWNoaW5lcyB0cmlwaGFz6WVzDXBoeXNpcXVlIGF0b21pcXVlIGV0IG1v bGVjdWxhaXJlDZNDb3ZhbGlvbpQNRXR1ZGUgZGVzIGxpYWlzb25zIGNoaW1pcXVlcyBmb25kYW1l bnRhbGVzDQ1GSUxNUyAoY2Fzc2V0dGUgVkhTIGZvcm1hdCBQYWwgb3UgU2VjYW0pDQ1iaW9sb2dp ZSB2ZWdldGFsZQ0zIGZpbG1zIHN1ciBsZXMgYWxndWVzIHByb2R1aXRzIHBhciBsJ2luc3RpdHV0 IGFsbGVtYW5kIElXRiwgbGVzIGZpbG1zIHNvbnQgcG91ciBsJ2luc3RhbnQgZGlzcG9uaWJsZXMg dW5pcXVlbWVudCBlbiB2ZXJzaW9uIGFuZ2xhaXNlLCB1bmUgdmVyc2lvbiBmcmFu52Fpc2Ugc2Vy YSBy6WFsaXPpZSB1bHTpcmlldXJlbWVudC4Nk0N5Y2xlIGRlIGTpdmVsb3BwZW1lbnQgZCdlY2xv Y2FycHVzIHNpbGljdWxvc3VzkyAoMTIgbWludXRlcykNk1L0bGUgZGVzIHBo6XJvbW9uZXMgZGFu cyBsYSByZXByb2R1Y3Rpb24gZGVzIGFsZ3VlcyBicnVuZXOUICg5IG1pbnV0ZXMpDZNCaW9sb2dp ZSBkZSBsYSByZXByb2R1Y3Rpb24gY2hleiBsZSBmdWN1cyAtIGVzcOhjZXMgZGlvaXF1ZXMgZXQg bW9ub2lxdWVzlCAoMTQgbWludXRlcykNDWJpb2xvZ2llIGFuaW1hbGUgDZNNb3J0IOAgdGVtcHMg cGFydGllbJQgKDQ1IG1pbnV0ZXMpDUxlcyBjcmV2ZXR0ZXMgcHJpbWl0aXZlcyAiYnJhbmNoaW9w b2RlcyIgbidvbnQgcGFzIOl2b2x16SBkZXB1aXMgMjAwIG1pbGxpb25zIGQnYW5u6WVzLCBjZSBz b250IGRlcyBmb3NzaWxlcyB2aXZhbnRzLiBQYXJmYWl0ZW1lbnQgYWRhcHTpZXMg4CBsJ2VhdSBm cmHuY2hlIGRlcyBtYXJlcyBvdSBkZXMgbGFjcyBzYWzpcywgZWxsZXMgcG9uZGVudCBkZXMgnHVm cyBjb250ZW5hbnQgdW4gZW1icnlvbi4gQ2VzIJx1ZnMgculzaXN0ZW50IOAgZGVzIGFubullcyBk ZSBz6WNoZXJlc3NlIGV0IGwnZW1icnlvbiBwZXV0IHN1cnZpdnJlIHNhbnMgbel0YWJvbGlzbWUu IENvbW1lbnQgbGVzIGVtYnJ5b25zIGFwcGFyZW1tZW50IG1vcnRzIHBldXZlbnQtaWxzIHLpc2lz dGVyID8gUXUnZXN0LWNlIHF1aSBsZXMgInLpdmVpbGxlIiA/IENldHRlIOltaXNzaW9uIG5vdXMg cGVybWV0IGQnb2JzZXJ2ZXIgbGVzIHN0cmF06WdpZXMgZGUgc3VydmllIGRlcyBicmFuY2hpb3Bv ZGVzLCBldCBwculzZW50ZSBsZXMgZGVybmnocmVzIHJlY2hlcmNoZXMgc3VyIGNlcyCcdWZzIGlu YWx06XJhYmxlcyBldCBjZSBxdWUgbCdob21tZSBwZXV0IGVuIHRpcmVyLg0NYXN0cm9ub21lDQ2T IFZpbmd0IHF1YXRyZSBoZXVyZXMgYXUgUGljLWR1LU1pZGmUICgyNCBtaW51dGVzKQ0NVW5lIGpv dXJu6WUgZXQgdW5lIG51aXQsIGVuIGNvbXBhZ25pZSBkZXMgYXN0cm9ub21lcyBldCBkZXMgdGVj aG5pY2llbnMg4CBsJ09ic2VydmF0b2lyZSBkdSBQaWMtZHUtTWlkaSwgZGFucyBsYSBzb2xpdHVk ZSBkZXMgY2ltZXMgcHly6W7pZW5uZXMuIENlIGZpbG0gcmV0cmFjZSBsZXMgcHJpbmNpcGF1eCBy 6XN1bHRhdHMgb2J0ZW51cyBjZXMgZGVybmnocmVzIGFubullcyBkYW5zIGxlcyBkb21haW5lcyBk dSBzb2xlaWwsIGRlcyBwbGFu6HRlcyBldCBkZSBsJ3VuaXZlcnMgbG9pbnRhaW4uIElsIHJldHJh Y2UgYXVzc2kgbCdoaXN0b2lyZSBkZSBjZXQgb2JzZXJ2YXRvaXJlIGZvbmTpIGVuIDE4NzgsIGV0 IHBy6XNlbnRlIGxlcyBmYW1ldXNlcyBpbWFnZXMgZGUgbGEgY291cm9ubmUgc29sYWlyZSBkZSBC ZXJuYXJkIEx5b3QuDQ1waHlzaXF1ZQ0NTGVzIEVjaGFuZ2VzIHRoZXJtaXF1ZXMgOiBwcmluY2lw ZXMgZGUgbCfpY2hhbmdldXIg4CBwbGFxdWVzICgxMCBtaW51dGVzKQ0NTGVzIOljaGFuZ2VzIHRo ZXJtaXF1ZXMgc29udCBy6WdpcyBwYXIgY2lucSBwcmluY2lwZXMgZm9uZGFtZW50YXV4IHF1aSBz b250IGljaSBpbGx1c3Ry6XMgYXUgdHJhdmVycyBkZSBsJ+ljaGFuZ2V1ciDgIHBsYXF1ZXMuIFBh cnRhbnQgZCdleGVtcGxlcyBlbXBydW506XMg4CBsYSB2aWUgcXVvdGlkaWVubmUsIGxlcyBkZXNj cmlwdGlvbnMgYWxsaWVudCBsZXMgcHJpc2VzIGRlIHZ1ZSBlbiBzaXR1YXRpb24gZXQgbGVzIHRl Y2huaXF1ZXMgZCdhbmltYXRpb24gYWZpbiBkZSBk6WNvdXZyaXIgY29tbWVudCBjZXMgcHJpbmNp cGVzIHNpbXBsZXMgc29udCBpbnTpZ3LpcyBldCBvcHRpbWlz6XMgZGFucyBsYSBjb25jZXB0aW9u IGQnb3V0aWxzIGluZHVzdHJpZWxzLg0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAcEAAATBAAAFAQAACIEAAA/ BAAAkwQAAJ4EAACoBAAAzQQAANkEAADhBAAAOAUAAGEFAAC/BQAA1gUAAOIFAAAWBgAAKQYAAEEG AABqBgAAlgYAAAsHAAAVBwAAHQcAAFMIAABZCAAAWggAAG0IAADtCAAA9QgAAPYIAAAWCQAA0wkA AOoJAAA/CgAASgoAAF8KAABnCgAAcwoAAKIKAACtCgAA1AoAAOAKAAAICwAAEwsAAEMLAABMCwAA VwsAAJ4LAACoCwAA3gsAAOkLAAAQDAAAHAwAAEgMAABRDAAAWgwAAIEMAACaDAAAqgwAAOUMAAD3 DAAAAw0AAEYNAABnDQAAcg0AAJ4NAACkDQAAxg0AAMcNAADIDQAA2g0AAJUOAADHDgAA0w4AABEP AAAcDwAAaQ8AAHUPAAB2DwAAdw8AAIkPAACgDwAArA8AAPfv6N7W6N7W6N7W6Nbo3tbo3tbo1uje 1uje79bo3u/W6Nbo7+je1ujW6Nbo1uje1ujW6Nbo1uje1uje1uje1uje1ujv6O/o3ujW6Nbo1ujW 6N7W6AAAAAAPPioBQ0oWAE9KAwBRSgMAEjUIgToIgUNKFgBPSgMAUUoDAAAMQ0oWAE9KAwBRSgMA AA81CIFDShYAT0oDAFFKAwAPPioBQ0ogAE9KAwBRSgMAAFQABAAABwQAABMEAAAUBAAAIgQAAD8E AACTBAAAngQAAKgEAADNBAAA2QQAAOEEAAA4BQAAYQUAAL8FAADWBQAA4gUAABYGAAApBgAAQQYA AGoGAACWBgAACwcAABUHAAAdBwAAUwgAAFoIAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOkA AAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAA AAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAA AOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAA AAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADh AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAAAAAAAABwAAAyQDBiQBEmRoAQEABgAAAyQDEmRoAQEA AAkAAAMkAwomAAtGAQASZGgBAQAGAAADJAESZGgBAQAAGgAEAAAHBAAAEwQAABQEAAAiBAAAPwQA AJMEAACeBAAAqAQAAM0EAADZBAAA4QQAADgFAABhBQAAvwUAANYFAADiBQAAFgYAACkGAABBBgAA agYAAJYGAAALBwAAFQcAAB0HAABTCAAAWggAAG0IAADtCAAA9ggAABYJAADTCQAA6gkAAD8KAABA CgAAXgoAAF8KAABoCgAAcwoAAKIKAACtCgAA1AoAAOAKAAAICwAAEwsAAEMLAABMCwAAVwsAAJ4L AACoCwAA3gsAAOkLAAAQDAAAHAwAAEgMAABRDAAAWgwAAIEMAACaDAAAqgwAAOUMAAD3DAAAAw0A AEYNAABnDQAAcg0AAJ0NAACeDQAAxw0AAMgNAADaDQAAlQ4AANQOAAAdDwAAdg8AAHcPAACJDwAA rQ8AAP0RAAD+EQAACBIAAAkSAAA8EgAAPRIAAN8TAADgEwAA6RMAAOoTAAA0FAAANRQAALEVAACy FQAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAUIAwAJAQUIAgAJAQUIAQAJAQBbWggAAG0IAADtCAAA9ggAABYJAADTCQAA 6gkAAD8KAABACgAAXgoAAF8KAABoCgAAcwoAAKIKAACtCgAA1AoAAOAKAAAICwAAEwsAAEMLAABM CwAAVwsAAJ4LAACoCwAA3gsAAOkLAAAQDAAAHAwAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ AAADJAMKJgALRgIAEmRoAQEABgAAAyQDEmRoAQEAABscDAAASAwAAFEMAABaDAAAgQwAAJoMAACq DAAA5QwAAPcMAAADDQAARg0AAGcNAAByDQAAnQ0AAJ4NAADHDQAAyA0AANoNAACVDgAA1A4AAB0P AAB2DwAAdw8AAIkPAACtDwAA/REAAP4RAAD5AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADjAAAA AAAAAAAAAAAA4wAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAyQDCwAAAyQDBiQBCiYAC0YDABJkaAEB AAAHAAADJAMGJAESZGgBAQAGAAADJAMSZGgBAQAAGqwPAACtDwAA/hEAAAgSAAAJEgAALhIAAOAT AADpEwAA6hMAACgUAACxFQAAshUAAPfw5t738Obw9/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA86CIFDShYAT0oDAFFKAwASNQiBOgiBQ0oWAE9KAwBRSgMAAAxD ShYAT0oDAFFKAwAADz4qAUNKFgBPSgMAUUoDAAAL/hEAAAgSAAAJEgAAPBIAAD0SAADfEwAA4BMA AOkTAADqEwAANBQAADUUAACxFQAAshUAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAAyQDAAwcAB+w0C8gsOA9IbA3AiKwNwIjkKoAJJA3AiWw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIADwAKAAEAWwAPAAIAAAAAAAAALAAAQPH/AgAs AAAABgBOAG8AcgBtAGEAbAAAAAIAAAAMAE9KAgBRSgIAbUgMBAAAAAAAAAAAAAAAAAAAAAAAADIA QUDy/6EAMgAAABEAUABvAGwAaQBjAGUAIABwAGEAcgAgAGQA6QBmAGEAdQB0AAAAAAAAAAAAAAAA AAAAAACyEQAABQAANgAAAAD/////AAQAAKwPAACyFQAAFAAAABkAAAAABAAAWggAABwMAAD+EQAA shUAABUAAAAXAAAAGAAAABoAAAAABAAAshUAABYAAAAAAAAA2gAAAN8AAAD0AAAA+QAAAH4BAACF AQAA1wEAAOABAAAtAgAANAIAAEQCAABLAgAAcAQAAHcEAABpBgAAcQYAAKQGAACrBgAA1gYAAN4G AAAJBwAAEQcAAE0HAABVBwAAkgcAAJ0HAACfBwAApgcAAN8HAADnBwAAEQgAABoIAACQEQAAtBEA AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAADAAcA//8CAAAACgBDAGgAcgBpAHMAdABvAHAAaABlADgAQwA6AFwAVwBJAE4ATgBU AFwAUAByAG8AZgBpAGwAZQBzAFwAQwBoAHIAaQBzAHQAbwBwAGgAZQBcAEIAdQByAGUAYQB1AFwA UABvAHIAdABlAC0AZABvAGMAXABBAG4AbgBlAHgAZQAuAGQAbwBjAAMAwS3bUAEADAT/DwAAAAAA AAAAAAAAAAAAAAABAHZ0B2IBAAwE/w8AAAAAAAAAAAAAAAAAAAAAAQA1Lf19AQAMBP8PAAAAAAAA AAAAAAAAAAAAAAEAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwAwAAAHZ0B2IAAAAAAAAAAAAAAADBLdtQAAAAAAAAAAAAAAAANS39 fQAAAAAAAAAAAAAAAP//////////////////AwAAAAAAAAAAAP9AA4ABALERAACxEQAADHotAQEA AACxEQAAAAAAALERAAAAAAAAAhAAAAAAAAAAshEAAFAAAAgAQAAABAAAAEcWkAEAAAICBgMFBAUC AwSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA ADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMm kAEAAAILBgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAA7JpABAAAC CwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAASABFAEwAVgBFAFQASQBDAEEAAAAiAAQA MQiIGAAAxAIAAKkBAAAAAHJ6LEZzeixGAAAAAAEAAQAAAI8CAACXDgAAAQAHAAAABAADEB8AAAAA AAAAAAAAAAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbA B7QAtACAABIwAAAAAAAAAAAAAAAAAADqEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAAGAEEAbgBu AGUAeABlAAAAAAAAAAoAQwBoAHIAaQBzAHQAbwBwAGgAZQAKAEMAaAByAGkAcwB0AG8AcABoAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAABgAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAoAAAAAQAAACsAAAABQAAAMAA AAAHAAAAzAAAAAgAAADgAAAACQAAAPQAAAASAAAAAAEAAAoAAAAcAQAADAAAACgBAAANAAAANAEA AA4AAABAAQAADwAAAEgBAAAQAAAAUAEAABMAAABYAQAAAgAAAOQEAAAeAAAABwAAAEFubmV4ZQAA HgAAAAEAAAAAbm5lHgAAAAsAAABDaHJpc3RvcGhlAAAeAAAAAQAAAABocmkeAAAACwAAAE5vcm1h bC5kb3QAAB4AAAALAAAAQ2hyaXN0b3BoZQAAHgAAAAIAAAAxAHJpHgAAABMAAABNaWNyb3NvZnQg V29yZCA4LjAAAEAAAAAARsMjAAAAAEAAAAAArOflByi+AUAAAAAA8qoJCCi+AQMAAAABAAAAAwAA AI8CAAADAAAAlw4AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rjgBAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYA AACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAA AMAAAAAMAAAA0wAAAAIAAADkBAAAHgAAAAUAAABTRlJTAABBbgMAAAAfAAAAAwAAAAcAAAADAAAA 6hEAAAMAAACzDQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAcAAABB bm5leGUADBAAAAIAAAAeAAAABgAAAFRpdHJlAAMAAAABAAAAAAAAmAAAAAMAAAAAAAAAIAAAAAEA AAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsANQAy AEIAMgAxAEMAMQAxAC0AOQAzAEYAOAAtADEAMQBEADIALQBBADEANQA1AC0AMAAwAEEAMAAyADQA NQBBADcAMABGADMAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAO AAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAAP7/ //8dAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAA ACsAAAD+////LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAAP7////9////NgAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAEEAbgBuAGUAeABlAC4AZABvAGMAFQDwA6YPCCi+AQQA AAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAKAHRQ4IKL4BkFH/ EAgovgE4AAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAEAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB42AAAAAAAABQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEC AAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAABAAAAAA AAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA AAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACwAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAPgAfAAAADACo AhQAqAIUAFDoFQAk6BUAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAABAAAAAAAAAAAAAAAOAAAAAQAAAAgAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArABMAAAAMAAAAAAD///////////////9vAGMA cgBvAGYAaQBsAGUAcwBcAEMAaAByAGkAcwB0AG8AcABoAGUAXABCAHUAcgBlAGEAdQAAACoALgAq AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABEb2N1bWVudCBNaWNyb3NvZnQgV29yZAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0033_01BE2849.2C2F8CF0-- From rem-conf Wed Dec 16 02:48:58 1998 From rem-conf-request@es.net Wed Dec 16 02:48:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqEP7-0004Aq-00; Wed, 16 Dec 1998 02:42:05 -0800 Received: from chico.rediris.es [130.206.1.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqEO8-000490-00; Wed, 16 Dec 1998 02:41:24 -0800 Received: from o2.rediris.es (o2.rediris.es [130.206.1.45]) by chico.rediris.es (8.9.1/8.9.1) with ESMTP id LAA06802; Wed, 16 Dec 1998 11:37:37 +0100 (MET) Message-Id: <199812161037.LAA06802@chico.rediris.es> X-Mailer: exmh version 2.0.2 2/24/98 From: "Angel L. Mateo" To: Ross Finlayson Cc: To: ; Subject: Re: A "sdr" source-code patch for directory sessions Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Dec 1998 11:37:36 +0100 Sender: amateo@o2.rediris.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list El d=EDa Fri, 13 Nov 1998 03:24:50 Ross Finlayson escribi=F3: > FYI to those of you who use "sdr" as your SDP session browser: > = > I have developed a patch to the "sdr" source code that will allow "sdr"= to > properly handle 'directory' SDP sessions (for instance, the "Test > Sessions", "Music", "Lectures and Seminars" directories that are curren= tly > being announced). > = > In particular, when rebuilt with this patch, "sdr" can now be used to: > - launch a directory session, with each directory's contents appearing = in a > new window > - create new session announcements (including directory session > announcements) within any directory > = > You can find this patch online at > > = Hello, I have tried the patch but I can do it works. I have done the following:= 1. I have download the patch (I save with the sdrpatch.diff name), the di= rectory icon, the plugins,... 2. The patch refers to sdr.old and sdr.new directorys, so I have rename t= he sdr/src directory to sdr/src.old and I have copied sdr/src.old to sdr/= sdr.new. 3. Then I have run: "patch < sdrpatch.diff. This reports me only the erro= r that I don't have any parsed_plugins.tcl file. 4. A copy the plugins that I have downloaded to the sdr/src.new/plugins d= irectory and the directory.xbm to the sdr/src.new 5. A rename sdr/src.new to sdr/src to correct compilation 6. I have gone the sgi directory (I have got an SGI O2 with IRIX6.3) and = run ./configure. 7. I run make in the sgi directory. 8. After compilation I have a sdr executable file, so I run "make install= " to install it to /usr/local/bin. 9. Run sdr. When I run sdr, it works with the same results than the normal sdr, but = I have some problems. First, when it starts I have got the warning messag= es: Warning: icon directory overridden by icon directory for media directory Warning: text Directory overridden by text Directory for media directory Then I have the list of sessions, but directory sessions don't have the = related icon, I have the unknown icon. Then when I want to enter in any o= f this sessions I have got an core file. With the other sessions I have n= o problem. I have the tcl and tk versions of UCL and I have the next directory stru= cture in /usr/local/src: sdr tcl-8.0 tk-8.0 ----------------------------------------- Angel L. Mateo Martinez Aplicaciones Telem=E1ticas de Trabajo Cooperativo RedIRIS/CSIC C/ Serrano, 142 28006 Madrid (Spain) Tlfo: +34-91-5855145 Fax: +34-91-5855146 From rem-conf Wed Dec 16 06:02:45 1998 From rem-conf-request@es.net Wed Dec 16 06:02:42 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zqHQA-0005zh-00; Wed, 16 Dec 1998 05:55:22 -0800 Received: from ndcrelay.mcit.com ([166.37.172.49]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zqHQ8-0005zP-00; Wed, 16 Dec 1998 05:55:20 -0800 Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id IAA05711; Wed, 16 Dec 1998 08:53:37 -0500 (EST) Received: from sinnreich2 ([166.35.227.182]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19981216135337.SHTG18202@[166.35.227.182]>; Wed, 16 Dec 1998 07:53:37 -0600 From: "Henry Sinnreich" To: "Mark Baugher" , "'Chris Fulmer'" , "Colin Perkins" Cc: Subject: RE: Slides from Orlando AVT meeting Date: Wed, 16 Dec 1998 07:53:21 -0500 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.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199812152221.OAA10053@ideal.jf.intel.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list PowerPoint and Word files can be saved very nicely as HTML. Nothing wrong with HTML and GIF's? BTW: Any fundamental criteria for which is more proprietary: PDF or PPT/Word? ;-) Thanks, Henry > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@intel.com] > Sent: Tuesday, December 15, 1998 5:21 PM > To: 'Chris Fulmer'; Colin Perkins > Cc: rem-conf@es.net > Subject: RE: Slides from Orlando AVT meeting > > > Powerpoint is preferred by the IETF > (http://www.ietf.org/instructions/slides.html). > PDF is not mentioned in the instructions. > I'll post postscript if asked to do so. > > Mark > > > -----Original Message----- > > From: Chris Fulmer [mailto:Chris.Fulmer.chrisf@nt.com] > > Sent: Tuesday, December 15, 1998 1:21 PM > > To: Colin Perkins > > Cc: rem-conf@es.net > > Subject: Re: Slides from Orlando AVT meeting > > > > > > May I suggest that in the future, it would be helpful for > > slides to be put > > into a less-proprietary format than powerpoint? Not only are not all > > subscribers to this list on PCs, but it's possible for > > various Microsoft > > document formats to have viruses. (Such as MS Word macro > > viruses... I > > have no idea about Powerpoint.) This is one of the reasons > > Adobe invented > > PDF. > > > > I'd offer to translate these to pdf or postscript or just > > plain JPGs, but I > > can't do it without Powerpoint! > > > > > > Colin Perkins wrote: > > > > > Most of the slides presented at the AVT meeting in Orlando are now > > > available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/. > > > The remainder will become available as soon as I receive copies. > > > > > > Colin > > > > -- > > Chris Fulmer Nortel, Ltd RTP, NC > > These opinions do not necessarily reflect those of my employer. > > > > > > > > > > > From rem-conf Wed Dec 16 06:55:10 1998 From rem-conf-request@es.net Wed Dec 16 06:55:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqIFS-0006dC-00; Wed, 16 Dec 1998 06:48:22 -0800 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zqIFR-0006d2-00; Wed, 16 Dec 1998 06:48:21 -0800 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id JAA12924; Wed, 16 Dec 1998 09:47:04 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Henry Sinnreich cc: rem-conf Subject: Re: Slides from Orlando AVT meeting In-reply-to: Your message of "Wed, 16 Dec 1998 07:53:21 EST." Date: Wed, 16 Dec 1998 09:47:03 -0500 Message-ID: <12922.913819623@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >BTW: Any fundamental criteria for which is more proprietary: PDF or >PPT/Word? ;-) Not really on the subject of this list, but you can get the PDF spec for free from: http://www.adobe.com/supportservice/devrelations/technotes.html and it's not likely to become completely incompatible from one year to the next. Can you point me at the word and powerpoint specs? Cheers, Mark From rem-conf Wed Dec 16 06:55:13 1998 From rem-conf-request@es.net Wed Dec 16 06:55:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqIDZ-0006cn-00; Wed, 16 Dec 1998 06:46:25 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqIDY-0006cd-00; Wed, 16 Dec 1998 06:46:24 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA05613; Wed, 16 Dec 1998 09:46:22 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA12374; Wed, 16 Dec 1998 09:46:20 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3677C7BC.11A8C97@cs.columbia.edu> Date: Wed, 16 Dec 1998 09:46:20 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich CC: Mark Baugher , "'Chris Fulmer'" , Colin Perkins , rem-conf@es.net Subject: Re: Slides from Orlando AVT meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henry Sinnreich wrote: > > PowerPoint and Word files can be saved very nicely as HTML. Nothing wrong > with HTML and GIF's? > > BTW: Any fundamental criteria for which is more proprietary: PDF or > PPT/Word? ;-) At least PDF is documented in publically available specifications (I don't think any of the MS formats are) and is a direct derivative of PostScript. That said, there is now a useful tool for Solaris: PCFileViewer, which allows one to look at the standard PC file types like PowerPoint and Word. It can be configured as a MIME viewer, too. It's freely available on the Sun web site. I don't know (but would like to...) whether this exists for other Unix platforms. From rem-conf Wed Dec 16 06:59:02 1998 From rem-conf-request@es.net Wed Dec 16 06:59:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqIMy-0006jj-00; Wed, 16 Dec 1998 06:56:08 -0800 Received: from mumrik.nada.kth.se [130.237.226.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqIMx-0006j0-00; Wed, 16 Dec 1998 06:56:07 -0800 Received: from localhost (nv91-tob@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id PAA29157 for ; Wed, 16 Dec 1998 15:55:56 +0100 (MET) Date: Wed, 16 Dec 1998 15:55:56 +0100 (MET) From: =?ISO-8859-1?Q?Tobias_=D6brink?= To: rem-conf@es.net Subject: RE: Slides from Orlando AVT meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mumrik.nada.kth.se id PAA29157 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 16 Dec 1998, Henry Sinnreich wrote: > PowerPoint and Word files can be saved very nicely as HTML. Nothing wro= ng > with HTML and GIF's? >=20 > BTW: Any fundamental criteria for which is more proprietary: PDF or > PPT/Word? ;-) Is there any free PPT/Word reader available? /Tobias .........................................................................= ... Tobias =D6brink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: tobias@it.kth.se URL: http://www.it.kth.se/~nv91-tob/ See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html From rem-conf Wed Dec 16 07:34:59 1998 From rem-conf-request@es.net Wed Dec 16 07:34:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqIvW-0000sc-00; Wed, 16 Dec 1998 07:31:50 -0800 Received: from mumrik.nada.kth.se [130.237.226.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqIvU-0000sL-00; Wed, 16 Dec 1998 07:31:49 -0800 Received: from localhost (nv91-tob@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id QAA00958 for ; Wed, 16 Dec 1998 16:31:46 +0100 (MET) Date: Wed, 16 Dec 1998 16:31:46 +0100 (MET) From: =?ISO-8859-1?Q?Tobias_=D6brink?= Reply-To: =?ISO-8859-1?Q?Tobias_=D6brink?= To: rem-conf@es.net Subject: Re: Slides from Orlando AVT meeting In-Reply-To: <199812161509.QAA06754@hercules.igd.fhg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mumrik.nada.kth.se id QAA00958 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 16 Dec 1998 wolt@igd.fhg.de wrote: >=20 > Hi, >=20 > you wrote: >=20 > Is there any free PPT/Word reader available? >=20 > Actually, there is. Called Deja Vu, it came out early this year and is = now > included in the Solaris 7 distribution (but should still be available > separately at www.sun.com).=20 : : > (and, FWIW DejaVu is unable to print, only to display on-screen) : : > --=20 > later, > Stephen >=20 > Fraunhofer-IGD | mailto: > Stephen Wolthusen | stephen@wolthusen.com > Rundeturmstr. 6 | swolthusen@acm.org > 64283 Darmstadt, GERMANY | wolt@igd.fhg.de > | wolt@capcom.de > |=20 > Tel +49 (0) 6151 155 539 (Bs.) | Fax: +49 (0) 6151 155 499 (Bs.) > +49 (0) 172 916 9883 | +49 (0) 6245 905 366 (Pri.) > +49 (0) 6245 6952 (Pri.) | Thanks Stephen /Tobias .........................................................................= ... Tobias =D6brink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: tobias@it.kth.se URL: http://www.it.kth.se/~nv91-tob/ See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html From rem-conf Wed Dec 16 08:52:57 1998 From rem-conf-request@es.net Wed Dec 16 08:52:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqK4Y-0002B4-00; Wed, 16 Dec 1998 08:45:14 -0800 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqK4X-0002Au-00; Wed, 16 Dec 1998 08:45:13 -0800 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id LAA11126; Wed, 16 Dec 1998 11:45:07 -0500 (EST) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA02367; Wed, 16 Dec 1998 11:45:28 -0500 Date: Wed, 16 Dec 1998 11:45:28 -0500 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199812161645.LAA02367@billings.csb> To: mbaugher@intel.com, Chris.Fulmer.chrisf@nt.com, C.Perkins@cs.ucl.ac.uk, henry.sinnreich@mci.com Subject: RE: Slides from Orlando AVT meeting Cc: rem-conf@es.net, rodgers@billings.nlm.nih.gov X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From rem-conf-request@es.net Wed Dec 16 09:17:44 1998 > From: "Henry Sinnreich" > > PowerPoint and Word files can be saved very nicely as HTML. Nothing wrong > with HTML and GIF's? Nothing at all -- this is the right way to go (more below)... > BTW: Any fundamental criteria for which is more proprietary: PDF or > PPT/Word? ;-) Yup -- just as with PostScript, the spec. for PDF is openly available, and there are already excellent freely available implementations, such as the PS to PDF converter that comes with ghostscript. Do you know of any comparable packages for PPT? I doubt very much that they exist. Both PS and PDF may have been developed outside of an open deliberative process, but they both certainly function as open standards now. A related comment on the broader issue here. It was said in an earlier posting by another party that "the IETF favors PowerPoint." Translation: "certain participants at IETF meetings prefer to use PowerPoint." I'm not aware of any official pronouncement on this point, and suspect that I would be just one member of a rather large and unruly mob if any such a pronouncement were to be made. It would run counter to the deeply rooted vendor- and platform- independent ethic of the IETF and its work. I think we all ought to strive mightily to use vendor-independent standards in the work we do both in and out of the IETF. And I think that this mitigates against the use of proprietary systems such as PowerPoint. > Thanks, Henry Cheerio, Rick Rodgers From rem-conf Wed Dec 16 10:57:14 1998 From rem-conf-request@es.net Wed Dec 16 10:57:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqM2M-00041x-00; Wed, 16 Dec 1998 10:51:06 -0800 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqM2L-00041n-00; Wed, 16 Dec 1998 10:51:05 -0800 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id KAA29418; Wed, 16 Dec 1998 10:50:58 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id KAA21742 for ; Wed, 16 Dec 1998 10:50:57 -0800 (PST) Date: Wed, 16 Dec 1998 10:50:57 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199812161850.KAA21742@jackson.cs.ucsb.edu> To: IPMULTICAST@STARDUST.COM, end2end-interest@ISI.EDU, rem-conf@es.net, tccc@ieee.org Subject: 43rd IETF Sessions on the IMJ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (lists bcc'ed to prevent accidental multi-mailing list responses). *** Announcing Availability of the 43rd IETF Sessions on the IMJ I'm ready to announce that most of the sessions from the 43rd IETF in Orlando, FL that were transmitted on the MBone are now available on the IMJ (http://imj.gatech.edu) for on-demand playback. You can schedule programs via the WWW page and start the MBone sessions via SDR (or the WWW page with a simple plug-in). For additional information about the MBone see http://mbone.com and http://ipmulticast.com/. Not much to report this time around about the IETF except that we offered two high speed video channels, one of which had two video feeds. We are gaining experience digitally recording sessions and now have a relatively quick turnaround on availability. For the record, the plan is to have the last 3 sets of IETF meetings archived on the MBone. We've got the last three available now: 41st, 42nd, and 43rd. Future plans in regard to content include making talks from conferences available as well. I'm working on some angles here. Also, A NEW SERVICE has been started for those who want access to the source files themselves. The latest batch of IETF files are available at ftp://ftp.cc.gatech.edu/pub/people/kevin/. Please be gentle on the ftp server since these files are around 100 MB for video and 40 MB for audio. And finally, one interesting characteristic of the IMJ that most of you won't notice but is interesting is that we now have two servers on the back end of the IMJ. There is one server at Georgia Tech and one at UCSB. The exact location of playout will depend on the request and where the content is located. There is no duplication of content, and this "distributed playout" system was implemented as a first step of a new project and because we ran out of disk space at Georgia Tech. Finally, and as usual, I've included the original IMJ e-mail announcement for those who want additional information about the IMJ. Any suggestions for improvement are welcome. -Kevin **** Announcing the Interactive Multimedia Jukebox At one point on the MBone list there was a discussion of what on-demand servers exist or are being developed. Well, I'd like to announce our version called the Interactive Multimedia Jukebox (IMJ). The IMJ web page is a request and scheduling interface for the playout of content over the MBone. CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM). Also check out mcontrol (http://imj.ucsb.edu/mcontrol/) a new MBone playout control tool for real-time broadcasts written in Java. The IMJ page is located at http://imj.gatech.edu. Information about the IMJ including general info, a postscript version of a paper about the IMJ, how-to-use information, and how it was implemented can be found at http://www.cc.gatech.edu/computing/Telecomm/IMJ/. (Recent note: the paper will be appearing in the WWW7 conference in Brisbane, Australia) Some quick additional information about the IMJ is included below: IMJ Audio/Video ----------------- The IMJ uses the WWW to submit requests which are then scheduled for playout on the MBone. Right now we are offering three channels: Channels 1 and 2 are being broadcast at a TTL of 127. Channel 3 is for internal testing and has a a TTL of 15. Each channel provides DVI-2 audio and 128 Kbps H.261 video. The encoding was done using Henning Schulzrinne's rtpplay and rtpdump. Scheduling ---------- Program scheduling uses a set of criteria to decide on which channel to schedule a program. The current set of criteria are listed just below the interactive schedule. We are exploring lots of different options. Content ------- We have been working on the jukebox paradigm with Turner Broadcasting, and as a result of their interest they have agreed to let us broadcast content on the MBone. I am particularly excited about this aspect because of their help and interest in investigating new applications on the Internet. The plan is to add a new set of content about every two weeks. When this happens, the old content will be moved to the secondary request menu for two weeks. The old-old stuff will be removed. Hopefully I'll be able to advertise on the MBone list when the new stuff is available. Development Platform -------------------- As is mentioned in the paper on the IMJ information page we are using the IMJ as a platform for a variety of research issues including providing interactivity, supporting multiple heterogeneous streams, video server organization, tracking usage, program scheduling, and pricing. Please send any feedback or suggestions to almeroth@cs.ucsb.edu or kevin@cc.gatech.edu. From rem-conf Thu Dec 17 03:57:41 1998 From rem-conf-request@es.net Thu Dec 17 03:57:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqbxS-0004M6-00; Thu, 17 Dec 1998 03:51:06 -0800 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqbxQ-0004Lw-00; Thu, 17 Dec 1998 03:51:04 -0800 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with SMTP id MAA10993 for ; Thu, 17 Dec 1998 12:50:23 +0100 (MET) Received: from betz by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA03037; Thu, 17 Dec 1998 12:49:53 +0100 From: Lars.Westberg@era-t.ericsson.se (Lars Westberg T/N) Received: by betz (SMI-8.6/client-1.3) id MAA01191; Thu, 17 Dec 1998 12:36:11 +0100 Date: Thu, 17 Dec 1998 12:36:11 +0100 Message-Id: <199812171136.MAA01191@betz> To: rem-conf@es.net Subject: RTP-header Compression X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi! We would like generate compressed RTP-headers for evaluation purposes but we need traces of compressed header information and have difficulties to generate them our-self. Is any implementation RTP/UDP/IP header compression available on the net ? Is it possible to get traces of uncompressed or compressed headers ? Could someone help me ? Regards Lars Westberg From rem-conf Thu Dec 17 05:15:42 1998 From rem-conf-request@es.net Thu Dec 17 05:15:40 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zqdDb-0004FB-00; Thu, 17 Dec 1998 05:11:51 -0800 Received: from imtest3.mcit.com ([166.37.172.6]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0zqdDZ-0004Eg-00; Thu, 17 Dec 1998 05:11:49 -0800 Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27]) by imtest3.mcit.com (8.8.7/) with ESMTP id IAA25192; Thu, 17 Dec 1998 08:08:45 -0500 (EST) Received: from sinnreich2 ([166.44.130.195]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19981217130908.FTSG18202@[166.44.130.195]>; Thu, 17 Dec 1998 07:09:08 -0600 From: "Henry Sinnreich" To: "R. P. Channing Rodgers, M.D." , , , Cc: , Subject: RE: Slides from Orlando AVT meeting Date: Thu, 17 Dec 1998 07:08:51 -0500 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.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <199812161645.LAA02367@billings.csb> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Of all the vendor independent graphic formats, the PNG format should be on top of the list. Please see http://w3c.org/Graphics/PNG/ (Fortunately my PowerPoint package can save as PNG) Would PNG be acceptable as a matter of principle? Thanks, Henry > -----Original Message----- > From: R. P. Channing Rodgers, M.D. [mailto:rodgers@nlm.nih.gov] > Sent: Wednesday, December 16, 1998 11:45 AM > To: mbaugher@intel.com; Chris.Fulmer.chrisf@nt.com; > C.Perkins@cs.ucl.ac.uk; henry.sinnreich@mci.com > Cc: rem-conf@es.net; rodgers@billings.nlm.nih.gov > Subject: RE: Slides from Orlando AVT meeting > > > > > From rem-conf-request@es.net Wed Dec 16 09:17:44 1998 > > From: "Henry Sinnreich" > > > > PowerPoint and Word files can be saved very nicely as HTML. > Nothing wrong > > with HTML and GIF's? > > Nothing at all -- this is the right way to go (more below)... > > > BTW: Any fundamental criteria for which is more proprietary: PDF or > > PPT/Word? ;-) > > Yup -- just as with PostScript, the spec. for PDF is openly available, > and there are already excellent freely available implementations, such > as the PS to PDF converter that comes with ghostscript. Do you know of > any comparable packages for PPT? I doubt very much that they exist. > Both PS and PDF may have been developed outside of an open deliberative > process, but they both certainly function as open standards now. > > A related comment on the broader issue here. > It was said in an earlier posting by another party that "the IETF > favors PowerPoint." Translation: "certain participants at IETF meetings > prefer to use PowerPoint." I'm not aware of any official pronouncement > on this point, and suspect that I would be just one member of a rather > large and unruly mob if any such a pronouncement were to be made. > It would run counter to the deeply rooted vendor- and platform- > independent ethic of the IETF and its work. > > I think we all ought to strive mightily to use vendor-independent > standards in the work we do both in and out of the IETF. And I think > that this mitigates against the use of proprietary systems such as > PowerPoint. > > > Thanks, Henry > > Cheerio, Rick Rodgers > From rem-conf Thu Dec 17 05:55:14 1998 From rem-conf-request@es.net Thu Dec 17 05:55:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqdqv-00061M-00; Thu, 17 Dec 1998 05:52:29 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zqdqs-00061C-00; Thu, 17 Dec 1998 05:52:27 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 17 Dec 1998 13:48:01 +0000 To: Henry Sinnreich cc: "R. P. Channing Rodgers, M.D." , mbaugher , "Chris.Fulmer.chrisf" , rem-conf , rodgers Subject: Re: Slides from Orlando AVT meeting In-reply-to: Your message of "Thu, 17 Dec 1998 07:08:51 EST." Date: Thu, 17 Dec 1998 13:48:00 +0100 Message-ID: <1041.913902480@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Quoting from http://www.ietf.org/instructions/slides.html "The online slide submissions are critical to the preparation of both the on-line and hardcopy versions of the proceedings, and should be submitted either as a PowerPoint (preferred) or PostScript file, one slide per page . The submissions can be sent either as a MIME message component or via an emailed URL." If that's what the secretariat want, then that's what we should provide since their job is difficult enough as it is. If this argument has to continue, can we please take it to someplace other than rem-conf? Colin --> Henry Sinnreich writes: >Of all the vendor independent graphic formats, the PNG format should be on >top of the list. >Please see http://w3c.org/Graphics/PNG/ > >(Fortunately my PowerPoint package can save as PNG) >Would PNG be acceptable as a matter of principle? > >Thanks, Henry > > >> -----Original Message----- >> From: R. P. Channing Rodgers, M.D. [mailto:rodgers@nlm.nih.gov] >> Sent: Wednesday, December 16, 1998 11:45 AM >> To: mbaugher@intel.com; Chris.Fulmer.chrisf@nt.com; >> C.Perkins@cs.ucl.ac.uk; henry.sinnreich@mci.com >> Cc: rem-conf@es.net; rodgers@billings.nlm.nih.gov >> Subject: RE: Slides from Orlando AVT meeting >> >> >> >> > From rem-conf-request@es.net Wed Dec 16 09:17:44 1998 >> > From: "Henry Sinnreich" >> > >> > PowerPoint and Word files can be saved very nicely as HTML. >> Nothing wrong >> > with HTML and GIF's? >> >> Nothing at all -- this is the right way to go (more below)... >> >> > BTW: Any fundamental criteria for which is more proprietary: PDF or >> > PPT/Word? ;-) >> >> Yup -- just as with PostScript, the spec. for PDF is openly available, >> and there are already excellent freely available implementations, such >> as the PS to PDF converter that comes with ghostscript. Do you know of >> any comparable packages for PPT? I doubt very much that they exist. >> Both PS and PDF may have been developed outside of an open deliberative >> process, but they both certainly function as open standards now. >> >> A related comment on the broader issue here. >> It was said in an earlier posting by another party that "the IETF >> favors PowerPoint." Translation: "certain participants at IETF meetings >> prefer to use PowerPoint." I'm not aware of any official pronouncement >> on this point, and suspect that I would be just one member of a rather >> large and unruly mob if any such a pronouncement were to be made. >> It would run counter to the deeply rooted vendor- and platform- >> independent ethic of the IETF and its work. >> >> I think we all ought to strive mightily to use vendor-independent >> standards in the work we do both in and out of the IETF. And I think >> that this mitigates against the use of proprietary systems such as >> PowerPoint. >> >> > Thanks, Henry >> >> Cheerio, Rick Rodgers >> > From rem-conf Thu Dec 17 06:22:52 1998 From rem-conf-request@es.net Thu Dec 17 06:22:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqeGE-0006hz-00; Thu, 17 Dec 1998 06:18:38 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqeGD-0006hp-00; Thu, 17 Dec 1998 06:18:37 -0800 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA18541; Thu, 17 Dec 1998 09:18:34 -0500 (EST) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA15200; Thu, 17 Dec 1998 09:18:33 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <367912B8.6E60B57@cs.columbia.edu> Date: Thu, 17 Dec 1998 09:18:32 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich CC: "R. P. Channing Rodgers, M.D." , mbaugher@intel.com, Chris.Fulmer.chrisf@nt.com, C.Perkins@cs.ucl.ac.uk, rem-conf@es.net, rodgers@billings.nlm.nih.gov Subject: Re: Slides from Orlando AVT meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henry Sinnreich wrote: > > Of all the vendor independent graphic formats, the PNG format should be on > top of the list. > Please see http://w3c.org/Graphics/PNG/ > > (Fortunately my PowerPoint package can save as PNG) > Would PNG be acceptable as a matter of principle? The problem with PNG (and GIF) is that it's only pixels. With PDF and PPT and other formats, I can print the slides at print (600 to 1200 dpi) resolution and cut-and-paste. GIF/PNG slides look fine on the screen, but look very low-res when printed, since the typical resolution is only 75 to 100 dpi. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Dec 17 07:53:16 1998 From rem-conf-request@es.net Thu Dec 17 07:53:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqfX8-000036-00; Thu, 17 Dec 1998 07:40:10 -0800 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0zqfX6-00002v-00; Thu, 17 Dec 1998 07:40:09 -0800 Received: from research.att.com ([135.207.30.100]) by rumor; Thu Dec 17 10:33:08 EST 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Thu Dec 17 10:38:29 EST 1998 Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA21012; Thu, 17 Dec 1998 10:37:53 -0500 (EST) Message-ID: <005401be29d3$4e678d00$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: , , Subject: Packet Video 99 Submission Deadline EXTENDED to JAN 7th 99 Date: Thu, 17 Dec 1998 10:38:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ******** DEADLINE EXTENDED ********* ---------------------------------------------------------------------- Due to the large volume of requests we are extending the deadline to JAN. 7th 1999 ---------------------------------------------------------------------- CALL FOR PAPERS Packet Video '99 The 9th International Packet Video Workshop 26-27 April 1999 New York City, U.S.A http://www.research.att.com/~mrc/PacketVideo99.html In Europe: http://www.inria.fr/rodeo/turletti/pv99/ Sponsored by: AT&T, Columbia University, EURASIP, IEEE Signal Processing Society IMDSP & MMSP Technical Committees The ninth International Packet Video Workshop (PV' 99) will be held at the Davis auditorium, of Columbia University in New York City. The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to seeing you in New York City in April 1999 for what will be a most rewarding and exciting experience! PV'99 is scheduled to take place in the week following Picture Coding Symposium 99 (PCS' 99) which is being held in Portland Oregon, on 21-23 April 1999. For information on PCS'99 please contact: pcs@pcs.ece.orst.edu TECHNICAL PROGRAM The technical program of Packet Video '99 will consist of invited talks, submitted paper presentations, poster sessions and a plenary session: "After Internet Telephony, Internet Television..." Topics of interest include, but are not limited to, the following: * Video streaming over the Internet * Network adaptive video coding and transport * Packetized video for home LAN's * Packetized video for wireless/mobile systems * Layered coding for error resilience and heterogeneous networks * Packet loss resilient coding and transport * Terminal and server architectures for Internet TV * Efficient transcoding for heterogeneous networks * Congestion control * Error concealment * Statistical multiplexing for greater network and terminal utilization * Traffic shaping for efficient network and terminal utilization * Interstream synchronization for multiple video presentations * Performance modeling and evaluation * Rate control for VBR video * International Standards: MPEG-4, MPEG-7, H.263+, RTP, RTSP, SIP, SDP * Multicasting, MBONE applications * Implementations and commercial applications Best Paper Award: The author of the best paper will receive: A $250 cash prize graciously donated by NEC USA, C&C Research Laboratories. Manuscripts submitted to PV'99 will be considered for publication in the special issue of EURASIP Journal Signal Processing: Image Communication, REAL-TIME VIDEO OVER THE INTERNET also. Submissions Please submit an electronic manuscript written in HTML, not exceeding 7 Mbytes and 10 printed pages. We will produce a CD-ROM containing the accepted papers. Electronic components accompanying your submission are strongly encouraged. Submit your work in ONE of the following forms: 1) a set of HTML files organized in a single directory and compressed with zip or WinZip OR 2) as a URL (you must have the rights to all the material there, and guarantee stability of the files until the conference). Detailed submission instructions for authors and help with manuscript preparation with HTML can be found on the conference web page: http://www.research.att.com/~mrc/PacketVideo99.html ALL SUBMISSIONS MUST BE RECEIVED no later than: Jan. 7th, 1999, NOTIFICATION OF ACCEPTANCE: February 28, 1999 FINAL PAPERS DUE: March 15, 1999 GENERAL CHAIR PUBLICATION & LOCAL ARRANGEMENTS M. Reha Civanlar Andrea Basso AT&T Labs - Research AT&T Labs - Research 100 Schultz Drive, 3-213 100 Schultz Drive, 3-219 Red Bank, NJ 07701 Red Bank, NJ 07701 USA USA civanlar@research.att.com basso@research.att.com PACKET VIDEO' 99 INTERNATIONAL STEERING COMMITTEE John Arnold, University of New South Wales, Australia Andrea Basso, AT&T Labs - Research, USA Stephen Casner, Precept Software, USA Shih-Fu Chang, Columbia University, USA Leonardo Chiariglione, CSELT, Italy M. Reha Civanlar, AT&T Labs - Research, USA Jon Crowcroft, University College of London, UK Mohammed Ghanbari, University of Essex UK Barry G. Haskell AT&T Labs - Research, USA Steven McCanne, U. C. Berkeley, USA Geoff Morrison, BT Labs, UK Joerg Ott, University of Bremen, Germany Sakae Okubo, Graphics Communication Labs, Japan D. Raychaudhuri, NEC Research, USA Amy Reibman, AT&T Labs - Research, USA Henning Schulzrinne, Columbia University, USA Gary Sullivan, PictureTel, USA Toshitaka Tsuda, Fujitsu, Japan Thierry Turletti, INRIA, France Stephan Wenger, Technical University of Berlin, Germany Hiroshi Yasuda, NTT, Japan From rem-conf Thu Dec 17 08:58:15 1998 From rem-conf-request@es.net Thu Dec 17 08:58:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqgg8-0001Ki-00; Thu, 17 Dec 1998 08:53:32 -0800 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqgg6-0001KY-00; Thu, 17 Dec 1998 08:53:30 -0800 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id LAA05029; Thu, 17 Dec 1998 11:53:29 -0500 (EST) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA03547; Thu, 17 Dec 1998 11:53:51 -0500 Date: Thu, 17 Dec 1998 11:53:51 -0500 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199812171653.LAA03547@billings.csb> To: henry.sinnreich@mci.com, C.Perkins@cs.ucl.ac.uk Subject: Re: Slides from Orlando AVT meeting Cc: rodgers@nlm.nih.gov, mbaugher@intel.com, Chris.Fulmer.chrisf@nt.com, rem-conf@es.net, rodgers@billings.nlm.nih.gov X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I stand corrected -- thanks for quoting chapter and verse, Colin, and yes, no more about this here 8^) But I will grumble to the secretariat -- I think this is a terrible policy... Cheerio, Rick Rodgers > From C.Perkins@cs.ucl.ac.uk Thu Dec 17 08:50:08 1998 > To: Henry Sinnreich > cc: "R. P. Channing Rodgers, M.D." , > mbaugher , > "Chris.Fulmer.chrisf" , > rem-conf , rodgers > Subject: Re: Slides from Orlando AVT meeting > Date: Thu, 17 Dec 1998 13:48:00 +0100 > From: Colin Perkins > Content-Length: 2895 > > Quoting from http://www.ietf.org/instructions/slides.html > > "The online slide submissions are critical to the preparation of > both the on-line and hardcopy versions of the proceedings, and > should be submitted either as a PowerPoint (preferred) or > PostScript file, one slide per page . The submissions can be sent > either as a MIME message component or via an emailed URL." > > If that's what the secretariat want, then that's what we should provide > since their job is difficult enough as it is. If this argument has to > continue, can we please take it to someplace other than rem-conf? > > Colin > > > --> Henry Sinnreich writes: > >Of all the vendor independent graphic formats, the PNG format should be on > >top of the list. > >Please see http://w3c.org/Graphics/PNG/ > > > >(Fortunately my PowerPoint package can save as PNG) > >Would PNG be acceptable as a matter of principle? > > > >Thanks, Henry > > > > > >> -----Original Message----- > >> From: R. P. Channing Rodgers, M.D. [mailto:rodgers@nlm.nih.gov] > >> Sent: Wednesday, December 16, 1998 11:45 AM > >> To: mbaugher@intel.com; Chris.Fulmer.chrisf@nt.com; > >> C.Perkins@cs.ucl.ac.uk; henry.sinnreich@mci.com > >> Cc: rem-conf@es.net; rodgers@billings.nlm.nih.gov > >> Subject: RE: Slides from Orlando AVT meeting > >> > >> > >> > >> > From rem-conf-request@es.net Wed Dec 16 09:17:44 1998 > >> > From: "Henry Sinnreich" > >> > > >> > PowerPoint and Word files can be saved very nicely as HTML. > >> Nothing wrong > >> > with HTML and GIF's? > >> > >> Nothing at all -- this is the right way to go (more below)... > >> > >> > BTW: Any fundamental criteria for which is more proprietary: PDF or > >> > PPT/Word? ;-) > >> > >> Yup -- just as with PostScript, the spec. for PDF is openly available, > >> and there are already excellent freely available implementations, such > >> as the PS to PDF converter that comes with ghostscript. Do you know of > >> any comparable packages for PPT? I doubt very much that they exist. > >> Both PS and PDF may have been developed outside of an open deliberative > >> process, but they both certainly function as open standards now. > >> > >> A related comment on the broader issue here. > >> It was said in an earlier posting by another party that "the IETF > >> favors PowerPoint." Translation: "certain participants at IETF meetings > >> prefer to use PowerPoint." I'm not aware of any official pronouncement > >> on this point, and suspect that I would be just one member of a rather > >> large and unruly mob if any such a pronouncement were to be made. > >> It would run counter to the deeply rooted vendor- and platform- > >> independent ethic of the IETF and its work. > >> > >> I think we all ought to strive mightily to use vendor-independent > >> standards in the work we do both in and out of the IETF. And I think > >> that this mitigates against the use of proprietary systems such as > >> PowerPoint. > >> > >> > Thanks, Henry > >> > >> Cheerio, Rick Rodgers > >> > > > From rem-conf Thu Dec 17 16:11:16 1998 From rem-conf-request@es.net Thu Dec 17 16:11:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zqnPF-0005Gm-00; Thu, 17 Dec 1998 16:04:33 -0800 Received: from proxy4.ba.best.com [206.184.139.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zqnPE-0005GV-00; Thu, 17 Dec 1998 16:04:32 -0800 Received: from mg132-104.ricochet.net (mg132-104.ricochet.net [204.179.132.104]) by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id QAA24743; Thu, 17 Dec 1998 16:00:49 -0800 (PST) Message-Id: <3.0.5.16.19981217165024.21673892@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Thu, 17 Dec 1998 16:50:24 To: "Angel L. Mateo" From: Ross Finlayson Subject: Re: A "sdr" source-code patch for directory sessions Cc: rem-conf@es.net In-Reply-To: <199812161037.LAA06802@chico.rediris.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:37 AM 12/16/98 +0100, Angel L. Mateo wrote: > I have tried the patch but I can do it works. I have done the following: > >1. I have download the patch (I save with the sdrpatch.diff name), the directory icon, the plugins,... >2. The patch refers to sdr.old and sdr.new directorys, so I have rename the sdr/src directory to sdr/src.old and I have copied sdr/src.old to sdr/sdr.new. >3. Then I have run: "patch < sdrpatch.diff. This reports me only the error that I don't have any parsed_plugins.tcl file. >4. A copy the plugins that I have downloaded to the sdr/src.new/plugins directory and the directory.xbm to the sdr/src.new Angel, At this point, if you haven't done so already, please try copying the files "sdr2.plugin.S50.directory" and "sdr2.plugin.S51.directory.sap.sdp" (available from ) to your "plugins/" directory, and try rebuilding a new "parsed_plugins.tcl" file from scratch. (Please follow up by replying just to me, to avoid bothering the entire "rem-conf" list.) By the way, it would be good if someone (e.g., UCL?) were to incorporate this patch into the 'official' "sdr" release (including the pre-compiled binaries). Ross. From rem-conf Sat Dec 19 03:46:40 1998 From rem-conf-request@es.net Sat Dec 19 03:46:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zrKdF-0001dU-00; Sat, 19 Dec 1998 03:33:13 -0800 Received: from laas.laas.fr [140.93.0.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zrKdD-0001dE-00; Sat, 19 Dec 1998 03:33:11 -0800 Received: from klebs.laas.fr (khalil@klebs [140.93.192.5]) by laas.laas.fr (8.9.1a/8.9.1) with ESMTP id MAA28328; Sat, 19 Dec 1998 12:32:14 +0100 (MET) Received: (from khalil@localhost) by klebs.laas.fr (8.9.1a/8.9.1) id MAA11854; Sat, 19 Dec 1998 12:31:53 +0100 (MET) Date: Sat, 19 Dec 1998 12:31:53 +0100 (MET) From: Khalil Drira Message-Id: <199812191131.MAA11854@klebs.laas.fr> To: atm96@inesc.pt, atm@sun.com, cost237-transport@comp.lancs.at, bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, cif@injector.ca.sandia.gov, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, comswtc@gmu.edu, dbword@cs.wisc.edu, enternet@bbn.com, apc@eee.nthu.edu.tw, ersads99-br@di.fc.ul.pt, ersads99-euro@di.fc.ul.pt, ersads99-pt@di.fc.ul.pt, ersads99-resto@di.fc.ul.pt, atm97authors@inesc.pt, ersads99-usa@di.fc.ul.pt, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, hipparch@sophia.inria.fr, ieee.announce@bellcore.com, osimcast@bbn.com, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, end2end-interest@ISI.EDU Subject: CFP Coordination session in PDPTA'99 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Our apologies for duplicate messages] ======================================================================= Call for Papers Special Session on Coordination in Parallel and Distributed Applications and Activities http://www.laas.fr/~khalil/cpdaa A session in PDPTA'99 June 28 - July 1, 1999 Monte Carlo Resort, Las Vegas, Nevada, USA http://www.cps.udayton.edu/~pan/pdpta/ This session is an approved technical session in the 5th International Conference on Parallel and Distributed Processing Techniques and Applications, PDPTA'99 (http://www.cps.udayton.edu/~pan/pdpta and http//www.jhpc.org/pdpta). Aims and scope =============== The emergence of new work activities, where remote participants -supported by coordination and collaboration tools- collaborate to achieve complex tasks, makes coordination from, both the activity and the software point of view, an important research issue. Coordination is, by nature, an inter-disciplinary research area involving different research skills and serving different application areas. This includes process coordination in multi-threaded programs, components coordination in concurrent applications, workflow management in CSCW, transactions in distributed applications, etc. The purpose of this session is to bring together researchers, and practitioners working on coordination in these different disciplinaries. The session serves as a forum enabling experience exchange between academia and industry as well as between researchers working in the different coordination research branches. Topics ====== Topics of interest include but are not limited to: o multisites coordination o dynamic architecture management for multi-component applications o coordination software architecture o coordination models and applications for collaborative work and CSCW o group decision protocols o coordination models for programming languages and application to Java and CORBA. o formal and semi-formal techniques for coordination description and analysis Accepted papers publishing ============================ Papers describing original research results are solicited and authors are encouraged to address both theoretical and practical aspects of coordination. All submitted papers will be subject to peer review and papers accepted for presentation at PDPTA'99 will be published in the conference Proceedings. Some technical sessions will be considered for publication in relevant international journals. Paper submission ================= Prospective authors are invited to submit three copies of their draft paper (about 4 pages) to one of the session co-chairs (address is given below) by the due date. E-mail and Fax submissions are also acceptable. The length of the Camera-Ready papers (if accepted) will be limited to 7 pages. Papers must not have been previously published or currently submitted for publication elsewhere. The first page of the draft paper should include: title of the paper, name, affiliation, postal address, E-mail address, telephone number, and Fax number for each author. The first page should also include the name of the author who will be presenting the paper (if accepted) and a maximum of 5 keywords. Important dates ================= March 1, 1999 (Monday): Draft papers (about 4 pages) due April 5, 1999 (Monday): Notification of acceptance May 1, 1999 (Monday): Camera-Ready papers & Prereg. due June 28 - July 1, 1999: PDPTA'99 Conference Session co-chairs ================= Khalil DRIRA Raul JACINTO MONTES Communication Tools and Software Group Distributed and Parallel Systems Group LAAS-CNRS CINVESTAV 7, Av. Colonel Roche Prol. Av. Lopez Mateos Sur 590 31077 Toulouse Cedex 4 c.p. 45090 Guadalajara Jalisco FRANCE MEXICO e-mail: khalil@laas.fr e-mail: rjacinto@gdl.cinvestav.mx Tel: +33 5 61 33 63 22 Tel: +52 3 6.84.15.80 Fax: +33 5 61 33 64 11 Fax: +52 3 6.84.17.08 WEB-ADRESSES : PDPTA'99: http://www.cps.udayton.edu/~pan/pdpta and http//www.jhpc.org/pdpta From rem-conf Mon Dec 21 07:03:01 1998 From rem-conf-request@es.net Mon Dec 21 07:03:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zs6bC-0001Np-00; Mon, 21 Dec 1998 06:46:18 -0800 Received: from lima.irisa.fr [131.254.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zs6bA-0001Nf-00; Mon, 21 Dec 1998 06:46:16 -0800 Received: from irisa.fr (borneo.irisa.fr [131.254.41.54]) by lima.irisa.fr (8.9.1a/8.9.1) with ESMTP id PAA25634; Mon, 21 Dec 1998 15:46:06 +0100 (MET) Message-ID: <367E5F2B.DFC1F41F@irisa.fr> Date: Mon, 21 Dec 1998 15:46:04 +0100 From: Christine Guillemot X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: "Anders Klemets (Exchange)" CC: "'rem-conf@es.net'" , "'4onip-sys@fzi.de'" <4onip-sys@fzi.de> Subject: Re: Comments on Generic RTP Payload Format proposal References: <69D8143E230DD111B1D40000F8485840073B4E16@ED> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lima.irisa.fr id PAA25634 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Anders, Thanks a lot for the constructive comments. Anders Klemets (Exchange) a =E9crit: > I have a couple of minor comments on the Generic RTP Payload Format > proposal, draft-guillemot-genpayload-00.txt, that was presented at the = IETF > AVT working group meeting. > > The payload format supports grouping and fragmentation, of higher level > "application units". It is also possible to carry arbitrary extension = data. > It is through this extension mechanism that the payload format can be m= ade > to support FEC with parity codes, FEC with Reed-Solomon codes, redundan= cy, > etc. > > The correct interpretation of the extension data is given by the XT > (Extension Type) header field. I think the main concern that I heard f= rom > several people at the IETF meeting, was that this introduces an extra > multiplexing point. To figure out how to interpret an RTP packet, one = must > first look at the RTP Payload Type field, and then look at the XT field= in > the generic payload format. May be I am missing something here, and sorry if I do, but I do not see why this should be 'more an issue' than to parse and interpret a payload header as in the pa= yload formats for H.261, H.263, H.263+, MPEG1 etc, .... The payload header in these formats may contain some redundant data (duplicated picture headers= ), that has to be parsed and interpreted by a so-called 'network adaptation = layer' which is going to examine if the previous packet has been received correc= tly ..etc and if the duplicated data has to be passed to the decoder. The idea was to apply the same scenario but allowing different types of protections, like a 'flexible payload header'. For example, looking at the video syntax hierarchy, the duplicated data may have a different structure depending on the AU it refers to, dependin= g on the level of the hierarchy (VOsequence, VO, VOL, GOV, VOPs....). The same mechanim could be used also for redundant data as audio re-encod= ed at a lower rate, or for other types of protection like parity codes. > > > However, after having looked at the Internet-Draft again, I now think t= his > might not be such a big issue after all. The reason is that the > Internet-Draft does not specify any static assignments for the XT field. > Rather, it says that the values to be used for the XT field should be > communicated out-of-band, using SDP or similar mechanisms. Yes. > > > I would think that in most cases, the extension data field would not be > used, or it would only be used in one single way. For instance, I think= it > is unlikely that some packets in an RTP session would have extension da= ta > for parity FEC, while other packets in the same session would use > Reed-Solomon FEC. Yes I agree it would be probably unlikely to mix parity FEC and R-S FEC, = butone could think of mixing protection in the sense of repeating vital headers with some protection like duplicating audio data at a lower rate, or like parity codes of less vital but still important video information... > > > So, when SDP indicates that there are 0-1 valid values for the XT field= , the > RTP receiver can effectively ignore the field. Thus, the problem with = the > additional multiplexing point becomes a non-issue in the typical case. > Yes, the XT field is not used when one does not need/want additional protectionof the streams or segments of streams like decoder config param= eters or others... > Given this, one could argue that the XT field should be removed, althou= gh > that would give up some flexibility that could be useful in the future.= In > any case, it seems clear that 8 bits is an excessively large size for t= his > field. > Yes, the number of bits for this field can be reduced. > I would also like to second Jonathan Rosenberg's comment, that it is be= tter > to specify the format of the extension data field by referring to the > relevant documents, rather than including the text explicitly in this > Internet-Draft. Of course, there might be cases where no relevant docu= ment > exists. In those cases, it might still be better to publish the format= of > the extension data field in a different document, which would be separa= te > from the document that specifies the Generic Payload Format. Actually the part in the I-D concerning the usage for R-S and parity code= sneeds definitely to be revised. Actually what we were thinking of, was to use the XT to select a FEC mechanism, including the pattern used for the FEC, namely the mask from a pre-defined set instead of having the= mask inserted in the extension data, this would save the size of the field for= the mask (24 bits). This may limit the number of possible patterns (masks) but at= this level, we may not need all the possibilities provided by the 24 bits mask. > > > I also have some comments regarding the alignment of the various fields= in > the payload format. The primary concern of any payload format that > implements "grouping" or "multiplexing", is to reduce the number of pac= kets. > The second concern would be to reduce the number of bytes in the payloa= d > format header. This is quite important when very small application uni= ts > are grouped together. To achieve this second goal, I think most people > would accept giving up word alignment of header fields, as long as the > header fields are still aligned to byte boundaries. > > In this payload format, however, individual header fields are not byte > aligned. Padding is inserted at the end of the last header field to en= sure > that the payload begins at a byte boundary. I know that byte alignment= is > not an issue in the MPEG world (Just look at the MPEG-4 SL-Packet heade= r > definition and you will be either horrified or delighted, depending on = where > you come from) but in the IETF header fields are typically aligned. > > I have two different proposals for how the header syntax can be modifie= d. > Both proposals ensure that header fields are byte aligned, but they wor= k a > little bit differently. The proposals all show that byte alignment can= be > achieved at a maximum cost of one byte, sometimes even less. > > Proposal 1: > > * Reduce the XT field from 8 bits to 6 bits. As discussed earlier, it = is > hard to conceive of a situation where someone would want more than 64 > different kinds of Extension Data in the same RTP session. > yes :-). > * If E=3D0, insert a new field with 5 bits, directly following the F fi= eld. > The 5 bits are reserved and should always be set to 0. > > * The size of the LENGTH field is increased from 13 to 16 bits. > > This causes all header fields to be aligned with byte boundaries. No > padding field is necessary. This comes at a cost, however. If you loo= k at > example #3 in draft-guillemot-genpayload-00.txt, you might see that the > second header, which consists only of flags and a LENGTH field, will > increase from two bytes to three bytes. And this is a fairly common ca= se, > because it happens whenever the packet consists of extension data and a= n > application unit that is not being fragmented. > > Proposal 2: > > * Reduce the XT field from 8 bits to 6 bits. See comment above. > > * If E=3D1, increase the size of the LENGTH field from 13 to 16 bits. > > * If E=3D0, the size of the LENGTH field remains at 13 bits. > > * If G=3D0 and E=3D0, the size of TSOFFSET is reduced from 16 to 13 bit= s. > > * If G=3D1 or E=3D1, the size of TSOFFSET remains at 16 bits. > > * If the FOFFSET field would directly follow the flag fields (because > neither LENGTH nor TSOFFSET is present), insert 5 reserved bits in fron= t of > FOFFSET, instead of adding 5 bits of padding at the end of FOFFSET. > > This causes all header fields to be aligned with byte boundaries. And = this > comes at no extra cost in terms of the header size. As a matter of fac= t, > this scheme saves one entire byte when the payload header only contains= the > TSOFFSET field. (See example #1, in draft-guillemot-genpayload-00.txt.= ) Thanks for these suggestions. The document is in a very preliminary versi= on and is open for amendments. > Of > course, you may already have noticed that there is another kind of cost > associated with this proposal: complexity. > Let us imagine that we have an application with first an MPEG-4 video str= eam, for which wewant only to protect the vital information, let's say the dec= oder configuration parameters, by repeating this information. Let us consider for this video stream two levels of such config parameters: 1) the GOV header parameters needed for the random access point functiona= lity and 2) the VOP decoder config parameters. Let us assume that this application also uses an audio stream in which we want to use the redundant mechanism which consists in repeating the audio data transmitted in packet n-1 and in packet n-2 at a lower rat= e. Why this payload format would be more complicated than supporting two pay= load formats, namely: 1)- the redundant audio payload format for which you would need a process to parse and interpret the payload header, extract the data of packet n-1= and data of packet n-2, see if these data are really needed (namely if the previous n= -1 and n-2 packets have been received correctly) in order to parse the right data to the rig= ht decoders. 2)- an MPEG-4 video payload format, which would also parse its own header= , extract the duplicated headers, and pass them to the decoder if relevant = (i.e. if previous packets containing these headers have been lost). The complexity resides in the protection mechanism (computing the FEC, extracting, interpreting, the redundant data, recovering loss packets from the redund= ant data...), which we would have to support in both cases, either in the case of 2 payload f= ormats, one format for each stream, or in the case of one payload for both streams. I do not see why the fact of having factorized the grouping mechanism int= o one single format, and to propose to signal the type of protection with the XT field would b= ring more complexity. Now if we want to use this mechanism for applying FEC (parity codes or R-= S) on different segments of streams, then this may be more complex. But the complexity would come from the target of Unequal Error Protection, so again from the= FEC computation mechanism, more than from the payload encapsulation process itself. Right= ? thanks again, Best regards, Christine > Anders From rem-conf Mon Dec 21 08:24:32 1998 From rem-conf-request@es.net Mon Dec 21 08:24:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zs83y-0002e8-00; Mon, 21 Dec 1998 08:20:06 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zs83w-0002dy-00; Mon, 21 Dec 1998 08:20:04 -0800 Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Mon Dec 21 11:19:45 EST 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA21007; Mon, 21 Dec 1998 11:19:43 -0500 (EST) Message-ID: <367E7470.7213E5D1@dnrc.bell-labs.com> Date: Mon, 21 Dec 1998 11:16:48 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Christine Guillemot CC: "Anders Klemets (Exchange)" , "'rem-conf@es.net'" , "'4onip-sys@fzi.de'" <4onip-sys@fzi.de> Subject: Re: Comments on Generic RTP Payload Format proposal References: <69D8143E230DD111B1D40000F8485840073B4E16@ED> <367E5F2B.DFC1F41F@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Christine Guillemot wrote: > > > So, when SDP indicates that there are 0-1 valid values for the XT field, the > > RTP receiver can effectively ignore the field. Thus, the problem with the > > additional multiplexing point becomes a non-issue in the typical case. > > > > Yes, the XT field is not used when one does not need/want additional > protectionof the streams or segments of streams like decoder config parameters > or others... > > > Given this, one could argue that the XT field should be removed, although > > that would give up some flexibility that could be useful in the future. In > > any case, it seems clear that 8 bits is an excessively large size for this > > field. > > > > Yes, the number of bits for this field can be reduced. This observation can apply equally well to the payload type indicator in the RTP header. With dynamic payload types, the number of bits in the header need only cover the number of possible codecs/payload formats one might observe during a particular session. > > > I would also like to second Jonathan Rosenberg's comment, that it is better > > to specify the format of the extension data field by referring to the > > relevant documents, rather than including the text explicitly in this > > Internet-Draft. Of course, there might be cases where no relevant document > > exists. In those cases, it might still be better to publish the format of > > the extension data field in a different document, which would be separate > > from the document that specifies the Generic Payload Format. > > Actually the part in the I-D concerning the usage for R-S and parity codesneeds > definitely to be revised. > Actually what we were thinking of, was to use the XT to select a > FEC mechanism, including the pattern used > for the FEC, namely the mask from a pre-defined set instead of having the mask > inserted in the extension data, this would save the size of the field for the > mask > (24 bits). This may limit the number of possible patterns (masks) but at this > level, we may not need all the possibilities provided by > the 24 bits mask. This also is an argument that can be applied directly to the parity document. The original proposal by Budge et. al. did explicitly that; it enumerated each FEC mechanism and assigned it a number. The packet contained just that number, effectively a payload type, plus some other parameters, like position in the block (I think). The more generic mechanism was preferred seems it allows a really wide range of algorithms with a not-so-unreasonable overhead. This allows for vendor differentiation in terms of choices of algorithms, and for the ability to do adaptation over a broad operating range. I don't see why the reasons for choosing the more generic mechanism apply there but not here. It seems we are falling into this particular tradeoff issue over and over, both here and in the muxing work - efficiency vs. flexibility. For any protocol, one can make all kinds of assumptions about its operating range, and then optimize the header to work only under those assumptions. Or, one can leave it flexible at the expense of more bits. Which is the right direction to go often seems a matter of religion and personal preference. I think its fair to say that in the past, generality and flexibility seem to have won (RTP being fairly flexible and applicable over a wide range of operation). I personally feel that choosing generality over efficiency (within reason, of course) is better. Time and time again, we have seen reuse and innovative applications of general protocols. Optimizing protocols for particular applications just means that when you assumptions change, you need to design a new protocol for the new assumptions. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Dec 22 19:18:46 1998 From rem-conf-request@es.net Tue Dec 22 19:18:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zsegI-0006xq-00; Tue, 22 Dec 1998 19:09:50 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zsegG-0006xg-00; Tue, 22 Dec 1998 19:09:48 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.1/8.9.1) with ESMTP id MAA16939 for ; Wed, 23 Dec 1998 12:09:41 +0900 (JST) Message-Id: <199812230309.MAA16939@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: vic-2.8 problem. In-reply-to: Your message of "Wed, 11 Nov 1998 06:07:18 +0900." <199811102107.GAA28741@aohakobe.ipc.chiba-u.ac.jp> Date: Wed, 23 Dec 1998 12:09:40 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi. I sent a message about "vic-2.8 problem" on 11th, November. Hakan from cdt.luth.se responded to me that > Vic 2.8 has a memory leak. 13 bytes are wasted for each incomming > RTCP addr. and gave me the diff below. (thanks!) yes, I'm also observing the process is growing bigger and bigger and die at last. with this patch I tried and succeeded to compile vic-2.8 with tcl7.6 and tk4.2, but dumps core right after starting... (segmentation fault at Tcl_GetFileInfo().) I know the right version of tcl and tk for vic-2.8 is tcl7.5 and tk4.1, and does say nothing about newer version, but I want to avoid installing older version of tcl&tk. anyone trying to provide the binary merging the patch, or release vic-2.8.1 with tcl&tk8? -- yozo. %%%% diff -c /usr/local/src/multicast/vic/vic-2.8/source.cc{.orig,} %%%% *** /usr/local/src/multicast/vic/vic-2.8/source.cc.orig Fri Apr 5 00:05:45 1996 --- /usr/local/src/multicast/vic/vic-2.8/source.cc Wed Nov 11 23:33:39 1998 *************** *** 250,260 **** tcl.result(wrk); return (TCL_OK); } ! if (strcmp(argv[1], "addr") == 0) { ! strcpy(wrk, InetNtoa(addr_)); ! tcl.result(wrk); ! return (TCL_OK); ! } if (strcmp(argv[1], "srcid") == 0) { sprintf(wrk, "%lu", (u_long)ntohl(srcid_)); tcl.result(wrk); --- 250,263 ---- tcl.result(wrk); return (TCL_OK); } ! if (strcmp(argv[1], "addr") == 0) { ! /* HL 980415 Memory leak fix (hakanl@cdt.luth.se) */ ! char *ptr= InetNtoa(addr_); ! strcpy(wrk, ptr); ! free(ptr); ! tcl.result(wrk); ! return (TCL_OK); ! } if (strcmp(argv[1], "srcid") == 0) { sprintf(wrk, "%lu", (u_long)ntohl(srcid_)); tcl.result(wrk); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From rem-conf Wed Dec 23 11:55:13 1998 From rem-conf-request@es.net Wed Dec 23 11:55:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zsu5l-00054N-00; Wed, 23 Dec 1998 11:37:09 -0800 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zsu5k-000544-00; Wed, 23 Dec 1998 11:37:08 -0800 Received: from roo.isi.edu (roo.isi.edu [128.9.160.127]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id LAA13378; Wed, 23 Dec 1998 11:37:07 -0800 (PST) Posted-Date: Wed, 23 Dec 1998 11:37:06 -0800 (PST) Received: from localhost by roo.isi.edu (5.65c/4.0.3-6) id ; Wed, 23 Dec 1998 11:37:06 -0800 Date: Wed, 23 Dec 1998 11:37:06 -0800 (PST) From: Steven Berson To: Yozo Toda Cc: rem-conf@es.net Subject: Re: vic-2.8 problem. In-Reply-To: <199812230309.MAA16939@aohakobe.ipc.chiba-u.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 23 Dec 1998, Yozo Toda wrote: > anyone trying to provide the binary merging the patch, > or release vic-2.8.1 with tcl&tk8? Yozo, The version of vic with FreeBSD has patches for tcl&tk8. Cheers, Steve From rem-conf Thu Dec 24 10:58:45 1998 From rem-conf-request@es.net Thu Dec 24 10:58:43 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ztFZQ-0004hN-00; Thu, 24 Dec 1998 10:33:12 -0800 Received: from pri-ra-1128.isdn.net.il ([212.25.75.128] helo=secure.com) by mail2.es.net with smtp (Exim 1.92 #1) id 0ztFZM-0004h0-00; Thu, 24 Dec 1998 10:33:09 -0800 To: From: Subject: Free Tip Date: ไ, 24 ใ๖๎แ๘ 1998 16:56:39 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Investor, Free Tip Iceberg would like you to have this free tip on world currency: Dollar vs. Japanese Yen is going to go up in the next few weeks between 4% and 8%. we hope you find it useful. and remember, this is just the Tip of the Iceberg. regards, the Free Tip Team. note: If you are not and investor or otherwise do not want to get a free tip, reply with subject line "remove". From rem-conf Sat Dec 26 17:52:04 1998 From rem-conf-request@es.net Sat Dec 26 17:52:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zu51Y-0003y6-00; Sat, 26 Dec 1998 17:29:40 -0800 Received: from pri-ra-1223.isdn.net.il (secure.com) [212.25.75.223] by mail1.es.net with smtp (Exim 1.81 #2) id 0zu51S-0003wP-00; Sat, 26 Dec 1998 17:29:35 -0800 To: From: Subject: Free Tip Date: เ, 27 ใ๖๎แ๘ 1998 00:06:57 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Investor / Business person, Free Tip Iceberg would like you to have the following tip on world currency: Dollar is going to go up vs. the Japanese Yen between 4% and 8% in the next few weeks. We hope you find it useful. And remember, this is just the Tip of the Iceberg. regards, Free Tip Iceberg team. note: if you are not an investor or business person or otherwise do not want to get a free tip, please reply with subject "remove". From rem-conf Mon Dec 28 00:37:51 1998 From rem-conf-request@es.net Mon Dec 28 00:37:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zuY0Q-0005bc-00; Mon, 28 Dec 1998 00:26:26 -0800 Received: from wolf1.wolf.net (mail.wolf.net) [209.49.165.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zuY0O-0005bS-00; Mon, 28 Dec 1998 00:26:24 -0800 Received: from [207.240.233.19] [207.240.233.19] by mail.wolf.net with ESMTP (SMTPD32-4.07) id A966DBF0228; Mon, 28 Dec 1998 02:55:18 EST5EDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Dec 1998 00:28:06 -0400 To: Tempting Tear-Outs From: Tempting Tear-Outs Subject: 047 ===>> FREE 1 yr USA Magazine Sub sent worldwide-200+ Choices! Up to $50.00 value! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To be removed from our mailing list, send a blank email message, with the subject of "remove" to: tempting.tear-outs@wolf.net -- FOR MORE INFO: please "cut out" the below form on the "cut" lines shown, and fax it, for the fastest reply to: 1-718-227-9125 (this is a fax # in the USA) or send via smail (first class mail or airmail) to: Tempting Tear-Outs Att. Free-catalogue-by-email Dept 3835 Richmond Ave. Suite #200 Staten Island NY 10312-3828 USA SORRY, BUT.... our software is not set up to accept the below form via return email; WE CAN ONLY acknowledge forms sent in via fax or smail. --> IMPORTANT complete directions, to ensure that you get a reply, and more info follow, below the reply form and the catalogue options. *------------cut here/begin-------------------------------------------* Name (First Middle Last): Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: Cellular (Mobile) Tel. #: Beeper (Pager) Tel. #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 0122798-l-aaa Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY: 1. you must call from an "unblocked number," ie. one that is not blocked >from caller id. We are very sorry for this requirement, but our fax software requires this before it allows an incoming fax call to connect. If you have a blocked number, you must first unblock it. In most cases this means dialing *82 from a touch-tone phone (or 1182 from a rotary phone) before you dial 1-718-227-9125. NOTE: If you are not sure if your number is blocked, just try dialing our fax # normally. If you don't get a recording telling you your number is blocked, your number has been transmitted and you may press the start button on your fax when you hear the fax tone from our fax. 2. no reply forms can be accepted by email....only via fax or smail. 3. your form must be typewritten or printed out on your computer printer before you fax it; sorry, but *no* handwritten forms will be acknowledged. If you can't find someone with a typewriter or a computer printer, we apologize for not being able to reply to you. 4. faxes with cover pages will be rejected. You must send *only* the reply form. 5. forms not *completely* filled in will not be acknowledged. 6. you will receive a reply within 1 business day directly from the company making the offer via email. Therefore you must have an email address. If you read this message, then you must have an email address, or access to one, at least. :-) 7. your fax must not exceed 1 page in length. Faxes of 2 or more pages will be sensed, then auto-terminated and deleted. Your fax goes directly onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1 page. 8. all faxes must begin with: *------------cut here/begin-------------------------------------------* and must end with: *------------cut here/end--------------------------------------------* 9. Any fax not conforming to this format will be sensed by our software, then auto-terminated and deleted from the hard drive, before any human ever gets to see it. 10. The type on your fax must be dark and legible. If in doubt, please print it out darker before faxing it in. If we can't read it, we can't reply to you or send you our FREE catalogue. :-( 11. If this all seems too complicated for faxing, just do it the old fashioned way via smail!!! WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER: The company making the offer is a magazine subscription agency based in the USA. They have over 1,100 popular USA titles available to be shipped to *any* country, including of course, to anywhere in the USA! They offer a FREE 1 yr. subscription to your choice of over 200 of the titles in their catalogue to any new customer using them for the first time. The dollar value of the freebies, based on the subscription prices directly >from the publishers, ranges from $6.97 all the way up to $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,100+ titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly >from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas customers. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new customers who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the two formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa, American Express, Diner's Club and Carte Blanche. Overseas, they accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche, even if your credit card is a local one in local currency (that most merchants in the USA would not normally be willing to accept). That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on advertising rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, 3835 Richmond Ave. Suite #200, Staten Island NY 10312-3828, USA. From rem-conf Mon Dec 28 07:44:42 1998 From rem-conf-request@es.net Mon Dec 28 07:44:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zueku-0001MD-00; Mon, 28 Dec 1998 07:38:52 -0800 Received: from (icard.hkstar.com) [202.40.141.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zuekt-0001M3-00; Mon, 28 Dec 1998 07:38:51 -0800 Received: from girl.com (ip-41-17.dialup.hkstar.com [202.82.41.17]) by icard.hkstar.com (8.9.1/8.9.1) with ESMTP id XAA02397; Mon, 28 Dec 1998 23:37:30 +0800 (HKT) Received: from gnmj.jvokt.ktkn.com [210.222.100.200] by girl.com (FTGate 2, 1, 1, 0); Mon, 28 Dec 98 23:18:32 +0800 Message-Id: <199812282317.VII5055@gnmj.jvokt.ktkn.com> Date: Mon, 28 Dec 1998 11:17:34 PM Subject: 10 Asian SEX Girl Pictures a day !! X-UIDL: 870483743.727 From: wwspwq@rnii.igcrr.rrfh.com Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IF YOU ARE UNDER 21 DELETE NOW! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10 Asian SEX Girl Pictures a day !! http://members.tripod.com/xcds1234/door.html All models are at least 18 years of age! From rem-conf Mon Dec 28 11:26:21 1998 From rem-conf-request@es.net Mon Dec 28 11:26:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zuiGR-0003HR-00; Mon, 28 Dec 1998 11:23:39 -0800 Received: from mail1.radix.net [209.48.224.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zuiGQ-0003HH-00; Mon, 28 Dec 1998 11:23:38 -0800 Received: from TheOTG.com (port30.annex3.radix.net [209.48.226.158]) by mail1.radix.net (8.9.1/8.9.1) with ESMTP id OAA09882; Mon, 28 Dec 1998 14:14:42 -0500 (EST) Message-ID: <3687D958.8963C7BE@TheOTG.com> Date: Mon, 28 Dec 1998 14:17:44 -0500 From: "John Weiler, CTO and Founder" Organization: The OBJECTive Technology Group, an OMG Affiliate X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: ckobryn@shl.com CC: Taieb Znati , commsoft@cc.bellcore.com, odp@dstc.edu.au, dbworld@cs.wisc.edu, enternet@BBN.COM, JavaCORBA@luke.org, ISWORLD@Danann.hea.ie, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, 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, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@BBN.COM, rem-conf@es.net, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@IEEE.ORG, xtp-relay@cs.concordia.ca Subject: Free OMG Industry@OOTS Object/Internet Primer, Jan. 14 References: <199805211953.PAA15292@zeus.cs.pitt.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.radix.net id OAA09882 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chris, Attached is the final Industry@OOTS agenda. Please pass this complimentar= y invite to your customers, business associates and IT staff so they may take adva= ntage of this unique opportunity. It is designed for those who are pushing relate= d architecture initiatives and increase cooperation between industry advoca= tes. Many of the speakers are also engaged in the Interoperability Clearinghou= se initiative. ------------------- INDUSTRY@OOTS Object/Internet Primer ----------------= -- You and your associates are invited! Register today..... On Jan. 14th, 1999, the OMG in cooperation with The OBJECTive Technology = Group will be co-hosting the OMG Industry@OOTS Object/Internet Primer at the Cr= ystal Gateway Mariott. This one day free event will provide an architectural v= iew of how objects, components and the internet are being successfully adopted a= nd implemented by industry. Industries=92 top practitioners will gather to = provide a comprehensive set of tutorials on how this new set of standards based internet-enabled components come together for a Networked Information Ent= erprise. This FREE Industry@OOTS primer will be held at the Crystal Gateway Marrio= tt in Arlington, VA concurrently with the OMG Technical Committee meeting. The= theme will be "Networked Information Enterprise: From Architectures to Reality"= and will focus on defining those sets of internet-enabled interoperable frameworks= that have been successfully developed and deployed. Updated program information will be online at http://www.theotg.com, and registration at http://www.omg.org/techprocess/meetings/ootprmr.html. You= may also register by faxing your contact information (name, organization, title, p= hone, fax, email) to 508-820-4303, attention =93OMG INDUSTRY@OOTS Registration= ) or email the same to loughry@omg.org. SEATING IS EXTREMELY LIMITED, so register t= oday. AM Program: 0800-1200 0800 Introductions and State of the Market =96 JOHN WEILER CTO, The OBJEC= Tive Technology Group 0815 Architectures for Interoperability - RICHARD SOLEY CEO/Chairman OMG 0900 Networked Information Infrastructure - DR. LINTON WELLS Principal DA= SD, OSD C3I 0945 Enterprise CORBA Beans =96 BILL ROTH, Product Line Manager, Sun Micr= osystems (or alt) 1015 break 1030 COM/CORBA Interoperability =96 JEFF BRUNELL Group Mgr, META Group (C= hair), Andre Yee, Senior Director, R&D for SAGA Software, PETER KRUPP Sr. Archit= ect Iona Technologies, Rick Rosen, Sr. Architect, BEA (or alt) 1115 Components Architectures Panel =96 Brian Buck Director of Architectu= res Platinum Technology, PATTY DOCK VP Corporate Product Strategy, BEA, KEVIN= KERNAN VP Rational Software, DENNIS REEDY Sr. Java Architect Sun Microsystems PM Program: 1330-1800 1330 Implementing Internet-enabled Frameworks =96 MICHAEL NELSON Program = Director, Internet Technology IBM 1400 Developing the Component Architectures w/ XML, UML, MOF and XMI - SR= IDHAR IYENGAR Unisys Fellow 1430 Modeling Distributed Component-based Architectures Panel - NEAL MARP= LE SAIC (Chair), WILL TRACZ Lockheed Martin, SIDNEY BAILIN President KEI, JOAQAUI= N MILLER Sr. Architect MCI Worldcom 1515 break 1530 Making IT Happen Panel - KEN NORLAND Ernst & Young (Chair), BRUCE AM= BLER Lucent, BOB MARCUS VP GM, RICK BENNETT Architecture Foundations AT&T 1630 Electronic Commerce...Myths and Reality, Patty Dock, VP Corporate Pr= oduct Strategy BEA 1730 Interoperability Initiatives update - JOHN WEILER CTO T= he OBJECTive Technology Group, David Signori ISO Deputy Director, DARPA (or= alt) * bolded names =3D confirmed participation A set of white papers will be assembled with the sponsoring organizations= and posted at www.TheOTG.com. You MUST register beforehand via TheOTG web sit= e as we have done in the past for other OOTS seminars. Registration is online vi= a TheOTG web site or the following: http://www.omg.org/techprocess/meetings/ootspr= mr.html Details of these interoperable frameworks (specific technologies, product= s, and standards), will be entered into an online knowledge repository called th= e Interoperability Clearinghouse, and made available to sponsors, subscribe= rs and conference attendees. Information on this joint govt/industry initiative = can be found; http://www.omg.org/techprocess/meetings/ic.html or http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm Those who are not OMG members and are interested in attending the OMG Tec= hnical Committee meetings being held the week of Jan. 11th, can do so as a paid = guest of TheOTG ($350.) Fee includes all sessions, breaks and lunches for entire = week. For information regarding registration and fees, please go to; http://www.omg.org/techprocess/meetings/meetingreg.html ******************************************** John A. Weiler CTO & Founder, The OBJECTive Technology Group OMG Government Liaison Member OMG, IEEE, ACM, AFCEA 8011 Washington, Ave. Alexandria, VA 22308 703-768-0400(v) 703-765-9295(f) http://www.TheOTG.com (Industry@OOTS Forums) john_weiler@TheOTG.com "From Architectures to Reality" ********************************************* From rem-conf Mon Dec 28 15:56:08 1998 From rem-conf-request@es.net Mon Dec 28 15:56:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zumSC-0005fR-00; Mon, 28 Dec 1998 15:52:04 -0800 Received: from mail1.radix.net [209.48.224.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zumSB-0005fH-00; Mon, 28 Dec 1998 15:52:03 -0800 Received: from TheOTG.com (port30.annex3.radix.net [209.48.226.158]) by mail1.radix.net (8.9.1/8.9.1) with ESMTP id RAA28978; Mon, 28 Dec 1998 17:48:07 -0500 (EST) Message-ID: <36880B5D.B65B38CE@TheOTG.com> Date: Mon, 28 Dec 1998 17:51:09 -0500 From: "John Weiler, CTO and Founder" Organization: The OBJECTive Technology Group, an OMG Affiliate X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: john_weiler@omg.org Subject: Complimentary Industry@OOTS Object/Internet Primer, Jan. 14th. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.radix.net id RAA28978 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, The following is a complimentary invite to the OMG Industry@OOTS Object/Internet Architecture Primer held in Arlington VA on Jan. 14th 1999, from 0800 to 1800 hrs. Registration: http://www.omg.org/techprocess/meetings/ootsprmr.html inquiries: john_weiler@omg.org ----------------- INDUSTRY@OOTS Object/Internet Primer------------------ You and your associates are invited! On Jan. 14th, 1999, the OMG in cooperation with The OBJECTive Technology Group will be co-hosting the OMG Industry@OOTS Object/Internet Primer at the Crystal Gateway Mariott. This one day free event will provide an architectural view of how objects, components and the internet are being successfully adopted and implemented by industry. Industries=92 top practitioners will gather to provide a comprehensive set of tutorials on how this new set of standards based internet-enabled components come together for a Networked Information Enterprise. This FREE Industry@OOTS primer will be held at the Crystal Gateway Marriott in Arlington, VA concurrently with the OMG Technical Committee meeting. The theme will be "Networked Information Enterprise: From Architectures to Reality" and will focus on defining those sets of internet-enabled interoperable frameworks that have been successfully adopted, developed and deployed. Updated program information will be online at http://www.theotg.com, and registration at http://www.omg.org/techprocess/meetings/ootsprmr.html You may also register by faxing your contact information (name, organization, title, phone, fax, email) to 508-820-4303, attention =93OM= G INDUSTRY@OOTS Registration) or email the same to loughry@omg.org. SEATING IS EXTREMELY LIMITED, so register today. AM Program: 0800-1200 0800 Introductions and State of the Market =96 JOHN WEILER CTO, The OBJECTive Technology Group 0815 Architectures for Interoperability - RICHARD SOLEY CEO/Chairman OMG 0900 Networked Information Infrastructure - DR. LINTON WELLS Principal DASD, OSD C3I 0945 Enterprise CORBA Beans =96 BILL ROTH, Product Line Manager, Sun Microsystems (or alt) 1015 break 1030 COM/CORBA Interoperability =96 JEFF BRUNELL Group Mgr, META Group (Chair), Andre Yee, Senior Director, R&D for SAGA Software, PETER KRUPP Sr. Architect Iona Technologies, Rick Rosen, Sr. Architect, BEA (or alt) 1115 Components Architectures Panel =96 Brian Buck Director of Architectures Platinum Technology, PATTY DOCK VP Corporate Product Strategy, BEA, KEVIN KERNAN VP Rational Software, DENNIS REEDY Sr. Java Architect Sun Microsystems PM Program: 1330-1800 1330 Implementing Internet-enabled Frameworks =96 MICHAEL NELSON Program Director, Internet Technology IBM 1400 Developing the Component Architectures w/ XML, UML, MOF and XMI - SRIDHAR IYENGAR Unisys Fellow 1430 Modeling Distributed Component-based Architectures Panel - NEAL MARPLE SAIC (Chair), WILL TRACZ Lockheed Martin, SIDNEY BAILIN President KEI, JOAQAUIN MILLER Sr. Architect MCI Worldcom 1515 break 1530 Making IT Happen Panel - KEN NORLAND Ernst & Young (Chair), BRUCE AMBLER Lucent, BOB MARCUS VP GM, RICK BENNETT Architecture Foundations AT&T 1630 Electronic Commerce...Myths and Reality, Patty Dock, VP Corporate Product Strategy BEA 1730 Interoperability Initiatives update - JOHN WEILER CTO The OBJECTive Technology Group, David Signori ISO Deputy Director, DARPA (or alt) * bolded names =3D confirmed participation A set of white papers will be assembled with the sponsoring organizations and posted at www.TheOTG.com. You MUST register beforehand via TheOTG web site as we have done in the past for other OOTS seminars. Registration is online via TheOTG web http://www.theotg.com site or the OMG site: http://www.omg.org/techprocess/meetings/ootsprmr.html Details of these interoperable frameworks (specific technologies, products, and standards), will be entered into an online knowledge repository called the Interoperability Clearinghouse, and made available to sponsors, subscribers and conference attendees. Information on this joint govt/industry initiative can be found; http://www.omg.org/techprocess/meetings/ic.html or http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm Those who are not OMG members and are interested in attending the OMG Technical Committee meetings being held the week of Jan. 11th, can do so as a paid guest of TheOTG ($350.) Fee includes all sessions, breaks and lunches for entire week. For information regarding registration and fees, please go to; http://www.omg.org/techprocess/meetings/meetingreg.html The OBJECTive Technology Group is an IT Architecture Consulting firm and one of the primary sponsors of the Interoperability Clearinghouse initiative. Current engagements are helping refine distributed architectures for major enterprises in Defense, Healthcare, Finance and Telecommunication industries. Some of these success and lessons learned will be portrayed in the annual Industry@OOTS conference series, and documented in the Interoperability Clearinghouse knowledge repository. ******************************************** John A. Weiler CTO & Founder, The OBJECTive Technology Group OMG Government Liaison Member OMG, IEEE, ACM, AFCEA 8011 Washington, Ave. Alexandria, VA 22308 703-768-0400(v) 703-765-9295(f) http://www.TheOTG.com (Industry@OOTS Forums) john_weiler@TheOTG.com "From Architectures to Reality" ********************************************* From rem-conf Tue Dec 29 12:03:04 1998 From rem-conf-request@es.net Tue Dec 29 12:03:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zv58f-0005Tv-00; Tue, 29 Dec 1998 11:49:09 -0800 Received: from 1cust178.tnt1.sylva.nc.da.uu.net (SKYSHOP) [208.254.171.178] by mail1.es.net with smtp (Exim 1.81 #2) id 0zv58X-0005Tk-00; Tue, 29 Dec 1998 11:49:08 -0800 From: SKYSHOP OFFICE SUPPLIES To: Message-Id: <419.436158.61900648skyshop@excite.com> Subject: Are you paying a to much for office supplies? Skyshop can save you money ..... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Tue, 29 Dec 1998 11:49:08 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are you paying to much for office supplies? Skyshop CAN save you money. If you would like to see our product line & website please email us back in the subject line of the below email address and place the letters (SP) Thank you! skyshop@gte.net Skyshop Office Supplies "We CAN save you MONEY & TIME" !! To be removed from our list please place the word remove and no further email will be sent to you at this mailing skyshop@gte.net From rem-conf Tue Dec 29 12:35:53 1998 From rem-conf-request@es.net Tue Dec 29 12:35:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zv5mo-0006QZ-00; Tue, 29 Dec 1998 12:30:38 -0800 Received: from jasper.cisco.com [171.69.198.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zv5mn-0006Q6-00; Tue, 29 Dec 1998 12:30:37 -0800 Received: from cisco.com (dhcp-i-222-174.cisco.com [171.69.222.174]) by jasper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA13054 for ; Tue, 29 Dec 1998 12:29:36 -0800 (PST) Message-ID: <36891E38.476D151E@cisco.com> Date: Tue, 29 Dec 1998 12:23:52 -0600 From: "Sanjay K. Agrawal" Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Voice and Video Traces Content-Type: multipart/mixed; boundary="------------A5F7B3A216491EB6F4B5A37D" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------A5F7B3A216491EB6F4B5A37D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am performing networking simulations on the voice and video traffic. I was wondering if anybody can point me to packetized (IP) voice and video traces (H.261) for the use in my simulations. Thanks very much, -Sanjay --------------A5F7B3A216491EB6F4B5A37D Content-Type: text/x-vcard; charset=us-ascii; name="sagrawal.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sanjay K. Agrawal Content-Disposition: attachment; filename="sagrawal.vcf" begin:vcard n:Agrawal;Sanjay tel;work:(408) 525-0938 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:ska@cisco.com end:vcard --------------A5F7B3A216491EB6F4B5A37D-- From rem-conf Tue Dec 29 20:28:04 1998 From rem-conf-request@es.net Tue Dec 29 20:28:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zvD88-0001zh-00; Tue, 29 Dec 1998 20:21:08 -0800 Received: from (artemis.petrobras.com.br) [200.255.28.10] by mail1.es.net with smtp (Exim 1.81 #2) id 0zvD86-0001zR-00; Tue, 29 Dec 1998 20:21:06 -0800 Received: by artemis.petrobras.com.br; (5.65v4.0/1.3/10May95) id AA14666; Wed, 30 Dec 1998 02:22:51 -0300 Message-Id: <199812300522.AA14666@artemis.petrobras.com.br> Date: 29 Dec 98 11:30:23 PM From: perotrump@3253137429.petrobras.com.br To: perotrump@3253137429.petrobras.com.br Subject: Ecstasy X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ecstasy - The Seduction Audio Cassette Tape! Can Modern Technology be used to put women into a more "receptive mood?" Can Modern Technology be used to make women "more attractive" to men? Can Modern Technology make you a better lover, a more satisfied lover, a more confident lover?          YES IT CAN! Read what just two customers said: "I never met so many women so happy to sleep with me!"           JK, Des Moines IA   "WOW. Thanks for a sexual experience I did not dream possible without drugs."           HP Manhattan, NY   According to Dr. Martin Feinberg:        "This is an amazing and unique tape. The sounds were designed to stimultate brain centers. To enhance pleasure. Reach new levels of sexual experiences without any chemicals or drugs but rather by allowing you mind to be stimulated by audio signals. The velvet voice provides a hypnotic-like state that produces a flow of intense pleasure and satisfaction. All that you need to do is listen." Hundreds of Tapes have been sold -- and rarely has one been returned. It is fully guaranteed to work as advertised or your money is refunded. You have NOTHING to lose. The Ecstasy tape was designed by a licensed Mental Health Counsellor specifically for her clients who had problems meeting the opposite sex, attracting the opposite sex, and having great sex with the opposite sex. Clinically tested, and set to digital music specifically designed to enhance the effects of the tape, you may never find another tape like it. Not yet sold in stores, it is only available on the Internet.     Listen to the Ecstasy Tape alone or with a lover or friend.     Listen to the Ecstasy Tape and change the way you meet women/men.     Listen to the Ecstasy Tape and change the way women and men feel about you.     Listen to The Ecstasy Tape and change the way you experience sex forever. 100% Legal. Is it mind control?        You'll have to listen and decide for yourself. GUARANTEED* TO:        Have potential lovers be attracted to you.        Be a Great Lover.        Maximize Your Sexual Pleasure.        Satisfy any lover.    *GUARANTEED or your money refunded! As you listen to the tape your body will feel what it never felt before.        Listen alone.        Or with a lover.        It is a most unbelievable, indescribable experience.        100% Legal.        Not a drug. But as powerful as drugs.        Not an aphrodisiac. But as powerful as one.        Not subliminal but more powerful. This tape, this experience is 100% legal, however, you must be over 18 to purchase it. No exceptions. Absolute satisfaction or purchase price refunded. Listen to the Ecstasy Tape. Experience True Sexual Ecstasy. For 6 months. If you can bear to return the tape after trying for up to 6 months, we will refund your payment. This may be your first and last opportunity to experience Ecstasy possibly the only seduction tape you'll ever find that really works. The digitally prepared Audio Cassette is $19.47 shipped to you. ($17.12 plus $2.45 shipping/handling). Florida residents add sales tax. It is easy to order. You must be over 18.  No exceptions. The digitally prepared Audio Cassette is $19.47  shipped to you. ($17.12 plus $2.45 shipping/handling).  Florida residents add sales tax. To order with your MasterCard, Visa, Discover or American Express card. Call our operators (24 hours) at (520) 453-0303 Extension - 222         And say "I'd like to order the Ecstasy Tape." OR         mail a check or money order for $19.47 to:                Euphoria Products                1859 No Pine Island Rd.                Suite #133 Dept.222                Plantation, FL 33322         Include your name and street address and write "I would like __ copies of the Ecstasy Tape # 222."  Get extra tapes as gifts: add $9.50 for each additional tape. No additional shipping. The Mailing List that you are being mailed from was filtered against a Global Filter List. If you would like not to recieve any other mailings of this type please call 1-888-7456328 From rem-conf Wed Dec 30 06:10:58 1998 From rem-conf-request@es.net Wed Dec 30 06:10:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zvME5-0005gC-00; Wed, 30 Dec 1998 06:03:53 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zvME3-0005fj-00; Wed, 30 Dec 1998 06:03:51 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA02075; Wed, 30 Dec 1998 09:02:17 -0500 (EST) Message-Id: <199812301402.JAA02075@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links to Proposed Standard Date: Wed, 30 Dec 1998 09:02:17 -0500 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" 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 documents defines a protocol for reducing the size of IP, UDP and RTP packets sent over a serial link by compressing out header information that is constant, changes rarely, or only changes by small increments. For small packets and slow links, the savings in transmission time can be quite significant. Working Group Summary The proposed protocol received solid working group support for its technical merits. There was however controversy within the WG that the protocol could not be deployed soon enough to meet the quickly emerging needs of Internet Telephony and similar applications. The alternative was to specify an end-to-end compression of just the RTP header that could be implemented in the applications themselves as an interim solution until the link-level compression specified in this draft could be deployed. Considering that the gain of compressing RTP alone would be relatively small and that it could not be standardized in the necessary timeframe, the prevalent position was that AVT should not define such an interim solution. Protocol Quality Vern Paxson reviewed the specification for the IESG. The protocol is sound, thoroughly analyzed, and builds appropriately on the earlier work of RFC 1144. From rem-conf Wed Dec 30 12:25:10 1998 From rem-conf-request@es.net Wed Dec 30 12:25:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zvS4V-0001BX-00; Wed, 30 Dec 1998 12:18:23 -0800 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zvS4U-0001BN-00; Wed, 30 Dec 1998 12:18:22 -0800 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id MAA01577; Wed, 30 Dec 1998 12:18:20 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id MAA07029 for ; Wed, 30 Dec 1998 12:18:18 -0800 (PST) Date: Wed, 30 Dec 1998 12:18:18 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199812302018.MAA07029@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Re: Voice and Video Traces Cc: sagrawal@cisco.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>I am performing networking simulations on the voice and video traffic. I >>was >>wondering if anybody can point me to packetized (IP) voice and >> video traces (H.261) for the use in my simulations. The IETF source files would probably work: ftp://ftp.cc.gatech.edu/people/kevin/ -Kevin