From rem-conf Mon Mar 01 00:08:31 1999 From rem-conf-request@es.net Mon Mar 01 00:08:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10HNdA-0005Aj-00; Mon, 1 Mar 1999 00:00:48 -0800 Received: from pop3.tu-dresden.de [141.30.2.83] by mail1.es.net with smtp (Exim 1.81 #2) id 10HNd9-0005AZ-00; Mon, 1 Mar 1999 00:00:47 -0800 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Mon, 1 Mar 1999 08:54:25 +0100 Received: from rncmm2.urz.tu-dresden.de by rmail with SMTP (IC-PP); Mon, 1 Mar 1999 08:54:02 +0100 Received: from localhost (fleck@localhost) by rncmm2.urz.tu-dresden.de (8.8.8+Sun/8.8.8) with SMTP id JAA03660; Mon, 1 Mar 1999 09:00:28 +0100 (MET) X-Authentication-Warning: rncmm2.urz.tu-dresden.de: fleck owned process doing -bs Date: Mon, 1 Mar 1999 09:00:28 +0100 (MET) From: Christoph Fleck X-Sender: fleck@rncmm2.urz.tu-dresden.de Reply-To: Multimedia Referenzzentrum To: Ross Finlayson cc: Patrick De Muynck , Rex Xi Xu , mbone@ISI.EDU, rem-conf@es.net, Multimedia Referenzzentrum Subject: Re: "liveCaster": MP3 streaming via multicast In-Reply-To: <3.0.5.16.19990228102359.0e27d09e@shell7.ba.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >I have a related question, which is if there exists a generic program > >which can handle the "application/sdp" MIME type, i.e. it should be > >able to accept an .sdp file, parse the SDP announcement, and then > >startup the proper audio/video tools > [...] > >Would "multikit" be able to do this? > > Not at present, although it could be modified to do this (thanks for the > suggestion :-) Right now multikit, like "sdr", can launch SDP sessions > from its own, built-in directory GUI - but cannot launch SDP files that > come from someone else's directory GUI (e.g., from a separate web browser). Try a perl script (written by Rex Xi Xu rexx@cs.cmu.edu) that can do that. Thats the only one, I have fond to do that, on Windows. It needs still some extensions. My description (sorry only in german): http://www-mm.urz.tu-dresden.de/mbone/sessions/ the script for win95/98 (using start.exe for background): ftp://ftp-mm.urz.tu-dresden.de/pub/mbone/mmrz/sdp.pl/win95/sdp.pl the script for unix: ftp://ftp-mm.urz.tu-dresden.de/pub/mbone/mmrz/sdp.pl/unix/sdp.pl If anybody makes some improvements or has a better soultion, please let me know. Rgds, Christoph Fleck ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Mon Mar 01 16:17:23 1999 From rem-conf-request@es.net Mon Mar 01 16:17:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10HcZ2-0007RC-00; Mon, 1 Mar 1999 15:57:32 -0800 Received: from firebreath.prognet.com (virginia.dev.prognet.com) [204.71.154.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 10HcZ1-0007R2-00; Mon, 1 Mar 1999 15:57:31 -0800 Received: from virginia (virginia@localhost [127.0.0.1]) by virginia.dev.prognet.com (8.7.5/8.7.3) with SMTP id PAA02142; Mon, 1 Mar 1999 15:57:13 -0800 Sender: virginia@virginia.dev.prognet.com Message-ID: <36DB2959.76D59F7E@real.com> Date: Mon, 01 Mar 1999 15:57:13 -0800 From: Virginia Thomas Organization: RealNetworks,Inc X-Mailer: Mozilla 3.04Gold (X11; I; Linux 2.0.27 i586) MIME-Version: 1.0 To: Patrick De Muynck CC: mbone@ISI.EDU, rem-conf@es.net, Ross Finlayson Subject: Re: "liveCaster": MP3 streaming via multicast References: <199902281721.SAA22268@vivaldi.belnet.be> Content-Type: multipart/mixed; boundary="------------143F257DE31EF856AF0FDFA" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------143F257DE31EF856AF0FDFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Patrick, Yes, the RealPlayer G2 does support local and network playback of MP3. You were able to play the mp3 file locally which means you must have the Digital Bitcast Mpeg DLLs on your system. The Player will play network based MP3 content as long as it is streamed using standard RTP and the payload is specified according to what the avt wg has documented to date. For instance, the RealPlayer can be used to playback content served by vic/vat and the ICast server, as you mentionned below. I've attached a NasaTV SDP file which you can load directly into your RealPlayer. I believe NasaTV is being streamed by an ICast server. Note: the player will grab the H.261 and PCM plugins from the update server. Can you send me the SDP file that you tried loading into the RealPlayer? THanks, Virginia Patrick De Muynck wrote: > > I thought that RealPlayer G2 should be able to do the job, because: > > - with the new so called "scalable multicast" support it's able to > play an RTP/RCP multicasted stream and furthermore to parse the > SDP announcement that describes the stream > > - it has Codec support for playing MP3 > > It didn't work for me however. > > Here's what I tried: I started broadcasting with the liveCaster, > sending SDP announcements. I launched the RealPlayer by using Peter > Parnes' WEB-based multicast Session Directory > (http://www.cdt.luth.se/~peppar/progs/mSD/) and clicking on the > liveCaster announcement (alternatively you can just save the SDP > announcement on disk as a file with extension ".sdp" > and open that file in RealPlayer). Note: if you install RealPlayer G2 > on a PC it becomes the default program for the MIME type "application/sdp" > MIME type, file extension = .sdp . > > The result was that it receives the stream but can't play it: actually > it goes to the RealNetworks WEB site to find an "unknown codec" > plugin. Then it reports that no appropriate plugin was found :-( > > That's rather strange because the RealPlayer streamed the MP3 file > from disk all right... So why? > > FYI: using RealPlayer G2 / scalable multicast this way works for > playback of one-way MBone sessions which use H261/DVI/PCM... > > I have a related question, which is if there exists a generic program > which can handle the "application/sdp" MIME type, i.e. it should be > able to accept an .sdp file, parse the SDP announcement, and then > startup the proper audio/video tools like MBone or RealPlayer G2. So > something similar as mLaunch (http://www.cdt.luth.se/~peppar/progs/mlaunch/) > but it should also support Windows and it should be more configurable > concerning the choice of the tools (not only MBone). Would "multikit" > be able to do this? > > Patrick De Muynck > > BELNET, the Belgian National Research Network > > Patrick.DeMuynck@belnet.be | DWTC - BELNET > Tel : +32/2/238.36.76 | Wetenschapsstraat, 4 > Fax : +32/2/513.57.30 | B-1000 Brussel > > In message <3.0.5.16.19990214154327.20975616@shell7.ba.best.com>, > Ross Finlayson writes: > >FYI, a quick update on the multicast MP3 audio tools that I first announced > >a couple of weeks ago: > > > >"liveCaster" (the multicast MP3 audio source): > > > >This can now take its MP3 input not only from ".mp3" files, but also from > >stdin, or from a HTTP stream (such as a 'Shoutcast' server, or just from a > >MP3 file on the web). Also, it will now automatically make an SDP > >announcements for its session (although you can choose not to do so). > > > >"playRTPMPEG" (the MP3/RTP/UDP multicast receiver tool): > > > >Unix versions (Linux, FreeBSD, Solaris/SPARC and IRIX) are now available. > >These will write the received MP3 frames to 'stdout', so you can use this > >tool to feed a separate MP3 player program (such as "X11Amp"). (The > >Windows version feeds the "Winamp" MP3 player, but by using a hack where it > >acts as a special-purpose HTTP server.) This tool doesn't do any buffering > >of the incoming MP3/RTP/UDP data; instead, it assumes that whatever > >application it feeds (via 'stdout') will have sufficient buffering. > > > >(I repeat my plea for someone to add MP3 decoding to an existing multicast > >audio tool, such as "rat". This would ultimately be a better solution.) > > > >Finally, both tools now do RTCP, although currently only at a basic level. > >(CNAME is the only item sent in a SDES, and the RRs are 'empty'.) > > > > Ross. -- ----------------------------------------------------------- Virginia Thomas, Program Manager 206.674.2267 virginia@real.com RealNetworks, Inc. 1111 Third Ave #2900 Home of RealAudio, RealVideo Seattle, WA 98101 and RealMedia http://www.real.com --------------143F257DE31EF856AF0FDFA Content-Type: text/plain; charset=us-ascii; name="nasa.sdp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nasa.sdp" v=0 o=- IN IP4 s= i= t=0 0 m=audio 22840 RTP/AVP 0 c=IN IP4 224.2.135.86/127 m=video 57914 RTP/AVP 31 c=IN IP4 224.2.135.86/127 --------------143F257DE31EF856AF0FDFA-- From rem-conf Mon Mar 01 16:17:23 1999 From rem-conf-request@es.net Mon Mar 01 16:17:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10HcbS-0007Rm-00; Mon, 1 Mar 1999 16:00:02 -0800 Received: from mtiwmhc07.worldnet.att.net [204.127.131.42] by mail1.es.net with esmtp (Exim 1.81 #2) id 10HcbN-0007RM-00; Mon, 1 Mar 1999 15:59:58 -0800 Received: from lobos ([12.72.54.40]) by mtiwmhc07.worldnet.att.net (InterMail v03.02.07 118 124) with SMTP id <19990301235847.EFWM6471@lobos>; Mon, 1 Mar 1999 23:58:47 +0000 X-Sender: lobosdelmar@postoffice.att.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 01 Mar 1999 15:49:42 -0800 To: rem-conf@es.net From: Ryan Thurman Subject: video training info Cc: drmm@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <19990301235847.EFWM6471@lobos> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, My name is Ryan Thurman and I am researching some information for a resource guide on the application of videoconferencing in telehealth for Dr. Marlene Maheu. Your answer to the following questions would be very helpful and your company will be cited appropriately. I am wondering if you have any information on the type of training that is packaged with your equipment. What is the normal procedure for training individuals after they have purchased the equipment? Could you describe some the important points involved in training people to use the videoconferencing equipment? What can you suggest for people who want more training with the equipment? Also, if your company is interested re-seller arrangements with Dr. Maheu please write at and put your vendor information at this address for us: http://cybertowers.com/cgibin/prof.cgi Thank you for your consideration, Ryan Thurman Research Assistant From rem-conf Tue Mar 02 02:42:08 1999 From rem-conf-request@es.net Tue Mar 02 02:42:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10HmUn-0005CJ-00; Tue, 2 Mar 1999 02:33:49 -0800 Received: from vivaldi.belnet.be [193.190.198.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10HmUk-0005C9-00; Tue, 2 Mar 1999 02:33:47 -0800 Received: from belnet.be (argos.belnet.be [193.190.198.37]) by vivaldi.belnet.be (8.8.8/mro1.4) with ESMTP id LAA21508; Tue, 2 Mar 1999 11:33:06 +0100 (MET) Message-Id: <199903021033.LAA21508@vivaldi.belnet.be> To: Virginia Thomas cc: mbone@ISI.EDU, rem-conf@es.net, Ross Finlayson Subject: Re: "liveCaster": MP3 streaming via multicast In-reply-to: Your message of "Mon, 01 Mar 1999 15:57:13 PST." <36DB2959.76D59F7E@real.com> Date: Tue, 02 Mar 1999 11:33:06 +0100 From: Patrick De Muynck X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If memory serves me well, the files tmp.sdp-1 and tmp.sdp-2 included below are the SDP announcements as they were captured respectively by the "multicast Session Directory" and by the Cisco router on our LAN. I didn't capture the cache files of sdr though, but I can try again. Do they look OK? :::::::::::::: tmp.sdp-1 :::::::::::::: v=0 o=- 920054817 3129043744 IN IP4 172.24.198.32 s=tmp i=MP3 audio e=patrick@belnet.be b=AS:320 t=3129043744 3129045364 a=type:broadcast a=tool:liveCaster v1.0a26 m=audio 49334 RTP/AVP 14 c=IN IP4 235.246.133.254/127 :::::::::::::: tmp.sdp-2 :::::::::::::: Session Name: tmp Description: MP3 audio Group: 0.0.0.0, ttl: 0, Contiguous allocation: 1 Lifetime: from 20:08:24 MET Feb 26 1999C until 20:35:24 MET Feb 26 1999C Uptime: 3d15h, Last Heard: 3d15h Announcement source: 172.24.198.32, destination: 224.2.127.254 Created by: - 920054817 3129044904 IN IP4 172.24.198.32 Phone number: Email: patrick@belnet.be URL: Media: audio 49334 RTP/AVP 14 Media group: 235.246.133.254, ttl: 127 :::::::::::::: In message <36DB2959.76D59F7E@real.com>, Virginia Thomas writes: > >Hi Patrick, > >Yes, the RealPlayer G2 does support local and network playback of MP3. >You were able to play the mp3 file locally which means you must have >the Digital Bitcast Mpeg DLLs on your system. > >The Player will play network based MP3 content as long as it is streamed >using standard RTP and the payload is specified according to what the >avt wg has documented to date. For instance, the RealPlayer can be used >to playback content served by vic/vat and the ICast server, as you >mentionned below. I've attached a NasaTV SDP file which you can load >directly into your RealPlayer. I believe NasaTV is being streamed by an >ICast server. Note: the player will grab the H.261 and PCM plugins from >the update server. > >Can you send me the SDP file that you tried loading into the RealPlayer? > >THanks, > >Virginia > > > > >Patrick De Muynck wrote: >> >> I thought that RealPlayer G2 should be able to do the job, because: >> >> - with the new so called "scalable multicast" support it's able to >> play an RTP/RCP multicasted stream and furthermore to parse the >> SDP announcement that describes the stream >> >> - it has Codec support for playing MP3 >> >> It didn't work for me however. >> >> Here's what I tried: I started broadcasting with the liveCaster, >> sending SDP announcements. I launched the RealPlayer by using Peter >> Parnes' WEB-based multicast Session Directory >> (http://www.cdt.luth.se/~peppar/progs/mSD/) and clicking on the >> liveCaster announcement (alternatively you can just save the SDP >> announcement on disk as a file with extension ".sdp" >> and open that file in RealPlayer). Note: if you install RealPlayer G2 >> on a PC it becomes the default program for the MIME type "application/sdp" >> MIME type, file extension = .sdp . >> >> The result was that it receives the stream but can't play it: actually >> it goes to the RealNetworks WEB site to find an "unknown codec" >> plugin. Then it reports that no appropriate plugin was found :-( >> >> That's rather strange because the RealPlayer streamed the MP3 file >> from disk all right... So why? >> >> FYI: using RealPlayer G2 / scalable multicast this way works for >> playback of one-way MBone sessions which use H261/DVI/PCM... >> >> I have a related question, which is if there exists a generic program >> which can handle the "application/sdp" MIME type, i.e. it should be >> able to accept an .sdp file, parse the SDP announcement, and then >> startup the proper audio/video tools like MBone or RealPlayer G2. So >> something similar as mLaunch (http://www.cdt.luth.se/~peppar/progs/mlaunch/) >> but it should also support Windows and it should be more configurable >> concerning the choice of the tools (not only MBone). Would "multikit" >> be able to do this? >> >> Patrick De Muynck >> >> BELNET, the Belgian National Research Network >> >> Patrick.DeMuynck@belnet.be | DWTC - BELNET >> Tel : +32/2/238.36.76 | Wetenschapsstraat, 4 >> Fax : +32/2/513.57.30 | B-1000 Brussel >> >> In message <3.0.5.16.19990214154327.20975616@shell7.ba.best.com>, >> Ross Finlayson writes: >> >FYI, a quick update on the multicast MP3 audio tools that I first announced >> >a couple of weeks ago: >> > >> >"liveCaster" (the multicast MP3 audio source): >> > >> >This can now take its MP3 input not only from ".mp3" files, but also from >> >stdin, or from a HTTP stream (such as a 'Shoutcast' server, or just from a >> >MP3 file on the web). Also, it will now automatically make an SDP >> >announcements for its session (although you can choose not to do so). >> > >> >"playRTPMPEG" (the MP3/RTP/UDP multicast receiver tool): >> > >> >Unix versions (Linux, FreeBSD, Solaris/SPARC and IRIX) are now available. >> >These will write the received MP3 frames to 'stdout', so you can use this >> >tool to feed a separate MP3 player program (such as "X11Amp"). (The >> >Windows version feeds the "Winamp" MP3 player, but by using a hack where it >> >acts as a special-purpose HTTP server.) This tool doesn't do any buffering >> >of the incoming MP3/RTP/UDP data; instead, it assumes that whatever >> >application it feeds (via 'stdout') will have sufficient buffering. >> > >> >(I repeat my plea for someone to add MP3 decoding to an existing multicast >> >audio tool, such as "rat". This would ultimately be a better solution.) >> > >> >Finally, both tools now do RTCP, although currently only at a basic level. >> >(CNAME is the only item sent in a SDES, and the RRs are 'empty'.) >> > >> > Ross. > >-- > >----------------------------------------------------------- >Virginia Thomas, Program Manager 206.674.2267 > virginia@real.com >RealNetworks, Inc. >1111 Third Ave #2900 Home of RealAudio, RealVideo >Seattle, WA 98101 and RealMedia >http://www.real.com From rem-conf Tue Mar 02 09:58:49 1999 From rem-conf-request@es.net Tue Mar 02 09:58:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10HtHO-0001FI-00; Tue, 2 Mar 1999 09:48:26 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10HtHN-0001F6-00; Tue, 2 Mar 1999 09:48:25 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 2 Mar 1999 17:47:30 +0000 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3704 To: Henning Schulzrinne , rem-conf@es.net Subject: G726/727 RTP Profile comments Date: Tue, 02 Mar 1999 17:47:28 +0100 Message-ID: <2739.920396848@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Quick question on the RTP profile for G726 / G727. * Section 4.5.6 G726-16/24/32/30 The payload format in draft-ietf-avt-profile-new-04.txt for G726 only specifies the packing order for G726-32 (4 bits per sample). The specified scheme aligns to byte boundaries as: +----+----+----+----+--- | S1 | S0 | S3 | S2 | ... +----+----+----+----+--- Looking at the ITU's G726 spec there does not appear to be a bitstream specified either. An obvious approach for all encodings is pack to the samples in the order they are produced. It makes the implementation marginally easier and means the sample time is monotonically increasing. For compatibility reasons it may be best to leave G726-32 alone. How many implementations implement this now? Are there implementations using 2,3,5 bits per sample? What have they elected to do? thanks /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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rem-conf Tue Mar 02 11:21:10 1999 From rem-conf-request@es.net Tue Mar 02 11:21:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Hudd-0002kC-00; Tue, 2 Mar 1999 11:15:29 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Hudc-0002jn-00; Tue, 2 Mar 1999 11:15:28 -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 LAA19009; Tue, 2 Mar 1999 11:15:22 -0800 (PST) Message-Id: <3.0.3.32.19990302111553.00959140@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 02 Mar 1999 11:15:53 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder 3/3 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 Parallel Software-Only Video Effects Processing Wednesday, March 3, 1999, 1:00-2:30 p.m. 405 Soda Hall Ketan Meyer-Patel Computer Science Division - EECS, UC Berkeley Experience in the television and film industries shows that video effects like fades, transitions, and titling improve the perceived quality of video material. Traditional production methods for video effects, however, are not well matched to the needs of Internet video streaming. In this talk, I describe a parallel software-only video effects processing system designed specifically for streaming Internet video. I will describe mechanisms for supporting different types of parallelism and show how their design is constrained by properties of streaming video formats and protocols. I will also describe a novel control mechanism built on Scalable Reliable Multicast (SRM). 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 Mar 02 22:43:10 1999 From rem-conf-request@es.net Tue Mar 02 22:43:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10I5B1-0000jP-00; Tue, 2 Mar 1999 22:30:39 -0800 Received: from mail1.radix.net [209.48.224.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 10I5Az-0000jF-00; Tue, 2 Mar 1999 22:30:38 -0800 Received: from TheOTG.com (port57.annex4.radix.net [209.48.225.185]) by mail1.radix.net (8.9.1/8.9.1) with ESMTP id VAA00017; Tue, 2 Mar 1999 21:10:23 -0500 (EST) Message-ID: <36DC9B11.99FE6D3F@TheOTG.com> Date: Tue, 02 Mar 1999 21:14:41 -0500 From: "John Weiler, CTO and Founder" Organization: The OBJECTive Technology Group X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: john_weiler@omg.org Subject: Interoperability Clearinghouse call for participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, The Interoperability Clearinghouse is formalizing as a govt. sanctioned 501C6 non-profit organization this quarter. We will be establishing several categories of membership to help map key information elements into this internet based knowledge repository of standards, "validated & interoperable COTS product suites" and associated implementation services. Those interested in providing support for this joint government/industry effort, and help major industries shorten their technology adoption process, please respond to the following questionnaire by COB March 24 if your organization is interested in becoming one of the "founding fathers". This is not a statement of commitment, but a means of assessing what industry groups would be best represented. Please indicate your interest areas; _ Am interested in participating in the IC Coalition _ Am interested in seeing validated standards or product profiles _ Am willing to sharing testing, implementation configuration results _ Would be willing to pay a small fee to access an internet based configurator for finding optimal set of "interoperable product suites" _ Am interested in using the IC List server for RFI/RFP notifications _ Am willing to share lessons learned in exchange of accessing all others _ Am interested in some of the more interactive support services provided to its members (_IT architecture support, _technology studies, _tools reports, _RFP development, _technology education) Am interested in participating the upcoming Industry@OOTS (object oriented technology solutions) executive forums where these validated architecture frameworks are outlined by industry (healthcare, finance, government, manufacturing, telecommunications) in the following manner; _ speaking/presenting _ sponsoring _ attending _ chairing _ Please call to set up an onsite brief for our organization. On March 25th, the AFCEA MD chapter will be hosting a breakfast meeting on the Interoperability Clearinghouse and want to know if your organization should be included in the list of potential participants. Afterwards, we will be conducting the IC Work Group meeting. Time and place will be provided to all respondents. For more information on this effort, please visit the following Interoperability Clearinghouse URLs; http://www.omg.org/techprocess/meetings/ic.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://www.gcn.com/gcn/1999/February8/1c.htm With another major article in next months Healthcare Informatics. We look forward to working with you to "making IT happen". Or give a call if you have any questions..... ********************************************* "From Architectures to Reality" John A. Weiler CTO & Founder, The OBJECTive Technology Group Ombudsman, Interoperability Clearinghouse Coalition 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 rem-conf Wed Mar 03 00:31:56 1999 From rem-conf-request@es.net Wed Mar 03 00:31:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10I6yp-0002II-00; Wed, 3 Mar 1999 00:26:11 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10I6yn-0002Ge-00; Wed, 3 Mar 1999 00:26:09 -0800 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA15360; Wed, 3 Mar 1999 00:25:08 -0800 (PST) Date: Wed, 3 Mar 1999 00:24:46 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net Subject: Requesting agenda items for AVT Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin and I are collecting requests for agenda items at the AVT meeting two weeks hence. We have received the following requests already: Jon Crowcroft, RTCP location reports Ross Finlayson, A More Loss-Tolerant RTP Payload Format for MP3 Audio Bill Strahm, RTP MIB draft Katsushi Kobayashi, RTP Payload Format for DV Format Video -- Steve From rem-conf Thu Mar 04 08:29:51 1999 From rem-conf-request@es.net Thu Mar 04 08:29:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Ialw-0001r6-00; Thu, 4 Mar 1999 08:14:52 -0800 Received: from sunblast.eng.usf.edu [131.247.14.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10Ialu-0001qv-00; Thu, 4 Mar 1999 08:14:50 -0800 Received: from localhost (padhye@localhost [127.0.0.1]) by sunblast.eng.usf.edu (8.8.8/8.8.7) with ESMTP id LAA14174 for ; Thu, 4 Mar 1999 11:14:47 -0500 (EST) Date: Thu, 4 Mar 1999 11:14:46 -0500 (EST) From: Chinmay Padhye X-Sender: padhye@sunblast To: rem-conf@es.net Subject: Voice Packet Traces. 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 Computer Science Graduate student at the University Of South Florida. My thesis topic deals with transporting voice over IP. I am looking for trace files for my simulations. I am interested in traces with different sampling rates. i.e sampling at 20ms, 40ms , etc.. I would appreciate it if someone could point me to where I can get these. Your help is appreciated. Yours Truly, Chinmay V. P. University Of South Florida. From rem-conf Thu Mar 04 10:09:27 1999 From rem-conf-request@es.net Thu Mar 04 10:09:27 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10IcT2-0003XN-00; Thu, 4 Mar 1999 10:03:28 -0800 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 10IcT1-0003XD-00; Thu, 4 Mar 1999 10:03:27 -0800 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA37366 for ; Thu, 4 Mar 1999 09:58:59 -0800 Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id ; Thu, 04 Mar 1999 09:58:51 -0800 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id JAA34250; Thu, 4 Mar 1999 09:58:40 -0800 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: Date: Thu, 4 Mar 1999 09:57:05 -0800 To: cabo@tzi.org From: Dave Singer Subject: payload name and type for H263+ (RFC2429) Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RFC 2429 says that "Payload Type (PT): The Payload Type shall specify the H.263+ video payload format." Presumably somewhere the Mime name is defined for this. What is it? (Where is it?). I missed it. Thanks! David Singer Apple Computer/QuickTime From rem-conf Thu Mar 04 17:44:38 1999 From rem-conf-request@es.net Thu Mar 04 17:44:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10IjZm-0007aE-00; Thu, 4 Mar 1999 17:38:54 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10IjZl-0007Yq-00; Thu, 4 Mar 1999 17:38:53 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20767; Thu, 4 Mar 1999 20:37:50 -0500 (EST) Message-Id: <199903050137.UAA20767@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-04.txt Date: Thu, 04 Mar 1999 20:37:49 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, B. Strahm, I. Suconick Filename : draft-ietf-avt-rtp-mib-04.txt Pages : 29 Date : 03-Mar-99 This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net.This memo does not specify a standard for the Internet community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990303160858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990303160858.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 05 00:29:53 1999 From rem-conf-request@es.net Fri Mar 05 00:29:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Iptr-0002mc-00; Fri, 5 Mar 1999 00:24:03 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Iptq-0002mN-00; Fri, 5 Mar 1999 00:24:02 -0800 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA09262; Fri, 5 Mar 1999 00:22:26 -0800 (PST) Date: Fri, 5 Mar 1999 00:22:04 -0800 (Pacific Standard Time) From: Stephen Casner To: Dave Singer cc: cabo@tzi.org, rem-conf@es.net Subject: Re: payload name and type for H263+ (RFC2429) In-Reply-To: Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 4 Mar 1999, Dave Singer wrote: > RFC 2429 says that "Payload Type (PT): The Payload Type shall specify the > H.263+ video payload format." Presumably somewhere the Mime name is > defined for this. What is it? (Where is it?). I missed it. I have made another revision to both the RTP spec and the profile. (See my next message on that topic.) In the profile, I have added "H263-1998", which is the name suggested by Joerg or Carsten, I believe. Also, please note that Philipp Hoschka has done a rough draft on the MIME registration of names from the RTP profile. -- Steve From rem-conf Fri Mar 05 00:39:49 1999 From rem-conf-request@es.net Fri Mar 05 00:39:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Iq57-0003Gt-00; Fri, 5 Mar 1999 00:35:41 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Iq55-0003DI-00; Fri, 5 Mar 1999 00:35:39 -0800 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA09458; Fri, 5 Mar 1999 00:34:38 -0800 (PST) Date: Fri, 5 Mar 1999 00:34:16 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net Subject: Revised RTP spec and profile drafts Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have revised the Real-time Transport Protocol (RTP) specification and the RTP Audio/Video Profile drafts. Both of these may now be ready for working group Last Call -- that is a question I will ask at the IETF meeting. The spec includes the corrections that Jonathan Rosenberg provided to the code in the appendix, and some improvements he suggested in the wording of sections 6.2 and 6.3 which contain most of the new work since RFC 1889. Recall that I had asked everyone to review those sections at the last meeting, and I appreciate Jonathan's careful review. The Profile draft includes the additional payload formats to date, and refers to a separate draft for MIME registration of the encoding / payload format names. You may have noticed the I-D announcement for that separate draft (currently at the rough draft stage) authored by Philipp Hoschka: draft-hoschka-rtp-mime-00.txt I am not sure if the revised RTP drafts are going to be officially posted or not. I submitted the request before the deadline, but I did not notice that the boilerplate text in the .txt version was not updated and so I got a rejection. (I look at the .ps version while editing because it has the changebars.) Henning Schulzrinne created a set of scripts and programs that allow a LaTeX source to generate both the .ps and .txt versions, but I had forgotten that the I-D boilerplate for the .txt version comes from a Tcl script off in another directory rather than from the one in the source used by LaTeX. I am hoping that Cynthia will at least post the .ps versions, or even better, accept the corrected .txt versions I sent. In any case, you can pick up the drafts from ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-rtp-new-03.txt ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-rtp-new-03.ps ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-profile-new-05.txt ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-profile-new-05.ps The .ps versions are recommended because of the changebars. -- Steve From rem-conf Fri Mar 05 08:52:12 1999 From rem-conf-request@es.net Fri Mar 05 08:52:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Ixjn-0006sl-00; Fri, 5 Mar 1999 08:46:11 -0800 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Ixjl-0006sJ-00; Fri, 5 Mar 1999 08:46:10 -0800 Received: from el (Ellery.it.hq.nasa.gov [131.182.119.58]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id LAA26893; Fri, 5 Mar 1999 11:46:02 -0500 (EST) Message-Id: <3.0.32.19990305114353.009aba00@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 05 Mar 1999 11:43:54 -0500 To: mbone@ISI.EDU, rem-conf@es.net, virginia@real.com From: "Ellery D. Coleman" Subject: Live: NASA Medical Surveillance Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If you have a spare minute of two, i'd appreciate if a couple of you could join the NASA Medical Surveillance Discussion for a few minutes and email a sentence or two about the quality of the audio and video you receive. thanks, o-> el Session information: -------------------- Title: NASA Medical Surveillance Discussion Audio: 224.2.193.25:24478 Video: 224.2.193.25:52544 ps. Anyone know exactly how to do something like: Click here to hear a live conversation. ...and have it bring the appropriate mbone util on your system? From rem-conf Fri Mar 05 08:52:13 1999 From rem-conf-request@es.net Fri Mar 05 08:52:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10IxdC-0006pH-00; Fri, 5 Mar 1999 08:39:22 -0800 Received: from boa.crl.mcmaster.ca [130.113.224.130] (todd) by mail1.es.net with esmtp (Exim 1.81 #2) id 10IxdB-0006p7-00; Fri, 5 Mar 1999 08:39:21 -0800 Received: from localhost (todd@localhost) by boa.crl.mcmaster.ca (8.8.7/8.8.7) with ESMTP id LAA20675; Fri, 5 Mar 1999 11:40:32 -0500 X-Authentication-Warning: boa.crl.mcmaster.ca: todd owned process doing -bs Date: Fri, 5 Mar 1999 11:40:32 -0500 (EST) From: Terry Todd X-Sender: todd@boa.crl.mcmaster.ca To: itc@ieee.org, comsoc-chapters@ieee.org, multicomm@cc.bellcore.com, commsoft@cc.bellcore.com, sigmedia@bellcore.com, end2end-interest@isi.edu, tcgn@ieee.org, hipparch@sophia.inria.fr, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, ieeetcpc@listserv.utoronto.ca, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, rem-conf@es.net Subject: ICNP'99 Call for Papers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please pass this along to anyone who might be interested. Note that the ICNP'99 web site is now active. Thanks, Terry Todd ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS 7th INTERNATIONAL CONFERENCE on NETWORK PROTOCOLS The Royal York Hotel, Toronto, Canada October 31 - November 3, 1999 http://boa.crl.mcmaster.ca/~icnp99/ In just 6 years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, implementation, and performance tuning. Protocol functions of interest include (but are not limited to) network access, switching, routing, flow and congestion control, multimedia transport, wireless protocols, network security, Web protocols and applications, electronic commerce, network management, interoperability, and internetworking. ICNP uses a single-track format which provides an intimate setting for discussion and debate. The conference is known for it's high quality papers from the research communities of IEEE COMSOC, IEEE Computer Society, and ACM SIGCOMM. To be considered for acceptance, a submission should present a significant contribution in its topic area. Selected papers will be forwarded for "fast track" consideration to IEEE/ACM Transactions on Networking. ICNP also includes panel sessions in which experts in a specific area offer their observations and opinions about a current topic. ICNP'99 will be held in Toronto, whose name is a Huron Indian word meaning "place of meeting". Toronto is Canada's largest city, the capital of the province of Ontario, and one of the most exciting, vibrant, and progressive cities in the world! It's attractions are far too numerous to list. The United Nations has designated Toronto as the world's "most ethnically-diverse city". It has the world's tallest building, the CN Tower, is the third-largest theatre centre in the English-speaking world, and contains over 5,000 restaurants and eateries. Toronto is also a very safe city with many family attractions. ICNP'99 will be held at the famous Royal York Hotel. The Royal York has been in operation since 1929 and is one of the grand hotels of Canada. It is located in the centre of downtown Toronto, a focal point for shopping, culture and nightlife. Important Dates --------------- Paper Submission Deadline: May 3, 1999 Notification of Acceptance: August 2, 1999 Camera Ready Due: August 25, 1999 Tutorials: October 31, 1999 Conference: November 1-3, 1999 Submission Information ---------------------- Submissions will be made via email. Details of the procedure are given at the ICNP'99 web site: http://boa.crl.mcmaster.ca/~icnp99/ General Chair ------------- Johnny Wong, University of Waterloo jwwong@bcr.uwaterloo.ca Technical Program Chairs ------------------------ Joe Bannister, USC Information Sciences Institute Email: joseph@isi.edu Terry Todd, McMaster University Email: todd@mcmaster.ca Tutorial Chair -------------- Kevin Almeroth, UC Santa Barbara Email: almeroth@cs.ucsb.edu Local Arrangements Chair ------------------------ Bart Domzy, Trent University ICNP Steering Committee ----------------------- Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs Program Committee ----------------- Sudhir Aggarwal, SUNY at Binghamton Kevin Almeroth, UCSB Mostafa Ammar, Georgia Tech Anish Arora, Ohio State Univ. Harmen van As, Vienna Technical Univ. Anindo Banerjea, USC ISI Jose Brustoloni, Bell Labs, Lucent Ken Calvert, Univ. of Kentucky Imrich Chlamtac, Univ. of Texas, Dallas Jorge Cobb, Univ. of Texas, Dallas Jon Crowcroft, University College, London Michael Dahlin, Univ. of Texas, Austin Christophe Diot, Sprint Labs Chris Edmondson-Yurkanan, Univ. of Texas, Austin Mario Gerla, UCLA Li Gong, Sun Microsystems Mohamed Gouda, Univ. of Texas, Austin Mark Handley, AT&T Center for Internet Research at ICSI Teruo Higashino, Osaka Univ. Chao-Ju Jennifer Hou, Ohio State Univ. Allison Mankin, USC ISI-East Ibrahim Matta, Northeastern Univ. Melody Moh, San Jose State Univ. Mart Molle, Univ. of California, Riverside Sanjoy Paul, Bell Labs, Lucent Chunming Qiao, SUNY at Buffalo Luigi Rizzo, Univ. of Pisa Marco Schneider, SBC Technology Resources Gurdip Singh, Kansas State Univ. Martha Steenstrup, BBN David Su, NIST Kenji Suzuki, Kokusai Denshin Denwa Co. Ljiljana Trajkovic, Simon Fraser Univ. Brett Vickers, Rutgers Univ. David Yau, Purdue Univ. Geoffrey Xie, Naval Postgraduate School Ellen Zegura, Georgia Tech Hui Zhang, Carnegie Mellon Univ. ICNP is sponsored by the IEEE Computer Society From rem-conf Fri Mar 05 10:13:24 1999 From rem-conf-request@es.net Fri Mar 05 10:13:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Iyzh-0001BN-00; Fri, 5 Mar 1999 10:06:41 -0800 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Iyzf-0001BD-00; Fri, 5 Mar 1999 10:06:40 -0800 Received: from el (Ellery.it.hq.nasa.gov [131.182.119.58]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id NAA07822; Fri, 5 Mar 1999 13:06:27 -0500 (EST) Message-Id: <3.0.32.19990305130405.009a1770@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 05 Mar 1999 13:04:05 -0500 To: mbone@ISI.EDU, rem-conf@es.net, virginia@real.com From: "Ellery D. Coleman" Subject: RE: Live: NASA Medical Surveillance Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Unfortunately the discussion has come to an end sooner than i had expected. However, this was the first in a series of such discussions and it is expected that each subsequent discussion will be made available to the public via the mbone. (If anyone has a special interest in viewing these sessions, please send a simple email message to me so that i can present your names to the discussion coordinators. This will increase the likelihood that future sessions will be made available via the mbone). Many thanks to those of you who took the time to view the session and respond; i appreciate your help. o-> el From rem-conf Fri Mar 05 11:00:12 1999 From rem-conf-request@es.net Fri Mar 05 11:00:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Izkn-0002GM-00; Fri, 5 Mar 1999 10:55:21 -0800 Received: from alpha.xerox.com [13.1.64.93] (firewall-user) by mail1.es.net with smtp (Exim 1.81 #2) id 10Izkm-0002GC-00; Fri, 5 Mar 1999 10:55:20 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <55651(3)>; Fri, 5 Mar 1999 10:55:16 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177546>; Fri, 5 Mar 1999 10:55:10 -0800 To: "Ellery D. Coleman" cc: mbone@isi.edu, rem-conf@es.net, virginia@real.com Subject: Re: Live: NASA Medical Surveillance Discussion In-reply-to: Your message of "Fri, 05 Mar 99 08:43:54 PST." <3.0.32.19990305114353.009aba00@mail.hq.nasa.gov> Date: Fri, 5 Mar 1999 10:55:04 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <99Mar5.105510pst.177546@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <3.0.32.19990305114353.009aba00@mail.hq.nasa.gov> you write: >ps. Anyone know exactly how to do something like: > >Click here to hear a live >conversation. > >...and have it bring the appropriate mbone util on your system? You want: Click here. i.e. create an SDP description (RFC2327) and encode it using a data: URL (RFC2397). (And then find a launcher that handles application/sdp; there are one or two floating around.) Bill From rem-conf Fri Mar 05 12:29:14 1999 From rem-conf-request@es.net Fri Mar 05 12:29:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J185-0003bp-00; Fri, 5 Mar 1999 12:23:29 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J184-0003bX-00; Fri, 5 Mar 1999 12:23:28 -0800 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA14067; Fri, 5 Mar 1999 12:22:24 -0800 (PST) Date: Fri, 5 Mar 1999 12:25:56 -0800 (Pacific Standard Time) From: Stephen Casner To: Orion Hodson cc: rem-conf@es.net Subject: Re: G726/727 RTP Profile comments In-Reply-To: <2739.920396848@cs.ucl.ac.uk> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Orion, > Quick question on the RTP profile for G726 / G727. As I was editing the RTP profile, I came upon the same question you ask. I also sent a message to Henning to ask if anything had been established. > Looking at the ITU's G726 spec there does not appear to be a bitstream > specified either. An obvious approach for all encodings is pack to > the samples in the order they are produced. It makes the > implementation marginally easier and means the sample time is > monotonically increasing. Isn't this merely a question of big-endian or little-endian bit packing within octets? Note that we have a mix of the two ends across the collection of payload formats because some have come out of the Internet world and some have come out of the telecom world. One could define a consistent set of little-endian bit packings for the other sample sizes as well. People writing code for little-endian machines would find the samples nicely aligned when they picked them up as words. Folks writing on big-endian machines will have to swap bytes first, then pick up samples from the bottom of a word. Nothing unusual, no lack of timestamp monotonicity. -- Steve From rem-conf Fri Mar 05 14:16:11 1999 From rem-conf-request@es.net Fri Mar 05 14:16:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J2oD-00057Y-00; Fri, 5 Mar 1999 14:11:05 -0800 Received: from uumail-relay-blr.ernet.in [202.141.1.17] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10J2oB-00057M-00; Fri, 5 Mar 1999 14:11:04 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with ESMTP id CAA05815 for ; Sat, 6 Mar 1999 02:58:35 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id SAA15145; Thu, 4 Mar 1999 18:48:26 +0530 (GMT+0530) Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA24060; Thu, 4 Mar 99 18:52:02+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9903041322.AA24060@ece.iisc.ernet.in> Subject: codecs To: rem-conf@es.net Date: Thu, 4 Mar 99 18:52:02 GMT+5:30 X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am wondering if it is ever possible for the sender to send the implementation of the software codec he is going to use to the recipients in some portable byte code. This byte code that implements the codec functionality can either be sent on-the-fly or off-line depending on the feasibility. There should be some way of making the application use the codec supplied in the mentioned scenarios, I am not sure how to go about this. If what I am saying can be realised, then the receiver need not have to implement all those varieties of codecs the senders might use for, say, bandwidth efficiency. The sender is now free to choose any codec he has and can expect the receiver to have the same. I think as many sophisticated codecs get developed, it can take lot of time for the deployment on all the receivers before the sender can really use. Of course, the question of, should I send the codec implementions for everything ? should be addressed alongwith perhaps many. Please pardon me if I sound too vague and whimsical :) Regards Anand From rem-conf Fri Mar 05 14:16:11 1999 From rem-conf-request@es.net Fri Mar 05 14:16:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J2oK-00057j-00; Fri, 5 Mar 1999 14:11:12 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J2oJ-00056m-00; Fri, 5 Mar 1999 14:11:11 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24597; Fri, 5 Mar 1999 17:10:02 -0500 (EST) Message-Id: <199903052210.RAA24597@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtpsample-02.txt Date: Fri, 05 Mar 1999 17:09:58 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sampling of the Group Membership in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-02.txt Pages : 10 Date : 04-Mar-99 In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. NOTE: This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the binning algorithm which is a part of the specification. This declaration is being made pursuant to the provisions of IETF IPR Policy , Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtpsample-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304114016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304114016.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 05 14:16:13 1999 From rem-conf-request@es.net Fri Mar 05 14:16:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J2oh-00057w-00; Fri, 5 Mar 1999 14:11:35 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J2oe-00057N-00; Fri, 5 Mar 1999 14:11: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 RAA24707; Fri, 5 Mar 1999 17:10:28 -0500 (EST) Message-Id: <199903052210.RAA24707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-05.txt Date: Fri, 05 Mar 1999 17:10:27 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-new-05.txt Pages : 38 Date : 04-Mar-99 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-new-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304171242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304171242.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 05 14:16:17 1999 From rem-conf-request@es.net Fri Mar 05 14:16:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J2ou-000587-00; Fri, 5 Mar 1999 14:11:48 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J2or-00057O-00; Fri, 5 Mar 1999 14:11:45 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24688; Fri, 5 Mar 1999 17:10:24 -0500 (EST) Message-Id: <199903052210.RAA24688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-03.txt Date: Fri, 05 Mar 1999 17:10:23 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-03.txt Pages : 95 Date : 04-Mar-99 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real- time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-new-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304170808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304170808.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Mar 05 15:06:39 1999 From rem-conf-request@es.net Fri Mar 05 15:06:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J3Yl-0000dw-00; Fri, 5 Mar 1999 14:59:11 -0800 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10J3Yk-0000dm-00; Fri, 5 Mar 1999 14:59:10 -0800 Received: from fix (fix.cdt.luth.se [130.240.64.20]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id XAA17929; Fri, 5 Mar 1999 23:58:46 +0100 (MET) Message-Id: <199903052258.XAA17929@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: anand@ece.iisc.ernet.in (SVR Anand) cc: rem-conf@es.net Subject: Re: codecs In-reply-to: Your message of "Thu, 04 Mar 1999 18:52:02 GMT." <9903041322.AA24060@ece.iisc.ernet.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Mar 1999 23:58:45 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sure, why not? It would be very simple to realize if you solve the usual security problems (or just ignore them :-). On demand downloading of codecs is already done by e.g. RealPlayer. /P From rem-conf Fri Mar 05 16:01:31 1999 From rem-conf-request@es.net Fri Mar 05 16:01:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J4SV-0001e6-00; Fri, 5 Mar 1999 15:56:47 -0800 Received: from f193.hotmail.com (hotmail.com) [207.82.251.82] by mail1.es.net with smtp (Exim 1.81 #2) id 10J4SU-0001dG-00; Fri, 5 Mar 1999 15:56:46 -0800 Received: (qmail 23300 invoked by uid 0); 5 Mar 1999 23:55:45 -0000 Message-ID: <19990305235545.23299.qmail@hotmail.com> Received: from 208.195.157.90 by www.hotmail.com with HTTP; Fri, 05 Mar 1999 15:55:45 PST X-Originating-IP: [208.195.157.90] From: "Neal Schneider" To: anand@ece.iisc.ernet.in, rem-conf@es.net Subject: Re: codecs Date: Fri, 05 Mar 1999 15:55:45 PST Mime-Version: 1.0 Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Hi, > > I am wondering if it is ever possible for the sender to send the >implementation of the software codec he is going to use to the recipients in >some portable byte code. General-purpose DSPs can use a shared memory to support various standard algorithms, loading only those needed to program memory. This approach only requires one set of codecs per DSP farm. If one were to forward a proprietary algorithm, it would have to be ported to whatever DSP the receiver was using, creating dependancy issues. Regards, Neal ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri Mar 05 16:45:50 1999 From rem-conf-request@es.net Fri Mar 05 16:45:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J58a-0002dE-00; Fri, 5 Mar 1999 16:40:16 -0800 Received: from fw1.tek.com [192.65.17.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J58Z-0002d4-00; Fri, 5 Mar 1999 16:40:15 -0800 Received: from fw1.tek.com (root@localhost) by fw1.tek.com with ESMTP id QAA02716 for ; Fri, 5 Mar 1999 16:40:14 -0800 (PST) Received: from icebox.vnd.tek.com (icebox.vnd.tek.com [128.181.120.101]) by fw1.tek.com with ESMTP id QAA02712 for ; Fri, 5 Mar 1999 16:40:14 -0800 (PST) Received: from icebox (localhost [127.0.0.1]) by icebox.vnd.tek.com (8.8.5/8.8.5) with ESMTP id QAA20080; Fri, 5 Mar 1999 16:39:55 -0800 (PST) Message-Id: <199903060039.QAA20080@icebox.vnd.tek.com> To: anand@ece.iisc.ernet.in (SVR Anand) Cc: rem-conf@es.net From: "Ted Brunner 503.627.1317" Reply-to: ted.brunner@tek.com Subject: Re: codecs In-reply-to: Your message of Thu, 04 Mar 1999 18:52:02 +0000. <9903041322.AA24060@ece.iisc.ernet.in> Date: Fri, 05 Mar 1999 16:39:54 -0800 Sender: tedb@vnd.tek.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I am wondering if it is ever possible for the sender to send the > implementation of the software codec he is going to use to the recipients in > some portable byte code. This byte code that implements the codec Netscape plug-in? Ted Brunner VideoTele.com Tektronix MS 50-475 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005 From rem-conf Fri Mar 05 20:29:05 1999 From rem-conf-request@es.net Fri Mar 05 20:29:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10J8a3-0004cR-00; Fri, 5 Mar 1999 20:20:51 -0800 Received: from sgi.sgi.com (sgi.com) [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10J8Zx-0004cH-00; Fri, 5 Mar 1999 20:20:50 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09827; Fri, 5 Mar 1999 20:20:21 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA14427; Fri, 5 Mar 1999 15:20:33 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA28873; Fri, 5 Mar 1999 15:20:26 -0800 From: "Ram Kordale" Message-Id: <9903051520.ZM28871@relic.engr.sgi.com> Date: Fri, 5 Mar 1999 15:20:26 -0800 In-Reply-To: Internet-Drafts@ietf.org "I-D ACTION:draft-ietf-avt-rtp-new-03.txt" (Mar 5, 5:10pm) References: <199903052210.RAA24688@ietf.org> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Internet-Drafts@ietf.org, IETF-Announce:;@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-03.txt Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mar 5, 5:10pm, Internet-Drafts@ietf.org wrote: > Subject: I-D ACTION:draft-ietf-avt-rtp-new-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Working Group of the IETF. > > Title : RTP: A Transport Protocol for Real-Time Applications > Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson > Filename : draft-ietf-avt-rtp-new-03.txt > Pages : 95 > Date : 04-Mar-99 > > This memorandum is a revision of RFC 1889 in preparation > for advancement from Proposed Standard to Draft Standard > status. Readers are encouraged to use the PostScript form > of this draft to see where changes from RFC 1889 are > marked by change bars. > Is there a standard place at the IETF web site where one can find the postscript version (referred to above and in many other ID summaries)? A search at the IETF web site only resulted in ASCII versions. Thanks. Ram -- Ram Kordale Advanced Media Products From rem-conf Sat Mar 06 09:52:25 1999 From rem-conf-request@es.net Sat Mar 06 09:52:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10JL59-0001iY-00; Sat, 6 Mar 1999 09:41:47 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10JL58-0001i8-00; Sat, 6 Mar 1999 09:41:46 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 6 Mar 1999 17:41:21 +0000 To: Ram Kordale cc: Internet-Drafts@ietf.org, rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-03.txt In-reply-to: Your message of "Fri, 05 Mar 1999 15:20:26 PST." <9903051520.ZM28871@relic.engr.sgi.com> Date: Sat, 06 Mar 1999 17:41:19 +0000 Message-ID: <1267.920742079@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Ram Kordale writes: >On Mar 5, 5:10pm, Internet-Drafts@ietf.org wrote: >> Subject: I-D ACTION:draft-ietf-avt-rtp-new-03.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the Audio/Video Transport Working Group of the >IETF. >> >> Title : RTP: A Transport Protocol for Real-Time Applications >> Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson >> Filename : draft-ietf-avt-rtp-new-03.txt >> Pages : 95 >> Date : 04-Mar-99 >> >> This memorandum is a revision of RFC 1889 in preparation >> for advancement from Proposed Standard to Draft Standard >> status. Readers are encouraged to use the PostScript form >> of this draft to see where changes from RFC 1889 are >> marked by change bars. >> > >Is there a standard place at the IETF web site where one can find the >postscript version (referred to above and in many other ID summaries)? > >A search at the IETF web site only resulted in ASCII versions. They normally appear on the AVT charter page, I don't know why this didn't happen this time. Alternatively, see ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-rtp-new-03.txt ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-rtp-new-03.ps ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-profile-new-05.txt ftp://ftp.isi.edu/mbone/avt/draft-ietf-avt-profile-new-05.ps Colin From rem-conf Sat Mar 06 11:55:24 1999 From rem-conf-request@es.net Sat Mar 06 11:55:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10JN5F-000300-00; Sat, 6 Mar 1999 11:50:01 -0800 Received: from uumail-relay-blr.ernet.in [202.141.1.17] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10JN5D-0002ze-00; Sat, 6 Mar 1999 11:50:00 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by uumail-relay-blr.ernet.in (8.9.0/8.9.0) with ESMTP id BAA10678; Sun, 7 Mar 1999 01:06:13 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id KAA29731; Sat, 6 Mar 1999 10:22:40 +0530 (GMT+0530) Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA00920; Sat, 6 Mar 99 10:26:18+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9903060456.AA00920@ece.iisc.ernet.in> Subject: Re: codecs To: peppar@cdt.luth.se (Peter Parnes) Date: Sat, 6 Mar 99 10:26:17 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: <199903052258.XAA17929@basil.cdt.luth.se>; from "Peter Parnes" at Mar 5, 99 11:58 pm X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Peter Parnes Oh! It means what I am saying is not all that fancy. Does this also mean that the RTP payload type management can get somewhat simplified ? The receiver need not necessarily concerned about how to interpret the incoming audio packet payload type for properly playing back! Regards Anand > > Sure, why not? It would be very simple to realize if you solve the usual > security problems (or just ignore them :-). > > On demand downloading of codecs is already done by e.g. RealPlayer. > > /P > > From rem-conf Sun Mar 07 13:04:19 1999 From rem-conf-request@es.net Sun Mar 07 13:04:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10JkWK-0002zu-00; Sun, 7 Mar 1999 12:51:32 -0800 Received: from badlands.nodak.edu [134.129.111.66] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10JkWI-0002zk-00; Sun, 7 Mar 1999 12:51:30 -0800 Received: from lily (lily.ee.ndsu.NoDak.edu [134.129.123.95]) by badlands.NoDak.edu (8.8.8/8.8.8) with SMTP id OAA12822; Sun, 7 Mar 1999 14:16:12 -0600 Message-Id: <3.0.3.32.19990307141834.006c2e1c@badlands.nodak.edu> X-Sender: msyed@badlands.nodak.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 07 Mar 1999 14:18:34 -0600 To: "ISIMADE7@Baden-Baden.Germany":; From: Mahbubur Syed Subject: ISIMADE'99 call for papers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_920859514==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_920859514==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague: Please find attached a call for paper. I am also attching a pdf version of the CFP. Please let me know if you or some one from your organisation would be willing to submit a paper. It will be highly appreciated, if you take the trouble also to circulate among interested faculty and your network. My apologies if you received this email more than once. Best Regards. Thanks. Syed M Rahman ******** CALL FOR PAPERS *********** INTERNATIONAL SYMPOSIUM ON INTELLIGENT MULTIMEDIA AND DISTANCE EDUCATION In Conjunction with The 11th International Conference on Systems Research, Informatics and Cybernetics 2-7 August 1999 in Baden-Baden, Germany ======================================== More Details at URL: http://venus.ee.ndsu.nodak.edu/ee/research/conferences/isimade/ ========================================== Symposium Co-Chairs Dr. Mahbubur Rahman Syed, North Dakota State University, USA Dr. Orlando R. Baiocchi, North Dakota State University, USA Conference Chair Dr. G. E. Lasker I.I.A.S, Scool of Computer Science, University of Windsor, canada ======= IMPORTANT DATES ====== Extended abstract/full paper to symposium chair 25 April 1999 Notification of acceptance 12 May 1999 Receipt of camera-ready papers by the conference chair 1 June 1999 ====== MAIN TOPICS ======= STREAMS: MULTIMEDIA stream and DISTANCE EDUCATION stream. Topics include, but not limited to, following. In Multimedia Stream: - Internet Applications - Applications in visualization, human computer interactions - Applications in virtual environments - Industrial, medical and other applications - Multimedia in electronic commerce applications - Video, audio & image processing and retrieval - Vision and Image Processing - Image data structures and databases - video, audio and image compression techniques - Neural network and AI applications - Next generation applications - Multimedia communications and databases - Multimedia standards - Intelligent multimedia - Document image understanding - Animation - Tools for multimedia production and services - Networked Multimedia - Digital Signal Processing - Distributed Intelligent Systems - Multimedia and Human Computer Interaction - Integration of MM Information - Interactive MM - Hypermedia - Representation of MM Information - Integration of Graphics & Vision - Synchronization of MM Information - MM and Virtual Reality - Education and Applications of MM - Cooperative Information Systems In Distance Education (DE) Stream: - DE delivery, experience and tools development at secondary schools, universities, business and industries and in all academic areas such as computer science, arts, engineering, business, medicine etc. - DE, the Internet and Internet-based visualization - Using computer graphics; visualization for education; video- and Multimedia-based Learning - Cognitive aspects of visual teaching and learning - New Educational paradigms such as interactive classrooms, tele-immersion, networked tele-collaboration and WebTV etc. - Internet-based visualization - Hardware and software tools for educational applications - Instructional Management, student assessment, student support services - Virtual Education environment; Virtual university - concepts and futures - Needs Assessments and Perspectives including National Policies and Regional Programs - Organizational Models of Distance Education Institutions and case studies ====== SUBMISSIONS ======= Submit electronic version (Word, postscript or rtf format) of the original research work, not submitted elsewhere, as an extended abstract (limited to 4 pages) or full paper (not exceeding 15 double-spaced pages) to the following email address: msyed@badlands.nodak.edu Alternatively, submit three copies in hard copy form to the symposium Co-chair at the following address. Dr. Mahbubur Rahman Syed Electrical Engineering Department, EERoom 101 North Dakota State University Fargo, ND 58105, USA Email: msyed@badlands.nodak.edu Phone: (701) 231 7689 Fax: (701) 231 8677 A cover sheet should include address, phone/fax numbers, email address of the corresponding author. All papers must be in English. All submitted papers will be refereed. Authors should indicate, at the time of submission, their preferences to present their papers either in the oral or poster sessions as detailed below. SESSIONS: There will be oral sessions and poster sessions for presentation of papers in the symposium. Authors should indicate their preferred mode of presentation at the time of submission of their papers. The paper review and acceptance process will be same for both type of presentation options and all accepted papers will be published in the proceedings. At least one of the authors must present their paper in the accepted presentation mode. However, poster session authors may arrange for their papers to be presented by a symposium attendee. Authors of accepted papers for the poster presentation must submit their posters along with the camera-ready papers to the conference chair. The authors who can not attend the symposium due to special circumstances must mention at the time of submission and may be considered for poster presentations only. ======================================= --=====================_920859514==_ Content-Type: application/pdf; name="ISIMADE99.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ISIMADE99.pdf" JVBERi0xLjINCiXi48/TDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1hPYmplY3QNCi9TdWJ0eXBlIC9J bWFnZQ0KL05hbWUgL0ltMQ0KL1dpZHRoIDYwMw0KL0hlaWdodCAxNzUNCi9CaXRzUGVyQ29tcG9u ZW50IDgNCi9Db2xvclNwYWNlIDIgMCBSDQovTGVuZ3RoIDYxODMNCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlDQo+Pg0Kc3RyZWFtDQpIieyXbXqrOAyFn8zqsqWErbGPZgkzv7IETwPY1pGOjA2kaVKrMzeA rQ9LL7IJoUuXLl26dOnSpUuXLl26dHk7uU7y6ijeQHqW2mTBqmdtXa7Tf11qJb6Kn8jW8Wv6wCQ9 TzJaH5i2ztZrpaPVYvFog28g1yjiAY7mWcvofHkVmulptoQW8zQ1KL1dheEgDckAIYB84pO/MHmT Lr4v0gjOFqnQhjGUj3wBV0WjpfOaZ+FkJCteRRXHpEAqmKs4TVc3+YMAMBQ51Xpu1jXejWkTKzUM yn9OqtFKP+kaNARa7L1PV/pC2/HQUlW84q2JZK8uvlIhKRYNSxua1D/Jlnkgsci7UhrK15QFU166 AZJHrWh5U2vQqtG1wXW0GiU37XQFo1c5wlKHl0W0im2rAq1UYfQcI4T6qtrW65LAryAsVnRh89PZ EvfL4DIU0m8BLWGCoJUKAxVK3Fahtegwzyao3GcadXXgcFtEK7roaM2iEmjZwuIX0ZoVKFppmqpH HVpxMICrNTz26NrM6PZEjNjV5vdytRAfKBotyIJMzgKG2U/y0ThsRwsbGaCV7wkeQd6i6i5dswwz OytFTTczKql/QjQINg1XM3zVz2VTEIkVFkJOudu1smG/84Rs+AqXganu0lWJCXa2UGIu4mIxiL8j DlpYnuakoEo1WiVbbNpqZHt09aS/RsZuMWiZfWEnWvYw80ZohY7WdpGngfmesLXBqrIY7eABR1wF t9gJzM1obdNV0/7cfrZfVN6PQUvp4EFd+rRHMhKeiYiHfqiusVI3ucuvlE0b7x5323W7dOnSpUuX Ll26dOnCZBiGn/P1Y57A6w+usIuQ4ePZ+tEVdpHy6Wj96ApXZY7l8e90JbFfLlW0cer8f/wnpH+W /5O1eEHGs+X4utl5YD/gcAp3MJbA/DAMZLoKnqVAJof4g2UQSyZbGJ8ejH5kFDkY4SwZMvnLS9NB mfX5no4SREvFK3/kU4nWoiLDH4aUQIrWIHViZhwElf1BDsX5MmqC1gDxCCuDNmiNBRWE+TGhbENr gKDIyqQz6Rzzp9AitZFj3NNhotESJNWgha+uc+/NhxIOasCxr+qko/bKm7L4+NcNZvpfxQXzXC26 LD8DBC2+aqgCNSLzl/8t1oLOMYXeLQYtPVSBlq0C7T5mHGof+FxjX5glERbRSggOxHi+pV0rPZFa qinoyX4GSHV510vBsAkmfwxSvQypRD0dJhot4aAWLdt0QxmtOI6pcef7G6JMO7eQo85opb3DGBSj YC3PG8DfcWhJW0ivXEIRreVqrTbstVeeDhKNFsaJgXvJ0uHT3JH5lWiBPV0bFTVFS2QzjdFgxGhW pJoME450HVqlLBUNYYWsJc+Z7+kwiWiZw1yMQAQi1jjMR6NBnISHQT4Xz0J84+y4TY2eZ+2LigcT tbIgHwkEmHGSgqAfkp9BBoF+WbZkfNItrpisDCIZ9AJlMVUBVG3UM5rDgyRlPdXK1mgCTL0+kM3F QhgsSeqBvpUxmHnGfkAzKVyRlUFPwa4SkkVtPKEOxvI/g/U3lELLFvRqdLpUgZlDsjCDlmhPaYzU Jj1zPR0lCS0ykl0qtFB5zfj6cC5yk36lAMZNxh3NNQ3nvsbQNmc6f4d7ahfRj33nql22olWYA29k ge6dMnDzVWi17hNltOpgrnbo5q8WrSfiVY9WPuJhv19zUIdW8Ap4VNvi4NYpNoVQQquu4lvQ0vmr svBctBrkVwTRpUuXLl26dOnSpUuXPyiXy+XVIXT5TLmEjlaXark8WtHUjkRPuizXl0seWf5Jjy/w eBqITy9EczE8qwcxy8zp8imyQBGxCYkfNZRu8C7fZPDYsPQFlvScLh8jBq3ld+onoR6tUIXWpaP1 d8RDK7ShJbdLD628RXa0/oKkTUqjBYBcOFqXdbQuGq1g0bp0tD5RKADTLxzG8zEJjt5p90yz84ne GraH/IW2TtYniqlqPmu129qk0Ln6ULGFvfgFX6GggZTFSb1Cl3eTeU9iDzegVT3HfDZ26dKlS5cu Xbp06dKlS5cuXQ6S0yKvjqPLh8kpy6tD6fJRcjp1tro8RRJPna0uz5KOVpcokYXERIbjJMfkQ0/t BGgJrZJxFUTJqNFWPj03yk9F7BU+zIjwx7yKUXSg3K8uQt9qt6pUdRWyw/M9CddLtRGaZ3CMEasE yF8IBbR84yYIYlT7xtBKaFl1Zk7EbqsVyivAdega2xSbcIz7lUXoW+bWXW3BkE5CvlWzcU2b0BK+ pFn8kbeFhbjGMQjiwxgFbcc6M+Cb049tscoFd9WK0Xj5LS2CEuK4XbsP/rCuvp19AFr4qxdsb22C VoxjECdiTfx6sbrr5UFoc9pLKSSnXZdqDLokam+RTniqHK5bHZ+XzBNE46XaLcUetLQqiVx5JFpu YaxR0hld2lfQQicmRuct4XnRPqw1tVJWBpjjLcpfHLNl3TqrZQsgdp1fv4BOQMW5HBIfLTqsV+5k W9VrbT1+9lfQokvmMa3k1lqzd77hLWgxb/5jvyLlCvFfMdmrTSGoElpJrGntmmt5xlUQp1M4Gq0c hIkRfnkRT24s1pq9O5m5KSRtkaDmoyXLQdyqB6sLYMv9NLROp+UDxQt/LfvkeQ7CxKiKq4qlnvqV QTW4Y7rJDVogz3Vq1VzfrbVeXABbbkfLsd6KVs4sy85haMnSMb2daMFzWhG+ALbcH0OL2PRccy3P OAZxegJa+dYWlQbh5MevjK2xo6tw0O7WFqe0rNssLD5/AWy5P44WeZxd5xfTarmQQBCnI9BiCeEx CjckSV4lxD1aC9YI6tI1W/f+4vSoMpaFxccWgHZLqfYLqFYlhYVQMr5+S567xmUQudBr6yHZh7ag 0tkWI+aFmTSxNKLl5pcWorgm6SmLV1eWzFPO4Ur1i1Eygbk5tnzJQ2au9bR86xqXQaSpK2gpQzqv 3K0Xo42VVGtlgQ1osTBXDPvDpIoObF4yPbv50nPrLN9FK+Sp1I+PVtK0vsvGj0Yr5EHjSGfDmWaK Q1ZArNkay+Xq8khVG2XQD5hfVkUW/okns2QX4/RmYz6sQO5Uw4MbnI9qaEBldsW4DDRsRov0ah2E idGklReHrYCvOOBdyY/Nr5OrPI5x2VCDFojPJNPYtQFJtEhINJK1oAoDOtJtotSXVSzXrnFbqyOc 7xQXrXLej42iYGybn63R3YU8bNyZOAPLY1etTpT68o6Ya0frWOc7Ba2dUH4qioLbbX6OiG4nWhtD OAitfWk7prjraHE/74HWnih93WeipYw3onU/vQlabIacut87dVtCaxzHWotEuzkod8yfv788Fi12 48X6DmjxGVJ1v3fidg2tB101eB2Yoy5vJqOQJrWv+1erUpd3kHONrBl5kPFNSPprIiXqdrpeL6nW +6E4BKwZrfsX/rXgFbU7XI2iitRaPH9+FRgF81XKtZtV3AxV96rMUdT7ZLi8krQCQevmjbTZKXng 4tsdV2XqJnW5m0R1sAa4fk3nWstiW6ILJLgTmgN0R+qNrEQsmSg7iArnr/Pt+3/5d0t/iY+VpWqB 3vXCzhW2q5Z5YKOldK/MqLBQba/SEiMmNhP6dOZi/lfi5YY2LlzJU1JkTNCxslIrGztXK43PlWLB G+lqhasxND2U+0tJfyIGa30bp7FR9BrNxfwX6XLjGjVX9G9LpbFzVSu10liSsNtCmZkVus5lFsue nIDcY4samXefr5FbktW/Yf3HBc1lL1OjYod7WNfmYQVjiagdXWtKw6ZdcZ/P46VIjOGgBa70XGFS Zit2F+ggZzEiCRhNPFD8eR4h6xzZJPvZclaarqCsyvgTyUK2qjtf6na/ha27YUI2i7uhwM4i4MAE 2G9ucYY2Ol+MtsrfFZ4GR2DgJm05ZNkda5RjZlSfyh9U8xxBNAfvh5CHtj3uF7IlDqfLiTauKRJG Jo+x+vK9l8Uede3iHmbYEg9GMRe6lmZrtWuNPlmPM/jNnpTEN18an1evuJri1Gs/smsptupPXK9g yz3ERJm5SruBrIt9a2Zy7MwvKLZlC2gAa6YbSLJiS5OMIqeMLNtDZGQkNkGVGB/ZocF8Hxzctd6L rZW1P7jC3UC8kxquXB81E+pg+wbuYdJYVhIdJO6HZ70GQZ13FNTr/Q/Joh1LdEoxwgAm57hju9ZG tl5zlqdsjWYcTrKCQYg151fNHO+ywI99R1UQ6iRsmW5DupbI9tK3EC1p2a52tD6ArPSWAFe36EVH qbhK367Om7u7Xm/HlkTL5hnoGs2RdrSzRpxgdw2Dlq3a3ANzB8lomRjHTOgdDRt64BQIIzf5hpBv RrLvWrJShMDXrvqO3EOt1qvZkv5HzGnMd+48CS7FljjPjjBhVPuqqvADAdIQ4NRzm/dQG6P4RoSY 5vsiWWr0Qe/0cfuf+iZJtI3qg9ZmEus4mft3d3XfiC12smUx2d6lopUd5kZn3NO4PuezQ7HpCPLU cwa0VHyxbSFYrPYAHu1L0G/gS9EUSWeSVfH7RdyLll+rKq0d7kOrQhtbd6jx/WbJyR2G2MvjNxx3 oZqV4pen7BlnFiP9RqQrOSNZSx4yPbn3PXqNfa90jWrIut/v+uOnWfZ9Jb66b3k7ItAlziEjNK6l w9yovXlcn2HwoG+guMsTXPpCPNMYz+qL80zO+zODSNZEnjxhjWA/jth9Pk0qvJ9Hys6T/Pa4wgad TWzJHnK7I1tkx8sCp7GbGPfJmjIjaV46jhiF2OwXp1mHmLUM43fKGd6HEUaWdwsPW08ka0xi19F+ 2noa89xtNVv5W0fRJTfFUVZhWQ1wctZ9C78hLVlTDOhPk5f+HjsiFexZZ9XazJdtSoEeJeyRHB5W QHHWu090vfC0tUHst5McFFzND9KTXG38YhP7yqypdiaskf0SUGClGHK3G2GK2hE1JbTrarR4BuLo +ab+8ttEM3hU/UYTl37CPWGnu8Pb97Nty2TfsiXPn/prCms94reU3KEW9a/7F5xdTNfCzUZWTnYt hy1xYiJcLWOy7f3zLZSNJZrHsO5ZqkLP2Q//Z79qs5xnQeg5Wd27aPbRLiH9U5cwbxujAsJV0895 RnI600ZAlOsFyepG9GNMVTFd+FJsUb1XuruR6OEcE1lNXcY0u+g+nk70H55PNkpGPJCxVDW7Q2sB 2DCQZ56+pyNLe9V13Z7LYLogTt+bSyI6C1RHo/QleqqO+SRpK3dOvG8RFXP4/lXvOHrWUENr8f3f B8fuOmWMDudRIaS0I3gvTKYjuUPf08mTEUsLi3D11dqNcdwl64h6Kgfa2xt6Vm81EVrIh4Os7c5z NI1+tw77OueMkbyNHYzpKSvRfG8YQCy2sVMyudq7Q+Ra3L5XtGVjaDXfGiflBh9Xo8laJOZaUxO9 vTmYRnAPRKzlsjfRl2KrRx9i6z52z1DInUvK5RI5YW94QsxyzFIxCJQ012i3fd/Howqz0d7vNivn JcpFMMWbK2KxDznke8TcPs5GZeptJNfUbe7t1/0b8YWLHSwBGAqqGqKdh/WidGgfq4i4wvXoI84O Clq381xyeM8ELbvcNHmOdoPb2zVpJGQVaGXb04685J3bsG6KismeS1oYFu8aGlp55uJTTF3QHMfX PKcHLe6mViCQC8BaxnlPHdoQb5jyc8DGjriBLXxnsrAlkJIysWOipJoy40jWWopKsirjYmRHyBqE zVIqHnGTGG5Gzv3VGhxoKZ9BoK7MzOdcHWgJNwa0QCb8+oIqiez+P1wR4fzOPSQPG2MCKYxXEsvE /ZaVJbFd4rKosRoZ2bulgpBbGch/BWtRrkUZWxmZLmtl1Ja40wiV6pcjjDhcfNbSE0gFyDE+B2B2 eLAi/oyblKkBC9XKNbKOslbhp8DRIeoJ7Twk9CU+NHcEDjrmlSSkQkikxfxX0MrxLAxB+/jehwls tnotHrQFLXTGB1jL7dHey1pD2DJvIqifdFjrlLmmWHHW2qtXqmGsiw/qyEsEFdQt+70geyWWQwat Ekmak8+Q4lnTd+I+9MzJj89aMgKtAJH1FNZ6N7b6u60msixffAOpYq0kIWePMwgxnZq14pSKO/ZX KvP8rspzKupdDS3OWno1y7JIvuxjLfalghY84S4DtPL3uTtiP7ZMZDU6AgWtirWqHEkGYthyWEt3 POmd8sqjXFhIe9fXYK3kn8oQi6lU1IdYy2D8riy1qs4nKyK61wItM9p6fwS0EjfVrCV7rYQjymhD rKV6rRhH9rqKFe3ThXQDKJ41GmrWooKJhY9KhG092BFo9SPk17BWZ7dl3Q7rc1Bhy2It0TvRafFZ a2VsIG6IjHoq1lrKjSFjIiTlZBgWWcMqNOzjG1KWgr0ErROPdr+Vxn/bn/E2HtdDH3lfzVq3DGK8 6AhHdkDvZs7nGrG137Qiy+wnP3ZPC8VLXEi9lOAr9k/aBGazY3gPUiBL17BsmY7BwuKS2CvRr1aX VrwIepVBC5xaO3e4i0cZ+QC0Wlxk6dixAtZKiU2VsOrRF9WBBaLyK2noTvqepZX/YEO5P4/CcBUE azH7jD4yImagSSNL3aUZzgKPYAuTgvR5uB62erQPs1YHtro6rU1RabBNT3k66YyVdzsPpLekOual QKtwEJ2YDYfWKWc+G5Q4+bwM4xlZAvcFW3Jqs0urnclZN2DtTFcUjnbxX85aHZ18X6dleFKbzvKU v2W9JfNAelvpFmgVrJDuq4QN77TYlzzDEm+AtHvb/1F6n+JI49uEBXN3rRpaqihy2aAVMtNlhUHW YsO4kj7KWj/jJv78PSsDkaqVys2lgjfbo/lWohTPSOL3EnukTSS0cNcM96ORy7ZQAwGGV4C8gf7/ E6w1zMd+pMqTglbOuINVhC0XWiom9nuJ3dcmS6GWpYGPOgryR4fzRabVENYHkP4Ya/0MW9SCsWVm 3A70AdYibyaOUgNgcvf4L6Gcm6AaWXItA8jy4I6EzN0buiH2I12fuw8IrvUWa3lxSl219xlbtb81 eoTYCja0xK6TNztDFs4HvtWI0UPQsrAzFBE69wiTn4HW6Dn2T4DU1dBKOfexesPGxcNWMKGl+gl/ 9nJlQ7mqdgKMvom1BnD3faw11LnCEzCK0VrP7uzAnKIiDls01gq7niPJIjvPCCEQPZCZvoG1YLeF uw/tCGm62Gog2dzTlv4BZNEQsvIobeLvieEBV8SBmgeZ6RtYaxBbCFpIsw8FjlY3U8Zn7dXPetRc p8EfG6j6M0fVrGnAnbfFlP4t8HGOfYpQOLu7ijtb7Qhkx2MtfCNq4dnx2qtfurwxZJ02rhrMHHX5 BifNmIZWZ7Rp+SYBteBpFbGXj0y9QdbyQ6x3XGBkf851iQO94jBrdWOrjQ8y7ap4PwcthIlWpQC6 PRXRIPnHsdVdD8ngK9MeImuUtazzZLKPqHf2JB5ev4W1ULeFa4VqYYcrYuMktvfG8gpICyJkf4xO 7RnIAqwl11wawJ45bK/wRtUlP+MmToCriAXf2kiM9a6on18MzSG09NZD+7HoAdv1QgtZEOV+l2r9 C+xCzvUewfrxXgHdFsAWjayon1+GmKjdgTc8i+di1p0GIodZy7SgXBWJ1C3BKYbZsPIKqlCn/Axb +PGNYStKEz8tbDlLVhyK8YIi16otZNk5bHHdaBfvWdx39Kx8Xxq4ioar8jqwJ55cnyd0PYmH2NDp ih7yvRCaQVrKYPAsUNdVtCKQlo5pY/1oRseLv5ib1no93z6n6+V6P74jvpN2tc4+L68SlCG69O6s 8gJQh1dM525dhGaoKZ7L1c1iC1k+6t3ZUZBMuvzuVtdLPh0DZ/g9ArEFz3sftuoMoQVX2p2sNeSz oArlkbIeZxT2fZi1XpFpysylc3X5NLIalQVhq6sijiFrAFvUpXU1mPBy7WGHjQ8ICrQ34nxNqhNz Vfv8cWShbssY7eQm8u0bK+7uobjnc6Meyj6ma88HS5Pv57WstU2xMZZk1C8A1rWJLb/jIt9HGhvq tEwLt+5Q2Uu0j0eY5plS1vPKuQ8R6hsEY8vvuFZQ9yKPWJZt1uJnz9+mL9xIS8rOfHWYL5Jmf0Nm J3xmehFDnJMjtIweuAWtXwKZXqG/jKyefoh0XVyvIvV0qTiZapr+dwDTL9So618m4cn+6KrYxdqH DRZJTyPkzyGmW+K5/bPb008tf5N5HhF6dQf/VHk2aU15odxYa57EKa8Q+i1d1pTfJpOypkyZMmXK lClTpkyZMmXKlClTpkyZMmXKlClTpkyZMmXKFC1hfubnNZ//BwAKasJaDQplbmRzdHJlYW0NCmVu ZG9iag0KNCAwIG9iag0KPDwNCi9MZW5ndGggNDYyNA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+ DQpzdHJlYW0NCkiJ5Fdbc9tWDn73jP8Dnrpkx2LIw3v65FhK150o6VrK7oPTB5qkJTY0qfLi1Pn1 C+AcUpR1sdtpKu9sPKEOz43AB+ADYIGFf9Xi9OTVjzMLFvXpiWXDyBLg4X8/FFClpye3pyem4ZoC hk86hKMggOHz6kechZ/AhF9xxhfwBSwTpnD9iwkJXg4Z4NPxDc8Bz7ENxwERuoYtYCQCQ33vzfen J7+dnrheaAR+GOJlJspkW4YIwMIzAfi+bYT4D+I7FP3yzoJxeXryL5IodPDA4Ely4iEUxXOEIRxw fcswA7zQ6753i997M8eL3gpEY35LEhqmw9+VIyvwjQAlRhkFzO9IR3MDBxNH8/j0ZERDG+ZfTk+0 y9nl9Hw8+UcYvoaL83fv4O2HK/j5/OfJ1Uyf/3p6Mpk/Ia9gYDp5HWMtLULr2jB8qmPCYTV9shLi NOJnd+oZ6womf/3ZjR1u4BjBgRueWl9LgD9yXViGJR5vkJP7Lzi0zsjx+hMq7BFBbdj7iafWTSMI KRzWT2kb8ExhOGB7juHtdL8tp7MC9tcgMGxPep2MP/zrvM5ir7vWZg93+sjXVvrI1co6a/kNLsrR xTLKKn1ka7X+y/ynzun2SOgGLmnSiSgoSjsJbd+nSamEMP3naOAIa7/42kVZ3KZVWsQpSCnXQbFL PiWAkpEl2BBQRrDTRbDVi8Ijx+LDvjDcQQRLHBlDk4P2WhtXBkyj5U1701ZwFS3vdMvXogJmD7pl aWkiYRwhGVm+gyAYlm+HMB9vsYBQF07yNG6qLI5ymBQL3bK1jOxRpGmVyXcY676W6qa2iqoGvxfy S9GoT5F3hdbGp0brbw0/Be9LtLWnNWT9JYwjfeRon/VQK/WRkLM8BbP1mEcpz34sMnq510M5wXfV NOJ53vmAi2fwcXYuhbNCwzIDH4RhO34gYRjAyWh+qPKoSEq4MuBNlJVxvMzY1Gg+00Nr/L9jKNDH 7b0QSo/8MS2rBTsgSQETeBfVn/m96h3SDfwtLK01lpa6bhYvyzKH8hbpAYEKtFXbpBXM4oxCscfL tczwOaZBhe/JAGlVZ80DmwKv/k9WJHVZncFFVERJ9DT3cMoRmGWDP5WghYtHwcV7ME1vcM1GknbX 8ntK/qnuoRHJoXyt0BHbebmicfwMwmShLczb3iBLO86z0rQrmBf35riD6wwWrx/IcftveGq9k4DN 0edI3Ptog+kRm+6/4NA6qSDXD6qwVwS1Ye8nnlo/nC4w9VLSwNLU30oXu+NgGmUFzCm80X/iGrIi ztskPYObtoGibCDPmJayJk2gKV9L73o17zxalrkhYJnrgYPCIyQ7Kk2V76cf380vp5Px5TnyQWhr s/nV5HzaX9qptZaa+MH0OGcK17Y7miGO/iQ8nwn51VuvO2c4tMnkbRqo1R4sw+RVqb2iBmebaS6L JtUDrSro2VBsRThYrfIsxl8aN1lZ1I+F7kXFHOuI7Zzy18jrKua3/c6C57owlXQhShcq6bCOQssi xwnkCKqjfK0lEqYdefZ1sPcMdGxTtCVWX8Lm2ULqZioitdeJx+4TT0dEMSYYy9TQSVyq43DY8rOh mg4JOqPfYjClW1oVxTzmNXle7jgqqBtx8TxUK91FrWytZVQhZewQ5I0NZcHA9ovNUbW08GCn5CVK VyQtqdWQpBmrcQa9vEmvfo7KAPtGAmWzpMVql5dc8+5t4I6iceetru10dNfmDRKaoIrE1xIucCJl VZrJdbkSEyTkqWWR0ViGCI1KOsM39NdUMRdxO9BYw/6icPG6KPZ9hcu/swQD09TKMzQyxXCSlfAd VWpAcDkaz3LJyvsAVhVWIGVMLzxTIy/S/0x3NFXbImbqIEW3luxDqOsGq5TCqcro556p1kWDHBGh jvIURJ16ZSFBwlDYDc4T2LwUjqPw7zl/QZRFYQ0Jeyc9gJlB0RhnD3JeJjyaod1MiYoX1gdvIrUk txzVyYVrbTu53nkmO/pha7IdKUtpvExJTiMDb5m23Jk3r7WGd/I1yyL7rVUHX4obvFd2Ypv2XF/Q VPOF0mBJC5/JP4bW5gxJLgQviNkOqPc7KUC+C72rFzKNub3UL0kVW6Vr++nktSMvtTJv0TLrABE3 irhnLw13ieplhbHdtQ77lK8bVi2hZ5VsSWn5hhPirdiGBcLxBmL+GQEtBxXeFFD0JfFGA+FpeZ4t EDcaFlToNlRXcXmMaY11MXkx4VI42gGv9/dHy1i6kmR6pvx18dowQT5OF22RdGHE6ULSQ3asPNf5 y7luBdLhpdd0kfBsqf7SBhPTkNd1THNqlcoyr9H2cKtbDDjmWHIPQZjbyj0I4IDcwyb3CKiuKJM2 Vg2oLElpvqAdXVhLb99q3BwFS51W99h2eVqcbge0+Ma22Q6V9xQAmGUIhOqzipbkDwfKN/ar0bpK VVjKWMkWWRPlUGcLNAHWqzms6LeiCqGkEYJcZ7x2pGjYRnyc1Vhi37RNjyj2Pnv4qn4gJ6x5la1w 1KxuGoEdPEqFqk0lnuLmtStOlm3PVAUtAtFZ2dPZitRfd7DbMTNkEoYHc0vU9YW7WORbh46zpuqN NEOeZVE96jAVMDGUTCownaJlB/zCjNJteinuqHIlgouURFyQ3SsffMEkcK3980G3Qo2jPdUZW4Q5 Tej9D8j27XzjijxjVaXcnXicRzhLNP8DTrKnU+U45rDl2mOjbCdlAlXYdwurJVfx3LJ8x43cPS1n aC6ao98XpOEMqRZ1JImXpEFZZF8HPUinIbMXP6TZAklqdKInvONZ7slaXVbqZAgTDYC01bQ0lUOV qmYlz5qHvzt+dphjQnVWuNkXouC720NUbNM8L8WpLsiRytVml3vfV+4HPQhIL3ZKrup1mWl5S18F iE5aFNREHQVUC5QuBOEYrm3ZA1Wx8Liczc/fX0zwa6GtTcYfL87nlx/ey9dP2njySZfj2fxqcj59 /RhF/gh/oMdTGHafsL9FveE67qAtmiAGwL1OvgaRcGOUznSsMmjmd1rqMc8UcEXXU6WDKqXBLkCW 8Xxtf2lertZdF9NeV+yjbVTN8qhcsezO6GQuOsgVT5HQmYolZIsywXDz4UuR22KgDBNjk6WKN3nD TcuzRTfJ/t6Lg1rwOCsS3oe1pdzIUs6/Vx5pd4mfBGYxI1QMWSDhJ2SU1eUMRDnnfC5NoziSO9I7 6pp4W4zEAVGVRjXULS/GS3WyhrjkIe9e8VBuaehkWklh65gvSvEi+c04PaOeSKlV8eaaqvizR3o4 fQHjKz1SusHSFtxUyXGaVoO3BV6NiN3wS8vPmuvVwYG6lptQbAfFkrBYcks83IhLkDY8faQKqLek 2fWz4wnBJQFk5KQ1UrgsBtAT28v3tJGm3XCAg3tHN/wS1anafc/2U9aX/sIzX6OmH0tHOGqGNw3h dQzyUYUOEULBhcq+nsTdX8j8sFnDtHQ4YkLaKBY2aZ1ZaTOf/bCbRHaWkvc6e6IgjsJbR0DVIYY9 V4otFY0y2QuuMhOayGjL6CYaVJ88DzkNaZr6lSJDHI5ZxiuFZaosqXZf6BxpAZHgPUmOlCKL/Lip gbfcsuloMSOVyAdRpRyaNPov8dXS2zYOhO8L7H8gsBd5YcumXpZ6WtdWtgUaJ7CTdovmIkt0LMSW BEluNv9+Z4aiHvEr20sOiSk+hsPhx2++QRqCpYmyRBCno7t49CCXpnFZNecdVdpIdw3FYXNUX8+k YHrclKJtH1aKDPEiRRqOZdjM8V8UP/aIaUHmIRPj/A1KPVJ5BQIvxuKumh6SKVJ+4jz6uD6us0QI WNn2ZEWCUMI/xE6aEuLws4/pAHmzRHARwgYwAxFLc2po4jpcAOfpswR7ymes4lIceOoRvcJtsbad mv0rwgsbFqz8g/Mg02jbbYDtFVhzNGpWwhFJKGLfqECkGXfY/Mroo4StyYb+PlhwqoiPuHrun+iF gkd4DqRbAAbccN1FbtfHKnquPP4aI4mnOTa7JMHhVvmVptIinCH7aB5iDvlcBY8a22Ng+aEdV+Lv y/X2QbmqpDPS8F4pQHk0jx6U1Yhu6ntUUqzRf2WfKTP7SPaQflRarK3LXqnGw5XHgtkpGSitZFmK HpdM2ccvmXmUhH3nWNvcrRz+GpOreEYZ1MNsx+qI1NkT16TJQbg64y2bgFFL6yjlnqyLsFpFaU0T BiejeyiaQiVPpPzMGvVDuvOVOlr3ukJWNnPxzrfAXaVu5hVQKPgK+ZQw3gjVznwglqwd5UzVM63q lRbECfZuCeBxpaoSde10dRcBn6WSROqiRxVnuLlQTxIxoV5tRuDpSDQ6THUZ/h0lV89l7f9Yt3JT HxvMsG2dG8weQ2hd8MvRPYPl4vff1pBmPt5h8A0VfEuHnIhlr2zhUvhv0cq7HT0EOAhMoF/co1E3 P7TlfrXDsiIuioYdL7pnunrjnaVbVu3cSB/bCIXmf7XMsNSpAEywyuC66dTLqgkmmHeqCfT/f4yT XzSuHOvMsF1Ld8+5UE04ucWlcXkt6k14uufQrVCDu3Q1fAz3aMpboUG6DfXuuXoo/g6zXxAj+QPs N4J+xRYEZp5SoReH1PVT5HBr1EPfD9o31IzUk6PMirDVJ1mN4xl+Ut8aMm2/6aMVBeC3LMI8pq6S RhtT9JmXuJCte2oT6Wn50GOpMsvQ4WZd/BgnIH2Bh0Dchhv2jM9ADj+BxErlXsV+hQ0yF5elICeZ 2BaC5m9QJuSiD1Ibnh5h1IaIOWO34qTqtVaBVMorQXfEv6jiRCILDEsTEQtWRZkHYZXpBsoUvn93 NFYGTcXDD1A7kUKMwTF5Jyn9WCwLHonRQN5iDHJkYQ7UCxwAJBBkImcP4AZomRIdAYYSAliIKMPT GFx5lOLs1VYMcGWRBSHs0TWLu0kOv3IVvCS2mGkAJEeOzh1ClbYrXkT01yqItkESFXqSRsGTLqK9 /oqyu/C0kDOsypDCZxVM06uiwCbo4LYUeRIAx4rtCxYDElzd6wME5EKwkO6WwBTDSVQiGlim7nFb 5h/ueAc1RxN4ChTbUJoGJRiByewFtaMMc4p753QzECMVIpWzXHjc3MKsZFr8dVmnfVBJ7HVE+WgM 3MY9IlPJny1o2Qpas1xnS4g1u0aMLYLNLoCKYSayIC93AuRXumY+vdg4BPj7CTwDIXJIQH3mz/+G HLIAIfwHH/E+m6d5uWGz4CktA7Ysg1Kwe9AR+LjLlz67CvLHFGbNqvjBlVXp28Tf9snINdvlI7vP 7iHvLOFJT1Rg+Kg6Kly2AwtHh6n/PEwcTwf5yl1DN1zzMDa1A4gUAEWY/oTYiB6IEFZssClK2QDI Q/UUQWqG33C7r58mC6IImKLos4zm4bgYrqXiH2n4khn24QoqKlcQpD4T1EbCrNZD9GVRQduCJzn0 ZmQuok0f0VKAZmhKmuuKC+AFuBTcsWvydoRaFZ18CfDAEdsBahNqCWzlBaNnsMdKtGSregBOizDY xsVGZ8rCcd47YZeoMIZVLaO5WFOQcYaQy/W3JXEOj96xfk1jWCNCAogM54zGkBJw0Ja0n3dQNpQB vI8ZwJxk3tucBcUx/gXJwW2nyfdHFMXZcQqS0xZiRwTBaQuXxpUHdA2nRRE3LXhvZwycG6fQ0fjZ I5x0oZpwcotL411RxHmNI2rZhCbObYReVxUNutSilLj/DwqcOyhtuOYDI8xn/oxNPi5lz2IylY3h 1f2XL+x2cusvmOy5ASZky+/XtzfLzz3uaPfwfc2mNwP8mPYM7dOE+hfwgrhraYbNJlkOjMI9z2sV CJZlS8qFeuZGmqZ1V+DMZ2Vr0hq4mbObKzaZTv1b2TuZT314riN7PNYAGNfBCymBepu7P9H4wp/6 tP4WDMuFaGc6ufYXk4H01ND8yey7POaSffxeHfUTHM2Ho82v/IUPm7FpczbLMD3NGB/ueukBAnpa XPGKKO7co/kCqktIpQ4GrcsSLd37Q7vaQ/YToBUN19NmogQaL+RHUMrf+8WXD2/z0vb0DqM5r5F4 itEsG1W95eimcdzV51bdC/pSWhnpBqTilgStxMWmLLMPw+FPkewLXQgdpNi+0WJDIYZKDg/DNFmD sk1CUQzjIt4FkRjSNvKop5kNDumeYYVzw/I63bOccHL9heF695pP3PYtyGHAxfgMJZ4bhgE5fN73 47vL4ZPmLwz/NwCUZOHhDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9Qcm9jU2V0 IFsvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSV0NCi9Gb250IDw8DQovRjIgNiAwIFINCi9GNCA3 IDAgUg0KL0Y2IDggMCBSDQovRjggOSAwIFINCi9GMTAgMTAgMCBSDQovRjEzIDExIDAgUg0KL1Qy IDEyIDAgUg0KL1Q0IDEzIDAgUg0KL1Q4IDE0IDAgUg0KPj4NCi9YT2JqZWN0IDw8DQovSW0xIDEg MCBSDQo+Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSAxNSAwIFINCj4+DQovQ29sb3JTcGFjZSA8PA0K L0NTMSAyIDAgUg0KPj4NCj4+DQplbmRvYmoNCjIgMCBvYmoNClsvSW5kZXhlZCAvRGV2aWNlUkdC IDI1NSAxNyAwIFJdDQplbmRvYmoNCjE3IDAgb2JqDQo8PA0KL0ZpbHRlciAvQVNDSUk4NURlY29k ZQ0KL0xlbmd0aCA5OTINCj4+DQpzdHJlYW0NCiEhISJMISElTkxKRkVRQ24sVThuITc6MzhpOiRh OW4uNVRoJi5uPUIrUmZwcm4uN2tTJjVfai1ALjRfSG4uOi0+DQomPFFBbVReV01zbi48RCkmQ0Ju WGk6JTxJbi9xYCMrOyIjYitSZ0wtbi90IWMrQWhQTUAuNTpYbjAhOE4rSFooOA0KVF5YKS5uMCNP OStPS1UjaTolbFluMVhrMzBHKl8tK1JoJz1uMVssczBNcTZtQC41amhuMV1DXjBUYmNYVF5YWT4N Cm4xX1pJMFtUO0NpOiZHaW4zQCFDNVMzRU0rUmhXTW4zQjguNVokcjhALjZGI24zRE5uNWBrSiNU Xlk0Tm4zRmVZDQo1Z10hY2k6JyMkSjU/Nzg6XVR1XSZGYEw9bjUoaC46ZEZNSDsiLjpobjUrKW46 azglM09SUSk+bjUtQFk6cilRcw0KZC1zbGluNS9XRD9pXVwoJkZhJ01uNmRzPj9wTzNoOyIuayNu Nmc1KUAiQGBTT1JRWU5uNmlLaUApMjg+ZC10SCQNCm42a2JURHVmQkgmRmFXXW44TClORSdXbzM7 Ii9GM244TkA5RS5JRnNPUlI0Xm44UFckRTU6c15kLXUjNG44UmpzDQpKOk4wIyEuXVRNbjoxTi5K LlY0IytSam44bjozZG5KNUdgY0AuOFxjbjo2JllKPDk4TlReW0s5bjo4PURKQyplOQ0KaTopOWRu O21ZPk86Xm9DK1JrSUhuO29wKU9BUEcuQC45N3NuO3IxaU9IQXNuVF5cJkluO3RIVE9PM0tZaTop aXQNCm49VGROVEZnVWMrUmwkWG49VyY5VE1ZLU5ALjloLm49WT0kVFRKWjlUXlxWWW49W1NkVFs8 MiRpOipFL24/O29eDQpZUnA8LitSbFRobj8+MUlZWWFobkAuOkM+bj9ASDRZYFNAWVReXTFpbj9C XnRZZ0RtRGk6KnU/MFlrS25eXTxsPg0KJkZkSVhuQSRhSV5kLkQpOyIyOC5uQScjNF5qdHBpT1JV JlluQSk5dF5xZkhUZC4iai9uQStQX2NpRVJeJkZlJGgNCm5CYGxZY3A3Kkk7IjJoPm5CYy5EZCIo VzRPUlVWaW5CZUUvZChvLnRkLiNFP25CZ1tPaTotNm8hOlxuWG5ER0dZDQppJVhaWTVrKl0ubkRJ XkRpLEoyREpGTUtZbkRLdS9pMztfL18hcDovbkRONm9pOiwrX25ETmcqbkYtR0luLj4qWQ0KK1Ju a1NuRi9eNG41L1dEQC48WiluRjF0dG48IS8vVF5fSFRuRjQ2X25CZ1tvaTotNyp+Pg0KZW5kc3Ry ZWFtDQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1R5cGUgL0hhbGZ0b25lDQovSGFsZnRvbmVUeXBl IDENCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpDQovRnJlcXVlbmN5IDYwDQovQW5nbGUgNDUNCi9T cG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwNCi9UeXBlIC9FeHRH U3RhdGUNCi9TQSBmYWxzZQ0KL09QIGZhbHNlDQovSFQgL0RlZmF1bHQNCj4+DQplbmRvYmoNCjE5 IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovQXNjZW50IDANCi9DYXBIZWlnaHQg MA0KL0Rlc2NlbnQgMA0KL0ZsYWdzIDQNCi9Gb250QkJveCBbLTMgLTIwMSA4ODkgNzY1XQ0KL0Zv bnROYW1lIC9DR0xNRUsrTVNUVDMxYzM3Nw0KL0l0YWxpY0FuZ2xlIDANCi9TdGVtViAwDQovQ2hh clNldCAoL0c3NS9HM0EvRzQ0L0c2Mi9HMjcvRzQ1L0c0Ri9HNjMvRzZEL0c0Ni9HNTAvRzZFL0c2 NS9HMjAvRzc5L0c2Ri9HNTIvRzY2L0c3MC9HNDkvRzUzL0c1NC9HNjgvRzcyL0cyRC9HNDEvRzY5 L0c3My9HNEMvRzc0L0czOS9HNDMvRzREL0c2MSkNCi9Gb250RmlsZTMgMjAgMCBSDQo+Pg0KZW5k b2JqDQoyMCAwIG9iag0KPDwNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQovTGVuZ3RoIDM3NzgNCi9T dWJ0eXBlIC9UeXBlMUMNCj4+DQpzdHJlYW0NCkiJTFNrUJNXGs4H5MvxQrxA6DZf+n3Y6sjUK9fA Wm0R8BPBpaJyEQEDBggQLgkBQrgGEF0BQa4JBBIuCQmhYMNF44Uq6qgdUdxt647rBZl2tjPrOFu7 PYET2I07/bE/zrzvnPO87znneZ8HY7g4MTAM2xhCRx4Oi9h2+OixY77eqb58/vvdHba9az1q7bt5 LB4PJ5mklhH+n/Pnfw9rWbB4PVSvgy83dPLWGTYyPsEwF9Zq1/VuHh/yqI+3eG3b6e3H/+PeL0IO hEdGRR+PS0gSnE7Pp/n+tG8w7edHB/jQPnzaz5/2O0AH+NIBobRfAO2/mw4IowP8aZ/dND+IDjhA +/vQAQE0fzftF0T7+9L+jsJAmu+odeC96YAgmu9L+4XQfD/aN4j2c+ShdID3//2Dga33ZGxl7GAE YcGMEOdwRiQWhUU7CZyEWAYmdpY4yx2QVuw81osNYmcxLabHzmH1WBOmxvoxA9aANWMdWBfWjQ1h f8YasRasE9NgOuwCdhFrx1RYD9aHDWB1WBvjEweTDCcGk/EhwwsLw5KwRqcTTi+ckPMfnP2dDzoX uQS6zDGjcF/8EIvFagL7wdtVoau6V42vTlo9sUa45u3a/a7erq2u/2RvZC8HspdP2qJ4uDsnyj7P RAI8yjbPZNvJxTabmrPsBU2LXjh7gOdyafExB7mVIpDzMZmzKdH7T19E7Pvsy+0pIGU7AkXoI+Jk QmNzHBXfLGpSNAF4ZYilqdJXjVSByhHrmXvEVWtz52XqcufXWrNhZMgwppvqm1LfankYIzohSZQD eVJ09UEi9kSzKpE6qTqlFQ7FWlJviB8A8YPS52+5Tzuf6B+Sgw/Hbl+7Zr16d2zOAPRzT1XzxPzT cuksNSu9k2aNn4me3G/wAUPeasRAG7l25gznWc1s+TRZNl08LjXKtcVqWRtoLZQ2SQhZ4RllIVWo LCotlsmLynIr0kCFsDYlmZvQnNqRTXZkd0t0cq28v1xfA6r1prNmwmBobDFSxpa+Fk0LuFjfVq8i 61Xnew1ctt1om1zM4aBfbR/BX/EV6PJ7xobraj1s53jMOabtU9yRLO1i2t3wnfA2056G70S3mbZ8 2xMO2marQNvtFUz2wqLZ0UaCwmYhgT6gkAckwmE0PMeFlQ/hl/AD6ElCT0cIewIlxN2bdbVWylpz WTlZMVI1VmYpsciHS/srAIJpLHlXQU+eLk+XrcvQibRCjUAN1CnJLUnE8RPKkiQqqUSQkyJIE4pj pRGg4FDF577cnR17ByLJ/sjhOIvwa+FknlUBSq5aq63ENWtL12VqqutSj7HX3GvUDugGtLqenm5g Rr/geeXZpemKdEVambAysSy5MtXBVsrRs6EEG/bzmHcXFRxEZaP1UciJdKx9/F1H9sXzM3eXgTLv T2u2EPbTDnJsp/B3b2rKf6J+KnuV9SzuTeTTgJlNYGbTENqANnPtbo2cNyUvMudI0VzczTBLvCFG fbQRNBw72LCPqFkJvIi/fFLfeJu603hTM22+d8l60/QIDD/qevGGyy6GOzwcFyxVoLFlV6SyPUNj 9mf2tYuuaIzF9uG5lPBcJjjLzmjENuc4mVt2t+Pv4TKcjcaX1nssW2AnFC0lIhHsXLSgTiRaSYQi nO3JcynyWJG8fzrgoQjbCs62XebhNR521lIujvqWNzDRRRzpFjcwV3LRu/e4YBZ8viyFf1+UMm3B DmFc5zFfLZZyUG0EOoI4iCQRidxRyAFUQCApCn0MPZE7hdygZ4Rj7kourP4WHoFukCIhBd1h6ByU ErAAhoQhErpT0NHgWxSNarh2Tj1nQfmD/D5ZfF86LbZkWdKHUjRAk5rSmkwkCZSKNCpNkZ6TIRCf lsQVR4DiCOU+X+6u1s81UaQmqj/OlDosGM0Zd9jRMlE9SUxNtvaMU+M9o0ajxTQ5cL37Dui+0/r9 z1z2LI/JXrrACasMLzxMyiKzYlMEkvxcqVgmlomK00vTFKkVgmqgPJVQF0OgOLvCDt6z8Ff81XfV ivvUfcVt6XXRjHAy3nQYGA+rg/259o1KzkTVaJGRLDJKtbkdGWpRa1YDaMhKbjhGxNijB/FR8/l6 E2XSN17op3obtc26Nl1bd3tHx0C/ZrBFD1oHm0avcNkwlcf8t4c9Abd72yaZiGuf/N9MbT/jz/9S W3WPulc1I5vO+kY0kTwcC0yx6oN7uAiX7IwLJeNCDxz1F4Ctts2csZrhUj1ZppdqM9UFbfnNuQ69 5aQ3CAi0wb7lN3x6qrF5lBptNqkGtP0aTV/7IOgYbB6Z4LI1NpjHQcyt7Tp/yl+3Rx9sBvC3EdZ3 Ec8TfhQB0Y+vS14SWkND01fUVxcMLdq2wXZdl6YXaHpb9SPcsVJjTj+Z05fRndoe13m8M7rjSEeM Kl6DWJagW/GPQfwjyfw7LqTuQiZcNU/Ow9Vw6xQMJRYWlPLX1IL8b5LHYoD+kck6Zj1o2WMGw58F dQcSmTln6/Kp/DN5ypzygsoiRUkhKCmsLsjnCjuz9TJSL5sueiq/XnG18krVlcprpd/IfxH+EH89 EtyIHAjczEVeR9AaBLxJbwSQdxKKJ9gS2yEPh2/sh+AYz2Xe4ZsIhwdY7JhFJbzCgeWsqNqTtWl1 6XXpyoyK7EqpokQGSmTVuencGFW6oYgsMkwobxEm00XVMDWsGuoZHARov4u0SCYvVhQrJIosRbZC XCmuBtXiFId4vILMs+HUoYeZL//FfdE9a54mzTeujj8wPjB+r1voeN3x387LNqat64zjSuKXs2my qkmOknvpvYmXuNqXNtmytlLVdGrTJA2lXQsJGBZIeH8xtq8xNtgGY2NDIB1gx/b19Qtgm2Ag2OCY xDS8hJfQQJSkeRFt07XqFqZ+6KQVlrJjc8y2S9ZNWqV92fdH+v/P/zzP7znnG/uqDVj5S6orp4NE MP8YfQA/m9eszyKz9CfrslWgGgZ5Yce88zMGMJ89sj3C4Um4pzJ9hVxJj/8c7cI2u9Bf+AJ3cjNx Vwg52t9XTBATFdnBN3GptMUoJaVGqV6mAalFfsAYsATPgdZAsD2Af3UrNH+FHJvv/QpyMJi0CdGx fLT/AEs5tP0g4mSh3XhmrtVVSBbSBT2n+/WZu9BjdsPCtdQ13nT8emSGXV8zS8w9HO5czdn/gLy/ fwSJ0HFMgHKTh6uFL7zoDB4mXwscH8mczJwoWJQuA+my7vG32N+8X4c/JcKffLi0MDn34Z3IJ37g //QR/SW+tNjcwM5Vw5JqSQrQTAG/waV1qz0aTy1TwygZmbPKARzSsq5i/BdHqzJyydyMmpdEGOJe fOl6FpF5/Z7iMR6PdjmGybAjRAeZANPDeN0et5uhaRBHMzyNSWWkmiiDwqQwVxirzLIW0FJd3JaH C95OnqoWojL04tQa4pKIs/o+3Ad/g8H0GSj+Dm4n4LbvoHgOvofD16Dwty/8kXz8/FW0G/0aQz/d 7OJ3ZDsLust95X3yIc2AOqKPmYApdrV1Ao/FOu2Xycv2EXrYHaL7maA7yPS43DQYRVd4MgNlVBlr jFWmQmOJsbi5yAIshXltrAY/qRK2LWvnqy6DaJWk5y382Cl1UQlZUqjOan0TCFKm5J/SuD8RKniN neouuRVY5YpOJX4kr5FSkhRlyD2CmeAAOoe8f9+B1jZ2oD3wHNwzxIfPjvz1wT3i44dwWwTux6ev tbXGyaut0dZLFiC4lMbx7URPErO88bbxc+NE67h52Og39Gl9tU7gVFVbS3CZzGKUkbImqbZSBTZH 0dq/mmGWf2NiLjrLNsPcTeY2DnkrpW/cJBffGBShZzHBpjih3sm6gHCN54CHhCkuvJjg8gTJX6Zx p3cmFvhz7dfaokRb1DJkDBqDOq+GlVNvyVGUxcDOvEGuk6q35J6wxbPfF5svbRXrveqtYpm1FJcp zI1yUtFA6an6p962BNEzrLXZ6BRrbeoGcwu/d1NbdZ2crozl9qffXbo1cTMMwh8tehfZKEw6dkVo I8qByqGywBmPBHgktvRXsE05//9K5j/q/zsYfRonnlgQoowcJH5uL7FXjESn0Ns4SkeimXUxKV7P gWKYgcF3pqF4dZ1YX4WiGZiOw3QoOrl3lVzdO43EKANDG23COy3zTXGiKa4f0fRrQqpuivVFVVsr cam8xUiRSqOqXq3QULoyQz4wnLa8fww7as10niWcZ90VPqWPCtSFDMAQGrKE2fehlR4gB+iAzxvs DXkijhhwxrrmH2ICRxrnbmJZiI6fRvsOPmXEgS1G7PovRoBUOdsW3H+wp/8R/weM+DZ73wPywc9G 0B50FENJsxBu035eOUVMVmT3HfkBqZb4vuZei58llb+/fRD/w63++bF/k0qQ2r0BksNCGdv+dZ0U u16V8t9V46UlFmMRWdhU3FjaADbN39/Br/gext8d8of8F30Bps896BpmwwkPWQdpup3BmXZXu7Md CJAqIZMKX37V7nudfN33Tm9eEMDJAb63sbuhV9+rG9RFdZd0o41jTaBpLN4ygU9etXmi5Ki7OxjG Lpq6tQyhdVW4JDRlrbAVXSi8UGaXOg71vxXLnwUFs7X3V7Ap+logTgTiw7HxSDw813+nB/TcXnZ8 iX/+sFl3m7yjm68frwVoVM432OtoykN5lC4lLXNVOsvs4EJZaVcJLjlj0paT5fValRyjLmh8DYRX H2240TDYHDFHzZfNUVPE8AW1WDwmAVckvcdfxk41SmryCGVeeVF+VV5ZpuJEHdCcOGw6iAtShxML tUIk2jfw0QnyxELVnyGGJfwIYzmBwWU2tmW4wvJjJSXiF52v+EBGVFspu4pw1Hjqg+yrNxCxjOO+ vs6nP4leG20Dg+g8r8RY1HyWZdiZ7LYMfGtq7Ozcw2d47+ZkFksoQOW823gURzsORe5nkBn3petQ hCXl8AnLj/c+yOsoIzpKbVJa6ajxav1sN/qHLDG8b8BKszSnhzyhXpAchWt8wXNpHGYDClNLaRvb uKkf8+CrifTU8xtfcBPbedCwmQUVySyuAHXAjjTgOs9L42wI/wm/EIJTDQplbmRzdHJlYW0NCmVu ZG9iag0KMjEgMCBvYmoNCjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3INCi9Bc2NlbnQgNzMyDQov Q2FwSGVpZ2h0IDY4MQ0KL0Rlc2NlbnQgLTIxMw0KL0ZsYWdzIDI2MjE3OA0KL0ZvbnRCQm94IFst MTk0IC0yNTAgMTM0NiA5MzRdDQovRm9udE5hbWUgL0Jvb2ttYW4tRGVtaQ0KL0l0YWxpY0FuZ2xl IDANCi9TdGVtViAxNjcNCi9YSGVpZ2h0IDUwMg0KPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8DQov UHJvY1NldCBbL1BERiAvSW1hZ2VCIF0NCj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0KL05hbWUg L1QyDQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUzDQovUmVzb3VyY2VzIDIyIDAgUg0KL0Zv bnRCQm94IFswIC0xNSA2MSA1N10NCi9Gb250TWF0cml4IFswLjAxMzMzIDAgMCAwLjAxMzMzIDAg MF0NCi9GaXJzdENoYXIgNDANCi9MYXN0Q2hhciA4NQ0KL0VuY29kaW5nIDIzIDAgUg0KL0NoYXJQ cm9jcyAyNCAwIFINCi9XaWR0aHMgWzM0IDM0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAN CjAgMCAyNyAwIDAgMCAwIDAgMCA1MSAwIDUwIDU3IDQ2IDAgMCANCjAgMzYgMCAwIDQzIDY3IDU4 IDU4IDAgMCA1NCA0OCA0NiA1NSBdDQo+Pg0KZW5kb2JqDQoyMyAwIG9iag0KPDwNCi9UeXBlIC9F bmNvZGluZw0KL0RpZmZlcmVuY2VzIFs0MC9HMjggL0cyOSA1OC9HM0EgNjUvRzQxIDY3L0c0MyAv RzQ0IC9HNDUgNzMvRzQ5IDc2L0c0QyAvRzREIC9HNEUgL0c0RiA4Mi9HNTIgL0c1MyAvRzU0IC9H NTUgXQ0KPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8DQovRzI4IDI1IDAgUg0KL0cyOSAyNiAwIFIN Ci9HM0EgMjcgMCBSDQovRzQxIDI4IDAgUg0KL0c0MyAyOSAwIFINCi9HNDQgMzAgMCBSDQovRzQ1 IDMxIDAgUg0KL0c0OSAzMiAwIFINCi9HNEMgMzMgMCBSDQovRzREIDM0IDAgUg0KL0c0RSAzNSAw IFINCi9HNEYgMzYgMCBSDQovRzUyIDM3IDAgUg0KL0c1MyAzOCAwIFINCi9HNTQgMzkgMCBSDQov RzU1IDQwIDAgUg0KPj4NCmVuZG9iag0KMjUgMCBvYmoNCjw8DQovTGVuZ3RoIDE5OA0KL0ZpbHRl ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJnJA9CsJAEIVXUgQWhhwhcwHJP1sKUcEUglYe QC0tFK2To+UoOULKFJJxZs0iYmfxMbDz3s6byXKMMcd5UmCWYGHwlIC+gk4Nv8do0ql5vIAuK9DR AVPDZcMtLuVuiWyIqi3eb48z6GqFNKiQesuCOlVTq4iaGeMRKZ9GS0BPlggDy4SepULHcgtbWof3 Rr5o/G+UEPyJ//tf433mufmSxeVyOV1ut4fsNKopkA0qZmuq7S16u2wIes2H3IN+CTAAo8+5uQ0K ZW5kc3RyZWFtDQplbmRvYmoNCjI2IDAgb2JqDQo8PA0KL0xlbmd0aCAxOTcNCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiZzQOwrCQBAG4AkWwsLiETIXkLwMWwpRwRSCVh5ALS0U rZOj5Sg5QsoUwXFmN4loafGxsMPOzvzJAkNMcB6lmISYGjxHWt20ig3fh2jivni6apXlWgVHjA0f Wy7xke1XyA+CfIeP+/OiVb5GmBCBR1SyCohqKKiBJbWsA5/N6MUIpk45cSrPqcFprMJqR9Lkl88N /+MG+u7XWu6/ZvSZa5hzmLvfQ3bqLN+2kJ1ld8lAspBMJButNhzkQau3AAMASGW25g0KZW5kc3Ry ZWFtDQplbmRvYmoNCjI3IDAgb2JqDQo8PA0KL0xlbmd0aCA5MQ0KL0ZpbHRlciAvRmxhdGVEZWNv ZGUNCj4+DQpzdHJlYW0NCkiJMjJXMFAAYSMDBRNDhRRDXq5CXi5DY6AIWAAklZzLy+XkyculH65g aAykPIASQMopwFkBRHv6KpQUlabycnm6KDCw44b/cQJ8uni5XIFWB/JyAQQYAKO2KmwNCmVuZHN0 cmVhbQ0KZW5kb2JqDQoyOCAwIG9iag0KPDwNCi9MZW5ndGggMjAwDQovRmlsdGVyIC9GbGF0ZURl Y29kZQ0KPj4NCnN0cmVhbQ0KSIlk0T0OgkAQBeBHKEg22XAE9gZKsTUENZHCRCsPoJYWGq3haByF I1BSEHEe/vCX3eTbnZ3iTdaGZtktGxprzTnU6qaV/VSlQE5XrZJUq8VRuoStPAjJfmV4TXfmcX9e tErXpm0LZG37J0c0BwhmvAB/RgN4M2rAHRKTCrEzpCQlSgxwKlII2YCa5G7NaGPgNYw24gVfdg8Y tCHehJq4EyriTCglQYEeJuaJlR8Oh8ryjuiHy/EjdARftNrITx20egswAMBB2jcNCmVuZHN0cmVh bQ0KZW5kb2JqDQoyOSAwIG9iag0KPDwNCi9MZW5ndGggMjI5DQovRmlsdGVyIC9GbGF0ZURlY29k ZQ0KPj4NCnN0cmVhbQ0KSImkkD0KwkAQhSekEBYWj5C5gPhDEu0Ef8AUglYeQC0tFK0NeLGAFxG8 wIKNRcj4djei2Np8A/tmZ968pMMd7nGry/GAk5Q3Xa32WsUpWyHpe22902qUadVecZyizKCgjBZj Rn87m/PxcNpqlU1Y5ElDEckpEKmI6IwHoqbcwFAKx9yRLCvH0hGN5zw0kAzYkDK84WMFRiKXws69 Fhgo94Kw4pFbSs3gQ/IM/2bwO7nmZ+/j7cd68z69Z+/fYISp7yq/LvVX+wTqTGw+DTFgJKXLDRus DZunVlPEv9TqJcAALITFsw0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PA0KL0xlbmd0 aCAxOTcNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTI1VzBQMANiU1MQSjHk 5Srk5TKxBIqAxUBSybm8XE6evFz64QomlkDKAygBpJwCnBWAyvU9fRVKikpTebk8XRQYGBjs//// D6QYIRSIC6L4IRQzhGKEUAxQqh5C2UMo+f9AZSAdQOoBAzuI+gCh/oAkmP//g1D/gcYgUQ1QigFM HcBGPWCopx6F1Qao7Q2MmA6Euhrqhx8QHz2AeBPsW6jfkUKiHjmUoGHGjhKe9shhDQp5Xi5XYEwF 8nIBBBgAGR2qQg0KZW5kc3RyZWFtDQplbmRvYmoNCjMxIDAgb2JqDQo8PA0KL0xlbmd0aCAxMDgN Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTIxUzBQAGETIwVTU4UUQ16uQl4u Y5CIAUgAxEjO5eVy8uTl0g9XMDYDUh5ACSDlFOCsAFSu7+mrUFJUmsrL5emiwAAE/KQRzP///yeN AAJ70gjS7cBnOWke5OVyBYZdIC8XQIABAAskXoANCmVuZHN0cmVhbQ0KZW5kb2JqDQozMiAwIG9i ag0KPDwNCi9MZW5ndGggOTgNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTI2 UzBQMAZhYwVTU4UUQ16uQl4uYwMFEAQKgKSSc3m5nDx5ufTDFYwNgJQHUAJIOQU4KwCV63v6KpQU labycnm6KDAwMDATg/8D0WDBxLqZl8sVGAiBvFwAAQYAJ0dWKg0KZW5kc3RyZWFtDQplbmRvYmoN CjMzIDAgb2JqDQo8PA0KL0xlbmd0aCA5Nw0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJl YW0NCkiJMjFWMFAwA2ITIwVTU4UUQ16uQl4uY5CIAUgAxEjO5eVy8uTl0g9XMDYDUh5ACSDlFOCs AFSu7+mrUFJUmsrL5emiwMD8////YU0AAT9JBC+XKzDsAnm5AAIMAM2Wl3ENCmVuZHN0cmVhbQ0K ZW5kb2JqDQozNCAwIG9iag0KPDwNCi9MZW5ndGggMTgzDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0K Pj4NCnN0cmVhbQ0KSIm00UEKglAQANARI+HDx27g3EBbaO0EK8hFUKsOUC1bFAUtAj2aR/EILl2I vxnN+B/XMTO8YWZ2Ey0wwIhrjmGI57kUNymoCygIXp2uUiSpFP6RJsS2J9mvkM79dIeP+/MiRbpG AKVasJiGyQZqJjbwVGVQMu5AwTgGtsoNgLG+tB2gM4E35D+m8LI6lj0B48DM1sgpRxTgapTgjakg 1qgh02hAjVHqT0ixoU8dpPgIMACjqIGDDQplbmRzdHJlYW0NCmVuZG9iag0KMzUgMCBvYmoNCjw8 DQovTGVuZ3RoIDE3Ng0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJTNAxDoJQ DAbgRzCSNHnhCPQGoOERNxLURAYTnTyAODpodIajcRSOwMhAwD6B5B/6tWk7NDU7jjiRMFs2houN ppem2HYi27DF/akpyzWFN44TSScZSMoue5b1MD/z5/19aMoPrFQ5Vq5SKRiAPuiBLuiACi3BVFzN BuJ61he9Wc9aTbrWetKxNpPK2v7t5IDFHhzAEa3AGmzAFuzAHhzAcVHTUV5+1fQTYAAyGF5WDQpl bmRzdHJlYW0NCmVuZG9iag0KMzYgMCBvYmoNCjw8DQovTGVuZ3RoIDIyOQ0KL0ZpbHRlciAvRmxh dGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJtJGxCsIwEIavOAiB0EfwXkDaSqNuhapgB0EnH0AdHRSd 20fro/QROnYQz7/1HCquhiQfJJf77/64OYc84XHEbtrOY2TNxRoX4zhkN3vfHc7WpJk1wZ5dDKxx A6TbBSM+yDZ8u95P1mRLFmkoF4yChtgfRATUQCJSASOREvBFsNNAni28LhChioY8nOc1chSU1Igu KanwFqtCpppGJWQa8ktqRT4oOgwLT5D3C9CC5uAf+KmntfQL1Kq1B+1I+9NuGyK4kPcNUZfUs4+D 6qe6q16r8+9/sGaFf9tZ8xJgAPyJw4UNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNyAwIG9iag0KPDwN Ci9MZW5ndGggMjEyDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSImM0cEKgkAQ BuCVPQgLi4/gvIEGrVfBCvIQ1KkHqI4dijqvj+aj+AgeO0jbzI6WewuRD3bWf2bQLCGHAl9TgDFw Xmh108rkQA8eUOl01aqqtcqOYHJkiwWk2q8Ar2f1Dh7350Wreg1CiNg5hwjLpEzCSCYKECP2i3Qj rSiJLqD/m45TuinM01A/+Z7aRsFkI3EwfMm4APuryc7flP0EbStfPkUOPhP7RTOc706zzNds8Xs/ bso7JATFeCQxMBTDs45YohGlVhv8UwetPgIMAH4zph0NCmVuZHN0cmVhbQ0KZW5kb2JqDQozOCAw IG9iag0KPDwNCi9MZW5ndGggMjQ2DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0K SIlE0D1uwzAMBWAaHQIIEHIE8gJBElT52QSkLVAPBdqpB2g7ZkjQztbRchQfIaOGwCz57KLLJ1iU yCenvazkXhZrSTvZbOVzHcMphpRseyWb3Vj7OMZwaGNYvktKtjxbxZbD64PY+WX7It/nn68Y2kdR LXeqWolYtSdqbIOI8kDuDVZ4hT28THKlXKhT0y722a/XTNZxgDqqkw2kUYa+VfBR/oer9597HLvo NorpijzdmG066mVGwXpc/JoO0D7cK6zwRvMMGc6gRya2R7hs/djGFcqEKbCDSkhCSOXOkJORrft7 TPUcMTzZ73+L4VeAAQA1AZrdDQplbmRzdHJlYW0NCmVuZG9iag0KMzkgMCBvYmoNCjw8DQovTGVu Z3RoIDkzDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyMVMwAEMTMwVTU4UU Q16uQl4uE4goUABEJefycjl58nLphwNVASkPoASQcgpwVgAq1/f0VSgpKk3l5fJ0UWAAAWbyyP// QXiUhJC8XK7AIA/k5QIIMABWh8PJDQplbmRzdHJlYW0NCmVuZG9iag0KNDAgMCBvYmoNCjw8DQov TGVuZ3RoIDE2MA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJ5JAxCsJAEEVH UiwMDB4hcwGJgaytEBXcQtDKA6ilhaJ1crQ9ikdImUIy/jV4Cofhffh/fjPe61y9zkr1UK/nUvgm XCUbxmLMTlfhOggXR608ZIsEUu9Xivsi7PRxf16Ew1ops4HcH3Fib3Jt4rQl63+M1HSUx+++CLMc 2SU2fSIqhPoAZmagM4tEuRmOGoMFQ3iDxx+EPwIMAKB4hOkNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0 MSAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9JbWFnZUIgXQ0KPj4NCmVuZG9iag0KMTMgMCBv YmoNCjw8DQovTmFtZSAvVDQNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTMNCi9SZXNvdXJj ZXMgNDEgMCBSDQovRm9udEJCb3ggWzMgOCAzMCAzNV0NCi9Gb250TWF0cml4IFswLjAxMzMzIDAg MCAwLjAxMzMzIDAgMF0NCi9GaXJzdENoYXIgMTgzDQovTGFzdENoYXIgMTgzDQovRW5jb2Rpbmcg NDIgMCBSDQovQ2hhclByb2NzIDQzIDAgUg0KL1dpZHRocyBbMzQgXQ0KPj4NCmVuZG9iag0KNDIg MCBvYmoNCjw8DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbMTgzL0dCNyBdDQo+Pg0K ZW5kb2JqDQo0MyAwIG9iag0KPDwNCi9HQjcgNDQgMCBSDQo+Pg0KZW5kb2JqDQo0NCAwIG9iag0K PDwNCi9MZW5ndGggMTM1DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyNlEw UDBWsFAwBlKmCimGvFyFvFxG5kBRAwUgBZJKzuXlcvLk5dIPB4oAKQ8I5RTgrABUru/pq1BSVJrK y+XpovD/QP3/fwz8//8wsP//wMD4/wEDAxgfYGCob2BgsIdhBgYGeVwYWR1IH8wMkHkgc0Hmg+zh 5XIFOiqQlwsgwABQlzGhDQplbmRzdHJlYW0NCmVuZG9iag0KNDUgMCBvYmoNCjw8DQovUHJvY1Nl dCBbL1BERiAvSW1hZ2VCIF0NCj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PA0KL05hbWUgL1Q4DQov VHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUzDQovUmVzb3VyY2VzIDQ1IDAgUg0KL0ZvbnRCQm94 IFsxIC0xIDYyIDYzXQ0KL0ZvbnRNYXRyaXggWzAuMDEyMDUgMCAwIDAuMDEyMDUgMCAwXQ0KL0Zp cnN0Q2hhciA1OA0KL0xhc3RDaGFyIDExNw0KL0VuY29kaW5nIDQ2IDAgUg0KL0NoYXJQcm9jcyA0 NyAwIFINCi9XaWR0aHMgWzMwIDAgMCAwIDAgMCAwIDAgMCAwIDYzIDAgNDggMCAwIDAgDQowIDAg NDggMCAwIDAgMCAwIDYwIDAgMCA2MSAwIDAgMCAwIA0KMCAwIDAgMCAwIDAgMCA1MCAwIDAgMCA0 OSAwIDAgNTMgMjUgDQowIDAgMjUgMCAwIDAgMCAwIDM2IDQzIDM0IDUzIF0NCj4+DQplbmRvYmoN CjQ2IDAgb2JqDQo8PA0KL1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWzU4L0czQSA2OC9H NDQgNzAvRzQ2IDc2L0c0QyA4Mi9HNTIgODUvRzU1IDk3L0c2MSAxMDEvRzY1IDEwNC9HNjggL0c2 OSANCjEwOC9HNkMgMTE0L0c3MiAvRzczIC9HNzQgL0c3NSBdDQo+Pg0KZW5kb2JqDQo0NyAwIG9i ag0KPDwNCi9HM0EgNDggMCBSDQovRzQ0IDQ5IDAgUg0KL0c0NiA1MCAwIFINCi9HNEMgNTEgMCBS DQovRzUyIDUyIDAgUg0KL0c1NSA1MyAwIFINCi9HNjEgNTQgMCBSDQovRzY1IDU1IDAgUg0KL0c2 OCA1NiAwIFINCi9HNjkgNTcgMCBSDQovRzZDIDU4IDAgUg0KL0c3MiA1OSAwIFINCi9HNzMgNjAg MCBSDQovRzc0IDYxIDAgUg0KL0c3NSA2MiAwIFINCj4+DQplbmRvYmoNCjQ4IDAgb2JqDQo8PA0K L0xlbmd0aCA5NQ0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjZQMFCwAGIj IwUTM4UUQ16uQl4uQxMFkDhQACSVnMvL5eTJy6UfrmBoAqQ8gBJAyinAWQGoXN/TV6GkqDSVl8vT RYGBGT/8jwcQ0svL5Qp0RCAvF0CAAQAckCwVDQplbmRzdHJlYW0NCmVuZG9iag0KNDkgMCBvYmoN Cjw8DQovTGVuZ3RoIDIwMA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJrNEx DoIwFAbgRxiaNGl6BHoDNAIrCWoig4lOHkAdHTQ649E4ikdgZCDiK39JSnQ0oflIS0vf/7KFmZnM juE5zZW8KpkmPIM55nhRsiiVjA8mTZgNLzDFbmn487jcmvvtcVayXBki0n3fM5QDAQJAFciBBgKE IADU81sNWt7IdLwRJw08KbLU4EXaoxkRlvYXHYV/5+ePmhH9fU93eVcKCnujWlf0EIGXSzAJy0UX TWKt/MiF3w7bHCXX3My9kh8BBgBglZ4yDQplbmRzdHJlYW0NCmVuZG9iag0KNTAgMCBvYmoNCjw8 DQovTGVuZ3RoIDEwMw0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMrFQMFAw A2ITMwUzA4UUQ16uQl4uEwMFEDSDSCXn8nI5efJy6YcrmBgAKQ+gBJByCnBWACrX9/RVKCkqTeXl 8nRRYCATMP7//59cAgiYySAosZIqBC+XKzBQA3m5AAIMAK4NgaMNCmVuZHN0cmVhbQ0KZW5kb2Jq DQo1MSAwIG9iag0KPDwNCi9MZW5ndGggOTgNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3Ry ZWFtDQpIiTKxUDBQMANiE3MFMwOFFENerkJeLhNDoIgBSAAklZzLy+XkyculH65gApTX9wBKACmn AGcFENfTV6GkqDSVl8vTRYGB8T8QjJIESBCop4Tk5XIFRkggLxdAgAEAVr/Ysw0KZW5kc3RyZWFt DQplbmRvYmoNCjUyIDAgb2JqDQo8PA0KL0xlbmd0aCAyMTkNCi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl DQo+Pg0Kc3RyZWFtDQpIiZTRsQ6CMBAG4DYMTZo0fQTuDagmsJKgJjKY6OQDqKODRmd9NB+FR2Bk INQ7rhg6Smg+Usp/d6Fw4KCgtYTCwXlh9M3onHYcbdDD6Wp0VRudHSEvkC2+QKr9CvB4Vu/gcX9e jK7XIPDy3hOWkYwIlEzK2AjFJD+k/zAtLrz7iOFfeg4LdExDZaV/T9Vt1GBo9zWfIUykojFttJkg sh9PIvSdHBg/hlG9kkl5TMu9WJ5WzRrspuYFjzJCMUxJYAyBMUQzoYhWJATGEBhj9AZ/5sHorwAD ADeZoLANCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MyAwIG9iag0KPDwNCi9MZW5ndGggMTc1DQovRmls dGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIns0TEOwjAMBVBXHSpZsjhCfAHUZkjWSgUk OiDBxAGAkYEK5vZoPUqP0LEDwtjAwMgBiBQ/KT+xh0TPBQeeew6RY8FHT3ghDHZccPTv7HAmrGrC fM9BL+RrTZRqu2Cz3vC1uZ0I6yVDIjKC+/MTIDKA616UHbTSf1GK7h6cALQ9pJMygC35MFpNZDJS uRuZPIyZiOFEO+kzG2YjLcwUbaCFcKV/uiN8CjAAE5/GBw0KZW5kc3RyZWFtDQplbmRvYmoNCjU0 IDAgb2JqDQo8PA0KL0xlbmd0aCAyMTENCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFt DQpIiXzQvQoCMQwH8BwOQqG4ujUvIKdexdsO/ABvEHTyAdTRQVFwq4/WR7lH0O0GaU0iJ+Lg8uuQ NPmTUR/7OMTeAO0I7Rh3A62OWtkMuWDzd2170GpSapVu0Gb0LKhCz2Q1RepPyyWeT5e9VuUMYw2d GAMAuHgnjdgWW2Iiwlv3ZXFvB9ZFD+YRqcHExvrXwKODLKhEnmCCWIsy01Sib6S/NyhEnkNh2NZf OTBbkeCA/8JH/2XV7O1KhhzME+DK2RLO7OkwUas5HXKt1UuAAQAfYHI3DQplbmRzdHJlYW0NCmVu ZG9iag0KNTUgMCBvYmoNCjw8DQovTGVuZ3RoIDIxNQ0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+ DQpzdHJlYW0NCkiJnJA9CgIxEIVnsVgIhBzBuYD4Q0StFlYFtxC08gBqaaFovTlabuAV9ggpt1gc Z7Iqgp0hfDPMmyRvYmc4wBH2hmgnsg9Drc5a2TGXB2inrbY/aZUXWvV3aMccVqxwyDdz5P5+scbr 5XbUqlggke8QUQNQEgUAwwWAlMgBJETAS8Q3y1qYBTAeskqSbgVUQ9dLg/HJiw8wrvNh2lKO/kHx R990yQ+BcfcygxijxlQ8SWAmBCbIPab+YpzFUEsXWUWKXLLX+FDgVKslf+RWq6cAAwCtG3o3DQpl bmRzdHJlYW0NCmVuZG9iag0KNTYgMCBvYmoNCjw8DQovTGVuZ3RoIDE0NA0KL0ZpbHRlciAvRmxh dGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjVWMFAwBWITCwUzY4UUQ16uQl4uE5CoAUgAJJWcy8vl 5MnLpR+uYGIMpDyAEkDKKcBZAahc39NXoaSoNJWXy9NFgYH5PxDQlGSoB5I/GPiB5AMGdiB5ACTI zMDA+J+BiYGB4T8DCNQjkfbYSPsGBnmg4gdAkvn/Bwzyx1AjeblcgVEUyMsFEGAAc4Sj+w0KZW5k c3RyZWFtDQplbmRvYmoNCjU3IDAgb2JqDQo8PA0KL0xlbmd0aCA5NQ0KL0ZpbHRlciAvRmxhdGVE ZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjJVMFAAYUNLBTNjhRRDXq5CXi5DE6CIAUgAJJWcy8vl5MnL pR+uYGgCpDyAEkDKKcBZAahc39NXoaSoNJWXy9NFgYEZG/yPBLCroA7k5XIFOjOQlwsgwAAjDhxx DQplbmRzdHJlYW0NCmVuZG9iag0KNTggMCBvYmoNCjw8DQovTGVuZ3RoIDg5DQovRmlsdGVyIC9G bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyMlUwUABhQ0sFM2OFFENerkJeLkMToIgBSAAklZzL y+XkyculH65gaAKkPIASQMopwFkBqFzf01ehpKg0lZfL00WBgXkgIS+XK9CZgbxcAAEGACVTEI8N CmVuZHN0cmVhbQ0KZW5kb2JqDQo1OSAwIG9iag0KPDwNCi9MZW5ndGggMTE5DQovRmlsdGVyIC9G bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyNlMwUDAFYmMzBRMzhRRDXq5CXi5jQ6CIAUgAJJWc y8vl5MnLpR+uYAyU1/cASgAppwBnBRDX01ehpKg0lZfL00WBgfk/IwPzHyD+AMQHgLiBkYGJgZGB ARfm/8nA8P8/UN+AYl4uV6AHA3m5AAIMACraV0INCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MCAwIG9i ag0KPDwNCi9MZW5ndGggMjEzDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIk8 0D0OgkAQhuHZUJBsstkjMBcw/kCiVCSoiRQmWnkAtbTQaA1Ho/MadLaWFoRxPog2z5Dd5V1CEvOE Yx5NOZlxMufT1Nmrs3GqyxNOFsPe8eJsXjg7PnCc6tjojo58t2Q9Py62fL89zs4WK5aOvEhDJFIR RR0RhS14g+ZPDaqBrFGkDcmI9DzBCw0hKoEHQ9MDA6hEJULP99HP77ZAehocbIE+Ki2ZTD/QRFoz IQgAlR0F5D8KXgMh8CACGSgBmgGa2qg16exaf8ze2a8AAwAAAVtRDQplbmRzdHJlYW0NCmVuZG9i ag0KNjEgMCBvYmoNCjw8DQovTGVuZ3RoIDEzNg0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpz dHJlYW0NCkiJMjZRMFAwVNA1VDA2UTC1VEgx5OUq5OUyNgYKGyiYQeWSc3m5nDx5ufTDFYyNgZQH UAZIOQU4KwDV63v6KpQUlabycnm6KPxgkP//nxKCAQjqSSIotpIcgh9OsIMIxj/1f0BuQRD/4MR/ MNEAIg6AiA8g4j9QHy+XKzBQA3m5AAIMADTsoiANCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MiAwIG9i ag0KPDwNCi9MZW5ndGggMTUwDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIky NVYwUDBV0DVUMLFQMDFTSDHk5Srk5TIBCRsomJhD5JJzebmcPHm59MMVTIyBlAdQBkg5BTgrANXr e/oqlBSVpvJyebooMDD//8EgP8RIRgyS4f8DEGnPwCDfwMCAlTyARD5gYOBgkP/AwCDBIP+DgaGC Qf4PAwPQnP8MzCDygPz///95uVyBQRjIywUQYACBLGjHDQplbmRzdHJlYW0NCmVuZG9iag0KNiAw IG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMg0KL0ZpcnN0 Q2hhciAzMg0KL0xhc3RDaGFyIDEyMQ0KL1dpZHRocyBbMjkyIDAgMCAwIDAgMCAwIDI3NCAwIDAg MCAwIDAgNDMwIDAgMCANCjAgMCAwIDAgMCAwIDAgMCAwIDYzNCAzNjIgMCAwIDAgMCAwIA0KMCA2 ODIgMCA2NjUgNzU0IDYxMyA1NzkgMCAwIDQ4MSAwIDAgNTcwIDg5MCAwIDc2NyANCjY1NSAwIDcy MyA2MzEgNjEwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANCjAgNTk2IDYyOSA1MjUgMCA1OTEgMzgx IDAgNjM4IDMwMSAwIDAgMCA5NTAgNjM4IDYxNSANCjYyNyAwIDQzMiA1MTMgNDE0IDYzOCAwIDAg MCA1NzMgXQ0KL0VuY29kaW5nIDYzIDAgUg0KL0Jhc2VGb250IC9DR0xNRUsrTVNUVDMxYzM3Nw0K L0ZvbnREZXNjcmlwdG9yIDE5IDAgUg0KPj4NCmVuZG9iag0KNyAwIG9iag0KPDwNCi9UeXBlIC9G b250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GNA0KL0VuY29kaW5nIDY0IDAgUg0KL0Jhc2VG b250IC9UaW1lcy1Sb21hbg0KPj4NCmVuZG9iag0KOCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQov U3VidHlwZSAvVHlwZTENCi9OYW1lIC9GNg0KL0VuY29kaW5nIDY0IDAgUg0KL0Jhc2VGb250IC9I ZWx2ZXRpY2ENCj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUg L1R5cGUxDQovTmFtZSAvRjgNCi9FbmNvZGluZyA2NCAwIFINCi9CYXNlRm9udCAvSGVsdmV0aWNh LUJvbGQNCj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9U eXBlMQ0KL05hbWUgL0YxMA0KL0VuY29kaW5nIDY0IDAgUg0KL0Jhc2VGb250IC9UaW1lcy1Cb2xk DQo+Pg0KZW5kb2JqDQoxMSAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTEN Ci9OYW1lIC9GMTMNCi9GaXJzdENoYXIgMA0KL0xhc3RDaGFyIDI1NQ0KL1dpZHRocyBbNDAwIDQw MCA1MDAgNDgwIDQ2MCA1MDAgMzIwIDUwMCAzNDAgMzYwIDQ0MCAzMjAgNTAwIDM2MCA0NjAgNDYw IA0KNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2 MCA0NjAgNDYwIA0KMzQwIDM2MCA0MjAgNjYwIDY2MCA5NDAgODAwIDI0MCAzMjAgMzIwIDQ2MCA2 MDAgMzQwIDM2MCAzNDAgNjAwIA0KNjYwIDY2MCA2NjAgNjYwIDY2MCA2NjAgNjYwIDY2MCA2NjAg NjYwIDM0MCAzNDAgNjAwIDYwMCA2MDAgNjYwIA0KODIwIDcyMCA3MjAgNzQwIDc4MCA3MjAgNjgw IDc4MCA4MjAgNDAwIDY0MCA4MDAgNjQwIDk0MCA3NDAgODAwIA0KNjYwIDgwMCA3ODAgNjYwIDcw MCA3NDAgNzIwIDk0MCA3ODAgNzAwIDY0MCAzMDAgNjAwIDMwMCA2MDAgNTAwIA0KNDAwIDU4MCA2 MDAgNTgwIDY0MCA1ODAgMzgwIDU4MCA2ODAgMzYwIDM0MCA2NjAgMzQwIDEwMDAgNjgwIDYyMCAN CjY0MCA2MjAgNDYwIDUyMCA0NjAgNjYwIDYwMCA4MDAgNjAwIDYyMCA1NjAgMzIwIDYwMCAzMjAg NjAwIDQ2MCANCjQ2MCA0NjAgMzIwIDY2MCA1NDAgMTAwMCA0NDAgMzgwIDUwMCAxMzYwIDY2MCAy MjAgMTIyMCA0NjAgNDYwIDQ2MCANCjQ2MCAzMjAgMzIwIDU0MCA1NDAgNDYwIDUwMCAxMDAwIDQ4 MCA5ODAgNTIwIDIyMCA5NDAgNDYwIDQ2MCA3MDAgDQozNDAgMzYwIDY2MCA2NjAgNjYwIDY2MCA2 MDAgNjAwIDUwMCA3NDAgNDAwIDQwMCA2MDAgMzYwIDc0MCA0NjAgDQo0MDAgNjAwIDM5NiAzOTYg NDAwIDY2MCA4MDAgMzQwIDM2MCAzOTYgNDAwIDQwMCA5OTAgOTkwIDk5MCA2NjAgDQo3MjAgNzIw IDcyMCA3MjAgNzIwIDcyMCAxMTQwIDc0MCA3MjAgNzIwIDcyMCA3MjAgNDAwIDQwMCA0MDAgNDAw IA0KNzgwIDc0MCA4MDAgODAwIDgwMCA4MDAgODAwIDYwMCA4MDAgNzQwIDc0MCA3NDAgNzQwIDcw MCA2NjAgNjYwIA0KNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgODgwIDU4MCA1ODAgNTgwIDU4MCA1 ODAgMzYwIDM2MCAzNjAgMzYwIA0KNjIwIDY4MCA2MjAgNjIwIDYyMCA2MjAgNjIwIDYwMCA2MjAg NjYwIDY2MCA2NjAgNjYwIDYyMCA2NDAgNjIwIA0KXQ0KL0VuY29kaW5nIDY0IDAgUg0KL0Jhc2VG b250IC9Cb29rbWFuLURlbWkNCi9Gb250RGVzY3JpcHRvciAyMSAwIFINCj4+DQplbmRvYmoNCjYz IDAgb2JqDQo8PA0KL1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWyAwL0cwMCA5L0cwOSAx MC9HMEEgMTMvRzBEIDEyNy9HN0YgMTI4L0c4MA0KXQ0KPj4NCmVuZG9iag0KNjQgMCBvYmoNCjw8 DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbIDAvZ3JhdmUvYWN1dGUvY2lyY3VtZmxl eC90aWxkZS9tYWNyb24vYnJldmUvZG90YWNjZW50L2RpZXJlc2lzDQovcmluZy9jZWRpbGxhL2h1 bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24vZG90bGVzc2kvYnVsbGV0L2J1bGxldA0KL2J1bGxldC9i dWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQNCi9idWxsZXQv YnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0DQogMzkvcXVv dGVzaW5nbGUgOTYvZ3JhdmUgMTI3L2J1bGxldC9idWxsZXQvYnVsbGV0L3F1b3Rlc2luZ2xiYXNl L2Zsb3Jpbi9xdW90ZWRibGJhc2UNCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2VyZGJsL2NpcmN1bWZs ZXgvcGVydGhvdXNhbmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UNCi9idWxsZXQvYnVsbGV0L2J1 bGxldC9idWxsZXQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmln aHQNCi9idWxsZXQvZW5kYXNoL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nhcm9uL2d1aWxzaW5n bHJpZ2h0L29lDQovYnVsbGV0L2J1bGxldC9ZZGllcmVzaXMvc3BhY2UgMTY0L2N1cnJlbmN5IDE2 Ni9icm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodA0KL29yZGZlbWluaW5lIDE3Mi9sb2dp Y2Fsbm90L2h5cGhlbi9yZWdpc3RlcmVkL21hY3Jvbi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVy aW9yDQovdGhyZWVzdXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVyZWQvY2VkaWxsYS9v bmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXINCi9vbmVoYWxmL3RocmVlcXVh cnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVyZXNpcy9Bcmlu Zw0KL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJlc2lzL0lncmF2 ZS9JYWN1dGUNCi9JY2lyY3VtZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9PZ3JhdmUvT2FjdXRl L09jaXJjdW1mbGV4L090aWxkZQ0KL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xhc2gvVWdyYXZlL1Vh Y3V0ZS9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlDQovVGhvcm4vZ2VybWFuZGJscy9hZ3Jh dmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMvYXJpbmcNCi9hZS9jY2VkaWxs YS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNpcy9pZ3JhdmUvaWFjdXRlDQovaWNp cmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0ZS9vY2lyY3VtZmxleC9v dGlsZGUNCi9vZGllcmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4 L3VkaWVyZXNpcy95YWN1dGUNCi90aG9ybi95ZGllcmVzaXMNCl0NCj4+DQplbmRvYmoNCjMgMCBv YmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCAxNiAwIFINCi9SZXNvdXJjZXMgNSAwIFINCi9D b250ZW50cyA0IDAgUg0KPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8DQovVHlwZSAvUGFnZXMNCi9L aWRzIFszIDAgUl0NCi9Db3VudCAxDQovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQ0KPj4NCmVuZG9i ag0KNjUgMCBvYmoNCjw8DQovVHlwZSAvQ2F0YWxvZw0KL1BhZ2VzIDE2IDAgUg0KPj4NCmVuZG9i ag0KNjYgMCBvYmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5OTkwMzA1MjAwMzQzKQ0KL1Byb2R1 Y2VyIChcMzc2XDM3N1wwMDBBXDAwMGNcMDAwclwwMDBvXDAwMGJcMDAwYVwwMDB0XDAwMCBcMDAw RFwwMDBpXDAwMHNcMDAwdFwwMDBpXDAwMGxcMDAwbFwwMDBlXDAwMHJcMDAwIFwwMDAzXDAwMC5c MDAwMFwwMDAxXDAwMCBcMDAwZlwwMDBvXDAwMHJcMDAwIFwwMDBXXDAwMGlcMDAwblwwMDBkXDAw MG9cMDAwd1wwMDBzKQ0KL0F1dGhvciAoTWFoYnVidXIgU3llZCkNCi9DcmVhdG9yIChIUFBTNDFB LkRSViBWZXJzaW9uIDQuMTApDQovVGl0bGUgKE1pY3Jvc29mdCBXb3JkIC0gcGFwZXJjYWxsMi5k b2MpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDY3DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MTcgMDAwMDAgbg0KMDAwMDAxMTM3MSAwMDAwMCBuDQowMDAwMDMwNDkwIDAwMDAwIG4NCjAwMDAw MDYzOTAgMDAwMDAgbg0KMDAwMDAxMTA5NCAwMDAwMCBuDQowMDAwMDI2ODQ0IDAwMDAwIG4NCjAw MDAwMjcyODIgMDAwMDAgbg0KMDAwMDAyNzM5MCAwMDAwMCBuDQowMDAwMDI3NDk2IDAwMDAwIG4N CjAwMDAwMjc2MDcgMDAwMDAgbg0KMDAwMDAyNzcxNiAwMDAwMCBuDQowMDAwMDE3MTk0IDAwMDAw IG4NCjAwMDAwMjE5OTYgMDAwMDAgbg0KMDAwMDAyMjYwMyAwMDAwMCBuDQowMDAwMDEyNjI5IDAw MDAwIG4NCjAwMDAwMzA1NzkgMDAwMDAgbg0KMDAwMDAxMTQyMiAwMDAwMCBuDQowMDAwMDEyNDk2 IDAwMDAwIG4NCjAwMDAwMTI3MDkgMDAwMDAgbg0KMDAwMDAxMzA1OCAwMDAwMCBuDQowMDAwMDE2 OTM1IDAwMDAwIG4NCjAwMDAwMTcxNDIgMDAwMDAgbg0KMDAwMDAxNzUzNCAwMDAwMCBuDQowMDAw MDE3Njg4IDAwMDAwIG4NCjAwMDAwMTc5MjIgMDAwMDAgbg0KMDAwMDAxODIwMiAwMDAwMCBuDQow MDAwMDE4NDgxIDAwMDAwIG4NCjAwMDAwMTg2NTMgMDAwMDAgbg0KMDAwMDAxODkzNSAwMDAwMCBu DQowMDAwMDE5MjQ2IDAwMDAwIG4NCjAwMDAwMTk1MjUgMDAwMDAgbg0KMDAwMDAxOTcxNSAwMDAw MCBuDQowMDAwMDE5ODk0IDAwMDAwIG4NCjAwMDAwMjAwNzIgMDAwMDAgbg0KMDAwMDAyMDMzNyAw MDAwMCBuDQowMDAwMDIwNTk1IDAwMDAwIG4NCjAwMDAwMjA5MDYgMDAwMDAgbg0KMDAwMDAyMTIw MCAwMDAwMCBuDQowMDAwMDIxNTI4IDAwMDAwIG4NCjAwMDAwMjE3MDIgMDAwMDAgbg0KMDAwMDAy MTk0NCAwMDAwMCBuDQowMDAwMDIyMjI3IDAwMDAwIG4NCjAwMDAwMjIyOTUgMDAwMDAgbg0KMDAw MDAyMjMzNCAwMDAwMCBuDQowMDAwMDIyNTUxIDAwMDAwIG4NCjAwMDAwMjI5NzIgMDAwMDAgbg0K MDAwMDAyMzEzNSAwMDAwMCBuDQowMDAwMDIzMzU2IDAwMDAwIG4NCjAwMDAwMjM1MzIgMDAwMDAg bg0KMDAwMDAyMzgxNCAwMDAwMCBuDQowMDAwMDIzOTk5IDAwMDAwIG4NCjAwMDAwMjQxNzggMDAw MDAgbg0KMDAwMDAyNDQ3OSAwMDAwMCBuDQowMDAwMDI0NzM2IDAwMDAwIG4NCjAwMDAwMjUwMjkg MDAwMDAgbg0KMDAwMDAyNTMyNiAwMDAwMCBuDQowMDAwMDI1NTUyIDAwMDAwIG4NCjAwMDAwMjU3 MjggMDAwMDAgbg0KMDAwMDAyNTg5OCAwMDAwMCBuDQowMDAwMDI2MDk5IDAwMDAwIG4NCjAwMDAw MjYzOTQgMDAwMDAgbg0KMDAwMDAyNjYxMiAwMDAwMCBuDQowMDAwMDI4OTU0IDAwMDAwIG4NCjAw MDAwMjkwNTggMDAwMDAgbg0KMDAwMDAzMDY2OSAwMDAwMCBuDQowMDAwMDMwNzI2IDAwMDAwIG4N CnRyYWlsZXINCjw8DQovU2l6ZSA2Nw0KL1Jvb3QgNjUgMCBSDQovSW5mbyA2NiAwIFINCi9JRCBb PGI3YzVmM2VjODA1NGFhOWM4OWU4OTkxYWFhMmJkYTlkPjxiN2M1ZjNlYzgwNTRhYTljODllODk5 MWFhYTJiZGE5ZD5dDQo+Pg0Kc3RhcnR4cmVmDQozMTA4Mg0KJSVFT0YNCg== --=====================_920859514==_ Content-Type: text/plain; charset="us-ascii" ******************************** Dr. Mahbubur Rahman Syed Department of Electrical Engineering, EERoom 101 North Dakota State University Fargo, ND 58105, USA Email: msyed@badlands.nodak.edu Phone: (701) 231 7689 Fax: (701) 231 8677 ******************************** --=====================_920859514==_-- From rem-conf Mon Mar 08 09:41:57 1999 From rem-conf-request@es.net Mon Mar 08 09:41:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10K3us-0002jx-00; Mon, 8 Mar 1999 09:34:10 -0800 Received: from magic.ensica.fr (magic) [192.70.110.76] by mail1.es.net with smtp (Exim 1.81 #2) id 10K3uq-0002jP-00; Mon, 8 Mar 1999 09:34:08 -0800 Received: (from pdss@localhost) by magic (940816.SGI.8.6.9/8.6.12) id SAA08225 for rem-conf@es.net; Mon, 8 Mar 1999 18:32:47 +0100 Date: Mon, 8 Mar 1999 18:32:47 +0100 From: pierre de saqui sannes DFR/MI Message-Id: <199903081732.SAA08225@magic> To: rem-conf@es.net Subject: IDMS99: extended deadline March 21st, 1999 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list =======> =======> IDMS99 extended deadline ===> March 21st, 1999 <=== =======> C a l l f o r p a p e r IDMS'99 6th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 12-15 October 1999, Toulouse, France Organized by LAAS-CNRS and ENSICA http://www.ensica.fr/idms99 email : idms99@ensica.fr The Sixth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services will be held in 1999 at ENSICA, Toulouse, France. The purpose of this workshop is to bring together researchers, developers, and practitioners from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services - ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to: * High-speed/ATM networks * Mobile multimedia systems * Multimedia over satellite * Multimedia middleware * Quality of service issues * Media scaling * Resource management * Protocol design and implementation * Development tools for distributed multimedia applications * Distributed multimedia database systems * Multimedia-specific intelligent agents * Computer supported collaborative work * Distributed virtual reality systems * Distance education * Conferencing * Digital libraries * Interactive television * Video-on-demand systems * Compression algorithms IDMS'99 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavor of a workshop, the number of participants will be restricted. Furthermore, we encourage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings edited by Springer Verlag in the Lecture Notes in Computer Science series. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'99 web page: http://www.ensica.fr/idms99/. Authors without web access may email to owe@laas.fr for requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to Dr Philippe Owezarski. Important Dates Submission due: March 21, 1999 NEW !!!!!!! Notification acceptance: April 30, 1999 Camera ready version: June 14, 1999 Workshop: October 12 - 15, 1999 Co-chairs: Michel Diaz, Philippe Owezarski, Patrick Sénac LAAS-CNRS, 7 Avenue du Colonel Roche, 31077 Toulouse cedex 4, France e-mail: {diaz, owe}@laas.fr, Phone: +33 5 61 33 63 17, Fax: +33 5 61 33 64 11 ENSICA, 1 Place Emile Blouin, 31056 Toulouse cedex, France e-mail: senac@ensica.fr, Phone: +33 5 61 61 86 81, Fax: +33 5 61 61 86 86 Program Committee Chairmen: Michel Diaz, Philippe Owezarski Organization Chairman: Patrick Sénac Tutorial Chairman: Laurent Dairaine Publicity and Demonstration Chairman: Pierre de Saqui-Sannes Conference electronic support Chairman: Marc Boyer Program Committee H. Affifi, ENST Bretagne, France P.D. Amer, U. Delaware, USA E. Biersack, Institut Eurécom, France G. v. Bochmann, U. Ottawa, Canada B. Butscher, GMD FOKUS, Germany A.T. Campbell, Columbia U., USA T.S. Chua, U. Singapore, SG J.-P. Courtiat, LAAS-CNRS, France J. Crowcroft, UCL, UK L. Delgrossi, U. Piacenza, Italy C. Diot, Sprint ATL, USA R. Dssouli, U. Montréal, Canada M. Dudet, CNET France Télécom, France W. Effelsberg, U. Mannheim, Germany F. Eliassen, U. Oslo, Norway S. Fdida, LIP6, France D. Ferrari, U. Piacenza, Italy V. Goebel, UNIK, Norway T. Helbig, Philips, Germany J.-P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK W. Kalfa, TU Chemnitz, Germany T.D.C. Little, Boston U., USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA G. Neufeld, UBC Vancouver, Canada B. Pehrson, KTH Stockholm, Sweden T. Plagemann, UNIK, Norway B. Plattner, ETH Zurich, Switzerland L.A. Rowe, U. California Berkeley, USA H. Scholten, U. Twente, Netherlands A. Seneviratne, UTS, Australia R. Steinmetz, GMD, Germany J.B. Stéfani, CNET France Télécom, France L. Wolf, TU Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany Pierre de Saqui-Sannes pdss@ensica.fr ENSICA http://www.ensica.fr/~pdss 1 Place Emile Blouin tel. +33 5 61.61.86.81 31056 Toulouse Cedex 5 fax. +33 5 61.61.86.86 From rem-conf Mon Mar 08 09:41:57 1999 From rem-conf-request@es.net Mon Mar 08 09:41:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10K3uM-0002jj-00; Mon, 8 Mar 1999 09:33:38 -0800 Received: from monsoon.dial.pipex.net [158.43.128.69] by mail1.es.net with smtp (Exim 1.81 #2) id 10K3uL-0002jW-00; Mon, 8 Mar 1999 09:33:37 -0800 Received: (qmail 12827 invoked from network); 8 Mar 1999 17:33:01 -0000 Received: from userl806.uk.uudial.com (HELO mice1) (193.149.76.111) by smtp.dial.pipex.com with SMTP; 8 Mar 1999 17:33:01 -0000 Message-ID: <000901be6989$293c3440$446afea9@mice1> Reply-To: "Conferences" From: "Conferences" To: "Marketing Ireland" Subject: Fw: 30% Higher Attendance at your Conference Date: Mon, 8 Mar 1999 17:28:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subject: 30% Higher Attendance at your Conference >Please forgive our interruption but this will help you. > > >We have a new Web Site > >http://www.irelandconferences.com > >You are a busy professional so we have geared ourselves to be of the most >assistance to you when you have to organise that conference, meeting, or >incentive . >Just eMail, phone , or fax us with the details of your event and we'll be >back to you within 48 hours with all the information you need to hold your >event in Ireland. > >Organisers are telling us that in 1998 they have had a 30%+ higher >attendance at their Irish events that anywhere else in Europe. It's no >wonder we're called the 'Party Capital of Europe' > >Of course, we are not an agent so cannot organise or book for you, but we >will put you in contact with all the relevant contacts. > >So if you have an event you are planning let Ireland, or Dublin quote for >the event. > >There has never been a better time to hold your event in Ireland. > >Please call us. > >marketing@irelandconferences.com > > >If you do not want to receive further information please write REMOVE and return this email. From rem-conf Mon Mar 08 09:46:08 1999 From rem-conf-request@es.net Mon Mar 08 09:46:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10K43G-0002uw-00; Mon, 8 Mar 1999 09:42:50 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10K43F-0002tS-00; Mon, 8 Mar 1999 09:42:49 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Mar 1999 17:42:04 +0000 To: rem-conf@es.net Subject: REMINDER: AVT agenda items due Date: Mon, 08 Mar 1999 17:42:03 +0000 Message-ID: <4043.920914923@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Just a reminder that requests for agenda time in AVT should be sent to Steve and I as soon as possible. We hope to have a draft agenda out tomorrow. Colin From rem-conf Mon Mar 08 12:24:54 1999 From rem-conf-request@es.net Mon Mar 08 12:24:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10K6UP-0006tH-00; Mon, 8 Mar 1999 12:19:01 -0800 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 10K6UO-0006t6-00; Mon, 8 Mar 1999 12:19:00 -0800 Received: from dopey (dopey [193.175.133.137]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA12387 for ; Mon, 8 Mar 1999 21:18:57 +0100 (MET) Received: (from ntl@localhost) by dopey (8.8.8/8.8.8) id VAA24664 for rem-conf@es.net; Mon, 8 Mar 1999 21:16:31 +0100 (MET) From: Le Message-Id: <199903082016.VAA24664@dopey> Subject: Question: Interleaving To: rem-conf@es.net Date: Mon, 8 Mar 1999 21:15:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, i am a newbie to avt and would like to know whether there are publications/research on interleaving of audio packets to reduce the effect of burst loss, especially for frame-based codecs (J. Rosenberg stated in "G.729 Error Recovery" that frame-based codecs are quite sensitive against burst loss). Thank you, -- long From rem-conf Tue Mar 09 05:44:23 1999 From rem-conf-request@es.net Tue Mar 09 05:44:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KMaW-00079u-00; Tue, 9 Mar 1999 05:30:24 -0800 Received: from newgate.mitel.com (Mitel.COM) [198.53.180.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10KMaU-00079T-00; Tue, 9 Mar 1999 05:30:22 -0800 Received: from Software.Mitel.COM (software.mitel.com [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id IAA19881 for ; Tue, 9 Mar 1999 08:29:20 -0500 (EST) Received: from woodr by Software.Mitel.COM (4.1/SMI-4.0) id AA02843 for rem-conf@es.net; Tue, 9 Mar 99 08:29:19 EST Sender: woodr@Mitel.COM Message-Id: <36E5222F.7F05@mitel.com> Date: Tue, 09 Mar 1999 08:29:19 -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: rem-conf@es.net Subject: RTP mux drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I notice most of the RTP mux drafts are expired or expiring. Does this mean we can forget all about this (good). [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Tue Mar 09 07:08:04 1999 From rem-conf-request@es.net Tue Mar 09 07:08:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KO1G-0000Z7-00; Tue, 9 Mar 1999 07:02:06 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10KO1D-0000Yx-00; Tue, 9 Mar 1999 07:02:03 -0800 Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by dirty; Tue Mar 9 10:01:04 EST 1999 Received: from dnrc.bell-labs.com (bombay [135.180.160.73]) by sea.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA23867; Tue, 9 Mar 1999 09:58:44 -0500 (EST) Message-ID: <36E5336D.656C3F0A@dnrc.bell-labs.com> Date: Tue, 09 Mar 1999 09:42:53 -0500 From: Sanjoy Paul Organization: Bell Laboratories X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qosws@dstc.edu.au, qos-iso@mci.org.uk, rem-conf@es.net, reres@laas.fr, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, testnet@canarie.ca, xtp-relay@cs.concordia.ca, sanjoy@dnrc.bell-labs.com Subject: Call for Papers (IEEE Network Magazine -- Special Issue on Multicasting) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please excuse me if you receive multiple copies of this announcement. Sorry to bother you if you shouldn't have received this e-mail. - Sanjoy Paul From rem-conf Tue Mar 09 07:48:21 1999 From rem-conf-request@es.net Tue Mar 09 07:48:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KOft-0001TM-00; Tue, 9 Mar 1999 07:44:05 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10KOfr-0001T6-00; Tue, 9 Mar 1999 07:44:04 -0800 Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by dirty; Tue Mar 9 10:43:15 EST 1999 Received: from dnrc.bell-labs.com (bombay [135.180.160.73]) by sea.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA24884; Tue, 9 Mar 1999 10:41:09 -0500 (EST) Message-ID: <36E53D5F.AD2F5293@dnrc.bell-labs.com> Date: Tue, 09 Mar 1999 10:25:19 -0500 From: Sanjoy Paul Organization: Bell Laboratories X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qosws@dstc.edu.au, qos-iso@mci.org.uk, rem-conf@es.net, reres@laas.fr, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, testnet@canarie.ca, xtp-relay@cs.concordia.ca, sanjoy@dnrc.bell-labs.com Subject: Forgot the attachment for Call for Papers -- Here it is! Content-Type: multipart/mixed; boundary="------------20DE0035C4B94C2E44EDD670" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------20DE0035C4B94C2E44EDD670 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------20DE0035C4B94C2E44EDD670 Content-Type: text/plain; charset=us-ascii; name="ieee-network.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ieee-network.txt" IEEE Network Magazine - Special Issue on Multicasting Guest Editor: Sanjoy Paul Room 4G-532, Bell Laboratories 101 Crawfords Corner Road Holmdel, NJ 07733 Phone: (732) 949-1637 Fax: (732) 949-9118 WWW: http://www.bell-labs.com/user/sanjoy email: sanjoy@research.bell-labs.com Scope: Multicasting is a fundamental communication paradigm for supporting one-to-many communications. There are several key applications, such as, real-time distribution of market data, website replication, push-based applications, distributed database synchronization, multimedia streaming, multi-party conferencing, distributed interactive simulations (DIS), distributed multi-party games etc. which cannot be supported in a scalable way on the Internet without multicasting. This special issue covers the technology needed to make multi-party communication a reality and the challenges that need to be addressed. Topics of interest for technical papers include but are not limited to: Multicast routing algorithms and protocols Multicast transport protocols Multicast applications Multicast Traffic Engineering Quality-of-service support for multicast communication Mobile multicast Charging and billing for multicast Novel architectures to support multicast Role of satellites in multicast Novel applications Multicast security and privacy issues We are especially interested in research papers that describe real systems and experiments and also good tutorial papers on any one or more of the above-mentioned topics. Work-in-progress papers describing the state of on-going research projects in multicasting are also encouraged. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the problems encountered and their potential solutions. Tutorial papers must be based on a detailed survey of the literature and written in a simple-to-understand manner. Submission, Approval, Review, and Acceptance: Authors are requested to send e-mail to the guest-editor, Sanjoy Paul (sanjoy@research.bell-labs.com), giving a URL from where a postscript or PDF file can be downloaded by the guest-editor. Upon approval by the guest-editor, all feature articles will then undergo a technical peer review consistent with other archival publications. Potential authors may wish to consult the sections on author information and guidelines for reviewers, which are given at http://www.comsoc.org/socstr/techcom/ntwrk. More details on the submission guidelines can be found in http://www.computer.org/internet/edguide.htm and http://www.comsoc.org/socstr/techcom/ntwrk Schedule: Call for Papers: March 1, 1999 Submission Deadline: July 1, 1999 Acceptance Notification: September 1, 1999 Final Manuscripts Due: October 1, 1999 Publication of Completed Special Issue: January/February 2000 --------------20DE0035C4B94C2E44EDD670-- From rem-conf Tue Mar 09 10:10:36 1999 From rem-conf-request@es.net Tue Mar 09 10:10:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KQnt-0003tJ-00; Tue, 9 Mar 1999 10:00:29 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10KQns-0003t9-00; Tue, 9 Mar 1999 10:00:28 -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 KAA06501; Tue, 9 Mar 1999 10:00:27 -0800 (PST) Message-Id: <3.0.3.32.19990210142139.00ad8a00@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Feb 1999 14:21:39 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/10 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 Technology and Accessibility Wednesday, March 10, 1999, 1:00-2:30 p.m. 405 Soda Hall Gary Robson VITAC As new technologies have invaded everyday life, they have created cycles of increased and decreased accessibility for people with hearing and vision impairments. This seminar focuses on multimedia and deafness, and where we are on the curve now. I'll discuss specific accessibility tools and technologies, and point out resources for those who want to explore the subject in greater depth. 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 Mar 09 11:47:15 1999 From rem-conf-request@es.net Tue Mar 09 11:47:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KSN4-0005eN-00; Tue, 9 Mar 1999 11:40:54 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10KSN2-0005eD-00; Tue, 9 Mar 1999 11:40:53 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Mar 1999 19:40:48 +0000 To: rem-conf@es.net Subject: DRAFT AVT agenda for Minneapolis cc: casner@cisco.com Date: Tue, 09 Mar 1999 19:40:47 +0000 Message-ID: <2613.921008447@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed is a draft agenda for the forthcoming AVT meeting in Minneapolis. Please send comments/corrections to Steve and I as soon as possible. Colin Audio/Video Transport WG A G E N D A Wednesday, March 17 at 15:30-17:30 ================================== - Introduction - Documents published since the last meeting RFC2508 - IP/UDP/RTP header compresssion - Update to RTP draft-ietf-avt-rtp-new-03.txt (Casner) draft-ietf-avt-rtpsample-02.txt * draft-ietf-avt-rtcptest-00.txt (Rosenberg) 15 - Update to RTP audio/video profile draft-ietf-avt-profile-new-05.txt (Casner) draft-hoschka-rtp-mime-00.txt draft-ietf-avt-rtp-format-guidelines-01.txt * - RTP MIB draft-ietf-avt-rtp-mib-04.txt (Strahm) 10* - A More Loss-Tolerant RTP Payload Format for MP3 Audio draft-finlayson-rtp-mp3-00.txt (Finlayson) 10 - RTP Payload Format for DV Format Video draft-kobayashi-dv-video-00.txt (Kobayashi) 10 - RTP Payload Format for Generic FEC draft-ietf-avt-fec-05.txt (Rosenberg) 5* - RTP Payload Format for Interleaved Media draft-ietf-avt-interleaving-01.txt (Perkins) 5 - RTP Payload Format for PureVoice (QCELP) audio 5 draft-mckay-qcelp-02.txt - RTCP location reports draft-crowcroft-rtcp-latlong-00.txt (Crowcroft) 10 Thursday, March 18 at 15:30-17:30 ================================= - RTP Payload Format for MPEG-4 Streams 15 draft-ietf-avt-rtp-mpeg4-01.txt (Civanlar) - RTP Multiplexing 30 Items marked with a * are considered ready for last call. From rem-conf Tue Mar 09 12:15:51 1999 From rem-conf-request@es.net Tue Mar 09 12:15:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KSpi-0006cY-00; Tue, 9 Mar 1999 12:10:30 -0800 Received: from sunblast.eng.usf.edu [131.247.14.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10KSph-0006cO-00; Tue, 9 Mar 1999 12:10:29 -0800 Received: from localhost (padhye@localhost [127.0.0.1]) by sunblast.eng.usf.edu (8.8.8/8.8.7) with ESMTP id PAA21976 for ; Tue, 9 Mar 1999 15:10:25 -0500 (EST) Date: Tue, 9 Mar 1999 15:10:24 -0500 (EST) From: Chinmay Padhye X-Sender: padhye@sunblast To: rem-conf@es.net Subject: Voice Traces. 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 computer science grad student at the University Of South Florida. My thesis area deals with transporting voice over IP. I had a couple of questions regarding research in this field. 1) Is there any standard set of traces that can be used for simulation. I think a standard set of traces will help when comparing two algorithms. 2) Is there any site where I can download any voice traces. 3) What is the tolerable end to end delay limit in interactive voice conversations. I have seen different tolerance limits taken in the literature. What is the general acceptable limit. It will be a great help if someone can let me have a few traces for my simulation work. Thanks in advance, Yours Truly, Chinmay V. P. University Of South Florida. From rem-conf Wed Mar 10 07:21:50 1999 From rem-conf-request@es.net Wed Mar 10 07:21:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KkaP-00063A-00; Wed, 10 Mar 1999 07:07:53 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10KkaM-000630-00; Wed, 10 Mar 1999 07:07:51 -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 KAA21683 for ; Wed, 10 Mar 1999 10:07:46 -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 KAA00302 for ; Wed, 10 Mar 1999 10:07:43 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <36E68ABF.D9CFA5A4@cs.columbia.edu> Date: Wed, 10 Mar 1999 10:07:43 -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: rem-conf@es.net Subject: US Patent 5870412: Forward error correction system for packet based real time media Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list http://www.patents.ibm.com/patlist?icnt=US&patent_number=5870412&x=37&y=9 On cursory inspection, this may be directly related to some of the redundancy and FEC work in rem-conf. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Mar 10 08:14:11 1999 From rem-conf-request@es.net Wed Mar 10 08:14:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KlXU-00070B-00; Wed, 10 Mar 1999 08:08:56 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10KlXR-0006zz-00; Wed, 10 Mar 1999 08:08:53 -0800 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Mar 1999 16:06:46 +0000 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: US Patent 5870412: Forward error correction system for packet based real time media In-reply-to: Your message of "Wed, 10 Mar 1999 10:07:43 EST." <36E68ABF.D9CFA5A4@cs.columbia.edu> Date: Wed, 10 Mar 1999 16:06:44 +0100 Message-ID: <6256.921082004@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <36E68ABF.D9CFA5A4@cs.columbia.edu>Henning Schulzrinne writes: > http://www.patents.ibm.com/patlist?icnt=US&patent_number=5870412&x=37&y=9 > > On cursory inspection, this may be directly related to some of the > redundancy and FEC work in rem-conf. Prior art ? Audio-Video Transport Working Group D. Budge INTERNET-DRAFT R. McKenzie W. Mills W. Diss P. Long Smith Micro Software, Inc. May 1997 Expires: December 4 1997 Media-independent Error Correction using RTP draft-budge-media-error-correction-00.txt - Orion From rem-conf Wed Mar 10 08:15:33 1999 From rem-conf-request@es.net Wed Mar 10 08:15:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KlaZ-00071k-00; Wed, 10 Mar 1999 08:12:07 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10KlaV-00071Y-00; Wed, 10 Mar 1999 08:12:03 -0800 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Wed Mar 10 11:11:57 EST 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Wed Mar 10 11:11:54 EST 1999 Received: from localhost (yener@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA05728; Wed, 10 Mar 1999 11:11:07 -0500 (EST) Date: Wed, 10 Mar 1999 11:11:07 -0500 (EST) From: Bulent Yener To: enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, tcgn@ieee.org, hipparch@entropy.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, int-serv@ISI.EDU, isadsoc@fokus.gmd.de, itc@ieee.org, isadsoc@fokus.gmd.de, itc@ieee.org, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qosws@dstc.edu.au, qos-iso@mci.org.uk, rem-conf@es.net, reres@laas.fr, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, testnet@canarie.ca, xtp-relay@cs.concordia.ca, multicomm@research.panasonic.com cc: jorg@cs.virginia.edu, p.dowd@ieee.org, Bulent Yener Subject: Call For Papers IEEE Network Magazine Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please excuse me if you receive multiple copies of this announcement and/or if you shouldn't have received it at all. ------------------------------------------------------------------------------- Call For Papers IEEE Network Magazine Special Issue on Network Security Guest Editors: Bulent Yener Patrick Dowd Bell Labs, Lucent Laboratory for Technologies Telecommunications Murray Hill, NJ 07974 Sciences Tel: +1 908 582 7087 United States Department Fax: +1 908 582 1239 of Defense Email: yener@research.bell-labs.com Ft. Meade MD 20755-6512 Tel: +1 301 688 0347 Fax: +1 301 688 0588 Email: p.dowd@ieee.org Scope: Network and Internet security has become a crucial requirement for both users and service providers. The Internet is a commercial infrastructure where sensitive and confidential personal and business data are carried over public networks. Although security is often treated as an after-thought, this attitude is changing. Security within an application needs to be considered as a fundamental element of the application, treated analogously to Quality of Service (QoS) considerations. Security is often viewed as a one-size-fits-all paradigm, but this is difficult to sustain due to the eclectic collection of communications mediums that compose the Internet infrastructure. The danger of a cookie-cutter strategy is that security will contend with performance since it is not suited to the environment. As the QoS requirements of applications and the physical layer properties internetworking become more diverse, agile but robust and consistent security solutions are needed. This is difficult, since custom solutions typically have difficulty surviving in a mass market, yet flexibility is needed for security use to become ubiquitous. We are interested in tutorial-oriented research papers that describe real services, software systems and experiments. Work-in-progress papers describing the state of on-going research projects in Internet security are encouraged. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Topics of interest include: Intrusion detection Authentication Mobile code and agent security Privacy and anonymity Key management Access control and Firewalls Wireless, mobile network security Secure multicasting Data integrity Security verification Security protocols Policy modeling Commercial security Electronic commerce Security management If you are unsure if your work falls within the scope of this special issue, please send an abstract to one of the guest editors. We would be happy to review it and provide feedback. Manuscript Submission This special issue will only consider electronic submissions in the format of postscript, PDF, or MS WORD. To submit a paper for consideration, authors should 1.Send your paper to one of the guest editors via email. The paper should be included as an email attachment, or the author may provide a URL where the file can be downloaded. 2.Indicate which author is to serve as the primary correspondence contact. 3.Provide a contact list for all of the other authors. Please list affiliations, mailing addresses, phone/fax numbers, and email addresses. We will provide an acknowledgement of receipt of the paper within 24 hours of submission. Schedule: Paper Submission Deadline: June 1, 1999 Feedback to Authors: August 1, 1999 Final Manuscripts to Publisher: September 1, 1999 Publication of Special Issue: Nov/Dec 1999 _____________________________________________________ Bulent Yener Information Sciences Research Center Bell Laboratories, Lucent Technologies 600 Mountain Avenue, Room 2T-314 Murray Hill, NJ 07974 email: yener@research.bell-labs.com phone: (908) 582 7087 fax: (908) 582 1239 _____________________________________________________ From rem-conf Wed Mar 10 08:38:03 1999 From rem-conf-request@es.net Wed Mar 10 08:38:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Kluv-0000cr-00; Wed, 10 Mar 1999 08:33:09 -0800 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Klut-0000ch-00; Wed, 10 Mar 1999 08:33:07 -0800 Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id QAA06824 for ; Wed, 10 Mar 1999 16:33:06 GMT Received: by FMSMSX26 with Internet Mail Service (5.5.2448.0) id ; Wed, 10 Mar 1999 08:33:05 -0800 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2321CFC@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'rem-conf@es.net'" Subject: RE: US Patent 5870412: Forward error correction system for packet based real time media Date: Wed, 10 Mar 1999 08:33:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Barely prior art ... One thing I am wondering about, do we think the IETF should start putting dates of first drafts on documents. For example the patent mention was awarded this year, but its date of filing was Dec 12 97. This document was published as an RFC Dec 4 1997, however I bet there were drafts around for a year or more that would help move the prior art date back quite a bit. There is no record of this available as far as I know (Drafts expire you know) Bill -----Original Message----- From: Orion Hodson [mailto:O.Hodson@cs.ucl.ac.uk] Sent: Wednesday, March 10, 1999 7:07 AM To: Henning Schulzrinne Cc: rem-conf@es.net Subject: Re: US Patent 5870412: Forward error correction system for packet based real time media <36E68ABF.D9CFA5A4@cs.columbia.edu>Henning Schulzrinne writes: > http://www.patents.ibm.com/patlist?icnt=US&patent_number=5870412&x=37&y=9 > > On cursory inspection, this may be directly related to some of the > redundancy and FEC work in rem-conf. Prior art ? Audio-Video Transport Working Group D. Budge INTERNET-DRAFT R. McKenzie W. Mills W. Diss P. Long Smith Micro Software, Inc. May 1997 Expires: December 4 1997 Media-independent Error Correction using RTP draft-budge-media-error-correction-00.txt - Orion From rem-conf Wed Mar 10 09:53:40 1999 From rem-conf-request@es.net Wed Mar 10 09:53:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Kn4x-0001nj-00; Wed, 10 Mar 1999 09:47:35 -0800 Received: from vs.informatik.uni-ulm.de [134.60.77.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Kn4v-0001nY-00; Wed, 10 Mar 1999 09:47:33 -0800 Received: from [134.60.77.18] (134.60.77.18) by vs.informatik.uni-ulm.de with SMTP (Eudora Internet Mail Server 2.2); Wed, 10 Mar 1999 18:50:34 +0200 X-Sender: wolf@134.60.77.243 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Mar 1999 18:50:38 +0200 To: rem-conf@es.net From: wolf@informatik.uni-ulm.de (Klaus H. Wolf) Subject: RE: US Patent 5870412: Forward error correction system for packet based real time media X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I know of a publication from March '93. This paper calls the recent IBM 'invention' the state of the art and proposes higher order FEC codes. -Klaus H. Wolf ---- Distributed Systems Dept. voice: +49 731 502 4145 University of Ulm ethernet: 08:00:20:12:2a:01 89069 Ulm Cobrow: http://www.cobrow.com/ Germany Live: http://www.cobrow.com/pages/people/wolf.html From rem-conf Wed Mar 10 11:29:50 1999 From rem-conf-request@es.net Wed Mar 10 11:29:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10KoXK-0002yG-00; Wed, 10 Mar 1999 11:20:58 -0800 Received: from mmlab.snu.ac.kr [147.46.114.112] by mail1.es.net with esmtp (Exim 1.81 #2) id 10KoXJ-0002y6-00; Wed, 10 Mar 1999 11:20:57 -0800 Received: from sapphire ([147.46.15.59]) by mmlab.snu.ac.kr (8.8.8+Sun/8.8.8) with SMTP id EAA06929 for ; Thu, 11 Mar 1999 04:17:37 +0900 (KST) Message-ID: <000d01be6b2b$43f44400$3b0f2e93@sapphire.snu.ac.kr> From: "Yung Yi" To: Subject: Vic Source Date: Thu, 11 Mar 1999 04:21:57 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BE6B76.B355A500" 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_000A_01BE6B76.B355A500 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGkuDQpJIHdhbnQgdG8ga25vdyB0aGUgc3RydWN0dXJlIG9mIFZpYyBzb3VyY2UuDQoNCklzIHRo ZXJlIGFueW9uZSB3aG8gYW5hbHl6ZSB0aGUgdmljIHNvdXJjZSBhbmQgaGF2ZSB0aGUgZGVzY3Jp cHRpb24gb3IgZXhwbGFuYXRpb24gb2YgdGhhdD8NCg0KSWYgeW91IGtub3cgdGhlIHVybCBvciBo YXZlIHNvbWUgb3RoZXIgZG9jdW1lbnQsIHBsZWFzZSBub3RpZnkgbWUgb2YgdGhhdC4NCg0KVGhh bmsgeW91IHZlcnkgbXVjaC4NCkJ5ZS4NCg== ------=_NextPart_000_000A_01BE6B76.B355A500 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZDhkMGM4 Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IaS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkkgd2FudCB0byBrbm93IHRoZSBzdHJ1Y3R1cmUg b2YgVmljIA0Kc291cmNlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Mj5JcyB0aGVyZSBhbnlvbmUgd2hvIGFuYWx5emUgdGhlIHZpYyBzb3VyY2UgYW5kIA0KaGF2ZSB0 aGUgZGVzY3JpcHRpb24gb3IgZXhwbGFuYXRpb24gb2YgdGhhdD88L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTI+SWYgeW91IGtub3cgdGhlIHVybCBvciBoYXZlIHNvbWUg b3RoZXIgZG9jdW1lbnQsIA0KcGxlYXNlIG5vdGlmeSBtZSBvZiB0aGF0LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5UaGFuayB5b3UgdmVyeSBtdWNoLjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+QnllLjwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000A_01BE6B76.B355A500-- From rem-conf Thu Mar 11 02:13:19 1999 From rem-conf-request@es.net Thu Mar 11 02:13:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10L2Kx-0001hS-00; Thu, 11 Mar 1999 02:05:07 -0800 Received: from olympus.noc.uoa.gr (noc.uoa.gr) [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10L2Kv-0001hI-00; Thu, 11 Mar 1999 02:05:05 -0800 Received: from kissavos.noc.uoa.gr (kissavos.noc.uoa.gr [195.134.100.101]) by noc.uoa.gr (8.8.8/8.8.8) with ESMTP id MAA08494; Thu, 11 Mar 1999 12:04:57 +0200 (EET) Received: from Aragorn (Aragorn.noc.uoa.gr [195.134.90.37]) by kissavos.noc.uoa.gr (8.8.8+Sun/8.8.8) with SMTP id MAA19101; Thu, 11 Mar 1999 12:09:15 +0200 (EET) Message-ID: <001a01be6ba6$cdf6cf80$255a86c3@Aragorn.noc.uoa.gr> From: "Nikos Laoutaris" To: "Remote conf mailing list" , "winsock2 mailing list" Subject: elemedia's IETF RTP stack Date: Thu, 11 Mar 1999 12:06:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01BE6BB7.8DD3AE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0017_01BE6BB7.8DD3AE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all If anyone has/is/plans on working with elemedia's RTP implementation = please contact me so we can cooperate. I am testing it and i have a lot = f problems. Thanks in advance Nikos Laoutaris Network Operations Center National and Kapodestrian University of Athens, Greece e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0017_01BE6BB7.8DD3AE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all
 
If anyone has/is/plans on working with elemedia's = RTP=20 implementation please contact me so we can cooperate. I am testing it = and i have=20 a lot f problems.
 
Thanks in advance
 
Nikos Laoutaris
Network = Operations=20 Center
National and Kapodestrian University of Athens, = Greece
e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0017_01BE6BB7.8DD3AE80-- From rem-conf Thu Mar 11 09:15:53 1999 From rem-conf-request@es.net Thu Mar 11 09:15:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10L8rI-0004Ts-00; Thu, 11 Mar 1999 09:02:56 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10L8rH-0004Ti-00; Thu, 11 Mar 1999 09:02:55 -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 JAA15258; Thu, 11 Mar 1999 09:02:53 -0800 (PST) Message-Id: <3.0.3.32.19990311090253.00ace870@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 11 Mar 1999 09:02:53 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/17 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar An Investigation into Web Site Design Practice Wednesday March 17, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time of the seminar has changed!! Mark Newman Computer Science Division - EECS University of California at Berkeley How can computer systems better support creative processes? Many computer-based tools currently exist to support art and design tasks, but the technology and the need exist to push these capabilities of these tools farther. In the Group for User Interface Research at UC Berkeley, we are undertaking a research project to understand how technology can be used to further assist the web design process, with the ultimate goal of developing tools to support designers. During the first phase of our project, we conducted an informal study involving interviews with professional designers and examination of works-in-progress to improve our understanding of the web design practice in professional settings. In this talk we present the results of our initial investigation, including observations about common and divergent design practices among the organizations studied, and the existence of multiple design specialties which confuse the definition of "web design". 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 Thu Mar 11 10:01:23 1999 From rem-conf-request@es.net Thu Mar 11 10:01:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10L9h4-0005gX-00; Thu, 11 Mar 1999 09:56:26 -0800 Received: from f253.hotmail.com (hotmail.com) [207.82.251.144] by mail1.es.net with smtp (Exim 1.81 #2) id 10L9h3-0005fA-00; Thu, 11 Mar 1999 09:56:25 -0800 Received: (qmail 10723 invoked by uid 65534); 11 Mar 1999 17:55:20 -0000 Message-ID: <19990311175520.10722.qmail@hotmail.com> Received: from 195.53.0.144 by www.hotmail.com with HTTP; Thu, 11 Mar 1999 09:55:19 PST X-Originating-IP: [195.53.0.144] From: "Pedro Revriego" To: rem-conf@es.net Subject: rfc2508 Date: Thu, 11 Mar 1999 09:55:19 PST Mime-Version: 1.0 Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, I am looking for information about rfc 2508 for RTP/UDP/IP header compression over low capacity links : - Products that support this RFC (I have seen Cisco Routers so far). - SW implementations available on the market or shareware. - Performance measures of the algorithm in real scenarios. - etc. I would appreciate any information on this subject. Thanks a lot, Pedro Reviriego Get Your Private, Free Email at http://www.hotmail.com From rem-conf Fri Mar 12 16:07:24 1999 From rem-conf-request@es.net Fri Mar 12 16:07:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10LboJ-0002Va-00; Fri, 12 Mar 1999 15:57:47 -0800 Received: from woodstock.cs.berkeley.edu [128.32.32.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10LboI-0002VQ-00; Fri, 12 Mar 1999 15:57:46 -0800 Received: from woodstock.cs.berkeley.edu (localhost [127.0.0.1]) by woodstock.cs.berkeley.edu (8.8.4/8.6.9) with ESMTP id PAA09334; Fri, 12 Mar 1999 15:58:08 -0800 (PST) Message-Id: <199903122358.PAA09334@woodstock.cs.berkeley.edu> To: Jonathan Rosenberg Cc: rem-conf@es.net Subject: Re: Reed Solomon Draft In-reply-to: Your message of Tue, 10 Nov 1998 14:01:19 EST. <36488D7F.F5F490C1@dnrc.bell-labs.com> From: yuzo@bmrc.berkeley.edu Reply-To: yuzo@bmrc.berkeley.edu X-Return-Receipt-To: yuzo@bmrc.berkeley.edu Date: Fri, 12 Mar 1999 15:58:07 -0800 Sender: yuzo@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear All, I have some comments on draft-ietf-avt-reedsolomon-00.txt. 1) What do you think about adding a flavor of interleaving? If the length of burst packet loss is proportional to bitrate, the protection becomes weak at high bitrate. Increasing of N is a way to strengthen the protection, but complexity also increases. Another way is interleaving, which disperses the consecutive lost packets. By introducing a new parameter S, we easily lengthen a media block while using small numbers of N and K. The step of media packets is defined as 2**S. Thus a media block contains K media packets numbered SN+(2**S)*i where 0<=i Message-Id: <9903121942.ZM11663@eos.ncsu.edu> Date: Fri, 12 Mar 1999 19:42:26 -0500 In-Reply-To: Henning Schulzrinne "US Patent 5870412: Forward error correction system for packet based real time media" (Mar 10, 10:07am) References: <36E68ABF.D9CFA5A4@cs.columbia.edu> X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: Re: US Patent 5870412: Forward error correction system for packet based real time media Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have also recently put together a techreport on FEC-based recovery scheme for interactive video transmission (http://www.csc.ncsu.edu/faculty/rhee/pub/fec2.ps.gz). An extension on my sigcomm'98 paper. The abstract for the paper (for your cursory reading pleasure before you download the monster file -- it is ~1MB, sorry) is as follows: ----------------------------------- Real-time interactive video transmission in the current Internet has mediocre quality because of high packet loss rates. Loss of packets belonging to a video frame manifests itself not only in the reduced quality of that frame but also in the propagation of that distortion to successive frames. This error propagation problem is inherent in any motion-based video codec because of the interdependence of encoded video frames. Since packet losses in the best-effort Internet environment cannot be prevented, minimizing the impact of these packet losses to the final video quality is important. In this paper, we present a new forward error correction (FEC) technique that effectively alleviates error propagation in the transmission of interactive video. The technique is based on our recently developed error recovery scheme called Recovery from Error Spread using Continuous Updates (RESCU). RESCU allows transport level recovery techniques previously known to be infeasible for interactive video transmission applications to be successfully used in such applications. The proposed FEC technique can be very useful when the feedback channel from the receiver is highly limited, or transmission delay is high. Both simulation and Internet experiments indicate that our proposed FEC technique effectively alleviates the error spread problem and is able to sustain much better video quality than H.261 or other conventional FEC schemes under various packet loss rates. Key words: Packet Loss Recovery, Interactive Video, Error Propagation, Forward Error Correction, Video conferencing. On Mar 10, 10:07am, Henning Schulzrinne wrote: > Subject: US Patent 5870412: Forward error correction system for packet bas > http://www.patents.ibm.com/patlist?icnt=US&patent_number=5870412&x=37&y=9 > > On cursory inspection, this may be directly related to some of the > redundancy and FEC work in rem-conf. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >-- End of excerpt from Henning Schulzrinne -- Dr. Injong Rhee Assistant Professor North Carolina State University Raleigh, NC 27695 Email: rhee@csc.ncsu.edu Phone: 919-515-3305 Fax: 919-515-7925 From rem-conf Fri Mar 12 18:17:18 1999 From rem-conf-request@es.net Fri Mar 12 18:17:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10LdwB-0004SJ-00; Fri, 12 Mar 1999 18:14:03 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10Ldw9-0004Ru-00; Fri, 12 Mar 1999 18:14:01 -0800 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Mar 12 21:12:27 EST 1999 Received: from dnrc.bell-labs.com ([135.17.200.55]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA12128; Fri, 12 Mar 1999 21:12:25 -0500 (EST) Message-ID: <36E9C975.21067E52@dnrc.bell-labs.com> Date: Fri, 12 Mar 1999 21:12:05 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: yuzo@bmrc.berkeley.edu CC: rem-conf@es.net Subject: Re: Reed Solomon Draft References: <199903122358.PAA09334@woodstock.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list yuzo@bmrc.berkeley.edu wrote: > > Dear All, > > I have some comments on draft-ietf-avt-reedsolomon-00.txt. > > 1) What do you think about adding a flavor of interleaving? If the > length of burst packet loss is proportional to bitrate, the protection > becomes weak at high bitrate. Increasing of N is a way to strengthen > the protection, but complexity also increases. Another way is > interleaving, which disperses the consecutive lost packets. By > introducing a new parameter S, we easily lengthen a media block while > using small numbers of N and K. The step of media packets is defined > as 2**S. Thus a media block contains K media packets numbered > SN+(2**S)*i where 0<=i as the draft. For interactive apps, this would move the latency for FEC from bad to worse. Of course, for streaming media, its not so bad. Its worth noting that this kind of interleaving is possible in the parity draft, because of the use of the bitmask to indicate the packets that are being covered. I wonder if its perhaps not a bad idea to apply that concept here as well. This would enable the interleaving Yuzo describes for the Reed Solomon as a "freebie". There is also a draft on interleaving of packets (draft-ietf-avt-interleaving-01), but that is something different. It interleaves the regular media packets, and has nothing to do with how FEC is generated. > > 2) In the Reed-Solomon FEC header, representations of (K-1,N-K-1,i) > seems to be better than (N,K,i), because the ranges of N-K-1 and i are > same. Good idea. We could possibly get away with fewer bits this way. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Mar 13 01:53:01 1999 From rem-conf-request@es.net Sat Mar 13 01:53:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Ll0T-0007SQ-00; Sat, 13 Mar 1999 01:46:57 -0800 Received: from 204-129-20.ipt.aol.com (ct1.webquill.com) [152.204.129.20] by mail1.es.net with smtp (Exim 1.81 #2) id 10Ll0Q-0007SG-00; Sat, 13 Mar 1999 01:46:55 -0800 Date: 12/15/98 5:08:53 PM Pacific Daylight Time From: breath@angelfire.com Reply-To:breath@angelfire.com To: breath@angelfire.com Subject: Personal Alcohol Testers (Breathalyzers) Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Personal Alcohol Testers (Breathalyzers) We are pleased to introduce our line of Personal Alcohol Testers (Breathalyzers). Drinking and Driving can be a deadly killer. If you or your loved ones drink, please drink responsibly and use our Personal Alcohol Tester. It could be the difference of life and death. The CheckMan is a portable Alcohol Detector that utilizes a microprocessor to determine the B.A.C. (Blood Alcohol Concentration) levels of intoxication. The microprocessor indicates up to 5 levels of B.A.C. The audio alarm engages when an individual is too intoxicated to drive. The B.A.C. indication levels can be adjusted to different levels of warnings for different countries. The CheckMan uses a single 1.5V AAA battery and has a built in battery replacement indicator. The CheckMan is affordable, compact and super lightweight. The CheckMan is about the size of a pager. The Catch-A is the Key Chain Holder version of the CheckMan. Note: We are accepting commission-based sales representatives and distributors for this innovative and revolutionary product. For additional information and to view pictures of the Personal Alcohol Testers. Please reply to this email with "P.A.T" in your subject heading. (Only serious inquiries) Thank You From rem-conf Sat Mar 13 06:29:41 1999 From rem-conf-request@es.net Sat Mar 13 06:29:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10LpLa-0001bU-00; Sat, 13 Mar 1999 06:25:02 -0800 Received: from cc00du.unity.ncsu.edu [152.1.2.239] by mail1.es.net with esmtp (Exim 1.81 #2) id 10LpLY-0001bI-00; Sat, 13 Mar 1999 06:25:00 -0800 Received: (from rhee@localhost) by cc00du.unity.ncsu.edu (8.8.4/UC02Jan97) id JAA02287; Sat, 13 Mar 1999 09:24:55 -0500 (EST) Date: Sat, 13 Mar 1999 09:24:55 -0500 (EST) From: rhee@unity.ncsu.edu Message-Id: <199903131424.JAA02287@cc00du.unity.ncsu.edu> To: jdrosen@dnrc.bell-labs.com, rem-conf@es.net Subject: Re: Reed Solomon Draft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > For interactive apps, this would move the latency for FEC from bad to > worse. Of course, for streaming media, its not so bad. Its worth noting > that this kind of interleaving is possible in the parity draft, because > of the use of the bitmask to indicate the packets that are being > covered. I wonder if its perhaps not a bad idea to apply that concept > here as well. This would enable the interleaving Yuzo describes for the > Reed Solomon as a "freebie". > -- > 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 > Well, believe it or not, even for interactive video, interleaving (even over the period of 100 - 1000 ms) can be very effective. And this does not introduce any playout latency. It might be very hard to believe.... In our technical report (http://www.csc.ncsu.edu/faculty/rhee/pub/fec2.ps.gz), we present this feasibility. The main idea is that repair FEC packets arriving after the display of their (damaged) protecting frames are still useful to remove errors propagating from those damaged frames. We can use these "late" packets to restore those damaged frames. Since they are used as reference frames for succeeding frames, restoring them removes error spread from them. By doing this, we can improve the received video quality by 3-6dB over the conventional schemes. We performed experiments using real Internet traces and MPEG-4 test video sequences. The similar idea can be applied to retransmission as well. We discuss the retransmission idea in sigcomm98. You can find some more related papers from my web site. We are currently working on making these schemes adaptive to network congestion levels, loss rate, and latency. So, stay tuned..... As soon as we finish writing about it (hopefully within a week), we will put together another techreport. Injong -- Dr. Injong Rhee Assistant Professor North Carolina State University Raleigh, NC 27695 Home page: www.csc.ncsu.edu/faculty/rhee Email: rhee@csc.ncsu.edu Phone: 919-515-3305 Fax: 919-515-7925 From rem-conf Sun Mar 14 01:34:52 1999 From rem-conf-request@es.net Sun Mar 14 01:34:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10M7Ab-0000Fx-00; Sun, 14 Mar 1999 01:26:53 -0800 Received: from meshsv501.tk.mesh.ad.jp [133.205.16.137] by mail1.es.net with esmtp (Exim 1.81 #2) id 10M7AZ-0000Fn-00; Sun, 14 Mar 1999 01:26:51 -0800 Received: from WinProxy (17.san-francisco-03-04rs.ca.dial-access.att.net [12.72.1.17]) by meshsv501.tk.mesh.ad.jp (8.8.8+2.7Wbeta7/3.5Wpl7-98060115) with SMTP id SAA11040; Sun, 14 Mar 1999 18:26:36 +0900 (JST) Message-ID: <008e01be6dfc$a7ca6d00$0200a8c0@willow> Reply-To: "Yuzo Senda" From: "Yuzo Senda" To: Cc: , Subject: RE: Reed Solomon Draft Date: Sun, 14 Mar 1999 01:24:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 >Well, believe it or not, even for interactive video, >interleaving (even over the period of 100 - 1000 ms) can be >very effective. And this does not introduce any playout latency. I understand what you said. That is a case of relatively low bitrate. Current PCs have plenty of both processing power and memory to decode multiple low-bitrate streams. Since the Reed-Solomon stream is sent separately, the interleaving I said does not affect playout latency directly. As you described, advanced decoders may utilize the FEC stream. At high bitrate, the latency induced by the interleaving is negligible. I guess within a few years it will be physically possible to send a program at 1Mbps or more. Yuzo From rem-conf Sun Mar 14 03:55:41 1999 From rem-conf-request@es.net Sun Mar 14 03:55:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10M9Qp-0001Sw-00; Sun, 14 Mar 1999 03:51:47 -0800 Received: from research.gate.nec.co.jp [202.32.8.49] by mail1.es.net with esmtp (Exim 1.81 #2) id 10M9Qn-0001Sg-00; Sun, 14 Mar 1999 03:51:45 -0800 Received: from adam.dsp.cl.nec.co.jp (root@adam.dsp.cl.nec.co.jp [133.207.2.76]) by research.gate.nec.co.jp (8.8.8+2.7Wbeta7/971104) with ESMTP id UAA10232; Sun, 14 Mar 1999 20:51:06 +0900 (JST) Received: from gore.dsp.cl.nec.co.jp by adam.dsp.cl.nec.co.jp (8.8.5+2.7Wbeta5/CL-960412) with SMTP id UAA07806; Sun, 14 Mar 1999 20:51:05 +0900 (JST) Message-Id: <199903141151.UAA07806@adam.dsp.cl.nec.co.jp> To: Yoshihiro Kikuchi cc: Christine Guillemot , Gerald Kuehne , 4onIP-sys <4onIP-sys@fzi.de>, christ , Holger Fahner , wesner , mpeg4_robust , rem-conf@es.net Subject: Re: Ad hoc report + contribution on generic multiplexing In-reply-to: Your message of "Sat, 13 Mar 1999 21:18:38 JST." <01f201be6d4b$dbeefd00$17c77885@kaiji> Date: Sun, 14 Mar 1999 20:50:53 +0900 From: Jiro Katto X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I know most people are away from this reflector until next week, but let me put my personal views. I am sorry if I missed important points discussed on the reflector (especially of Cristine and Gerald). (1) Header duplication (re-synchronization) I don't have any technical objections about where the header duplication is specified, in HEC or in RTP payload format. But let me repeat again, when specified in HEC, it becomes non IP-specific. As Gerald mentioned, I also appreciate the RTP payload format for H261 (quite a great and pioneering standard). But, notice that it can be applied to any error-prone networks (if they are referred to by other network standards). So, I think the header duplication may be specified in a coding standard, if available and avoidable. (2) Channel encoding (network adaptation) I am not sure header duplication is a part of channel encoding. But, generally speaking, I completely agree that the channel encoding should be done by network standards (TransMux, in MPEG4 word). In my humble knowledge, e.g., error correction codes seem to be quite differently specified according to TransMuxes (RTP, TS, H223, etc.). So, I agree with you to let them remain in network standards. (3) Pre-encoding or real-time I am not sure why the pre-encoding becomes a serious problem (although your insight is quite interesting and impressive). It seems free for receivers to save the received streams in a format with or without HECs as long as the stream syntax complies to MPEG4 standard. It seems free for servers to transcode them or insert/remove HECs adaptively. Am I missing something ? (4) Generic payload format I am not yet sure what is a main purpose of the generic payload format. Is it something like a container into which everybody can specify payload formats of any coding standards out of RFC 1890 ? Or something else ? Anyway, I am quite impressed and educated by the discussion on this reflector. Thank you very much for all and I hope both the meetings (MPEG and IETF) will be successfull. Best regards, -- Jiro Katto NEC Corporation. -------------------------------------------------------------------- Kikuchi-san wrote: > > Apologize for my late reply. I hope this not too late. > > I add "mpeg4_robust" to the CC field because I think this issue is > much relevant to the VIDEO error resiliency. > > > > To rely only on the source encoder for resilience against packet > > > losses, may not be sufficient. Also, if this may work with > > > real-time encoding when the encoder can adjust video packets, > > > HEC field content to network conditions, how can this work with > > > pre-encoded streams? Shouldn't this type of application be > > > considered as well? > > > > > > It seems to us that separating source encoding from 'channel > > > encoding' (header duplication) would allow to provide protection > > > (adaptive to network conditions) in both (real-time or non-real > > > time encoding) scenarios. > > > > > > So, please, if there is something wrong with these technical > > > concerns and technical arguments, we would be grateful to hear > > > the TECHNICAL reasons. > > > > I did not read your contribution (M4469 Proposal for a normative ESI) > > because I have no access to the MPEG-ftp yet (Could you send it to me > > by e-mail?)). Maybe you covered in the document some items I am > > going to mention in the following. > > > > I agree with you that it would be the best approach to split error > > resilience information and header duplication from the compression > > layer. > > That means, ideally we would use an RTP payload like the one for > > H.261, where all necessary information for independent decoding > > are given in the RTP header. > > > > However, to achieve this for MPEG-4 video ES poses several problems. > > In contrast to H.261, MPEG-4 video uses enhanced predictive coding. > > Consider for example the coding of the DC coefficients in intra > > macroblocks as it is described in the FDIS: > > > > B C D A, B, C, D, X, Y = 8x8 blocks > > A X Y > > > > The DC coefficient in block X depends on a predictor calculated from > > neighbouring blocks. Block Y depends on a predictor, too. This > > predictor cannot be calculated from X's predictor. The predictor > > concept is also used in AC prediction, motion vector coding and > > shape coding. > > Yes. > > > Therefore, if we want independently decodable units (e.g. a collection > > of macroblocks), we have to provide all necessary predictors (and > > there are many predictors) in an RTP header not to mention > > duplicated header information. > > Yes, this is correct. Is it realy good to have such BIG fields in an RTP > header? > > > It was my understanding that these advanced predictive modes were > > notallowed (or switched off) when we were using the error > > resilient coding modes, is that correct? > > No. Please read the ISO14496-2 carefully. > > >So, can't we imagine that an application (or the application producer/ > >designer) knows that its streams are to be transported on networks > >with non guaranteed QoS. In this case the error resilient modes should > >be used, and the advanced prediction modes switched off, right? > >My point in the previous messages was to say that the nice features > >of error resilient modes, incorporated in the spec., may be in certain > >network conditions not sufficient. Complementary - and definitely > >not conflicting - mechanisms, know in the litterature under the > >name of 'error control' may be necessary. But these error control > >mechanisms are beyond the scope of a source encoder, this is > >the scope of a network adaptation layer or of a channel encoder. > > > In this context the video packet concept is a useful compromise - all > > predictively encoded data is confined within the packet. However, you > > are right, it mixes error resilience with compression aspects. > > >The concept of a video packet is nice, especially the idea of having > >sync makersevery M bits instead of every M macroblocks. Only the > >HEC field incorporates some 'channel coding' in the sense of > >redundant or duplicated data. > >This is ok when having real-time encoding, but may not be the most > >efficient way in the case of off-line encoding :-(. > > I cannot understand why HEC field is a 'channel coding'. > > Just an addition of the duplicated information of the VOP header to the > video bitstream generated without aware of the video packet boundary > does NOT help the decoder at all because there are lots of prediction > signals needed for video decoding, as explained by Gerald. > > That's why the duplication tool is treated in conjunction with Video > coding in MPEG-4. This may be an different manner from the existing > standards, say H.261, but the video coding scheme itself is different. > > I hope that when defining a RTP format, this should really be a media > aware manner. I'm not saying that duplicate information should not be > place in RTP header. But, just a duplication of headers without aware > of video coding will not help anything. > > > Regards, > Yoshihiro > > ---- > Yoshihiro Kikuchi > > E-mail: kiku@eel.rdc.toshiba.co.jp > Research and Development Center Toshiba Corp. > TEL: +81 +44 549 2151 FAX: +81 +44 520 1308 From rem-conf Sun Mar 14 10:49:23 1999 From rem-conf-request@es.net Sun Mar 14 10:49:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10MFs3-0003zo-00; Sun, 14 Mar 1999 10:44:19 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10MFs1-0003zO-00; Sun, 14 Mar 1999 10:44:17 -0800 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Sun Mar 14 13:43:19 EST 1999 Received: from dnrc.bell-labs.com ([135.17.200.60]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA02554; Sun, 14 Mar 1999 13:43:17 -0500 (EST) Message-ID: <36EC0333.5040F6C8@dnrc.bell-labs.com> Date: Sun, 14 Mar 1999 13:42:59 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: rhee@unity.ncsu.edu CC: rem-conf@es.net Subject: Re: Reed Solomon Draft References: <199903131424.JAA02287@cc00du.unity.ncsu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list rhee@unity.ncsu.edu wrote: > > It might be very hard to believe.... In our technical report > (http://www.csc.ncsu.edu/faculty/rhee/pub/fec2.ps.gz), we present this > feasibility. The main idea is that repair FEC packets arriving after the > display of their (damaged) protecting frames are still useful to remove > errors propagating from those damaged frames. We can use these "late" > packets to restore those damaged frames. Since they are used as > reference frames for succeeding frames, restoring them removes > error spread from them. By doing this, we can improve the received video > quality by 3-6dB over the conventional schemes. We performed experiments > using real Internet traces and MPEG-4 test video sequences. Neat idea. The benefit will depend a lot on how good the codec itself is at recovering "naturally". For example, a video sequence with mostly intra macroblocks probably won't benefit much from your approach. There's a cost to this approach too - a significant increase in decoder complexity, since you will need to re-decode the old frames with the updated information. Have you done any studies with speech codecs? I have a report on error recovery for G.729. It basically concluded that error propagation due to encoder/decoder de-synchronization was more significant than the loss of a frame itself, based on both SNR and subjective evaluation. This would be an argument for your approach for speech. You can find a copy of the report at: http://www.cs.columbia.edu/~jdrosen/e6880/index.html -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 Sun Mar 14 11:07:12 1999 From rem-conf-request@es.net Sun Mar 14 11:07:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10MGBa-0004Wp-00; Sun, 14 Mar 1999 11:04:30 -0800 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 10MGBZ-0004We-00; Sun, 14 Mar 1999 11:04:29 -0800 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id OAA21211; Sun, 14 Mar 1999 14:04:25 -0500 (EST) From: "Dr. Injong Rhee" Message-Id: <9903141404.ZM21209@eos.ncsu.edu> Date: Sun, 14 Mar 1999 14:04:25 -0500 In-Reply-To: Jonathan Rosenberg "Re: Reed Solomon Draft" (Mar 14, 1:42pm) References: <199903131424.JAA02287@cc00du.unity.ncsu.edu> <36EC0333.5040F6C8@dnrc.bell-labs.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Jonathan Rosenberg Subject: Re: Reed Solomon Draft Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mar 14, 1:42pm, Jonathan Rosenberg wrote: > Subject: Re: Reed Solomon Draft > rhee@unity.ncsu.edu wrote: > > > > It might be very hard to believe.... In our technical report > > (http://www.csc.ncsu.edu/faculty/rhee/pub/fec2.ps.gz), we present this > > feasibility. The main idea is that repair FEC packets arriving after the > > display of their (damaged) protecting frames are still useful to remove > > errors propagating from those damaged frames. We can use these "late" > > packets to restore those damaged frames. Since they are used as > > reference frames for succeeding frames, restoring them removes > > error spread from them. By doing this, we can improve the received video > > quality by 3-6dB over the conventional schemes. We performed experiments > > using real Internet traces and MPEG-4 test video sequences. > > Neat idea. The benefit will depend a lot on how good the codec itself is > at recovering "naturally". For example, a video sequence with mostly > intra macroblocks probably won't benefit much from your approach. You are absolutely right. If the input video contains fast mocing objects or complete scene change, my RESCU technique does not work well because motion estimation and compensation is not simply effective in this case. However, in a telephony or conferencing case, this would pay off big time. In general, when the video sequence is ameanable to motion estimation, RESCU can work well. > There's a cost to this approach too - a significant increase in decoder > complexity, since you will need to re-decode the old frames with the > updated information. Yes. However, increase in the complexity of decoder part may not be so significant because it has to decode only the missing portion by keeping the old frames in the buffer. > Have you done any studies with speech codecs? I > have a report on error recovery for G.729. It basically concluded that > error propagation due to encoder/decoder de-synchronization was more > significant than the loss of a frame itself, based on both SNR and > subjective evaluation. This would be an argument for your approach for > speech. You can find a copy of the report at: > > http://www.cs.columbia.edu/~jdrosen/e6880/index.html That's interesting. I always thought it would be difficult to apply the idea to speech. I will certianly look into it. Thanks for pointing that out to me. Injong -- Injong Rhee Assistant Professor North Carolina State University Raleigh, NC 27695 Home page: http://www.csc.ncsu.edu/faculty/rhee Email: rhee@csc.ncsu.edu Phone: 919-515-3305 Fax: 919-515-7925 From rem-conf Sun Mar 14 23:41:12 1999 From rem-conf-request@es.net Sun Mar 14 23:41:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10MRu5-0001h4-00; Sun, 14 Mar 1999 23:35:13 -0800 Received: from d06lmsgate.uk.ibm.com (d06lmsgate.emea.ibm.com) [195.212.29.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10MRu3-0001gm-00; Sun, 14 Mar 1999 23:35:11 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d06lmsgate.emea.ibm.com (1.0.0) with ESMTP id HAA98168 for ; Mon, 15 Mar 1999 07:31:24 GMT From: ashour@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v1.8) with SMTP id IAA16426 for ; Mon, 15 Mar 1999 08:32:48 +0100 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id C1256735.002970EC ; Mon, 15 Mar 1999 08:32:38 +0100 X-Lotus-FromDomain: IBMIL@IBMDE To: rem-conf@es.net Message-ID: Date: Mon, 15 Mar 1999 09:32:31 +0200 Subject: Re: RTP mux drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't consider forgetting about RTP mux as 'good' from the following reason: Ignoring standardisation for RTP muxing (mainly for purposes of reducing waste of bandwidth) will not avoid non-standardized implementations by different vendors (since efficient bandwidth requirements are requested by our customers). Ignoring the issue will not affect the existing demand for it (demand that is not going to be reduced - to say the least (at least from my point of view)). I believe that numerous vendor-specific (most likely not interoperable) solutions would be worse than having one standardised solution. A standardised spec will result in a more stable and network-friendly solution, than most of the initiatives by 3rd party vendors will. As a side-kick a standardised spec will allow interoperability which is always a good thing to have. -- Gal. ================================= Gal Ashour ashour@il.ibm.com Audio/Video Technologies Group IBM HRL - Haifa Research Lab ================================= ================================= Robert Wood wrote: I notice most of the RTP mux drafts are expired or expiring. Does this mean we can forget all about this (good). [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ From rem-conf Mon Mar 15 09:56:04 1999 From rem-conf-request@es.net Mon Mar 15 09:56:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10MbMW-0005zU-00; Mon, 15 Mar 1999 09:41:12 -0800 Received: from lri.lri.fr [129.175.15.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10MbMU-0005zK-00; Mon, 15 Mar 1999 09:41:11 -0800 Received: from lri.fr (pc-copri.lri.fr [129.175.13.18]) by lri.lri.fr (8.9.1a/8.9.1) with ESMTP id SAA22026; Mon, 15 Mar 1999 18:41:07 +0100 (MET) Message-ID: <36ED4639.6BA8EF2@lri.fr> Date: Mon, 15 Mar 1999 18:41:14 +0100 From: =?iso-8859-1?Q?kav=E9?= Salamatian X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re Reed Solomon Draft 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 > Dear All, > > I have some comments on draft-ietf-avt-reedsolomon-00.txt. > > 1) What do you think about adding a flavor of interleaving? If the > length of burst packet loss is proportional to bitrate, the protection > becomes weak at high bitrate. Increasing of N is a way to strengthen > the protection, but complexity also increases. Another way is > interleaving, which disperses the consecutive lost packets. By > introducing a new parameter S, we easily lengthen a media block while > using small numbers of N and K. The step of media packets is defined > as 2**S. Thus a media block contains K media packets numbered > SN+(2**S)*i where 0<=i as the draft. Hello, interleaving basically reduce the memory of the loss process. But its performance fade out fast. After a interleaving order of 4 to 5 your interleaved process loss all its memory and became as a memoryless process. If you want to have higher performance you should use stronger MDS codes (by stronger codes I means more lenghty codes). About the complexity of the decoding process it is linear on the number of lost packets, squared on the length of the block and squared on size of the underlying field of the Reed Solomon code. Some faster implementation using discrete Fourier Transform exist who reduce the complexity to Nlog N where N is the size of the code. But there are interesting only for large values of N. Interleaving increase highly the decoding latency but some means can be used to reduce this latency. The idea is to interleave shifted versions of a long block. For example Interleaving matrix 1 2 3 4 5 3 4 5 6 7 5 6 7 8 9 10 11 12 13 14 R1 R3 R5 R7 R9 Redundant packets R2 R4 R6 R8 R10 Sent sequence 1 3 5 10 R1 R2 2 4 6 11 R3 R5 7 12 R6 R7 8 13 R8 R9 9 14 The latency is reduced but the redondance is added. You can easily construct more intelligent interleaving patterns with interesting properties.About interleaving performance and globally about general performance of MDS codes (as Reed Solomon are) over erasure channels with memory we have a report (which is unfortunately in french). You can get it from www.lri.fr/~bouchero/MARS/main.ps.gz Kave Salamatian From rem-conf Mon Mar 15 21:47:45 1999 From rem-conf-request@es.net Mon Mar 15 21:47:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Mmbi-0002md-00; Mon, 15 Mar 1999 21:41:38 -0800 Received: from mail1.radix.net [209.48.224.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Mmbh-0002mT-00; Mon, 15 Mar 1999 21:41:37 -0800 Received: from TheOTG.com (port11.annex7.radix.net [207.226.55.11]) by mail1.radix.net (8.9.1/8.9.1) with ESMTP id PAA28100; Mon, 15 Mar 1999 15:57:07 -0500 (EST) Message-ID: <36ED7508.AFE910B@TheOTG.com> Date: Mon, 15 Mar 1999 16:00:56 -0500 From: "John Weiler, CTO and Founder" Organization: The OBJECTive Technology Group X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: icwg@omg.org Subject: IC Working Group meeting announcement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, The Interoperability Clearinghouse Working Group (ICWG), is holding several industry meetings in the upcoming weeks, hosted by OMG and AFCEA. Those interested in engaging this joint government/ industry initiative should may attend one of the planned ICWG meetings; 1) March 22, OMG Technical Committee Meeting, Wyndham Hotel, Philadelphia (215-448-2000). Open session for all OMG participants :12:00-1:00pm includes lunch and overview briefing. Meeting continues 1:00-4:00pm for working discussions. Evening Session for prospective IC sponsor 5:00-7:00pm Cocktail hour follows. Please register at the OMG registration desk. 2) March 23, 08:00am-12noon. AFCEA Gaithersburg Breakfast Meeting, Hampton Inn, off Rt. 118. Cost $20. Payable to AFCEA. Please RSVP. Limited seating. 3) On-site Brief. If your organization has an large IT shop who would be interested in this effort, the principles would will be glad to set up an on-site brief at your convenience. The primary goal of the Interoperability Clearinghouse will be establish an internet based knowledge repository of IT standards, "validated & interoperable COTS product suites" and associated implementation services. Integration, testing and implementation successes will help validate vendor claims, and enable IT users to configure and validate enterprise information solutions. For more information on this effort, please visit the following Interoperability Clearinghouse URLs; http://www.omg.org/techprocess/meetings/ic.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://www.gcn.com/gcn/1999/February8/1c.htm We look forward to working with you to "making IT happen" for all. Details of how all of this will unfold will be discussed at these meetings. us know if your organization is interested in participating. Best Regards, John ****************************************************** "From Architectures to Reality" 703-768-0400(v) 703-765-9295(f) http://www.TheOTG.com john_weiler@TheOTG.com ********************************************* From rem-conf Tue Mar 16 02:13:07 1999 From rem-conf-request@es.net Tue Mar 16 02:13:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Mqko-0004iY-00; Tue, 16 Mar 1999 02:07:18 -0800 Received: from olympus.noc.uoa.gr (noc.uoa.gr) [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Mqkm-0004iO-00; Tue, 16 Mar 1999 02:07:16 -0800 Received: from kissavos.noc.uoa.gr (kissavos.noc.uoa.gr [195.134.100.101]) by noc.uoa.gr (8.8.8/8.8.8) with ESMTP id MAA28002 for ; Tue, 16 Mar 1999 12:07:13 +0200 (EET) Received: from Aragorn (Aragorn.noc.uoa.gr [195.134.90.37]) by kissavos.noc.uoa.gr (8.8.8+Sun/8.8.8) with SMTP id MAA23189 for ; Tue, 16 Mar 1999 12:11:38 +0200 (EET) Message-ID: <002801be6f94$f02bd540$255a86c3@Aragorn.noc.uoa.gr> From: "Nikos Laoutaris" To: "Remote conf mailing list" Subject: elemedia's IETF RTP stack Date: Tue, 16 Mar 1999 12:08:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01BE6FA5.B3378600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0025_01BE6FA5.B3378600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 In my previous mail i had stated that i am facing problems with the = stack in windows 98. I finally figured out why, the stack needs windows = NT to operate correctly. Thanks=20 Nikos Laoutaris Network Operations Center National and Kapodestrian University of Athens, Greece e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0025_01BE6FA5.B3378600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello
 
    In my previous = mail i had=20 stated that i am facing problems with the stack in windows 98. I finally = figured=20 out why, the stack needs windows NT to operate correctly.
 
Thanks 
 
Nikos Laoutaris
Network = Operations=20 Center
National and Kapodestrian University of Athens, = Greece
e-mail : laoutaris@noc.uoa.gr ------=_NextPart_000_0025_01BE6FA5.B3378600-- From rem-conf Tue Mar 16 09:14:15 1999 From rem-conf-request@es.net Tue Mar 16 09:14:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10MxJF-0000NG-00; Tue, 16 Mar 1999 09:07:17 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10MxJE-0000N6-00; Tue, 16 Mar 1999 09:07:16 -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 JAA06148; Tue, 16 Mar 1999 09:07:15 -0800 (PST) Message-Id: <3.0.3.32.19990316090714.0090cc30@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 16 Mar 1999 09:07:14 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/17 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar An Investigation into Web Site Design Practice Wednesday March 17, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time of the seminar has changed!! Mark Newman Computer Science Division - EECS University of California at Berkeley How can computer systems better support creative processes? Many computer-based tools currently exist to support art and design tasks, but the technology and the need exist to push these capabilities of these tools farther. In the Group for User Interface Research at UC Berkeley, we are undertaking a research project to understand how technology can be used to further assist the web design process, with the ultimate goal of developing tools to support designers. During the first phase of our project, we conducted an informal study involving interviews with professional designers and examination of works-in-progress to improve our understanding of the web design practice in professional settings. In this talk we present the results of our initial investigation, including observations about common and divergent design practices among the organizations studied, and the existence of multiple design specialties which confuse the definition of "web design". 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 Mar 16 13:55:58 1999 From rem-conf-request@es.net Tue Mar 16 13:55:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10N1dO-0002vP-00; Tue, 16 Mar 1999 13:44:22 -0800 Received: from cliff.acs.oakland.edu [141.210.10.111] by mail1.es.net with esmtp (Exim 1.81 #2) id 10N1dN-0002vF-00; Tue, 16 Mar 1999 13:44:21 -0800 Received: from jupiter.acs.oakland.edu (jupiter.acs.oakland.edu [141.210.10.23]) by cliff.acs.oakland.edu (8.8.8/8.8.8) with ESMTP id QAA32655; Tue, 16 Mar 1999 16:44:19 -0500 (EST) Received: (from srodawa@localhost) by jupiter.acs.oakland.edu (8.6.9/8.6.9) id QAA14462; Tue, 16 Mar 1999 16:48:13 -0500 From: srodawa Message-Id: <199903162148.QAA14462@jupiter.acs.oakland.edu> Subject: DVI audio player location. To: rem-conf@es.net Date: Tue, 16 Mar 1999 16:48:12 -0500 (EST) Cc: srodawa@cliff.acs.oakland.edu (Ron Srodawa) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am trying to attend the IETF MBONE sessions. VIC and WB reception is just fine. AUdio is being sent in DVI format and VAT won't accept it. Is there an easy solution to this--either a "plugin" to VAT or another audio player? Thanks for your help. Ron. | Ronald J. Srodawa | Internet: srodawa@oakland.edu | | School of Engineering and CS | Voice: (248) 370-2247 | | Oakland University | FAX: (248) 370-4625 | | Rochester, Michigan 48309-4478 | | From rem-conf Tue Mar 16 18:42:30 1999 From rem-conf-request@es.net Tue Mar 16 18:42:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10N6BS-0005NV-00; Tue, 16 Mar 1999 18:35:50 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10N6BR-0005NL-00; Tue, 16 Mar 1999 18:35:49 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 17 Mar 1999 02:35:43 +0000 To: srodawa cc: rem-conf@es.net, srodawa@cliff.acs.oakland.edu (Ron Srodawa) Subject: Re: DVI audio player location. In-reply-to: Your message of "Tue, 16 Mar 1999 16:48:12 EST." <199903162148.QAA14462@jupiter.acs.oakland.edu> Date: Wed, 17 Mar 1999 02:35:41 +0000 Message-ID: <1594.921638141@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> srodawa writes: >I am trying to attend the IETF MBONE sessions. VIC and WB reception is just >fine. AUdio is being sent in DVI format and VAT won't accept it. Is there >an easy solution to this--either a "plugin" to VAT or another audio player? Both vat and rat accept DVI format audio. If you're using vat, ensure that the -r option is specified on the command line to make it understand RTP. Colin From rem-conf Tue Mar 16 20:57:01 1999 From rem-conf-request@es.net Tue Mar 16 20:57:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10N8KP-0006VR-00; Tue, 16 Mar 1999 20:53:13 -0800 Received: from anchor.cs.colorado.edu [128.138.242.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10N8KO-0006V7-00; Tue, 16 Mar 1999 20:53:12 -0800 Received: from anchor.cs.colorado.edu (evi@localhost.cs.colorado.edu [127.0.0.1]) by anchor.cs.colorado.edu (8.9.3/8.9.2) with ESMTP id VAA05956; Tue, 16 Mar 1999 21:51:39 -0700 (MST) Message-Id: <199903170451.VAA05956@anchor.cs.colorado.edu> To: srodawa cc: rem-conf@es.net, srodawa@cliff.acs.oakland.edu (Ron Srodawa) Subject: Re: DVI audio player location. Date: Tue, 16 Mar 1999 21:51:39 -0700 From: Evi Nemeth X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list thats wierd, vat is generating the dvi. dont know why he wouldnt accept it. i guess we could switch to pcm if it would help you. -evi From rem-conf Wed Mar 17 12:15:50 1999 From rem-conf-request@es.net Wed Mar 17 12:15:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10NMR4-0004mH-00; Wed, 17 Mar 1999 11:57:02 -0800 Received: from imo19.mx.aol.com [198.81.17.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 10NMR2-0004kS-00; Wed, 17 Mar 1999 11:57:00 -0800 Received: from TECemail@aol.com by imo19.mx.aol.com (IMOv19.3) id 3VWa005011 for ; Wed, 17 Mar 1999 14:55:56 -0500 (EST) From: TECemail@aol.com Message-ID: <9224984.36f008cc@aol.com> Date: Wed, 17 Mar 1999 14:55:56 EST To: Rem-Conf@es.net Mime-Version: 1.0 Subject: The Education Coalition (TEC) Newsletter! Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: AOL 3.0.1 for Mac sub 85 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Welcome to The Education Coalition (TEC) Newsletter! We are very excited a= bout initiating an update to keep our business associates, and partners informe= d about our activities in educational technology and distributed learning. F= or further information visit our website at TECWeb.org or call us at 949-369-3867. TEC Newsletter March 1999 Contents: TEC headquarters relocates to Southern California The move is completed ! TEC=92s corporate headquarters is unpacked and se= ttled in beautiful San Clemente, California, on the coast midpoint between San D= iego and Los Angeles. ( Address: 31 Segovia, San Clemente, California tel: 949-369-3867) You will hear the friendly voice of Kathleen Bail, office administrator, answering the phones in San Clemente; Donna LoBue, operating TEC in the Ba= y area, can be reached at 925-691-5650. VTEC selected as developer for TEC Personal Learning Model Providing course material in a student=92s preferred learning style offers quicker, better learning with a higher retention rate. The question becom= es how to ascertain learning styles for online courses. To meet this need, TE= C is developing the Personal Learning Model, (PLM), an online learning styles/ multiple intelligences (LS/MI) assessment that will determine a student=92= s preferred learning style and secondary learning modes. The PLM is not a "paper-and-pencil" type test; rather it will be a series= of tasks and problems to solve in a virtual environment. The responses will = be tracked and built into a LS/MI profile. The profile is tagged, stored in = a data base, and passed to an online course so material can be presented in = the preferred learning style. After issuing an RFP, TEC has selected the Virtual Technology Education Center (VTEC) from the South Orange County Community College District (SOC= CCD) in California to develop the PLM using Asymetrix software. PLM adheres t= o the EDUCAUSE/Information Management System (IMS) standards, and utilizes object-oriented, reusable learning objects. TEC is currently accepting applicants to be BETA testers for the software.= If you are interested in participating in this milestone project, call the TE= C office for more details. Training =9299 in Chicago TEC, represented by Dr. Carla Lane and Joanne Carle-Accornero, presented = to approximately 125 people in the Windy City on February 3rd. Topics of discussion were an overview of learning styles, addressing learning style= s through technology, the Advanced Distributed Learning (ADL) initiative, an= d the how to assess learning styles online. The San Bernardino Student and Teacher Excellence Project (STEP) San Bernardino is one of the few areas in the US chosen to offer its stud= ents accelerated science and math programs based on material from NASA. This engaging program enables students to communicate with astronauts and learn complex math and science concepts by solving problems based on actual NASA space travel issues. San Bernardino is committed to providing total educational improvement through the integration of staff development, curriculum development, home access, evaluation and technology/ infrastructure support. TEC is delighte= d to have been selected as the evaluator of this innovative program with its winning use of technology in the classroom. TeleCon East and TeleCon West TEC has again been selected to produce the TeleCon East (Washington, DC, March) and TeleCon West (Anahaim, CA, Oct ) conferences. These are super- charged shows that feature bleeding-edge technologies, new as well as sophisticated users, educators, business people and government representatives, all focused on using technology to enhance learning. Tele= Con East is being held from March 17 through March 19th at the Marriott Wardma= n Park Hotel in Washington, DC. We hope to see you at the TEC Breakout sessions on Thursday, March 18th ,= in the Virginia C Conference Room from noon through 5:15 PM ! Web-based instruction offered through TEC With an already FULL schedule, how can one keep up with the constant and r= apid changes in the distributed learning field? Try a TEC online course specifically designed for the busy professional! Facilitated by Dr. Lane and Joanne Carle-Accornero, developers and instruc= tors for numerous online programs including UCLA and UC Berkeley, the followin= g courses are currently being offered: Introduction to Distributed Learning - 15 hours - asynchronous online an= d audio conferencing - $59 Using Technology to Address Learning Styles - 15 hours - asynchronous online and audio-conferencing- $59 The textbook for the courses is Guide to Teleconferencing and Distance Learning, 3rd Edition, co-authored by Dr. Carla Lane, which is available through Amazon.com. Course sections will have limited enrollments! For more information and to enroll, call 949-369-3867. TECWeb.org Tel: 949-369-3867 Fax: 949-369-3865 From rem-conf Wed Mar 17 16:24:38 1999 From rem-conf-request@es.net Wed Mar 17 16:24:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10NQXU-0007gT-00; Wed, 17 Mar 1999 16:19:56 -0800 Received: from mail1.radix.net [209.48.224.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 10NQXS-0007gJ-00; Wed, 17 Mar 1999 16:19:54 -0800 Received: from TheOTG.com (port9.annex7.radix.net [207.226.55.9]) by mail1.radix.net (8.9.3/8.9.3) with ESMTP id LAA27973; Wed, 17 Mar 1999 11:57:20 -0500 (EST) Message-ID: <36EFDFDD.2375A698@TheOTG.com> Date: Wed, 17 Mar 1999 12:01:17 -0500 From: "John Weiler, CTO and Founder" Organization: The OBJECTive Technology Group X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: icwg@omg.org Subject: Corrected Dates - IC Working Group meetings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>>>>>>>>>>>>>>>>Please note the corrected dates below: Dear Colleagues, The Interoperability Clearinghouse Working Group (ICWG), is holding several industry meetings in the upcoming weeks, hosted by OMG and AFCEA. Those interested in engaging this joint government/ industry initiative should may attend one of the planned ICWG meetings; 1) Wednesday, March 24, OMG Technical Committee Meeting, Wyndham Hotel, Philadelphia (215-448-2000). Open session for all OMG participants :12:00-1:00pm includes lunch and overview briefing. Meeting continues 1:00-4:00pm for working discussions. Evening Session for prospective IC sponsors 5:00-7:00pm Cocktail hour follows. Please register at the OMG registration desk. (Guest price for OMG meeting day is $50). 2) Thursday, March 25, 08:00am-12noon. AFCEA Gaithersburg Breakfast Meeting, Hampton Inn, off Rt. 118. Cost $20. Payable to AFCEA. Limited seating. Please RSVP to James M. Robinette, james.robinette@hq.doe.gov 3) On-site Brief. If your organization has an large IT shop who would be interested in this effort, the principles would will be glad to set up an on-site brief at your convenience. The primary goal of the Interoperability Clearinghouse will be establish an internet based knowledge repository of IT standards, "validated & interoperable COTS product suites" and associated implementation services. Integration, testing and implementation successes will help validate vendor claims, and enable IT users to configure and validate enterprise information solutions. For more information on this effort, please visit the following Interoperability Clearinghouse URLs; http://www.omg.org/techprocess/meetings/ic.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://www.gcn.com/gcn/1999/February8/1c.htm We look forward to working with you to "making IT happen" for all. Details of how all of this will unfold will be discussed at these meetings. us know if your organization is interested in participating. Best Regards, John ****************************************************** "From Architectures to Reality" 703-768-0400(v) 703-765-9295(f) http://www.TheOTG.com john_weiler@TheOTG.com ********************************************* -- ********************************************* "From Architectures to Reality" John A. Weiler CTO & Founder, The OBJECTive Technology Group Ombudsman, Interoperability Clearinghouse Coalition 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) Interoperability Clearinghouse URLs; http://www.omg.org/techprocess/meetings/ic.html http://www.infoworld.com/cgi-bin/displayStory.pl?981113.whsoft.htm http://www.fcw.com/pubs/fcw/1999/0208/fcw-newsinterop-2-8-99.html http://www.gcn.com/gcn/1999/February8/1c.htm john_weiler@TheOTG.com ********************************************* From rem-conf Thu Mar 18 03:08:33 1999 From rem-conf-request@es.net Thu Mar 18 03:08:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10NaVa-0005ZZ-00; Thu, 18 Mar 1999 02:58:38 -0800 Received: from smtp1.gte.net [207.115.153.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10NaVY-0005Yj-00; Thu, 18 Mar 1999 02:58:36 -0800 Received: from two (1Cust124.tnt2.long-beach.ca.da.uu.net [208.255.162.124]) by smtp1.gte.net with SMTP id EAA21619; Thu, 18 Mar 1999 04:55:32 -0600 (CST) Date: Thu, 18 Mar 1999 04:55:32 -0600 (CST) From: 2ygo@gte.net Message-Id: <199903181055.EAA21619@smtp1.gte.net> To: abctech@gte.net Subject: You have been invited X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are invited! Now for the first time ever you have the opportunity to join the most extraordinary and most powerful wealth-building program in the world! Because of your desire to succeed, you have been given the opportunity to take a closer look at this program. If you're skeptical, that's ok. Just make the call and see for yourself. My job is to inform you. Your job is to make your own decision. If you Didn't Make $200,000 Last Year... You owe it to yourself and to your family to give our program Serious Consideration! Also, when you start making this kind of money within weeks, after joining our team, you will actually learn how you can preserve it and how to strategically to invest it! I invite you to call me for more details at 1-800-636-6773 Ext 4848. This is a free 2 minute recording, so call right now! Prosperous regards, Mary Shearer This is Not Multi-level Marketing. Please, Serious Inquiries Only! This is a one time mailing. When you visited one of our web pages you indicated that you would be interested in this information If not, please excuse the intrusion. Thank you. Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter can not be considered spam as long as we include: Contact information See above The way to be removed from future mailings for free: simply e-mail us at LgdInc@mymail.com and respond with "REMOVE" in the subject line. This will permanently remove you from all future mailings us. All future mailings from other e-mail addresses must be dealt with separetely. From rem-conf Thu Mar 18 15:00:14 1999 From rem-conf-request@es.net Thu Mar 18 15:00:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Nlby-0000yL-00; Thu, 18 Mar 1999 14:49:58 -0800 Received: from f186.hotmail.com (hotmail.com) [207.82.251.75] by mail1.es.net with smtp (Exim 1.81 #2) id 10Nlbx-0000xj-00; Thu, 18 Mar 1999 14:49:57 -0800 Received: (qmail 23742 invoked by uid 0); 18 Mar 1999 22:48:56 -0000 Message-ID: <19990318224856.23741.qmail@hotmail.com> Received: from 208.195.157.90 by www.hotmail.com with HTTP; Thu, 18 Mar 1999 14:48:56 PST X-Originating-IP: [208.195.157.90] From: "Neal Schneider" To: rem-conf@es.net Cc: nschneid@hotmail.com Subject: Unique RTP Sessions Date: Thu, 18 Mar 1999 14:48:56 PST Mime-Version: 1.0 Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In a situation with gateways there can be many unique RTP sessions established between them. In general, are RTP sessions uniquely identified via distinct UDP ports? Or is there a single UDP port opened for all RTP traffic, with other unique identifiers? I realize this is application specific, but am curious as to what is currently popular. Regards, Neal A. Schneider ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rem-conf Thu Mar 18 19:38:27 1999 From rem-conf-request@es.net Thu Mar 18 19:38:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Nq2E-0006Z5-00; Thu, 18 Mar 1999 19:33:22 -0800 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Nq2D-0006Yv-00; Thu, 18 Mar 1999 19:33:22 -0800 Received: from junior.it.hq.nasa.gov (dialup55.remote.hq.nasa.gov [131.182.97.155]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id WAA04918; Thu, 18 Mar 1999 22:33:16 -0500 (EST) Message-Id: <3.0.32.19990318223934.0068a398@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 18 Mar 1999 22:39:37 -0500 To: mbone@ISI.EDU, rem-conf@es.net From: "Ellery D. Coleman" Subject: NASA - Workplace Health Surveillance/Maintenance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NASA HQ will be mulitcasting the 2nd of a series of discussions on the topic of "Workplace Health Surveillance/Maintenance" tomorrow (3.19.99) >from 9:30am-12:00pm EST. The session will feature speakers Vladimir Subbotin and Albert Nechaev (Moscow, Russia) and Jun-Yao Li (Beijing, China) via the NASA HQ Video Teleconferencing facility. I would greatly appreciate if some of you could tune in and send email with reguards to the quality of video and audio you're receiving. Thanks in Advance!, o-> el Session Info: Title: NASA - Workplace Health Surveillance/Maintenance Video: 224.2.235.72:59348 Audio: 224.2.235.72:17274 From rem-conf Thu Mar 18 20:38:21 1999 From rem-conf-request@es.net Thu Mar 18 20:38:19 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10Nqzu-0003q4-00; Thu, 18 Mar 1999 20:35:02 -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 10Nqzs-0003pm-00; Thu, 18 Mar 1999 20:35:00 -0800 Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id EAA01021; Fri, 19 Mar 1999 04:33:06 GMT Received: from dwillispc3 ([166.44.154.154]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990319043332.BKZS20027@dwillispc3>; Thu, 18 Mar 1999 22:33:32 -0600 From: "Dean Willis" To: "Neal Schneider" , Subject: RE: Unique RTP Sessions Date: Thu, 18 Mar 1999 22:31:47 -0600 Message-ID: <000101be71c1$669acb40$9a9a2ca6@dwillispc3> 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: <19990318224856.23741.qmail@hotmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would say that in practice RTP sessions are uniquely identified by the "socket", that is, the double tuple of the host IP Addresses and associated port numbers at each end, or {(IP1,PN1),(IP2,PN2)} So, the session from 10.1.1.1 port 3456 to host 172.16.1.2 port 4692 would be identified by the socket {(10.1.1.1,3456),(172.16.1.2)}. That way, the IP demux layer can hand incoming packets to the right process. For reference, I like Richard Steven's "TCP/IP Illustrated, Volume 1". It's getting a bit dated, but is a good read, and Stevens is a personable fellow who used to be quite handy at answering questions on usenet group comp.protocols.tcpip. Quoting from RFC1889 (RTP spec) --- Port: The "abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers." [3] The transport selectors (TSEL) used by the OSI transport layer are equivalent to ports. RTP depends upon the lower-layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session. --- And also: --- In RTP, multiplexing is provided by the destination transport address (network address and port number) which define an RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium should be carried in a separate RTP session with its own destination transport address. It is not intended that the audio and video be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different payload types but using the same SSRC would introduce several problems. . . --- Note that there is in general also an associated RTCP socket, occupying by default the next higher-numbered port on each machine. Also note that there is an ongoing discussion on how to combine multiple RTP streams onto one socket using a additional multiplexing protocol that allows extraction of the individual streams. -- Dean > -----Original Message----- > From: Neal Schneider [mailto:nschneid@hotmail.com] > Sent: Thursday, March 18, 1999 4:49 PM > To: rem-conf@es.net > Cc: nschneid@hotmail.com > Subject: Unique RTP Sessions > > > In a situation with gateways there can be many unique RTP sessions > established between them. In general, are RTP sessions uniquely > identified via distinct UDP ports? Or is there a single UDP > port opened > for all RTP traffic, with other unique identifiers? I > realize this is > application specific, but am curious as to what is currently popular. > > Regards, > Neal A. Schneider > > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From rem-conf Thu Mar 18 21:57:44 1999 From rem-conf-request@es.net Thu Mar 18 21:57:42 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10NsDa-0004Nn-00; Thu, 18 Mar 1999 21:53:14 -0800 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 10NsDY-0004Nd-00; Thu, 18 Mar 1999 21:53:12 -0800 Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id FAA08932; Fri, 19 Mar 1999 05:48:26 GMT Received: from dwillispc3 ([166.44.154.154]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990319055134.BMSK20027@dwillispc3>; Thu, 18 Mar 1999 23:51:34 -0600 From: "Dean Willis" To: "Dean Willis" , "Neal Schneider" , Subject: RE: Unique RTP Sessions, oops Date: Thu, 18 Mar 1999 23:49:45 -0600 Message-ID: <001101be71cc$4a8d64c0$9a9a2ca6@dwillispc3> 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: <000101be71c1$669acb40$9a9a2ca6@dwillispc3> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You know, it's really embarassing when I screw up while lecturing. Especially when the audience has already forgotten more than I will ever know. The: > would be identified by the socket {(10.1.1.1,3456),(172.16.1.2)}. should look more like: {(10.1.1.1,3456),(172.16.1.2,4692)} The port number of the destination end is rather important . . . -- Dean > -----Original Message----- > From: Dean Willis [mailto:Dean.Willis@mci.com] > Sent: Thursday, March 18, 1999 10:32 PM > To: Neal Schneider; rem-conf@es.net > Subject: RE: Unique RTP Sessions > > > > I would say that in practice RTP sessions are uniquely > identified by the > "socket", that is, the double tuple of the host IP Addresses and > associated port numbers at each end, or {(IP1,PN1),(IP2,PN2)} > > So, the session from 10.1.1.1 port 3456 to host 172.16.1.2 port 4692 > would be identified by the socket {(10.1.1.1,3456),(172.16.1.2)}. > > That way, the IP demux layer can hand incoming packets to the right > process. For reference, I like Richard Steven's "TCP/IP Illustrated, > Volume 1". It's getting a bit dated, but is a good read, and > Stevens is > a personable fellow who used to be quite handy at answering > questions on > usenet group comp.protocols.tcpip. > > Quoting from RFC1889 (RTP spec) > --- > Port: The "abstraction that transport protocols use to > distinguish among > multiple destinations within a given host computer. TCP/IP protocols > identify ports using small positive integers." [3] The transport > selectors (TSEL) used by the OSI transport layer are equivalent to > ports. RTP depends upon the lower-layer protocol to provide some > mechanism such as ports to multiplex the RTP and RTCP packets of a > session. > --- > > And also: > --- > In RTP, multiplexing is provided by the destination transport address > (network address and port number) which define an RTP session. For > example, in a teleconference composed of audio and video media encoded > separately, each medium should be carried in a separate RTP > session with > its own destination transport address. It is not intended > that the audio > and video be carried in a single RTP session and > demultiplexed based on > the payload type or SSRC fields. Interleaving packets with different > payload types but using the same SSRC would introduce several > problems. > . . > --- > > Note that there is in general also an associated RTCP socket, > occupying > by default the next higher-numbered port on each machine. > > Also note that there is an ongoing discussion on how to > combine multiple > RTP streams onto one socket using a additional multiplexing protocol > that allows extraction of the individual streams. > > -- > Dean > > > -----Original Message----- > > From: Neal Schneider [mailto:nschneid@hotmail.com] > > Sent: Thursday, March 18, 1999 4:49 PM > > To: rem-conf@es.net > > Cc: nschneid@hotmail.com > > Subject: Unique RTP Sessions > > > > > > In a situation with gateways there can be many unique RTP sessions > > established between them. In general, are RTP sessions uniquely > > identified via distinct UDP ports? Or is there a single UDP > > port opened > > for all RTP traffic, with other unique identifiers? I > > realize this is > > application specific, but am curious as to what is > currently popular. > > > > Regards, > > Neal A. Schneider > > > > > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com > > > > From rem-conf Fri Mar 19 01:47:31 1999 From rem-conf-request@es.net Fri Mar 19 01:47:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Nvnb-0005H1-00; Fri, 19 Mar 1999 01:42:39 -0800 Received: from daffy.ee.lbl.gov [131.243.1.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Nvna-0005Gr-00; Fri, 19 Mar 1999 01:42:38 -0800 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA08526; Fri, 19 Mar 1999 01:42:37 -0800 (PST) Message-Id: <199903190942.BAA08526@daffy.ee.lbl.gov> To: rem-conf@es.net Subject: clarification on IPR issues Cc: sob@harvard.edu Date: Fri, 19 Mar 1999 01:42:37 PST From: Vern Paxson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My comments at this week's meeting regarding IPR issues weren't quite right. In particular, it's possible for a document to advance on the standards track if no reply is received from an alleged rights holder regarding licensing. I've appended the relevant section from RFC 2026. Vern 10.3.2. Standards Track Documents (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. Where implementations are required before advancement of a specification, only implementations that have, by statement of the implementors, taken adequate steps to comply with any such rights, or claimed rights, shall be considered for the purpose of showing the adequacy of the specification. (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights. (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification. From rem-conf Fri Mar 19 08:32:27 1999 From rem-conf-request@es.net Fri Mar 19 08:32:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O24h-0004XS-00; Fri, 19 Mar 1999 08:24:43 -0800 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10O244-0004R6-00; Fri, 19 Mar 1999 08:24:04 -0800 Received: from el (Ellery.it.hq.nasa.gov [131.182.119.58]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id LAA03968; Fri, 19 Mar 1999 11:23:42 -0500 (EST) Message-Id: <3.0.32.19990319112044.009d0100@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Mar 1999 11:20:44 -0500 To: mbone@ISI.EDU, rem-conf@es.net From: "Ellery D. Coleman" Subject: LIVE: NASA - Workplace Health Surveillance/Maintenance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ============== Short version: ============== All, please tune in to the session listed below: Title: NASA - Workplace Health Surveillance/Maintenance Video: 224.2.235.72:59348 Audio: 224.2.235.72:17274 Any comments on quality of reception will be greatly appreciated. o-> el ============== Long version: ============== NASA HQ is currently mulitcasting the 2nd of a series of discussions on the topic of "Workplace Health Surveillance/Maintenance". This discussion is estimated to run >from 9:30am-12:00pm EST. The session features speakers Vladimir Subbotin and Albert Nechaev (Moscow, Russia) and Jun-Yao Li (Beijing, China) via the NASA HQ Video Teleconferencing facility. I would greatly appreciate if some of you could tune in and send email with reguards to the quality of video and audio you're receiving. Thanks in Advance!, o-> el Session Info: Title: NASA - Workplace Health Surveillance/Maintenance Video: 224.2.235.72:59348 Audio: 224.2.235.72:17274 From rem-conf Fri Mar 19 10:17:33 1999 From rem-conf-request@es.net Fri Mar 19 10:17:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O3jn-0007Aa-00; Fri, 19 Mar 1999 10:11:15 -0800 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10O3jm-0007AQ-00; Fri, 19 Mar 1999 10:11:14 -0800 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id SAA07726; Fri, 19 Mar 1999 18:10:47 GMT Received: from mbaugher-desk.jf.intel.com (mbaugher-desk.jf.intel.com [192.198.161.123]) by ideal.jf.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with SMTP id KAA17415; Fri, 19 Mar 1999 10:10:46 -0800 (PST) From: mbaugher@intel.com Message-Id: <199903191810.KAA17415@ideal.jf.intel.com> Sender: "Mark Baugher" To: "'Neal Schneider'" , Subject: RE: Unique RTP Sessions Date: Fri, 19 Mar 1999 10:10:40 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <19990318224856.23741.qmail@hotmail.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi >From RFC 1889: RTP session: The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses plus a common port pair. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. Synchronization source (SSRC): The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera, or an RTP mixer (see below). A synchronization source may change its data format, e.g., audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session (see Section 8). A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session; the binding of the SSRC identifiers is provided through RTCP (see Section 6.4.1). If a participant generates multiple streams in one RTP session, for example from separate video cameras, each must be identified as a different SSRC. Mark > -----Original Message----- > From: Neal Schneider [mailto:nschneid@hotmail.com] > Sent: Thursday, March 18, 1999 2:49 PM > To: rem-conf@es.net > Cc: nschneid@hotmail.com > Subject: Unique RTP Sessions > > > In a situation with gateways there can be many unique RTP sessions > established between them. In general, are RTP sessions uniquely > identified via distinct UDP ports? Or is there a single UDP > port opened > for all RTP traffic, with other unique identifiers? I > realize this is > application specific, but am curious as to what is currently popular. > > Regards, > Neal A. Schneider > > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > From rem-conf Fri Mar 19 10:42:28 1999 From rem-conf-request@es.net Fri Mar 19 10:42:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O4Bq-0000Yv-00; Fri, 19 Mar 1999 10:40:14 -0800 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 10O4Bn-0000WS-00; Fri, 19 Mar 1999 10:40:12 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.9.3/8.9.3) with SMTP id TAA21032 for ; Fri, 19 Mar 1999 19:39:10 +0100 (MET) Received: from localhost by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA28993; Fri, 19 Mar 1999 19:39:10 +0100 Date: Fri, 19 Mar 1999 19:39:10 +0100 (MET) From: Christian Isnard - CERN IT/IA To: rem-conf MBONE List Subject: CERN MBone Announcement: Next LEPC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LEPC Open Session ================= 24 March 1999 Place: CERN Main Auditorium *** Times are UTC+1 *** LEP machine report: 09:00 - 09:30 Summary of the 1999 Chamonix Workshop (Roger Bailey) LEP2 physics jamboree: 09:30 - 10:10 DELPHI (Niels Kjaer) 10:10 - 10:50 L3 (Gerjan Bobbink) 10:50 - 11:20 Coffee Break 11:20 - 12:00 OPAL (Douglas Glenzinski) 12:00 - 12:40 ALEPH (Fabiola Gianotti) LEP2 workshop report: 12:40 - 13:00 Summary of the LEP2 Monte Carlo Workshop (Roberto Pittau) The broadcast is announced via sdr as "CERN LEPC". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact: multicast@noc.cern.ch From rem-conf Fri Mar 19 10:44:55 1999 From rem-conf-request@es.net Fri Mar 19 10:44:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O4GA-0000p4-00; Fri, 19 Mar 1999 10:44:42 -0800 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 10O4G9-0000nN-00; Fri, 19 Mar 1999 10:44:41 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.9.3/8.9.3) with SMTP id TAA24267 for ; Fri, 19 Mar 1999 19:43:40 +0100 (MET) Received: from localhost by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA11702; Fri, 19 Mar 1999 19:43:39 +0100 Date: Fri, 19 Mar 1999 19:43:39 +0100 (MET) From: Christian Isnard - CERN IT/IA To: rem-conf MBONE List Subject: CERN MBone Announcement: Next LHCC Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LHCC Open Session ================= 25 March 1999 Place: CERN Main Auditorium *** Times are UTC+1 *** 09.00-09.40 TOTEM Proposal: Total Cross Section, Elastic Scattering and Diffraction Dissociation at the LHC (G. Matthiae) 09.40-10.20 MOEDAL Letter of Intent: A search for highly ionizing particles and slow exotic decays at the LHC (J. Pinfold) 10.20-10.45 COFFEE BREAK 10.45-12.00 ATLAS Technical Co-ordination TDR (F. Butin, M. Hatch, B. Nicquevert) 12.00-12.45 ALICE Photon Spectrometer TDR (V. Manko) 12.45-13.15 ALICE Zero-Degree Calorimeter TDR (M. Gallio) The broadcast is announced via sdr as "CERN LHCC". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact: multicast@noc.cern.ch From rem-conf Fri Mar 19 11:16:40 1999 From rem-conf-request@es.net Fri Mar 19 11:16:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O4iG-0002vA-00; Fri, 19 Mar 1999 11:13:44 -0800 Received: from sgi1.exa.unicen.edu.ar [170.210.115.2] by mail1.es.net with smtp (Exim 1.81 #2) id 10O4hu-0002n2-00; Fri, 19 Mar 1999 11:13:40 -0800 Received: from exa.unicen.edu.ar by sgi1.exa.unicen.edu.ar via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id QAA27144; Fri, 19 Mar 1999 16:13:22 -0300 Sender: grigotti@sgi1.exa.unicen.edu.ar Message-ID: <36F2A0FC.6B00A5F@exa.unicen.edu.ar> Date: Fri, 19 Mar 1999 16:09:48 -0300 From: Gillermo Rigotti Organization: UNICEN X-Mailer: Mozilla 4.06 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: rem-conf@es.net Subject: Mixers, translator and routers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have a question about the functionality required in routers to support mixers and translators. Some RTCP packets are received and processed by mixers and translators, this packets can be modified and send. The original ones must not be propagated (for example a translator converting encodings). If we are using multicast, the router directly connected to the host where translator resides must not propagate that packets. Is necessary to modify router functionality to avoid propagation? (assuming the case translators are placed dynamically in funcion of characteristics of sets of receivers, so they can't be statically configured). Many Thanks M Guillermo Rigotti ISISTAN Research Institute Universidad Nacional del Centro de la Provincia de Buenos Aires Campus Universitario - Paraje Arroyo Seco - Tandil - 7000 Buenos Aires - Argentina Home: +54 (2293) 440824 Work: +54 (2293) 440363 e-mail: grigotti@exa.unicen.edu.ar From rem-conf Fri Mar 19 15:36:09 1999 From rem-conf-request@es.net Fri Mar 19 15:36:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10O8eo-0001Er-00; Fri, 19 Mar 1999 15:26:26 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10O8ef-0001Di-00; Fri, 19 Mar 1999 15:26:20 -0800 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Fri Mar 19 18:24:05 EST 1999 Received: from dnrc.bell-labs.com ([135.17.200.52]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA24286; Fri, 19 Mar 1999 18:24:00 -0500 (EST) Message-ID: <36F2DC82.A35AD976@dnrc.bell-labs.com> Date: Fri, 19 Mar 1999 18:23:46 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Gillermo Rigotti CC: rem-conf@es.net Subject: Re: Mixers, translator and routers References: <36F2A0FC.6B00A5F@exa.unicen.edu.ar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I think the assumption is that the mixer/translator is involved in two different sessions. For a translator, media comes in from one session, gets translated, and goes into another session. Similar for a mixer. Since these are different sessions, the RTCP packets from one won't be part of the other. If the different sessions are on the same group, but different ports, the packets will be forwarded but not processed by hosts in the other session. No explicit support is needed in routers for translators or mixers. -Jonathan R. Gillermo Rigotti wrote: > > Hi, > > I have a question about the functionality required in routers to support > > mixers and translators. > Some RTCP packets are received and processed by mixers and translators, > this packets can > be modified and send. The original ones must not be propagated (for > example a translator converting > encodings). If we are using multicast, the router directly connected to > the host where translator resides must not propagate that packets. > Is necessary to modify router functionality to avoid propagation? > (assuming the case translators > are placed dynamically in funcion of characteristics of sets of > receivers, so they can't be statically configured). > > Many Thanks > > M Guillermo Rigotti > ISISTAN Research Institute > Universidad Nacional del Centro de la Provincia de Buenos Aires > Campus Universitario - Paraje Arroyo Seco - Tandil - 7000 > Buenos Aires - Argentina > Home: +54 (2293) 440824 Work: +54 (2293) 440363 > e-mail: grigotti@exa.unicen.edu.ar -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Mar 20 22:59:58 1999 From rem-conf-request@es.net Sat Mar 20 22:59:57 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10Oc4O-00008H-00; Sat, 20 Mar 1999 22:50:48 -0800 Received: from ip41.moorestown.nj.pub-ip.psi.net ([38.14.101.41] helo=server2525) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 10Oc4K-00007s-00; Sat, 20 Mar 1999 22:50:45 -0800 To: From: Subject: AD:Family Reunion T Shirts & More Date: Sun, 21 Mar 1999 01:45:19 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info Bill Kuppler Graphics From rem-conf Mon Mar 22 02:40:51 1999 From rem-conf-request@es.net Mon Mar 22 02:40:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10P1zM-0000cK-00; Mon, 22 Mar 1999 02:31:20 -0800 Received: from hakea.cs.ntu.edu.au [138.80.116.6] (malcolm) by mail1.es.net with esmtp (Exim 1.81 #2) id 10P1zJ-0000cA-00; Mon, 22 Mar 1999 02:31:18 -0800 Received: (from malcolm@localhost) by hakea.cs.ntu.edu.au (8.8.8/8.8.8) id UAA06301 for rem-conf@es.net; Mon, 22 Mar 1999 20:01:05 +0930 (CST) Date: Mon, 22 Mar 1999 20:01:05 +0930 From: Malcolm Caldwell To: rem-conf@es.net Subject: mrouted 3.8 for Sparc Linux Message-ID: <19990322200105.A6259@hakea.cs.ntu.edu.au> Mail-Followup-To: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I have a redhat 5.2 system running on a Sparc box with a Linux 2.2.1 kernel. I am having heaps of problems compiling mrouted for this box. I have tried many ways to get around the problem. I have tried the patches for 3.8 as mentioned in /usr/src/linux/Documentation/networking I have tried following instructions on the page (somewhere) that was supposed to help. (It mentions using headers from tcpdump) I keep getting to the point where it says that vif.c: In function `dump_vifs': vif.c:1373: `SIOCGETVIFCNT' undeclared (first use in this function) vif.c:1373: (Each undeclared identifier is reported only once vif.c:1373: for each function it appears in.) make: *** [vif.o] Error 1 This is an ioctl: ... if (ioctl(igmp_socket, SIOCGETVIFCNT, (char *)&v_req) < 0) { ... I can not find this defined anywhere in /usr/include I am at my wits end - can anyone help?? From rem-conf Mon Mar 22 13:53:38 1999 From rem-conf-request@es.net Mon Mar 22 13:53:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PCVQ-00032t-00; Mon, 22 Mar 1999 13:45:08 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10PCVP-00032j-00; Mon, 22 Mar 1999 13:45:07 -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 NAA25667; Mon, 22 Mar 1999 13:45:05 -0800 (PST) Message-Id: <3.0.3.32.19990322134505.00ad2330@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 22 Mar 1999 13:45:05 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/31 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar How did IP Multicast Get So Complicated? Wednesday March 31, 1999 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) To understand where IP Multicast looks like it's going, you need to have some understanding of PIM-DM, PIM-SM, MSDP, BGMP, MBGP, MZAP, MADCAP, AAP and MASC. And that's before you even consider anything at the transport or application layers. It is not surprising then that people have started to question the underlying assumptions about what problem we are attempting to solve, and alternative proposals such as Express and "Simple Multicast" have recently been proposed. In this talk I will try to go through the evolution of IP multicast, explaining briefly how these protocols work and how they fit together. I'll also touch on the two proposed alternatives and explain why I believe the "traditional" approach is still desirable despite the additional mechanism needed to support it. No prior knowledge of multicast routing or address allocation will be assumed. 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 Mon Mar 22 14:11:16 1999 From rem-conf-request@es.net Mon Mar 22 14:11:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PCt9-0003dA-00; Mon, 22 Mar 1999 14:09:39 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10PCsq-0003WP-00; Mon, 22 Mar 1999 14:09:20 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01138; Mon, 22 Mar 1999 17:07:38 -0500 (EST) Message-Id: <199903222207.RAA01138@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-fec-05.txt Date: Mon, 22 Mar 1999 17:07:33 -0500 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-05.txt Pages : 19 Date : 19-Mar-99 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-fec-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-fec-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990319182910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990319182910.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Mar 22 19:09:33 1999 From rem-conf-request@es.net Mon Mar 22 19:09:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PHWI-00028Z-00; Mon, 22 Mar 1999 19:06:22 -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 10PHWH-00028L-00; Mon, 22 Mar 1999 19:06:21 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.3/8.9.3) with ESMTP id MAA05397 for ; Tue, 23 Mar 1999 12:05:32 +0900 (JST) Message-Id: <199903230305.MAA05397@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: mrouted 3.8 for Sparc Linux In-reply-to: Your message of "Mon, 22 Mar 1999 20:01:05 +0930." <19990322200105.A6259@hakea.cs.ntu.edu.au> Date: Tue, 23 Mar 1999 12:05:31 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > vif.c: In function `dump_vifs': > vif.c:1373: `SIOCGETVIFCNT' undeclared (first use in this function) > vif.c:1373: (Each undeclared identifier is reported only once > vif.c:1373: for each function it appears in.) > make: *** [vif.o] Error 1 > > This is an ioctl: > ... > if (ioctl(igmp_socket, SIOCGETVIFCNT, (char *)&v_req) < 0) { > ... > > I can not find this defined anywhere in /usr/include on RedHat-5.2/intel I can find /usr/include/linux/mroute.h and it contains "#define SIOCGETVIFCNT ...". I suppose RedHat-5.2/sparc is the same. BTW is your mrouted 3.8? try compile mrouted-3.9-beta3. and there is mrouted-3.9-beta3-snmp (-: see or . cmu-snmp library used in this version (taken from mrouted-3.8-snmp) looks very old and not support linux, but adjusting the sources not difficult, I think, if you have enough time. or how about importing newer cmu-snmp or ucsd-snmp library? -- yozo. From rem-conf Tue Mar 23 05:34:18 1999 From rem-conf-request@es.net Tue Mar 23 05:34:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PR4N-0006yY-00; Tue, 23 Mar 1999 05:18:11 -0800 Received: from (seeyes.seeyes.co.in) [202.54.67.82] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10PR4J-0006yO-00; Tue, 23 Mar 1999 05:18:08 -0800 Received: from seeyes.co.in ([10.1.5.146]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id TAA32586 for ; Tue, 23 Mar 1999 19:00:33 +0530 Message-ID: <36F797F6.43C96B13@seeyes.co.in> Date: Tue, 23 Mar 1999 19:02:38 +0530 From: Venkata Narasimha Murthy Nanduri Reply-To: nvnmurthy@seeyes.co.in Organization: SeeYes X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Reg. RTP header compression/decompression Content-Type: multipart/mixed; boundary="------------54DECA406C4ACB758F650F9E" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------54DECA406C4ACB758F650F9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hai, Can you please let me know whether any sample code for RTP header compression/decompression exists anywhere in the net? Any algorithm available for this purpose? I have gone through the RFC2508 and RFC1144. Any suggestions/help is appreciated.. Thanks in advance Murthy NVN -- ------------------------------------- Venkata Narasimha Murthy Nanduri, Software Engineer, SeeYes Network Technologies Pvt. Ltd H-4, DD Colony, Bagh Amberpet, Hyderabad, Andhra Pradesh, India - 500 013 Office : 91-40-760 7842 Home : 91-40-712 3437 Fax : 91-40-761 2860 ------------------------------------- --------------54DECA406C4ACB758F650F9E Content-Type: text/x-vcard; charset=us-ascii; name="nvnmurthy.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Venkata Narasimha Murthy Nanduri Content-Disposition: attachment; filename="nvnmurthy.vcf" begin:vcard n:Nanduri;Venkata Narasimha Murthy tel;fax:91-40-761 2860 tel;home:91-40-712 3437 tel;work:91-40-760 7842 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:nvnmurthy@seeyes.co.in x-mozilla-cpt:;-8368 fn:Murthy NVN end:vcard --------------54DECA406C4ACB758F650F9E-- From rem-conf Tue Mar 23 05:34:18 1999 From rem-conf-request@es.net Tue Mar 23 05:34:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PR7z-00070d-00; Tue, 23 Mar 1999 05:21:55 -0800 Received: from (seeyes.seeyes.co.in) [202.54.67.82] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10PR7v-0006zR-00; Tue, 23 Mar 1999 05:21:52 -0800 Received: from seeyes.co.in ([10.1.5.146]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id TAA32655 for ; Tue, 23 Mar 1999 19:03:38 +0530 Message-ID: <36F798B0.8168C2C@seeyes.co.in> Date: Tue, 23 Mar 1999 19:05:44 +0530 From: Venkata Narasimha Murthy Nanduri Reply-To: nvnmurthy@seeyes.co.in Organization: SeeYes X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Reg. RTP Header compression and Decompression Content-Type: multipart/mixed; boundary="------------168AB91AEF8030FD62ABFEB9" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------168AB91AEF8030FD62ABFEB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hai, In the RFC2508, it has been mentioned that RFC1144 has to be taken as the base for RTP Header compression/decompression. Can any of U please tell me how I can proceed/modify the code given in RFC1144? Thanks in advance Murthy NVN -- ------------------------------------- Venkata Narasimha Murthy Nanduri, Software Engineer, SeeYes Network Technologies Pvt. Ltd H-4, DD Colony, Bagh Amberpet, Hyderabad, Andhra Pradesh, India - 500 013 Office : 91-40-760 7842 Home : 91-40-712 3437 Fax : 91-40-761 2860 ------------------------------------- --------------168AB91AEF8030FD62ABFEB9 Content-Type: text/x-vcard; charset=us-ascii; name="nvnmurthy.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Venkata Narasimha Murthy Nanduri Content-Disposition: attachment; filename="nvnmurthy.vcf" begin:vcard n:Nanduri;Venkata Narasimha Murthy tel;fax:91-40-761 2860 tel;home:91-40-712 3437 tel;work:91-40-760 7842 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:nvnmurthy@seeyes.co.in x-mozilla-cpt:;-8368 fn:Murthy NVN end:vcard --------------168AB91AEF8030FD62ABFEB9-- From rem-conf Tue Mar 23 09:41:55 1999 From rem-conf-request@es.net Tue Mar 23 09:41:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10PV76-0003MT-00; Tue, 23 Mar 1999 09:37:16 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10PV75-0003LY-00; Tue, 23 Mar 1999 09:37:16 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Mar 1999 17:36:42 +0000 To: rem-conf@es.net Subject: Slides from the Minneapolis AVT meeting Date: Tue, 23 Mar 1999 17:36:41 +0000 Message-ID: <29034.922210601@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've started to make a collection of the presentation slides from the AVT meeting in Minneapolis which is available on the web at http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/ Could all those who presented please send me a copy of their slides so I can include them here and in the minutes. Cheers, Colin From rem-conf Thu Mar 25 08:10:48 1999 From rem-conf-request@es.net Thu Mar 25 08:10:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10QCX1-0001NN-00; Thu, 25 Mar 1999 07:58:55 -0800 Received: from hkusua.hku.hk [147.8.2.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 10QCX0-0001ND-00; Thu, 25 Mar 1999 07:58:54 -0800 Received: from localhost (h9608112@localhost) by hkusua.hku.hk (8.9.1/8.9.1) with ESMTP id XAA12631 for ; Thu, 25 Mar 1999 23:59:54 +0800 (HKT) Date: Thu, 25 Mar 1999 23:59:49 +0800 (HKT) From: Ngai Tsz Man To: rem-conf@es.net Subject: Vic problem In-Reply-To: <199902230934.KAA24956@chico.rediris.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I have installed Linux RedHat in my PC and I have a capture card with chipset Bt878 and I want to do video conferencing with them using Vic. Is it possible ? I know there is a project called Video4Linux that has driver for my captuer card but what else do I need ? Thank you very much ! Tom From rem-conf Thu Mar 25 08:10:52 1999 From rem-conf-request@es.net Thu Mar 25 08:10:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10QCbz-0001Ov-00; Thu, 25 Mar 1999 08:04:03 -0800 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 10QCby-0001Ol-00; Thu, 25 Mar 1999 08:04:02 -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 IAA21175; Thu, 25 Mar 1999 08:03:59 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id IAA09874 for ; Thu, 25 Mar 1999 08:03:58 -0800 (PST) Date: Thu, 25 Mar 1999 08:03:58 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199903251603.IAA09874@jackson.cs.ucsb.edu> To: almeroth@jackson.cs.ucsb.edu Cc: ksarac@jackson.cs.ucsb.edu Subject: sdr-monitor effort X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Based on some of the feedback we received at the IETF we have modified the sdr-monitor WWW pages to add a new look for the GLOBAL sessions. http://imj.ucsb.edu/sdr-monitor/global/ This page has a matrix of red/green showing reachability for GLOBAL sessions and sdr-monitor participants. The original idea was suggested by Bill Fenner. This type of format has proven quite valuable. For example, if a whole COLUMN is red then the sdr-monitor participant is likely having local problems. If a whole ROW is red (there has to be at least one green since someone has to see the session) this suggests the sdr-monitor participant is advertising a session but the outside world cannot see it. In any case, take a look at the page and send us any suggestions. And as always, if you are interested in participating in the effort, send me email... it is very simple. You'll be expected to add some tcl/tk code to your sdr.tcl file. BTW, if you aren't running sdr, you can't participate at this time... that's the only mechanism we have to collecting session information. -Kevin Almeroth & Kamil Sarac From rem-conf Thu Mar 25 09:47:47 1999 From rem-conf-request@es.net Thu Mar 25 09:47:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10QEAN-0003Sv-00; Thu, 25 Mar 1999 09:43:39 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10QEAM-0003Sl-00; Thu, 25 Mar 1999 09:43:38 -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 JAA02592; Thu, 25 Mar 1999 09:43:37 -0800 (PST) Message-Id: <3.0.3.32.19990325094336.00ae5100@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 25 Mar 1999 09:43:36 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/31 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar How did IP Multicast Get So Complicated? Wednesday March 31, 1999 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) To understand where IP Multicast looks like it's going, you need to have some understanding of PIM-DM, PIM-SM, MSDP, BGMP, MBGP, MZAP, MADCAP, AAP and MASC. And that's before you even consider anything at the transport or application layers. It is not surprising then that people have started to question the underlying assumptions about what problem we are attempting to solve, and alternative proposals such as Express and "Simple Multicast" have recently been proposed. In this talk I will try to go through the evolution of IP multicast, explaining briefly how these protocols work and how they fit together. I'll also touch on the two proposed alternatives and explain why I believe the "traditional" approach is still desirable despite the additional mechanism needed to support it. No prior knowledge of multicast routing or address allocation will be assumed. 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 Fri Mar 26 03:18:31 1999 From rem-conf-request@es.net Fri Mar 26 03:18:30 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10QUZ3-0002bp-00; Fri, 26 Mar 1999 03:14:13 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10QUZ2-0002b4-00; Fri, 26 Mar 1999 03:14:13 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Mar 1999 11:13:49 +0000 To: rem-conf@es.net Subject: Re: Slides from the Minneapolis AVT meeting In-reply-to: Your message of "Tue, 23 Mar 1999 17:36:41 GMT." <29034.922210601@cs.ucl.ac.uk> Date: Fri, 26 Mar 1999 11:13:47 +0000 Message-ID: <1047.922446827@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Colin Perkins writes: >I've started to make a collection of the presentation slides from the AVT >meeting in Minneapolis which is available on the web at > http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/ >Could all those who presented please send me a copy of their slides so I >can include them here and in the minutes. All the slides presented in AVT are now online at the above URL, with the exception of Jon Crowcroft's presentation where there doesn't exist an electronic copy. Colin From rem-conf Fri Mar 26 18:50:23 1999 From rem-conf-request@es.net Fri Mar 26 18:50:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Qj5Z-0001aP-00; Fri, 26 Mar 1999 18:44:45 -0800 Received: from ppp2038.on.bellglobal.com (mail.mia.machine) [206.172.235.118] by mail1.es.net with smtp (Exim 1.81 #2) id 10Qj5S-0001ZY-00; Fri, 26 Mar 1999 18:44:38 -0800 From: Subject: HUMAN GROWTH HORMONES AD Date: Sun, 4 Apr 1999 09:30:54 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Human Growth Hormones Available Now Without a Prescription Biggest Medical Breakthrough in Anti-Aging in the 20th Century Human Growth Hormone is a naturally occurring substance secreted by the pituitary gland, and our bodies age because the pituitaries production of human growth hormones decreases with age. The production of Human Growth Hormones helps to slow down, and in some cases even reverse the aging process. Best of all, there are "no know side effects" when taken in the proper amounts. Over 1000 doctors that attended the Anti-Aging conference in December agreed that Human Growth Hormones is one of the "most exciting advancements in reversing the disease of aging," since the introduction of DHEA. Traditionally, Human Growth Hormone has been used in Europe and the United States for approximately 15 years with amazing results. It has previously been available by injection only, and since injections by doctors costs between $5,000 and $20,000 a year, only the wealthy were able to afford these treatment. Now everyone can afford and receive the benefits of Human Growth Hormones. Now it is available for less than $100 per month in a handy application that you can spray under your tongue. Some of the benefits you will receive from using Human Growth Hormones are: A more youthful skin and hair appearance. Increased mental alertness. Increased strength and muscle mass. Increased feeling of well being. Decreased wrinkling. Increased sexual function. Increased stamina and energy. Decreased body fat. Improved neurological function. Rejuvenation of all cell and organ tissue. If you are interested in improving your quality of life, have an overall feeling of well being, then call 1-800-955-5553 to order your Human Growth Hormones. Call within 24 hours of receiving this letter and get a free gift from Advanced Labs. to be removed e mail coolguy74@eastmail.com From rem-conf Tue Mar 30 09:42:20 1999 From rem-conf-request@es.net Tue Mar 30 09:42:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10S2Go-0007Ym-00; Tue, 30 Mar 1999 09:25:46 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10S2Gn-0007Yc-00; Tue, 30 Mar 1999 09:25:45 -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 JAA15556; Tue, 30 Mar 1999 09:25:44 -0800 (PST) Message-Id: <3.0.3.32.19990330092543.00ad28f0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Mar 1999 09:25:43 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 3/31 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar How did IP Multicast Get So Complicated? Wednesday March 31, 1999 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) To understand where IP Multicast looks like it's going, you need to have some understanding of PIM-DM, PIM-SM, MSDP, BGMP, MBGP, MZAP, MADCAP, AAP and MASC. And that's before you even consider anything at the transport or application layers. It is not surprising then that people have started to question the underlying assumptions about what problem we are attempting to solve, and alternative proposals such as Express and "Simple Multicast" have recently been proposed. In this talk I will try to go through the evolution of IP multicast, explaining briefly how these protocols work and how they fit together. I'll also touch on the two proposed alternatives and explain why I believe the "traditional" approach is still desirable despite the additional mechanism needed to support it. No prior knowledge of multicast routing or address allocation will be assumed. 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 Mar 30 12:07:59 1999 From rem-conf-request@es.net Tue Mar 30 12:07:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10S4iu-0001ZA-00; Tue, 30 Mar 1999 12:02:56 -0800 Received: from helios.cstp.umkc.edu [134.193.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 10S4il-0001Yv-00; Tue, 30 Mar 1999 12:02:50 -0800 Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id OAA06110; Tue, 30 Mar 1999 14:02:16 -0600 (CST) Date: Tue, 30 Mar 1999 14:02:16 -0600 (CST) From: Eun Kyo Park Message-Id: <199903302002.OAA06110@helios.cstp.umkc.edu> To: atm@sun.COM, members@farnet.ORG, nren-discuss@psi.COM, rem-conf@es.NET, wireless@tandem.COM Subject: ICCCN99 CFP X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------------------------------------------------------------------------ (This cfp appeared in the CACM and IEEE Computer magazines, Feb. 1999 issues. Note that conference dates have been changed slightly - by one day!!) ------------------------------------------------------------------------------ IEEE IC3N'99 CALL FOR PAPERS EIGHTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 11 -- 13, 1999, Crowne Plaza Hotel Boston - Natick, Massachusetts, USA Sponsored by IEEE Communication Society (tech. co-sponsor), NOKIA and Army Research Office. In Cooperation with The Center For Telecommunications Studies-USL and Computer Science Telecommunications-UMKC (pending approval of sponsorships/in cooperations) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results. The topics include, but are not limited to: Optical Communication Networks Wireless/Mobile/Satellite Comm Networks ATM Networking Internet Services/Applications Wireless Multimedia Applications Real-time Communications Quality of Services (QoS) Issues LAN/WAN Internetworking Network Interoperability Personal Communication Services Network Control Management Broadband Networks Intelligent Networks Multicast and Routing Protocols Network Security Media Access Control/Mobility Algorithms Network Reliability High Speed Network OAM/Protocols Video-on-Demand Data Traffic Engineering Network Management/Billing Global Infrastructure Network Evolution Multimedia Human-Machine Interface Performance Modeling/Analysis Communication Software Protocol Design/Validation/Testing Networked Databases Network Architectures Terabit optical switching/routing architectures and signaling SUBMISSION: Authors are invited to submit complete and original papers. Papers that may be submitted should not have been previously published in another forum, or are not currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a submission as long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (go to the end of this CFP for more information; ps or pdf format is preferred). Six copies of the manuscript should be submitted by Friday, May 14, 1999 to either of the program co-chairs: Dr. Sudhir S. Dixit Professor Arun K. Somani Nokia Research Center Dept of Electrical and Computer Eng 3 Burlington Woods Drive Iowa State University Burlington, MA 01803-4514, USA 3227 Coover Hall, Ames, IA, 50011-3060 sudhir.dixit@research.nokia.com arun@iastate.edu (781)238-4915; (781)359-5196(fax) (515) 294-0442; (515) 294-8432(fax) IMPORTANT DATES: Paper submission deadline : May 14, 1999 Notification of acceptance: July 16, 1999 Camera ready papers due : August 16, 1999 WORKSHOPS and TUTORIALS: Proposals are solicited for organizing workshops and tutorials. Please send your proposals by April 24, 1999 to one of the General Chairs, Prof. Niki Pissinou}, Center For Advanced Computer Studies, University of Southwestern Louisiana, Lafayette, LA 70504, USA, pissinou@cacs.usl.edu, Tel: (318) 482- 6604, Fax:(318) 482-6604 or Prof. Kia Makki, Center for Telecommunications Studies, University of Southwestern Louisiana, Lafayette, LA 70504, USA, kia@usl.edu}, Tel: (318) 482-5872, Fax: (318) 482-6687. For all other information please contact Prof. E. K. Park, Computer Science and Telecommunications Program, University of Missouri, 4747 Troost Ave, Room 207, Kansas City, MO 64110 USA, ekpark@cstp.umkc.edu, Tel: (816) 235-1497, Fax: (816) 235-5159 or send email to ic3n@cacs.usl.edu. General Chairs: Kia Makki, USL and N. Pissinou, USL Program Chairs: S. Dixit, NOKIA and A. Somani, ISU Registration Chair: E. K. Park, U. of Missouri More information about the conference: www.icccn99.cstp.umkc.edu We are currently setting up electronic paper submission procedures (will be ready soon), so please visit ICCCN99 web site www.icccn99.cstp.umkc.edu for more up-to-date information !! From rem-conf Tue Mar 30 12:46:47 1999 From rem-conf-request@es.net Tue Mar 30 12:46:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10S5Nb-0002Su-00; Tue, 30 Mar 1999 12:44:59 -0800 Received: from helios.cstp.umkc.edu [134.193.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 10S5NV-0002Sk-00; Tue, 30 Mar 1999 12:44:53 -0800 Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id OAA06946; Tue, 30 Mar 1999 14:34:33 -0600 (CST) Date: Tue, 30 Mar 1999 14:34:33 -0600 (CST) From: Eun Kyo Park Message-Id: <199903302034.OAA06946@helios.cstp.umkc.edu> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, kia@usl.edu, multicomm@cc.bellcore.com, osimcast@bbn.com, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca Subject: ICCCN99 CFP X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------------------------------------------------------------------------ (This cfp appeared in the CACM and IEEE Computer magazines, Feb. 1999 issues. Note that conference dates have been changed slightly - by one day!!) ------------------------------------------------------------------------------ IEEE IC3N'99 CALL FOR PAPERS EIGHTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 11 -- 13, 1999, Crowne Plaza Hotel Boston - Natick, Massachusetts, USA Sponsored by IEEE Communication Society (tech. co-sponsor), NOKIA and Army Research Office. In Cooperation with The Center For Telecommunications Studies-USL and Computer Science Telecommunications-UMKC (pending approval of sponsorships/in cooperations) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results. The topics include, but are not limited to: Optical Communication Networks Wireless/Mobile/Satellite Comm Networks ATM Networking Internet Services/Applications Wireless Multimedia Applications Real-time Communications Quality of Services (QoS) Issues LAN/WAN Internetworking Network Interoperability Personal Communication Services Network Control Management Broadband Networks Intelligent Networks Multicast and Routing Protocols Network Security Media Access Control/Mobility Algorithms Network Reliability High Speed Network OAM/Protocols Video-on-Demand Data Traffic Engineering Network Management/Billing Global Infrastructure Network Evolution Multimedia Human-Machine Interface Performance Modeling/Analysis Communication Software Protocol Design/Validation/Testing Networked Databases Network Architectures Terabit optical switching/routing architectures and signaling SUBMISSION: Authors are invited to submit complete and original papers. Papers that may be submitted should not have been previously published in another forum, or are not currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a submission as long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (go to the end of this CFP for more information; ps or pdf format is preferred). Six copies of the manuscript should be submitted by Friday, May 14, 1999 to either of the program co-chairs: Dr. Sudhir S. Dixit Professor Arun K. Somani Nokia Research Center Dept of Electrical and Computer Eng 3 Burlington Woods Drive Iowa State University Burlington, MA 01803-4514, USA 3227 Coover Hall, Ames, IA, 50011-3060 sudhir.dixit@research.nokia.com arun@iastate.edu (781)238-4915; (781)359-5196(fax) (515) 294-0442; (515) 294-8432(fax) IMPORTANT DATES: Paper submission deadline : May 14, 1999 Notification of acceptance: July 16, 1999 Camera ready papers due : August 16, 1999 WORKSHOPS and TUTORIALS: Proposals are solicited for organizing workshops and tutorials. Please send your proposals by April 24, 1999 to one of the General Chairs, Prof. Niki Pissinou}, Center For Advanced Computer Studies, University of Southwestern Louisiana, Lafayette, LA 70504, USA, pissinou@cacs.usl.edu, Tel: (318) 482- 6604, Fax:(318) 482-6604 or Prof. Kia Makki, Center for Telecommunications Studies, University of Southwestern Louisiana, Lafayette, LA 70504, USA, kia@usl.edu}, Tel: (318) 482-5872, Fax: (318) 482-6687. For all other information please contact Prof. E. K. Park, Computer Science and Telecommunications Program, University of Missouri, 4747 Troost Ave, Room 207, Kansas City, MO 64110 USA, ekpark@cstp.umkc.edu, Tel: (816) 235-1497, Fax: (816) 235-5159 or send email to ic3n@cacs.usl.edu. General Chairs: Kia Makki, USL and N. Pissinou, USL Program Chairs: S. Dixit, NOKIA and A. Somani, ISU Registration Chair: E. K. Park, U. of Missouri More information about the conference: www.icccn99.cstp.umkc.edu We are currently setting up electronic paper submission procedures (will be ready soon), so please visit ICCCN99 web site www.icccn99.cstp.umkc.edu for more up-to-date information !! From rem-conf Wed Mar 31 04:32:23 1999 From rem-conf-request@es.net Wed Mar 31 04:32:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10SK6O-0000pn-00; Wed, 31 Mar 1999 04:28:12 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10SK6M-0000pd-00; Wed, 31 Mar 1999 04:28:10 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id C07CE4CE14; Wed, 31 Mar 1999 07:28:08 -0500 (EST) Received: from pcbasso.research.att.com (nsl-dialup6.research.att.com [135.207.140.133]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id HAA00760; Wed, 31 Mar 1999 07:28:00 -0500 (EST) Message-ID: <007a01be7b71$ee425cc0$858ccf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: , , , Subject: Packet Video '99 Workshop - New York 26-27 April 1999 Date: Wed, 31 Mar 1999 07:27:59 -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 Registration for the Packet Video '99 Workshop New York 26-27 April 1999 is now open. Please visit http://www.research.att.com/~mrc/PacketVideo99.html for more information. Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf Wed Mar 31 08:15:32 1999 From rem-conf-request@es.net Wed Mar 31 08:15:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10SNZk-0003HS-00; Wed, 31 Mar 1999 08:10:44 -0800 Received: from qhars002.nortelnetworks.com (qhars002.nortel.com) [192.100.101.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 10SNZj-0003HI-00; Wed, 31 Mar 1999 08:10:43 -0800 Received: from nnsgifd1.europe.nortel.com (actually 47.137.131.66) by qhars002.nortel.com; Wed, 31 Mar 1999 17:02:56 +0100 Received: by nnsgifd1.europe.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 Mar 1999 17:02:57 +0100 Message-ID: <391D82D86F58D111B8250000F805C4D0023526EF@bhari886.europe.nortel.com> From: "Graeme Gibbs" To: "'rem-conf@es.net'" Cc: "Rade Gvozdanovic" , "Rajakulasingam Raviraj" , "'Chaoxin.Qiu@mail.sprint.com'" Subject: Additional Named Signal Events Date: Wed, 31 Mar 1999 17:02:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Orig: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To whoever is editting/championing "RTP Payloads for Telephone Signal Events" Firstly I have not been following the mailing list so apologies if this topic is old & cold. Basically I believe this draft would benefit from the addition of 2 extra Named Signal Events ie 2100Hz tones (ITU G.164)& 2100Hz tone with Phase reversals (ITU G.165) Rationale: These tones, while not used by traditional TDM switches per se, are used by echo cancellers within the TDM network to turn off echo cancellation for calls carrying modems & faxes. Certain carriers may wish to build telephony over IP transit networks, where, at least initially, modem/faxes are carried transparently as G.711 (64kbit/s) packets over IP (yes I know this amounts to data over voice over data, but it may be some period before all gateways support all modulation techniques, and carriers must provide equivalence to current Public Switched Telephone Network from Day 1). Modems/faxes sending such tones would expect both the intervening IP network and prior/subsequent echo cancellers in PSTN to moderate their behaviour accordingly. Take a scenario where the VOIP gateways are running voice calls as compressed to G.729, with silence suppression and echo cancellation, and such a 2100Hz tone is detected The local GW must: Upspeed to 64 kbit/s & turn off silence suppression, and echo cancellation The remote GW must also: Upspeed to 64 kbit/s & turn off silence suppression, and echo cancellation The tone must be propagated back into the PSTN by remote GW 2100Hz tones will not reliably propagate through G.729, therefore if the system relied on passing this tone in-band, the near-end modem would have to detect tone , decide to upspeed (maybe local CAC decisions), and then execute upspeeding before far end GW can begin to detect tones in the stream >from the IP network- this may take too long. This method also relies on codec that can receive one codec type and transmit in another (desirable BUT not always the case) However if the near-end GW were to send a Named Signal Event once it had detected the tone, this would allow CAC and upspeeding to occur in parallel, together with a correct tone being enforced to the PSTN Any replies, please mail direct to me as I do not subscribe to avt list From rem-conf Wed Mar 31 11:30:53 1999 From rem-conf-request@es.net Wed Mar 31 11:30:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10SQNU-00058B-00; Wed, 31 Mar 1999 11:10:16 -0800 Received: from qhars002.nortelnetworks.com (qhars002.nortel.com) [192.100.101.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 10SQNT-000581-00; Wed, 31 Mar 1999 11:10:15 -0800 Received: from nnsgifd1.europe.nortel.com (actually 47.137.131.66) by qhars002.nortel.com; Wed, 31 Mar 1999 19:38:10 +0100 Received: by nnsgifd1.europe.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 Mar 1999 19:38:10 +0100 Message-ID: <391D82D86F58D111B8250000F805C4D0023526F2@bhari886.europe.nortel.com> From: "Graeme Gibbs" To: "'rem-conf@es.net'" Subject: RE: Additional Named Signal Events Date: Wed, 31 Mar 1999 19:38:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Orig: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Gibbs, Graeme [HAL02:HQ20-I:EXCH] Sent: Wednesday, March 31, 1999 5:03 PM To: 'rem-conf@es.net' Cc: Gvozdanovic, Rade [HAL02:HQ20-M:EXCH]; Raviraj, Rajakulasingam [HAL02:HF10-I:EXCH]; 'Chaoxin.Qiu@mail.sprint.com' Subject: Additional Named Signal Events To whoever is editting/championing "RTP Payloads for Telephone Signal Events" Firstly I have not been following the mailing list so apologies if this topic is old & cold. Basically I believe this draft would benefit from the addition of 2 extra Named Signal Events ie 2100Hz tones (ITU G.164)& 2100Hz tone with Phase reversals (ITU G.165) Rationale: These tones, while not used by traditional TDM switches per se, are used by echo cancellers within the TDM network to turn off echo cancellation for calls carrying modems & faxes. Certain carriers may wish to build telephony over IP transit networks, where, at least initially, modem/faxes are carried transparently as G.711 (64kbit/s) packets over IP (yes I know this amounts to data over voice over data, but it may be some period before all gateways support all modulation techniques, and carriers must provide equivalence to current Public Switched Telephone Network from Day 1). Modems/faxes sending such tones would expect both the intervening IP network and prior/subsequent echo cancellers in PSTN to moderate their behaviour accordingly. Take a scenario where the VOIP gateways are running voice calls as compressed to G.729, with silence suppression and echo cancellation, and such a 2100Hz tone is detected The local GW must: Upspeed to 64 kbit/s & turn off silence suppression, and echo cancellation The remote GW must also: Upspeed to 64 kbit/s & turn off silence suppression, and echo cancellation The tone must be propagated back into the PSTN by remote GW 2100Hz tones will not reliably propagate through G.729, therefore if the system relied on passing this tone in-band, the near-end modem would have to detect tone , decide to upspeed (maybe local CAC decisions), and then execute upspeeding before far end GW can begin to detect tones in the stream from the IP network- this may take too long. This method also relies on codec that can receive one codec type and transmit in another (desirable BUT not always the case) However if the near-end GW were to send a Named Signal Event once it had detected the tone, this would allow CAC and upspeeding to occur in parallel, together with a correct tone being enforced to the PSTN Any replies, please mail direct to me as I do not subscribe to avt list From rem-conf Wed Mar 31 21:37:06 1999 From rem-conf-request@es.net Wed Mar 31 21:37:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Sa5U-0002FU-00; Wed, 31 Mar 1999 21:32:20 -0800 Received: from kailash.future.futsoft.com (fsnt.future.futsoft.com) [38.242.192.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Sa5R-0002FK-00; Wed, 31 Mar 1999 21:32:18 -0800 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 01 Apr 1999 11:03:38 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA01498; Thu, 1 Apr 1999 11:02:58 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3703C318@msgate.future.futsoft.com>; Thu, 01 Apr 99 11:03:52 PST From: vishwas To: "'Joseph Serra'" , "IPMULTICAST@stardust.com" Cc: mbone , rem-conf Subject: RE: Who is offering multicast commercially? Date: Thu, 01 Apr 99 11:01:00 PST Message-Id: <3703C318@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, Great News for me. I have been long discussing this issue with my ISP "PSI Net" based in US. I am not aware wether Huges can provide "native multicast", if atleast they can provide us with a DVMRP tunnel it is just great for us. we care connected to PSI net like this, FS---(fire wall)--64kbps leased line--(fire wall)--FCS--PSI Net-->Other Public/Private Peers. What we want is a tunnel to a CISCO router in FS from a peering point >from PSI Net, As I made sure PSI Net itself doesent provide Multicast Services. Please check out this image and let me know any body else out there can help http://www.arl.mil/ARL-Directorates/ASHPC/HPCD/MBONE/mbone-topology.gif Thanks vishu -----Original Message----- From: Joseph Serra [SMTP:joeserra@WORLDNET.ATT.NET] Sent: Thursday, April 01, 1999 3:56 AM To: IPMULTICAST@stardust.com Subject: Re: Who is offering multicast commercially? Hughes Network Systems Probably is the Best Multicasting service provider out there. They'rr in Germantown, MD and can provide service anywhere in the USA. Joe Serra ----- Original Message ----- From: Alejandro Avella To: Sent: Wednesday, March 31, 1999 10:49 AM Subject: Re: Who is offering multicast commercially? > Bernhard Friedl wrote: > > > Does anyone know other > > network providers that offer multicasting as a commercial service? > > It seems that only 8 ISPs do it today. See here: > http://www.ipmulticast.com/ipmi_dir//dc_indexes//category_to_product_names /6 .html > > For more info look here: > http://www.ipmulticast.com/ipmi_dir/ > > Alejandro