From rem-conf Fri May 01 13:23:34 1998 From rem-conf-request@es.net Fri May 01 13:23:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yVM9e-0004pk-00; Fri, 1 May 1998 13:11:34 -0700 Received: from x400bnr.nortel.ca (bcarsbf5.nortel.ca) [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yVM9b-0004o3-00; Fri, 1 May 1998 13:11:31 -0700 Received: from bcars520.ca.nortel.com by x400bnr; Fri, 1 May 1998 16:11:06 -0400 Received: from ca.nortel.com by bcars520.ca.nortel.com id <13223-0@bcars520.ca.nortel.com>; Fri, 1 May 1998 16:09:18 -0400 Date: 01 May 1998 16:08 EDT Sender: "Vahe Balabanian" To: rem-conf@es.net From: "Vahe Balabanian" Subject: AVT Consensus on MPEG4/DMIF Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This e-mail is to enable AVT to form a consensus on its approach to MPEG-4 and DMIF. It essentially addresses the various features of MPEG-4 and DMIF, their relevance to AVT in particular and to IETF in general and finally it derives alternative courses of action within AVT. MPEG-4 and DMIF (Delivery Multimedia Integration Framework) are addressed separately since they present complementary and independent functions. This e-mail aims to stimulate the debate in AVT by inviting the audience on the rem-conf list to participate in the analysis. Interested members from the MPEG community will join AVT on the rem-conf list. At the conclusion of this debate, with the kind help of Steve Casner, I will summarize the result of the consensus for the course of action to take in AVT. I- What is MPEG-4 and how is it relevant to AVT and IETF? ---------------------------------------------------- 1- MPEG-4 divides the screen into AudioVisualObjects (AVO) each having a desired shape (including geometric and natural shapes) and multiplicity of coded streams to be chosen from by the receiving end-user. Analysis: This approach is useful to AVT for enabling an end-user to adapt its viewing to changing network conditions. 2- MPEG-4 composites the AVOs and renders them on the screen with the help of a Scene tree and related Object Descriptor information. Both of these are also classified as streams in MPEG-4. MPEG-4 uses a variety of timestamps and clocks to synchronize the display of the streams within and across the AVOs in a scene. Analysis: AVT has already embarked on defining generic format RTP (GF-RTP) streams and is using Session Description Protocol to identify the characteristics of the GF-RTPs to the receiver. The similarities of MPEG-4 and AVT in this area are in the equivalence of GF-RTP to the MPEG-4 stream and the SDP to the Scene and Object Descriptor. Except in the latter case SDP is a queried entity as opposed to a stream. AVT is not involved in compositing or rendering of AVOs which remain purely MPEG-4 functions. II- What is DMIF and how is it relevant to AVT and IETF? --------------------------------------------------- 1- The abstract DMIF Application Interface (DAI) isolates MPEG-4 from the underlying delivery mechanisms. In this DAI makes use of a media-based QoS (expressed in access unit metrics of priority, loss, delay and jitter) and an explicit format description for each stream. Analysis: This is useful to AVT in maintaining applications intact while transiting from IPV4 to IPV6 and adopting multiple implementations of the TOS byte to carry Diff Serv information. 2- DMIF allows tagging of resources used in a given presentation session. The tags are used to log and apply policy to multiple streams on different source and destination addresses and over different networks. Analysis: As IETF is moving towards usage accountability with RSVP, this concept allows the collection of usage information for a given presentation. A joint server and client policy can thus be applied to limit the usage of resources for a given presentation. 3- DMIF allows efficient and agile packing of streams into transports and the reuse of existing transports to reduce the visual impact of addition of new higher priority streams at the expense of existing lower priority streams. Analysis: This allows AVT users to experiment with different streams in order to optimize their viewing experience perhaps also in the face of changing network conditions reflected in RTCP reports. III- Options for going forward with MPEG-4 and DMIF in AVT ------------------------------------------------------- a) Adopt MPEG-4 FlexMux for agile packing of multiple streams on a UDP flow as opposed to using RTP Analysis: This will create a parallel track to RTP (including mixers, translators and multicast) and in time it could supersede RTP. Although this may be a realistic course of action it can only be adopted after the limit of RTP is duly tested first. AVT and IETF have demonstrated ingenuity in adapting the existing structures to new evolving conditions. b) Adopt MPEG-4 FlexMux for agile packing of multiple streams on RTP. This is the proposal put on the table by draft-ietf-avt-mpeg4-00.txt/ps. Analysis: To some in AVT, FlexMux on RTP appears to be a reasonable way to pack a large number of thin streams. It may require MPEG-4 to increase the size of the FlexMux MTU to 64 Kbytes. In contrast, others in AVT believe this to be unnecessary and would like to use only RTP. This may require restricting MPEG-4 streams to an MPEG-4 Profile created expressly for RTP. c) Redesign the whole of MPEG-4 for IETF or instead use DMIF as in draft-ietf-avt-mpeg4-dmif-00.txt Analysis: Certain functions such as compositing and rendering are clearly not in the scope of AVT, in other words the skill set does not exist in AVT. This suggests that a clear demarcation point must exist where both MPEG-4 and AVT can use their best skill sets and achieve an optimum overall performance. This demarcation point is described in draft-ietf-avt-mpeg4-dmif-00.txt. The argument is that this approach may compromise efficiency in order to satisfy the requirements of complete separation of application from the underlying delivery mechanisms. As resources on Internet are better utilized and as more bandwidth capacity is available to RTP, the benefits of this approach will outweigh the extracting of the last few bits of efficiency for RTP. Note: It is conceivable to think of the transfer of the DMIF design expertise to AVT since it falls within its domain of expertise. DMIF could be used to regulate the stream traffic on Internet in a similar fashion to regulating its TCP traffic. d) Use a subset of MPEG-4 suitable for AVT Analysis: The stream formats in MPEG-4 cover a wide range of timestamps and clocks including implicit timestamps. It may be possible to subset these for operation over RTP. This argues for the creation of MPEG-4 profile for RTP. But this breaks the clean separation adopted in DMIF for isolating the applications from the delivery mechanisms, thus MPEG-4 profiles are normally reserved to applications and not to transports. But one can argue that within the confines of the RTP subset, the DAI principle can still be applied across both the storage and broadcast media. As experience is gained with RTP the subset can be enlarged to encompass more of MPEG-4. IV- Summary ------------ First consider option "d". A clear understanding why MPEG-4 uses a wide range of timestamps and clock mechanisms is required by AVT in order to arrive at an answer whether a useful subset for RTP can be found. Failing the above consider option "c". This allows AVT to propose a delivery mechanism which is most suitable for RTP. Failing the above consider option "b". This considers the use of FlexMux over RTP and ensures that the benefits of RTP (including mixers, translators and multicast) can still be applied to MPEG-4. Finally failing the above use option "a". In this a parallel track is set for MPEG-4. Regards, Vahe Balabanian Nortel balabani@nortel.ca From rem-conf Fri May 01 17:07:49 1998 From rem-conf-request@es.net Fri May 01 17:07:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yVPdw-0005EG-00; Fri, 1 May 1998 16:55:04 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yVPdt-0005Ck-00; Fri, 1 May 1998 16:55:01 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.9.0.Beta5/8.6.6.Beta11) with SMTP id QAA15867; Fri, 1 May 1998 16:54:59 -0700 (PDT) Message-Id: <3.0.3.32.19980501165457.00c44100@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 01 May 1998 16:54:57 -0700 To: rem-conf@es.net, 298-list@brmc From: Irene Yam Subject: Re: UCB MIG Seminar, Wed., May 6, "The SoundFisher Sound Browser " Erling Wold, Muscle Fish, LLC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The SoundFisher Sound Browser (Wednesday May 6, 1998 12:30-2:00 PDT 405 Soda Hall) Erling Wold Muscle Fish, LLC Content-based retrieval of audio has found a place in automatic segmentation and classification of audio and video recordings, multimedia databases and file systems, surveillance and content-based audio processing equipment. This talk will describe our approach to audio analysis and comparison and how it is used in one particular application: the SoundFisher sound effects browser and editor. Our audio analysis reduces sounds to low-level perceptual and acoustical attributes as well as higher-level statistical models of the behaviors of these attributes. Given such an analysis, sounds can then be searched, classified or retrieved by any one or a combination of the attributes, by specifying previously learned categories based on these attributes, or by selecting or entering reference sounds and asking the engine to retrieve sounds that are similar (or dissimilar) to them. The talk will also cover the use of this technology in some related applications. _______________________________________ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Sat May 02 04:40:39 1998 From rem-conf-request@es.net Sat May 02 04:40:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yVaYp-0007VT-00; Sat, 2 May 1998 04:34:31 -0700 Received: from hercules.tsc.upna.es (hercules) [130.206.160.235] by mail1.es.net with smtp (Exim 1.81 #2) id 0yVaYk-0007Sl-00; Sat, 2 May 1998 04:34:27 -0700 Received: from tsc.upna.es by hercules (SMI-8.6/SMI-SVR4) id NAA24168; Sat, 2 May 1998 13:34:26 +0100 Message-ID: <354AFE09.22BD83A1@tsc.upna.es> Date: Sat, 02 May 1998 13:05:48 +0200 From: Arantza Organization: Universidad Pública de Navarra X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Mbone Broadcast:Medical Engeneering Course Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list II Medical Engeneering Course. >From Public University of Navarra, Spain. Organized by the department of Electric and Electronic Ingeneering of this University and in colaboration with the Health Service of Navarra (Osasunbidea). Daily, from 27th April to 15th of May. 16:00 - 19:30 (GMT+1 hr). For more information see: http://www.iee.upna.es/ingemed/introduc.htm ingemed@upna.es This course will be broadcast on the Internet MBONE. The broadcast will begin at 16:00 (GMT +1 hrs). From rem-conf Sat May 02 20:20:30 1998 From rem-conf-request@es.net Sat May 02 20:20:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yVoys-0004r9-00; Sat, 2 May 1998 19:58:22 -0700 Received: from mailhub.tebault.org (genesis.tebault.org) [207.20.149.53] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yVoyo-0004mv-00; Sat, 2 May 1998 19:58:19 -0700 Received: from tebault.org (exodus.tebault.org [207.20.149.50] (may be forged)) by genesis.tebault.org (8.8.7/8.8.7) with ESMTP id TAA22634; Sat, 2 May 1998 19:46:23 -0700 Message-ID: <354BDCBC.FD8878B8@tebault.org> Date: Sat, 02 May 1998 19:55:56 -0700 From: "Peter H. Tebault" Reply-To: petert@tebault.org Organization: ICAST Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Denis DeLaRoca CC: Yiorgos Adamopoulos , mbone@ISI.EDU, rem-conf@es.net Subject: Re: Is www.mbone.net down ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list www.mbone.com is back up now. www.mbone.net has never been up. -Pete- Denis DeLaRoca wrote: > > On Sat, 25 Apr 1998, Yiorgos Adamopoulos wrote: > > > > > I keep getting ``connection refused'' from any *.gr site that I have tried > > Same with www.mbone.com. The DNS entries are gone so I presume that site > is history... can anyone clarify that is the case and wether someone else > will maintain the mbone archives and resource directory that used to > reside at www.mbone.com? > > -- Denis From rem-conf Mon May 04 14:50:25 1998 From rem-conf-request@es.net Mon May 04 14:50:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWSnA-0001tU-00; Mon, 4 May 1998 14:28:56 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with smtp (Exim 1.81 #2) id 0yWSn9-0001su-00; Mon, 4 May 1998 14:28:55 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2212.0) id ; Mon, 4 May 1998 14:28:00 -0700 Message-ID: <69D8143E230DD111B1D40000F8485840F40030@ED> From: "Anders Klemets (Exchange)" To: rem-conf@es.net Subject: RE: AVT Consensus on MPEG4/DMIF Date: Mon, 4 May 1998 14:27:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2212.0) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > b) Adopt MPEG-4 FlexMux for agile packing of multiple > streams on RTP. This is the proposal put on the table by > draft-ietf-avt-mpeg4-00.txt/ps. > > Analysis: To some in AVT, FlexMux on RTP appears to be a > reasonable way to pack a large number of thin streams. It is clear that if you have a large number of very low bit rate streams, it might be reasonable to bundle data from different streams into a single RTP packet. However, FlexMux seems to be an unnecessarily complex approach for achieving this goal. It is not clear how useful a FlexMux PDU in MuxCode mode is, when used over RTP. (See pages 161-164 in the MPEG-4 Systems CD, starting with section 7.5.2.2, for a detailed description of MuxCode mode.) MuxCode mode is used for byte interleaving of data from different streams. A MuxCodeTableEntry specifies exactly how the interleaving is done. Unless you have the MuxCodeTableEntry, you will not be able to decode the FlexMux PDU. Here is an example of how you can use the MuxCodeTableEntry. Suppose a FlexMux PDU contains data from two streams, A and B. A possible interleaving algorithm that could be expressed by a MuxCodeTableEntry could look like this: do do 1 byte from A and 1 byte from B repeat 3 times do 2 bytes from A and 3 bytes from B repeat 2 times repeat until end of FlexMux PDU It would seem to me that MuxCode mode could be useful on packet radio networks, where you have to worry about bit errors. If you decide to process a received packet even though the UDP checksum failed, byte interleaving could spread a burst of bit errors across data from multiple streams, making the errors easier to correct using FEC. But other than this particular scenario, I don't see any particular benefit from having to implement support for MuxCode mode. Anders From rem-conf Mon May 04 20:14:55 1998 From rem-conf-request@es.net Mon May 04 20:14:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWY5z-0003tj-00; Mon, 4 May 1998 20:08:43 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWY5y-0003tW-00; Mon, 4 May 1998 20:08:42 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id UAA01217; Mon, 4 May 1998 20:07:34 -0700 (PDT) Date: Mon, 4 May 1998 20:07:38 -0700 (Pacific Daylight Time) From: Stephen Casner To: GOULEAU Emmanuel CNET/DSM/REN cc: rem-conf@es.net Subject: Re: Payload format for "MPEG1 System" In-Reply-To: <425A62747E7CD111B4570060974B1C6344F7FC@r-mhs.ccett.fr> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 24 Apr 1998, GOULEAU Emmanuel CNET/DSM/REN wrote: > I would like to know if a Payload Format has been defined for "MPEG1 > System". I'm not sure whether you are asking about a payload format or a static payload type number. The answer to the former is yes, and to the latter, no. Assuming you're asking about the latter, here's more detail which I'm sending because I recently needed to answer the same question in a different context. The payload format specification for MPEG1/2 in RFC 2250 defines five different data types that may be carried, but only three of them have static RTP payload types assigned. Since the payload type space is small, we were reluctant to assign five values all at once. Instead, at the time the spec was written the three modes expected most likely to be used were assigned values, and the other two were left to dynamic payload type assignment or possible future static assignment if the other modes were found to be needed. When experiments with RTP began, it was necessary to use statically assigned payload types because that was the only mechanism available. However, in the time since the RTP specification and A/V Profile were published as RFCs 1889 and 1890, the mechanisms for defining dynamic payload type mappings have been specified in the Session Description Protocol (recently published as RFC 2327) and in other protocols such as H.323/H.245. The way a dynamic payload type works is that a longer name for the encoding/payload-format combination is mapped to a payload type number in the range 96-127. That mapping applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the space limitation is avoided. There are now many systems implementing these dynamic payload type mechanisms. It is recognized that there would eventually be a problem with running out of space to make further static payload type assignments, and the mechanisms for using dynamic payload types are now established. Therefore, at the past couple of IETF meetings the AVT working group has discussed revising the policy for static payload type assignments such that no further assignments would be made. The minutes of the most recent meeting include the following: As had been discussed in Munich, it was agreed that the RTP Profile draft should be revised to say no more static payload types would be assigned. Those that are already assigned should be considered "default" values in the dynamic payload type table, and may be overwritten once all the unassigned values have been used for dynamic types within a session. This new policy has not been published yet, but we plan to get the profile draft (draft-ietf-avt-profile-new-02.txt/ps) revised and published soon. Please consider the use of a dynamic payload type value for your applications. See the SDP spec (RFC 2327) for examples of how the dynamic payload type mapping is expressed using the "rtpmap" attribute. If the system you are implementing does not use SDP to describe sessions, the mapping between the dynamic payload type value and the longer name may be conveyed along with the address and port number using whatever communication path you use now for that address and port number. If you consider it implicit in your connection establishment procedure that MPEG1 Systems Streams will always be used, then you could simply use PT 96 and assume that it is implicitly mapped. However, I advise against making that assumption because if you decide later to use another encoding/payload-format, or if you try to interoperate with another implementation that has made a different assumption, then communication will fail. The revision of the profile draft needs to include some additional encoding/payload-format names so that those names may be used in dynamic payload type mappings. In looking at the profile draft, I see that names are not defined for MPEG1 Systems and MPEG2 Programs streams. Following the model of MP2T, I suggest that we define the names MP1S and MP2P, however that may be open to discussion. It was also resolved at the recent IETF meeting that the payload format names would be registered in the MIME type namespace, so that is the registration which needs to occur now for all the existing names in the draft plus others such as the two new ones for MPEG. -- Steve From rem-conf Mon May 04 20:43:23 1998 From rem-conf-request@es.net Mon May 04 20:43:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWYbd-0004Ye-00; Mon, 4 May 1998 20:41:25 -0700 Received: from jupiter.nal.utoronto.ca [128.100.244.3] by mail1.es.net with smtp (Exim 1.81 #2) id 0yWYbc-0004YU-00; Mon, 4 May 1998 20:41:24 -0700 Received: from nal.utoronto.ca by jupiter.nal.utoronto.ca (SMI-8.6/SMI-SVR4) id XAA07236; Mon, 4 May 1998 23:41:13 -0400 Message-ID: <354E8B6E.70F36494@nal.utoronto.ca> Date: Mon, 04 May 1998 23:45:50 -0400 From: Yasser Rasheed Organization: University Of Toronto X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: AVT IETF , Yasser Rasheed Subject: MPEG2 Tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear colleagues, I am preparing a survey on MPEG2 tools available in both hardware and software. I am looking for encoders, decoders and testing tools, for layered and non-layered MPEG2. I would appreciate any feedback regarding this issue and please also let me know if such information is compiled anywhere. Thank you for your attention. --Yasser Rasheed. _________________________________________________________________________________ YASSER RASHEED University of Toronto, ECE Dept., 10 king's College Road Toronto Ont M5S 3G4 Canada Tel: (416)-978-4829 Fax: (416)-978-4425 Email: yrasheed@nal.utoronto.ca http://www.comm.utoronto.ca/~yrasheed From rem-conf Tue May 05 01:24:17 1998 From rem-conf-request@es.net Tue May 05 01:24:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWcwz-0006VH-00; Tue, 5 May 1998 01:19:45 -0700 Received: from (uranus.vdo.co.il) [207.232.4.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWcwx-0006V0-00; Tue, 5 May 1998 01:19:44 -0700 Received: from zvil.vdo.co.il ([207.232.4.205]) by uranus.vdo.co.il (8.8.7/8.8.7) with SMTP id KAA23874 for ; Tue, 5 May 1998 10:19:38 +0300 Received: by localhost with Microsoft MAPI; Tue, 5 May 1998 11:20:46 +0300 Message-ID: <01BD7817.D93D5C20.zvil@vdo.net> From: Zvi Lifshitz Reply-To: "zvil@vdo.net" To: "rem-conf@es.net" Subject: RE: AVT Consensus on MPEG4/DMIF Date: Tue, 5 May 1998 10:47:45 +0300 Organization: VDOnet X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 27 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Anders:] It would seem to me that MuxCode mode could be useful on packet radio networks, where you have to worry about bit errors. If you decide to process a received packet even though the UDP checksum failed, byte interleaving could spread a burst of bit errors across data from multiple streams, making the errors easier to correct using FEC. But other than this particular scenario, I don't see any particular benefit from having to implement support for MuxCode mode. [Reply:] MuxCode can save bandwidth in case of multiple streams with very small access units of known size. This may happen in animation streams, for instance. Sometimes the units may be 2-3 bytes long, and the use of MuxCode can reduce bandwidth by 20-30%. Zvi (newbi in this forum, not so much in MPEG :-) ===================== Zvi Lifshitz (zvil@vdo.net) VDOnet Corp. (www.vdo.net) Phone +972(2)679-4788 Fax +972(2)679-4789 ===================== From rem-conf Tue May 05 02:05:18 1998 From rem-conf-request@es.net Tue May 05 02:05:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWddU-0007Fs-00; Tue, 5 May 1998 02:03:40 -0700 Received: from isis.u-strasbg.fr [130.79.200.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yWddS-0007Fi-00; Tue, 5 May 1998 02:03:38 -0700 Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.75.86]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA24708 for ; Tue, 5 May 1998 11:03:09 +0200 Received: by clarinet.u-strasbg.fr (5.x/SMI-SVR4) id AA20035; Tue, 5 May 1998 11:03:02 +0200 Date: Tue, 5 May 1998 11:03:02 +0200 From: pate@clarinet.u-strasbg.fr (David PATE) Message-Id: <9805050903.AA20035@clarinet.u-strasbg.fr> To: rem-conf@es.net Subject: Re: MPEG2 Tools X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Dear colleagues, > I am preparing a survey on MPEG2 tools available in both hardware and > software. > I am looking for encoders, decoders and testing tools, for layered and > non-layered MPEG2. > I would appreciate any feedback regarding this issue and please also let > me know if such > information is compiled anywhere. > > Thank you for your attention. > > --Yasser Rasheed. > see http://www.mpeg.org/index.html/ DAVID ----- From rem-conf Tue May 05 06:17:52 1998 From rem-conf-request@es.net Tue May 05 06:17:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWhWB-0001yi-00; Tue, 5 May 1998 06:12:23 -0700 Received: from lutra.sztaki.hu [193.225.86.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWhW9-0001yX-00; Tue, 5 May 1998 06:12:21 -0700 Received: by lutra.sztaki.hu id <1152040-959>; Tue, 5 May 1998 15:11:55 +0200 Date: Tue, 5 May 1998 15:11:50 +0200 (MET DST) Sender: Andras Micsik From: Andras Micsik To: rem-conf@es.net Subject: Mrouted tunneling? 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 would need the exact specification of the tunneling used by moruted. We have to enable a tunnel through a firewall. The firewall expert asked me about the type of tunneling: Is it GRE? We use mrouted 3.8 and Cisco routers. Thanks in advance. ----------------------------------------------------------- Andras Micsik micsik@sztaki.hu MTA SZTAKI Hungary http://www.sztaki.hu/~micsik From rem-conf Tue May 05 17:25:23 1998 From rem-conf-request@es.net Tue May 05 17:25:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWrqB-0007Tk-00; Tue, 5 May 1998 17:13:43 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with smtp (Exim 1.81 #2) id 0yWrqA-0007Sx-00; Tue, 5 May 1998 17:13:42 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2217.0) id ; Tue, 5 May 1998 17:12:48 -0700 Message-ID: <69D8143E230DD111B1D40000F8485840F40035@ED> From: "Anders Klemets (Exchange)" To: "'zvil@vdo.net'" , "'rem-conf@es.net'" Subject: RE: AVT Consensus on MPEG4/DMIF Date: Tue, 5 May 1998 17:12:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2217.0) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > MuxCode can save bandwidth in case of multiple streams with > very small > access units of known size. This may happen in animation streams, for > instance. Sometimes the units may be 2-3 bytes long, and the > use of MuxCode > can reduce bandwidth by 20-30%. Thanks for your reply. Perhaps I am missing something obvious. Why would byte interleaving cause the bandwidth to be reduced? You can shuffle the bytes around any way you want, and it's still going to be the same number of bytes. One way to save bandwidth would be to eliminate certain common fields from the AL-PDU headers. Suppose, for example, you want to multiplex three AL-PDU's from different streams into one FlexMux-PDU. If the three AL-PDU headers are sufficiently similar, (same timestamps, etc.) it may pay off to compress the headers. However, FlexMux does not say that any such AL-PDU header compression should be done. What am I missing? Anders From rem-conf Tue May 05 19:17:22 1998 From rem-conf-request@es.net Tue May 05 19:17:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWteK-0000jZ-00; Tue, 5 May 1998 19:09:36 -0700 Received: from docws001.shl.com [159.249.56.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWteI-0000i4-00; Tue, 5 May 1998 19:09:34 -0700 Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id VAA53120 for ; Tue, 5 May 1998 21:02:18 -0500 Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD7869.F6DF2400@dalmsdoc01.shl.com>; Tue, 5 May 1998 21:08:34 -0500 Message-ID: From: "KOBRYN, Cris" To: "'commsoft@cc.bellcore.com'" , "'bomsig@omg.org'" , "'adtf@omg.org'" , "'mof@omg.org'" , "'tc@omg.org'" , "'ptc@omg.org'" To: "'dtc@omg.org'" , "'ab@omg.org'" , "'mof-rtf@omg.org'" , "'odp@dstc.edu.au'" , "'dbworld@cs.wisc.edu'" , "'enternet@BBN.COM'" To: "'JavaCORBA@luke.org'" , "'ISWORLD@Danann.hea.ie'" , "'comsoc-chapters@IEEE.ORG'" , "'comsoc-gicb@IEEE.ORG'" , "'comsoc.tac@tab.ieee.org'" , "'comswtc@gmu.edu'" To: "'ctc-members@redbank.tinac.com'" , "'dbworld@cs.wisc.edu'" , "'end2end-interest@isi.edu'" , "'enternet@BBN.COM'" , "'f-troup@codex.cis.upenn.edu'" , "'fokus-user@fokus.gmd.de'" To: "'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'" To: "'itc@fokus.gmd.de'" , "'modern-heuristics@uk.ac.mailbase'" , "'multicomm@cc.bellcore.com'" , "'osimcast@BBN.COM'" , "'rem-conf@es.net'" , "'reres@laas.fr'" To: "'sb.all@IEEE.ORG'" , "'sc6wg4@ntd.comsat.com'" , "'sigmedia@bellcore.com'" , "'tccc@IEEE.ORG'" , "'xtp-relay@cs.concordia.ca'" Subject: EDOC '98: Final Call for Papers & Invited Speakers Date: Tue, 5 May 1998 21:08:21 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Encoding: 231 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Please forward this message to colleagues who might be interested. We apologize if you receive multiple copies.] The following is the final Call for Papers for the 2nd International Enterprise Distributed Object Computing Workshop (EDOC '98). A HTML version of the CFP can be found at: http://uml.systemhouse.mci.com/events/edoc98/home.htm A PDF version of the CFP can be found at: http://uml.systemhouse.mci.com/events/edoc98/docs/edoc98-cfp.pdf Invited speakers for the workshop include: Ivar Jacobson, VP of Business Engineering, Rational Software Corp. Phil Bernstein, Repository Architect, Microsoft Corp. ====================================================================== ***** CALL FOR PAPERS ***** 2nd International Enterprise Distributed Object Computing Workshop (EDOC '98) November 3-5, 1998 Hyatt Regency La Jolla, San Diego, California, USA http://uml.systemhouse.mci.com/events/edoc98/home.htm ====================================================================== Hosted by: MCI Systemhouse Corporation Technical Co-Sponsors: Object Management Group (OMG) IEEE Communications Society, Enterprise Networking Technical Committee Endorsed by: Institute of Electronics, Information and Communication Engineers of Japan Information Processing Society of Japan (IPSJ) Corporate sponsors: Distributed Systems Technology Centre (DSTC) Unisys Corp. Fujitsu Corp. ====================================================================== SCOPE: ~~~~~~ The software industry is in the midst of a major shift in technology from static, monolithic systems to the era of distributed objects and components. The remarkable level of interest in the first Enterprise Distributed Object Computing (EDOC '97) Workshop demonstrated that this transformation is well underway. However, there remain some major challenges to be overcome if distributed objects and components are to fulfill their full potential for solving enterprise problems. The goal of the EDOC workshops is to provide a leading forum for the exchange of ideas and results in this rapidly developing field of computing, and to establish a new community of researchers and industry experts to address the enterprise issues associated with distributed object technology. Building on the success of the first EDOC workshop, EDOC '98 will focus on securing high-quality papers and tutorials from around the world, and will provide ample opportunities for discussion and debate. In addition, there will be relevant panel sessions with substantial time for open discussions. EDOC '98 will target two interrelated categories of topics. The first group will deal with the specification of enterprise models for distributed systems. This includes issues related to the specification of roles, policies, business objects and their relationships in open distributed systems. The second group will address the problems of implementing systems specified by enterprise models using currently available distributed object technologies (e.g., CORBA, DCOM, Java-RMI, TINA, RM-ODP). This includes issues related to architectural models, technology bridges and the general problem of middleware selection and application. TOPICS: ~~~~~~~ The program committee seeks research results, experience reports and case studies related to all aspects of enterprise distributed object computing, including such topics as: - Distributed object architectures and frameworks - Distributed business objects - Analysis and design methods - Metamodeling architectures - Collaborative and workflow systems - ODP enterprise language and business modeling - UML for enterprise applications - Enterprise policy, management and security - Enterprise Quality of Service - Traders, brokers, and agents for enterprise solutions - Application of the above technologies in vertical application domains such as telecomunnications, business and financial systems Papers must be of high quality and will be evaluated for originality, significance, insight, clarity and their relevance to the enterprise aspects of distributed object computing. IMPORTANT DATES: ~~~~~~~~~~~~~~~~ June 1st, 1998: Papers due August 10, 1998: Notification of acceptance September 11, 1998: Final papers due November 3-5, 1998: Workshop INFORMATION FOR AUTHORS: ~~~~~~~~~~~~~~~~~~~~~~~~ PAPERS: Authors are invited to submit full papers according to the submission guidelines below. Papers will be refereed by an international committee of experts. Presented papers will be published by the IEEE Computer Society Press. SUBMISSIONS: The papers should not exceed 12 pages, according to IEEE format (double column, single space, 10 point Times font). The preferred method for submission is electronic mail (Word, RTF, PostScript or PDF format). Please send your submissions to the following address: edoc98-submissions@omg.org Enquiries should be directed to: edoc98-info@omg.org WORKSHOP ORGANIZERS: ~~~~~~~~~~~~~~~~~~~~ General Chair: Cris Kobryn (MCI Systemhouse, USA) Program Chairs: Colin Atkinson (IESE, Germany) Zoran Milosevic (DSTC, Australia) Program Committee: Nigel Baker (University of West England, UK) Phil Bernstein (Microsoft, USA) Eng Chew (Optus, Australia) Jim Coplien (Bell Labs, USA) Fred Cummins (EDS, USA) Takeo Hamada (Fujitsu Laboratories of America, USA) Sridar Iyengar (Unisys, USA) Peter Linington (University of Kent at Canterbury, UK) Claudia Linnhoff-Popien (RWTH Aachen, Germany) George Karetsos (National Technical University of Athens, Greece) Subrata Mazumdar (Bell Labs, USA) Osamu Miyagishi (NTT, Japan) Luke O'Connor (IBM Zurich, Switzerland) Maria Orlowska (The University of Queensland, Australia) Jong-Tae Park (Kyungpook National University, Korea) Thomas Preuss (Brandenburg University of Technology, Germany) Kerry Raymond (DSTC, Australia) Roberto Saracco (CSELT, Italy) Marc-Thomas Schmidt (IBM, USA) Morris Sloman (Imperial College, UK) Richard Mark Soley (OMG, USA) Jean-Bernard Stefani (CNET France Telecom, France) Keith Swenson (Netscape, USA) Sandy Tyndale-Biscoe (Birchquest Ltd, UK) Kevin Tyson (Enterprise Engineering, USA) Sanya Uehara (Fujitsu, Japan) Karl-Heinz Weiss (Public Administration Berlin, Germany) Edward White (MCI, USA) Bryan Wood (Open-IT, UK) Douglas Zuckerman (Bellcore, USA) Local Organizing Committee: Cheryl Bissonnette (OMG, USA) VENUE: ~~~~~~ EDOC '98 will be held in San Diego, California at one of Southern California's premier venues: the Hyatt Regency La Jolla at Aventine. The hotel is a San Diego landmark destination and a Mobil 4-Star and AAA 4-Diamond Award winner. It provides the perfect complement of business and recreation facilities. The Aventine complex includes the Hyatt Regency La Jolla, a 32,000 sq. ft. world-class Sporting Club and Spa, a restaurant village with internationally themed restaurants, lighted tennis courts and a heated pool. The hotel is five minutes from golf and the beach and 15 minutes from downtown San Diego. ENQUIRIES AND REGISTRATION DETAILS: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Accommodation at a discounted conference rate is available at the workshop venue. Registration and accommodation details will be available in the near future. For enquiries, please email to Cheryl Bissonette at: cheryl@omg.org Postal address: Object Management Group 492 Old Connecticut Path Framingham, MA 01701 USA RELATED EVENTS: ~~~~~~~~~~~~~~~ November 9-13, 1998 OMG Technical Committee meeting, Burlingame, CA, USA WWW PAGE: ~~~~~~~~~ Further details about the EDOC'98 event and this Call For Papers can be found at: http://uml.systemhouse.mci.com/events/edoc98/home.htm From rem-conf Tue May 05 20:05:34 1998 From rem-conf-request@es.net Tue May 05 20:05:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWuSM-0001a9-00; Tue, 5 May 1998 20:01:18 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWuSL-0001Zq-00; Tue, 5 May 1998 20:01:17 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id UAA11543; Tue, 5 May 1998 20:00:10 -0700 (PDT) Date: Tue, 5 May 1998 20:00:15 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Re: AVT WG last call on two drafts In-Reply-To: Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: The "working group last call for comments" period has concluded for the two drafts: "Options for Repair of Streaming Media" draft-ietf-avt-info-repair-03.txt Informational RFC "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)" draft-ietf-avt-rtp-h263-video-01.txt Proposed Standard RFC I believe there were no comments on the first draft. There was some discussion of the relationship between the second draft and RFC 2190 on the earlier version of H.263. My interpretation of the discussion was that everyone agreed that including a paragraph in the new spec explaining its relationship to 2190 is a good idea. Furthermore, although there were several opinions stated pro & con regarding the designation of 2190 as "updated by" the new one, the folks who were concerned about that designation were persuaded that it would be OK. I will now send a request for IESG Last Call on the info-repair draft. I will send a similar request for the h263-video draft as soon as the authors have posted the updated version including the aforementioned paragraph and other minor fixes previously discussed. -- Steve From rem-conf Wed May 06 00:09:57 1998 From rem-conf-request@es.net Wed May 06 00:09:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yWyBN-0003NX-00; Wed, 6 May 1998 00:00:01 -0700 Received: from (uranus.vdo.co.il) [207.232.4.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yWyBL-0003NC-00; Tue, 5 May 1998 23:59:59 -0700 Received: from zvil.vdo.co.il ([207.232.4.202]) by uranus.vdo.co.il (8.8.7/8.8.7) with SMTP id IAA00239; Wed, 6 May 1998 08:58:42 +0300 Received: by localhost with Microsoft MAPI; Wed, 6 May 1998 10:01:15 +0300 Message-ID: <01BD78D5.E8475CC0.zvil@vdo.net> From: Zvi Lifshitz Reply-To: "zvil@vdo.net" To: "'rem-conf@es.net'" , "'Anders Klemets (Exchange)'" Subject: RE: AVT Consensus on MPEG4/DMIF Date: Wed, 6 May 1998 09:43:31 +0300 Organization: VDOnet X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 44 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Anders:] Thanks for your reply. Perhaps I am missing something obvious. Why would byte interleaving cause the bandwidth to be reduced? You can shuffle the bytes around any way you want, and it's still going to be the same number of bytes. [Reply:] Example: We have 4 access units, from streams 1, 2, 3 and 4, each 4 bytes long. Without MuxCode, we will convey them in 4 FlexMux PDUs, each consists of 1 byte for PDU length, 1 byte for stream number, and 4 bytes for payload. In total 4*(2+4)=24. With MuxCode this will be 1 byte for PDU length, 1 byte for MuxCode (which tells "payload contains AUs from stream 1, 2, 3 and 4, each 4 bytes long), and payloads for the 4 PDUs. In total 2+4*4=18. 25% reduction if you pay in cash. [Original Message:] One way to save bandwidth would be to eliminate certain common fields from the AL-PDU headers. Suppose, for example, you want to multiplex three AL-PDU's from different streams into one FlexMux-PDU. If the three AL-PDU headers are sufficiently similar, (same timestamps, etc.) it may pay off to compress the headers. However, FlexMux does not say that any such AL-PDU header compression should be done. What am I missing? [Reply:] Could be done, but was not :-(. Zvi ===================== Zvi Lifshitz (zvil@vdo.net) VDOnet Corp. (www.vdo.net) Phone +972(2)679-4788 Fax +972(2)679-4789 ===================== From rem-conf Wed May 06 10:19:39 1998 From rem-conf-request@es.net Wed May 06 10:19:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yX7em-0000DG-00; Wed, 6 May 1998 10:07:00 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yX7el-0000D6-00; Wed, 6 May 1998 10:06:59 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.9.0.Beta5/8.6.6.Beta11) with SMTP id KAA26275; Wed, 6 May 1998 10:06:57 -0700 (PDT) Message-Id: <3.0.3.32.19980506100655.00c7c260@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 May 1998 10:06:55 -0700 To: 298-list@bmrc.berkeley.edu, rem-conf@es.net, soda-info@cs.Berkeley.EDU, mm-all@bmrc.Berkeley.EDU From: Irene Yam Subject: Re: UCB MIG Seminar, Wed., May 6, "The SoundFisher Sound Browser " Erling Wold, Muscle Fish, LLC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please join us for our last MIG Seminar for Spring 1998! The SoundFisher Sound Browser (Wednesday May 6, 1998 12:30-2:00 PDT 405 Soda Hall) Erling Wold Muscle Fish, LLC Content-based retrieval of audio has found a place in automatic segmentation and classification of audio and video recordings, multimedia databases and file systems, surveillance and content-based audio processing equipment. This talk will describe our approach to audio analysis and comparison and how it is used in one particular application: the SoundFisher sound effects browser and editor. Our audio analysis reduces sounds to low-level perceptual and acoustical attributes as well as higher-level statistical models of the behaviors of these attributes. Given such an analysis, sounds can then be searched, classified or retrieved by any one or a combination of the attributes, by specifying previously learned categories based on these attributes, or by selecting or entering reference sounds and asking the engine to retrieve sounds that are similar (or dissimilar) to them. The talk will also cover the use of this technology in some related applications. _______________________________________ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Thu May 07 06:12:07 1998 From rem-conf-request@es.net Thu May 07 06:12:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yXPvy-00025i-00; Thu, 7 May 1998 05:37:58 -0700 Received: from lutra.sztaki.hu [193.225.86.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yXPvw-00025X-00; Thu, 7 May 1998 05:37:56 -0700 Received: by lutra.sztaki.hu id <1152049-946>; Thu, 7 May 1998 14:37:38 +0200 Date: Thu, 7 May 1998 14:37:37 +0200 (MET DST) Sender: Andras Micsik From: Andras Micsik To: rem-conf@es.net Subject: ESPRIT Information Day, Friday 8 May Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ESPRIT Information Day with EC and CEEC on Last Call for Proposals in the 4th Framework Programme Friday, 8 May 1998, Budapest, Hungary We are pleased to announce that the ESPRIT Information Day will be broadcasted over the MBONE. (More about the broadcast at the end of this mail.) The aim of the event is to disseminate information on (1) the Last Call for Proposals in ESPRIT, (2) the Fifth Framework Programme. The speakers include Mr. Klaus Woelcken, Mr. Anton Schrag and Mr. Bill Collin (EU DG III), and Mr. Sandor Bottka (OMFB). The programme on Friday, 8th May 1998, is as follows: 09:00-09.30 Welcome 09:30-11:00 K. Woelcken: The Fifth Framework programme: current status and options for the CEE countries A. Schrag: The current ESPRIT call for proposals in the 4th Framework Programme, participation possibilities for the CEE countries Speakers from CEE countries on their project experiences in the national R&D programmes. 11:30-13.00 Discussion, Q&A session on proposal preparation 14:00-15:30 Regional discussion of project participants - practical advice on proposals (Chair: B. Collin) --------------------------------------------------------------------- About the broadcast over MBONE Please note that you can only watch and listen to the event but cannot actively participate (i.e. put questions or make comments). 1. How to connect? Join the session called "ESPRIT Info Day Budapest" in the session directory tool. 2. More info about the MBONE See: or in English, or in Hungarian From rem-conf Thu May 07 15:49:48 1998 From rem-conf-request@es.net Thu May 07 15:49:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yXZJj-0006m6-00; Thu, 7 May 1998 15:39:07 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yXZJh-0006lw-00; Thu, 7 May 1998 15:39:05 -0700 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA25895; Thu, 7 May 1998 15:50:42 -0700 (PDT) Received: from newport (newport.jf.intel.com [134.134.210.54]) by ideal.jf.intel.com (8.8.7/8.8.7) with SMTP id PAA18496; Thu, 7 May 1998 15:27:52 -0700 (PDT) Reply-To: From: "Gim Deisher" To: "IETF Draft Submission (E-mail)" , "Rem-Conf Mailing List (E-mail)" , "ITU Video Mailing List (E-mail)" Cc: "Carsten Bormann (E-mail)" , "Linda Cline (E-mail)" , "Gim Deisher (E-mail)" , "Tom Gardos (E-mail)" , "Christian Maciocco (E-mail)" , "Donald Newell (E-mail)" , "Joerg Ott (E-mail)" , "Gary Sullivan (E-mail)" , "Stephan Wenger (E-mail)" , "Chad Zhu (E-mail)" Subject: New H.263+ RTP Payload Draft Date: Thu, 7 May 1998 15:33:05 -0700 Message-ID: <001301bd7a08$1b3ab040$36d28686@newport.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed is a new revision of the H.263+ RTP payload format specification which is to replace the 1/98 IETF internet draft, draft-ietf-avt-rtp-h263-video-01.txt. Here is a brief summary on the changes: 1. Extended the first paragraph to describe the relationship of this payload draft and RFC2190. (section 1) 2. Mentioned P-picture temporal scalability (sections 1 & 4.2). 3. Made a correction in the RTP timestamp description. (section 2.1) 4. Clarified GOB boundary packetization. (section 2.2) 5. Adjusted diagrams. No change in payload format. (sections 5.1.1, 5.1.2, 5.1.3, 5.2) 6. Added/deleted references. (section 8) 7. A few other minor editorial changes. Comments welcome as usual. Thank you. ------------------------------------------------------------------------ Internet Engineering Task Force Audio-Video Transport WG draft-ietf-avt-rtp-h263-video-02.txt C. Bormann / Univ. Bremen May 7, 1998 L. Cline / Intel G. Deisher / Intel T. Gardos / Intel C. Maciocco / Intel D. Newell / Intel J. Ott / Univ. Bremen G. Sullivan / PictureTel S. Wenger / TU Berlin C. Zhu / Intel RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 1. Introduction This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 [3], and is recommended for this use by new implementations. This format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 shall use the format described in this document. The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options. The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries. With the independent segment decoding option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others. The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode can be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information. H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to-noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both. 2. Usage of RTP When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream including the fixed length codes and variable length codes will be included in the packet, with the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of the start code are removed and replaced by setting an indicator bit in the payload header. For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications. The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in section 4. This section defines the usage of the RTP fixed header and H.263+ video packet structure. 2.1 RTP Header Usage Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263+ video streams: Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame, and is 0 otherwise. Payload Type (PT): The Payload Type shall specify the H.263+ video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to the 1998 ITU-T Recommendation H.263 [4] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of the RTP payload for H.261 stream [5]. Since both the H.263+ data and the RTP header contain time information, it is required that those timing information run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. Any H.263+ picture clock frequency can be expressed as 1800000/(cd*cf) source pictures per second, in which cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock of the RTP timestamp, the time increment between each coded H.263+ picture should therefore be a integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer display update rates of 60, 72 and 75 Hz, respectively). For RTP packetization of hypothetical H.263+ bitstreams using "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary for generating the RTP timestamps. 2.2 Video Packet Structure A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable depending on the payload involved as detailed in the section 4. The layout of the RTP H.263+ video packet is shown as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Payload Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Compressed Data Stream ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS starts codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned; however, since this is not required in H.263+, there may be some cases where GOB start codes are not aligned, such as when transmitting existing content, or when using H.263 encoders that do not support GOB start code alignment. In this case, follow-on packets (see section 5.2) should be used for packetization. All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header. 3. Design Considerations The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in such cases in which another packet containing the original picture header becomes lost. There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video. o The optional slice structured mode described in Annex K of H.263+ [4] enables more flexibility for packetization. Similar to a picture segment that begins with a GOB header, the motion vector predictors in a slice are restricted to reside within its boundaries. However, slices provide much greater freedom in the selection of the size and shape of the area which is represented as a distinct decodable region. In particular, slices can have a size which is dynamically selected to allow the data for each slice to fit into a chosen packet size. Slices can also be chosen to have a rectangular shape which is conducive for minimizing the impact of errors and packet losses on motion compensated prediction. For these reasons, the use of the slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs. o In non-rectangular slice structured mode, only complete slices should be included in a packet. In other words, slices should not be fragmented across packet boundaries. The only reasonable need for a slice to be fragmented across packet boundaries is when the encoder which generated the H.263+ data stream could not be influenced by an awareness of the packetization process (such as when sending H.263+ data through a network other than the one to which the encoder is attached, as in network gateway implementations). Optimally, each packet will contain only one slice. o The independent segment decoding (ISD) described in Annex R of [4] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to further improve resiliency in high loss conditions. o If ISD is used in conjunction with the slice structure, the rectangular slice submode shall be enabled and the dimensions and quantity of the slices present in a frame shall remain the same between each two intra-coded frames (I-frames), as required in H.263+. The individual ISD segments may also be entirely intra coded from time to time to realize quick error recovery without adding the latency time associated with sending complete INTRA-pictures. o When the slice structure is not applied, the insertion of a (preferably byte-aligned) GOB header can be used to provide resync boundaries in the bitstream, as the presence of a GOB header eliminates the dependency of motion vector prediction across GOB boundaries. These resync boundaries provide natural locations for packet payload boundaries. o H.263+ allows picture headers to be sent in an abbreviated form in order to prevent repetition of overhead information that does not change from picture to picture. For resiliency, sending a complete picture header for every frame is often advisable. This means, that especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable, the sender may always set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. o In a multi-layer scenario, each layer may be transmitted to a different network address. The configuration of each layer such as the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type should be determined at the start of the session and should not change during the course of the session. o All start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned. The boundaries of these syntactical elements provide ideal locations for placing packet boundaries. o We assume that a maximum Picture Header size of 504 bits is sufficient. The syntax of H.263+ does not explicitly prohibit larger picture header sizes, but the use of such extremely large picture headers is not expected. 4. H.263+ Payload Header For H.263+ video streams, each RTP packet carries only one H.263+ video packet. The H.263+ payload header is always present for each H.263+ video packet. The payload header is of variable length. A 16 bit field of the basic payload header may be followed by an 8 bit field for Video Redundancy Coding information, and/or by a variable length extra picture header as indicated by PLEN. These optional fields appear in the order given above when present. If an extra picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, corresponding to PLEN equal to 0 and no VRC information present. The remainder of this section defines the various components of the RTP payload header. Section five defines the various packet types that are used to carry different types of H.263+ coded data, and section six summarizes how to distinguish between the various packet types. 4.1 General H.263+ payload header The H.263+ payload header is structured as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |P|V| PLEN |PEBIT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RR: 5 bits Reserved bits. Shall be zero. P: 1 bit Indicates the picture start or a picture segment (GOB/Slice) start or a video sequence end (EOS or EOSBS). Two bytes of zero bits then have to be prefixed to the payload of such a packet to compose a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the omission of the two first bytes of the start codes, thus improving the compression ratio. V: 1 bit Indicates the presence of an 8 bit field containing information for Video Redundancy Coding (VRC), which follows immediately after the initial 16 bits of the payload header if present. For syntax and semantics of that 8 bit VRC field see section 4.2. PLEN: 6 bits Length in bytes of the extra picture header. If no extra picture header is attached, PLEN is 0. If PLEN>0, the extra picture header is attached immediately following the rest of the payload header. Note the length reflects the omission of the first two bytes of the picture start code (PSC). See section 5.1. PEBIT: 3 bits Indicates the number of bits that shall be ignored in the last byte of the picture header. If PLEN is zero, then PEBIT shall also be zero. 4.2 Video Redundancy Coding Header Extension Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N. By having multiple "threads" of independently inter-frame predicted pictures, damage of individual frame will cause distortions only within its own thread but leave the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture which is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For more information on codec support for VRC see [7]. P-picture temporal scalability is another use of the reference picture selection mode and can be considered a special case of VRC in which only one copy of each sync frame may be sent. It offers a thread-based method of temporal scalability without the increased delay caused by the use of B pictures. In this use, sync frames sent in the first thread of pictures are also used for the prediction of a second thread of pictures which fall temporally between the sync frames to increase the resulting frame rate. In this use, the pictures in the second thread can be discarded in order to obtain a reduction of bit rate or decoding complexity without harming the ability to decode later pictures. A third or more threads can also be added as well, but each thread is predicted only from the sync frames (which are sent at least in thread 0) or from frames within the same thread. While a VRC data stream is - like all H.263+ data - totally self- contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, and the thread-id and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension. The format of the VRC header extension is as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | TID | Trun |S| +-+-+-+-+-+-+-+-+ TID: 3 bits Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC data will use as reference information only sync frames or frames within the same thread. By convention, thread 0 is expected to be the "canonical" thread, which is the thread from which the sync frame should ideally be used. In the case of corruption or loss of the thread 0 representation, a representation of the sync frame with a higher thread number can be used by the decoder. Lower thread numbers are expected to contain equal or better representations of the sync frames than higher thread numbers in the absence of data corruption or loss. See [7] for a detailed discussion of VRC. Trun: 4 bits Monotonically increasing (modulo 16) 4 bit number counting the packet number within each thread. S: 1 bit A bit that indicates that the packet content is for a sync frame. An encoder using VRC may send several representations of the same "sync" picture, in order to ensure that regardless of which thread of pictures is corrupted by errors or packet losses, the reception of at least one representation of a particular picture is ensured (within at least one thread). The sync picture can then be used for the prediction of any thread. If packet losses have not occurred, then the sync frame contents of thread 0 can be used and those of other threads can be discarded (and similarly for other threads). Thread 0 is considered the "canonical" thread, the use of which is preferable to all others. The contents of packets having lower thread numbers shall be considered as generally preferred over those with higher thread numbers. 5. Packetization schemes 5.1 Picture Segment Packets and Sequence Ending Packets (P=1) A picture segment packet is defined as a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This corresponds to the definition of the start of a video picture segment as defined in H.263+. For such packets, P=1 always. An extra picture header can sometimes be attached in the payload header of such packets. Whenever an extra picture header is attached as signified by PLEN>0, only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled on the receiving end by prepending the sixteen leading '0' bits. When PLEN>0, the end bit position corresponding to the last byte of the picture header data is indicated by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header. A sequence ending packet is defined as a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. This delineates the end of a sequence of H.263+ video data (more H.263+ video data may still follow later, however, as specified in ITU-T Recommendation H.263). For such packets, P=1 and PLEN=0 always. The optional header extension for VRC may or may not be present as indicated by the V bit flag. 5.1.1 Packets that begin with a Picture Start Code Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC), and should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in such a case. However, if the coded picture contains an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization in order to provide greater error resilience. Thus, for packets that start at the location of a picture start code, PLEN shall be zero unless both of the following conditions apply: 1) The picture header in the H.263+ bitstream payload is incomplete (PLUSPTYPE present and UFEP="000"), and 2) The additional picture header which is attached is not incomplete (UFEP="001"). A packet which begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream, and signify their presence by setting P=1 in the payload header. Here is an example of encapsulating the first packet in a frame (without an attached redundant complete picture header): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | first two 0 bytes of the PSC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.2 Packets that begin with GBSC or SSC For a packet that begins at the location of a GOB or slice start code, PLEN may be zero or may be nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when picture header contents are very seldom likely to change (except as can be detected from the GFID syntax of H.263+), a redundant copy of the picture header is not required. However, in less ideal circumstances a redundant picture header should be attached for enhanced error resilience, and its presence is indicated by PLEN>0. Assuming a PLEN of 9 and P=1, below is an example of a packet that begins with a byte aligned GBSC or a SSC: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | starting with TR, PTYPE ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bitstream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data starting with GBSC/SSC without its first two 0 bytes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled if needed on the receiving end by prepending the sixteen leading '0' bits. 5.1.3 Packets that Begin with an EOS or EOSBS Code For a packet that begins with an EOS or EOSBS code, PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet. As with other packets beginning with start codes, the two all-zero bytes that begin the EOS or EOSBS code at the beginning of the packet shall be omitted, and their presence shall be indicated by setting the P bit to 1 in the payload header. System designers should be aware that some decoders may interpret the loss of a packet containing only EOS or EOSBS information as the loss of essential video data and may thus respond by not displaying some subsequent video information. Since EOS and EOSBS codes do not actually affect the decoding of video pictures, they are somewhat unnecessary to send at all. Because of the danger of misinterpretation of the loss of such a packet, encoders are generally to be discouraged from sending EOS and EOSBS. Below is an example of a packet containing an EOS code: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2 Encapsulating Follow-On Packet (P=0) A Follow-on packet contains a number of bytes of coded H.263+ data which does not start at a synchronization point. That is, a Follow-On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS header, and it may or may not start at a macroblock boundary. Since Follow-on packets do not start at synchronization points, the data at the beginning of a follow-on packet is not independently decodable. For such packets, P=0 always. If the preceding packet of a Follow-on packet got lost, the receiver may discard that Follow-on packet as well as all other following Follow-on packets. Better behavior, of course, would be for the receiver to scan the interior of the packet payload content to determine whether any start codes are found in the interior of the packet which can be used as resync points. The use of an attached copy of a picture header for a follow-on packet is useful only if the interior of the packet or some subsequent follow-on packet contains a resync code such as a GOB or slice start code. PLEN>0 is allowed, since it may allow resync in the interior of the packet. The decoder may also be resynchronized at the next segment or picture packet. Here is an example of a follow-on packet (with PLEN=0): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Use of this payload specification There is no syntactical difference between a picture segment packet and a Follow-on packet, other than the indication P=1 for picture segment or sequence ending packets and P=0 for Follow-on packets. See the following for a summary of the entire packet types and ways to distinguish between them. It is possible to distinguish between the different packet types by checking the P bit and the first 6 bits of the payload along with the header information. The following table shows the packet type for permutations of this information (see also the picture/GOB/Slice header descriptions in H.263+ for details): --------------+--------------+----------------------+------------------- First 6 bits | P-Bit | PLEN | Packet | Remarks of Payload |(payload hdr.)| | --------------+--------------+----------------------+------------------- 100000 | 1 | 0 | Picture | Typical Picture 100000 | 1 | > 0 | Picture | Note UFEP 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs Xxxxxx | 0 | 0 | Follow-on | Xxxxxx | 0 | > 0 | Follow-on | Interior Resync --------------+--------------+----------------------+------------------- See [4] for details regarding the possible values of the six bits (a "1" bit followed by a five bit GN field explicit or emulated) of GOB, Slice, EOS, and EOSBS codes. As defined in this specification, every start of a coded frame (as indicated by the presence of a PSC) has to be encapsulated as a picture segment packet. If the whole coded picture fits into one packet of reasonable size (which is dependent on the connection characteristics), this is the only type of packet that needs to be observed. Due to the high compression ratio achieved by H.263+ it is often possible to use this mechanism, especially for small spatial picture formats such as QCIF and typical Internet packet sizes around 1500 bytes. If the complete coded frame does not fit into a single packet, two different ways for the packetization may be chosen. In case of very low or zero packet loss probability, one or more Follow-on packets may be used for coding the rest of the picture. Doing so leads to minimal coding and packetization overhead as well as to an optimal use of the maximal packet size, but does not provide any added error resilience. The alternative is to break the picture into reasonably small partitions - called Segments - (by using the Slice or GOB mechanism), that do offer synchronization points. By doing so and using the Picture Segment payload with PLEN>0, decoding of the transmitted packets is possible even in such cases in which the Picture packet containing the picture header was lost (provided any necessary reference picture is available). Picture Segment packets can also be used in conjunction with Follow-on packets for large segment sizes. 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1], and any appropriate RTP profile (for example [2]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets >from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. A security review of this payload format found no additional considerations beyond those in the RTP specification. 8. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP : A Transport Protocol for Real-Time Applications," RFC 1889, January 1996. [2] H. Schulzrinne, "RTP Profile for Audio and Video Conference with Minimal Control," RFC 1890, January 1996. [3] "Video Coding for Low Bit Rate Communication," ITU-T Recommendation H.263, March 1996. [4] "Video Coding for Low Bit Rate Communication," ITU-T Recommendation H.263, January 1998. [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video Streams," RFC 2032, October 1996. [6] C. Zhu, "RTP Payload Format for H.263 Video Streams," RFC 2190, September 1997. [7] S. Wenger, "Video Redundancy Coding in H.263+," Proc. Audio-Visual Services over Packet Networks, Aberdeen, U.K., September 1997. From rem-conf Fri May 08 17:57:24 1998 From rem-conf-request@es.net Fri May 08 17:57:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yXxkX-0007VN-00; Fri, 8 May 1998 17:44:25 -0700 Received: from postoffice-lane0.cisco.com (postoffice.cisco.com) [171.69.197.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yXxkV-0007VC-00; Fri, 8 May 1998 17:44:23 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18603; Fri, 8 May 1998 17:42:51 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 May 1998 17:44:02 -0700 To: mbone@isi.edu, rem-conf@es.net From: Steve Deering Subject: MBone apps for Windows? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I could have sworn that I saw a message within the last week, *probably* sent to either the mbone or rem-conf mailing list, explaining where the most functional versions of vat/rat/vic/sdr/(wb?) for Windows can be found, but I can't seem to find that message in any of my folders. If someone knows the message I am talking about, would you please forward it to me (privately, assuming everyone else who might have been interested already saw it, and I'm the only idiot to lose it). (No, I haven't given up my Mac. I'm seeking the info for a colleague. :-) Steve From rem-conf Fri May 08 20:46:45 1998 From rem-conf-request@es.net Fri May 08 20:46:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yY0Tn-0000qK-00; Fri, 8 May 1998 20:39:19 -0700 Received: from proxy4.ba.best.com [206.184.139.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yY0Tm-0000qA-00; Fri, 8 May 1998 20:39:18 -0700 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12] (may be forged)) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id UAA14834; Fri, 8 May 1998 20:37:24 -0700 (PDT) Message-Id: <3.0.5.16.19980508192812.1b3f4e8c@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Fri, 08 May 1998 19:28:12 To: Steve Deering From: Ross Finlayson Subject: Re: MBone apps for Windows? Cc: mbone@isi.edu, rem-conf@es.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:44 PM 5/8/98 -0700, Steve Deering wrote: >I could have sworn that I saw a message within the last week, *probably* >sent to either the mbone or rem-conf mailing list, explaining where the >most functional versions of vat/rat/vic/sdr/(wb?) for Windows can be found, >but I can't seem to find that message in any of my folders. (I'm not 100% sure that I saw such a message, and this seems to be a frequently-asked question anyway, so I'm cc'ing to the "mbone" & "rem-conf" lists.) The most up-to-date versions of these tools appear to be the recent releases from University College, London. They have these versions listed in a table at (BTW, I've also bundled their versions of "vic", "rat", "wbd", and "nte" into a single self-extracting installer package; you can download this from . This may be more convenient for people in the U.S., during times of trans-Atlantic network congestion.) Ross. From rem-conf Fri May 08 20:56:00 1998 From rem-conf-request@es.net Fri May 08 20:56:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yY0i1-00017P-00; Fri, 8 May 1998 20:54:01 -0700 Received: from postoffice-lane0.cisco.com (postoffice.cisco.com) [171.69.197.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yY0i0-00015x-00; Fri, 8 May 1998 20:54:00 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA29762; Fri, 8 May 1998 20:52:27 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <3.0.5.16.19980508192812.1b3f4e8c@shell7.ba.best.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 May 1998 20:53:24 -0700 To: mbone@isi.edu, rem-conf@es.net From: Steve Deering Subject: Re: MBone apps for Windows? Cc: Ross Finlayson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A couple people sent me the message I was seeking; it was from Christophe Orlhac to the mbone list, dated 27 Apr, subject "Hardware for multicasting ?". It contained the following very useful URL: http://www.cs.ucl.ac.uk/staff/K.Hasler/shrimp/bin/ which Ross Finlayson also posted here. Thanks! Steve From rem-conf Sat May 09 03:48:46 1998 From rem-conf-request@es.net Sat May 09 03:48:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yY75F-00045u-00; Sat, 9 May 1998 03:42:25 -0700 Received: from mumrik.nada.kth.se [130.237.226.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yY75D-00045k-00; Sat, 9 May 1998 03:42:23 -0700 Received: from localhost (nv91-tob@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id MAA14859 for ; Sat, 9 May 1998 12:42:20 +0200 (MET DST) Date: Sat, 9 May 1998 12:42:20 +0200 (MET DST) From: =?ISO-8859-1?Q?Tobias_=D6brink?= Reply-To: =?ISO-8859-1?Q?Tobias_=D6brink?= To: rem-conf@es.net Subject: How to make start-up-scripts for vic? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mumrik.nada.kth.se id MAA14859 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all I'm (so far) not familiar with Tcl/Tk, but have been assigned the task to write a script that starts vic in Transmit-mode with a certain Quality and opens a receive-window of a certain format at a certain geometry.=20 In the man-page it says to use the -u argument to source an additional script, but I've no idea of what this script should look like. /Tobias .........................................................................= ... Tobias =D6brink Grad. Stud. Dept. of Teleinformatics, KTH Phone numbers: Paper mail address: +46 8 752 14 75 (IT, work) KTH-ELECTRUM/204 +46 8 751 17 93 (Fax) S-164 40 Kista Sweden E-mail: nv91-tob@it.kth.se URL: http://www.it.kth.se/~nv91-tob/ See if I'm logged in: http://www.it.kth.se/~nv91-tob/notice.html From rem-conf Sat May 09 08:13:52 1998 From rem-conf-request@es.net Sat May 09 08:13:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYBDk-0005xh-00; Sat, 9 May 1998 08:07:28 -0700 Received: from mail.netvision.net.il [194.90.1.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYBDi-0005xW-00; Sat, 9 May 1998 08:07:26 -0700 Received: from ts006p4.rvt.netvision.net.il (ts006p4.rvt.netvision.net.il [199.203.248.114]) by mail.netvision.net.il (8.9.0.Beta5/8.8.6) with SMTP id SAA21516 for ; Sat, 9 May 1998 18:07:17 +0300 (IDT) Received: by ts006p4.rvt.netvision.net.il with Microsoft Mail id <01BD8419.8C281D90@ts006p4.rvt.netvision.net.il>; Wed, 20 May 1998 18:03:09 +0300 Message-ID: <01BD8419.8C281D90@ts006p4.rvt.netvision.net.il> From: Gadi Ittach To: "'rem-conf@es.net'" Subject: Remove Date: Wed, 20 May 1998 18:02:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Remove From rem-conf Sat May 09 09:33:07 1998 From rem-conf-request@es.net Sat May 09 09:33:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYCVx-0006sn-00; Sat, 9 May 1998 09:30:21 -0700 Received: from imo26.mx.aol.com [198.81.17.70] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYCVw-0006sC-00; Sat, 9 May 1998 09:30:20 -0700 Received: from TSLGroup@aol.com by imo26.mx.aol.com (IMOv14.1) id CSATa02437 for ; Sat, 9 May 1998 12:29:14 -0400 (EDT) From: TSLGroup Message-ID: <470a6a82.3554845b@aol.com> Date: Sat, 9 May 1998 12:29:14 EDT To: rem-conf@es.net Mime-Version: 1.0 Subject: Remove Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL for Macintosh sub 133 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Sat May 09 16:50:34 1998 From rem-conf-request@es.net Sat May 09 16:50:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYJL7-0001ya-00; Sat, 9 May 1998 16:47:37 -0700 Received: from post.queensu.ca [130.15.126.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYJL6-0001yO-00; Sat, 9 May 1998 16:47:36 -0700 Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.8.8/8.8.8) with SMTP id TAA06063; Sat, 9 May 1998 19:48:49 -0400 (EDT) Received: from htm5.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA03679; Sat, 9 May 98 19:46:00 EDT Received: by htm5.queensu.ca (4.1/SMI-4.1) id AA10481; Sat, 9 May 98 19:45:52 EDT Date: Sat, 9 May 1998 19:45:52 -0400 (EDT) From: Hussein Mouftah X-Sender: mouftah@htm5 To: multicomm@research.panasonic.com, multicomm@cc.bellcore.com, comswtc@gmu.edu, atm@bbn, com@eleceng.ee.queensu.ca, ieeetcpc@ccvm.sunysb.edu, hipparch@sophia.inria.fr, rem-conf@es.net, commsoft@cc.bellcore.com, tccc@ieee.org, ietf@cnri.reston.va.us Subject: Call for Participation (IEEE) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE SYMPOSIUM ON PLANNING AND DESIGN OF BROADBAND NETWORKS Montebello, Quebec, Canada October 8-11, 1998 CALL FOR PARTICIPATION The third IEEE Symposium on Planning and Design of Broadband Networks will be held at Le Chateau Montebello, Montebello, Quebec, Canada on October 8-11, 1998. The first two Symposia, held in October 1994 and 1996, were an outstanding success with representation from North America, Europe and Asia. The purpose of this symposium is to provide an environment for the discussion and exchange of ideas concerning computer-aided planning and design techniques and tools for broadband networks. The symposium will include both invited and contributed talks, panel discussions, and demonstrations of broadband network planning and design tools. This year, the symposium will also include a strong focus on the application of design tools and contributors are encouraged to display their applications at the exhibition. Abstracts of all presentations will also be distributed at the symposium. The symposium will address topics in the following areas: * Challenges in broadband network planning and design * Simulation methodologies and tools for planning and design of broadband networks * Tool applications and deployment case studies Please submit by July 15th, 1998, 5 copies of the abstract of proposed talk or demos to the Technical Program Chairman: Professor Hussein Mouftah, Department of Electrical and Computer Engineering, Queen's University, Kingston, Ontario, Canada K7L 3N6, Telephone: (613) 545-2934, Fax: (613) 545-6615 EMAIL: mouftah@eleceng.ee.queensu.ca For further information please contact: Ibrahim Gedeon, Symposium Chair, Nortel 1431 Merivale Road, Nepean, P.O. Box 5080, Station F, Ottawa, Ontario, Canada K2C 3T1 Tel: 613 723 4928 Fax: 613 723 4028 Email: ibgedeon@nortel.com Organizing Committee: Secretary/Treasurer: John Hopkins (Nortel Technology) Publicity: Kathy Mahoney (Ottawa Centre for Research and Innovation) IEEE Ottawa Chairperson: Hala Tabl Symposium Secretariat and Local Arrangments: Ms. Amy Riordon Jarette c/o OCRI, 36 Steacie Drive, Kanata, Ontario, Canada K2K 2A9 Tel: 613 592 8160 Ext.224 Fax: 613 592 5130 Email: ariordon@ocri.ca Technical Program Committee: Chair : Hussein Mouftah (Queen's University) Richard Vickers (Nortel Technology) Thomas Chen (Southern Methodist University) Steven Katz (Lucent Technologies Bell Labs) Kenichi Sato ( NTT) From rem-conf Sun May 10 00:13:10 1998 From rem-conf-request@es.net Sun May 10 00:13:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYQ7H-0004NW-00; Sun, 10 May 1998 00:01:47 -0700 Received: from adm.ict.nsk.su (adm.ict.nsc.ru) [193.124.243.71] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYQ7D-0004NL-00; Sun, 10 May 1998 00:01:45 -0700 Received: from Lab22-3.ict.nsc.ru (lab22-3.ict.nsk.su [193.124.243.60]) by adm.ict.nsc.ru (8.8.7/8.8.7) with SMTP id OAA03656; Sun, 10 May 1998 14:01:09 +0700 (NSS) (envelope-from chubarov@adm.ict.nsc.ru) Message-Id: <199805100701.OAA03656@adm.ict.nsc.ru> Reply-To: "chubarov" From: "chubarov" To: "TSLGroup" , Subject: Îòâåò: Remove Date: Sun, 10 May 1998 14:01:08 +0600 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove ______________________________________________ Dr. Leonid B. Chubarov, Head of Laboratory Institute of Computational Technologies SB RAS, Ac. Lavrentjev Ave., 6, Novosibirsk, RUSSIA Phone: 7(3832) 344470, Fax: 7(3832) 341342, E-mail: chubarov@adm.ict.nsc.ru http://www.ict.nsk.su/lab2.2/eng/people/chubarov.html -----Èñõîäíîå ñîîáùåíèå----- Îò: TSLGroup Êîìó: rem-conf@es.net Äàòà: 9 ìàÿ 1998 ã. 22:40 Òåìà: Remove > > From rem-conf Sun May 10 09:39:47 1998 From rem-conf-request@es.net Sun May 10 09:39:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYZ0T-0000Ba-00; Sun, 10 May 1998 09:31:21 -0700 Received: from colmar.uha.fr [194.167.107.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYZ0N-0000BN-00; Sun, 10 May 1998 09:31:16 -0700 Received: from [194.167.107.40] (gtrmac2.colmar.uha.fr [194.167.107.40]) by colmar.uha.fr (8.8.8/8.8.8) with ESMTP id SAA25304; Sun, 10 May 1998 18:25:32 +0100 (WET DST) X-Sender: lorenz@colmar.uha.fr Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 May 1998 18:28:16 +0000 To: atm2:; From: conf@colmar.uha.fr (by way of Pascal LORENZ) Subject: Call for Participation X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE International Conference on ATM ICATM'98 June 22-24, 1998 - Colmar, France http://iutsun1.colmar.uha.fr/ICATM98.html 08:00 - 19:00 Conference Registration _____________________________________________________ Monday June 22 09:00 - 09:20 Opening Address 09:20 - 10:30 Plenary Session 1 Chair: G. Pujolle IP or ATM versus IP over ATM : the Role of the ATM Forum and the IETF in Setting Standards S. Ritzenthaler, Newbridge, France 10:30 - 11:00 Coffee Break 11:00 - 12:30 Plenary Session 2 Chair: J.P. Coudreuse IETF Multiprotocol Label Switching (MPLS) Architecture =46. Le Faucheur, Cisco, France 12:30 - 14:00 Lunch - Restaurant Universitai= re 14:00 - 15:30 Plenary Session 3 Chair: P. Rolin ATM for Wireless Networks B. Bing, Ngee Ann Polytechnic, Singapore 14:00 - 15:30 Plenary Session 4 Chair: P. Lorenz =46ourth generation ATM switches for public carrier and their role for telephone service at the transit exchange level M. Dickmann, Siemens, France 15:30 - 16:00 Coffee Break and exhibitions 16:00 - 17:30 Wireless ATM 1 Chair: G. Pujolle Power Saving Mode of Operation in the WATM MAC Protocol G. Sfikas, C. Apostolas, R. Tafozolli, University of Surrey, UK Support for Multimedia Applications in a Wireless ATM System A. Kassler, A. Lupper, University of Ulm, Germany LMDS Systems: a possible solution for Wireless ATM Access Networks B. Conaglia, R. Santaniello, CSELT, Italy ; E. Leonardi, R. Lo Cigno, M. Meo, F. Neri, D. Saracino, Politecnico di Torino, Italy 16:00 - 17:30 Video 1 Chair: J.J. Pansiot Scalable Video on Demand on ABR in ATM Networks K. Ben Younes, University of Erlangen-Nuremberg, Germany ; K. Begain, Mu'tah, Jordan MPEG Video Aggregation over ABR-ATM J.M. Forn=E9s, J.A. Ternero, F.R. Rubio, University of Sevilla, Spain Efficient Connection Admission Control for Real Time Video Multiplexing A.M. Ibrahim, ENST, France 17:30 - 18:00 Coffee Break and exhibitions 18:00 - 19:30 Wireless ATM 2 Chair: G. Pujolle A New Approach for Combined Performance Evaluation of Wireless ATM at Channel and Higher Protocol Levels K. Ben Younes, University of Erlangen-Nuremberg, Germany ; W. Franz, Communication technology, Germany ; B. Girod, University of Erlangen-Nuremberg, Germany BAAWAM with Wireless Specific Quality of Service J. Ben-Othman, K. Boussetta, A. Gueroui, University of Versailles, France Authentication Protocols for Wireless ATM Networks D. Patiyoot, S.J. Shepherd, University of Bradford, UK 18:00 - 19:30 Video 2 Chair: J.J. Pansiot Performance Evaluation of Cell Discarding Mechanisms for Hierarchical VBR MPEG-2 Video Traffic over ATM Networks P. Cuenca, R. Casado, A. Garrido, F. Quiles, University of Castilla-La Mancha, Spain ; L. Orozco-Barbosa, University of Ottawa, Canada Multiple Leaky Buckets with Buffer Sharing for MPEG Video in ATM Networks Y.C. Ouyang, J.L.Sun, University of Chung Hsing, Taiwan An Experimental Study for Transmitting MPEG-2 Streams over ATM Networks =46. Meylan, L.G. Kiatake, M.Z. Santos, S.T. Kofuji, University of Sao Paulo= , Brazil ; J.P. Courtiat, LAAS, France 20:00 Reception _____________________________________________________ Tuesday June 23 09:00 - 10:30 Traffic Control Chair: J. Halpern =46low Control and Bandwidth Management in Next Generation Internets C.M. Pazos, M. Gerla, UCLA, USA ; G. Rigolio, Italtel, Italy Analysis and Simulation on a Recently proposed Flow Control Algorithm for ATM Network: Phantom E.R. Ruh, M. Juanatey, F. D'Alvano, University of Simon Bolivar, Venezuela A Measurement Based Connection Admission Control for ATM Networks M. Zukerman, T.K. Lee, University of Melbourne, Australia 09:00 - 10:30 Multicast Chair: J.J. Pansiot Dynamic Multicast on Loss Networks W.K. Liao, L.M. Ni, Michigan State University, USA Batcher Banyan Network with Cell Copy Preparation Stages for Multicast Switching S. Takagi, Y. Tanaka, H. Tominaga, Waseda University, Japan CRAM: Cell Re-labeling at Merge-points for ATM Multicast J. Crowcroft, University College London, UK ; S. Komandur, D. Mosse, University of Pittsburgh, USA 10:30 - 11:00 Coffee Break and exhibitions 11:00 - 12:30 Real-time traffic Chair: J.P. Coudreuse Issues on Connection Allocation for Supporting Distributed Real-Time Systems on ATM Networks Z. Mammeri, University of Le Havre, France A Real-Time Communication Service for ATM-based Distributed Systems C. Lizzi, J. Montiel, CS Technology, France ; E. Gressier-Soudan, CNAM, Fran= ce An Architecture For Flexible High Level Communication Services B. Maaref, S. Nasri, P. Sicard, IMAG, France 11:00 - 12:30 Interconnection Chair: P. Rolin Design and Applications of ATM LAN/WAN Adapters D. Bonjour, G. De Hauteclocque, J. Le Moal, CNET, France Network Interworking for Narrowband Services over an ATM Network H. Park, Y.I. Choi, Y.K. Lee, Electronics and Telecommunications Research Institute, Korea On the Design of a High-Performance ATM Bridge W.T. Chen, Y.W. Deng, C.P. Wang, N.F. Huang, H.C. Lin, C.C. Lu, National Tsing Hua University, Taiwan ; R.C. Chang, National Taiwan University of Science and Technology, Taiwan 12:30 - 14:00 Lunch - Restaurant Universitai= re 14:00 - 15:30 Traffic 1 Chair: K. Begain A Detailed Experimental Performance Evaluation on TCP over UBR L. Jaussi, EPFL, Switzerland ; M. Lorang, University of Stuttgart, Germany ; J. Nelissen, Alcatel Alsthom, Belgium Scaling of ABR Parameters using a Parallel Control Scheme in ATM Networks Q.L. Ding, Centre for Wireless Communications, Singapore ; S.C. Liew, Chinese University of Hong Kong, Hong Kong Application of AR Based Model in Proactive Management of VBR Traffic T.S. Randhawa, Applied Digital Access, Canada ; R.H.S. Hardy, Simon Fraser University, Canada 14:00 - 15:30 Modelization Chair: Z. Mammeri A Top-Down Operations Model for ADSL and ATM Based Access Networks T.K. Lu, DSC Communications, USA =46PGA Implementation of a Scalable Shared Buffer ATM Switch J.W. Shim, G.J. Jeong, , M.K. Lee, Yonsei University, Korea ; S.H. Ahn, Hyundai Electronics Industries Co., Korea =46air Queuing for Input-Buffered Switches with Back Pressure S. Li, N. Ansari, New Jersey Institute of Technologies, USA ; J.G. Chen, Lucent Technologies, USA 15:30 - 16:00 Coffee Break and OASICE exhibitions 16:00 - 17:30 Traffic 2 Chair: K. Begain A Dynamic Call Admission Scheme for VBR Traffic in ATM Networks S. Ramaswamy, Newbridge Networks, Canada ; and P. Gburzynski, University of Alberta, Canada Multi-Layer Simulation Approach for Evaluation of Data service Support in ATM Networks L. Guijarro, V. Pla, J.R. Vidal, J. Martinez, Polytechnic University of Valencia, Spain On the Applicability and Utility of Gaussian models for Broadband Traffic R.G. Addie, University of Southern Queensland, Australia 16:00 - 17:30 Quality of Service 1 Chair: S. Ritzenthaler QoS Control: an Application Integrated Framework J. Bom, P. Marquest, INESC, Portugal ; M. Correia, P. Pinto, University of Lisboa, Portugal A Dynamic Bandwidth Allocation for ATM-based Networks Supporting Multimedia Applications A.L. Diniz, J.M. Nogueira, Federal University of Minas Gerais, Brazil ; C.C. Goulart, Federal University of Vi=E7osa, Brazil Interaction Approaches for Internet and ATM Quality of Service Architectures J. Schmitt, L. Wolf, R. Steinmetz, University of Darmstadt, Germany, C. Siebel, Y.O. Lorcy, Deutsche Telekom, Germany 17:30 - 18:00 Coffee Break and OASICE exhibitions 18:00 - 19:30 Quality of Service 2 Chair: S. Ritzenthaler Priority Encoding of Video Data over ATM K.K. Lau, M.H. Lee, K.N. Ngan, University of Western Australia, Australia ; G. Rogers, CSIRO, Australia Communication Application Programming Interfaces with Quality of Service Support R. Eberhardt, C. Rue=DF, Daimler-Benz, Germany ; R. Rusnak, Artem, Germany Agents Based Approach for QoS Adaptation in Distributed Multimedia Applications over ATM Networks =46. Nait-Abdesselam, N. Agoulmine, University of Versailles-Saint Quentin e= n Yveline, France ; K. Kasiolas, University of Western Ontario, Canada 18:00 - 19:30 Flow Control in ATM : ABR Chair: R. Muraine ABR Traffic Control in ATM Networks using Optimal Control Theory B.K. Kim, C. Thompson, University of Massachusetts, USA A Simulator for and Result of Comparing ABR Flow Controls for ATM E.C. Foudriat, K. Maly, M. Hou, Old Dominion University, USA The ABR Congestion Control by the Least Squares Estimation of Spatial Distribution of Sources B.G. Kim, G. Pecelli, University of Mass. Lowell, USA 20:00 Gala Dinner _____________________________________________________ Wednesday June 24 09:00 - 10:30 User applications 1 Chair: M. Potts Intelligent Building Systems: System Integration using ATM E. Stipidis, S. Li, E.T. Powner, University of Sussex, UK NETrix: A procedure for the Calculation of the Network Structure and Traffic Matrix in ATM Networks A.E. Garcia, K.D. Hackbarth, University of Cantabria, Spain The LAN-E Network of the Fraunhofer Institute for Computer Graphics M. G=E4rtner, B. Tritsch, Fraunhofer Institute, Germany 09:00 - 10:30 Protocols 1 Chair: P. Lorenz Proxy PNNI Augmented Routing (Proxy PAR) T. Przygienda, Lucent Technologies, USA ; P. Droz, C. West, IBM Research Division, Switzerland Routing in a Hierarchical Structure P. Van Mieghem, Alcatel Corporate Research, Belgium A Hybrid Spanning Tree Algorithm for Efficient Topology Distribution in PNNI E. Basturk, Pluris, USA ; P. Stirpe, Reuters, USA 10:30 - 11:00 Coffee Break and exhibitions 11:00 - 12:30 User applications 2 Chair: M. Potts A Design and Implementation of Home PC for Interactive Multimedia Services J.H. Lee, Electronics and Telecommunication Research Institute, Korea IP "Telephony" versus ATM: What is There to discuss ? S. Wright, R. Onvural, Fujitsu Network Communications, USA Performance measurements on an ATM-based Metropolitan Area Network : OASICE Case Study H. Tobiet, Clemessy, France ; P. Lorenz, University of Haute Alsace, France 11:00 - 12:30 Protocols 2 Chair: J. Halpern Cells in Frames: ATM over Legacy Networks M. Shore, J. Veronneau, T. Parker, D. Cogger, Cornell University, USA Resource Location in Mobile ATM Networks L. Frel=E9choux, D. Dykeman, I. Iliadis, P. Scotton, IBM Research Laboratory= , Switzerland Native ATM support for CORBA Platforms A. Puder, M. Moscarda, University of Berkeley, USA 12:30 - 14:00 Lunch - Restaurant Universitai= re 14:00 - 15:30 IP over ATM 1 Chair: D. Bonjour IPv6 over ATM Flow-Handling M.V. Loukola, Helsinki University of Technology, Finland TCP/IP over ATM Challenges in Enterprise Network Integration S. Yousef, C. Strange, Anglia Polytechnic University, UK IP Switch over ATM and LAN Emulation (IP-Express) M. Bavant, M. Delattre, O. Gibergues, Thomson-CSF, France 14:00 - 15:30 Performance 1 Chair: H. Tobiet A Large-Scale ATM Switch: Analysis, Simulation and Implementation H.S. Yoon, Samsung Electronics Co., Korea TCP Performance over ATM on Linux and Windows NT M. Borriss, U. Dannowski, H. H=E4rtig, Dresden University of Technigy, Germa= ny Performance Evaluation of Frame Discard Strategies in ATM Networks C.M. Wu, Napier University, UK 15:30 - 16:00 Coffee Break and exhibitions 16:00 - 18:00 IP over ATM 2 Chair: D. Bonjour A Way to Accommodate IP Services in ATM Access Networks J.O. Kim, H.S. Choi, I.K. Kim, J.H. Lee, H.J. Kim, Electronics and Telecommunications Research Institute, Korea A Study on Accommodation of TCP/IP Traffic using Window Scale Option to International ATM Network with VBR Service Category S. Ano, T. Hasegawa, T. Kato, K. Narita, K. Hokamura, Kokusai Denshin Denwa Co. ; Japan Extension of Classical IP over ATM to Support QoS at the Application Level S. Martignoni, T. K=FChnel, Ascom Autelca AG, Switzerland Smart IP Switching: a Hybrid System for Fast IP-based Network Backbones D. Lloyd, Telenor RDI, Ireland ; D. O'Mahony, Trinity College, Ireland 16:00 - 18:00 Performance 2 Chair: H. Tobiet Comprehensive In-Service Measurement of QoS P. Kelley, Net2Net Corporation, USA The Variable Bandwidth Virtual Path ATM Network and its Self-healing Performance K. Wipusitwarakun, H. Tode, H. Ikeda, University of Osaka, Japan Simulation Study of AAL Type 2 M. Han, A.A. Nilsson, North Carolina State University, USA Performance Implications of QoS Mapping in Heterogeneous Networks Involving ATM P. Francis-Cobley, N. Davies, University of Bristol, UK 18:00 Closing Session From rem-conf Sun May 10 23:27:58 1998 From rem-conf-request@es.net Sun May 10 23:27:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYlrn-00044w-00; Sun, 10 May 1998 23:15:15 -0700 Received: from mail.multitech.com (multitech.com) [204.26.122.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYlrl-00044b-00; Sun, 10 May 1998 23:15:13 -0700 Received: from multitech.com ([192.168.11.250]) by gateway.multitech.com with ESMTP id <16131>; Mon, 11 May 1998 01:38:18 -0500 Received: from Microsoft Mail (PU Serial #1944) by multitech.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998May10.011100.1944.402278; Mon, 11 May 1998 01:22:22 -0500 From: NAVEENKUMA@multitech.com (Naveen Kumar R) To: rem-conf@es.net Message-ID: <1998May10.011100.1944.402278@multitech.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Multi-Tech Systems, Inc. Date: Mon, 11 May 1998 01:22:22 -0500 Subject: remove X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Mon May 11 03:59:24 1998 From rem-conf-request@es.net Mon May 11 03:59:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYq9Z-00064r-00; Mon, 11 May 1998 03:49:53 -0700 Received: from imo25.mx.aol.com [198.81.17.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYq9Y-000631-00; Mon, 11 May 1998 03:49:52 -0700 Received: from TSLGroup@aol.com by imo25.mx.aol.com (IMOv14.1) id CHTAa03031 for ; Mon, 11 May 1998 06:48:29 -0400 (EDT) From: TSLGroup Message-ID: <997622b9.3556d77f@aol.com> Date: Mon, 11 May 1998 06:48:29 EDT To: rem-conf@es.net Mime-Version: 1.0 Subject: Remove Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL for Macintosh sub 133 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Mon May 11 04:53:41 1998 From rem-conf-request@es.net Mon May 11 04:53:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYr6B-00073M-00; Mon, 11 May 1998 04:50:27 -0700 Received: from relay.cs.tcd.ie [134.226.32.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYr69-00073B-00; Mon, 11 May 1998 04:50:25 -0700 Received: from cs.tcd.ie (venus.dsg.cs.tcd.ie [134.226.36.132]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id MAA03684; Mon, 11 May 1998 12:44:31 +0100 (BST) Message-ID: <3556E637.D45B302B@cs.tcd.ie> Date: Mon, 11 May 1998 12:51:19 +0100 From: Paddy Nixon Organization: Trinity College Dublin X-Mailer: Mozilla 4.02 [en] (WinNT; I) MIME-Version: 1.0 To: "KOBRYN, Cris" CC: "'commsoft@cc.bellcore.com'" , "'bomsig@omg.org'" , "'adtf@omg.org'" , "'mof@omg.org'" , "'tc@omg.org'" , "'ptc@omg.org'" , "'dtc@omg.org'" , "'ab@omg.org'" , "'mof-rtf@omg.org'" , "'odp@dstc.edu.au'" , "'dbworld@cs.wisc.edu'" , "'enternet@BBN.COM'" , "'JavaCORBA@luke.org'" , "'ISWORLD@Danann.hea.ie'" , "'comsoc-chapters@IEEE.ORG'" , "'comsoc-gicb@IEEE.ORG'" , "'comsoc.tac@tab.ieee.org'" , "'comswtc@gmu.edu'" , "'ctc-members@redbank.tinac.com'" , "'end2end-interest@isi.edu'" , "'f-troup@codex.cis.upenn.edu'" , "'fokus-user@fokus.gmd.de'" , "'g-troup@ccrc.wustl.edu'" , "'giga@tele.pitt.edu'" , "'hipparch@sophia.inria.fr'" , "'ieee_rtc_list@cs.tamu.edu'" , "'ieeetcpc@ccvm.sunysb.edu'" , "'isadsoc@fokus.gmd.de'" , "'itc@fokus.gmd.de'" , "'modern-heuristics@uk.ac.mailbase'" , "'multicomm@cc.bellcore.com'" , "'osimcast@BBN.COM'" , "'rem-conf@es.net'" , "'reres@laas.fr'" , "'sb.all@IEEE.ORG'" , "'sc6wg4@ntd.comsat.com'" , "'sigmedia@bellcore.com'" , "'tccc@IEEE.ORG'" , "'xtp-relay@cs.concordia.ca'" Subject: CFP: Objects, Components and the Virtual Enterprise References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list First Call for Papers Objects, Components and the Virtual Enterprise An Interdisciplinary Workshop at OOPSLA'98, Vancouver (CA) http://www.cs.tcd.ie/Virtues/ocve98/ Monday 19 October 1998 We are currently witnessing a convergence of several threads of technology and business imperatives. The idea of a virtual enterprise - a business built from both organisationally and geographically distributed units - is becoming an area of increasing interest to both computer scientists and business people. Virtual enterprises are becoming feasible on account of technology phenomena including CORBA, the World Wide Web, Java and component-based software; they are becoming attractive because of business trends such as downsizing and outsourcing. Set against these positive factors are a number of disincentives, including exposing key business processes to the hostile Internet, the extra complexities of cross-border contracts, and the fluidity of the software marketplace. >From a technical perspective, building a virtual enterprise involves confronting problems such as heterogeneity, distribution, authentication, privacy, and auditing. From a business perspective it involves contracts, cross-organisational management and statutory obligations. Within the object oriented arena solutions exist to each of these problems, but their integration is still elusive. So, given that the ingredients exist, what is the recipe? And what is the final dish? Aims The workshop aims to bring together a complementary group of practitioners and researchers from a range of fields with a common interest in constructing virtual enterprises. The intention is to facilitate the exchange of ideas between those working on the general problems of dynamic component integration and those with specific practical problems to solve or experiences to offer. The workshop will thus be of interest to practising software engineers, to researchers in workflow, component-based software and software methodologies, and to business people interested in the new oportunities being facilitated by these new technologies. The specific goals of the workshop are: * to identify those factors - technological, managerial and political - which impede the creation of virtual enterprises through the use object technology; * to identify any new business models which emerge from improving business communication and interaction; and * to draw a road map of projected future developments, to aid the development of strategies for deploying virtual enterprises. Workshop format The workshop is a full day event comprising an invited "scene-setting" lecture by a speaker from outside computer science, a small set of presentations selected from the submitted position papers, and targetted discussion sessions addressing the important emerging themes. Topics of interest for position papers include, but are not restricted to: * object methodologies for building the virtual enterprise; * software frameworks and infrastructures; * economic models; * managing business processes in the virtual enterprise; * applications to large-scale scientific collaborations; and * experiences in building existing virtual enterprises. Proceedings All position papers will be made available to workshop attendees on the day. A post-workshop proceedings will be published both electronically and in book form. It will include a selection of the best papers, a summary and commentary on the meeting. Attendance Submission of a position paper is a condition of attendence. A representative selection will be chosen by the committee for presentation. The number of attendees will be limited to around fifty to facilitate discussion. Submission of position papers : 14 August 1998 Notification of selection for presentation : 31 August 1998 Workshop date : 19 October 1998 A position should be 6 pages maximum (including diagrams and references). Papers should be submitted to Simon Dobson (address below). Electronic submission is strongly encouraged. Organising committee Paddy Nixon (Chairman) Trinity College Dublin, IE Simon Dobson Trinity College Dublin, IE and CLRC Rutherford Appleton Laboratory, UK Ian Gorton Transarc Corporation, AU Spyros Lalis ICS-FORTH, GR Oliver Sims SSA Object Technology, UK Vincent Wade Trinity College Dublin, IE David Zenie NIIIP, USA Contacts Further information: Paper submissions: Dr Paddy Nixon Dr Simon Dobson Department of Computer Science Department of Computer Science Trinity College Trinity College Dublin 2, Ireland Dublin 2, Ireland Tel: (+353)-1-608-2666 Tel: (+353)-1-608-2224 Fax:(+353)-1-677-2204 Fax:(+353)-1-677-2204 paddy.nixon@cs.tcd.ie simon.dobson@cs.tcd.ie http://www.cs.tcd.ie/Paddy.Nixon/ http://www.cs.tcd.ie/Simon.Dobson/ -- _____________________________________________________________________ Dr. Paddy Nixon Department of Computer Science The Warden Trinity College Trinity Hall Dublin 2, Ireland Dartry Road Tel: (+353)-01-608-2666 Dublin 6, Ireland Fax: (+353)-01-677-2204 Tel:(+353)-01-497-1772 Email: Paddy.Nixon@cs.tcd.ie WWW: http://www.dsg.cs.tcd.ie/~pnixon/ From rem-conf Mon May 11 06:10:49 1998 From rem-conf-request@es.net Mon May 11 06:10:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYsGB-0000On-00; Mon, 11 May 1998 06:04:51 -0700 Received: from cagw1.att.com (att.com) [192.128.52.89] by mail1.es.net with smtp (Exim 1.81 #2) id 0yYsG9-0000Od-00; Mon, 11 May 1998 06:04:49 -0700 Received: by cagw1.att.com; Mon May 11 08:57 EDT 1998 Received: from njb140r1.ems.att.com (njb140r1.ems.att.com [135.65.202.58]) by caig1.att.att.com (AT&T/GW-1.0) with SMTP id JAA11643 for ; Mon, 11 May 1998 09:04:42 -0400 (EDT) Received: from njb140bh3.ems.att.com by njb140r1.ems.att.com (SMI-8.6/EMS-1.2 sol2) id JAA08123; Mon, 11 May 1998 09:03:05 -0400 Message-Id: <199805111303.JAA08123@njb140r1.ems.att.com> Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.1960.3) id ; Mon, 11 May 1998 09:04:41 -0400 From: "Hussain, Arshad, NPG NNAD" To: rem-conf@es.net Subject: Remove. Date: Mon, 11 May 1998 09:04:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list please remove me from your mailing list. Arshad Hussain AT&T 3F-531A 101 Crawfords Corner Road Holmdel, NJ 07733-3030 Tel: 732-949-4441 Fax: 732-949-4632 From rem-conf Mon May 11 08:31:01 1998 From rem-conf-request@es.net Mon May 11 08:31:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYuRg-00024x-00; Mon, 11 May 1998 08:24:52 -0700 Received: from smile.es.net (es.net) [147.155.137.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYuRf-00024n-00; Mon, 11 May 1998 08:24:51 -0700 Sender: metzger@es.net Message-ID: <35571842.BA785FB8@es.net> Date: Mon, 11 May 1998 10:24:50 -0500 From: Joe Metzger Organization: ESnet X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: Mailing List Trivia Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The rem-conf@es.net mailing list is maintained with software, not by a person. If you would like to get off the list, please send mail to rem-conf-REQUEST@es.net, not to the list. The list administrators at ESnet rarely read the list. If you have questions or comments for us, send them to rem-conf-request@es.net, not to the list. Thank You. -- Joe Metzger metzger@es.net Network Information Services Group ESnet, Lawrence Berkeley National Laboratory From rem-conf Mon May 11 10:54:57 1998 From rem-conf-request@es.net Mon May 11 10:54:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYwgn-00040G-00; Mon, 11 May 1998 10:48:37 -0700 Received: from bsu.edu (wizard.bsu.edu) [147.226.53.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYwgm-000406-00; Mon, 11 May 1998 10:48:36 -0700 Received: from bsu-cs.bsu.edu (bsu-cs.bsu.edu [147.226.112.101]) by wizard.bsu.edu (8.8.7/8.8.7) with ESMTP id MAA19343 for ; Mon, 11 May 1998 12:50:03 -0500 (EST) Received: (from lguo@localhost) by bsu-cs.bsu.edu (8.8.7/8.8.7) id MAA05194 for rem-conf@es.net; Mon, 11 May 1998 12:51:20 -0500 (EST) Date: Mon, 11 May 1998 12:51:20 -0500 (EST) From: Lijia Guo Message-Id: <199805111751.MAA05194@bsu-cs.bsu.edu> To: rem-conf@es.net Subject: : Remove X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Mon May 11 11:26:34 1998 From rem-conf-request@es.net Mon May 11 11:26:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYxE9-0004tr-00; Mon, 11 May 1998 11:23:05 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYxE8-0004tA-00; Mon, 11 May 1998 11:23:04 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA24613; Mon, 11 May 1998 11:21:57 -0700 (PDT) Date: Mon, 11 May 1998 11:22:10 -0700 (Pacific Daylight Time) From: Stephen Casner To: Vahe Balabanian cc: rem-conf@es.net Subject: Re: AVT Consensus on MPEG4/DMIF In-Reply-To: Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Responding to Vahe Balabanian's summary of approaches for RTP/MPEG4: Vahe, I think you have covered the space of options pretty well. Your use of the term "AVT" is a bit fuzzy in some instances, as explained in a couple of the following comments. > 1- MPEG-4 divides the screen into AudioVisualObjects > (AVO) each having a desired shape (including geometric > and natural shapes) and multiplicity of coded streams > to be chosen from by the receiving end-user. > > Analysis: This approach is useful to AVT for enabling > an end-user to adapt its viewing to changing network > conditions. Here I think AVT means "RTP applications". This network adaptivity is not a function built into RTP (at least not yet), but is a matter of the application choosing the appropriate streams. One might say this selection is enabled by performance measurement done at the receiver and perhaps sent back to the source using RTCP. Here is a case where sending in separate RTP streams is important (at least for multicast) so selection of RTP streams can be used to control the incoming data rate. > the receiver. The similarities of MPEG-4 and AVT in this > area are in the equivalence of GF-RTP to the MPEG-4 stream > and the SDP to the Scene and Object Descriptor. Except in > the latter case SDP is a queried entity as opposed to a > stream. I think the division of information between static out-of-band delivery and in-band delivery is an important question for RTP with respect to generic payload formats, and for MPEG-4 (especially for multicast) even if RTP were not used at all. > 1- The abstract DMIF Application Interface (DAI) isolates > MPEG-4 from the underlying delivery mechanisms. In this > DAI makes use of a media-based QoS (expressed in access > unit metrics of priority, loss, delay and jitter) and an > explicit format description for each stream. > > Analysis: This is useful to AVT in maintaining applications > intact while transiting from IPV4 to IPV6 and adopting > multiple implementations of the TOS byte to carry Diff Serv > information. RTP is already independent of IPv4 vs IPv6. It does not address QoS APIs at all. So this is not exactly an AVT working group concern. Applications using RTP may want to use QoS and therefore they would need to use protocols from other working groups (RSVP, Diff-Serv). One problem here is the DMIF is primarily an API, not a protocol. IETF work focusses on protocols and only occasionally considers APIs. > 2- DMIF allows tagging of resources used in a given > presentation session. The tags are used to log and apply > policy to multiple streams on different source and > destination addresses and over different networks. > > Analysis: As IETF is moving towards usage accountability > with RSVP, this concept allows the collection of usage > information for a given presentation. A joint server and > client policy can thus be applied to limit the usage of > resources for a given presentation. This is again outside the bounds of AVT. > 3- DMIF allows efficient and agile packing of streams > into transports and the reuse of existing transports to > reduce the visual impact of addition of new higher > priority streams at the expense of existing lower > priority streams. DMIF allows an expression of priority with the goal of achieving the desired visual impact, but it depends on the implementation to and the protocols actually achieve that. I think this is where some of the pushback from RTP may come -- that in order to achive the desired goal, some changes might be needed above the DAI. > expertise. DMIF could be used to regulate the stream traffic > on Internet in a similar fashion to regulating its TCP traffic. Again, I think the key part of achieving this goal is in the protocols and mechanisms below the API, not in the API itself. > Analysis: The stream formats in MPEG-4 cover a wide range of > timestamps and clocks including implicit timestamps. It may > be possible to subset these for operation over RTP. This > argues for the creation of MPEG-4 profile for RTP. But this > breaks the clean separation adopted in DMIF for isolating the > applications from the delivery mechanisms, thus MPEG-4 profiles > are normally reserved to applications and not to transports. > But one can argue that within the confines of the RTP subset, > the DAI principle can still be applied across both the storage > and broadcast media. As experience is gained with RTP the subset > can be enlarged to encompass more of MPEG-4. This is where we really need to learn more on both sides. How flexible are the boundaries? Is it important to solve all the problems and scenarios that MPEG-4 has taken on in the RTP context, or is it reasonable to say that some we just don't expect to solve some of those problems or support some of those scenarios across the Internet. That is, is the problem too hard just because we artificially made it so? -- Steve From rem-conf Mon May 11 12:49:13 1998 From rem-conf-request@es.net Mon May 11 12:49:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYyVp-0006Id-00; Mon, 11 May 1998 12:45:25 -0700 Received: from yfn2.ysu.edu [150.134.50.6] (exim) by mail1.es.net with smtp (Exim 1.81 #2) id 0yYyVo-0006IT-00; Mon, 11 May 1998 12:45:24 -0700 Received: from as715 by yfn2.ysu.edu with local (Exim 1.62 #2) id 0yYydD-0002TP-00; Mon, 11 May 1998 15:53:03 -0400 From: as715@yfn.ysu.edu (John Meeks) To: rem-conf@es.net Subject: remove Reply-To: as715@yfn.ysu.edu Message-Id: Date: Mon, 11 May 1998 15:53:03 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list please remove me from the list john meeks as715@yfn.ysu.edu thanks From rem-conf Mon May 11 13:09:09 1998 From rem-conf-request@es.net Mon May 11 13:09:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yYyrJ-000736-00; Mon, 11 May 1998 13:07:37 -0700 Received: from inetgw.fs.lmco.com [204.177.125.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yYyrI-00072j-00; Mon, 11 May 1998 13:07:36 -0700 Received: (from mail@localhost) by inetgw.fs.lmco.com (AIX4.2/UCB 8.7/8.7) id QAA16684 for ; Mon, 11 May 1998 16:07:35 -0400 (EDT) Received: from t2.owg.fs.lmco.com(158.187.56.68) by inetgw.fs.lmco.com via smap (V2.0) id xma037534; Mon, 11 May 98 16:06:48 -0400 Received: by t2.owg.fs.lmco.com (AIX 4.1/UCB 5.64/4.03) id AA17382; Mon, 11 May 1998 16:06:47 -0400 From: "Dan Driscoll x3414" Message-Id: <980511160645.ZM17124@t2.owg.fs.lmco.com> Date: Mon, 11 May 1998 16:06:44 -0400 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list please remove me from the list. From rem-conf Mon May 11 16:58:14 1998 From rem-conf-request@es.net Mon May 11 16:58:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ2Pv-0001lj-00; Mon, 11 May 1998 16:55:35 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ2Pu-0001lZ-00; Mon, 11 May 1998 16:55:34 -0700 Received: from jackson.cs.ucsb.edu (almeroth@jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with SMTP id QAA13851 for ; Mon, 11 May 1998 16:55:32 -0700 (PDT) Received: by jackson.cs.ucsb.edu (SMI-8.6/SMI-SVR4) id QAA25437 for rem-conf@es.net; Mon, 11 May 1998 16:55:28 -0700 Date: Mon, 11 May 1998 16:55:28 -0700 From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199805112355.QAA25437@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Linux vs FreeBSD X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Which OS has more/better support for MBone tools... Linux or FreeBSD? More importantly, what audio and video cards have drivers under both Linux/FreeBSD and Windows 95/98? I'd like to run MBone under both OSs with minimal overhead. It seems like I visit this question at least once every six months, and this list sees questions about it every couple of weeks. I've scanned the archives and none of the answers are very satisfactory. -Kevin Almeroth From rem-conf Mon May 11 18:26:19 1998 From rem-conf-request@es.net Mon May 11 18:26:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ3mL-0002sx-00; Mon, 11 May 1998 18:22:49 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0yZ3mK-0002sn-00; Mon, 11 May 1998 18:22:48 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id VAA26049; Mon, 11 May 1998 21:22:44 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: almeroth@cs.ucsb.edu (Kevin C. Almeroth) cc: rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Mon, 11 May 1998 16:55:28 PDT." <199805112355.QAA25437@jackson.cs.ucsb.edu> Date: Mon, 11 May 1998 21:22:44 -0400 Message-ID: <26047.894936164@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Which OS has more/better support for MBone tools... Linux or FreeBSD? I would say that there isn't much in it, but probably FreeBSD because it's used by most of the people I know who are developing Mbone tools, and the audio driver is very solid now. As of FreeBSD 2.2.6, Luigi Rizzo's excellent audio driver is included, which removes many of the problems with audio that existed 6 months ago. I'm using it at home with an A/Open AW35Pro soundcard ($40) and a Hauppauge Wincast/TV capture card ($100), and have had very few problems. >More importantly, what audio and video cards have drivers under both >Linux/FreeBSD and Windows 95/98? I can't tell you if the above hardware is supported under Linux though. >It seems like I visit this question at least once every six months, >and this list sees questions about it every couple of weeks. I've >scanned the archives and none of the answers are very satisfactory. If you're interested in this setup under FreeBSD, I put together a page for the CAIRN community a little while back. It isn't really intended for non-CAIRN sites, but the information is application, and there are a couple of patched binaries that might be useful: http://north.east.isi.edu/mbone/ Cheers, Mark From rem-conf Mon May 11 19:34:52 1998 From rem-conf-request@es.net Mon May 11 19:34:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ4rq-0003va-00; Mon, 11 May 1998 19:32:34 -0700 Received: from rkrishnan.bbn.com [128.89.35.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ4ro-0003vQ-00; Mon, 11 May 1998 19:32:32 -0700 Received: (from rkrishna@localhost) by rkrishnan.bbn.com (8.8.7/8.8.7) id WAA02913 for rem-conf@es.net; Mon, 11 May 1998 22:26:48 -0400 From: Rajesh Krishnan Message-Id: <199805120226.WAA02913@rkrishnan.bbn.com> Subject: Re: Linux vs FreeBSD To: rem-conf@es.net Date: Mon, 11 May 1998 22:26:48 -0400 (EDT) Reply-to: krash@bbn.com Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > > Which OS has more/better support for MBone tools... Linux or FreeBSD? I do not wish to start a religious flame war here. Let me start by stating that I do not see there is a strong advantage to either for just running MBone tools. Some maintain that the TCP/IP stack implementation in FreeBSD is superior, but I am not an expert there. In general I have noticed that FreeBSD and NetBSD are favored more by the networking community, possibly due to historic reasons. IMO, Linux has an edge in terms of documentation and growing popularity. The general software turnover is also higher, but not specifically so for the MBone. > > More importantly, what audio and video cards have drivers under both > Linux/FreeBSD and Windows 95/98? Video drivers are not an issue between Linux/FreeBSD since both these OS'es use the XFree86 implementation. Well for obscure cards, I believe that 3rd party drivers are more readily available for Linux. As far as audio goes the OSSLite/USSlite/.. drivers are work both under FreeBSD and Linux. FreeBSD also has an alternate sound driver (pcm0) which IMO is easier to configure under FreeBSD. Linux sound configuration is now quite painless, as far as Mbone conferencing needs go. However getting the funky features of the latest sound cards to work correctly under Linux/FreeBSD may require a little more work. Typically most video and audio cards do ship with a Win95 driver and Linux hardware compatibility is well documented. This list can get to be long. The Linux Hardware Compatibility HOWTO can be found at www.linuxresources.com, www.linuxnow.com, www.redhat.com and other sites. Its always a good idea to check the latest compatibility information before ordering new hardware. The same holds for Solaris x86, Windows NT as well as other OSes; I'd probably take a chance with Win '95 i.e., if I had to. > > I'd like to run MBone under both OSs with minimal overhead. I am not sure about minimal overhead. MBone tools work well under either. I recently tried many of these tools under Linux and did not have much trouble in setting up. I could find many tools in binary form for Linux, which is a time saver when configuring a bunch of machines. One useful site for Mbone+Linux is http://www.cs.virginia.edu/~mke2e/multicast/ > > It seems like I visit this question at least once every six months, > and this list sees questions about it every couple of weeks. I've > scanned the archives and none of the answers are very satisfactory. > > -Kevin Almeroth > Please excuse me if I have misunderstood your question and have answered it a very naive level. Regards, Rajesh From rem-conf Mon May 11 19:45:11 1998 From rem-conf-request@es.net Mon May 11 19:45:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ535-0004OD-00; Mon, 11 May 1998 19:44:11 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ534-0004O3-00; Mon, 11 May 1998 19:44:10 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id TAA07922; Mon, 11 May 1998 19:42:32 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805120242.TAA07922@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: almeroth@cs.ucsb.edu (Kevin C. Almeroth) cc: rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Mon, 11 May 1998 16:55:28 PDT." <199805112355.QAA25437@jackson.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 May 1998 19:42:32 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list For now, FreeBSD is better and this is due to its better ip multicast suport. Further inquiries with respect to using FreeBSD with mbone tools to multimedia@freeBSD.org Cheers, Amancio From rem-conf Mon May 11 21:33:39 1998 From rem-conf-request@es.net Mon May 11 21:33:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ6ha-0000Mo-00; Mon, 11 May 1998 21:30:06 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ6hY-0000MT-00; Mon, 11 May 1998 21:30:04 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeozq06379; Tue, 12 May 1998 00:30:02 -0400 (EDT) Received: by neserve0.uu.net id QQeozp17708; Tue, 12 May 1998 00:29:42 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Linux vs FreeBSD To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 12 May 1998 00:29:42 -0400 (EDT) Cc: almeroth@cs.ucsb.edu, rem-conf@es.net In-Reply-To: <199805120242.TAA07922@rah.star-gate.com> from "Amancio Hasty" at May 11, 98 07:42:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've been using Linux apps for over a year now, an while they aren't without problems, they definitely work. I was successful in compiling all the tools, and they all work, including mrouted. _J Amancio Hasty said: > > For now, FreeBSD is better and this is due to its better ip multicast suport. > Further inquiries with respect to using FreeBSD with mbone tools to > multimedia@freeBSD.org > > Cheers, > Amancio > > > From rem-conf Mon May 11 21:41:59 1998 From rem-conf-request@es.net Mon May 11 21:41:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ6sE-00011C-00; Mon, 11 May 1998 21:41:06 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ6sC-000110-00; Mon, 11 May 1998 21:41:05 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA08401; Mon, 11 May 1998 21:38:09 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805120438.VAA08401@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: jhall@UU.NET (Jeremy Hall) cc: almeroth@cs.ucsb.edu, rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Tue, 12 May 1998 00:29:42 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 May 1998 21:38:09 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please qualify "while they aren't without problems" and justify postings such as: "> 2. Linux on a similar Pentium Not recommended. I spent much time with mrouted. Couldn't get it to prune. I also am aware that mrouted and apps cannot work on the same linux box. Possibly ok for just running the apps, though if you don't need mrouted." or more recently: " Are there any patches for mrouted-3.9 to get it to work with recent versions of Linux 2.1? I tried writing a quick-fix, but it looked like it'd take more than that to get it to compile. " Thank you, Amancio > I've been using Linux apps for over a year now, an while they aren't > without problems, they definitely work. I was successful in compiling all > the tools, and they all work, including mrouted. > From rem-conf Mon May 11 22:53:53 1998 From rem-conf-request@es.net Mon May 11 22:53:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ7y1-0004by-00; Mon, 11 May 1998 22:51:09 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ7y0-0004bo-00; Mon, 11 May 1998 22:51:08 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeozv09551; Tue, 12 May 1998 01:51:07 -0400 (EDT) Received: by neserve0.uu.net id QQeozv21318; Tue, 12 May 1998 01:50:59 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Linux vs FreeBSD To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 12 May 1998 01:50:59 -0400 (EDT) Cc: almeroth@cs.ucsb.edu, rem-conf@es.net In-Reply-To: <199805120438.VAA08401@rah.star-gate.com> from "Amancio Hasty" at May 11, 98 09:38:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Amancio Hasty said: > " > Are there any patches for mrouted-3.9 to get it to work with > recent versions of Linux 2.1? I tried writing a quick-fix, but > it looked like it'd take more than that to get it to compile. " > > Thank you, > Amancio > I believe this is a challenge. :-) _J > > > > I've been using Linux apps for over a year now, an while they aren't > > without problems, they definitely work. I was successful in compiling all > > the tools, and they all work, including mrouted. > > > > > > From rem-conf Mon May 11 23:49:30 1998 From rem-conf-request@es.net Mon May 11 23:49:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZ8pu-0005k3-00; Mon, 11 May 1998 23:46:50 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZ8ps-0005jt-00; Mon, 11 May 1998 23:46:49 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id XAA08783; Mon, 11 May 1998 23:46:40 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805120646.XAA08783@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: jhall@UU.NET (Jeremy Hall) cc: almeroth@cs.ucsb.edu, rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Tue, 12 May 1998 01:50:59 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 May 1998 23:46:40 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry to disappoint you, I just don't subscribe to the linux insect-like propaganda. Have Fun, Amancio > Amancio Hasty said: > > " > > Are there any patches for mrouted-3.9 to get it to work with > > recent versions of Linux 2.1? I tried writing a quick-fix, but > > it looked like it'd take more than that to get it to compile. " > > > > Thank you, > > Amancio > > > I believe this is a challenge. :-) > > _J > > > > > > > > I've been using Linux apps for over a year now, an while they aren't > > > without problems, they definitely work. I was successful in compiling all > > > the tools, and they all work, including mrouted. > > > > > > > > > > > > From rem-conf Tue May 12 05:58:12 1998 From rem-conf-request@es.net Tue May 12 05:58:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZETe-0001DM-00; Tue, 12 May 1998 05:48:14 -0700 Received: from thumper.bellcore.com [128.96.41.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZETc-0001Cu-00; Tue, 12 May 1998 05:48:13 -0700 Received: from mailee.bellcore.com (mailee.bellcore.com [192.4.7.23]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id IAA20835; Tue, 12 May 1998 08:44:28 -0400 (EDT) Received: from stanpc (stanpc.bellcore.com [192.4.12.105]) by mailee.bellcore.com (8.8.8/8.8.8) with SMTP id IAA10173; Tue, 12 May 1998 08:44:10 -0400 (EDT) Message-Id: <199805121244.IAA10173@mailee.bellcore.com> X-Sender: stanm@mailee.bellcore.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 12 May 1998 08:46:53 -0400 To: enternet@bbn.com, tccc@cs.umass.edu, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@codex.cis.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, multicomm@research.panasonic.com From: Stan Moyer Subject: ENCOM '98 Technical Program Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enterprise Networking and Computing (ENCOM) '98 Technical Program ----------------------------------------------------------------- ENCOM-98 will be held in conjunction with ICC '98 and SUPERCOMM on Sunday, June 07, 1998 in the Westin Peachtree Plaza Hotel, Atlanta, GA, USA, in "Plaza North/Center" and "Plaza South" rooms. UP-TO-DATE info on ENCOM -98 is at http://www.comsoc.org/confs/encom/98/ REGISTRATION INFO is at http://icc98.bellsouth-hosting.net/regis.html 8:30 am - 9:00 am: Opeing the ENCOM-98 Bhumip Khasnabish, Gen, Chair, ENCOM-98, GTE Labs. Inc., USA Vijay Bhagavath, TPC Chair, ENCOM-98, AT&T Labs, USA Roberto Saracco, EnterNet's Chair, CSELT, Italy 9:00 am - 9:45 am: Keynote Speech "Networking Goes Home" by Paul W. Shumate, Executive Director, Broadband Local Access and Premises Networking, Bellcore 9:45 am - 10:30 am: TWO Parallel Sessions Panel Discussion Session: Title: Enterprise Network Security Issues Organiser:Vijay Bhagavath, AT&T Labs, USA and/or Scott Marcus, GTE Internetworking, USA Participants: TBA Paper Session: Title: Enterprise Network Applications and Services Chair: Pradeep Ray, Australia [A] Service supplier chains for the outsourcing of information processing services, T. Preuss ( Thomas.Preuss@tu-cottbus.de ) et al, Germany [B] Supporting enterprise applications with the eternal system, L. Moser ( moser@ece.ucsb.edu ) et al, USA [C] An approach to support cooperation in project-enterprises, G. Canals, C. Godart ( godart@loria.fr ) et al, France [D] Bilateral protection firewalls based on dynamic rules, D, Zenchelsky ( dzenc@geoplex.com ) , USA 10:30 am - 10:45 am: Coffee Break 10:45 am - 12:00 noon: TWO Parallel Sessions Panel Discussion Session: Title: Internet Technologies and Services in Enterprise Organiser: Scott Marcus, GTE Internetworking, USA and/or Vijay Bhagavath, AT&T Labs, USA Participants: TBA Paper Session: Title: Performance Analysis of Enterprise Networks Chair: Gagan Choudhury, AT&T Labs., USA [A] Designing an appropriate traffic shaping scheme to reduce network resource requirements, Shan and O. Yang ( yang@trix.genie.uottawa.ca , Canada [B] A Fuzzy Logic Based Call Admission Controller with Feedback for ATM Networks, N. Shenoy ( nirmala@spri.levels.unisa.edu.au ) and S. Halgamugue, Australia [C] Web-Based Enterprise Network Traffic Monitoring and Reporting, Sung-Uk Park, Young-Min Kang, James W Hong, and Jong-Tae Park ( park@ee.kyungpook.ac.kr ), Korea [D] Parallel data mining on a large scale ATM connected PC cluster and Performance Analysis of TCP retransmission mechanism, Oguchi, Shintani, Tamura and Kitsuregawa ( oguchi@tkl.iis.u-tokyo.ac.jp ), Japan 12:00 noon - 1:00 pm: Lunch Break 1:00 pm - 3:30 pm: TWO Parallel Sessions: Panel Discussion Session: Title: Management of Broadband Enterprise Networks Organiser: Dr. Shervin Erfani, Lucent Technologies, USA Possible participants: Manu Malek, Bell Labs/Lucnet Technologies, USA Shawn Shokoohi, BellSouth, USA Robbie Cohen, Lucnet Technologies, USA Ram Kare, SIAC, USA Paper Session: Title: Enterprise Network Design and Implementation Chair: Julian Newman, Glasgow Caledonian Univ., UK [A] Video on Demand over ATM: System Design and Networking Requirements, Zheng ( zhengbin@flyernet.udayton.edu ) and M. Atiquzamman, USA [B] Novel Multicasting Scheme over Integrated Services Packet Networks, Sang-Ha Kim ( shkim@cclab.chungnam.ac.kr ) and Kwang-Il Lee, Korea [C] Internetworking Architecture Based on a Cells-in-Frames Mechanism, T Tiradentes Boaventura and P. R. Guardieiro, ( taciana@ufu.br OR guardieiro@lrc.deene.ufu.br ), Brazil [D] Enterprise-wide Networking and Computing in the Health-Care Industry: A Case Study, Pronab Ganguly and Pradeep Ray ( p.ray@uws.edu.au ), Australia [E] Unicast Access to Multicast IP Sessions, David Shur ( d.shur@att.com ), AT&T Labs, USA 3:30 pm - 3:45 pm: Coffee Break 3:45 pm - 4:45 pm: TWO Parallel Sessions Panel Discussion Session: Title: Enterprise-Wide Internet Service Quality Organise/Moderator: Stan Moyer, Bellcore, USA Possible participants: (1) Kai Tesink, Bellcore -- The Automotive Network Exchange, an Extranet with a Guaranteed QoS (2) Patricia Wirth, AT&T (3) Scott Marcus, GTE Internetworking (4) Chris Baldwin or Steve Willis, Argon Networks Paper Session: Title: Enterprise Network Management and Middleware Issues Chair: Mohammed Atiquzzaman, Univ of Dayton, Ohio, USA [A] Middleware for Nomadic Access to Enterprise Information Systems, Ravi Jain ( rjain@bellcore.com ), Bellcore, USA [B] Design and Implementation of Web-based Internet/Intranet Application Service Management System, Eun-Ju Ha et al, Kyung pook ( ejha@ain2.kyungpook.ac.kr OR jwkhong@postech.ac.kr ) National University, Korea [C] Anonymous Communication Mechanism and its Integration in CORBA, Maouche Ahmed ( maouche@msisun1.unilim.fr ), France [D] An implantation of SNMPv3, O. Cherkaoui ( cherkaoui.omar@uqam.ca ) et al, Canada. 4:45 pm - 5:00 pm: Closing Remarks/Discussion Moderator(s): IEEE ComSoc's EnterNet's Exec. Committee Particpants: ENCOM-98 Attendees. From rem-conf Tue May 12 07:27:39 1998 From rem-conf-request@es.net Tue May 12 07:27:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZFyp-0002bT-00; Tue, 12 May 1998 07:24:31 -0700 Received: from ietf.org [132.151.1.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZFyn-0002ao-00; Tue, 12 May 1998 07:24:29 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15409; Tue, 12 May 1998 10:23:25 -0400 (EDT) Message-Id: <199805121423.KAA15409@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-h263-video-02.txt Date: Tue, 12 May 1998 10:23:25 -0400 Sender: cclark@CNRI.Reston.VA.US X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Author(s) : C. Maciocco, J. Ott, C. Bormann, C. Zhu, L. Cline, D. Newell, G. Sullivan, G. Deisher, S. Wenger, T. Gardos Filename : draft-ietf-avt-rtp-h263-video-02.txt Pages : 10 Date : 11-May-98 This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 [3], and is recommended for this use by new implementations. This format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 shall use the format described in this document. The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options. Internet-Drafts are 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-h263-video-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-h263-video-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-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: <19980511104958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h263-video-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980511104958.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue May 12 14:57:56 1998 From rem-conf-request@es.net Tue May 12 14:57:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZMyv-0006mM-00; Tue, 12 May 1998 14:53:05 -0700 Received: from ece.rice.edu [128.42.4.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZMyt-0006m3-00; Tue, 12 May 1998 14:53:03 -0700 Received: from qos.ece.rice.edu (qos.ece.rice.edu [128.42.12.65]) by ece.rice.edu (8.8.5/8.7.1) with ESMTP id QAA18297 for ; Tue, 12 May 1998 16:51:48 -0500 (CDT) Received: (from knightly@localhost) by qos.ece.rice.edu (8.7.5/8.7.5) id QAA28478 for rem-conf@es.net; Tue, 12 May 1998 16:48:46 -0500 (CDT) From: "Edward W. Knightly" Message-Id: <980512164846.ZM28476@qos.ece.rice.edu> Date: Tue, 12 May 1998 16:48:45 -0500 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: IWQoS 1998 Final Program MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Below is the final program for IWQoS '98. Registration is now closed as we're over booked, but proceedings can be ordered soon from IEEE. Instructions will appear on the workshop's web page http://www-ece.rice.edu/conf/iwqos98 Best regards, -Ed Knightly (IWQoS '98 co-chair) _________________________________________________________________________ Sixth IEEE/IFIP International Workshop on Quality of Service (IWQoS '98) -Napa, California USA - May 18-20, 1998 Sponsored by IEEE Communications Society Technical Committees on Computer Communications, Multimedia Communications, Internet, and Software Technical co-sponsorship by IFIP WG6.1 In co-operation with ACM SIGCOMM Patrons: Hewlett Packard and Nokia =============== Monday May 18th =============== 8:00 - 8:50 Continental Breakfast 8:50 - 9:00 Opening Remarks: IWQoS '98 chairs Rich Friedrich, HP Labs Ed Knightly, Rice University 9:00 - 10:00 Keynote Address: Roch Guerin, IBM Research "Quality-of-Service: Too little or too much (How much optimization do we really need?)" 10:00 - 10:30 Coffee Break 10:30 - 12:00 Technical Session 1: QoS, Scaling, and Large-Scale Networks Session Chair: Jorg Liebeherr, University of Virginia Full papers: Measuring and Analyzing Service Levels: A Scalable Passive Approach Manjari Asawa (Hewlett-Packard Laboratories) On Flow Aggregation for Multicast Video Transport Kentarou Fukuda, Naoki Wakamiya, Masayuki Murata, Hideo Miyahara (Osaka University) Position papers: Reservations for Aggregate Traffic: Experiences from an RSVP Tunnels Implementation Andreas Terzis, Lixia Zhang (UCLA), Ellen Hahne (Bell Labs) Aggregation of Internet Service States Steven Berson and Subramaniam Vincent (University of Southern California) Aggregating Resource Reservations over Multiple Routing Domains Olov Schelen and Stephen Pink (Lulea University of Technology) A Case for Proportional Fair Sharing Zheng Wang (Bell Labs) Session Panel Discussion 12:00 Lunch 1:30 - 3:00 Technical Session 2: Internet Resource Reservation Session Chair: Kang Shin, University of Michigan Full papers: On-line Measurement of QoS for Call Admission Control Matthew Siler and Jean Walrand (University of California at Berkeley) A General Framework for Deterministic Service Guarantees in Telecommunication Networks with Variable Length Packets C.S. Chang and Y. Lin (National Tsing Hua University) Position papers: QoS Enhancement and its Implementation in the vBNS Laura Cunningham, Chuck Song, and Rick Wilder (MCI) QoS Control via Robust Envelope-Based MBAC Jingyu Qiu and Edward W. Knightly (Rice University) High Quality and High Utilization - Incompatible Objectives for the Internet? Kalevi Kilkki, Jussi Ruutu, and Ove Strandberg (Nokia Research Center) Conservative Gaussian Models Applied to Measurement-Based Admission Control Francois Brichet and Alain Simonian (France Telecom) Session Panel Discussion 3:00 - 3:30 Afternoon Break 3:30 - 5:00 Technical Session 3: Economics, Pricing, and QoS Session Chair: Cormac Sreenan, AT&T Labs Research Full papers: Paying for QoS: An Optimal Distributed Algorithm for Pricing Network Resources Errin Fulp (NEC and North Carolina State University), Max Ott and Daniel Reininger (NEC), and Douglas Reeves (North Carolina State University) INDEX: A Platform for Determining how People Value the Quality of their Internet Access Bjorn Rupp, Richard Edell, and Pravin Varaiya (University of California at Berkeley) An Embedded Charging Approach for RSVP Martin Karsten, Jens Schmitt, Lars Wolf, and Ralf Steinmetz (Darmstadt University of Technology) Position paper: INDEX Project: User Support for Buying QoS with Regard to User's Preferences Jorn Altmann and Pravin Varaiya (University of California at Berkeley) Session Panel Discussion 6:00 Welcome dinner sponsored by Nokia ================ Tuesday May 19th ================ 8:15 - 9:00 Continental Breakfast 9:00 - 10:00 Keynote Paper: Domenico Ferrari, Universita Cattolica Piacenza "Charging for QoS" 10:00 - 10:30 Coffee Break 10:30 - 12:00 Technical Session 4: QoS Architecture, Protocols, and Middleware Session Chair: Hermann de Meer, University of Hamburg Full papers: SRP: a Scalable Resource Reservation Protocol for the Internet Werner Almesberger (EPFL ICA), Tiziana Ferrari (University of Bologna), and Jean-Yves Le Boudec (EPFL ICA) SAAM: Integrated Network Architecture for Integrated Services Geoffrey Xie, Debra Hensgen, Taylor Kidd, and John Yarger (Naval Postgraduate School) Dynamic Authentication for High-Performance Networked Applications Phyllis Schneck and Karsten Schwan (Georgia Institute of Technology) Position papers: The Quality of Service (QoS) Binding Model Jan de Meer (GMD Fokus), Abdelhakim Hafid (University of Western Ontario), and Arno Puder (ICSI) Qualis: the QoS Component for the Globus Metacomputing System Craig Lee (The Aerospace Corporation), Carl Kesselman, Robert Lindell, Soonwook Hwang, Joseph Bannister (University of Southern California), Ian Foster, Alain Roy (Argonne National Laboratory) Session Panel Discussion 12:15-1:30 Lunch and Panel Panel: Hui Zhang, Carnegie Mellon University "The Future of Differential and Integrated Services in the Internet" Fred Baker Cisco Yoram Bernet Microsoft Raj Yavatkar Intel Rick Wilder MCI John Wroclawski MIT 2:00-3:15 Technical Session 5: Adaptive QoS 1 Session Chair: Andrew Campbell, Columbia University Full papers: A Control Theoretical Model for Quality of Service Adaptations Baochun Li and Klara Nahrstedt (University of Illinois at Urbana-Champaign) Soft Real-Time Application Execution with Dynamic QoS Assurance Scott Brandt, Gary Nutt, Toby Berk, and Marty Humphrey (University of Colorado at Boulder) Position papers: A Study of Dynamic QoS Negotiation for Multimedia Applications in RSVP Antonio Loureiro, Vladimir de L. Santos, Carlos de C. Goulart and Jose Marcos S. Nogueira (Federal University of Minas Gerais) Robust and Secure Light-weight Resource Reservation for Unicast IP Traffic Anders Eriksson (Ericsson Telecom) and Christian Gehrmann (Ericsson Radio Systems) Satisfying QoS with a Learning Based Scheduling Algorithm Jason Hall and Philip Mars (University of Durham) Session Panel Discussion 3:15 - 3:45 Afternoon Break 3:45-5:15 Technical Session 6: Application QoS Session Chair: Klara Nahrstedt, University of Illinois at Urbana-Champaign Full papers: User Services Assistant: An End-to-End Reactive QoS Architecture Bjorn Landfeldt, Aruna Seneviratne (UTS), and Christophe Diot (Inria) Network Support for Application-Oriented QoS Prashant Chandra, Allan Fisher, Corey Kosak, and Peter Steenkiste (Carnegie Mellon University) Development of Opinion-Based Audiovisual Quality Models for Desktop Video Teleconferencing Coleen Jones and D. Atkinson (U.S. Department of Commerce) Position paper: Content-based VBR Resource Allocation Model and its Application to Dynamic Network Resource Allocation Paul Bocheck and Shih-Fu Chang (Columbia University) Session Panel Discussion 6:00 Board Bus for V. Sattui Winery, St. Helena for Dinner and Wine Tasting ================== Wednesday May 20th ================== 8:15 - 9:00 Continental Breakfast 9:00 - 10:30 Technical Session 8: Adaptive QoS 2 Full papers: Achieving High Utilization in Guaranteed Services Networks using Early-Deadline-First Scheduling Fabio Chiussi and Vijay Sivaraman (Bell Laboratories) Exact Emulation of an Output Queueing Switch by a Combined Input Output Queueing Switch Ion Stoica and Hui Zhang (Carnegie Mellon University) On the Speedup Required for Work-Conserving Crossbar Switches P. Krishna (DEC), N. Patel (Sycamore), A. Charney (Cabletron and MIT), and R. Simcoe (Nexabit) Algorithms for Providing Bandwidth and Delay Guarantees in Input-Buffered Crossbars with Speed Up A. Charny (Cabletron and MIT), P. Krishna (DEC), N. Patel (Sycamore), and R. Simcoe (Nexabit) Session Panel Discussion 10:30 - 11:00 Coffee Break 11:00 - 12:00 Panel: Vaduvur Bharghavan, University of Illinois "QoS in Wireless Networks: the Transition from Myth to Reality" Andrew Campbell Columbia U. Randy Katz UC Berkeley Upamanyu Madhow UIUC 12:00 Lunch Technical Session 8: Adaptive QoS 2 1:30 - 2:45 Full papers: Decision Support in Cooperative QoS Management Stefan Fischer (University of Mannheim) and Hermann De Meer (University of Hamburg) Supporting Utility Fair Adaptive Services in Wireless Networks Giuseppe Bianchi, Andrew Campbell, and Raymond Liao (Columbia University) Position papers: UNITE: A Framework for Flexible QoS in Networks Gisli Hjalmtysson and K. K. Ramakrishnan (AT&T Labs) A Summary of QoS Support in SWAN T. Chen (Bell Labs), P. Krzyanowski (VenGen Inc.), C. Sreenan, (AT&T Labs Research), and J. Trotter, (Bell Labs) A General Model for QoS Adaptation D.G. Waddington and D. Hutchison (Lancaster University) Session Panel Discussion 2:45 Closing Remarks and Announcement of IWQoS '99 From rem-conf Wed May 13 01:25:43 1998 From rem-conf-request@es.net Wed May 13 01:25:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZWee-0003h4-00; Wed, 13 May 1998 01:12:48 -0700 Received: from pop3.tu-dresden.de [141.30.2.83] by mail1.es.net with smtp (Exim 1.81 #2) id 0yZWed-0003gt-00; Wed, 13 May 1998 01:12:47 -0700 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Wed, 13 May 1998 10:10:00 +0200 Received: from rncmm1.urz.tu-dresden.de by rmail with SMTP (PP); Wed, 13 May 1998 10:06:02 +0200 Received: from localhost by rncmm1.urz.tu-dresden.de (SMI-8.6/SMI-SVR4) id KAA02413; Wed, 13 May 1998 10:09:16 +0200 Date: Wed, 13 May 1998 10:09:16 +0200 (MET DST) From: Christoph Fleck X-Sender: fleck@rncmm1 Reply-To: Multimedia Referenzzentrum To: Amancio Hasty cc: Jeremy Hall , almeroth@cs.ucsb.edu, rem-conf@es.net Subject: Re: Linux vs FreeBSD In-Reply-To: <199805120646.XAA08783@rah.star-gate.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 Hi, I would give the "FreeBSD/Linux & MBone" dispute a profitable direction. How about to list the function with the MBone-Tools tested at your site? Importrend could be vat, rat, vic, mrouted on different Hardware. I would use both, FreeBSD & Linux, to work with MBone. In the case of FreeBSD it was nearly easy to get an working MBone-Box. With Linux I had no such sucess. I miss some "cooking recipe" that I found for FreeBSD. Perhaps anybody has such recipe for Linux to. Here is my list: FreeBSD: * CS4236B, driver Luigi Rizzo: - vat fullduplex, volume-slider work - rat halfduplex, volume-slider work not * SB16, driver Luigi Rizzo: - no useful audio * CS4236B, driver OSS FreeBSD: - no matching vat or rat found * BT848: - vic send PAL@(QCIF,CIF,SCIF) up to 25fps * mrouted pruning o.k. Linux: * CS4236B & SB16, OSS Free & OSS Linux: - no matching vat or rat found, volume-slider work not * BT848: - vic send PAL@(QCIF,CIF,SCIF) up to 15fps * mrouted no pruning. Any extensions of the list are welcome. Who has a solutions for the described restrictions ? Rgds, Christoph ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck, Rainer Kranz | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Wed May 13 02:06:28 1998 From rem-conf-request@es.net Wed May 13 02:06:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZXOd-0005eT-00; Wed, 13 May 1998 02:00:19 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yZXOc-0005dW-00; Wed, 13 May 1998 02:00:18 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id BAA14226; Wed, 13 May 1998 01:58:39 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805130858.BAA14226@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Multimedia Referenzzentrum cc: almeroth@cs.ucsb.edu, rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Wed, 13 May 1998 10:09:16 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 May 1998 01:58:39 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, We , FreeBSD, have been in the MBone for the last 4 years. In fact, while working at Cisco during 93 to 94, I had a little FreeBSD box listening and watching IP Multicast broadcasts at Cisco. This is the list of MBone apps currently ported to FreeBSD and mrouted and friends are part of our base distribution: {hasty} which mrouted /usr/sbin/mrouted ncftp ftp.freebsd.org:/pub/FreeBSD/FreeBSD-current/ports/mbone/ nte/ rtptools/ vat/ imm/ sdr/ vic/ mbone_vcr/ rtpmon/ speak_freely/ wb/ I mostly used vat / linux sound driver with gus pnp and vic with bt848 or meteor and in the past I have used my box to trouble-shoot the mbone at large . The latter came about due to Jim Lowe's Parking Lot Cam broadcast. He was using a sun box to broadcast on the FreeBSD MBone Lounge. On my PPro 200Mhz , vic-2.8/bt848, I get about anywhere between 15 frames to 30 frames pending on context. Like right now , I am getting 29 frames with a newswoman standing up and talking . I have used in the past vat / full duplex / guspnp to talk to people and I wrote the FreeBSD audio component in vat so the volume , mute etc works. If it matters , the primary development platform for the UCB mash project is FreeBSD. This is a quote and an leaving out the original poster's name out in case of a flame war: " Luigi, All the mash tools ought to compile on FreeBSD. FreeBSD is the primary development platform for mash, so you should not require any porting to get it to compile on a FreeBSD box. Thanks. " Very recently Luigi modified Vic so we can use the tuner component in my bt848 driver. If you guys are really interested in the latest news on FreeBSD with Mbone tools just mail to multimedia@freeBSD.org. Best Regards, Amancio From rem-conf Wed May 13 02:22:49 1998 From rem-conf-request@es.net Wed May 13 02:22:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZXdZ-0006Db-00; Wed, 13 May 1998 02:15:45 -0700 Received: from aries.dif.um.es (aries.dif.um.es.) [155.54.12.152] by mail1.es.net with smtp (Exim 1.81 #2) id 0yZXdX-0006CK-00; Wed, 13 May 1998 02:15:44 -0700 Received: from orion by aries.dif.um.es. (SMI-8.6/SMI-SVR4) id LAA15265; Wed, 13 May 1998 11:10:59 +0100 Message-Id: <199805131010.LAA15265@aries.dif.um.es.> X-Sender: amateo@aries.dif.um.es X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Wed, 13 May 1998 11:13:59 +0100 To: mbone@isi.edu, rem-conf@es.net From: Angel Luis Mateo =?iso-8859-1?Q?Mart=EDnez?= Subject: ISDN and MBone Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are installing a videconferencing room that works over ISDN and over MBone, so we are interested about configure it for internetworking over both architectures. Does anybody knows a way to installed a "reflector" that propagates data from ISDN to the MBone the data receive over ISDN? and >from Mbone to ISDN ? Thanks, Angel L. Mateo ------------------------------------------------------------------------ Angel L. Mateo Mart=EDnez Tfo: 968/364640 Laboratorio Redes. Facultad de Inform=E1tica Universidad de Murcia Espa=F1a (Spain) From rem-conf Wed May 13 04:03:34 1998 From rem-conf-request@es.net Wed May 13 04:03:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yZZGL-0000Mo-00; Wed, 13 May 1998 03:59:53 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yZZGH-0000Md-00; Wed, 13 May 1998 03:59:51 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 May 1998 11:57:32 +0100 To: Multimedia Referenzzentrum cc: Amancio Hasty , Jeremy Hall , almeroth@cs.ucsb.edu, rem-conf@es.net Subject: Re: Linux vs FreeBSD In-reply-to: Your message of "Wed, 13 May 1998 10:09:16 +0200." Date: Wed, 13 May 1998 11:57:30 +0100 Message-ID: <590.895057050@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Christoph Fleck writes: >I would give the "FreeBSD/Linux & MBone" dispute a profitable direction. >How about to list the function with the MBone-Tools tested at your site? >Importrend could be vat, rat, vic, mrouted on different Hardware. >I would use both, FreeBSD & Linux, to work with MBone. >In the case of FreeBSD it was nearly easy to get an working MBone-Box. >With Linux I had no such sucess. I miss some "cooking recipe" that I found >for FreeBSD. Perhaps anybody has such recipe for Linux to. > >Here is my list: > >FreeBSD: >* CS4236B, driver Luigi Rizzo: > - vat fullduplex, volume-slider work > - rat halfduplex, volume-slider work not >* SB16, driver Luigi Rizzo: > - no useful audio >* CS4236B, driver OSS FreeBSD: > - no matching vat or rat found For rat development on FreeBSD we use Luigi's sound driver. However, older versions used the OSS driver, and you should be able to compile this into the FreeBSD version of rat fairly easily. >* BT848: > - vic send PAL@(QCIF,CIF,SCIF) up to 25fps >* mrouted pruning o.k. > >Linux: >* CS4236B & SB16, OSS Free & OSS Linux: >- no matching vat or rat found, volume-slider work not The development machine for rat on linux has a SoundBlaster AWE32 with OSS/Linux 3.8.1q as the driver (in SoundBlaster16 mode). The volume slider works, but there's an annoying click every few seconds (this bug is mostly fixed in the development version of rat). We only have one linux machine to test on: if anyone has success/failure reports for different cards, or patches to fix problems, I'd be happy to receive them. -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Thu May 14 09:40:42 1998 From rem-conf-request@es.net Thu May 14 09:40:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ya0lG-0005K8-00; Thu, 14 May 1998 09:21:38 -0700 Received: from george.arc.nasa.gov [128.102.194.142] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ya0lF-0005Jx-00; Thu, 14 May 1998 09:21:37 -0700 Received: (from lamaster@localhost) by george.arc.nasa.gov (8.8.7/8.8.7) id JAA19441; Thu, 14 May 1998 09:21:34 -0700 (PDT) Date: Thu, 14 May 1998 09:21:33 -0700 (PDT) From: Hugh LaMaster To: mbone@ISI.EDU, rem-conf@es.net Subject: Re: MBone apps for Windows? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 8 May 1998, Steve Deering wrote: > A couple people sent me the message I was seeking; it was from Christophe > Orlhac to the mbone list, dated 27 Apr, subject "Hardware for multicasting ?". > It contained the following very useful URL: > > http://www.cs.ucl.ac.uk/staff/K.Hasler/shrimp/bin/ I concur. I finally got around to downloading the new tools (I didn't have very good luck with the previous versions of the W95/Mbone tools) and ran them on W95. [They should also work on NT - reports?] They seemed to work pretty well, and wb is there now, also. Anyone who gave up on using the initial port should try these debugged versions. [Of course, I use FreeBSD most of the time when running on x86's, but, these are handy to have and seem usable.] The bottom line: W95 Mbone users should try these. - Hugh LaMaster, M/S 233-21, ASCII Email: hlamaster@mail.arc.nasa.gov NASA Ames Research Center Or: lamaster@george.arc.nasa.gov Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 Phone: 650/604-1056 Disclaimer: Unofficial, personal *opinion*. From rem-conf Thu May 14 10:56:16 1998 From rem-conf-request@es.net Thu May 14 10:56:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ya2Ai-0006Vx-00; Thu, 14 May 1998 10:52:00 -0700 Received: from cepheid.physics.gla.ac.uk [130.209.45.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ya2Af-0006Vn-00; Thu, 14 May 1998 10:51:58 -0700 Received: from a5.ph.gla.ac.uk (a5.ph.gla.ac.uk [194.36.1.167]) by cepheid.physics.gla.ac.uk (8.8.5/8.8.5) with ESMTP id SAA05973; Thu, 14 May 1998 18:45:39 +0100 (BST) Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with SMTP id SAA18255; Thu, 14 May 1998 18:51:40 +0100 (BST) Date: Thu, 14 May 1998 18:51:39 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: Hugh LaMaster cc: mbone@isi.edu, rem-conf@es.net Subject: Re: MBone apps for Windows? In-Reply-To: Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 14 May 1998, Hugh LaMaster wrote: > > http://www.cs.ucl.ac.uk/staff/K.Hasler/shrimp/bin/ > > I concur. Me too. Those UCL folks have done good work (Disclaimer: I'm speaking as a dumb user who has not looked under the covers!). The speedup of vic is truly astonishing. > (I didn't have very good luck with the previous versions of > the W95/Mbone tools) and ran them on W95. [They should > also work on NT - reports?] They seem to be working fine on two NT4 systems we've tried. One system has some trouble with audio hangups, but it has trouble with audio on NetMeeting too, so it seems to be something with its sound card or with that card's driver software, rather than anything amiss with rat. > The bottom line: W95 Mbone users should try these. NT too. There's a working sdr for NT. Accidentally running two instances of rat under W95 can hang the audio system, I've found (reported to K.H). That's not a problem on NT4. all the best From rem-conf Thu May 14 13:02:09 1998 From rem-conf-request@es.net Thu May 14 13:02:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ya40P-00005f-00; Thu, 14 May 1998 12:49:29 -0700 Received: from mail.structured.net [206.58.0.25] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ya40O-00005U-00; Thu, 14 May 1998 12:49:28 -0700 Received: from blackbird (blackbird.eric.structured.net [206.58.33.13]) by mail.structured.net (8.8.8/8.8.8) with SMTP id MAA11356; Thu, 14 May 1998 12:46:08 -0700 (PDT) Message-Id: <199805141946.MAA11356@mail.structured.net> X-Sender: kozowski@pop.structured.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 14 May 1998 12:46:06 -0700 To: Hugh LaMaster , mbone@ISI.EDU, rem-conf@es.net From: Eric Kozowski Subject: Re: MBone apps for Windows? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:21 AM 5/14/98 , Hugh LaMaster wrote: > >On Fri, 8 May 1998, Steve Deering wrote: > >> A couple people sent me the message I was seeking; it was from Christophe >> Orlhac to the mbone list, dated 27 Apr, subject "Hardware for multicasting ?". >> It contained the following very useful URL: >> >> http://www.cs.ucl.ac.uk/staff/K.Hasler/shrimp/bin/ > >I concur. I finally got around to downloading the new tools >(I didn't have very good luck with the previous versions of >the W95/Mbone tools) and ran them on W95. [They should >also work on NT - reports?] seems to work ok on nt 4.0 worstation. minor cosmetic bugs, but it's fairly stable. From rem-conf Thu May 14 21:02:56 1998 From rem-conf-request@es.net Thu May 14 21:02:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaBd7-0003GO-00; Thu, 14 May 1998 20:57:57 -0700 Received: from mail.gmd.de [129.26.8.90] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaBd5-0003GE-00; Thu, 14 May 1998 20:57:55 -0700 Received: (from mayer@localhost) by mail.gmd.de (8.8.8/8.8.8) id FAA11627; Fri, 15 May 1998 05:57:38 +0200 (MET DST) Date: Fri, 15 May 1998 05:57:38 +0200 (MET DST) From: Hans Mayer Message-Id: <199805150357.FAA11627@mail.gmd.de> To: mbone@ISI.EDU, rem-conf@es.net Subject: Re: MBone apps for Windows? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [...deleted...] >>I concur. I finally got around to downloading the new tools >>(I didn't have very good luck with the previous versions of >>the W95/Mbone tools) and ran them on W95. [They should >>also work on NT - reports?] > >seems to work ok on nt 4.0 worstation. minor cosmetic bugs, but it's >fairly stable. What version are the current tools based upon? I had a great time trying getting version 5.0a (the mash version) running (and they still don't :-( ) As I do have problems with multicast with other applications I suspect it's not the tools but the stack (from M$). Does anyone know how (and what) to configure multicast on a W'95 / WNT machine? I looked at the registry but found nothing. I got a few pointers to things to try but they didn't help either. Hans From rem-conf Thu May 14 23:50:13 1998 From rem-conf-request@es.net Thu May 14 23:50:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaEFU-0004Vy-00; Thu, 14 May 1998 23:45:44 -0700 Received: from nwuxe014.iwate-pu.ac.jp [210.156.40.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaEFS-0004VT-00; Thu, 14 May 1998 23:45:43 -0700 Received: from nwux0011.iwate-pu.ac.jp (nwux0011.iwate-pu.ac.jp [210.156.41.1]) by nwuxe014.iwate-pu.ac.jp (8.8.8+2.7Wbeta7/3.6W/98032117) with SMTP id PAA07577 for ; Fri, 15 May 1998 15:45:23 +0900 (JST) Received: from [172.16.138.102] (mozart2.soft.iwate-pu.ac.jp [172.16.138.102]) by nwux0011.iwate-pu.ac.jp (SMI-8.6/3.6W/98032117) with SMTP id PAA15363 for ; Fri, 15 May 1998 15:45:22 +0900 Message-Id: <199805150645.PAA15363@nwux0011.iwate-pu.ac.jp> X-Sender: issam@pmail.iwate-pu.ac.jp X-Mailer: Macintosh Eudora Pro Version 2.1.4-J Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Fri, 15 May 1998 15:45:08 +0900 To: rem-conf@es.net From: issam@soft.iwate-pu.ac.jp (Prof. Issam A. Hamid) Subject: Remove X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Remove --------------------------------------------------------------------------- Dr. Issam A. Hamid Professor, Faculty of Software and Information Science, Iwate Prefectural University 152-52 Sugo, Takizawa aza, Iwate Prefecture$B!"(JJapan Tel:+81-19-694-2578 Fax:+81-19-694-2579 e-mail:issam@soft.iwate-pu.ac.jp ---------------------------------------------------------------------------- From rem-conf Fri May 15 00:10:21 1998 From rem-conf-request@es.net Fri May 15 00:10:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaEbq-0005ED-00; Fri, 15 May 1998 00:08:50 -0700 Received: from elm.fernuni-hagen.de [132.176.114.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaEbp-0005E2-00; Fri, 15 May 1998 00:08:49 -0700 Received: from lgks1.fernuni-hagen.de by elm.FernUni-Hagen.de with Local ESMTP (PP); Fri, 15 May 1998 09:08:15 +0200 Received: from LGKS1/MAILQUEUE by lgks1.fernuni-hagen.de (Mercury 1.13); Fri, 15 May 98 9:09:30 MET Received: from MAILQUEUE by LGKS1 (Mercury 1.13); Fri, 15 May 98 9:09:00 MET Received: from brinkhoffs by lgks1.fernuni-hagen.de (Mercury 1.13); Fri, 15 May 98 9:09:00 MET Received: by localhost with Microsoft MAPI; Fri, 15 May 1998 09:08:51 +0200 Message-ID: <01BD7FE1.13F319B0.michael.stepping@fernuni-hagen.de> From: "Stepping, Michael" To: 'Hans Mayer' Cc: "mbone@ISI.EDU" , "rem-conf@es.net" , "'KS Grosch, Christian'" , "'KS Paleschke, Thomas'" , "'Stepping, Christoph'" Subject: AW: MBone apps for Windows? Date: Fri, 15 May 1998 09:08:50 +0200 X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Hans, with our experience according MBone at the University of Hagen, Germany, you have to do nothing on your local PC (whether Win95 nor WinNT). If you cannot receive any Multicast sessions, this is normally a problem of routers and their software. Perhaps a problem from firewalls. On WinNT we could only establish "Shrimp"-Version-Tools (others do not=20 function.) Other hints are: http://www.mbone.de http://www.lvn.com/multikit/wintools.html http://www.research.microsoft.com/research/barc/mbone/ For all people who want to test VIVA (music sender)(from = ASTRA-Satellite) there is a multicast-test-server in Erlangen (Germany). Hopefully helps, Michael Stepping -------------------------------------------------------------------------= ------ Dipl.-Ing. Michael Stepping an der FernUniversitaet-Hagen Lehrgebiet fuer Kommunikationssysteme, Herr Prof. Dr. Kaderali Feithstrasse 142 im TGZ in 58084 Hagen Tel. (0 23 31) 9 87 - 41 04, Fax: - 3 97 EMail: Michael.Stepping@Fernuni-hagen.de Homepage: http://www-kommsys.fernuni-hagen.de/~stepping -------------------------------------------------------------------------= ------ FTK Research Institute for Telecommunications Image Processing & Multimedia Technology Martin-Schmeisser-Weg 4, D-44227 Dortmund Phone: (02 31) 97 50 56 - 0, Fax: - 10 > -----Urspr=FCngliche Nachricht----- > Von: Hans Mayer [SMTP:Hans.Mayer@gmd.de] > Gesendet am: Freitag, 15. Mai 1998 05:58 > An: mbone@ISI.EDU; rem-conf@es.net > Betreff: Re: MBone apps for Windows? > > [...deleted...] > >>I concur. I finally got around to downloading the new tools > >>(I didn't have very good luck with the previous versions of > >>the W95/Mbone tools) and ran them on W95. [They should > >>also work on NT - reports?] > > > >seems to work ok on nt 4.0 worstation. minor cosmetic bugs, but it's > >fairly stable. > > What version are the current tools based upon? I had a great time = trying > getting version 5.0a (the mash version) running (and they still don't = :-( ) > As I do have problems with multicast with other applications I suspect = it's > not the tools but the stack (from M$). > Does anyone know how (and what) to configure multicast on a W'95 / WNT > machine? I looked at the registry but found nothing. I got a few = pointers > to things to try but they didn't help either. > > Hans > > From rem-conf Fri May 15 00:27:43 1998 From rem-conf-request@es.net Fri May 15 00:27:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaErK-0005ul-00; Fri, 15 May 1998 00:24:50 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.18.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaErJ-0005uR-00; Fri, 15 May 1998 00:24:49 -0700 Received: from ksat24 (ksat24.rus.uni-stuttgart.de [129.69.13.219]) by artemis.rus.uni-stuttgart.de (8.8.7/8.8.7) with SMTP id JAA13844; Fri, 15 May 1998 09:24:29 +0200 (MET DST) env-from (Andreas.Rozek@RUS.Uni-Stuttgart.De) Received: by localhost with Microsoft MAPI; Fri, 15 May 1998 09:28:23 +0200 Message-ID: <01BD7FE3.CEBAE320.Andreas.Rozek@RUS.Uni-Stuttgart.De> From: Andreas Rozek To: "'Hugh LaMaster'" , "mbone@ISI.EDU" , "rem-conf@es.net" Subject: AW: MBone apps for Windows? Date: Fri, 15 May 1998 09:28:23 +0200 Organization: Rechenzentrum Uni Stuttgart X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list | > A couple people sent me the message I was seeking; it was from | > Christophe | > Orlhac to the mbone list, dated 27 Apr, subject "Hardware for | > multicasting ?". | > It contained the following very useful URL: | > | > http://www.cs.ucl.ac.uk/staff/K.Hasler/shrimp/bin/ | | I concur. I finally got around to downloading the new tools | (I didn't have very good luck with the previous versions of | the W95/Mbone tools) and ran them on W95. [They should | also work on NT - reports?] | | They seemed to work pretty well, and wb is there now, | also. Anyone who gave up on using the initial port | should try these debugged versions. | | [Of course, I use FreeBSD most of the time when running | on x86's, but, these are handy to have and seem usable.] | | The bottom line: W95 Mbone users should try these. Until yesterday, I had severe problems with RAT, the Robust Audio Tool from UCL, then Kristian Hasler told me to install the Microsoft WinSock 2.2 upgrade - since then RAT works perfectly! I include his mail here for reference: | Andreas, | | I recently had a problem with RAT not working on my friends machine. | The symptoms where a very slow and unusable user interface and broken | audio. I'm not sure if it's the same problem you had but an upgrade | to | winsock2.2 (from tucows - http://tucows.cableinet.co.uk/tcp95.html) | solved the problem. | | Hope that helps! Kris What shall I say: it DID help! Thus, the line below the bottom one could be: W95 MBone users should upgrade to WinSock 2.2 first! Andreas Rozek Rechenzentrum Universitaet Stuttgart ****** ** ** ***** Kommunikationssysteme/BelWue-Entwicklung ** ** ** ** ** Allmandring 3a ** ** ** ** ** D-70550 Stuttgart ****** ** ** ***** *** ** ** ** Telefon: ++49 (711) 685-4514 ** ** ** ** ** Telefax: ++49 (711) 678-8363 ** ** ***** ****** E-Mail: Andreas.Rozek@RUS.Uni-Stuttgart.De From rem-conf Fri May 15 06:02:01 1998 From rem-conf-request@es.net Fri May 15 06:02:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaK2e-0002Vb-00; Fri, 15 May 1998 05:56:52 -0700 Received: from ctral1.vanderbilt.edu [129.59.1.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaK2c-0002VQ-00; Fri, 15 May 1998 05:56:51 -0700 Received: from gavish (D009205.N1.Vanderbilt.Edu) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #24212) with SMTP id <01IX1ZKAUA9W9GJLE4@ctrvax.Vanderbilt.Edu>; Fri, 15 May 1998 07:49:00 CDT Date: Fri, 15 May 1998 07:48:49 -0500 From: Bezalel Gavish Subject: ICTEC - CFP X-Sender: gavishb@ctral1.vanderbilt.edu To: (Recipient list suppressed) Message-id: <01IX1ZKB84IE9GJLE4@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS First International Conference on Telecommunications and Electronic Commerce (ICTEC) Nashville, USA, November 19-22, 1998 http://cottonian.ogsm.vanderbilt.edu/ICTEC/ Sponsored by Vanderbilt University Institute for Public Policy Studies (VIPPS) BELLSOUTH MAGNETEK National Commercial Bank, Saudi Arabia INFORMS Colleges on Information Systems and Telecommunications, IFIP WG 7.3, ATSMA Important Dates: Paper (or Extended Abstract) Submission Deadline: May 15, 1998 Panel Proposal Submission Deadline: May 15, 1998 Final Paper Submission Deadline: September 15, 1998 Conference Dates: November 19-22, 1998 Over the past few years, electronic commerce (EC) has emerged as a dramatic new mode of business. Today, almost every company is either using or considering EC. Advances in telecommunications and automated processes are already forcing dramatic changes in a variety of industries, ranging from banking and finance to music and entertainment. Yet, the TEC environment is still in a relatively early state of evolution. The rapid development of the field has also resulted in two phenomena. First, many of the significant advances in understanding and implementing EC are occurring concurrently in academia and industry. The traditional sequential process of technology innovation followed by technology transfer no longer applies. Thus, it is increasingly important for dialogue on this field between academia and industry to be fostered. Second, study of EC does not conform to traditional academic disciplines, and spans a wide range of reference disciplines. Thus, new forums focusing on EC are necessary to stimulate the necessary interactions and knowledge sharing. Furthermore, the role of telecommunications networks is central to EC, and advances in telecommunications technologies are a fundamental force in shaping EC. Thus, dialogue between telecommunications researchers and EC researchers is essential. ICTEC is intended to address these needs. The goal of the conference is to bring together both academic and industrial researchers in the fields of telecommunications and EC on an ongoing, annual basis, to discuss new technological developments and their implications for EC, as well as technological issues that need to be addressed to further the effectiveness and efficiency of EC. The conference will combine research tracks in which technical papers will be presented, with industrial tracks consisting of panels, plenary speakers and exhibits. Topics of interest for the conference include (but are not limited to) the following: * Impact of EC on supply chain, distribution chain management, EDI and IOS * Impact of EC on business processes * Secure transaction-processing methods for electronic commerce * Design and analysis of multimedia applications on the Internet * The impact of mobility on EC mechanisms * Internet traffic management and analysis * Pricing Internet services * EC market mechanisms and business models * EC intermediary roles and their analysis * Electronic payment mechanisms * Economic analysis of intranets and extranets * Design and analysis of intranets * Data management issues in EC * Managing response time and content in Web-based information services * Effective management of electronic commerce transaction servers * EC developments and challenges in specific industries (e.g., financial services, music, manufacturing, tourism, publishing) * Globalization issues in EC (standards, regulation, property rights, etc.) Authors should submit an extended abstract of at least 2000 words, or a complete paper, to the Program Committee Chair by May 15, 1998. Three hard-copies should be submitted. Electronic submissions are welcome, but must be augmented with at least one hard-copy. Authors of accepted papers will be asked to submit their complete manuscripts to the Program Chair, by September 15, 1998. Accepted papers that are presented at the conference will be included in the Conference Proceedings. Formatting instructions for accepted papers will be sent with the acceptance notice. Appropriate papers will be considered for publication in the Telecommunication Systems Journal, and the Journal of Distributed and Parallel Databases (in a special issue on Internet Electronic Commerce). Proposals for panels are also invited. Both academic and industry panels are encouraged. Each proposal should include a list of panelists with their affiliations. A brief statement explaining the motivation for the design and composition of the panel should also be included. The deadline for proposal submission to the program chair is May 15, 1998. Address for Submissions: Professor Amit Basu, Owen Graduate School of Management, Vanderbilt University, Nashville, TN 37203, USA. TEL: +(615) 322-7043; FAX: +(615) 343-7177; EMAIL: Amit.Basu@owen.vanderbilt.edu Conference General Chair: Bezalel Gavish, Vanderbilt University, Nashville, USA. Program Committee Abdullah Al-Dhelaan, King Saud Univ., Saudi Arabia Kemal Altinkemer, Purdue Univ., USA Michael Ball, Univ. of Maryland, USA Amit Basu, Vanderbilt Univ., USA (Chair) Robert Blanning, Vanderbilt Univ., USA Imrich Chlamtac, Univ. of Texas, Dallas, USA H. Michael Chung, California State Univ., USA Asuman Dogac, Middle East Tech. Univ., Turkey Lawrence Dowdy, Vanderbilt Univ., USA Amitava Dutta, George Mason Univ., USA Tony Eyers, Univ. of Woolagong, Australia Usama Fayyad, Microsoft Corp., USA Stuart Feldman, IBM Corp., USA Erol Gelenbe, Duke Univ., USA Sigmund Handelman, IBM Corp., USA Eric van Heck, Erasmus Univ., Netherlands Ravi Kalakota, Georgia State Univ., USA Joakim Kalvenes, Univ. of Texas, Dallas, USA Ajit Kambil, New York Univ., USA Kalevi Kilkki, Nokia Corp., Finland Norihisa Komoda, Osaka Univ., Japan Ramayya Krishnan, Carnegie Mellon Univ., USA Akhil Kumar, Univ. of Colorado, USA Ronald Lee, Erasmus Univ., Netherlands John D. C. Little, MIT, USA Alberto Mendelzon, Univ. of Toronto, Canada Juzar Motiwalla, National Univ. of Singapore Prabir Neogi, Industry Canada June Park, Univ. of Iowa, USA Charles Perkins, Sun Microsystems, USA Hasan Pirkul, Univ. of Texas, Dallas, USA Sara Porat, IBM Corp., Israel Kotagiri Ramamohanarao, Univ. of Melbourne, Australia Louiqa Raschid, Univ. of Maryland, USA Arie Segev, UC Berkeley, USA Olivia Sheng, Univ. of Arizona, USA Andrew Whinston, Univ. of Texas, Austin, USA Leon Zhao, Univ. of Science & Tech., Hong Kong ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu From rem-conf Fri May 15 06:47:47 1998 From rem-conf-request@es.net Fri May 15 06:47:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yaKo9-0003gN-00; Fri, 15 May 1998 06:45:57 -0700 Received: from pi4.informatik.uni-mannheim.de [134.155.48.125] (-2146555104) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yaKo7-0003gB-00; Fri, 15 May 1998 06:45:56 -0700 Received: from pyrrhon.informatik.uni-mannheim.de (root@pyrrhon [134.155.48.103]) by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with ESMTP id PAA11363 for ; Fri, 15 May 1998 15:45:53 +0200 (MET DST) Received: from pi4.informatik.uni-mannheim.de (geyer@localhost [127.0.0.1] (may be forged)) by pyrrhon.informatik.uni-mannheim.de (8.8.7/8.8.7) with ESMTP id PAA21749 for ; Fri, 15 May 1998 15:45:52 +0200 (MET DST) Sender: geyer@pi4.informatik.uni-mannheim.de Message-ID: <355C470E.8EE97BF9@pi4.informatik.uni-mannheim.de> Date: Fri, 15 May 1998 15:45:50 +0200 From: Werner Geyer Organization: University of Mannheim X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: New sdr plugin fails on SGI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I've written a new sdr plugin for whiteboard media and I'm wondering why this plugin works fine with solaris 2.6 and Linux sdr version but not with SGI. We have installed sdr v2.3a1 and the plugin is written according to the description in the sdr help. Has anybody encountered the same problem or is this a bug on SGI or is something wrong with my plugin??? Can anybody help me out with this? The plugin looks like this: media:whiteboard proto:udp tool:dlb fmt:dlb flags:-t $(TTL) flags:$(ADDRESS)/$(PORT) Thank you very much, Werner ______________________________________________________________ Werner Geyer, University of Mannheim, Praktische Informatik IV Tel +49-621-292-1526 ,Fax +49-621-292-5745 EMail: geyer@pi4.informatik.uni-mannheim.de http://www.informatik.uni-mannheim.de/~geyer/ From rem-conf Mon May 18 12:09:06 1998 From rem-conf-request@es.net Mon May 18 12:08:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ybUvc-0003wb-00; Mon, 18 May 1998 11:46:28 -0700 Received: from cs.gmu.edu [129.174.87.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ybUvb-0003wL-00; Mon, 18 May 1998 11:46:27 -0700 Received: from markov (markov [129.174.87.29]) by cs.gmu.edu (8.8.5/8.8.5) with SMTP id NAA19590 for ; Mon, 18 May 1998 13:03:57 -0400 (EDT) From: Sanjeev Setia Received: by markov (SMI-8.6) id NAA19130; Mon, 18 May 1998 13:06:41 -0400 Date: Mon, 18 May 1998 13:06:41 -0400 Message-Id: <199805181706.NAA19130@markov> To: sigmetrics98@cs.gmu.edu Subject: ACM Sigmetrics 98/Performance 98 Early Registration Deadline (May 22) X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (My apologies if you have already received this message.) Dear Colleagues: The ACM Sigmetrics '98/Performance '98 Joint Conference will be held in Madison, Wisconsin from June 22-26. The EARLY REGISTRATION DEADLINE for the conference is May 22. Some highlights of the conference are: * strong tutorial program, June 22 (pm) and June 23 * Workshop on Internet Server Performance, June 23 (Tutorial Track 5) * Keynote address by Dr. Susan Owicki: "The Technological Basis of Electronic Commerce" * strong conference program with a nice mixture of theory and applied performance evaluation. The web site contains the full program as well as registration forms for the tutorial/workshop and conference: http://www.cs.gmu.edu/conf/sigmetrics98 Please register early to avail of the discounted registration fees. Sanjeev Setia ACM Sigmetrics 98 Publicity Co-chair From rem-conf Mon May 18 13:40:23 1998 From rem-conf-request@es.net Mon May 18 13:40:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ybWYp-0005CI-00; Mon, 18 May 1998 13:31:03 -0700 Received: from news.engr.udayton.edu [131.238.32.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ybWYo-0005C8-00; Mon, 18 May 1998 13:31:02 -0700 Received: from udecc.engr.udayton.edu (udecc.engr.udayton.edu [131.238.32.19]) by news.engr.udayton.edu (8.8.8/8.8.8) with SMTP id QAA22963 for ; Mon, 18 May 1998 16:31:00 -0400 (EDT) Received: from ensun103.UD.Engr by udecc.engr.udayton.edu (5.0/SMI-SVR4) id AA15339; Mon, 18 May 1998 16:30:38 -0400 Received: by ensun103.UD.Engr (SMI-8.6/SMI-SVR4) id QAA10200; Mon, 18 May 1998 16:28:34 -0400 Message-Id: <199805182028.QAA10200@ensun103.UD.Engr> Subject: CFP: IC3N'98: 7th Int Conf on Comp Communications & Networks To: rem-conf@es.net Date: Mon, 18 May 1998 16:28:33 -0400 (EDT) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] 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 **************************************************************************** ********* Pls note new submission deadline of May 29, 1998 ***************** **************************************************************************** IC3N'98 CALL FOR PAPERS SEVENTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS October 12-15, 1998, Lafayette, Louisiana, USA Sponsored (pending approval) by IEEE Communication Society (TCCC Tech. Co-Sponsor), BellSouth, Army Research Office, NASA. In cooperation (pending approval) with The Center for Telecommunications Studies and the Center for Advanced Computer Studies at USL, NSF, NIST, ACM. Technical co-sponsored by IEEE COMSOC Technical Committee on Personal Communications (TCPC), Technical Committee on Parallel Processing (pending), IEEE ComSoc Technical Committee on Network Operations and Managements (CNOM) http://www.cacs.usl.edu/~ic3n The objective of this conference is to provide an effective forum for original and fundamental advances in Computer Communications and Networks and 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 solicit the submission of papers that address novel, challenging and innovative results. Therefore the topics that will be addressed include, but are not limited to: o Optical Communications Networks o Wireless/Mobile Communication Networks o ATM Networking o Internet Services/Applications o Wireless Multimedia Applications o Real-time Communications o Quality of Services (QoS) Issues o LAN/WAN Internetworking o Network Interoperability & Scalability o Personal Communication Services o Network Control Management o Broadband Networks o Intelligent Networks o Multicast & Routing Protocols o Network Security o Media Access Control/Mobility Algorithms o Network Reliability o High Speed Network OAM/Protocols o Video-on-Demand o Data Traffic Engineering o Network Management o Global Infrastructure Network Evolution o Multimedia Human-Machine Interface o Performance Modeling/Analysis o Communication Software o Protocol Design/Validation/Testing o Networked Databases o Network Architectures SUBMISSION =========== Authors are invited to submit complete and original papers. Papers that may be submitted for consideration include those that have not previously been published in another forum, or are not currently being published or reviewed 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. Authors will be interested to know that 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. Six copies of the manuscript should be submitted by Friday, May 29,1998 (extended) to one of the Program Co-Chairs: Dr. Kia Makki The Center for Telecommunications Studies The University of Southwestern Louisiana Lafayette, LA 70504-3890 e-mail: kia@usl.edu Tel: (318) 482-5872 Fax: (318) 482-5872 Dr. Imrich Chlamtac MS EC33, P.O. Box 830688 The University of Texas at Dallas Richardson, TX 75083 e-mail: chlamtac@utdallas.edu Tel: (972) 883-6295 Fax: (972) 883-2710 For more information about the conference (as opposed to paper submissions) please send e-mail to ic3n@cacs.usl.edu. IMPORTANT DATES ================ Paper submission deadline: May 29, 1998 Notification of acceptance: July 17, 1998 Camera ready papers due: August 10, 1998 WORKSHOPS, TUTORIALS AND INDUSTRIAL EXHIBITS ============================================ Proposals must clearly identify the intended audience. Tutorial proposal should be considerably broader than the communications and network research communities. Exhibits should should illustrate innovative technology. Please send your proposal by May 29, 1998 to Professor O. Frieder, Workshop and Tutorial Chair, College of Engineering, Florida Institute of Technology, Melbourne, FL 32901 (ophir@ee.fit.edu). SOCIAL ACTIVITIES ================== Lafayette is situated within 130 miles of New Orleans and 220 miles of Houston. It is serviced by the major Airlines. It is famous for its distinct Cajun culture, food and music. Besides the technical program, a very entertaining social program and tours are being planned. CONFERENCE ORGANIZING COMMITTEE =============================== General Chairs: B. Mukherjee, UC Davis N. Pissinou, USL Program Chairs: I. Chalmtac, UT Dallas K. Makki, USL Program Vice-Chairs: Y. Fang, UT Dallas C. Qiao, SUNY Buffalo Program Committee: I. F. Akyildiz, Georgia Tech. M. H. Ammar, Georgia Tech. H. Arabnia, U. of Georgia B. Chen, UT Dallas J. C.I. Chuang, AT&T Labs-Research P. Dowd, DoD D. Everitt, Univ. of Melbourne, Australia A. Farago, UT Dallas B. Gavish, Vanderbilt U. S. Goyal, GTE Labs R. Guerin, IBM T.J.Watson Research Center Z. Haas, Cornell Univ. D. Kazakos, USL L. Kleinrock, UCLA R. Krishnan, UT Dallas Y. B. Lin, NCTU, Taiwan T. Liu, Ascend Communications M. T. Liu, Ohio State U. F. Lombardi, Texas A&M S. Makki, RMIT P. McKinley, Michigan State. R. Melhem, Univ of Pittsburgh W. M. Moh, San Jose St. L. E. Moser, UC S. Barbara M. Mutka, Michigan State L. Ni, Michigan State Y. Pan, U. of Dayton D. K. Panda, Ohio State W. Peng, SW Texas State G. Polyzos, UC San Diego S. S. Rappaport, SUNY at Stony Brooks I. Rubin, UCLA S. Sahni, U. of Florida G. Sasaki, U. Hawaii M. Schwartz, Columbia U. M. Singhal, Ohio State K. Sohraby, U. of Missouri A. K. Somani, Iowa State T. Todd, McMaster H.C. Torng, Cornell U. E. Torng, Michigan State S. Tripathi, UC Riverside Y. Yang, U. of Vermont T. Znati, Univ. of Pittsburgh Z. Zhang, Bell Laboratories others (See Web Site) Industrial Committee: K. Bhat, Lucent Tech. C. Fayet, INT, France A. Gaivoronski, ITALTEL IT A. Kogiantis, Lucent Tech. P. O'Reilly, GTE Lab. H. Saito, NTT, Japan A. Vernon, BellSouth H. Rudin, IBM, Switzerland Government Committee: S. Balikirsky, US Army P. W. Dowd, U.S. Department of Defense D. Fisher, NSF M. Halem, NASA D. Su, NIST D. Grossman, US Gov. T. Pressley, ARO International Committee: I. Cidon, Technion, Israel T. S. Dillon, LaTrobe, AU J. Misic, Hong U. ST Y. Oie, KIT, Japan Z. Y. Zomaya, UWA, AU Publicity Chairs: M. Atiquzzaman, U. Dayton J. Wigglesworth, IBM CA Panel Chairs: F. Golshani, Arizona State M. S. Obaidat, Monmouth Local Arrangm. Chair: R. Henry, USL Social Activities Chair: J. V. Lillie, BellSouth Treasurer: E. K. Park, U. of Missouri Registration Chairs: S. Busovaca, Cal. State Sac X. Jia, City U. Hong Kong Information: http://www.cacs.usl.edu/~ic3n From rem-conf Tue May 19 14:57:51 1998 From rem-conf-request@es.net Tue May 19 14:57:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ybtsI-0000P0-00; Tue, 19 May 1998 14:24:42 -0700 Received: from yosemite.main.gnac.com [198.151.248.221] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ybtsG-0000Op-00; Tue, 19 May 1998 14:24:40 -0700 Received: by yosemite.main.gnac.com; id OAA05409; Tue, 19 May 1998 14:24:38 -0700 (PDT) From: Received: from dhcp-211.main.gnac.com(192.168.1.211) by yosemite.main.gnac.com via smap (4.1) id xma005402; Tue, 19 May 98 14:24:12 -0700 Received: (from greg@localhost) by localhost.main.gnac.com (8.8.7/8.8.8) id OAA09543; Tue, 19 May 1998 14:24:31 -0700 Message-Id: <199805192124.OAA09543@localhost.main.gnac.com> Subject: BayLISA meeting: IP over ATM (Berry Kercheval) To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org Date: Tue, 19 May 1998 14:24:31 -0700 (PDT) Cc: blw@baylisa.org Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. *** *** NOTE: As of the upcoming May meeting, we have a new meeting space! *** We are now at the "Network Meeting Center at Techmart". Directions can be found on our web page at http://www.baylisa.org/locations/techmart.html The meetings are also broadcast via MBONE. Schedule -------- Thursday, 21 May, 1998: IP over ATM, Berry Kercheval Author Berry Kercheval will be talking about his experiences running IP over ATM. This talk will be an overview of ATM technology and how IP traffic can be carried over it. Following a brief introduction to ATM, I will discuss the two main approaches in current use: the IETF's "Classical IP" and the ATM Forum's "LAN Emulation". Pros and cons of both schemes will be addressed. #### For further information on BayLISA, check out our web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/BayLISA/location or you can query the BayLISA mail server by cutting and pasting the following line to your shell: echo "index baylisa" | mail majordomo@baylisa.org BayLISA makes video tapes of the meetings available to members. For more information on available videos, please send email to: video@baylisa.org For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or the info alias listed above. -- Greg A. Kulosa | "The avalanche has already started, it is too Systems Administrator | late for the pebbles to vote." - Ambassador Kosh GNAC, Inc. |___________________________________________________ greg@gnac.com 999 Main Street - Redwood City, CA 94063 From rem-conf Wed May 20 07:02:54 1998 From rem-conf-request@es.net Wed May 20 07:02:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yc9Mz-0006ea-00; Wed, 20 May 1998 06:57:25 -0700 Received: from ietf.org [132.151.1.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yc9My-0006e7-00; Wed, 20 May 1998 06:57:24 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA13979; Wed, 20 May 1998 09:56:19 -0400 (EDT) Message-Id: <199805201356.JAA13979@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-aggregation-00.txt Date: Wed, 20 May 1998 09:56:18 -0400 Sender: cclark@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 User Multiplexing Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-aggregation-00.txt Pages : 10 Date : 19-May-98 This memo describes an RTP payload format for multiplexing data from multiple users into a single RTP packet. Such multiplexing is especially useful for transporting voice data between Internet telephony gateways. It causes significant reductions in header overheads and improves scalability. Internet-Drafts are 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-aggregation-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-aggregation-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-aggregation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980519104700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-aggregation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-aggregation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980519104700.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed May 20 10:58:39 1998 From rem-conf-request@es.net Wed May 20 10:58:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycD5m-0001Xp-00; Wed, 20 May 1998 10:55:54 -0700 Received: from netserver.buyersusa.com [208.215.223.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycD5l-0001XJ-00; Wed, 20 May 1998 10:55:53 -0700 Received: from 208.215.223.7 [208.215.223.7] by netserver.buyersusa.com (SMTPD32-4.03) id A8E0378A0146; Wed, 20 May 1998 12:54:40 EST5EDT From: frank@newquestcity.com To: rem-conf@es.net Subject: Directory Listings Date: Wed, 20 May 1998 12:48:28 -0500 X-Mailer: Allaire Cold Fusion 3.1 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just came across your e-mail address on a Web site. Apparently you have an interest in people finding out about you. Let me suggest a few directories that you may use for FREE advertising and exposure. (You may list yourself on these directories even if you don't have a Web page. And, there is absolutely no fee or strings attached.) National Business Directory http://www.newquestcity.com/dir.htm National Community Directory http://www.newquestcity.com/comdir.htm National Realty Directory http://www.newquestcity.com/natdir.htm These directories allow you to classify your organization or business in one of over 1,000 categories. Your listing appears simultaneously in one of the over 3,500 New Quest City community or business directories. You may post your listing in more than one city or nationally. (http://www.newquestcity.com) To make your posting simply find other listings in your category. On the results page you will find a link for submitting your listing. Remember that this is a totally FREE service. I am contacting you because I think these directories are something that you will benefit from. If for some reason I have contacted you in error, please accept my sincere apology. Unless you respond, I will make the utmost effort to ensure that I never contacted you again. Nevertheless, I do hope that you take the time to visit New Quest City and review our programs and features. Thanks. Sincerely, Frank Frank@newquestcity.com From rem-conf Wed May 20 13:47:29 1998 From rem-conf-request@es.net Wed May 20 13:47:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycFfq-0003F9-00; Wed, 20 May 1998 13:41:18 -0700 Received: from golden.net [199.166.210.183] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycFfo-0003ER-00; Wed, 20 May 1998 13:41:16 -0700 Received: from AS52-38-105.cas-kit.golden.net (AS52-38-105.cas-kit.golden.net [209.183.135.105]) by golden.net (8.8.5/8.6.12) with SMTP id QAA19912 for ; Wed, 20 May 1998 16:41:02 -0400 (EDT) Received: by AS52-38-105.cas-kit.golden.net with Microsoft Mail id <01BD840E.09B66980@AS52-38-105.cas-kit.golden.net>; Wed, 20 May 1998 16:40:46 -0400 Message-ID: <01BD840E.09B66980@AS52-38-105.cas-kit.golden.net> From: Paul Reader To: "rem-conf@es.net" Subject: remove Date: Wed, 20 May 1998 16:40:44 -0400 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 From rem-conf Wed May 20 13:58:10 1998 From rem-conf-request@es.net Wed May 20 13:58:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycFuZ-0003mb-00; Wed, 20 May 1998 13:56:31 -0700 Received: from bsu.edu (wizard.bsu.edu) [147.226.53.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycFuY-0003kZ-00; Wed, 20 May 1998 13:56:30 -0700 Received: from bsu-cs.bsu.edu (bsu-cs.bsu.edu [147.226.112.101]) by wizard.bsu.edu (8.8.7/8.8.7) with ESMTP id PAA20974 for ; Wed, 20 May 1998 15:57:02 -0500 (EST) Received: (from lguo@localhost) by bsu-cs.bsu.edu (8.8.7/8.8.7) id PAA28117 for rem-conf@es.net; Wed, 20 May 1998 15:58:06 -0500 (EST) Date: Wed, 20 May 1998 15:58:06 -0500 (EST) From: Lijia Guo Message-Id: <199805202058.PAA28117@bsu-cs.bsu.edu> To: rem-conf@es.net Subject: Re: remove X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove From rem-conf Wed May 20 14:23:00 1998 From rem-conf-request@es.net Wed May 20 14:22:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycGIr-0004ol-00; Wed, 20 May 1998 14:21:37 -0700 Received: from alpo.casc.com [152.148.10.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycGIp-0004o8-00; Wed, 20 May 1998 14:21:35 -0700 Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id RAA04010; Wed, 20 May 1998 17:20:30 -0400 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id RAA00777; Wed, 20 May 1998 17:20:31 -0400 Date: Wed, 20 May 1998 17:20:30 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice Reply-To: "Andrew G. Malis" To: jdrosen@bell-labs.com, schulzrinne@cs.columbia.edu cc: "Andrew G. Malis" , rem-conf@es.net Subject: draft-ietf-avt-aggregation-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan and Henning, I've just joined the rem-conf list, so please forgive me if I bring up any issues that have already been discussed. I just read your draft, and I have a few questions as a result. It requires that all of the multiplexed streams share a common base sampling rate, and it can add a variable amount of delay as incoming samples to the mux are buffered to wait for other samples that will be combined in a single RTP packet. I was curious if the practicality of this requirement and the buffering delay have been discussed in the group at all. I was also curious if possible interactions with draft-ietf-avt-crtp-04.txt have been considered, since the compression it provides is a huge win. Thanks, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 From rem-conf Wed May 20 17:46:39 1998 From rem-conf-request@es.net Wed May 20 17:46:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycJMx-00079Q-00; Wed, 20 May 1998 17:38:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycJMv-00079G-00; Wed, 20 May 1998 17:38:01 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed May 20 20:37:46 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA29373; Wed, 20 May 1998 20:37:45 -0400 (EDT) Message-ID: <356376E6.1FF983D9@dnrc.bell-labs.com> Date: Wed, 20 May 1998 20:35:50 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Andrew G. Malis" CC: schulzrinne@cs.columbia.edu, rem-conf@es.net Subject: Re: draft-ietf-avt-aggregation-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Andrew G. Malis wrote: > > Jonathan and Henning, > > I've just joined the rem-conf list, so please forgive me if I bring up > any issues that have already been discussed. Being that the draft only appeared this morning in the archives, this discussion is the first :) > It requires that all of the multiplexed streams share a common base > sampling rate, and it can add a variable amount of delay as incoming > samples to the mux are buffered to wait for other samples that will be > combined in a single RTP packet. I was curious if the practicality of > this requirement and the buffering delay have been discussed in the > group at all. By sampling rate, I assume you mean frame size (10ms for G.729, for example), and not A->D sampling rate (8 khz, for example). The draft does not require all users in a packet to have equal frame sizes. The draft proposes that users be clustered into groups, and each group has its media frames encapsulated together in an RTP packet. The only requirement of users in a group is that the timestamp of their media frames be the same in the given packet. Lets say, for example, two users (1 and 2) are multiplexed. User 1 has a frame size of 20ms, and 2 has a frame size of 10. You can operate with two user groups (A and B), both with packets sent every 20ms, but out of phase by 10ms. User 1 places a frame in each packet of group A, while user 2 places frames in each packet in both groups A and B. Note that there is no additional delay introduced here, and that the users are muxed together 50% of the time. Essentially, the requirement for efficient multiplexing is that the frame sizes of the codecs have a greatest common divisor that is as large as possible. It was my assumption in writing the draft that most systems would operate with codecs that run at some multiple of a base size (10ms, say). If this is not the case, I would appreciate input to that regard. Our earlier draft on multiplexing allowed for mixing of completely disparate frame sizes in the same packet, but at the cost of a larger per-user header. The amount of additional delay introduced by the scheme depends entirely on how it is used. In the above example, there was no additional delay. If, instead, the system were run with a single user group, with packets sent every 20ms, user 2 would suffer an additional 10ms packetization delay. It is therefore at the discretion of the implementor to determine the acceptable level of delay/efficiency tradeoff. > I was also curious if possible interactions with > draft-ietf-avt-crtp-04.txt have been considered, since the compression > it provides is a huge win. Its use of SSRC-based user groups means it should work quite well with RTP header compression. Each user group will be considered a separate compression context. As the SN and TS within each group should generally behave "well", I don't see any problems. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu May 21 00:48:13 1998 From rem-conf-request@es.net Thu May 21 00:48:10 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0ycPy4-0006JU-00; Thu, 21 May 1998 00:40:48 -0700 Received: from 1cust227.tnt1.hilo.hi.gt.uu.net ([208.255.248.227] helo=43ds) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0ycPy2-0006JK-00; Thu, 21 May 1998 00:40:46 -0700 Date: Wed, 20 May 1998 18:05:00 From: To: Subject: Your web site... Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Would you like to improve your website's "find-ability" in the Search Engines? During the past two years, my company has been placing hundreds of webpages into the Top Ten -- the front page -- of the major search engines... and for a small fee, I will show you how we do it... and I'll share with you our ongoing research -- every month! My name is Stephen Mahaney. I am the president of Planet Ocean Communications. My web marketing company has literally "written the book" on how to position your website on the front page -- the Top Ten -- of each of the major search engines... guaranteed! Our 65 page manual identifies every trick & technique that is being used on the Internet to gain an almost "unfair" advantage in landing websites at the top of the search engine lists -- right where you need to be so that potential customers who are seeking your services or products can find you. Our monthly Newsletter keeps you abreast of the latest techniques and frequent changes that take place in the dynamic world of "search engine" science. However, understanding the process does not require a degree in "rocket" science -- nor do you need to be "technically oriented". Whether your website is a "do-it-yourself" project or you are paying someone to maintain your site, you (or your webmaster) need to know the tricks in this book in order to compete with the professionals who are dominating the front pages of the various search categories. To learn more about how you can obtain this essential information and receive a free subscription to our Newsletter -- SEARCH ENGINE SECRETS UPDATE, go to....   http://www.searchengine-help.com/rankings/ You'll be glad you did. Sincerely, Stephen Mahaney - President Planet Ocean Communications *************************************************** Note: We have contacted you based on information that we gathered while visiting your website - If you would prefer not to receive mail from us in the future, simply reply with the word "remove" in the subject line and you will be automatically excluded from future correspondence. Thanks *************************************************** Thought for the day... "The only thing a man can take beyond this lifetime is his ethics" From rem-conf Thu May 21 05:30:53 1998 From rem-conf-request@es.net Thu May 21 05:30:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycURu-0004NW-00; Thu, 21 May 1998 05:27:54 -0700 Received: from alpo.casc.com [152.148.10.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycURs-0004NC-00; Thu, 21 May 1998 05:27:52 -0700 Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id IAA06513; Thu, 21 May 1998 08:26:47 -0400 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id IAA00993; Thu, 21 May 1998 08:26:47 -0400 Date: Thu, 21 May 1998 08:26:47 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: Jonathan Rosenberg cc: schulzrinne@cs.columbia.edu, rem-conf@es.net Subject: Re: draft-ietf-avt-aggregation-00.txt In-Reply-To: <356376E6.1FF983D9@dnrc.bell-labs.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 Jonathan, > > It requires that all of the multiplexed streams share a common base > > sampling rate, and it can add a variable amount of delay as incoming > > samples to the mux are buffered to wait for other samples that will be > > combined in a single RTP packet. I was curious if the practicality of > > this requirement and the buffering delay have been discussed in the > > group at all. > > By sampling rate, I assume you mean frame size (10ms for G.729, for > example), and not A->D sampling rate (8 khz, for example). Yes, thanks for clarifying. > The amount of additional delay introduced by the scheme depends entirely > on how it is used. In the above example, there was no additional delay. > If, instead, the system were run with a single user group, with packets > sent every 20ms, user 2 would suffer an additional 10ms packetization > delay. It is therefore at the discretion of the implementor to determine > the acceptable level of delay/efficiency tradeoff. The case I had in mind was multiple independent IP-based sources having their streams muxed together (say, by a router at the edge of a WAN). If all of the sources were sending their own packets every 10 ms, and the muxed packets were sent across the WAN every 10 ms, then the sources would have an average of 5 ms additional delay (and worse case just under 10 ms). This could also conceivably affect the playback, since the original timestamps are lost. However, if your source is a PBX or a PSTN gateway, then the syncronization is automatic and there aren't any playback concerns. But of course you're right, it's under the control of the implementer or network operator (to the extent that the muxing is made configurable). > > I was also curious if possible interactions with > > draft-ietf-avt-crtp-04.txt have been considered, since the compression > > it provides is a huge win. > > Its use of SSRC-based user groups means it should work quite well with > RTP header compression. Each user group will be considered a separate > compression context. As the SN and TS within each group should generally > behave "well", I don't see any problems. Thanks - good to hear. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 From rem-conf Thu May 21 06:40:36 1998 From rem-conf-request@es.net Thu May 21 06:40:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycVXo-0005Wt-00; Thu, 21 May 1998 06:38:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycVXn-0005Wh-00; Thu, 21 May 1998 06:38:03 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 21 09:36:23 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA10018; Thu, 21 May 1998 09:36:23 -0400 (EDT) Message-ID: <35642D61.80EEC61E@dnrc.bell-labs.com> Date: Thu, 21 May 1998 09:34:25 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Andrew G. Malis" CC: schulzrinne@cs.columbia.edu, rem-conf@es.net Subject: Re: draft-ietf-avt-aggregation-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Andrew G. Malis wrote: > > > The amount of additional delay introduced by the scheme depends entirely > > on how it is used. In the above example, there was no additional delay. > > If, instead, the system were run with a single user group, with packets > > sent every 20ms, user 2 would suffer an additional 10ms packetization > > delay. It is therefore at the discretion of the implementor to determine > > the acceptable level of delay/efficiency tradeoff. > > The case I had in mind was multiple independent IP-based sources having > their streams muxed together (say, by a router at the edge of a WAN). > If all of the sources were sending their own packets every 10 ms, and > the muxed packets were sent across the WAN every 10 ms, then the > sources would have an average of 5 ms additional delay (and worse case > just under 10 ms). This could also conceivably affect the playback, > since the original timestamps are lost. However, if your source is a > PBX or a PSTN gateway, then the syncronization is automatic and there > aren't any playback concerns. Actually, the WAN edge mux example you mention is quite problematic, and isn't easily supported by the protocol described in the draft. The assumption in our draft was that the media were generated locally by the entity performing the muxing, not by outside sources. As a result, I see the following problems applying the protocol: 1. The SSRC in the RTP packets being muxed will likely never be the same; RTP timestamps are chosen with a random offset. As the protocol requires the users in a user group to share a common base timestamp, no muxing could occur. 2. The SSRC of the RTP packets being muxed will be lost, as these are not carried by the protocol. This means that (among other things) the RTCP packets generated by the sources will be ignored if transmitted end to end. So, they must be dropped, and the mux point has to generate new RTCP for the muxed source. 3. Any header extension or CSRC information in the muxed packets would be lost. 4. The UDP header information in the muxed packets also needs to be conveyed across the multiplex. This is not supported in our draft either. Basically, as there is no redundancy of information in the headers of the packets being muxed, you would need to retain the entire UDP/RTP header in the multiplex. In that case, the problem is not actually RTP specific. What you are looking for is a general tunelling mechanism which allows you to place multiple IP packets within a single tunneled packet. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu May 21 06:46:23 1998 From rem-conf-request@es.net Thu May 21 06:46:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycVfX-0005nr-00; Thu, 21 May 1998 06:46:03 -0700 Received: from alpo.casc.com [152.148.10.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycVfW-0005li-00; Thu, 21 May 1998 06:46:02 -0700 Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id JAA12276; Thu, 21 May 1998 09:44:57 -0400 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id JAA01029; Thu, 21 May 1998 09:44:57 -0400 Date: Thu, 21 May 1998 09:44:57 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: Jonathan Rosenberg cc: schulzrinne@cs.columbia.edu, rem-conf@es.net Subject: Re: draft-ietf-avt-aggregation-00.txt In-Reply-To: <35642D61.80EEC61E@dnrc.bell-labs.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 Jonathan, > Actually, the WAN edge mux example you mention is quite problematic, and > isn't easily supported by the protocol described in the draft. The > assumption in our draft was that the media were generated locally by the > entity performing the muxing, not by outside sources. OK, thanks again. I've got a much better feel for the draft and its application. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 From rem-conf Thu May 21 07:59:19 1998 From rem-conf-request@es.net Thu May 21 07:59:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycWlI-0007Bb-00; Thu, 21 May 1998 07:56:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycWlH-0007BR-00; Thu, 21 May 1998 07:56:03 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu May 21 10:55:29 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA12895; Thu, 21 May 1998 10:55:27 -0400 (EDT) Message-ID: <35643FEA.A5FB8638@dnrc.bell-labs.com> Date: Thu, 21 May 1998 10:53:30 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net, confctrl@isi.edu Subject: SIP and RTP correlations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I believe there is a need to be able to associate RTP packets with the SIP address of the entity which generated them. There are a few examples of where this is useful: 1. In a multicast conference, you hear audio from someone and want to invite them to a side conference using SIP. 2. You sent out a SIP INVITE, and got two 200 responses, both of which are ACK'ed. The caller now receives audio from both sources to the same port. How does it know which RTP stream is associated with which SIP entity? Such correlation is needed for various UI features. There seem to be a number of possible solutions: 1. Include the CNAME as a header somewhere in the SIP INVITE message or SDP. This solves problem 2 above, but not problem 1. 2. Include the SSRC as a header somewhere in the SIP INVITE or SDP. This also solves problem 2, but not 1. It has the additional drawback that SSRC are not fixed, and may change due to a collision. 3. Use the EMAIL SDES item. For problem (1), you would send a SIP invite to the address listed in the email identifier. For problem (2), the email identifier could be matched with the contents of the Location header to perform the correlation. The problem here is that SIP addresses need not be the same as the user's email address. 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP address. The ITU folks did a similar thing for H.332; they have registered an H.323-CADDR type used for solving problem (1). Comments or other possibilities? Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu May 21 08:46:06 1998 From rem-conf-request@es.net Thu May 21 08:46:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycXVM-0000Jf-00; Thu, 21 May 1998 08:43:40 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycXVL-0000JT-00; Thu, 21 May 1998 08:43:39 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id LAA29476; Thu, 21 May 1998 11:43:28 -0400 (EDT) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id LAA19305; Thu, 21 May 1998 11:43:27 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <35644B9F.646A@cs.columbia.edu> Date: Thu, 21 May 1998 11:43:27 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.03 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Jonathan Rosenberg CC: rem-conf@es.net, confctrl@isi.edu Subject: Re: SIP and RTP correlations References: <35643FEA.A5FB8638@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: > > I believe there is a need to be able to associate RTP packets with the > SIP address of the entity which generated them. There are a few examples > of where this is useful: > > 1. In a multicast conference, you hear audio from someone and want to > invite them to a side conference using SIP. > 2. You sent out a SIP INVITE, and got two 200 responses, both of which > are ACK'ed. The caller now receives audio from both sources to the same > port. How does it know which RTP stream is associated with which SIP > entity? Such correlation is needed for various UI features. > > 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP > address. The ITU folks did a similar thing for H.332; they have > registered an H.323-CADDR type used for solving problem (1). Only solution (4) seems generic enough, and we definitely want to avoid making SSRCs visible outside RTP as much as we can. Given the bandwidth limitation of the RTCP channel, allowing re-use of the same identifier is helpful, since having H323-CADDR: foo@bar SIP-CADDR: foo@bar WhitePine-CADDR: foo@bar is very inefficient, in particular since it is likely that many of these addresses are going to be of the user@host variety. We could use something like CADDR: {sip,h323,whitepine}:foo@bar or a binary equivalent. From rem-conf Thu May 21 10:37:32 1998 From rem-conf-request@es.net Thu May 21 10:37:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycZE4-0001e3-00; Thu, 21 May 1998 10:33:56 -0700 Received: from mail4-b.microsoft.com [131.107.3.122] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycZE3-0001dp-00; Thu, 21 May 1998 10:33:55 -0700 Received: by mail4-b.microsoft.com with Internet Mail Service (5.5.2217.0) id ; Thu, 21 May 1998 10:26:07 -0700 Message-ID: <5BF896CAFE8DD111812400805F1991F701FE807A@red-msg-08.dns.microsoft.com> From: Jim Gemmell To: 'Julian Highfield' , Yves Lepage , rem-conf@es.net Subject: wbd on NT ( was RE: Declining audiences? (Was: Netshow and the MB ONE)) Date: Thu, 21 May 1998 10:17:58 -0700 X-Mailer: Internet Mail Service (5.5.2217.0) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just tried it out on NT 4 and it seemed to work fine. Postscript didn't work for me, but I'm not sure if I have the right version of ghostsript. > -----Original Message----- > From: Julian Highfield [mailto:J.C.Highfield@maybeso.demon.co.uk] > Sent: Wednesday, April 22, 1998 7:24 PM > To: Yves Lepage; rem-conf@es.net > Subject: RE: Declining audiences? (Was: Netshow and the MBONE) JG: WBD > > > Yves Lepage wrote: > > > >Since then, my desktop is NT. This makes it much more > problematic. I am > >not going to purchase IP/TV or Icast. My only option from > that point is > >to use the freeware apps, which are not really mature on MS OS'es. > > If you noticed the lack of a "wb" whiteboard I can perhaps help: > http://www.stile.lboro.ac.uk/~cojch/winwbd/winwbd.html Of course, I've only tested it under Windows 95 because I've never met anyone who will admit to using NT... Regards, Julian. From rem-conf Thu May 21 12:02:57 1998 From rem-conf-request@es.net Thu May 21 12:02:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycaZY-0002wG-00; Thu, 21 May 1998 12:00:12 -0700 Received: from chainmail.everyware.com [209.121.83.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycaZX-0002vr-00; Thu, 21 May 1998 12:00:11 -0700 Received: from cmoffett [207.181.72.91] by chainmail.everyware.com (SMTPD32-4.04) id A98E7080210; Thu, 21 May 1998 14:59:26 EST To: From: ghj45@yahoo.com Bcc: rem-conf@es.net, btrippett@everett.net, info@monroe.net, rfindley@premier1.net, info@icehouse.net, rey@inforamp.net, bh470@torfree.net, webmaster@paconline.net, websolutions@canfind.net, webmaster@monroe.net Subject: Invitation Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII content-length: 2065 Date: Thu, 21 May 98 15:00:10 EST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are invited to an important Web developer/ISP seminar in beautiful Vancouver British Columbia. As a Web developer, are you - Interested in increasing your customer base with innovative services? - Constantly challenged to push the envelope in order to provide top-notch, Web based business applications? - Looking for a more efficient way of building database access over the Internet? - In need of providing better Web site statistical information? As an ISP, are you - Interested in increasing your customer base with innovative services? - Constantly challenged to push the envelope in order to provide top-notch Web hosting services? - Looking for a revenue generating way of providing database hosting services? - In need of providing better Web site statistical information? If so, participate in this action-packed 2-hour FREE seminar sponsored by EveryWare Development Inc. The focus of the presentation will be on 2 key areas of interest for today's Internet professional. 1. Building Database functionality over the Web 2. Tracking and Managing web site usage To find out more go to: http://betawest.everyware.com/sales/index.html Or read on... Date: Friday June 5, 1998 Time: From 9:30 AM to 11:30 AM - Web Developers; From 1:30 PM to 3:30 PM - ISP's Location: Simon Fraser University at Harbour Centre http://www.harbour.sfu.ca/ 515 West Hastings Street Vancouver, British Columbia V6B 5K3 Room 1700, Labatt Hall Contact Linda Hewitt lhewitt@sfu.ca 604/291.5085 Over $10,000 in door prizes! -refreshments -hands-on training -meet and learn from other professionals **Space is Limited** Get all the details and Register Now to receive a full Tango Developer license valued at $695 US for $95 US! http://betawest.everyware.com/sales/index.html For more information contact: Chris Moffett cmoffett@everyware.com 604/464.8704 www.everyware.com EveryWare Development Inc. If no longer want to receive messages from this list send "remove from list" in the body of your text and e-mail to: northwestsales@everyware.com From rem-conf Thu May 21 12:28:47 1998 From rem-conf-request@es.net Thu May 21 12:28:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycb05-0003gQ-00; Thu, 21 May 1998 12:27:37 -0700 Received: from chainmail.everyware.com [209.121.83.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycb03-0003gG-00; Thu, 21 May 1998 12:27:35 -0700 Received: from cmoffett [207.181.72.135] by chainmail.everyware.com (SMTPD32-4.04) id A0043A70222; Thu, 21 May 1998 15:27:00 EST To: From: ghj45@yahoo.com Bcc: rem-conf@es.net, btrippett@everett.net, info@monroe.net, rfindley@premier1.net, info@icehouse.net, rey@inforamp.net, bh470@torfree.net, webmaster@paconline.net, websolutions@canfind.net, webmaster@monroe.net Subject: Invitation Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII content-length: 2065 Date: Thu, 21 May 98 15:27:35 EST X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You are invited to an important Web developer/ISP seminar in beautiful Vancouver British Columbia. As a Web developer, are you - Interested in increasing your customer base with innovative services? - Constantly challenged to push the envelope in order to provide top-notch, Web based business applications? - Looking for a more efficient way of building database access over the Internet? - In need of providing better Web site statistical information? As an ISP, are you - Interested in increasing your customer base with innovative services? - Constantly challenged to push the envelope in order to provide top-notch Web hosting services? - Looking for a revenue generating way of providing database hosting services? - In need of providing better Web site statistical information? If so, participate in this action-packed 2-hour FREE seminar sponsored by EveryWare Development Inc. The focus of the presentation will be on 2 key areas of interest for today's Internet professional. 1. Building Database functionality over the Web 2. Tracking and Managing web site usage To find out more go to: http://betawest.everyware.com/sales/index.html Or read on... Date: Friday June 5, 1998 Time: From 9:30 AM to 11:30 AM - Web Developers; From 1:30 PM to 3:30 PM - ISP's Location: Simon Fraser University at Harbour Centre http://www.harbour.sfu.ca/ 515 West Hastings Street Vancouver, British Columbia V6B 5K3 Room 1700, Labatt Hall Contact Linda Hewitt lhewitt@sfu.ca 604/291.5085 Over $10,000 in door prizes! -refreshments -hands-on training -meet and learn from other professionals **Space is Limited** Get all the details and Register Now to receive a full Tango Developer license valued at $695 US for $95 US! http://betawest.everyware.com/sales/index.html For more information contact: Chris Moffett cmoffett@everyware.com 604/464.8704 www.everyware.com EveryWare Development Inc. If no longer want to receive messages from this list send "remove from list" in the body of your text and e-mail to: northwestsales@everyware.com From rem-conf Thu May 21 12:56:16 1998 From rem-conf-request@es.net Thu May 21 12:56:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycbPA-0004Va-00; Thu, 21 May 1998 12:53:32 -0700 Received: from gomez.cs.pitt.edu [136.142.79.193] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycbP8-0004VQ-00; Thu, 21 May 1998 12:53:30 -0700 Received: from zeus.cs.pitt.edu (zeus.cs.pitt.edu [136.142.79.56]) by gomez.cs.pitt.edu (8.8.7/8.8.7) with ESMTP id PAA01253; Thu, 21 May 1998 15:53:13 -0400 (EDT) From: Taieb Znati Received: (from znati@localhost) by zeus.cs.pitt.edu (8.8.3/8.8.3) id PAA15292; Thu, 21 May 1998 15:53:02 -0400 (EDT) Message-Id: <199805211953.PAA15292@zeus.cs.pitt.edu> Subject: IJPDSN: Special Issue To: ckobryn@shl.com, commsoft@cc.bellcore.com, bomsig@omg.org, adtf@omg.org, mof@omg.org, tc@omg.org, ptc@omg.org, dtc@omg.org, ab@omg.org, mof-rtf@omg.org, odp@dstc.edu.au, dbworld@cs.wisc.edu, enternet@BBN.COM, JavaCORBA@luke.org, ISWORLD@Danann.hea.ie, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, end2end-interest@isi.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, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@BBN.COM, rem-conf@es.net, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@IEEE.ORG, xtp-relay@cs.concordia.ca Date: Thu, 21 May 1998 15:53:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, The following is the Call for Papers for the IJPDSN Special Issue On "Network Architectures for End-to-end Quality-of-Service Support". Please forward this message to colleagues who might be interested. My apologies if you receive multiple copies of this message. Sincerely, Prof. T. Znati, Guest Editor CALL FOR PAPERS ---------------------------------------------------------------------------- INTERNATIONAL JOURNAL OF PARALLEL AND DISTRIBUTED SYSTEMS AND NETWORKS Special Issue On Network Architectures for End-to-end Quality-of-Service Support ----------------------------------------------------------------------------- A wide-range of real-time and multimedia applications, such as interactive multimedia teleconferencing, video-on-demand, and tele-medicine, rely on the next generation of Integrated Services and Telecommunication networks for data transport. Successfully deploying these networks requires new switching and transmission technologies and new network and transport protocols capable of supporting a wide range of Quality-of-Service requirements. Further, these technologies and protocols must operate and co-exist within a heterogeneous infrastructure, encompassing real-time and best-effort networks and wired and wireless environments. To address these issues very intensive research and standardization activities are being carried out. The research challenge is to develop these communication systems and protocols in an efficient and scalable manner. The objective of this special issue is the design, implementation and evaluation of a broad range of network architectures capable of supporting the full spectrum of distributed real-time and multimedia applications with both stringent and adaptive QoS guarantees. Papers should address current results and future directions of research and development in new services and frameworks for these next generation applications. Topics include, but are not limited to: ** Network protocol architectures and services for end-to-end QoS support ** New architectures for switching and routing at gigabit speeds ** Modeling, simulation and implementation of real-time network architectures ** Routing and congestion control protocols in integrated service networks ** End-to-end QoS support over heterogeneous networks ** Network and transport protocols for Integrated Services Networks ** Scheduling and queue management policies for multiple traffic classes ** Differentiated Services Architectures ** End-to-end QoS support over Mobile and Wireless Systems ** Open Control Architectures and Active Networks ** Real-time control in mobile and wireless networks Prospective authors should directly deposit their manuscripts (PostScript or PDF format only) by anonymous ftp at ftp.cs.pitt.edu:/pub/IJPDSN/incoming, or send five (5) hard copies to one of the Guest Editors listed below. The following deadlines will apply: Manuscript Submission Date September 30, 1998 Acceptance Notification Date November 15, 1998 Final Manuscript Due Date December 31, 1998 Anticipated Publication Date Second quarter 1999 Guest Editors Prof. Taieb Znati Prof. Robert Simon Computer Science Department Computer Science Department University of Pittsburgh George Mason University Pittsburgh, PA 15260 Fairfax, VA 22030 U.S.A. U.S.A. Phone: +1(412)624-8417 Phone: +1(703)993-1556 FAX: +1(412)624-8854 FAX: +1(703)993-1710 e-mail: znati@cs.pitt.edu e-mail: simon@cs.gmu.edu From rem-conf Fri May 22 06:38:23 1998 From rem-conf-request@es.net Fri May 22 06:38:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycrrR-0003o3-00; Fri, 22 May 1998 06:27:49 -0700 Received: from hobbes.risq.qc.ca [192.26.210.154] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ycrrQ-0003nt-00; Fri, 22 May 1998 06:27:48 -0700 Received: from maverick.risq.qc.ca (maverick.risq.qc.ca [192.26.210.11]) by hobbes.risq.qc.ca (8.8.8/8.8.7) with ESMTP id JAA27979 for ; Fri, 22 May 1998 09:27:46 -0400 (EDT) Date: Fri, 22 May 1998 09:27:46 -0400 (EDT) From: yboudrea@maverick.risq.qc.ca Message-Id: <199805221327.JAA27979@hobbes.risq.qc.ca> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: unknown X-Exmh-Isig-Folder: inbox Bcc: To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >From allegre@risq.qc.ca Thu May 21 19: 24:26 1998 Return-Path: Received: from mailboy.risq.qc.ca (mailboy.risq.qc.ca [192.26.210.3]) by hobbes.risq.qc.ca (8.8.8/8.8.7) with ESMTP id TAA20708; Thu, 21 May 1998 19:24:25 -0400 (EDT) Received: from platon (platon.crim.ca [132.218.1.18]) by mailboy.risq.qc.ca (8.8.8/8.8.7) with SMTP id TAA00293; Thu, 21 May 1998 19:24:25 -0400 (EDT) Message-ID: <00c101bd850f$d4db56f0$1201da84@platon.crim.ca> From: "=?iso-8859-1?Q?Christian_All=E8gre?=" To: rem-conf@es.net Subject: Annonce M-Bone Date: Thu, 21 May 1998 19:25:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Resent-To: rem-conf@es.net Resent-Date: Fri, 22 May 1998 09:27:46 -0400 Resent-From: Yves Boudreau Title : RISQ '98 : High Bandwidth InterNetworking in Quebec Description : RISQ '98 is the yearly technical Conference of the RISQ, Quebec's Leading Educational and Research Network. RISQ is the Quebec backbone of CA*Net-2 and of CANARIE's new Canadian Optical Network. Highlights include : conferences about performance on IP networks, Video server architecture for CA*Net II, the Canadian Policy regarding Internet Domain Names Registration, and a high level panel on competing access technologies and IP telephony (May 26, 1:30-3:00PM). Conferences are mostly in french. Date : Monday 25 May (PM) and Tuesday 26 May (AM and PM) URL : http://www.risq.qc.ca/risq98/ -- Christian Allegre, conseiller NTIC Programme RISQ '98 : <>, 25-26 mai a Montreal http://www.risq.qc.ca/risq98/ RISQ Inc. (514) 840-1235 ext. 5559 allegre@risq.qc.ca From rem-conf Fri May 22 06:46:46 1998 From rem-conf-request@es.net Fri May 22 06:46:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ycs82-000404-00; Fri, 22 May 1998 06:44:58 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0ycs80-0003zl-00; Fri, 22 May 1998 06:44:57 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 May 1998 14:44:34 +0100 To: Henning Schulzrinne cc: Jonathan Rosenberg , rem-conf@es.net, confctrl@ISI.EDU Subject: Re: SIP and RTP correlations In-reply-to: Your message of "Thu, 21 May 1998 11:43:27 EDT." <35644B9F.646A@cs.columbia.edu> Date: Fri, 22 May 1998 14:44:32 +0100 Message-ID: <1520.895844672@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >Jonathan Rosenberg wrote: ... >> 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP >> address. The ITU folks did a similar thing for H.332; they have >> registered an H.323-CADDR type used for solving problem (1). > >Only solution (4) seems generic enough, and we definitely want to avoid >making SSRCs visible outside RTP as much as we can. Given the bandwidth >limitation of the RTCP channel, allowing re-use of the same identifier >is helpful, since having > >H323-CADDR: foo@bar >SIP-CADDR: foo@bar >WhitePine-CADDR: foo@bar > >is very inefficient, in particular since it is likely that many of these >addresses are going to be of the user@host variety. We could use >something like > >CADDR: {sip,h323,whitepine}:foo@bar Could we use the CNAME? Put a sip: url in there? The media tools will have to be modified anyway, to send out SIP-CADDR. This also avoids having a proliferation of sdes packet types... Colin From rem-conf Fri May 22 08:00:34 1998 From rem-conf-request@es.net Fri May 22 08:00:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yctFr-0005gt-00; Fri, 22 May 1998 07:57:07 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yctFq-0005gj-00; Fri, 22 May 1998 07:57:06 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA05236; Fri, 22 May 1998 10:57:02 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA25860; Fri, 22 May 1998 10:56:57 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <35659239.AD8FA59@cs.columbia.edu> Date: Fri, 22 May 1998 10:56:57 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Colin Perkins CC: Jonathan Rosenberg , rem-conf@es.net, confctrl@ISI.EDU Subject: Re: SIP and RTP correlations References: <1520.895844672@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > --> Henning Schulzrinne writes: > >Jonathan Rosenberg wrote: > ... > >> 4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP > >> address. The ITU folks did a similar thing for H.332; they have > >> registered an H.323-CADDR type used for solving problem (1). > > > >Only solution (4) seems generic enough, and we definitely want to avoid > >making SSRCs visible outside RTP as much as we can. Given the bandwidth > >limitation of the RTCP channel, allowing re-use of the same identifier > >is helpful, since having > > > >H323-CADDR: foo@bar > >SIP-CADDR: foo@bar > >WhitePine-CADDR: foo@bar > > > >is very inefficient, in particular since it is likely that many of these > >addresses are going to be of the user@host variety. We could use > >something like > > > >CADDR: {sip,h323,whitepine}:foo@bar > > Could we use the CNAME? Put a sip: url in there? The media tools will have > to be modified anyway, to send out SIP-CADDR. This also avoids having a > proliferation of sdes packet types... I don't think CNAME is appropriate, since it identifies the actual host the data is coming from. In many cases, I want my SIP requests to go through various proxies (that do call filtering, firewall drilling, etc.). Also, we want to maintain backward-compatibility, and CNAME is the one crucial piece of RTP SDES information that applications rely on for grouping. Also, it is sufficient to send the SIP URL in one media stream, while CNAME is clearly needed everywhere. > > Colin -- Henning Schulzrinne schulzrinne@cs.columbia.edu Dept. of Comp. Sci. ph +1 212 939-7042 Columbia University fax +1 212 666-0140 New York, NY 10027 http://www.cs.columbia.edu/~hgs From rem-conf Sun May 24 01:10:39 1998 From rem-conf-request@es.net Sun May 24 01:10:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydVWX-00043s-00; Sun, 24 May 1998 00:48:53 -0700 Received: from birch.ee.vt.edu [128.173.88.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ydVWV-00043i-00; Sun, 24 May 1998 00:48:51 -0700 Received: from oak.ee.vt.edu (oak.ee.vt.edu [128.173.88.33]) by birch.ee.vt.edu (8.8.6/8.8.4) with ESMTP id DAA14582 for ; Sun, 24 May 1998 03:48:47 -0400 (EDT) Received: from localhost (sferat@localhost) by oak.ee.vt.edu (8.8.6/8.8.6) with SMTP id DAA06720 for ; Sun, 24 May 1998 03:48:47 -0400 (EDT) X-Authentication-Warning: oak.ee.vt.edu: sferat owned process doing -bs Date: Sun, 24 May 1998 03:48:46 -0400 (EDT) From: Ferat Sahin To: rem-conf@es.net Subject: remove Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove rem-conf@es.net -------------------------------------------------------------------------- Ferat Sahin Ph.D. Candidate, Virginia Polytechnic Institute & SU |\/\/\/| Electrical Engineering Department | | Control&Systems | | My favorite | (o)(o) cartoon Tel: (H) (540) 953 0743 C _) (W) (540) 231 5717 (MIL) 231 5613 | ,___| email: sferat@birch.ee.vt.edu | / homepage: http://www.ee.vt.edu/sferat /____\ / \ --------------------------------------------------------------------------- From rem-conf Sun May 24 07:17:52 1998 From rem-conf-request@es.net Sun May 24 07:17:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydbWN-0006Jn-00; Sun, 24 May 1998 07:13:07 -0700 Received: from mail.airmail.net [206.66.12.40] by mail1.es.net with smtp (Exim 1.81 #2) id 0ydbWM-0006Jd-00; Sun, 24 May 1998 07:13:06 -0700 Received: from ibm-770-laptop from [207.136.47.83] by mail.airmail.net (/\##/\ Smail3.1.30.16 #30.237) with smtp for sender: id ; Sun, 24 May 98 09:12:58 -0500 (CDT) Reply-To: From: "daveh" To: , Subject: remove Date: Sun, 24 May 1998 09:10:16 -0500 Message-ID: <000201bd871d$b1a7afc0$5d3488cf@ibm-770-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <35643FEA.A5FB8638@dnrc.bell-labs.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Remove daveh@airmail.net From rem-conf Sun May 24 07:35:32 1998 From rem-conf-request@es.net Sun May 24 07:35:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydbqm-0006xS-00; Sun, 24 May 1998 07:34:12 -0700 Received: from tac.inria.fr [138.96.24.102] (flyonnet) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ydbql-0006xI-00; Sun, 24 May 1998 07:34:11 -0700 Received: from localhost by tac.inria.fr (8.8.8/8.8.5) with ESMTP id QAA26777; Sun, 24 May 1998 16:34:09 +0200 (MET DST) Message-Id: <199805241434.QAA26777@tac.inria.fr> X-Mailer: exmh version 2.0.2 2/24/98 X-url: http://www.inria.fr/rodeo/personnel/Frank.Lyonnet/ X-face: *:~v#FFaCB"8E*p1e>EJK}hMuiF^~h6$zZ6QC,64W3hOE*5l2.QIO#*{PTdN4G.FtW]MsAl uS@0V13~FZ5G'ntJ;1;,c\MthD:ikaak8}0y `n\C=@kb/kT%[EYvo`Tr4&>Q=H0,O4vM- To: rem-conf@es.net Cc: Frank.Lyonnet@inria.fr, rodeo@inria.fr Subject: Rendez-Vous 1.0.3 with Layered DCT codec & Appli. level FEC ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 May 1998 16:34:08 +0200 From: Frank Lyonnet X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A quick word to announce the availability of Rendez-Vous 1.0.3 an Internet audio/video conferencing software developped in INRIA France. This release of Rendez-Vous should be of interest for people willing to experiment with multilayer video codec, application level FEC and bit error resilience. Extracted from the Rendez-Vous web page (http://www.inria.fr/rodeo/rv) : ------------------------------------------------------------------------ Rendez-Vous is an Internet videoconferencing tool developed at INRIA by Frank Lyonnet. It is in a way the successor to the IVS tool developed some time ago by Thierry Turletti, which was one of the first MBone tools available (however it is a completely new piece of code compared to IVS). The audio component of Rendez-Vous is an integration of the application kernel of the FreePhone 3.5 audio tool developped also at INRIA by Sacha Fosse-Parisis and Andres Vega Garcia (http://www.inria.fr/rodeo/fphone). Main features of Rendez-Vous : - RTP protocol support over multicast or unicast IP. - H261 video standard. - High quality PCMU, ADPCM, VADPCM (with HiFi support) and low bandwidth GSM and LPC audio coding. - Mpeg 1/2 file reading / transcoding - An integrated scheduler for multilayer video and audio flow management and processing (layer synchronisation and optimization of machine ressources to maximise the suggestive quality rendered to the user). - Experimental multilayer DCT based video codec. - Application level hierarchical FEC. - Bit error resilience with layered DCT codec. Who should care for Rendez-Vous ? Who should NOT care for Rendez-Vous : Rendez-Vous is not intended to be commercial product. We, the RODEO team at INRIA are a small research group, part of a French public institute. In no case we recommend Rendez-Vous for a buisness or even personnal use. We will not provide any support for such use of Rendez-Vous. Who should care for Rendez-Vous : Rendez-Vous is an experimental research tool. It has been developped in order to be an ideal testbed for some hot topics such as layered video and audio transport and coding, Forward Error Correction for video and audio on the Internet, wireless and satellite links access to the Internet. As a side effect of this primary goal, Rendez-Vous can also be used for personnal use by people with an adventurous mind. Supported systems : - Sun Sparc Solaris machines, internal audio hardware, SunVideo and VigraPix grabbers - x86 Linux machines, VoxWare audio by Sacha Fosse-Parisis, no video grabbing - x86 FreeBSD machines, VoxWare audio by Sacha Fosse-Parisis, no video grabbing - Windows 95 machines, DirectX 5.0 audio, VideoForWindows (QuickCam only) and Matrox Meteor grabbing. Windows NT 4 users have to wait for offical support for DirectX 5.0 in NT 4. Frank Lyonnet Frank.Lyonnet@inria.fr http://www.inria.fr/rodeo/personnel/Frank.Lyonnet/ From rem-conf Sun May 24 08:14:38 1998 From rem-conf-request@es.net Sun May 24 08:14:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydcSZ-0007jA-00; Sun, 24 May 1998 08:13:15 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ydcSY-0007j0-00; Sun, 24 May 1998 08:13:14 -0700 Received: from tuttifrutti.cdt.luth.se (root@tuttifrutti.cdt.luth.se [130.240.142.2]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id RAA13546 for ; Sun, 24 May 1998 17:13:10 +0200 (MET DST) Received: from tuttifrutti (hakan@localhost [127.0.0.1]) by tuttifrutti.cdt.luth.se (8.8.7/8.8.7) with ESMTP id RAA00956 for ; Sun, 24 May 1998 17:14:03 +0200 Message-Id: <199805241514.RAA00956@tuttifrutti.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 From: Hakan.Lennestal@cdt.luth.se Reply-to: Hakan.Lennestal@cdt.luth.se To: rem-conf@es.net Subject: Spam filter ? (Was: remove) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 May 1998 17:14:02 +0300 Sender: hakan@tuttifrutti.cdt.luth.se X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message writes: > Remove Is it possible to filter out this kind of spam from the list ? /H=E5kan --------------------------------------- e-mail: Hakan.Lennestal@lu.erisoft.se | or Hakan.Lennestal@cdt.luth.se | or hakan@tuttifrutti.cdt.luth.se | --------------------------------------- From rem-conf Sun May 24 09:38:55 1998 From rem-conf-request@es.net Sun May 24 09:38:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yddm1-0000tf-00; Sun, 24 May 1998 09:37:25 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yddm0-0000tV-00; Sun, 24 May 1998 09:37:24 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id JAA12373; Sun, 24 May 1998 09:37:10 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199805241637.JAA12373@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Frank Lyonnet cc: rem-conf@es.net, Frank.Lyonnet@inria.fr, rodeo@inria.fr Subject: Re: Rendez-Vous 1.0.3 with Layered DCT codec & Appli. level FEC ... In-reply-to: Your message of "Sun, 24 May 1998 16:34:08 +0200." <199805241434.QAA26777@tac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 May 1998 09:37:10 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thank you for supporting FreeBSD! Any reason why there is no FreeBSD video capture support? If you like you can use vic as model for interfacing to our matrox meteor or bt848 driver in fact the vic's freebsd video capture is the same for the meteor and bt848 cards. Tnks, Amancio From rem-conf Sun May 24 17:36:20 1998 From rem-conf-request@es.net Sun May 24 17:36:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydlAE-0003V6-00; Sun, 24 May 1998 17:30:54 -0700 Received: from mail.datacraft-asia.com [152.102.112.182] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ydlAC-0003Uw-00; Sun, 24 May 1998 17:30:53 -0700 Received: from dsi.datacraft-asia.com ([152.102.112.188]) by mail.datacraft-asia.com (Post.Office MTA v3.0 release 0122 ID# 0-34116U100L2S100) with SMTP id AAA50 for ; Mon, 25 May 1998 08:36:06 +0800 Received: by dsi.datacraft-asia.com with VINES-ISMTP; Mon, 25 May 98 8:30:45 +0800 Date: Mon, 25 May 98 8:30:33 KUL Message-ID: X-Priority: 3 (Normal) To: From: "Gary Tam" Reply-To: Subject: Remove X-Incognito-SN: 971 X-Incognito-Version: 4.10.71 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Sun May 24 17:58:11 1998 From rem-conf-request@es.net Sun May 24 17:58:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ydlYI-0004Ew-00; Sun, 24 May 1998 17:55:46 -0700 Received: from iris.ctd.comsat.com [134.133.40.12] (exim) by mail1.es.net with smtp (Exim 1.81 #2) id 0ydlYH-0004Em-00; Sun, 24 May 1998 17:55:45 -0700 Received: from simao by iris.ctd.comsat.com with local (Exim 1.82 #1) id 0ydlYF-0003ii-00; Sun, 24 May 1998 20:55:44 -0400 To: rem-conf@es.net From: "Simao F. Campos-Neto" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Loop: "Simao F. Campos-Neto" Subject: Illegal list specification Message-Id: Sender: Date: Sun, 24 May 1998 20:55:44 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, rem-conf. Your `UNSUBSCRIBE UGST' request has been received by "Simao F. Campos-Neto" ; however no lists are named `UGST'. Available lists are: UGST - UGST e-mail discussion group UGST-HW - UGST hardware specific e-mail discussion group UGST-MANUAL - UGST STL Manual editorial group Please try again. __________________________________________________________________________ From rem-conf Mon May 25 11:08:41 1998 From rem-conf-request@es.net Mon May 25 11:08:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ye1XU-0004Zl-00; Mon, 25 May 1998 11:00:00 -0700 Received: from giascl01.vsnl.net.in [202.54.9.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0ye1XL-0004ZC-00; Mon, 25 May 1998 10:59:53 -0700 Received: from [202.54.53.124] by giascl01.vsnl.net.in; (5.65v3.2/1.1.8.2/27May97-1036AM) id AA05701; Mon, 25 May 1998 23:20:29 GMT Reply-To: From: "d.saha@computer.org" To: , , , , , , , , , , , , , , , , , Cc: , , , , , , , , , , , , , , , , , , , Subject: Last CFP for IEEE CNIW'98 Date: Mon, 25 May 1998 20:34:41 +0530 Message-Id: <01bd87ee$7188d140$LocalHost@vsnl.vsnl.net.in> Mime-Version: 1.0 X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01BD8834.AB244600" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0002_01BD8834.AB244600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear recipient: This is the last CFP for IEEE CNIW'98 to be held at Ahmedabad, India during 9-12 Dec, 1998. It is my great pleasure to introduce you to the IEEE 1998 Conference on Networking India & the World (CNIW98) to be held at Ahmedabad during December 9-12, 1998 as a part of the Annual Convention & Exhibition (ACE98) programme of the IEEE India Council. It is being organized and hosted by the IEEE Gujrat Section in cooperation with the IEEE Computer Society Chapters of the India Council. As you are aware of, IEEE is the worlds largest technical professional body with the current motto of Networking the World. ACE98 is one of the premier events in our profession providing an excellent forum for learning and sharing ideas and experiences with other practitioners and organizations. This year the heart of ACE is going to be the CNIW98 - a leading conference in identifying and focussing modern trends in the development of new initiatives in networking. Accordingly, the conference theme has been decided to highlight the importance of networks in todays ever-changing world. The conceived Technical Program track also embodies that theme through its multicultural mix. The evolution of networking techniques resembles a revolution. The analog to digital transition is virtually complete. The dream of networking throughout the world is moving quickly towards reality, as advanced technologies are being developed. Network access is trending from wired to wireless. Mobility and multimedia are being demanded by end-users. In near future, networks will be capable of instantly transporting and processing information between any locations, be they homes, offices or businesses. Various new technologies, new system solutions and new business opportunities have created a completely new horizon of networking that constitutes the nervous system of todays economy and more generally of tomorrows society. In this context, INTERNET can be cited as the most dynamic sector of activity and growth worldwide. Being a part of this global information economy, India is all poised to take the centre stage in the coming millennium, fuelled by an expanding economy and increasing affluence of its population. Service providers are merging and de-merging and deregulating. Liberalization and globalization of services and networks are now driving the networking market, with the backdrop of a multi-vendor and multi- service provider environment. Virtually every network is composed of equipment from multiple vendors. Vendors are forging alliances amongst themselves. Still, is it possible to manage the global information superhighway? What are the real issues? Are standards the answer? Will your systems and technologies enable it? What are the practical and theoretical limits? How is the INTERNET being driven by business and social forces? Millions of such problems, in all facets of networking, are growing faster than they are being solved. More importantly, these challenges make it even harder than ever to strive for cooperation among customers, service providers and vendors. To explore these challenges and many more, and to debate on their possible solutions, we cordially invite you to use the platform of CNIW98. To this end, CNIW98 features an intellectually stimulating technical program with 8 technical sessions having a broad coverage of topics on network technologies, applications, operations, management, policies and future developments. It also offers timely and highly relevant tutorials by subject matter experts on recently developed techniques. Moreover, four invited talks by eminent speakers provide a vision into the future and discuss networking strategies from business, service and technology perspective. In addition, manufacturers/service providers/consortia will be presenting technical demonstrations, featuring state-of-art ideas in networking and illustrating the latest advances of interest to industry professionals responsible for Networking India and the World. Given the rapid pace at which developments occur within the networking community, a major national event like this is vital in keeping professionals aware of the state-of-the-art technology. It provides a valuable forum for exchanging knowledge and experience between academicians, research scientists and technical managers. It also serves as a showcase of the most advanced products and services, offering industry leaders a marvelous opportunity to display their revolutionary technologies, as well as to make contacts which will prove beneficial in the years to come. Indeed, it is a grand occasion to distinguish yourself in an elite gathering of leaders and professional from all corners of the networking world for four days at Ahmedabad. Lastly, we are sure you will find this Conference to be not only an excellent forum for innovation and technical discussion, but also a very natural environment for extending friendship and fellowship here at Ahmedabad. So please do join us for this very special event and be a part of Networking India & the World. See you in Ahmedabad. Dr. Debashis Saha. (Program Committee Vice Chairman) Dept. of Computer Science & Engg. Jadavpur University Calcutta 700 032 Tel. : +91 (33) 413 1766 (O) +91 (33) 462 2833 (R) Fax : +91 (33) 473 1138 email : d.saha@computer.org, debashis_saha@hotmail.com ------=_NextPart_000_0002_01BD8834.AB244600 Content-Type: text/plain; name="tccc.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tccc.txt" From: d.saha@computer.org To : tccc@ieee.org >=20 > ANNUAL CONFERENCE & EXHIBITION > NETWORKING INDIA & THE WORLD > =20 >=20 > December 9-12, 1998 IRS Campus, ONGC Chandkheda, Ahmedabad >=20 > =20 >=20 > Organised by >=20 > INDIA COUNCIL, GUJARAT SECTION, Computer Society Chapter, India=20 >=20 > Council Computer Society Chapter, Gujarat Section >=20 > =20 >=20 > in co-operation with >=20 > INSTITUTION OF ENGINEERS (INDIA), GUJARAT STATE CENTRE >=20 > GUJARAT ASSOCIATION OF ELECTRONICS & SOFTWARE INDUSTRIES >=20 > =20 >=20 > =20 >=20 > For details please see our Web-Site at "ieee-gujarat.org" >=20 > =20 >=20 > The Conference will provide a vibrant forum to debate the entire=20 >=20 > gamut of continually exploding NETWORKING and INTERNET=20 >=20 > environment - and their impact, especially in relation to India.=20 >=20 > The exchange of information will be through presentation and=20 >=20 > discussion of papers, tutorials, the Best Web Page Awards,=20 >=20 > Manufacturers' Presentations and Exhibition. =20 >=20 > =20 >=20 > =20 >=20 > The Conference elicits papers on the following and related=20 >=20 > topics : >=20 > =20 >=20 > 1. Impact of Networking 4. Applications = >=20 > * Business Impact of the web * Virtual Reality = =20 >=20 > and Intranets * Science & Engineering =20 >=20 > * Management Issues * Internet Commerce = =20 >=20 > * Infrastructure * Electronic Publishing = =20 >=20 > * Indian Economics * Online Resources =20 >=20 > * Information Services =20 >=20 > * Education =20 >=20 > =20 >=20 > 2. Network Technologies 5. Policies and Guidelines for = =20 >=20 > * Networking Products Cyberlaws = =20 >=20 > * LAN/WAN Technology * Ethics and Legalities = =20 >=20 > * Server Technologies * Intellectual Property = Rights(IPRs >=20 > * Network Issues * Freedom vs abuse of Internet = =20 >=20 > = =20 >=20 > 3. Software Tools 6. Internet Issues = =20 >=20 > * Multimedia * Security = =20 >=20 > * Internet Tools * Authenticity of information = =20 >=20 > * Web Browser and Search Engines * Forgery, Frauds = =20 >=20 > * Audio/Video on Internet * Privacy = =20 >=20 > =20 >=20 > 7. Future Developments = =20 >=20 > =20 >=20 > Besides the papers on the main theme, papers on any field of =20 >=20 > interest covered by any IEEE Society/Council are also welcome. = =20 >=20 > =20 >=20 > Associated with the Conference will be a prestigious All =20 >=20 > India Best Web Page Award. Companies registered in India or=20 >=20 > individuals engaged in web design can compete for the Award. For=20 >=20 > competing for the award, please send the URL along with a=20 >=20 > Certificate from the client. A disk containing the Web Page may =20 >=20 > also be provided. >=20 > =20 >=20 > CONFERENCE PROGRAM : >=20 > =20 >=20 > 9 Dec, 1998 Tutorial on INERNET >=20 > 10 Dec, 1998 Tutorials on Software Technologies for Networked=20 >=20 > & Internet-connected systems. >=20 > 11-12 Dec,1998 The Conference >=20 > 12 Dec, 1998 Presentation of the All India Web Page Award >=20 > =20 >=20 > =20 >=20 > Participate in the Manufacturer's Presentation : >=20 > =20 >=20 > The ACE-98 December Seminar will be a gathering of leading =20 >=20 > professionals and decision makers. These are people who will be=20 >=20 > actual users and buyers of your products and will decide the =20 >=20 > suitability of your products for their applications in their=20 >=20 > respective organisation. >=20 > =20 >=20 > Keeping this in mind, Special Presentation slots will be=20 >=20 > allotted to the manufacturers of Networking Products and Services=20 >=20 > during the conference. >=20 > =20 >=20 > So if your industry has anything to offer for use by these=20 >=20 > computer professionals, don't miss this opportunity. Book your=20 >=20 > time slots now. Please note that these are limited and will be=20 >=20 > booked on first-come first-served basis. >=20 > =20 >=20 > The rate is Rs. 15,000 (US$ 400) for a 30 minutes slot. >=20 > =20 >=20 > DEADLINES >=20 > 30 May, 1998 : =20 >=20 > Receipt of brief abstract, in not more than 100 words giving=20 >=20 > title, author(s) name(s) & Affiliation (s)and FULL address,=20 >=20 > clearly indicating a) subject category as above, b) author(s)'=20 >=20 > contribution and c) conclusion & further work. >=20 > =20 >=20 > 15 July 1998 : =20 >=20 > Receipt of full paper, additional to the abstract as above [TWO=20 >=20 > copies, not more than 10 pages in A4 size, including figures,=20 >=20 > etc., typed in double spacing, using the typical format of an=20 >=20 > IEEE Transaction paper]. >=20 > =20 >=20 > 1 September,1998 :=20 >=20 > Notification of acceptance of paper to the author(s). >=20 > =20 >=20 > 15 October, 1998 : =20 >=20 > Receipt of final, " Camera-ready" paper from the author(s) as per=20 >=20 > guidelines to be provided by the Program Committee. >=20 > =20 >=20 > REGISTRATION FEES : = =20 >=20 > Conference + Two Tutorials=20 >=20 > Before Oct 30 After Oct 30=20 >=20 > For delegates from India =20 >=20 > =20 >=20 > IEEE Member Rs. 2500 Rs. 3000 =20 >=20 > IEEE Student Member Rs. 850 Rs. 1000 =20 >=20 > Non-member Rs. 3250 Rs. 3900 =20 >=20 > Student Rs. 1250 Rs. 1400 =20 >=20 > =20 >=20 > For delegates from outside India =20 >=20 > IEEE Member US $100 US $125 =20 >=20 > IEEE Student Member US $ 50 US $ 70 =20 >=20 > Non-member US $150 US $180 =20 >=20 > Student US $ 70 US $ 90 =20 >=20 > =20 >=20 > Note : A Twin Conference on the Application of ' Computers,=20 >=20 > Electronics & Electrical Engg in Petroleum and Chemical Industry =20 >=20 > (CCEEPCI) is being organised from Dec 10-12,=20 >=20 > 1998 Ahmedabad by IEEE Gujarat Section. A copy of the Proceedings=20 >=20 > & Tutorials material of the twin Conference will be available to=20 >=20 > the delegates at Rs. 500 (US $50) only, provided the payment =20 >=20 > ois made while registering as a delegate. =20 >=20 > =20 >=20 > =20 >=20 > REGISTER TODAY =20 >=20 > =20 >=20 > If you register NOW as a delegate you receive the =20 >=20 > advantages of a LOWER REGISTRATION FEE =20 >=20 > =20 >=20 > For Registration, please send your name, your office,=20 >=20 > residence and e- mail addresses, your office & =20 >=20 > residence telephone nos. and fax no., along with an =20 >=20 > a/c payee demand draft, for the required amount =20 >=20 > payable at Ahmedabad in the name of IEEE GUJARAT SECTION = =20 >=20 > =20 >=20 > Registration Form >=20 > =20 >=20 > Name : __________________________________________________________ >=20 > Organisation : __________________________________________________=20 >=20 > Address : _______________________________________________________ >=20 > _________________________________________________________________=20 >=20 > _________________________________________________________________=20 >=20 > Postal Code : ___________________________________________________=20 >=20 > Phone : ________________________(O)_______________________(Home)=20 >=20 > Fax : ___________________E-Mail__________________________________ >=20 > IEEE Member No. : _______________________________________________=20 >=20 > Payment for Rs./US$ _____________________________________________=20 >=20 > By Cheque No. : _________________________________________________ >=20 > By Draft No. : _________________________________________________ >=20 > =20 >=20 > =20 >=20 > Signature of the Authorised persons >=20 > =20 >=20 > The Cheque/Draft should be made a/c payee and payable to IEEE=20 >=20 > GUJARAT SECTION at Ahmedabad, INDIA. >=20 > =20 >=20 > Address for registration >=20 > Ms. Flavia Lobo >=20 > Deptt. of Computer Science >=20 > Gujarat University,=20 >=20 > Rollwala Computer Centre >=20 > Ahmedabad - 380 009, INDIA >=20 > Phone : +91 (79) 644 0164 >=20 > > =20 >=20 > Address for communication of papers on the main theme: >=20 > Mr. Pramod Kumar =20 >=20 > Chairman, Program Committee =20 >=20 > Director, INFLIBNET =20 >=20 > Gujarat University Campus, =20 >=20 > Ahmedabad - 380 009, INDIA =20 >=20 > Tel : +91 (79) 64 2571 / 656 9695 (O)=20 >=20 > FAX : +91 (79) 656 0990=20 >=20 > e-mail : pramod@infahd.ernet.in >=20 > =20 >=20 > Papers from authors in North America may be sent to >=20 > Dr. Nitin J. Shah >=20 > Vice President, Wireless Data Networking >=20 > Lucent Technologies,=20 >=20 > Tel1 :-973-386-3939 >=20 > Fax :1-973-386-2651 >=20 > email : njshah@lucent.com >=20 > =20 >=20 > Papers from Authors in Europe may be sent to >=20 > Mr. Domenico Talia >=20 > ISI-CNR, c/o DEIS >=20 > Universita della Calabria >=20 > 87036 Rende, CS , ITALY >=20 > Tel . : +34 - 984 - 839072=20 >=20 > Fax : +34 - 984 - 839054 >=20 > e-mail : talia@si.deis.unical.it / taliad@acm.org=20 >=20 > d.talia@computer.org >=20 > =20 >=20 > Address for communication of proposals for Manufacturers' = Presentations : >=20 > Mr. A. R. Dasgupta >=20 > Group Director, >=20 > Image Processing and Data Products >=20 > Space Applications Centre - ISRO, >=20 > Ahmedabad - 380 053, INDIA >=20 > Tel. : +91 (79) 674 2381 (O) >=20 > Fax : +91 (79) 656 5449=20 >=20 > email : arup@sac.ernet.in, pdpg@ad1.vsnl.net.in,=20 >=20 > arup52@hotmail.com >=20 > =20 >=20 > Address for communication of proposals for tutorials. : =20 >=20 > Dr. S. N. Pradhan >=20 > Physical Reserach Laboratory >=20 > Navrangpura >=20 > Ahmedabad - 380 009 >=20 > Tel. : +91 (79) 46 2129 E 4154 (O) >=20 > FAX : +91 (79) 656 0502 >=20 > e-mail : pradhan@prl.ernet.in >=20 > =20 >=20 > Coordinator : Session & Award Support >=20 > Dr. Debashis Saha >=20 > Dept. of Computer Science & Engg. >=20 > Jadavpur University >=20 > Calcutta 700 032=20 >=20 > e-mail : d.saha@computer.org >=20 > Tel. : +91 (33) 413-1766/473-1138 (O) > +91 (33) 462-2833 (R)=20 >=20 > FAX : +91 (33) 473 1138 =20 >=20 > =20 >=20 > Address for communication of entries for the AIB Web Page Award =20 >=20 > All India Best Web Page =20 >=20 > Mr. Hetal Trivedi =20 >=20 > Intellicon Pvt. Ltd. =20 >=20 > Flat # 1 D, Plot # 127, =20 >=20 > Sector 19 =20 >=20 > Gandhinagar - 382019 =20 >=20 > Tel :+91 (2712) 22993/4/5(O) =20 >=20 > FAX :+91 (2712) 23373 =20 >=20 > e-mail questel@ad1.vsnl.net.in =20 >=20 > =20 >=20 > Conference Web-Site >=20 > Ruzan Khambatta >=20 > Wizz O Tech >=20 > 8th Floor, White House >=20 > Pnachwati >=20 > Ahmedabad - 380 006 >=20 > Tel : + 91 (79) 656 0773 (O) >=20 > Fax : +91 (79) 656 2574 >=20 > e-mail : info@wizzotech.com >=20 > =20 >=20 > Invited Talks >=20 > Mr. Pankaj Chaudhary >=20 > India Internet Pvt. Ltd. >=20 > 601, Supath, Vijay Char Rasta >=20 > Navrangpura >=20 > Ahmedabad - 380 009 >=20 > Tel. : +91 (79) 656 5113,40 2475(O) >=20 > e-mail : ankit@ad1.vsnl.net.in, =20 >=20 > iciahd@allindia.com=20 >=20 > =20 >=20 > Address for communication of papers in fields other than the main = theme :=20 >=20 > Dr. B.P.Singh Dr. K. Uday Kumar =20 >=20 > EE Deptt. High Voltage Engg. Deptt. = =20 >=20 > I.I.T. Anna University, Guindy=20 >=20 > New Delhi - 110 016 Chennai - 600 025 =20 >=20 > INDIA INDIA =20 >=20 > Tel. : +91 (11) 66 6979 E 2209 (O) Tel.: +91 (44) 235 1723 E 3223 = (O) > +91 (11) 686 8245 (R) =20 >=20 > FAX : +91 (11) 686 2037 +91 (44) 40 4038 (R) = =20 >=20 > e-mail : bps@ee.iitd.ernet.in FAX : +91 (44) 235 0397 = =20 >=20 > e-mail : = annastud@giasmd01.vsnl.net.in=20 >=20 > * Pager : 9632-720113 = =20 >=20 > Other members of the Program Committee >=20 > Prof. Pradip K. Srimani >=20 > Colorado State University >=20 > =20 >=20 > Prof. Narendra Ahuja >=20 > University of Illinois >=20 > =20 >=20 > Prof. T. P. Rama Rao >=20 > IIMA >=20 > =20 >=20 > Mr. S. A. Dula >=20 > INDEXTb >=20 > =20 >=20 > Dr. R. Ramani >=20 > SAC >=20 > =20 >=20 > Mr. Narayan Satyan >=20 > Onward Novell India Ltd >=20 > =20 >=20 > Publication >=20 > Dr. Dilip Ahalpara >=20 > IPR >=20 > =20 >=20 > Panel Discussion >=20 > Mr. A. K. Goyal >=20 > Commissionerate of Industries >=20 > =20 >=20 > =20 >=20 > Network Services >=20 > Mr. Rajnish Mahajan >=20 > NIC >=20 > =20 >=20 > Souvenir >=20 > Dr. B. R. Sitaram >=20 > VASCSC >=20 > =20 >=20 > Design of Punlications >=20 > Mr. Samad Shaikh >=20 > Unmil Computer Service >=20 > =20 >=20 > West Asian Delegates >=20 > Mr.Sanjeev Chakraborty >=20 > Masibus P. I. Pvt. Ltd. >=20 > * >=20 > Secretary=20 >=20 > Mr. S. L. Salgar >=20 > INFLIBNET >=20 > =20 >=20 > STEERING COMMITTEE >=20 > Chairman, IEEE India Council =20 >=20 > Maj. Gen. (Dr.) R. K. Bagga, =20 >=20 > AVSM(Retd) =20 >=20 > B-172, Sainikpuri =20 >=20 > Secunderabad - 500 094 =20 >=20 > Tel. : +91 (40) 711 4465 (R) =20 >=20 > Fax : +91 (40) 82 2574 =20 >=20 > e-mail : bagga@ieeeh.ernet.in >=20 > =20 >=20 > Conference Chairman : =20 >=20 > Dr. A. K. Aggarwal =20 >=20 > Professor of Computer Science >=20 > Gujarat University, =20 >=20 > Rollwala Computer Centre Building >=20 > Navrangpura, Ahmedabad-380 009,INDIA >=20 > Tel : +91 (79) 644 0164 (O), +91 (79) 40 0144 (R) >=20 > e-mail : aka@ad1.vsnl.net.in >=20 > =20 >=20 > Conference Vice-Chairman >=20 > Mr. Dhiren L. Patel >=20 > President, AMTECH Electronics P.Ltd. >=20 > E-6, G.I.D.C., Electronics Zone, >=20 > Gandhinagar - 38 044, INDIA >=20 > Tel. : +91 (2712) 2 5324 /2 7294 (O) >=20 > Fax : +91 (2712) 2 4611 >=20 > e-mail : amtech@ad1.vsnl.net.in >=20 > =20 >=20 > Chairman Conference Coordination Committee =20 >=20 > Mr. A. D. Pathak =20 >=20 > 21, New Alkapuri Society, Gulbai Tekra, =20 >=20 > Ahmedabad - 380 015, INDIA =20 >=20 > Tel . : +91 (79) 40 3774 (O),+91 (79) 656 3378 (R) =20 >=20 > Fax . : +91 (79) 656 5185 =20 >=20 > =20 >=20 > Conference Secretary =20 >=20 > Dr.R.G. Gupta >=20 > Director, Deptt of Electronics >=20 > Electronics Niketan, 6m, CGO Complex, =20 >=20 > Lodhi Road, New Delhi - 100 003=20 >=20 > Tel. : +91 (11) 436 3095 (O), +91 (11) 625 5675 (R) >=20 > FAX : +91 (11) 436 3079 >=20 > e-mail : guptarg@xm.doe.ernet.in >=20 > =20 >=20 > Secretary to the Steering Committee >=20 > Mr. Vijay L. Somani >=20 > Director, Somani Strips Ltd, >=20 > Chandramauleshwar Farm, >=20 > Opp. Ashok Vatika, Ambli Bopal Road, >=20 > Ahmedabhad - 380 058 >=20 > Tel : +91 (79) 6743434/6740465 (O) >=20 > Fax : +91 (79) 6640245 >=20 > e-mail : somani@ad1.vsnl.net.in ------=_NextPart_000_0002_01BD8834.AB244600-- From rem-conf Tue May 26 05:39:50 1998 From rem-conf-request@es.net Tue May 26 05:39:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yeItN-0001R0-00; Tue, 26 May 1998 05:31:45 -0700 Received: from inetgw.fs.lmco.com [204.177.125.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yeItM-0001Qn-00; Tue, 26 May 1998 05:31:44 -0700 Received: (from mail@localhost) by inetgw.fs.lmco.com (AIX4.2/UCB 8.7/8.7) id IAA665006 for ; Tue, 26 May 1998 08:31:35 -0400 (EDT) Received: from t2.owg.fs.lmco.com(158.187.56.68) by inetgw.fs.lmco.com via smap (V2.0) id xma784862; Tue, 26 May 98 08:26:48 -0400 Received: by t2.owg.fs.lmco.com (AIX 4.1/UCB 5.64/4.03) id AA16052; Tue, 26 May 1998 08:26:47 -0400 From: "Dan Driscoll x3414" Message-Id: <980526082645.ZM17330@t2.owg.fs.lmco.com> Date: Tue, 26 May 1998 08:26:44 -0400 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove daniel.driscoll@lmco.com From rem-conf Tue May 26 06:36:36 1998 From rem-conf-request@es.net Tue May 26 06:36:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yeJqV-0002ds-00; Tue, 26 May 1998 06:32:51 -0700 Received: from gdv050.vptt.ch [193.5.238.17] by mail1.es.net with smtp (Exim 1.81 #2) id 0yeJqT-0002d4-00; Tue, 26 May 1998 06:32:49 -0700 Received: by gdv050.vptt.ch (SMI-8.6/VPTT.1.05.05.97) id PAA13117; Tue, 26 May 1998 15:31:39 +0200 Received: from gdv015.vptt.ch(193.5.224.27) by gdv050.vptt.ch via smap (V2.1) id xma013115; Tue, 26 May 98 15:31:19 +0200 Received: from gdvpoz.vptt.ch by vptt.ch (4.1/PTT-1.24) id AA18572; Tue, 26 May 98 15:31:19 +0200 Message-Id: <3.0.32.19980526163120.007d1700@gdv015.vptt.ch> X-Sender: cabano@gdv015.vptt.ch X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 26 May 1998 16:31:20 +0100 To: rem-conf@es.net From: claudio cabano Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********************************************************************** Claudio Cabano Phone +41 31 342-59-26 Swisscom Fax +41 31 342-99-03 Corporate Technology e-mail cabano@vptt.ch Zentweg 27 claudio.cabano@swisscom.com CH-3000 Bern 29 http://figeac.vptt.ch/~cabano CUSeeMe:manor.vptt.ch *********************************************************************** From rem-conf Tue May 26 07:30:57 1998 From rem-conf-request@es.net Tue May 26 07:30:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yeKgK-0003pT-00; Tue, 26 May 1998 07:26:24 -0700 Received: from smtp3.ny.us.ibm.com [198.133.22.42] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yeKgJ-0003nw-00; Tue, 26 May 1998 07:26:24 -0700 Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id KAA37226 for ; Tue, 26 May 1998 10:15:45 -0400 Received: from US.IBM.COM (d01lms03.pok.ibm.com [9.117.30.8]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id KAA47304 for ; Tue, 26 May 1998 10:22:23 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU035 id 5010300018317527; Tue, 26 May 1998 10:21:22 -0400 From: Ferdinand Hendriks To: Subject: remove Message-ID: <5010300018317527000002L072*@MHS> Date: Tue, 26 May 1998 10:21:22 -0400 MIME-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list * From rem-conf Tue May 26 10:45:33 1998 From rem-conf-request@es.net Tue May 26 10:45:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yeNeZ-0006rP-00; Tue, 26 May 1998 10:36:47 -0700 Received: from penguin-ext.wise.edt.ericsson.se (penguin.wise.edt.ericsson.se) [194.237.142.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yeNeY-0006rF-00; Tue, 26 May 1998 10:36:46 -0700 Received: from kkb3 (kkb3.kk.etx.ericsson.se [130.100.97.23]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/penguin-1.12) with SMTP id TAA03696 for ; Tue, 26 May 1998 19:36:43 +0200 (MET DST) Received: from kk661.kk.etx.ericsson.se by kkb3 (SMI-8.6/LME-2.2.6) id TAA00794; Tue, 26 May 1998 19:36:39 +0200 From: teima@kk.etx.ericsson.se (Valter Mazzaro) Received: by kk661.kk.etx.ericsson.se (SMI-8.6/client-1.6) id TAA21929; Tue, 26 May 1998 19:36:41 +0200 Date: Tue, 26 May 1998 19:36:41 +0200 Message-Id: <199805261736.TAA21929@kk661.kk.etx.ericsson.se> To: rem-conf@es.net Subject: Question about IP/UDP/RTP headers compression X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I'm investigating the Casner-Van Jacobson draft in order to produce an implementation of it. Still some doubts remain about it... I apologize whether this subject has been already faced on the mailing list (it should be indeed), but I'm still quite new with it :( In the draft an important part of the compression scheme it's based on the assumption that the link-level protocol provides for a packet length indication. I've checked 'PPP' and 'PPP in HDLC-like framing' RFCs and I haven't yet figured out where (or how) the packet length indication comes from (or is deduced). Any hint? Thanks in advance Valter ================================================================ | Valter Mazzaro | E-mail: | | --- --- SW Engineer | teima@kk.etx.ericsson.se | | \|/ ERICSSON ITALIA R&D | mazzaro@tei.ericsson.se | | SW- O --L c/o SwitchLab | | | /|\ KK/ETX/DN/SL 2204:083 | Phone : +46 8 7191607 | | --- --- Dialoggatan 1, 12625 | Ecn : 850 91607 | | Stockholm (Sweden) | Fax : +46 8 7196677 | ================================================================ From rem-conf Tue May 26 14:19:42 1998 From rem-conf-request@es.net Tue May 26 14:19:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yeR0J-0002hK-00; Tue, 26 May 1998 14:11:27 -0700 Received: from hnc.hnc.com [206.79.10.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yeR0I-0002gh-00; Tue, 26 May 1998 14:11:26 -0700 Received: (from adm@localhost) by hnc.hnc.com (8.8.8/8.8.8) id OAA02348; Tue, 26 May 1998 14:08:29 -0700 (PDT) Received: from hnc2.hnc.com(206.79.10.10) by hnc.hnc.com via smap (V2.1) id xma002346; Tue, 26 May 98 14:08:24 -0700 Received: from pchnc.hnc.com (pchnc [191.9.204.105]) by spike.hnc.com (8.8.8/8.8.8) with ESMTP id OAA19177; Tue, 26 May 1998 14:08:47 -0700 (PDT) Received: by pchnc.hnc.com with Internet Mail Service (5.0.1460.8) id ; Tue, 26 May 1998 14:10:08 -0700 Message-ID: From: "Lovett, Dean" To: scwpf@sdsc.edu, talks@ucsd.edu, talks-ece@ece.ucsd.edu, talks-cse@cs.ucsd.edu, e-club@ucsd.edu, web-watchers--KClaffy , rem-conf@es.net, webteam@qualcomm.com, webheads@sio.ucsd.edu, java-ucsd@mib.org, flesner@nosc.mil, GregJohnson Subject: Wednesday night - Web Programmers Forum - Live MBone Broadcast Date: Tue, 26 May 1998 14:10:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Wednesday, May 27, 1998, 7pm San Diego Supercomputer Center (SDSC) Auditorium We have scheduled two very interesting speakers this month: Jim Holscher Symantec Corporation Symantec will demonstrate their most current Java Tool, Visual Cafe Database Development Edition 2.5. Come see why Visual Cafe is the hottest Java tool and enter your name in a raffle to win a free evaluation copy of Visual Cafe! Lane Sharman GoodTimes "Time and Business Management. Anywhere, Anytime." Lane Sharman will present GoodTimes, a new Java based application for time and business management. GoodTimes contains a new and intuitive interface. It is a multi-tiered application using Oracle or a JDBC compliant database on the backend. For this presentation, Lane will discuss some of the engineering challenges and approaches to building a client-server application that runs exclusively over the Internet. GoodTimes provides a managed set of essential business and developmental functions to any Java capable workstation. The delivery and continuous maintenance of the software is transparent. Application Distribution and Management is a core ingredient allowing customers to enjoy zero-administration benefits on the desktop. With time permitting, Lane will also touch on some new technical developments including mutable algorithms in Java. For directions and parking information, see the Southern California Web Programmers Forum home page at http://www.sdsc.edu/scwpf From rem-conf Wed May 27 05:16:04 1998 From rem-conf-request@es.net Wed May 27 05:16:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yef0J-00032T-00; Wed, 27 May 1998 05:08:23 -0700 Received: from ietf.org [132.151.1.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yef0I-000324-00; Wed, 27 May 1998 05:08:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA29274; Wed, 27 May 1998 08:06:47 -0400 (EDT) Message-Id: <199805271206.IAA29274@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Document Action: Options for Repair of Streaming Media to Informational Date: Wed, 27 May 1998 08:06:47 -0400 Sender: scoya@CNRI.Reston.VA.US X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'Options for Repair of Streaming Media' as a Informational RFC. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. From rem-conf Thu May 28 00:33:34 1998 From rem-conf-request@es.net Thu May 28 00:33:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yex2y-0006ev-00; Thu, 28 May 1998 00:24:20 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yex2x-0006eK-00; Thu, 28 May 1998 00:24:19 -0700 Received: from big-bear (big-bear.precept.com [204.162.119.41]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA22939; Thu, 28 May 1998 00:21:49 -0700 (PDT) Date: Thu, 28 May 1998 00:21:49 -0700 (PDT) From: Stephen Casner X-Sender: casner@big-bear To: Valter Mazzaro cc: rem-conf@es.net Subject: Re: Question about IP/UDP/RTP headers compression In-Reply-To: <199805261736.TAA21929@kk661.kk.etx.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 26 May 1998, Valter Mazzaro wrote: > I've checked 'PPP' and 'PPP in HDLC-like framing' RFCs and I haven't yet > figured out where (or how) the packet length indication comes from > (or is deduced). There is not an explicit length field. HDLC framing uses a starting flag character and ending flag character to delimit the frame. The packet length is determined from the number of bytes in between (after subtracting overhead bytes such as checksum). -- Steve From rem-conf Fri May 29 21:50:58 1998 From rem-conf-request@es.net Fri May 29 21:50:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yfdQd-0002k1-00; Fri, 29 May 1998 21:39:35 -0700 Received: from (forest.icast.com) [209.1.118.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yfdQc-0002jq-00; Fri, 29 May 1998 21:39:34 -0700 Received: (from mail@localhost) by forest.icast.com (8.8.5/8.8.5) id VAA22709; Fri, 29 May 1998 21:39:32 -0700 Received: from apache.icast.com(192.168.20.10) by forest.icast.com via smap (V2.0) id xma022707; Fri, 29 May 98 21:39:30 -0700 Received: from shazamm.internal.icast.com ([192.168.20.112]) by apache.internal.icast.com (8.8.5/8.8.5) with SMTP id VAA28780; Fri, 29 May 1998 21:39:12 -0700 (PDT) Message-ID: <356F8B9D.17B9@icast.com> Date: Fri, 29 May 1998 21:31:25 -0700 From: Vinay Kumar Reply-To: vinay@icast.com Organization: ICAST Corporation X-Mailer: Mozilla 3.02 (Win95; I) MIME-Version: 1.0 To: mbone@isi.edu CC: rem-conf@es.net, mboned@network-services.uoregon.edu Subject: icast c:tv 3.0 beta release Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list the icast c:tv software is fully compatible with vat/vic/sdr and works on Win95, Win NT 4.0, and MacOS8. "icast c:tv 3.0" includes: - viewer & guide 3.0 software for viewing sdp, rtp, rtcp. includes video codecs (h.263, h.261). - iss (icast server suite) 3.0 includes: recorder server: records and playsback any ip multicast rtp stream. relay server: converts multicast to unicast rtp streams. meter server: enables rtcp monitoring. iss runs as an NT service. - streamsMeter client 3.0 viewer to connect to icast meter server and monitor rtcp stats. - broadcaster, 2.2.1 server to transmit h.261, h.263 live streams; or pre-recorded AVI files. as you can see, we are fully committed to the advancement of open standards based IP Multicast protocols (rtp, rtcp, sap, sdp et.al.) and applications. however we are a commercial company and have to pay our own salaries therefore we do recommend everyone to eventually buy the product(s). this is the only way to fix and stabilize the MBone and make it a household name for internet broadcasting. Download site: http://www.icast.com/evalform.html submit bug-reports to: support@icast.com ICAST website: http://www.icast.com/ we will do our best to fix outstanding bugs, problems and interoperability issues in our products. please report bugs to: support@icast.com. we look forward to working with you. happiness and regards --- vinay http://www.icast.com/evalform.html From rem-conf Sat May 30 15:44:47 1998 From rem-conf-request@es.net Sat May 30 15:44:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yfuGd-0002D1-00; Sat, 30 May 1998 15:38:23 -0700 Received: from mail.ats.it [195.62.227.25] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yfuGb-0002Cn-00; Sat, 30 May 1998 15:38:21 -0700 Received: from gSlqb60l9 (1Cust100.tnt2.orl1.da.uu.net [208.250.78.100]) by mail.ats.it (8.9.0/8.8.7) with SMTP id AAA21536; Sun, 31 May 1998 00:31:45 +0200 From: E0jrO9dS1@1step6.za DATE: 30 May 98 6:29:41 PM Message-ID: TO: magnli4y.ur@mail.ats.it SUBJECT: In the market for a new car? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Union Nissan of Lake County can show you over 500 new, almost new program cars, and fully certified used cars of all makes and models. Whether you're looking for a great buy on a used vehicle, would like to save thousands on a program car, or you really have your heart set on a new car; you owe it to yourself to see our selection and talk to our people. Our service department has evening and Saturday hours and every new Union Nissan comes with Gold Card privileges. Your Gold Card will entitle you to $9.95 lifetime oil changes, free service loaners, free towing and more! We invite you to e-mail our Internet Sales Manager Aaron Segal at unionnissan@iconnect.net or e-mail directly >from our website, www.unionnissan.com., or call (847) 244-8000 and ask for Aaron. ALL INTERNET CUSTOMERS WILL RECEIVE A FREE TIRE ROTATION JUST FOR COMING IN. We look forward to hearing from you! From rem-conf Sun May 31 23:16:09 1998 From rem-conf-request@es.net Sun May 31 23:16:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ygNeD-0003hc-00; Sun, 31 May 1998 23:00:41 -0700 Received: from sasi.com (samar.sasi.com) [164.164.56.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ygNeA-0003h7-00; Sun, 31 May 1998 23:00:39 -0700 Received: from lnxc34.sasi.com (lnxc34.sasi.com [10.0.32.34]) by samar.sasi.com (8.8.7/8.8.7) with ESMTP id LAA10801 for ; Mon, 1 Jun 1998 11:31:42 +0530 Received: from lnxc34.sasi.com (anoop@localhost [127.0.0.1]) by lnxc34.sasi.com (8.8.7/8.8.8) with ESMTP id LAA02479 for ; Mon, 1 Jun 1998 11:27:51 +0530 Message-Id: <199806010557.LAA02479@lnxc34.sasi.com> To: rem-conf@es.net Reply-To: anoop@sasi.com Subject: H.323 protocol stack. Date: Mon, 01 Jun 1998 11:27:46 +0530 From: Anoop Kulkarni X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Is there any public domain H.323 protocol stack implementation available? If not, then what are the companies that sell the development version of H.323 (alongwith source code that is)? If it *has* to be bought, then what is the typical price range? Thanks a lot for your responses, Best regards, anoop -- ---------------------------------------------------------------------------- Home : Anoop Kulkarni, PhD | Office: Anoop Kulkarni, Flat A2, Pioneer | Silicon Automation Systems (I) Pvt Ltd. Residency, HAL III | 3008, 12th 'B' Main, 8th Cross, Stage, Bangalore 75 | HAL II Stage, Bangalore 560008, INDIA Phone: +091-080-528 5749 | Fax : +091-080-528 4396 Email: anoop@sasi.com | Phone : +091-080-528 1461 ext 4001 ----------------------------------------------------------------------------